H100 显存预算怎么做：先算权重与 KV，再谈混合精度

买到一张 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, fKV{kv/GiB:.2f}GiB, ftotal{total/GiB:.2f}GiB, total capacity) assert per_token 131072 assert weights 524288 * per_token reserve capacity运行输出32768 KV4.00GiB total28.90GiB True 262144 KV32.00GiB total56.90GiB True短请求与长请求可以共享前缀但共享多少要依赖实际命中不应提前把理想命中率算进保底容量。这里也没有计算 CUDA Graph 捕获池、通信缓冲、激活峰值和量化元数据。脚本适合排除明显装不下的方案不能代替峰值测量。怎样把预算变成上线依据先固定模型 revision、tokenizer、引擎版本、量化配置和并行方式再逐档增加总驻留 token 数。每档记录显存峰值、抢占次数、TTFT 和 TPOT尤其观察长短请求混合时的尾部。启动时看到的空闲显存不是稳态峰值。FP8 也不能按“文件减半所以并发翻倍”决策。权重、KV 和临时计算可能使用不同精度需要分别核对后端支持与精度回归。本文只验证了 CPU 侧容量算术没有运行真实模型或 GPU。一个可靠预算的价值是把下一次测试要量什么说清楚。