GPU 推理容量规划：从 token 吞吐、显存模型到峰值与故障冗余

“每天一百万次请求需要多少张 GPU”没有可靠答案。两个请求都算一次，一个可能是 200 token 输入、50 token 输出的分类，另一个可能带 20K 上下文并生成 2K token；前者可以高效动态批处理，后者长时间占用 KV Cache 并拖慢同批请求。GPU 推理容量规划必须从工作负载分布和服务目标出发，而不是从日均请求数或厂商峰值吞吐倒推。

先为每个模型和任务采集输入 token、输出 token、到达时间、流式与否、优先级、首 token SLO、完成延迟 SLO、取消率和缓存命中。至少保留 P50、P95、P99 以及分钟级峰值，日均会掩盖发布活动与时区叠加。敏感提示词不必进入容量数据集，长度、任务类别、租户和经过脱敏的路由标签通常已经足够。

把预填充与解码分开建模

LLM 推理包含 prefill 和 decode。长输入主要消耗预填充算力与 KV Cache，长输出则让解码槽位持续更久。容量表应分别记录每种 GPU、精度、张量并行度、模型版本和推理运行时下的 prefill tokens/s、decode tokens/s、首 token 延迟曲线、最大并发序列与显存占用。不要把实验室里单一短输入的峰值 tokens/s 当作生产能力。

显存预算可以拆成模型权重、运行时工作区、KV Cache 与安全余量。权重相对固定，KV Cache 随层数、序列长度、并发和数据类型增长；运行时还可能因 CUDA Graph、量化内核或碎片化产生额外占用。用压测测得可稳定运行的并发上限，且在长短请求混合、取消、突发和持续运行后仍不 OOM。仅凭理论公式容易漏掉实现开销。

批处理提升吞吐，却可能损害等待时间。对交互请求设置最大批等待和独立队列，对 LLM 批量推理 使用吞吐优先的队列与时间窗。若两类流量共享一个池，离线任务必须可抢占或严格限额，不能在夜间批任务尚未结束时占满第二天早高峰的解码槽位。

用排队模型估算，再用回放校准

一个实用起点是按高峰窗口计算所需 token 服务率，并乘以目标利用率的倒数。假设某任务高峰每秒到达 20 个请求，P95 输入 1,500 token、输出 300 token，不能简单计算 20 * 1800 后除以单卡峰值，因为 prefill 与 decode 资源不同、请求重叠且尾部更长。应把真实到达时间和长度序列回放到候选配置，观察排队、首 token 和完成延迟。

目标利用率也不是越高越好。GPU 长期 95% 忙碌可能经济，却不给突发、故障重调度和长请求留下余量。交互池常需要比批任务池更低的稳态利用率。平台应同时报告 GPU SM 利用率、显存、队列深度、活跃序列、等待时间、prefill/decode 吞吐、被拒请求和每百万 token 成本；基础采集可以衔接 Prometheus 与 Grafana 可观测性。

容量结论要写成可复现的配置矩阵，例如：

modelDigest: sha256:...
gpu: H100-80GB
runtime: serving-v2.4
precision: fp8
tensorParallel: 2
workload: interactive-code-2026q3
maxStableSequences: 72
testedPeakRps: 18
firstTokenP95: 780ms
decodeP95: 31ms/token
headroom: 30%

任何模型权重、运行时、驱动、精度或调度参数变化都应使旧结论过期。否则平台升级后仍按几个月前的单卡数字分配，很容易在真实峰值才发现容量断层。

为扩容延迟和故障预留容量

GPU 节点扩容通常比 CPU 慢：云端可能缺货，节点启动后还要安装驱动、拉取大型权重、校验并预热。自动扩缩容不能只看 GPU 利用率，因为利用率升高时排队已经形成。更合适的领先信号包括按优先级的队列等待、预计清空时间、活跃 token 数和可用 KV Cache。提前扩容后，要等模型真正 ready 才计入可用容量。

最小冗余来自故障域，而不是一个固定百分比。设计目标若要求丢失一台节点仍守住 SLO，就用 N+1 验证；若要求一个可用区故障仍服务关键流量，就确保剩余区域的热容量、权重副本和网络入口能接管。不要把待启动的实例当作故障容量。对于多个模型共享 GPU 的平台，还要模拟最热门模型故障迁移时是否挤占其他租户。

容量不足时的降级顺序应预先定义：先暂停低优先级批任务，限制超长输出和新会话，再按租户配额排队或拒绝；只有通过质量与合规评估的较小模型才能作为替代。静默截短上下文或随机换模型会把基础设施故障转成回答错误。云成本优化 提供采购与利用率视角，AI 成本归因 则帮助确认预留容量由哪些产品和租户承担。

每周重算而不是年度拍脑袋

容量计划至少包含基线、业务增长、已知活动、模型迁移、故障余量和不确定性区间。每周用真实分布重放，比较预测与实际：若 token 长度上升、缓存命中下降或新功能增加多轮对话，就更新未来四到十二周需求。对预留实例、按需实例和可中断资源分别标注可用性，不把便宜但会被回收的容量用于关键在线 SLO。

上线验收要进行三类演练：逐步增加到预测峰值并保持足够时间；突然注入突发流量观察排队与扩容；移除节点或可用区验证冗余。只有在请求长度分布、模型配置和 SLO 都与生产相符时，压测数字才有意义。最终产物不是“采购十张卡”，而是一份能说明负载、假设、性能证据、故障余量、扩容时延和成本归属的容量契约。

延伸阅读

• LLM 批量推理
• Prometheus 与 Grafana 可观测性
• 云成本优化
• AI 成本归因