# SGLang 开 MTP 后 KV 池被砍到 1/5：一个上游 bug 的完整定位与修复，附同机四方实测总表

[Enigma]

上一篇我还在说"SGLang 开 MTP 只能跑 32K 上下文，因为它在显存分配上留了 8GB 结构性预留"。

那个结论是错的。 后来插了几行日志一查，真相是 SGLang 把 MTP 的层数识别成了 64（实际只有 1 层），导致每 token 的 KV 成本被高估 5 倍，KV 池被砍到 1/5 —— 不是"显存不够"，是"算错了"。

修好之后，单路 128K + MTP 直接跑通（池子 44913 → 211357 token）。这篇把定位过程、修复、前后实测和更新后的四方总表一次写完。

1. 先给三张结论表

1.1 修复前后（单变量 A/B：只切换补丁）

指标	修复前	修复后	变化
cell_size	163840 B/token	32768 B/token	÷5
KV 池 token	44913	211357	×4.71
单条输入上限	45417 token	~211000 token	×4.65
127K 单路请求	被拒（HTTP 400）	成功	—
短上下文 code	86.1 t/s	86.1 t/s	0
短上下文 抽取	85.9 t/s	85.9 t/s	0
短上下文 创作	59.8 t/s	59.8 t/s	0
双流聚合	170.1 t/s	171.8 t/s	+1%
运行显存	26182 MiB（余 6016）	30626 MiB（余 1572）	预算用满

1.2 MTP 到底值多少（同权重同参数，只切投机）

场景	无 MTP	MTP	增益
短上下文 code	41.5 t/s	86.1 t/s	+107%
短上下文 抽取原文	40.5 t/s	85.9 t/s	+112%
短上下文 中文创作	41.5 t/s	59.8 t/s	+44%
双流聚合	82.9 t/s	171.8 t/s	+107%
128K 单路 decode	34.4 t/s	31.5 t/s（另一次 37.8）	−8% ~ +10%，基本持平
接受长度	—	短上下文 2.5-3.7 / 128K 仅 1.68	—

MTP 的价值全在短/中上下文；128K 下接受长度塌到 1.6-2.0，验证开销把收益吃光 —— 长上下文别指望 MTP。

1.3 更新后的四方总表

项目	① llama.cpp<br>Q6_K+MTP	② llama.cpp<br>unsloth Q4_K_M+MTP	③ SGLang<br>INT4 无投机	④ SGLang<br>INT4+NEXTN
权重	20.89 GB	15.33 GB	17.7 GB	17.7 GB
code 解码	80.9 t/s	101.2（nmax4）	41.5 t/s	86.1 t/s
tool 解码	81.8 t/s	91.1（nmax4）	40.5 t/s	85.9 t/s
prose 解码	52.9 t/s	59.7（nmax3）	41.5 t/s	59.8 t/s
双路总吞吐	95-160	161.4	82.9 t/s	171.8 t/s
可用上下文	128K × 2	256K × 2	128K	128K（单路，修复前只有 45K）
显存	28.4 GB（含视觉）	27.6 GB	30.4 GB	26.2-30.6 GB
MTP 接受率	未记录	tool 87-100% / code 87-89%	—	0.87-0.94 / 0.90 / 0.50（128K 时 0.42）

口径提醒：①② 是 Windows 11 + -c 262144/131072、temp 0.7；③④ 是 Ubuntu + fp8 KV、贪婪解码。④ 的双路吞吐 171.8 是在 32K 上下文下测的，② 的 161.4 是在 256K 下测的，论"每单位上下文的速度"② 更强。

2. 现象：MTP 一开，KV 池从 28 万掉到 4.5 万

模型是 RedHatAI/Qwen3.8-27B-INT4（17.7 GB，自带 model_mtp.safetensors），同一个启动命令只差投机开关：

运行	KV 池	128K 请求
不开投机	279214	能跑
开 NEXTN	44913	Input length (125837 tokens) exceeds the maximum allowed length (60967 tokens)

3. 排查：先以为显存不够，后来发现是算错

第一反应当然是"显存被 MTP 吃掉了"，于是把所有能想到的旋钮都试了一遍：

尝试	KV 池	结论
基线 mf 0.92	44913	—
mf 0.97	55228	涨得很少
mf 0.99	59150	还是很少
mf 0.97 + 并发降到 1 + prefill 压到 2048 + hicache 缩到 4	60973（上限）	到顶了
--max-total-tokens 262144 强制指定	55228	参数被忽略
关 CUDA graph	不变	无关
投机步数从 3 降到 1	+2.9K	无关

参数调到天亮都没用。直到我注意到一个矛盾：

Memory pool end. avail mem=7.90 GB      ← 分配完还剩 7.9GB 空闲
KV Cache is allocated. #tokens: 44913   ← 却只给了 1.37GB

显存明明够，它却不用。 那就不是"不够"，是"算错"。

于是往 sizing 代码里插了几行日志（_profile_available_bytes 和 _compute_cell_size），一次就露馅了：

[KV_SIZING] avail=11.359GB slack=2.387GB rest_after_mamba=6.853GB pre_load=29.837GB
            reserve_mb=3712 mf=0.92 post_capture=False
→ 交给池子的预算是 6.85GB，却只分配了 1.37GB

[KV_CELL_DEBUG]  cell_size=32768B (32.0KiB/token) num_layers_arg=16
                 mambaish=True full_attn=16 spec=SpeculativeAlgorithm.EAGLE
                 eagle_draft_layers=64                      ← 这里！
[KV_CELL_DEBUG2] EAGLE 缩放生效: eagle_draft_layers=64 num_layers=16
                 -> cell_size=163840B                       ← 每 token 成本被放大 5 倍

顺带还排除了一个我原本以为的元凶：日志里 post_capture=False，说明那个"混合 mamba 模型的 pre_capture 激活预留"（3712 MB）根本没生效，跟这事无关。

4. 根因：MTP 层数识别错误，×5 的缩放

两处代码组合出来的。

第一处，spec_aux_hidden_state.py 里推导 draft 层数：

num_nextn_predict_layers = draft_model_config.num_nextn_predict_layers
if num_nextn_predict_layers is not None:
    config.eagle_draft_num_layers = int(num_nextn_predict_layers)
else:
    config.eagle_draft_num_layers = int(max(
        draft_model_config.num_hidden_layers,      # ← 拿到 64
        draft_model_config.num_attention_layers,
    ))

Qwen3.5/3.8 的 MTP 层数写在 text_config.mtp_num_hidden_layers 里（=1），不是 DeepSeek/GLM 用的 num_nextn_predict_layers。字段认不出来就走了 fallback，而 --speculative-draft-model-path 指向的正是模型自己的目录 —— 于是这个"draft 模型配置"读到的就是整模型的 64 层。

（证据：model_mtp.safetensors 里只有 mtp.layers.0.*，就一层。）

第二处，pool_configurator.py 拿这个数字去缩放每 token 成本：

# EAGLE/STANDALONE: scale cell_size to account for draft model KV cache
self._cell_size = int(
    self._cell_size * (1 + int(eagle_draft_num_layers) / int(num_layers))
)

而混合注意力模型（48 层 GDN + 16 层全注意力）里 num_layers 取的是真正带 KV 的层数 = 16，于是缩放系数变成：

1 + 64 / 16 = 5

每 token 成本高估 5 倍，KV 池就被砍到 1/5。

5. 修法：一处改动

最地道的改法不是去改那个 fallback（那只修了一处），而是在 ModelConfig 里就把字段补齐 —— 所有依赖 num_nextn_predict_layers 的地方都自动受益：

# sglang/srt/configs/model_config.py
         self.num_nextn_predict_layers = getattr(
             self.hf_text_config, "num_nextn_predict_layers", None
         )
+        if self.num_nextn_predict_layers is None:
+            # Qwen3.5/3.8 name the MTP depth `mtp_num_hidden_layers`
+            self.num_nextn_predict_layers = getattr(
+                self.hf_text_config, "mtp_num_hidden_layers", None
+            )

验证（只改这一处，把之前打在 fallback 上的补丁撤销）：

mem-fraction	修复前	只改 ModelConfig 后
0.92	44913	211355
0.97	59150	257367

mf 0.97 时池子 257367 token，双路 128K（需要 262144）已经接近可行。

6. 修复前后实测：单变量 A/B

方法：只切换这一个补丁，vocab 占位补丁两边都开，其他启动参数逐字符相同。

公共参数：

--model-path <Qwen3.8-27B-INT4> --language-only \
--context-length 131072 --max-running-requests 2 --mem-fraction-static 0.92 \
--kv-cache-dtype fp8_e4m3 --page-size 1 \
--max-mamba-cache-size 16 --mamba-ssm-dtype bfloat16 \
--enable-hierarchical-cache --hicache-size 12 --hicache-write-policy write_through \
--speculative-algorithm NEXTN --speculative-draft-model-path <同目录> \
--speculative-eagle-topk 1 --speculative-num-steps 3 --speculative-num-draft-tokens 4

127K 单路请求（本轮唯一真实差异）

	修复前	修复后
结果	HTTP 400：exceeds the maximum allowed length (45417 tokens)	成功
prompt	—	128180 token
prefill	—	112.9 s（1136 tok/s）
解码 @128K	—	31.5 t/s（接受长度 1.68）

短上下文 decode：两边逐位相同（对照组）

修复前:  code 86.1 t/s accept 3.56 | echo 85.9 accept 3.66 | prose 59.8 accept 2.51
        双流聚合 90.9 + 79.2 = 170.1 t/s
修复后:  code 86.1 t/s accept 3.56 | echo 85.9 accept 3.66 | prose 59.8 accept 2.51
        双流聚合 90.9 + 80.9 = 171.8 t/s

逐位相同是预期结果：那个字段只被 KV 池尺寸估算消费，不参与任何 kernel、attention 或采样逻辑。这也正好反证了补丁是纯内存修复 —— 如果有人报告"打了补丁速度变了"，那一定是别的原因。

顺带一修的另一个浪费：draft 的 vocab 层（2.4 GiB）

MTP draft 在 __init__ 里会建自己的 embed_tokens 和 lm_head（各 248320×5120×2 byte ≈ 2.5 GB），但运行时 set_embed_and_head() 会把它们 del 掉、换成目标模型的张量引用 —— 而 KV 池是在这之前就按"draft 还占着 5.53GB"算好尺寸的，之后释放的显存就白空着。

用"0 尺寸占位"规避（上游对应 PR #37155 把这步释放提前了）：

draft 加载显存:  5.53 GB → 0.79 GB
KV 池:          14161 → 45423 token

两个修复加起来：池子 14161 → 45423（vocab 层）→ 211357（层数），总共 ×14.9。

7. MTP 参数怎么扫（同 llama.cpp 扫 n-max 的规律）

steps/draft	code	抽取	创作	接受率（code/抽取/创作）
1/2	62.0	60.5	54.6	0.97 / 0.95 / 0.74
2/3	73.5	77.8	60.9	0.87 / 0.98 / 0.64
3/4	86-89	86	59.8	0.87-0.94 / 0.90 / 0.50
5/6	108.7	—（显存不足）	59.6	0.91 / — / 0.42

规律和 llama.cpp 完全一致：steps 越大，可预测任务（代码/工具）越快，创作类接受率反而下降。而且上下文越长接受长度越低：短上下文 3.76，128K 时只有 1.68。

8. 三方/四方横评（更新后）

项目	① llama.cpp Q6_K+MTP	② llama.cpp Q4_K_M+MTP	③ SGLang INT4 无投机	④ SGLang INT4+NEXTN
系统	Windows 11	Windows 11	Ubuntu	Ubuntu
权重	20.89 GB	15.33 GB	17.7 GB	17.7 GB
code	80.9	101.2	41.5	86.1
tool	81.8	91.1	40.5	85.9
prose	52.9	59.7	41.5	59.8
双路聚合	95-160	161.4	82.9	171.8
上下文	128K×2	256K×2	128K	128K 单路（修复前 45K）
显存	28.4 GB 含视觉	27.6 GB	30.4 GB	26.2-30.6 GB
prefill	未测	报告未列	1680-1915 tok/s	~1775 tok/s

结论：

1. llama.cpp + Q4_K_M + MTP 仍是"最快 + 最长上下文"的综合最优（256K×2 还能 161 t/s），它的 KV 池是按实际使用分配；
2. SGLang + MTP 修好之后，解码反超 llama.cpp（+6%~13%），双流聚合最高，而且单路 128K 保住了；
3. SGLang 无投机的唯一优势是 prefill（1680-1915 tok/s，123K 时还有 1199）和 HiCache 前缀复用（17.9K 前缀 10.2s → 1.25s）；
4. 两者取舍的核心差异从"显存分配策略"变成了"MTP 在长上下文下收益趋零"这个共同的物理限制。

9. 给同是小白的提醒

1. 池子异常小的时候，先怀疑"算错"而不是"不够"。判据很简单：分配完成后还剩多少显存。像这次分完还剩 7.9GB，就说明预算没被用满，参数调到天亮都没用。
2. 定位靠日志，别靠猜：在 sizing 路径（_profile_available_bytes、_compute_cell_size）插几行 print，把中间值打出来，一次就能看到 cell_size 被放大了 5 倍。改完记得把调试补丁撤掉（env 变量门控更安全）。
3. 换带 MTP 的权重先确认两件事：它带 model_mtp.safetensors；model.safetensors.index.json 里引用了它。
4. Xet 存储的仓库必须 HF_HUB_DISABLE_XET=1，否则 hf-mirror 等于没用，还会 401。
5. max_running_requests is capped to 1 这条日志一定要看：混合 mamba 模型 + 投机下每请求要 5 个 mamba 槽，槽不够就变排队（我实测 2×64K 墙钟 84.4s ≈ 2×42s，是串行不是并行）。
6. --max-mamba-cache-size 别乱调大：bf16 + 16 槽 下跑 2×60K 长并发，两个请求都能完成但随后 AssertionError: Can not alloc mamba cache（mamba_component.py:479）→ SIGQUIT → 整个服务退出。长上下文档建议用 --max-mamba-cache-size 6（默认 float32）。
7. 投机参数要自己扫，而且别忘了它只在短上下文值钱：短上下文 +107%，128K 下 −8%~+10%（基本白干）。

10. 还没解决的

• 双路长并发的 mamba 槽位断言崩溃（见提醒 6），要么等上游修，要么避开 bf16 + 大槽位组合。
• 128K 下 MTP 收益趋零：接受长度塌到 1.68，属于投机解码在长上下文下的通用问题，不是这个 bug 带来的。
• SGLang 的 L3 磁盘层只写不读（混合模型上从不触发预取），三级缓存实际只能用两级。

---

上游已按第 5 节的方案提交了 issue 和最小复现脚本（repro_mtp_draft_layers.py：Part 1 不需要 GPU，只读 config.json 和权重就能证明误判；Part 2 起两次服务对比池子）。这个 bug 对所有用 mtp_num_hidden_layers 的 Qwen3.5/3.8 混合模型都成立，池子会被砍 1 + 总层数/带KV层数 倍；就算是全注意力模型（每层都带 KV）也会被砍 2 倍。

感谢论坛里讨论投机解码和显存分配的各位，这次少走了很多弯路。

[Xiaote]

这个 ×5 的定位很漂亮，我这边有一段要跟着改口：我在隔壁 1622 说过「SGLang 侧因 MTP 预留只剩 ~45K」，用的就是「8GB 结构性预留」那个说法——来源是你上一篇的结论，现在被你自己推翻了，那句撤回，改记成这一版：不是预留，是 sizing 把 draft 层数从 1 算成了 64。

借这个案例固化三条，以后再遇到同类（不报错但某个数字差整数倍）能少走夜路：

1. 派生量要和真值对账，别只跟参数对账

你试的那一圈旋钮（mf、并发、hicache、--max-total-tokens、关 CUDA graph）全是「喂给推导公式的输入」，公式本身错了，输入怎么调都没用。真正的破局点其实不是日志，是那两行自相矛盾的数字：

• avail mem = 7.90 GB
• 却只分配了 1.37 GB

凡是「资源够但不用」，优先怀疑「算错」而不是「不够」。

2. 唯一真值在权重文件的 header 里

config 是元数据，可以缺字段——你这份就是 num_nextn_predict_layers 为 None 才走的 fallback；safetensors 的 header 才是事实。所以拿到任何带 draft/MTP 的第三方包，先读 header 把 draft 那一块的层数数出来，跟日志里的 eagle_draft_layers 对一次，两者不等就先别看性能数字：

import json, struct
with open('model_mtp.safetensors', 'rb') as f:
    n = struct.unpack('<Q', f.read(8))[0]
    hdr = json.loads(f.read(n))
print(len(hdr), list(hdr)[:5])

（层号前缀按你这份权重的实际命名取，要紧的是「数出来的层数」，不是「config 声称的层数」。）

3. 修复优先走配置，不走 patch

你的 traceback 已经把答案给出来了：第一分支读的是 draft_model_config.num_nextn_predict_layers，只有它是 None 才 fallback 到 num_hidden_layers。所以在模型目录的 config.json 里显式写上这个字段（值 = header 里数出来的真实 MTP 层数），比打上游 patch 稳：SGLang 换 wheel 不会把你打回原形，也不用维护 diff。上游那个 fallback 值得顺手提个 issue——拿 num_hidden_layers 当 draft 层数在结构上就不成立，这类单层 MTP head 永远不是 N 层。

一个可以顺手验的预测：修好后 32768 B/token ÷ 16 层 ÷ 2(KV) = 1024 B/层/token，正好是 fp8 下 kv_heads × head_dim = 1024 的布局。如果你哪天为了精度把 KV 换成 bf16，池子会再掉一半回到 10 万 token 出头——「128K 单路 + MTP」就又放不下了。也就是说这份配置的可跑性是被 fp8 KV 撑起来的，换精度前先把这条账算清。

最后，你 1.2 表里那条结论我认为是整帖最值钱的部分：128K 下接受长度塌到 1.68、decode 31.5 对无 MTP 的 34.4——说明长上下文里 MTP 的收益会被验证开销吃光。长上下文的显存应该给 KV 池，不是给 draft 权重。 这条和引擎无关，llama.cpp 那边也是同一个方向，比「SGLang 行不行」有用得多。