上一期，我们揭秘了 PagedAttention 如同“智慧酒店”般的内存管理魔法。但理论归理论，当你手握一张 24GB 显卡，准备部署一个8B模型时，心里是不是还在打鼓：
“我的显存，到底够不够用？”
“我最多能支持多少并发？”
别慌！今天，我们就从理论走向实践。这份终极指南，将手把手教你如何像一名总建筑师一样，精确规划你的“AI停车场”，让你对每一MB的显存都了如指掌！
规划容量 vs. 实时占用
在开始计算之前，最关键的是理解 PagedAttention 带来的一个理念转变：
- 容量规划 (Capacity Planning)
我们计算显存是为了确保系统的稳定性。我们需要为理论上可能发生的**“最坏情况”**准备足够的资源。这决定了你需要购买多大的显卡，或者你的服务能承诺多高的上限。
- 实时占用 (Runtime Usage)
得益于 PagedAttention，系统在运行时极其高效，只会占用当前实际需要的显存。这使得在“最坏情况”的容量保障下，平均吞吐量得到巨大提升。
我们的评估，本质上是在做容量规划。
第一部分：拆解三大核心显存组件
在使用 PagedAttention 时，总显存需求由三个清晰的部分构成：
总预估显存 ≈ ① 模型权重显存 + ② 峰值 KV 缓存显存 + ③ 框架与开销显存
① 模型权重显存 (静态基础)
这是模型的“大脑”，一旦加载，就固定不变。
- 计算方法
权重显存 (GB) = 模型参数量 (Billion) × 单个参数的字节数
以 Qwen3-8B 为例
模型参数为 8.2B，默认使用 FP16/BF16 精度（2 字节）。
权重显存
= 8.2B × 2 Bytes/Param ≈ 16.4 GB
② 峰值 KV 缓存显存 (动态核心)
这是评估的重点。我们是在为**系统需要支撑的“峰值总词元（Token）负荷”**进行规划。
第一步：计算单个词元的“成本”
这个成本是固定的，由模型架构决定。
- 公式
每 Token 的 KV 缓存大小 = 2 × 层数 × KV 头数 × 单头维度 × 精度字节数
以 Qwen3-8B 为例 (使用 FP16 KV 缓存)
2 × 36 (层) × 8 (KV头) × 128 (维度) × 2 (字节)
= 147,456 Bytes ≈ 144 KB / Token
第二步：定义容量规划的“目标峰值”
你需要为你的服务设定一个明确的性能上限。
- 公式
峰值总词元数 = 最大并发数 × 最大服务序列长度 (注：最大服务序列长度 = 输入长度 + 输出长度)
这个公式计算的是理论上最极端的情况，即所有并发请求同时都达到了你设定的最大长度。
第三步：计算峰值 KV 缓存的总显存
- 公式
峰值 KV 缓存 (GB) = 峰值总词元数 × 每 Token 的 KV 缓存大小
实战演练：以 Qwen3-8B 为例
- 我们的目标
支持 8 个并发请求，且每个请求的最大服务序列长度为 4096。
计算目标峰值
峰值总词元数 = 8 (并发) × 4096 (长度) = 32,768 Tokens
计算峰值 KV 缓存
峰值 KV 缓存 = 32,768 Tokens × 144 KB/Token ≈ 4.5 GB
③ 框架与开销显存 (安全余量)
这部分是为 vLLM 框架自身、CUDA 工作区、激活值、块表（Block Tables）等预留的“缓冲带”。
- 估算方法
通常预留“权重显存 + 峰值 KV 缓存显存”总和的 5% 到 15%。10% 是一个合理的起点。
汇总与决策：一次完整的容量评估
现在，我们将三部分加起来，看看我们的目标是否可行。
- 目标
在 24GB 显卡上，部署 Qwen3-8B，支持 8 并发 × 4096 长度。
权重显存
16.4 GB
峰值 KV 缓存显存
4.5 GB
核心占用
16.4 GB + 4.5 GB = 20.9 GB
增加 10% 安全余量
20.9 GB × 1.1 ≈ 23.0 GB
结论: 我们的预估总需求为 23.0 GB，小于 24GB。因此，这个容量规划是完全可行的。我们有信心在 24GB 显卡上稳定地提供此项服务。
重要澄清：容量规划 vs. 运行时现实
实例：如果一个批次里请求长度不一（例如 1个4096，7个256），会发生什么，应该怎么配置GPU利用率？
容量规划 (理论计算): 我们必须按照
8 × 4096的最坏情况来准备资源。这就像游泳池的管理员，必须确保泳池的总容量能装下所有持票会员（最大并发数），以防他们某天同时都来了。泳池的总容量就是我们计算出的 23.0 GB。运行时现实 (PagedAttention 的魔法): 在那个具体的批次里，系统只会为
(1 × 4096) + (7 × 256) = 5888个词元分配显存。这就像在那个时刻，泳池里只有少数几个人在游泳，占用了很小一部分水域。泳池的绝大部分空间都是空闲的，可以立即容纳更多新来的游泳者。
PagedAttention 的伟大之处，就是让我们有能力建造一个足够大的“泳池”（规划容量），同时确保在任何时候，都只为实际在游泳的人提供“水”（实时占用），从而极大地提高了泳池的利用效率。
反向推算：从硬件出发，规划服务能力
这在实际工作中更为常见：我有一张 24GB 的卡，用它部署 Qwen3-8B，最多能提供什么样的服务？
计算“KV 缓存预算”: 首先，从总显存中减去固定开销。
KV 缓存预算 (GB) = (总显存 × 0.9) - 权重显存 (这里的 0.9 是一个安全系数，为框架开销预留 10%)
- KV 缓存预算 = (24 GB × 0.9) - 16.4 GB = 21.6 GB - 16.4 GB = 5.2 GB
计算“最大总词元数”容量: 看看这个预算能容纳多少个词元的 KV 缓存。
最大总词元数 = KV 缓存预算 / 每 Token 的 KV 缓存大小
- 最大总词元数 = 5.2 GB / (144 KB/Token) ≈ 37,700 Tokens
灵活组合服务配置: 现在，你可以用这 37,700 个词元的总容量来自由组合你的服务。例如，你可以提供以下任意一种配置：
- 高并发、短序列
16 并发 × ~2,300 长度
- 中等并发、中序列
8 并发 × ~4,700 长度
- 低并发、长序列
4 并发 × ~9,400 长度
- 极限长文本处理
1 并发 × ~37,700 长度
这个反向推算的过程，能让你基于现有硬件，做出最合理的商业和技术决策。