比的是约束与总成本
自托管与 API 调用不是优劣之争，而是约束边界与总拥有成本的权衡。先确认硬约束：数据能否出域、是否需要固定出口、延迟上限、可用性责任归属；再看软指标：单位成本随请求量的变化、模型迭代速度、运维人力、合规审计要求。硬约束决定可行集合，软指标只在可行集合内排序。
基本信息
| 硬约束 | 数据出域限制、驻留地区、审计与留痕要求、出口策略 |
|---|---|
| 规模相关量 | 平均与峰值并发、输入输出 token 分布、突发倍数 |
| 成本构成 | 计算资源、存储与带宽、运维人力、许可与合规成本 |
| 责任划分 | 模型质量与可用性由谁承担、故障响应时间要求 |
| 迭代速度 | 自托管需要自行跟进新权重与推理栈升级 |
| 混合形态 | 敏感任务自托管、通用任务走 API 的分层方案 |
典型使用场景
- 合规前置评估：数据分类后判断哪些场景必须留在自有环境
- 容量规划：按峰值并发与突发倍数比较两种形态的可扩展性
- 成本对比：把人力与运维计入后重算单位成本，而不是只比算力
- 技术验证：先在小规模自托管上验证质量与延迟，再决定是否扩量
- 架构设计：设计分层路由与降级路径，避免单点依赖
- 对外承诺：明确可用性目标由哪一层承担，避免承诺无法保障的指标
决策维度对照
| 维度 | 自托管 | API 调用 | 判断口径 |
|---|---|---|---|
| 数据边界 | 数据留在自有环境，可控性高 | 数据需按协议出域，依赖厂商条款 | 是否有不得出域的硬约束 |
| 单位成本 | 前期投入高，随量摊薄 | 随用量线性变动，含免费额度差异 | 按实际用量分布测算，不按单价 |
| 弹性 | 受自有资源上限约束，需预留冗余 | 通常可弹性扩展，但受配额与限流 | 峰值倍数与扩容时间要求 |
| 迭代速度 | 需自行跟进权重与推理栈，掌控强 | 跟随厂商更新，可能静默变化 | 能否接受行为漂移与升级节奏 |
| 可用性责任 | 自行保障，需要值班与监控 | 依赖厂商 SLA，需自建降级路径 | 对外承诺的可用性指标归属 |
| 运维投入 | 需要专门的推理与容量人力 | 需要对接、限流与成本治理人力 | 长期是否有稳定团队 |
| 能力上限 | 受本机可承载的模型档位限制 | 可选用更高档位模型 | 任务是否依赖最强档位 |
总成本对比模板
总成本对比模板
# 用占比与用量分布表达，避免引用会变动的价格数字
period: 月度
usage:
requests: 需求方给出的实际请求量
input_tokens_p50_p95: 输入长度分位
output_tokens_p50_p95: 输出长度分位
burst_factor: 峰值与均值倍数
self_host:
compute: 按预留冗余后的资源占比
storage_bandwidth: 占比
ops_headcount: 折算人力占比 # 常被忽略的最大项
license_compliance: 占比
api:
usage_cost: 按用量分布折算
engineering: 对接与治理人力占比
fallback_buffer: 降级路径预留
qualitative:
data_residency: 是否满足硬约束
iteration_ownership: 谁负责跟进升级
switching_cost: 换供应商或换权重的迁移代价把运维人力按占比计入后，结论常常反转：小规模场景自托管的单位成本远高于直觉，而大规模稳定负载下自托管的摊薄优势才显现。测算时要用实际用量分布，而不是理论上限。
混合形态往往比二选一更现实：敏感数据留在自有环境，通用请求走 API，并设计统一的调用层屏蔽差异。这样既满足合规边界，也保留能力与成本的弹性。
只比较单价会得出错误结论：限流、重试、失败重跑、上下文冗余与提示词膨胀都会放大实际用量。预算模型要基于观测到的用量分布，并保留缓冲；厂商计费口径与配额以官方文档为准。