先画负载曲线
利用率的前提是有稳定需求。把近三个月请求按小时画出来，分出稳定基载、可预测峰值与不可预测突发；基载长期占满的适合自建，峰谷比大的适合弹性。曲线没画就谈取舍，等于用感觉代替容量规划。
合规先过再谈成本
涉及个人信息、图纸与工艺参数的数据，要先确认能否出内网、是否需要出境评估，再比较成本。公有云服务的条款、日志留存与是否用于模型改进必须逐条核对；把合规留到审计时补，代价高于前期评估。
折算单位任务成本
比较要落到单位有效任务成本：自建含折旧、机房电力、运维人力与空闲浪费，云 API 含调用阶梯与限流后的重试。只比单卡小时或单次调用价格，会漏掉运维与闲置，得出相反结论，测算口径需财务确认。
混合架构与锁定
常见做法是自建承担基载与敏感任务，云 API 承接峰值与长尾模型，用统一网关做路由、限流与计量，避免业务代码绑死一家。边界是网关有维护成本，规模小时反而增加复杂度；切换演练要定期做，否则降级只是纸面方案。
适用与不适用
适合谁
- 已有稳定推理负载、正在评估自建或混合部署的企业
- 数据敏感、需要区分内外网处理的 AI 平台负责人
- 要给管理层做技术路线与成本对比的架构师
不适合谁
- 负载很小、按需调用即可满足的团队
- 要求全部数据与模型都放在公有云的场景
典型场景
某零售企业的推荐与客服推理白天高峰明显、夜间几乎空闲。团队把稳定基载放在自建推理集群，峰值溢出到公有云 API，由网关按队列长度切换，敏感会员数据只走自建。运行一个季度后，依据单位任务成本与超时率重新调整了切分比例。
可执行步骤
- 导出近三个月请求曲线，标出稳定基载、可预测峰值与突发，并完成负载分类
- 先做数据分级，确认哪些负载不能出内网、哪些出境需要评估后才能使用
- 把自建折旧、运维人力与闲置卡时，和云 API 调用一起折算到单位有效任务成本
- 用统一网关承接路由、限流、计量与降级，业务代码不直连单一厂商，便于切换
常见坑
- 只比单次调用价格，忽略自建的人力、机房与闲置卡时，测算结论可能完全相反，预算批了也难以落地。
- 先上线再补合规，数据流向与日志留存说不清，审计时被迫整体回退，业务连续性也跟着受牵连，返工代价很高。
- 业务代码直接写死某家接口，换供应商时改造成本被低估，所谓混合架构只剩一半，议价空间也随之消失。
自检与验收清单
- 是否画出近三个月按小时的负载曲线并完成分类
- 数据分级与出境评估结论是否书面化并有人签字
- 成本比较是否包含运维人力、机房电力与闲置卡时
- 是否部署统一网关、降级策略，并定期做切换演练
常见问题
自建一定比调用 API 便宜吗？
不一定。只有基载稳定、设备长期接近满载且运维能力到位时，自建的单位成本才可能更低；负载波动大或规模小，闲置与人力会抵消优势，应按单位有效任务成本测算而非单卡价格。
混合架构会不会太复杂？
取决于规模。负载有明显潮汐、又有数据分级要求时，混合能兼顾弹性与合规；若请求量很小，维护网关与两套环境的成本可能高于收益。复杂度要与管理能力匹配，并写清回退方案。
公有云 API 的数据会被用于训练吗？
取决于服务条款与所选产品，不能一概而论。采购前应逐条核对数据处理协议、日志留存与是否用于模型改进；涉及个人信息时按合规要求做评估并留存记录，必要时改用私有化部署。