LLM 内存预算交互计算器：把 KV 缓存估算从玄学变算式 · 干货攻略

  • 链接: https://x.com/rasbt/status/2096655320172962176
  • 分类: x-tips
  • 来源: X @rasbt
  • 作者: Jay
  • 更新: 2026-09-10

这是什么

Sebastian Raschka（@rasbt）在 X 上分享的 LLM Memory Calculator，是一个基于 his LLM Architecture Gallery 构建的在线交互计算器。

它的核心价值在于：把 LLM 推理时的内存估算拆成两个互不相关的部分——模型权重内存和 KV Cache 增长——让你可以独立调节上下文长度或批量大小，观察其中一项的变化，而不会被另一项干扰。

调参界面可以选择模型（Qwen3 0.6B、Llama 3 8B、DeepSeek V3 等数十个主流开源模型）、上下文长度、批量大小、权重精度（FP16 / INT8 / INT4 等）和 KV Cache 精度。实时显示两个数字：Weights（固定值）和 KV Cache（随上下文增长的值）。

为什么值得关注

做本地推理或长上下文应用的人，经常遇到一个经典问题："7B 模型 8GB 显存能跑多少 token？"

这个问题之所以难回答，不是因为没有公式，而是因为大家经常把权重内存和 KV Cache 内存混为一谈——或者干脆靠经验猜测。

Raschka 这个计算器解决的是这个认知问题：

  1. 权重内存只和参数量、精度有关，和上下文长度无关。7B 模型 FP16 就是约 14 GiB，放到显存里就不变了。
  2. KV Cache 内存只和上下文长度、批量大小、KV Head 配置有关，和总参数量没有直接关系。GQA/MQA 模型因为 KV Head 比 Query Head 少，KV Cache 反而更小。

这意味着：同样是 7B 量级，Llama 3 8B（128 KiB/token）的 KV Cache 负担只有 OLMo 2 7B（512 KiB/token）的四分之一——参数量相近，但 KV Head 数量决定了"能跑多长"。

核验过程

官方来源

主来源：Sebastian Raschka 官方博客页面 - https://sebastianraschka.com/llm-architecture-gallery/memory-calculator/ - https://sebastianraschka.com/llm-architecture-gallery/kv-cache-calculations/

从官方页面确认的公式如下：

权重内存：

Weight bytes = 参数总量 × 权重位数 ÷ 8

KV Cache（GQA/MHA 通用）：

KV-cache bytes = 2 × Num_Layers × Num_KV_Heads × Head_Dim × 上下文长度 × 批量大小 × 每元素字节数

对于 MLA（DeepSeek V3 等）则是：

bytes_per_layer = (kv_lora_rank + qk_rope_head_dim) × 2
bytes_per_model_per_token = Num_MLA_Layers × (kv_lora_rank + qk_rope_head_dim) × 2

官方给出的具体例子（均 BF16，batch=1）： - Qwen3 8B：144 KiB/token；32,768 tokens 时 KV Cache 约 4.5 GiB，权重约 14.90 GiB - Llama 3 8B：128 KiB/token - OLMo 2 7B（MHA）：512 KiB/token（"Very high" 级别） - DeepSeek V3（MLA）：68.6 KiB/token（"Low" 级别） - Gemma 3 27B（混合滑动窗口）：496 KiB/token（"Very high"）

关于滑动窗口注意力的说明（来自官方）：滑动窗口的每 token 代价与基础 MHA/GQA/MQA 相同，但它改变了 token 的存活时长；跨层 KV 共享则减少了产生 cache 的层数。两者是不同方向的优化。

交叉验证

通过第三方来源交叉验证关键数字：

来源 关键说法 交叉结论
Spheron Blog（2026） LLaMA-7B FP16 约 14 GB，KV Cache 加 15-20% overhead ✅ 与官方 Qwen3 8B ≈14.90 GiB 权重数一致
Michael Brenndoerfer Llama 7B MHA：4,096 tokens × 4,096 hidden_dim × 2 layers × 2 bytes = 2 GB KV Cache ✅ 512 KiB/token × 4096 ≈ 2 GB，匹配
Lyceum Technology（2026-08 更新） Llama-3-70B GQA 80 layers × 8 KV heads × 128 head_dim：batch=8 时 10 GiB KV Cache ✅ 验证 GQA 公式，KV Head 远小于 Query Head 时优势明显

结论：Raschka 官方公式和第三方计算结果高度吻合，所有关键数字（144 KiB/token Qwen3 8B、128 KiB/token Llama 3 8B、68.6 KiB/token DeepSeek V3）均来自官方来源，可信度高。

上手步骤

直接使用在线计算器

  1. 打开：https://sebastianraschka.com/llm-architecture-gallery/memory-calculator/
  2. 选择目标模型（如 Qwen3 8B）
  3. 调节上下文长度（Tokens）和批量大小（Batch）
  4. 读取 Weights（GiB）和 KV Cache（GiB）两个数字

计算器支持 URL 参数分享结果，例如：

https://sebastianraschka.com/llm-architecture-gallery/memory-calculator/?model=qwen3-0-6b&tokens=8192&batch=1&weight=16&kv=16

用公式手动计算（以 Llama 3 8B 为例）

Llama 3 8B 配置：32 GQA layers，8 KV heads，head_dim = 128，batch=1，seq=8192，BF16

# 权重内存
params = 8e9          # 8B 参数
weight_bits = 16      # BF16
weight_bytes = params * weight_bits / 8  # = 16 GiB

# KV Cache 内存（每 token）
bytes_per_layer = 2 * 8 * 128 * 2   # 2 tensors × 8 KV heads × 128 head_dim × 2 bytes
bytes_per_token = 32 * bytes_per_layer  # 32 layers
# = 131,072 bytes/token = 128 KiB/token

# 完整上下文
total_kv_cache = bytes_per_token * 8192  # = 1,073,741,824 bytes ≈ 1 GiB

按 GPU 显存估算最大上下文

以 RTX 4060（8 GiB）跑 Llama 3 8B FP16 为例：

total_vram = 8  # GiB
weight_memory = 16  # GiB
available_for_kv = total_vram - weight_memory  # ≈ 0 GiB (实际还需留系统 overhead)

# 结论：8GB 显存跑 FP16 8B 模型基本没有 KV Cache 空间
# 需要 INT4 量化：weight ≈ 4.2 GiB，剩余 ≈ 3.8 GiB → 可跑约 8192 token

坑与适用边界

1. 计算器是"逻辑估计"，不含运行时开销 官方页面明确指出：结果不包括 activations（激活值）、prefill workspace、分配器预留、其他 serving 缓冲区。实际 OOM 可能在"逻辑估计"远未满时发生。

2. 滑动窗口/循环模型用了"全量保留"假设 计算器对 Sliding Window Attention 模型（如 Gemma 3）默认假设每个 token 都保留在 cache 中，不反映真实 sliding window 的驱逐行为。

3. MoE 模型的"活跃参数"不减少权重内存 权重内存计算的是所有参数（包括不活跃的专家），活跃参数 per token 只影响计算量，不影响显存占用。DeepSeek V3 671B 总参数虽然极大，但 37B 活跃参数的权重依然全部驻留显存。

4. 量化精度对权重内存影响大，但 KV Cache 通常仍用 BF16 当前大多数量化方案（INT4 GPTQ/AWQ）主要针对权重；KV Cache 仍以 BF16 存储意味着它不会随权重量化同比例缩小。

5. 批量大小直接乘 KV Cache batch=8 时 KV Cache 是 batch=1 的 8 倍（无共享前缀假设下）。多用户并发场景务必单独计算每个用户的 KV Cache 需求。

一句话结论

Raschka 的 LLM Memory Calculator 让你把"权重内存"和"KV Cache 增长"分开计算，从而精确回答"我的 GPU 能跑多长上下文"——关键是 KV Head 数量而非参数量，才是决定长度的关键变量。

工具地址：https://sebastianraschka.com/llm-architecture-gallery/memory-calculator/ 配套公式详解：https://sebastianraschka.com/llm-architecture-gallery/kv-cache-calculations/