模型工程系列新篇。前面聊的扩缩容、过载保护都是「容量不够之后怎么办」——这篇回到源头：容量怎么算。推理服务的容量规划和传统服务有个本质差异：瓶颈不在 CPU 核数，在显存带宽和显存容量，而这两个量跟模型结构强耦合——算错一个系数，采购就差一个数量级。
先立换算链：从业务量到 GPU
日翻译请求量 → 峰值 QPS → 并发请求数 → KV Cache 显存 → 模型副本数 → GPU 数
每一环都有系数，逐环拆。
环一：日均到峰值
用日均量估容量是新手错误——推理流量日内波动极大（工作时段尖峰）。正确姿势：取「工作时段 1 小时峰值 / 日均」的比值，翻译类业务典型 3~5 倍。容量按峰值 QPS × 1.2 冗余算，冗余系数留给重试和毛刺。
环二：QPS 到并发数
并发数 = 峰值 QPS × 单请求平均耗时。这是最容易被低估的一环：单请求 2 秒生成时间，10 QPS 就是 20 个在途请求——每个在途请求都占着一份 KV Cache。
环三：并发到显存（本篇核心）
单请求显存 = 模型权重分摊 + KV Cache。KV Cache 的公式：
KV Cache = 2 × 层数 × KV头数 × 头维度 × token数 × 精度字节
以主流 7B 级模型（32 层、GQA 后 KV 头 8、头维 128、FP16）为例：每 1K token 上下文约占 128MB 显存。一个 8K 上下文的请求 KV Cache 就是 1GB——长上下文业务里，Cache 比权重还吃显存不是夸张。
单卡容量上限速算：24GB 卡跑 7B（权重约 14GB）→ 剩 10GB 给 Cache → 按 4K 上下文/请求（0.5GB）→ 单卡约 20 并发。再对环二的并发需求，需要的卡数就出来了。
环四：别忘了带宽这个隐形瓶颈
显存算够只是「能装下」，跑得快还要带宽：推理是访存密集负载，生成速度 ≈ 带宽 ÷ 模型大小（粗算）。同一张 24GB 卡，带宽 1TB/s 跑 7B FP16 的生成速度上限约 70 tokens/s（全给单请求的理论值）——多并发分摊后每请求速度线性下降。采购时同显存不同带宽的卡差价，买的就是这个速度。
一张真实的规划表（翻译业务示例）
| 参数 | 值 |
|---|---|
| 日请求量 | 50 万次 |
| 峰值 QPS（×4 波动 ×1.2 冗余） | 28 |
| 单请求耗时 | 2.5s |
| 峰值并发 | 70 |
| 单请求 KV Cache（4K 上下文） | 0.5GB |
| 单卡可承载并发（24GB 卡） | ~20 |
| 模型副本数 | 4 |
| GPU 数（含 1 卡冗余） | 5 |
这行链条里任何一环的假设变了（上下文涨到 8K、模型换 14B），末端的 GPU 数直接翻倍——容量规划的文档价值就是把每个系数的依据写清楚，半年后流量涨了知道怎么重算，而不是重头猜。
三个实务提醒
- 量化改变一切：Q4 量化让权重减半、KV Cache 可配 FP8——同样的卡容量翻倍。规划表里「量化方案」是必填项，不是 footnote
- batching 是近乎零成本的容量增益：连续批处理（continuous batching）让同卡并发上限提升 2~3 倍——上 batching 前后的容量表是两张表
- 留 20% 的「意外税」：框架开销、碎片、监控 agent——实际可用显存永远比标称少，规划时打折要狠一点
（模型工程系列：扩缩容 → 混部 → 冷启动 → 输出缓存 → 过载保护 → 灰度发布 → 本文：容量规划）
