ModelVRAM
EN 中文

投机解码显存计算器（MTP 与草稿模型）

投机解码会给 llama.cpp 再加一个模型或预测头，而 llama.cpp 的自动适配并不总会把它算进去。选择主模型文件和草稿，就能看到精确的额外字节数：GPU 上的草稿权重、草稿上下文（始终与主上下文一样长）下的草稿 KV cache、混合架构模型额外保存的循环状态副本，以及草稿计算缓冲区的估算值。

– 投机解码额外显存

GPU 上的草稿 / MTP 权重
–
草稿上下文的 KV cache
–
主模型额外的循环状态副本
–
草稿模型自身的循环状态
–
草稿计算缓冲区（估算）
–
仅主模型（文件 + KV + 状态 + 1 GB 缓冲区）
–
开启投机解码
–
GPU 显存12 GB16 GB24 GB32 GB48 GB
仅主模型–––––
加上草稿–––––

“紧张”：只有按计算缓冲区估算的下限才装得下。权重、KV 和状态都是精确字节数；计算缓冲区取两份 Qwen3.8 27B MTP 日志给出的范围（126.77–272.28 MiB），再加上 CUDA flash attention 为量化草稿缓存保留的 F16 副本。“仅主模型”按整个文件和 1 GB 缓冲区计算，与本站其他页面一致。如果这块 GPU 还要驱动显示器，请再留出约 0.5–1 GB。

GB 即 GiB（1024³ 字节），MB 即 MiB；日志数值按 llama.cpp 输出原样显示。

llama-server 命令

所有草稿对比

使用各模型的 Q4_K_M 文件、f16 缓存、单个 slot、--spec-draft-n-max 3。额外 = 权重 + 草稿 KV + 循环状态副本 + 计算缓冲区估算。“-fit 计入”：llama.cpp 的自动适配是否把草稿算进去。

草稿--spec-type文件大小GPU 上 草稿 KV，32K草稿 KV，128K额外，32K额外，128K-fit 计入
模型文件内的 MTP 层 Qwen3.8 27B draft-mtp – 335 MB 128 MB 512 MB 1.01 GB–1.16 GB 1.39 GB–1.53 GB 是
Unsloth MTP 文件（mtp-Qwen3.8-27B-Q4_0） Qwen3.8 27B draft-mtp 1.28 GB 1.08 GB 128 MB 512 MB 1.77 GB–1.91 GB 2.15 GB–2.29 GB 是
DFlash2 Q4_K_M (z-lab) Qwen3.8 27B draft-dflash 1.06 GB 1.05 GB 50.0 MB 50.0 MB 1.67 GB–1.81 GB 1.67 GB–1.81 GB 否
DFlash2 Q8_0 (z-lab) Qwen3.8 27B draft-dflash 1.92 GB 1.90 GB 50.0 MB 50.0 MB 2.52 GB–2.66 GB 2.52 GB–2.66 GB 否
DFlash2 BF16 (z-lab) Qwen3.8 27B draft-dflash 3.60 GB 3.58 GB 50.0 MB 50.0 MB 4.20 GB–4.34 GB 4.20 GB–4.34 GB 否
Qwen3.5 0.8B Q4_K_M Qwen3.8 27B draft-simple 508 MB 497 MB 384 MB 1.50 GB 1.00 GB–1.15 GB 2.13 GB–2.27 GB 是
Qwen3.5 0.8B Q8_0 Qwen3.8 27B draft-simple 774 MB 764 MB 384 MB 1.50 GB 1.26 GB–1.41 GB 2.39 GB–2.53 GB 是
Qwen3.5 2B Q4_K_M Qwen3.8 27B draft-simple 1.19 GB 1.18 GB 384 MB 1.50 GB 1.70 GB–1.84 GB 2.83 GB–2.97 GB 是
Qwen3.5 2B Q8_0 Qwen3.8 27B draft-simple 1.87 GB 1.86 GB 384 MB 1.50 GB 2.38 GB–2.52 GB 3.51 GB–3.65 GB 是
Unsloth MTP assistant Q8_0 Gemma 4 31B draft-mtp 491 MB 476 MB 0 0 603 MB–748 MB 603 MB–748 MB 否
Unsloth MTP assistant F16 Gemma 4 31B draft-mtp 911 MB 896 MB 0 0 1.00 GB–1.14 GB 1.00 GB–1.14 GB 否
DFlash Q4_K_M (Anbeeld) Gemma 4 31B draft-dflash 870 MB 855 MB 168 MB 552 MB 1.12 GB–1.27 GB 1.50 GB–1.64 GB 否
DFlash Q8_0 (Anbeeld) Gemma 4 31B draft-dflash 1.53 GB 1.52 GB 168 MB 552 MB 1.81 GB–1.95 GB 2.18 GB–2.33 GB 否

相关的 llama.cpp 参数

读自 llama.cpp master 的 common/arg.cpp 和 common/common.h，提交 4364bf7（2026-09-28）。

--spec-type
draft-mtp（内置 MTP 层、Qwen MTP 文件或 Gemma 4 assistant）、draft-dflash、draft-dspark、draft-eagle3、draft-simple（小模型），以及不需要模型的 n-gram 类型。给了 -md 却没写 --spec-type 时，llama.cpp 会从草稿文件读取类型。
--spec-draft-n-max / --spec-draft-n-min
每步最多和最少草稿 token 数，默认 3 和 0。在混合架构模型（Qwen3.8）上，每多一个草稿 token 就多保存一份循环状态：Qwen3.8 27B 每份 150 MB。
-md, --spec-draft-model
草稿、MTP 或 DFlash 文件。模型文件内置的 MTP 层不需要它。
-ngld, --spec-draft-ngl
放到 GPU 上的草稿层数：数字、auto（默认）或 all。
-ctkd / -ctvd
草稿 KV cache 类型，默认 f16。-ctk / -ctv 对草稿不起作用。
-devd, --spec-draft-device
草稿放在哪些设备上，例如第二块 GPU；none 表示留在 CPU。

没有设置草稿上下文长度的参数：草稿上下文总是与主上下文（-c）容纳同样多的 token。-Cd 是草稿的 CPU 掩码，不是上下文长度。

公式能复现的 llama.cpp 日志

日志内容日志数值来源
循环状态，不开投机解码（Qwen3.8 27B，1 个 slot） 149.62 MiB #27814 2026-08-27
循环状态，MTP --spec-draft-n-max 3（Qwen3.6 27B，结构相同） 598.50 MiB #28112 2026-08-31
循环状态，MTP --spec-draft-n-max 4（Qwen3.6 27B） 748.12 MiB #23577 2026-05-23
MTP 草稿 KV cache，4 × 131,072 token，-ctk q8_0（草稿仍为 f16） 2,048.00 MiB #28115 2026-08-31
MTP 草稿计算缓冲区，-c 64000，f16 草稿缓存 126.77 MiB #28378 2026-09-04
同上，加 -ctkd q8_0 -ctvd q8_0 374.03 MiB #28378 2026-09-04
MTP 草稿计算缓冲区申请量，-c 196608，q4_0 草稿缓存（显存不足） 1,040.28 MiB #27282 2026-08-17

文件大小和张量字节数读自 GGUF 文件头和 Hugging Face API，日期 ： unsloth/Qwen3.8-27B-GGUF、ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF、unsloth/gemma-4-31B-it-GGUF、z-lab/Qwen3.8-27B-DFlash2-GGUF、unsloth/Qwen3.5-0.8B-GGUF、unsloth/Qwen3.5-2B-GGUF、Anbeeld/gemma-4-31B-it-DFlash-GGUF。 想看任意上下文下仅模型本身的显存，请用 LLM 显存计算器；Qwen3.8 27B 在 8–16 GB 显卡上的文件选择，见 Ternary Bonsai 2、GSQ-RCO 与 UD 量化对比。

使用方法

  1. 选择主模型文件。Unsloth 的 Qwen3.8 27B 文件自带 MTP 层；GSQ-RCO IQ3_XXS 文件没有。
  2. 选择草稿：内置 MTP 层、单独的 MTP 文件、DFlash 草稿模型或小的 Qwen3.5 模型；Gemma 4 31B 可选 Unsloth 的 MTP assistant 或 DFlash 草稿模型。
  3. 按你运行 llama-server 的方式设置上下文长度、主模型和草稿的 KV cache 类型以及 --spec-draft-n-max。
  4. 查看额外显存、12–48 GB 显卡上加草稿前后的总量，并复制 llama-server 命令。

常见问题

Qwen3.8 27B 开启 MTP 要多占多少显存？

UD-Q4_K_M、64K 上下文、f16 缓存、默认 --spec-draft-n-max 3 时：MTP 层 335 MB，它的 KV cache 256 MB，再多 3 份循环状态副本 449 MB，计算缓冲区约 127–272 MB，合计 1.14–1.28 GB。256K 时草稿缓存增至 1.00 GB，合计 1.89–2.03 GB。

文件里的 MTP 层在不开 MTP 时占显存吗？

不占。除非设置 --spec-type draft-mtp，llama.cpp 会以 TENSOR_SKIP 创建 blk.64 张量，所以带这一层的文件只是多下载 335 MB（Q8_0 为 430 MB），不多占显存；加载日志会把它们列为未使用。Hugging Face 上 Swift-1.5 的一个讨论里，一位使用 DFlash2 草稿模型的用户发现显存多了约 1 GB，怀疑是 MTP 层；1 GB 正是草稿模型本身的大小（DFlash2 Q4_K_M 在 GPU 上占 1.05 GB），而 MTP 层只有 335 MB。

DFlash2 和 MTP 哪个更占显存？

DFlash2 Q4_K_M 的权重更大（1.05 GB，MTP 为 335 MB），但缓存很小：它的五层都用 2,048 token 的滑动窗口，只保留 2,560 个单元，任何上下文下 f16 都是 50 MB。MTP 的缓存随上下文增长：64K 时 256 MB，256K 时 1.00 GB。两者额外保存的循环状态副本相同（每个草稿 token 150 MB）。64K 时 DFlash2 Q4_K_M 额外 1.67–1.81 GB，MTP 1.14–1.28 GB；256K 时分别为 1.67–1.81 GB 和 1.89–2.03 GB。

为什么 Gemma 4 31B 加上 MTP 草稿就爆显存，不加却正常？

在 llama.cpp issue #29521（Gemma 4 31B 搭配 --model-draft mtp-gemma-4-31B-it-F16.gguf）中，common/fit.cpp 输出 "failed to measure the memory of the extra model, fitting without it"：assistant 必须借助主上下文才能创建，所以适配器把它算作 0，并用上下文填满显存。草稿上下文的 n_ctx 总是和主上下文相同。请自己为草稿留出显存：F16 assistant 在 GPU 上占 896 MB（Q8_0 为 476 MB），另加约 127–272 MB 计算缓冲区；它读取主模型的 KV cache，不另外占缓存。请自己设置 -c 和 -np 1，或把 --fit-target 调高约 1.2 GB。

有设置草稿上下文长度的参数吗？

llama.cpp master（提交 4364bf7，2026-09-28）上没有：common/speculative.cpp 把草稿 n_ctx 设为主上下文的值，所以草稿缓存总是覆盖完整的 -c。-Cd 是草稿的 CPU 掩码。实际存在的参数是 --spec-type、--spec-draft-n-max、--spec-draft-n-min、-md、-ngld、-ctkd、-ctvd 和 -devd。

-ctk q8_0 会同时压缩草稿缓存吗？

不会。草稿缓存有自己的类型参数 -ctkd 和 -ctvd，默认 f16（issue #28115 的日志里，q8_0 主缓存旁边是 2,048 MiB 的 f16 MTP 缓存）。在 CUDA 上量化它反而可能更占显存：flash attention 会在计算缓冲区里保留一份 F16 副本，PR #28378 中 -c 64000 时计算缓冲区从 126.77 MiB 增至 374.03 MiB，比缓存省下的还多。

这里的 GB 指 GB 还是 GiB？

指 GiB，MB 指 MiB，与 llama.cpp 和 nvidia-smi 输出的单位一致，全站都是如此。

更多计算器

更新于