先分清三类负载
推理、训练与评测的计费方式不同：推理按调用量或实例时长，训练按卡时，评测往往短时高频。混在一起算总账，无法判断成本花在哪，也难优化。怎么分？按负载类型分别记账，再按场景归集。
推理的计价单元
推理常见按输入与输出 token 分别计价，输出通常更贵；自建部署则按实例规格与运行时长计。选择哪种取决于调用量是否稳定与数据能否出内网。怎么选？稳定部分自建，峰值部分走云。
容量预留与按量
业务有明确峰值时，预留容量能保障响应；峰值不明显时按量更省。混合方式是保底预留加弹性按量，把确定性成本与波动成本分开管理。怎么定保底？按近三个月用量测算，避免按峰值一次买满。
存储网络与对账
向量库、对象存储、日志与备份按容量计费，跨区域传输与出网流量单独计价。这些项目在试点阶段金额小，进入生产后会随数据增长持续上升。怎么控？把账单拆到场景与接口维度，才能定位异常。
成本要能归到场景
算力账单由谁看？技术团队看用量结构，财务看结算口径，业务负责人确认场景分摊比例。三方每月对一次账，把异常归到具体接口与场景。只由一方看账时，超支往往到季度末才发现，此时能调整的空间已经很小，预算只能被动追加。分摊比例每半年复核一次，业务变化后及时调整。
适用与不适用
适合谁
- 需要为 AI 应用做成本预算的技术负责人
- 正在比较自建与云服务成本结构的企业
- 调用量增长后成本失控、需要优化的团队
不适合谁
- 仅做小规模试用、用量可忽略的团队
- 完全使用内部闲置算力、不涉及外部计费的组织
典型场景
某企业的问答应用上线后月度账单持续上升。技术团队把用量拆成推理、向量检索与存储三项，发现上下文过长导致输入 token 偏高，通过压缩提示与缓存重复问题，单位请求成本回到可控范围。
可执行步骤
- 把负载拆成推理、训练与评测三类，分别记录用量、单价与费用明细
- 确认各供应商的计价单元、阶梯与结算周期，写进成本测算表中留档
- 按峰值特征选择预留或按量，必要时采用保底加弹性的混合方式组合
- 把存储、出网与日志单独列项，按容量与流量增长趋势估算上限与弹性
- 建立按场景与接口分摊的月度对账机制，定位异常并复核优化效果闭环
常见坑
- 只算推理单价而漏掉存储与出网，第二年账单明显超出预算，又难以解释来源，只能被动接受
- 把试点用量当生产用量做预算，上线后成本成倍上升，预算缺口无法消化，只能紧急申请，流程上很被动
- 预留容量按峰值买满，闲时资源大量闲置，利用率长期偏低，单位成本被抬高，谈判也没底气
- 账单不拆分场景与接口，异常无从定位，优化只能凭感觉，投入产出说不清，复盘流于形式
自检与验收清单
- 推理、训练与评测三类负载是否分开计量核算
- 各供应商的计价单元、阶梯与结算周期是否确认
- 存储、出网与日志是否作为独立项单列估算与对账
- 是否建立按场景与接口分摊的月度对账与复核机制
常见问题
自建和云服务哪个更划算？
取决于利用率。利用率高且数据不能出内网时，自建可能更经济；用量波动大时，云的弹性更合适。需要按三年口径把运维人力也算进去，否则容易低估自建成本，也很难做公平比较。
token 单价会一直降吗？
不能假设。价格随供应商策略与模型版本变化，预算应留出调整空间，并在合同中约定价格调整的通知期与结算方式。把全部成本压在单价下降的预期上，风险很高，评审也难通过。
怎么估算月度用量？
用试点期的真实调用量乘业务增长系数，再按场景拆分。估算要区分工作时段与峰值，并预留重试与多轮对话带来的额外消耗，否则上线后很快会超预算，补申请很被动。