GPU 容量规划不要按卡数算，要按 token、队列和 SLA 算

“我们有多少张 GPU”是最没用也最常被问的问题。更有用的问题是：这些 GPU 每天产出多少有效 token，训练任务平均排队多久，P95 是否达标，失败重试浪费了多少 GPU 小时。

AI infra 的容量规划要从资源视角切到产品视角。GPU 是成本中心，token、模型更新速度、任务完成率才是产出。

推理容量：从 token 开始

LLM 推理的容量可以粗略拆成：

capacity = replicas * tokens_per_second_per_replica

但生产里还要扣掉很多损耗：

• prompt 长度分布；
• output 长度分布；
• batching 效率；
• KV cache 碎片；
• 热点模型不均衡；
• 流式请求占用连接；
• 失败和取消请求。

所以容量压测不能只用固定 prompt。要用真实流量分布，至少分短问答、长文档、代码生成、工具调用、多轮对话几类。

训练容量：从 GPU 小时开始

训练任务的账本更像批处理：

effective_gpu_hours = allocated_gpu_hours * useful_step_ratio

useful step ratio 很关键。任务 Pending 不算，等数据不算，NCCL hang 不算，失败后重跑也要扣。一个团队“用了 1,000 GPU 小时”，不代表产出了 1,000 小时有效训练。

平台应该按队列统计：

这些数据比“平均 GPU 利用率”更能指导资源分配。

GPU 型号要和任务匹配

不是所有任务都该上最贵 GPU。

GPU 的优势是并行吞吐，但不同任务吃的是不同瓶颈。训练吃互联和显存带宽，embedding 更吃批量吞吐，Notebook 多半吃的是交互体验而不是满卡算力。

容量规划要考虑峰谷

在线推理有业务峰值，训练有提交峰值。二者混跑时，可以用时间和优先级错峰：

• 白天保护在线推理；
• 夜间放宽训练借用；
• 批量 embedding 走低优先级队列；
• spot 资源只跑可恢复任务；
• 热门模型保留 warm capacity。

Kueue 的借用和抢占可以把空闲 GPU 利用起来，但要有明确边界。训练不该抢掉生产推理，Notebook 不该阻塞大训练，批量任务要能被中断。

成本指标要进 API 设计

很多成本是在产品层产生的：

• 默认最大输出 token 太高；
• 上下文无限制；
• agent 循环没有步数上限；
• RAG 把大量低质量文本塞 prompt；
• 每个请求都走最大模型；
• 没有缓存和去重。

基础设施能优化吞吐，但产品也要给成本边界。模型路由、配额、限流、max tokens、context policy 都是容量规划的一部分。

一个实用容量看板

推理看板：

• 每模型 tokens/sec；
• TTFT/TPOT P50/P95/P99；
• KV cache 使用率；
• pending queue；
• 每租户 token 消耗；
• 每百万 token 成本。

训练看板：

• 每队列 GPU 小时；
• Pending P95；
• 失败原因；
• step time；
• checkpoint 成功率；
• GPU 利用率和数据等待。

容量规划不是月末盘点，而是每天调整队列、模型路由和默认参数。GPU 平台真正成熟的标志，是能解释每一块钱换来了多少可用算力和多少业务产出。

延伸阅读

• Kueue Resource Flavors
• vLLM Metrics
• NVIDIA DCGM Exporter