当大模型应用的调用量逐渐增长，API 账单越来越高时，团队里总会有人提议：“我们自己部署开源模型吧，长期看更便宜。”这个判断可能正确，也可能大错特错。自建推理的真实成本远不只是 GPU 租金，而 API 的价格也在持续下降。 做决定之前，需要一套完整的测算框架。

两种方案的成本构成

API 调用

  • 直接成本：按输入和输出 Token 计费，部分服务商提供缓存折扣和批量处理折扣；
  • 隐性成本：较少，主要是集成开发和监控；
  • 特点：用多少付多少，无闲置浪费，弹性无限。

自建推理

  • 硬件成本：购买或租用 GPU 服务器，按小时或按月计费，无论是否在使用；
  • 运维人力：部署、监控、扩缩容、故障处理、模型更新，需要具备相应技能的工程师投入时间；
  • 配套设施：负载均衡、日志、监控、网络带宽、存储；
  • 机会成本：团队把精力花在基础设施上，而不是业务功能上；
  • 能力差距成本：如果开源模型效果不如商业 API，可能需要更多的人工审核或导致用户体验下降。

关键变量：利用率

自建推理最容易被忽略的是 GPU 利用率。GPU 按时间计费，如果你的流量在白天高峰、夜间几乎为零，大部分时间 GPU 都在闲置。

测算时，要用实际有效吞吐而不是理论峰值来计算单位成本：

每百万 Token 实际成本 = 月度总成本 ÷ 月度实际处理的 Token 数（以百万计）

月度总成本应包括 GPU、配套设施和分摊的人力。如果利用率很低，自建的单位成本可能远高于 API。

测算步骤

1. 统计当前用量与负载形态

收集过去一段时间的调用数据：每日总 Token 量、输入输出比例、峰值与平均值之比、请求长度分布。

2. 确定可替代的模型

用业务测试集评估哪些开源模型能达到可接受的效果，以及需要多大规模的模型，选型方法见中文开源大模型选型思路。

3. 估算所需硬件

根据模型规模、量化方案和目标并发，估算需要的 GPU 类型和数量。要考虑峰值负载和冗余备份，详见大模型推理 GPU 选型。

4. 实测吞吐

在候选硬件上用推理引擎做压测，得到在你的请求长度分布下的真实吞吐量和延迟。不要直接套用厂商宣传的数字。

5. 计算总拥有成本

把硬件、人力、配套设施加总，除以预计的实际处理量，得到单位成本，与 API 成本比较。

6. 做敏感性分析

调用量增长或下降一半会怎样？API 降价会怎样？开源模型升级会怎样？观察结论是否稳健。

什么情况下自建更合适

  • 调用量大且稳定：负载平稳、利用率高，规模效应明显；
  • 数据合规要求：数据不能离开企业边界或特定地域，参见企业使用大模型的数据隐私指南；
  • 需要深度定制：使用微调后的专有模型；
  • 延迟与可控性要求：需要固定的模型版本和可预测的延迟；
  • 任务适合小模型：分类、抽取等任务用小模型即可完成，自建成本很低。

什么情况下 API 更合适

  • 调用量小或波动大；
  • 需要最强的模型能力；
  • 团队缺乏推理基础设施的运维经验；
  • 产品处于早期，需求和模型选择还在快速变化。

混合策略

很多团队最终采用混合方案：

  • 高频、简单的任务用自建小模型处理；
  • 复杂、低频的任务调用商业 API 的强模型；
  • 通过模型路由自动分配请求，参见大模型 API 成本优化；
  • 自建服务作为基础容量，峰值流量溢出到 API。

小结

自建与 API 的选择不能只看 Token 单价。利用率、运维人力、模型能力差距和合规要求，都是决定性因素。按照“统计用量—评估模型—估算硬件—实测吞吐—计算总成本—敏感性分析”的步骤测算，结合混合策略，才能找到成本与效果的最佳平衡。