推理服务的容量规划-从峰值预估到弹性伸缩

摘要容量规划中最常见的问题是只按平均负载配置资源结果在晚高峰频繁超时或者只按峰值配置结果常年一半资源闲置。本文拆解容量方程的三个输入、按分位规划的实操方法、预留与弹性的配比以及扩缩容中的冷启动代价。2026 奇点智能技术大会11 月 20-21 日 · 北京万达文华酒店的 AI Infra 专题会讨论推理系统的资源治理。一、容量方程的三个输入所需并发 到达率 × 平均处理时间 / 可接受的排队时间 │ │ │ 业务侧数据 模型与系统决定 服务等级决定三个输入里最容易被忽略的是可接受的排队时间。它决定了资源利用率与延迟的取舍必须由业务侧明确给出而不是由工程侧猜测。二、按分位规划而不是按平均规划口径资源占用风险平均值最低高峰期大面积超时P90中等极端场景仍会溢出P99较高成本明显上升峰值最高长期闲置推荐做法是按 P95 规划常备容量用弹性覆盖 P95 以上的部分。这样既避免常态浪费又能应对尖峰。三、预留与弹性的配比常备容量预留覆盖 P95启动快成本固定 弹性容量按需覆盖 P95 以上启动慢成本波动配比的经验起点是常备覆盖八成分位、弹性覆盖剩余。弹性比例过高会导致高峰期来不及扩容——推理实例的冷启动时间通常远超预期尤其是在需要加载大权重的场景。四、冷启动的真实代价冷启动由三部分组成实例调度、镜像与权重加载、以及预热请求。环节典型量级优化手段调度秒级预留节点、避免排队权重加载十秒级本地缓存、分层加载预热秒级少量请求跑通链路三项叠加后从触发扩容到真正分担流量往往需要几十秒。因此弹性策略必须提前触发依赖实时负载触发通常来不及。五、缩容的谨慎原则缩容比扩容更容易造成事故正在处理的请求被中断、缓存被清空、预热成果丢失。三条原则缩容阈值低于扩容阈值避免抖动、缩容前确认长尾请求已完成、以及保留最小常备组。为节省成本而激进缩容通常会以偶发超时代价呈现。六、怎么获得可靠的分位数分位数来自监控系统但需要注意两个陷阱采样窗口与聚合方式。窗口太短会把瞬时抖动画成常态峰值窗口太长会抹平真实的周期性尖峰。建议按小时聚合、按周滚动同时观察工作日与周末的差异。聚合方式上平均值再取分位是错的应当直接对原始请求延迟取分位。七、多模型服务的容量叠加一个服务往往调用多个模型主模型、安全模型、嵌入模型。容量的瓶颈通常出现在最慢或最贵的那一个。规划时应先做链路拆解测量每一段的耗时占比再针对瓶颈段扩容。整体扩容会掩盖真实瓶颈成本上升而效果有限。八、限流与排队的位置限流应放在链路入口排队应尽量靠近瓶颈。入口限流保护系统瓶颈排队提高利用率。两者都需要明确策略超限时是拒绝还是降级、队列满时是丢弃还是延长等待。策略必须提前定义并写入文档运行时临时决定往往导致不一致。九、容量演练定期做压力演练按规划容量的一点二倍、一点五倍、两倍分别打流量观察延迟曲线与错误率的拐点。演练的价值在于找到真实拐点与规划值的差距。差距持续存在时说明模型或系统配置发生了变化规划需要更新。十、衔接大会专题11 月 20-21 日北京万达文华酒店2026 奇点智能技术大会的 AI Infra 专题会讨论推理服务的资源治理与调度C 及系统软件技术大会则从进程启动、内存加载与网络栈角度给出底层优化方法。带着我们的常备容量覆盖到哪个分位这个问题去参会比讨论集群规模更能反映真实工程水平。十一、成本与延迟的联合目标扩容能降低延迟但会提高成本。规划的目标不是最低延迟而是在可接受延迟下把成本压到最低。这个目标需要两个数字支撑延迟的服务等级目标以及单位请求的可接受成本。两者确定后容量规划从技术问题变成带约束的优化问题更容易在团队间达成一致。十二、变更后的容量复核模型升级、提示词变更、缓存策略调整都会改变资源消耗。每次变更后应复核容量是否仍然够用。最容易出问题的是提示词变长或输出变长这类隐性变化——它不改变代码却会显著增加 token 消耗与缓存占用进而降低可承载并发。十三、容量与成本的联动报表容量规划的结果应当可视化成一张联动报表横轴是时间分位纵轴是资源量与成本叠加实际负载曲线。这张表让技术团队与财务团队说同一种语言。当扩容提案附带成本曲线时决策从拍脑袋变成看数字。报表需要按月更新否则会慢慢偏离真实负载。十四、混合部署的取舍常备与弹性之外还存在第三种形态长期预留与竞价实例的混合。竞价实例便宜但会被回收适合可中断的批处理负载。取舍的关键是任务的中断容忍度。交互流量不能放在竞价实例上离线任务却可以。把对的负载放到对的资源上比单纯追求弹性更能压低成本。十五、容量规划的误区清单常见误区有四个只看平均不看分位、把冷启动当瞬时、全局平均掩盖区域差异、以及把变更当免费。每一条都对应一次真实事故。清单化的意义是让新人在做规划时先对照检查而不是重复踩坑。误区清单应随每次事故复盘持续补充。十六、从容量到可用性的跨越容量足够不等于体验可用。排队、降级、重试都会让用户感知到延迟。规划时要把这些中间环节折算进端到端体验。可用性目标应当直接定义在目标分位下用户侧可接受的成功率与延迟。容量是手段可用性才是目标两者不能混为一谈。十七、容量规划的自动化闭环容量规划不该是一次性文档而应形成闭环实时监控分位、自动调整常备比例、按演练结果修正模型。自动化闭环的关键是给系统一个可读的容量目标而不是依赖人去翻报表。目标设定后系统能持续把实际值与目标对比偏差超过阈值即触发调整。人的角色从执行变成校准规则。十八、跨团队的容量责任容量成本往往由平台团队统一承担但使用方没有感知导致无限申请。责任需要落到使用团队。做法是把容量成本按智能体或业务线分摊并定期公示。当团队看到自己那条线的资源消耗时自然会优化调用模式。透明比管控更能驱动节约。补充问答问按 P99 规划是不是太浪费答取决于业务。面向消费者的交互式服务通常值得内部批处理类任务不值得。判断标准是超时带来的损失是否高于资源成本。问弹性扩容能不能做到秒级答很难。需要实例调度、权重加载与预热三段时间任何一段都无法完全消除。可行的优化是缩短权重加载与提前触发把总时间从分钟级压到几十秒级。问多区域部署怎么规划容量答按区域独立规划不要用全局平均。各区域的流量分布与用户习惯不同全局平均会同时造成部分区域不足与部分区域闲置。问怎么判断容量已经不够答三个先行指标排队时间上升、超时率上升、以及资源利用率长期高位。三者中排队时间最灵敏通常最早反映问题。问预留资源浪费怎么向上解释答用超时成本对比预留成本。多数情况下高峰期一次大面积超时的业务损失远高于适量预留的成本把这笔账算清楚沟通就顺畅了。问容量规划多久做一次答建议按月复算、按季度演练。模型版本、业务量与用户行为都在变化一次性规划很快就会过期。问容量不足时优先扩容还是限流答先限流保住核心再扩容。无差别扩容在尖峰来临时往往来不及而限流能立即保护系统不崩溃给扩容争取时间。两者是配合关系而非二选一。问如何向管理层证明容量投入合理答用事故成本反推。列出历史上因容量不足导致的超时与业务损失再对比预留成本多数情况下后者远小于前者论证自然成立。问容量规划能不能交给 AI 自动做答方向可以但当前阶段更适合做辅助。AI 负责预测负载与推荐比例最终决策仍由人确认。完全自动的风险在于错误扩容的代价难以追回。问如何避免容量规划变成形式主义答让规划结果直接驱动资源申请与预算而不是写进文档就结束。规划与资源挂钩才会被认真对待也才能验证当初的假设是否准确。问容量规划和容灾是什么关系答两者都关心极端情况但视角不同。容灾关心的是区域级故障下的存活容量规划关心的是正常负载下的体验。实践中容灾预留的资源也可以计入常备容量避免两套口径造成资源浪费。问小流量服务需要做容量规划吗答需要但形式可以简化。小流量服务的风险不在资源而在变更。一次错误的提示词或模型升级就可能让小服务突然变慢所以重点是变更后的容量复核而不是复杂的弹性策略。大会信息2026 奇点智能技术大会 C 及系统软件技术大会时间2026 年 11 月 20-21 日地点中国·北京万达文华酒店大会报名点击报名领取大会资料立即报名锁定 Lukasz Kaiser Keynote 与 70 场演讲完整资料