结论先说：综合最强的是 llama.cpp + unsloth UD-Q4_K_M + MTP —— 它在 256K 上下文双路并发下还能跑 161 t/s，单路代码破 100 t/s，这是 SGLang 这套做不到的（我们的 MTP 只能跑 32K）。

1. 四方总表

项目	① llama.cpp<br>Q6_K + MTP	② llama.cpp<br>unsloth Q4_K_M + MTP	③ SGLang<br>INT4 无投机	④ SGLang<br>INT4 + NEXTN
系统	Windows 11	Windows 11	Ubuntu	Ubuntu
引擎	llama.cpp b10549	llama.cpp b10549	SGLang 0.5.17	SGLang 0.5.17
权重	Q6_K 20.89 GB	UD-Q4_K_M 15.33 GB	RedHatAI INT4 17.7 GB	同 ③
投机	draft-mtp n-max 3	draft-mtp n-max 2~5	无	NEXTN steps3/draft4
code 解码	80.9 t/s	101.2（nmax4）/ 94.7（nmax3）	41.5 t/s	89.3 t/s
tool 解码	81.8 t/s	91.1（nmax4）/ 80.2（nmax3）	40.5 t/s	86.6 t/s
prose 解码	52.9 t/s	59.7（nmax3）	41.5 t/s	59.7 t/s
双路总吞吐	95-160（波动大）	161.4（±0.3%，3 轮）	82.9 t/s	170.5 t/s
可用上下文	128K × 2	256K × 2	128K（单路实测 123K）	~45K（建议 32K）
显存占用	28.4 GB（含视觉）	27.6 GB（256K KV，无视觉）	30.4 GB	26.2 GB
MTP 接受率	未记录	tool 87-100% / code 87-89% / prose 42-45%	—	0.94 / 0.93 / 0.51
接受长度	未记录	n-max4：4.22-4.50	—	steps3：3.66-3.76
视觉	mmproj（+0.84 GB）	未加载（可加，+870 MiB）	该权重有视觉塔	可 --language-only 跳过
prefill	未测	报告未列出	1680-1915 tok/s（123K 时 1199）	~1775 tok/s
无审查	（去审版）	未标注	原始模型	原始模型

2. 口径说明（不看这段会误判）

四组数据的"上下文"完全不同，这是最容易误读的地方：

其余差异：

• ① ② 用 temp 0.7 / top-p 0.8 / top-k 20，③ ④ 用贪婪解码（temp 0）
• ① ② 输出长度 tool 36 / code 300 / prose 338-363 token；③ ④ 取 128 token
• ① ② 的 tool 负载是 JSON 工具调用；③ ④ 的对应项是"抽取原文（回声型）"
• ①② 的 KV 是 q8_0 + -fa on；③④ 是 fp8_e4m3

所以 ④ 的 170.5 t/s 双路吞吐虽然最高，但它是在 32K 上下文下测的；② 的 161.4 t/s 是在 256K 上下文下测的。论"每单位上下文的速度"，② 明显更强。

3. 分项解读

3.1 解码速度：Q4_K_M + MTP 单路最快

解码是显存带宽游戏，权重越小越快，四组的排名和权重体积排名几乎一致：

15.33 GB (②)  >  17.7 GB (③④)  >  20.89 GB (①)

② 比 ④ 快 13%（code），主要就是 15.33 GB vs 17.7 GB 的差距。③ 慢是因为它完全没有投机 —— 也就是说，④ 相比 ③ 的 +115% 全部来自投机，和权重无关。

3.2 双路扩展性：② 最稳，④ 峰值最高

② 的双路三轮数据波动只有 ±0.3%（161.0 / 161.6 / 161.5），稳定性最好。报告里的解释也合理：tool 请求输出短（36 token），并发调度开销占比大所以掉 13.7%；code 输出长（300 token），几乎不掉速。

3.3 上下文与显存：这才是 ② 的杀手锏

② 能做到 256K 双路 + MTP 只占 27.6 GB，秘籍在报告里那句话："KV 池按实际使用分配，不是预分配全上下文" —— 双路只比单路多 342 MiB，n-max 每 +1 只多 150 MiB（草稿模型 KV）。

而 SGLang 是预分配：打开 MTP 后它会留约 8 GB 结构性预留，KV 池被硬顶在 45423 token（把并发降到 1、mem-fraction 拉到 0.97、prefill 压到 2048 也只到 60973），--max-total-tokens 还被忽略。

这就是"llama.cpp 能 256K×2 + MTP、SGLang 只能 32K + MTP"的根本原因 —— 不是引擎算得慢，是显存分配策略不同。

3.4 MTP 参数扫描对照

两组都印证了同一个规律：n-max / steps 越大，可预测任务越快，创作类接受率反而下降。

② 的接受率：n-max 2 → tool 100% / code 89.3% / prose 45.2%；n-max 4 → 81.2% / 80.9% / 29.6%。
④ 的接受率：steps 1/2 → 0.95 / 0.97 / 0.74；steps 3/4 → 0.93 / 0.94 / 0.51。

② 的接受长度在 n-max 4 时到 4.22-4.50，已经和帖子 1356 里 SGLang NEXTN 的 3.8-4.2 持平甚至更高；④ 的 steps3 是 3.66-3.76。④ 理论上也能上 steps 5（code 108.7 t/s、接受长度 5.57），但 KV 池会被压到 10403 token，13.7K 的提示直接 400 —— 又是那个显存分配问题。

3.5 prefill

只有 ③④ 有干净的 prefill 数据（SGLang）：

①② 的 llama.cpp 响应体里其实有 prompt_per_second 字段（报告第八节提到取数方式），建议补一组 llama-bench -p 512,8192,65536 -n 128，四方就能在同一口径下比 prefill。SGLang 的 chunked prefill 在 512→123K 只掉 30%，这是它目前唯一稳赢的项。

3.6 功能面

能力	①	②	③④
视觉	mmproj	可加（+870 MiB）	该权重有视觉塔
前缀复用	prompt cache per-slot	同	HiCache 两级，17.9K 前缀 10.2s → 1.25s
并发模型	固定 --parallel N	同	continuous batching（但受 mamba 态限制）
部署复杂度	单 exe，最简	同	Python 环境 + 一堆参数
无审查		未标注	（原始模型）

4. 结论与选型

如果只记一句话：llama.cpp 的"KV 按需分配"让它在 MTP + 长上下文这个组合上完胜；SGLang 的"预分配 + MTP 预留"把上下文锁死在 45K，但它换来了 HiCache 前缀复用和更高的 prefill。

5. 附：② 的推荐参数（来自 unsloth 测试报告）

:: 单任务优先（最快）
-c 262144 --parallel 1 --spec-draft-n-max 4

:: 同时跑两个任务（吞吐优先）
-c 262144 --parallel 2 --spec-draft-n-max 3

:: 中文创作为主（prose 峰值）
-c 262144 --parallel 1 --spec-draft-n-max 3