A
版块：AI 芯片与算力
现在采购推理服务器，很多人还在拿"算力够不够"说事，但现场拦路的几乎全是显存容量和带宽。这篇把显存账算一遍，再对齐几条主流解法的适用边界。（数据均为公开规格的量级估算，选型请以官方资料为准。）
一、先会算显存：一个 70B 模型到底吃多少
以 70B 参数、FP16 权重推理为例：
- 权重：70B × 2 Bytes ≈ 140 GB —— 单张 80 GB 卡装不下，最少 2 卡张量并行；
- KV Cache：近似 2 × 层数 × KV头数 × 头维度 × 序列长 × batch × 字节数。粗略记法：70B 级模型、4K 上下文，单条序列约 1~2 GB FP16；32 条并发就是 32~64 GB,比权重增量还快；
- 激活与碎片：再留 10~15% 安全水位。
结论很干脆：并发上去以后，显存增长的大头是 KV，不是模型本身。这也是为什么各家都在喊 PagedAttention / KV 量化 / 前缀缓存——都是在解显存题。
二、带宽比容量更早决定用户体验
推理分两个阶段，对硬件的索取完全不同：
- Prefill（读 prompt 生成首 token）：算力密集，吃 FLOPS；
- Decode（逐 token 吐出）：每生成 1 个 token 都要把全部权重读一遍——吞吐上限 ≈ HBM 带宽 ÷ 每字节权重的模型大小。H100 的 3.35 TB/s 量级带宽，跑 FP16 的 70B，理论上限就是每秒约 24 次全模型读取，batch 拉大靠的是 KV 并行摊薄。
- 所以量化从 FP16 → FP8/INT4，第一步收益是带宽（体积减半/四分之一），第二步才是算力释放。GPU 利用率打不满、decode 慢，多半是带宽不足不是算力不足。
三、几条"扩容"路线的真实边界
1. HBM 堆更多：单卡 80GB→192GB 级路线，容量解了，仍受功耗散热（每瓦带宽在进步但有限）；
2. CXL 内存池：适合 KV 卸载、多机共享，但延迟比 HBM 高一个量级，只能当"慢速 KV 层"，不能指望全放上去；
3. KV 量化（FP8/INT8 KV）与分组注意力（GQA/MLA）：模型结构侧省显存，目前性价比最高——MLA 把 KV 压缩一个数量级的路线已经被主流新架构采纳；
4. 多轮对话的前缀缓存：命中即省 Prefill；工程上按"会话路由+RadixAttention"做集群亲和；
5. 投机解码：用小模型打草稿大模型验算，本质是用多余的显存和算力换 decode 串行速度，带宽受限场景收益特别明显。
四、给平台/选型同学的一句话判断树
- QPS 优先、延迟宽松 → 堆 batch + KV 压缩 + INT8/FP8，容量优先选大显存单卡；
- 首字延迟优先（对话、Agent 工具链） → 投机解码 + 前缀缓存 + 亲和调度；
- 长文档/长上下文（32K+） → 显存先爆，先做滑动窗口/外部检索，再谈硬件。
大家在生产集群里 KV Cache 占显存的实际比例是多少？欢迎贴脱敏后的数字，这类"真实配比"比跑分有用得多。
现在采购推理服务器，很多人还在拿"算力够不够"说事，但现场拦路的几乎全是显存容量和带宽。这篇把显存账算一遍，再对齐几条主流解法的适用边界。（数据均为公开规格的量级估算，选型请以官方资料为准。）
一、先会算显存：一个 70B 模型到底吃多少
以 70B 参数、FP16 权重推理为例：
- 权重：70B × 2 Bytes ≈ 140 GB —— 单张 80 GB 卡装不下，最少 2 卡张量并行；
- KV Cache：近似 2 × 层数 × KV头数 × 头维度 × 序列长 × batch × 字节数。粗略记法：70B 级模型、4K 上下文，单条序列约 1~2 GB FP16；32 条并发就是 32~64 GB,比权重增量还快；
- 激活与碎片：再留 10~15% 安全水位。
结论很干脆：并发上去以后，显存增长的大头是 KV，不是模型本身。这也是为什么各家都在喊 PagedAttention / KV 量化 / 前缀缓存——都是在解显存题。
二、带宽比容量更早决定用户体验
推理分两个阶段，对硬件的索取完全不同：
- Prefill（读 prompt 生成首 token）：算力密集，吃 FLOPS；
- Decode（逐 token 吐出）：每生成 1 个 token 都要把全部权重读一遍——吞吐上限 ≈ HBM 带宽 ÷ 每字节权重的模型大小。H100 的 3.35 TB/s 量级带宽，跑 FP16 的 70B，理论上限就是每秒约 24 次全模型读取，batch 拉大靠的是 KV 并行摊薄。
- 所以量化从 FP16 → FP8/INT4，第一步收益是带宽（体积减半/四分之一），第二步才是算力释放。GPU 利用率打不满、decode 慢，多半是带宽不足不是算力不足。
三、几条"扩容"路线的真实边界
1. HBM 堆更多：单卡 80GB→192GB 级路线，容量解了，仍受功耗散热（每瓦带宽在进步但有限）；
2. CXL 内存池：适合 KV 卸载、多机共享，但延迟比 HBM 高一个量级，只能当"慢速 KV 层"，不能指望全放上去；
3. KV 量化（FP8/INT8 KV）与分组注意力（GQA/MLA）：模型结构侧省显存，目前性价比最高——MLA 把 KV 压缩一个数量级的路线已经被主流新架构采纳；
4. 多轮对话的前缀缓存：命中即省 Prefill；工程上按"会话路由+RadixAttention"做集群亲和；
5. 投机解码：用小模型打草稿大模型验算，本质是用多余的显存和算力换 decode 串行速度，带宽受限场景收益特别明显。
四、给平台/选型同学的一句话判断树
- QPS 优先、延迟宽松 → 堆 batch + KV 压缩 + INT8/FP8，容量优先选大显存单卡；
- 首字延迟优先（对话、Agent 工具链） → 投机解码 + 前缀缓存 + 亲和调度；
- 长文档/长上下文（32K+） → 显存先爆，先做滑动窗口/外部检索，再谈硬件。
大家在生产集群里 KV Cache 占显存的实际比例是多少？欢迎贴脱敏后的数字，这类"真实配比"比跑分有用得多。