私有化部署还是调 API：企业 AI 选型绕不开的合规账

企业要用大模型，第一个绕不开的决策是：直接调用云端 API，还是在自己机房里部署一套。

这个问题经常被简化成「预算够不够」，但在我们实际接触的项目里，真正起决定作用的往往不是预算，而是数据能不能出门。

先判断数据能不能出企业网络

这是第一道，也是最硬的一道筛子。如果下面任何一条成立，基本可以直接排除公有云 API：

• 涉及个人信息且数据量较大，受个人信息保护法约束，跨境传输另有要求
• 属于党政机关内部办公系统，有明确的网络隔离要求
• 行业主管部门有数据不出域的规定，金融、医疗、能源等领域较常见
• 客户合同里写明了数据不得提供给第三方
• 需要通过等保三级测评，且测评机构对外部数据流转有明确意见

需要注意的是，「数据脱敏后再传出去」这个思路，在实际操作中比想象中脆弱。文档类数据尤其难脱敏，一份看似普通的会议纪要，把人名去掉之后，通过项目名称和时间往往仍然能定位到具体的人和事。真正要做到不可复原，通常会破坏文本的可用性，最后知识库也就没什么用了。

如果数据可以出门，再算成本结构

对数据敏感度不高的场景，比如面向公众的咨询问答、营销文案辅助，API 方案通常更划算，原因在成本结构：

调 API 是按用量付费，前期投入接近于零，用多少付多少。私有化部署是先付固定成本，一台能跑得动主流开源模型的推理服务器，加上运维投入，起步就是一笔不小的开销，而且无论用不用都在折旧。

所以这里的分界线大致是：

1. 用量小、波动大、场景还在探索期，用 API，把试错成本压到最低
2. 用量大且稳定，能算出私有化的回本周期，此时私有化才有成本优势
3. 用量小但数据必须留在内网，那就不是成本问题了，只能私有化

值得提醒的是，很多企业在评估时会低估私有化的隐性成本：模型要更新、显卡驱动要维护、并发上来要扩容、出了问题得有人能定位。如果内部没有相应的技术人力，这部分往往要外包，长期算下来未必比 API 便宜。

中间路线：把敏感的留下，把不敏感的送出去

实际项目里我们用得最多的其实是混合方案，因为纯粹的两极选择常常不划算。

一种常见做法是按数据分级路由：把业务划分成若干等级，涉密和内部数据走本地部署的模型，公开信息类的请求走云端 API。两条链路共用同一套前端和知识库管理界面，使用者感知不到差异。

另一种做法是只把向量检索留在内网。文档、向量库、检索全部在本地，只有最后生成答案那一步调用外部模型。这样传出去的只是与问题相关的少量片段，而不是整个文档库。这个方案能显著降低硬件门槛，但要清楚它并没有做到数据完全不出门，是否可接受取决于具体的合规要求，需要提前和合规部门确认，不要等到验收阶段才发现不合规。

国产模型是不是必选项

对党政机关和国企客户，这通常不是一道选择题。信创相关要求会直接约束可选范围，采购环节也会有明确的目录。

对一般企业，我们的看法是：中文场景下国产开源模型这两年的进步很快，在企业知识库这类以理解和总结为主的任务上，主流开源模型的表现已经够用，和顶级闭源模型的差距远没有通用榜单上看起来那么大。真正的差距更多体现在复杂推理和长链路任务上，而这些恰恰不是知识库的主要负载。

所以如果你的场景是文档问答、内容摘要、格式转换这一类，不必默认认为必须用最贵的模型。先用实际业务数据做一轮对比测试，往往会发现便宜不少的方案就能满足要求。

一个务实的决策顺序

综合下来，我们给客户的建议顺序是：

1. 先问合规，确定数据能不能出企业网络，这一步直接砍掉一半选项
2. 再问用量，估算稳定后的调用规模，算私有化的回本周期
3. 然后问人力，评估内部能不能承担私有化的长期运维
4. 最后才是选具体模型，并且用自己的真实数据测，不要只看榜单

顺序不能颠倒。我们见过不少项目一上来就在纠结用哪个模型，结果方案做到一半发现数据根本不允许出网，前面的工作全部推倒重来。合规是约束条件，不是优化项，它应该出现在决策链条的最前端。