第一步：负载盘点分层
把现有与规划的负载按训练、微调、在线推理、离线批处理四类列出，标注调用量、峰值时段、延迟要求与数据级别。为什么先做这一步？因为不同负载对算力的要求差异极大，混在一起采购必然出现一部分闲置、一部分排队。
第二步：统一成本口径
把算力、网络、存储、运维人力折算到单位任务，形成可比较的账。怎么做？先选一个高频任务作为基准，按月计算总成本除以有效任务数，再逐步覆盖其他任务。没有统一口径，自建与租赁的比较就没有意义。
第三步：压测与基线
用真实流量或接近真实的合成流量做压测，记录吞吐、延迟与错误率随并发变化的曲线。基线的作用是设定扩容触发线，而不是追求最高分。测试条件要写清模型版本、批量与输入长度，否则下次无法复现，这也是为什么条件要写清。
第四步：混合部署与合同
核心与敏感推理放在可控环境，峰值与训练用租赁补充，并在合同中约定可用性、扩容时限、价格调整与退出迁移。边界是：不要把关键业务完全依赖单一供应商的临时配额，至少保留一条可切换的路径。
第五步：季度复盘
每季度核对账单、利用率与业务增长，决定扩容、缩容或迁移。复盘要有财务与业务共同参与，否则容易只看技术指标。把结论写入下季度容量计划，形成闭环，避免每年重复一次临时采购，边界在复盘要有业务参与。
适用与不适用
适合谁
- 算力支出增长较快、需要控成本的企业
- 需要自建与租赁并行的 IT 团队
- 准备重新签订算力合同的采购部门
不适合谁
- 负载极小、按需调用即可满足的团队
- 没有账单与监控数据、无法盘点的企业
典型场景
一家软件公司按清单推进：先盘点出离线报表占用大量峰值资源，再把报表迁到夜间低价时段；统一成本口径后发现某类任务单位成本异常，定位到重复调用；随后用压测设定扩容线，并与两家供应商签了互补协议。半年后账单增速低于业务增速。
可执行步骤
- 按四类负载盘点调用量、峰值时段与延迟要求，并逐项标注数据级别
- 选一个高频基准任务，统一单位成本的计算口径与统计周期后再推广
- 用真实流量压测，记录吞吐、延迟与错误率随并发变化的容量基线数据
- 确定混合部署的边界与可执行的切换路径，并同时保留人工兜底手段
- 按季度复盘账单、利用率与业务增长，并据此更新下季度的容量计划
常见坑
- 只做技术盘点不做成本归集，扩容决策仍然靠感觉，预算反复追加，还难以向管理层解释。
- 压测使用理想化流量，上线后并发一高就超时，容量基线失效，后续扩容判断都失去依据。
- 关键业务只依赖一家供应商的临时配额，一旦供给紧张便无路可退，只能被动接受涨价与排队。
自检与验收清单
- 负载是否按四类分层，并逐项标注数据级别与接口
- 是否有统一且可复现的单位成本计算口径与周期
- 压测条件是否记录完整，结果是否可以复现出来
- 是否保留了可切换的供给路径以及对应的降级预案
常见问题
没有专职平台团队怎么做？
先由运维牵头、财务配合，用账单与日志做最小化盘点，每季度一次即可。关键是形成固定的口径与节奏，而不是一次性做完。等负载增长到需要专职团队时，这些数据就是最好的起点。
混合部署的切换成本高吗？
取决于架构是否可移植。使用容器与统一推理接口、避免绑定专有算子，可以把切换成本降到可接受范围。若已深度绑定某家专有服务，迁移周期会明显拉长。
扩容触发线怎么定？
用延迟与利用率的组合而不是单一阈值：例如尾延迟连续一周超过业务容忍值，或峰值利用率长期接近上限，就启动扩容评估。触发线要随业务变化每年校准。