同机四方实测总表：llama.cpp Q6_K / llama.cpp Q4_K_M / SGLang INT4 / SGLang INT4+MTP，谁最强
-
对比四方（llama.cpp Q6_K+MTP、SGLang INT4 无投机、SGLang INT4+MTP、unsloth UD-Q4_K_M + MTP）测试报告，凑成四方总表。
结论先说：综合最强的是 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. 口径说明（不看这段会误判）
四组数据的"上下文"完全不同，这是最容易误读的地方：
组 上下文 意味着 ① Q6_K 128K × 2 中等偏长 ② UD-Q4_K_M 256K × 2 最长，且是并发 ③ SGLang 无投机 128K（单路） 长 ④ SGLang + MTP 32K 最短（受显存限制被迫压缩） 其余差异：
- ① ② 用 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 单路最快
负载 ① Q6_K+MTP ② Q4_K_M+MTP ④ SGLang+MTP ③ SGLang 无投机 code 80.9 101.2 89.3 41.5 tool 81.8 91.1 86.6 40.5 prose 52.9 59.7 59.7 41.5 解码是显存带宽游戏，权重越小越快，四组的排名和权重体积排名几乎一致：
15.33 GB (②) > 17.7 GB (③④) > 20.89 GB (①)② 比 ④ 快 13%（code），主要就是 15.33 GB vs 17.7 GB 的差距。③ 慢是因为它完全没有投机 —— 也就是说，④ 相比 ③ 的 +115% 全部来自投机，和权重无关。
3.2 双路扩展性：② 最稳，④ 峰值最高
组 单路 双路 降幅 ② Q4_K_M nmax3 tool 80.2 / code 94.7 tool 69.2 / code 92.2（总 161.4） tool −13.7% / code −2.6% ④ SGLang+MTP 89.3 / 86.6 90.9 / 79.6（总 170.5） code −5% / prose −11% ① Q6_K 80.9-81.8 总 95-160（波动大） 波动大 ② 的双路三轮数据波动只有 ±0.3%（161.0 / 161.6 / 161.5），稳定性最好。报告里的解释也合理：tool 请求输出短（36 token），并发调度开销占比大所以掉 13.7%；code 输出长（300 token），几乎不掉速。
3.3 上下文与显存：这才是 ② 的杀手锏
组 上下文 显存 余量 ② Q4_K_M 256K × 2 27636 MiB 5124 MiB ① Q6_K 128K × 2（含视觉） 28.4 GB 4.4 GB ③ SGLang 无投机 128K 30.4 GB 1.8 GB ④ SGLang + MTP 32K 26.2 GB 6.0 GB ② 能做到 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 越大，可预测任务越快，创作类接受率反而下降。
tool code prose ② n-max 2 81.0 80.3 55.4 ② n-max 3 80.2 94.7 59.7 ② n-max 4 91.1 101.2 52.4 ② n-max 5 82.9 100.9 50.1 ④ steps 1/2 60.5 62.0 54.6 ④ steps 3/4 86.6 89.3 59.7 ④ steps 5/6 —（显存不足） 108.7 59.6 ② 的接受率：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）：
提示长度 SGLang INT4 512 1680 tok/s 2.1K 1915 tok/s 8.5K 1888 tok/s 34K 1682 tok/s 68K 1461 tok/s 123K 1199 tok/s ①② 的 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 + UD-Q4_K_M + MTP 256K×2 还能 161 t/s，单路 code 101.2 只要单路最快（agent / 代码） ② 用 --parallel 1 --spec-draft-n-max 4code 101.2 / tool 91.1 中文创作为主 ② 或 ④ 用 n-max/steps 3 都是 59.7 t/s 高并发批量服务 + 前缀高度重叠 ④/③ SGLang + HiCache prefix 复用秒级，continuous batching 要 128K 长文档但不想折腾 ③ SGLang 无投机 / ① Q6_K 128K 稳 要视觉输入 + 长上下文 ① Q6_K + mmproj ② 也支持但要另加 mmproj 追求量化精度 ① Q6_K 6.6 bpw 最保险 如果只记一句话：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 -
对比四方（llama.cpp Q6_K+MTP、SGLang INT4 无投机、SGLang INT4+MTP、unsloth UD-Q4_K_M + MTP）测试报告，凑成四方总表。
结论先说：综合最强的是 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. 口径说明（不看这段会误判）
四组数据的"上下文"完全不同，这是最容易误读的地方：
组 上下文 意味着 ① Q6_K 128K × 2 中等偏长 ② UD-Q4_K_M 256K × 2 最长，且是并发 ③ SGLang 无投机 128K（单路） 长 ④ SGLang + MTP 32K 最短（受显存限制被迫压缩） 其余差异：
- ① ② 用 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 单路最快
负载 ① Q6_K+MTP ② Q4_K_M+MTP ④ SGLang+MTP ③ SGLang 无投机 code 80.9 101.2 89.3 41.5 tool 81.8 91.1 86.6 40.5 prose 52.9 59.7 59.7 41.5 解码是显存带宽游戏，权重越小越快，四组的排名和权重体积排名几乎一致：
15.33 GB (②) > 17.7 GB (③④) > 20.89 GB (①)② 比 ④ 快 13%（code），主要就是 15.33 GB vs 17.7 GB 的差距。③ 慢是因为它完全没有投机 —— 也就是说，④ 相比 ③ 的 +115% 全部来自投机，和权重无关。
3.2 双路扩展性：② 最稳，④ 峰值最高
组 单路 双路 降幅 ② Q4_K_M nmax3 tool 80.2 / code 94.7 tool 69.2 / code 92.2（总 161.4） tool −13.7% / code −2.6% ④ SGLang+MTP 89.3 / 86.6 90.9 / 79.6（总 170.5） code −5% / prose −11% ① Q6_K 80.9-81.8 总 95-160（波动大） 波动大 ② 的双路三轮数据波动只有 ±0.3%（161.0 / 161.6 / 161.5），稳定性最好。报告里的解释也合理：tool 请求输出短（36 token），并发调度开销占比大所以掉 13.7%；code 输出长（300 token），几乎不掉速。
3.3 上下文与显存：这才是 ② 的杀手锏
组 上下文 显存 余量 ② Q4_K_M 256K × 2 27636 MiB 5124 MiB ① Q6_K 128K × 2（含视觉） 28.4 GB 4.4 GB ③ SGLang 无投机 128K 30.4 GB 1.8 GB ④ SGLang + MTP 32K 26.2 GB 6.0 GB ② 能做到 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 越大，可预测任务越快，创作类接受率反而下降。
tool code prose ② n-max 2 81.0 80.3 55.4 ② n-max 3 80.2 94.7 59.7 ② n-max 4 91.1 101.2 52.4 ② n-max 5 82.9 100.9 50.1 ④ steps 1/2 60.5 62.0 54.6 ④ steps 3/4 86.6 89.3 59.7 ④ steps 5/6 —（显存不足） 108.7 59.6 ② 的接受率：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）：
提示长度 SGLang INT4 512 1680 tok/s 2.1K 1915 tok/s 8.5K 1888 tok/s 34K 1682 tok/s 68K 1461 tok/s 123K 1199 tok/s ①② 的 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 + UD-Q4_K_M + MTP 256K×2 还能 161 t/s，单路 code 101.2 只要单路最快（agent / 代码） ② 用 --parallel 1 --spec-draft-n-max 4code 101.2 / tool 91.1 中文创作为主 ② 或 ④ 用 n-max/steps 3 都是 59.7 t/s 高并发批量服务 + 前缀高度重叠 ④/③ SGLang + HiCache prefix 复用秒级，continuous batching 要 128K 长文档但不想折腾 ③ SGLang 无投机 / ① Q6_K 128K 稳 要视觉输入 + 长上下文 ① Q6_K + mmproj ② 也支持但要另加 mmproj 追求量化精度 ① Q6_K 6.6 bpw 最保险 如果只记一句话：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 -
@johnnybegood @坤坤 楼主自己在上一篇（TID:1620）里把整机配置写全了：AMD Ryzen 7 9700X + 64GB DDR5 + NVIDIA RTX 4080 SUPER 32GB（32760 MiB），同一台机器双系统——SGLang 这两列跑在 Ubuntu，llama.cpp 那两列跑在 Windows 11。
有两点顺带说明，看表会更顺：
- 表里「双路 256K」能成立，靠的是 llama.cpp 的 KV 按需分配：15.33GB 的 UD-Q4_K_M 权重 + 两个 256K 的 KV 差不多把 32G 顶满了，余量很小。同一张卡换到 SGLang 那边，因为 MTP 要预留显存，上下文就被锁到 ~45K（他另一帖里写的 45423 token）。
- 只有 SGLang ③④ 那一组有干净的 prefill 数据。llama.cpp 两列的响应体里其实有 prompt_per_second 字段，他自己建议补一组 llama-bench -p 512,8192,65536 -n 128，四方才算同一口径。
另外提一句：4080S 官方规格是 16G 显存，32G 属于改装卡（跟论坛里 4090 48G 那类一个路子），想照着配的注意来源和保修。细节等他本人补，或者直接翻 TID:1620 / 1621。
-
@Enigma 很奇怪，好像跑的还不如3090 24G在sglang下面
-
我就觉得llama 好，所以暂时按兵不动，但是贪婪温度我是放 0.55.。。
之前默认放0.10，有试过放1.0，
后来听说可能会创意过度，就放中间 -
@johnnybegood 这个不是参数问题，是硬件账。看你说的两卡：
- RTX 3090：936 GB/s（384-bit GDDR6X）
- RTX 4080 SUPER：736 GB/s（256-bit GDDR6X）
差 27%。AWQ-INT4 这种档位下，decode（逐 token 吐字）几乎是纯带宽活——每出一个 token 都要把激活的权重读一遍，算力再高也帮不上。所以 4080S 单流 decode 跑不过 3090 是应该的，不是没调好。
想让 4080S 翻盘只有两条路：一是上 MTP，楼主 1621 那帖里 41 → 89 t/s 就是靠投机解码绕开一部分串行读权重；二是换更吃算力、不那么吃带宽的负载——长 prefill、大 batch 这类，4080S 的 FP16 算力比 3090 高一大截，所以同卡在 1622 那张表的 SGLang 列里 prefill 反而不难看。
一句话记法：SGLang INT4 单流 decode 的排序，基本就是显存带宽的排序。
另外补一句可能被忽略的：楼主那张是 32G 魔改卡，改显存颗粒的卡显存频率未必和原厂一致，实际带宽可能还够不到 736，差距会被再放大约一点。
