先把算力定义为前置条件，不是后置配套
在很多企业的AI项目里，模型选型常被当成第一道决策，但“先模型后算力”常把风险延后到上线后才暴露。随着业务全面接入，临时加购算力虽然方便，却容易形成连锁迁移压力。上云前应先把业务峰值、延迟目标、数据更新节奏和故障恢复要求转成可执行的资源边界，再决定部署规模。
上云前先做四维算力盘点
单看GPU数量不足以判断是否可上云，算力能力是一个系统能力组合。算力、存储、网络和编排控制缺一不可，任何一层不足都会让模型扩容演变为“补丁式”建设。企业在立项时应按这四维建立容量基线并形成共识。
- 推理链路：核验实时与异步请求比例、超时容忍度、可降级策略，决定计算池结构。
- 数据链路：评估训练数据、日志与向量数据的增量速度，提前预留读写与备份容量。
- 检索与存储链路：向量检索、对象存储和数据库必须同时扩展，不然会出现“模型快、数据慢”的错位。
- 运维链路：自动化编排、监控与故障恢复能力决定容量方案是否真的可持续运行。
容量预算盘点应看“边界场景”而非平均场景
企业常用平均QPS或日均并发作估算，但真实服务受促销、节假日、外部事件影响会出现突发波峰。预案必须定义峰值场景下的可接受响应时间与降级路径，避免系统一味扩容。将“可接受失败率、最长排队时间、恢复时长”写入前置方案，可让团队在压力到来前知道如何应对。
- 基线容量：保障日常业务稳定运行的最低算力。
- 弹性容量：应对可预见波峰的阈值区间。
- 熔断容量：触发人工确认或服务降级前的上限。
模型扩容失控通常由“合理请求”触发
扩容失控很少是一次性错误，更常见于多个看似合理的变更叠加。研发团队为了提升效果增加上下文长度和工具链，产品团队扩大功能闭环，运维团队再补充副本，形成资源指数上升。没有统一额度与审批机制时，预算、性能和交付目标会逐步偏离，故障修复反而更慢。
- 新增模型版本后未更新容量模型，旧估算继续沿用。
- 日志与监控级别提升，导致I/O与存储负载同步上升。
- 长尾请求和重试策略放大并发，排队与超时呈现雪崩。
- 预算告警缺失，团队只能事后解释费用增长。
实践上，先盘点再上云，才是可控的扩容节奏
治理上建议把容量预算与发布流程绑定，任何模型升级都要先提交资源增量说明。业务、技术、财务三方联合评审后，再进入分阶段上云，先在受控环境观察再扩展到全量场景。这样不仅降低扩容失控概率，也能让AI项目在2026年保留演进空间，而不是被短期算力浪潮推着跑。
- 流程上：建立“评估-审批-发布-回顾”的闭环，扩容动作必须有依据。
- 技术上：用统一监控看见GPU、网络、存储与队列的关联趋势。
- 策略上：设置弹性上限和人工确认线，避免盲目自动扩容。
