买到一张 H100，并不等于拿到了型号名称里那一整块可任意使用的显存。模型权重、KV Cache、算子临时空间和运行时余量同时竞争容量。模型能加载，只说明第一关过去了；长上下文和并发常常在第二关触发 OOM。
10 月 18 日发布的 vLLM v0.32.0 又增加了一批模型与执行路径。升级清单可以很长，容量评审仍应从具体模型结构、精度和服务长度开始。不能拿另一种架构的 KV 公式直接套用。
把缓存规格和显存容量分开
NVIDIA Hopper 调优指南 给出的 H100 L2 为 50 MB，统一 L1/纹理/共享内存为每 SM 256 KB；它们都不是模型权重存储容量。这些层级决定数据复用方式，不能拿来补足几十 GiB 的显存缺口。选型时还要记录 SXM、PCIe、显存版本及实际设备报告，别把不同 SKU 的带宽和容量拼成一张不存在的卡。
对普通 GQA 模型，未压缩 KV 的基础估算是2 × 层数 × KV头数 × 头维度 × 每元素字节 × 驻留token数。两个来自 K 与 V；驻留 token 数要汇总所有活动请求。MLA、滑动窗口、混合注意力、量化缩放与块填充都会改变这个账本。
示意图中的区段不按真实容量比例绘制；预算必须再用目标设备的峰值测量修正。
一个能查出量级错误的预算器
以下用一个教学用 8B 模型，假设 32 层、8 个 KV 头、头维度 128、BF16 权重和 KV。设备可用容量人为设为 80 GiB，另留 10 GiB；这不是 H100 产品规格表，也不是框架默认值。
GiB = 1024 ** 3 weights = 8_000_000_000 * 2 per_token = 2 * 32 * 8 * 128 * 2 capacity = 80 * GiB reserve = 10 * GiB for tokens in (32768, 262144): kv = tokens * per_token total = weights + kv + reserve print(tokens, f"KV={kv/GiB:.2f}GiB", f"total={total/GiB:.2f}GiB", total <= capacity) assert per_token == 131072 assert weights + 524288 * per_token + reserve > capacity运行输出：
32768 KV=4.00GiB total=28.90GiB True 262144 KV=32.00GiB total=56.90GiB True短请求与长请求可以共享前缀，但共享多少要依赖实际命中，不应提前把理想命中率算进保底容量。这里也没有计算 CUDA Graph 捕获池、通信缓冲、激活峰值和量化元数据。脚本适合排除明显装不下的方案，不能代替峰值测量。
怎样把预算变成上线依据
先固定模型 revision、tokenizer、引擎版本、量化配置和并行方式，再逐档增加总驻留 token 数。每档记录显存峰值、抢占次数、TTFT 和 TPOT，尤其观察长短请求混合时的尾部。启动时看到的空闲显存不是稳态峰值。
FP8 也不能按“文件减半，所以并发翻倍”决策。权重、KV 和临时计算可能使用不同精度；需要分别核对后端支持与精度回归。本文只验证了 CPU 侧容量算术，没有运行真实模型或 GPU。一个可靠预算的价值，是把下一次测试要量什么说清楚。
