过去两年，我们参与过四十余次选型评审。最常见的场景是：业务部门希望尽快上线，安全部门要求数据不出域，财务部门关心三年总成本，三方各有一套判断。争论几轮之后，往往以一个折中方案收场，半年后再推翻重来。
更高效的做法是先回答四道硬约束，再看成本。因为约束是刚性的，成本是可算的。
第一层：四道硬约束
- 数据能否出域：涉及个人信息、生产参数、未公开财务数据的场景，通常不适合直接送公有云。这里要注意区分「训练数据」与「推理时的输入」——很多争议其实只发生在后者。
- 延迟底线：需要 200 毫秒以内首字返回的交互场景（如产线质检、实时助手），跨公网调用很难稳定达标。
- 并发与峰谷比：峰谷比超过 8 倍的业务，自建算力会长期闲置；而以稳定负载为主的业务，自建的边际成本更低。
- 版本节奏：能否接受半年才升级一次模型。如果不能，公有云的优势会被显著放大。
四条里只要有一条是硬性的（不可折中），选型方向基本就定了。剩下的是把成本算清楚，说服另外两方。
第二层：三年总成本对照
成本对照要放在三年尺度上，且必须把「隐性人力」计入。我们习惯按下面这张表逐项填数，填不出数的项，就是风险项。
| 成本项 | 公有云 API | 私有化部署 |
|---|---|---|
| 算力 | 按量计费，无前期投入 | 一次性采购 + 三年折旧 |
| 模型迭代 | 厂商负责，自动可用 | 需自行评测、回归、上线 |
| 人力 | 集成与调优为主 | 额外需要运维与 MLOps 能力 |
| 闲置风险 | 无 | 峰值采购导致的长期闲置 |
| 合规成本 | 取决于厂商资质与协议 | 取决于自身安全体系建设 |
第三层：能力差距与追赶周期
私有化最容易被忽略的代价不是钱，是能力时差。开源模型与第一梯队闭源模型之间通常存在一段稳定差距，这段差距在多数业务场景里可以接受——前提是任务类型相对收敛，比如分类、抽取、摘要、结构化转换。
但如果业务依赖复杂推理、长文档理解或开放式生成，差距会被用户直接感知。我们的判断标准是：先用同一套评测集把候选模型跑一遍，看差距落在哪个环节。如果差距集中在「不常用的长尾问题」上，可以接受；如果集中在核心场景，就不要为了合规叙事牺牲可用性，改为混合路线。
第四层：混合路线的边界条件
混合是最常见的落地形态：敏感数据走私有化小模型，非敏感的高难度任务走公有云。它成立的前提有三个：
- 能把任务按数据敏感度与难度做分流，而不是凭感觉路由；
- 两类模型共享同一套评测集与提示词管理方式，否则效果无法比较；
- 路由规则本身可审计，避免出现「本该走私有化却发了出去」的情况。
架构上至少要做三层解耦：模型调用接口、检索与向量层、提示词与工作流层。解耦做得好，未来从公有云迁回私有化，主要工作是替换适配器与重跑评测，而不是重写业务。
常见问题
问：私有化部署一定比调用 API 更安全吗？
不一定。私有化解决的是数据不出域，但安全还取决于访问控制、日志留痕、依赖组件漏洞管理。我们见过一些自建环境，因为缺少统一权限与审计，实际风险高于使用具备合规资质的云服务。安全性要看体系，不能只看部署位置。
问：私有化部署需要多少算力投入？
取决于参数量、并发与是否量化。中等规模场景（数十路并发、以问答与文档处理为主）通常需要多张推理加速卡起步，并预留三成冗余应对峰值。建议先压测再采购：按厂商推荐值直接下单，是算力闲置最常见的原因。
问：能否先用公有云，之后再迁到私有化？
可以，但要在架构上预留模型接口、检索层、提示词与工作流三层抽象。把这三层与具体厂商解耦后，迁移主要是替换适配器与重跑评测集；如果业务代码直接嵌入了某家 SDK，迁移成本会明显上升。
最后一个提醒：选型文档里请写清楚「什么情况下我们会推翻这个决定」。没有退出条件的架构决策，通常会在两年后变成没人敢动的历史包袱。
本文结论基于天辰平台在制造、零售、金融与数字内容行业的交付经验，具体项目需结合自身约束重新测算。