要用一个大模型，路有两条：把权重拉到自己的服务器，或调别人家的接口。结论先行：数据敏感、需要深度定制、有运维团队，选自部署；求快上线、流量波动大、团队精简，调 API。
差异一：数据走到哪
自部署的数据不出自己的机房，合同、代码库这类敏感资产可以留在内网，这是它最大的不可替代性。调 API 意味着数据要出网到服务商，多数厂商承诺不用于训练，但链路毕竟经过第三方。合规审查常把这一条作为硬门槛——先过数据边界这关，再谈别的。
延迟和服务等级也要算进去。自部署的延迟取决于自家硬件，优化空间在自己手里；API 的延迟取决于服务商的负载，高峰期排队不可控，还受限于服务商的技术选型。对响应时间敏感的业务，这一项常常比单价更能左右选择。
差异二：成本与弹性
自部署是重资产：一次性投入显卡与建设费，之后边际成本趋近于零，流量翻倍只要机器扛得住。调 API 是轻资产：按 token 付费，零预付，但流量涨成本线性涨，长文档场景账单可能超预期。流量平稳且利用率高，自部署便宜；流量忽高忽低或刚起步，API 的总成本往往更低。Q4 和 Q8 量化版差多少那篇讲的档位选择，就是自部署路线里控制成本的核心手段之一。
差异三：运维负担与能力边界
自部署要自己管扩容、监控、故障恢复、版本升级，一个值班的工程团队是隐性成本；好处是行为完全可控，模型可以随便微调。调 API 把这些打包带走，换来的是省心，代价是定制受限——多数 API 只暴露参数级调优，动不了权重。想挂适配器改风格，基本只有自部署一条路，LoRA 文件和全量模型怎么配合用那篇讲的定制深度，在这里划出了两条路的能力差。
运维压力还有隐性的一面：安全更新。自部署的模型服务要跟漏洞、依赖库、显卡驱动打交道，一个没人盯的开源组件就能成为入口；API 把这部分责任转移给服务商，出事有对方的安全团队兜底。团队里没有专职安全岗的话，这一项的权重还要往上加。
| 维度 | 自部署权重 | 调 API |
|---|---|---|
| 数据边界 | 不出自家机房，敏感资产留在内网 | 数据出网到服务商，链路经过第三方 |
| 成本结构 | 重资产，一次性投入后边际成本趋近于零 | 按 token 付费，流量涨成本线性涨 |
| 延迟与弹性 | 取决于自家硬件，优化空间在自己手里 | 取决于服务商负载，高峰期排队不可控 |
| 运维与定制 | 自己管扩容、监控、升级，权重可随便微调 | 省心但定制受限，多数只暴露参数级调优 |
选型速查表
- 数据不能出网：自部署，没得商量
- 流量平稳、利用率高：自部署更省
- 流量波动、快速试错：调 API 更稳
- 要挂适配器改权重：自部署，API 做不到
混合路线正在成为默认答案
成熟团队常两条腿走路：敏感业务走内网自部署，创新业务走 API 快速验证，用同一套评测集给两条路打分。腾讯元宝、讯飞星火的政企方案与开放 API 并行，正是服务这种混合需求。选型时不必一次定死，先小流量双轨跑，让账单和指标说话。
双轨运行还要防一个问题：两边的提示词、参数、评测标准要统一，否则测出来的分数没有可比性。常见做法是同一份测试集、同一套打分脚本，分别打给两边，定期复盘。成熟团队还会把两边的成本、延迟、错误率画进同一张看板，让迁移决策有据可查。
关于自部署与API，问得最多的三个
- 自部署一定更省钱吗？：只在流量平稳且利用率高时成立，算上显卡折旧、电费、人力，低利用率下自部署反而更贵。
- API 的数据真的不用于训练吗？：主流厂商多承诺不用于训练，但条款随时可能调整，以最新服务协议为准，敏感场景建议走私有化。
- 两条路的效果一样吗？：同权重同参数下接近，但 API 侧的推理优化常更好，细节参考领域特化和通用模型差在哪那篇的评估思路。
收束一句：数据定生死，流量定成本，定制定路线，三问过完再拍板。
