-
双 3090 NVLink 从 vLLM 换到 SGLang 跑 Qwen3.8-27B：实测 108 t/s，262K 上下文全开
之前在论坛发过一篇双 3090 跑 Qwen3.6 的帖子（vLLM 世代，p50 大概 61 t/s）。板主说要我试试看sglang , 之前试了一直没成功。 今天花了一些时间，这几个月把整套东西迁到了 SGLang，顺便换上了 Qwen3.8-27B 的 AWQ 去审查版，速度翻了一截，踩了一堆坑，整理出来给大家参考，也请各位大神帮忙看看还有什么优化空间。
一句话结论
双 3090 + NVLink + SGLang 0.5.18 + Qwen3.8-27B AWQ W4A16 + EAGLE 投机解码，常规对话 88 t/s，中文散文 178 t/s，accept rate 0.95，262K 上下文全开无压力。比之前 vLLM + Qwen3.6 世代快了约 40%。
硬件配置
项目 内容 GPU 2× RTX 3090 24GB（NVLink 4-link，56.25 GB/s/方向） CPU / RAM Core Ultra 285K / 64GB DDR5 系统 Ubuntu 26.04，CUDA 13 引擎 SGLang 0.5.18（pip editable） 模型 twolven/Qwen3.8-27B-abliterated-AWQ-MTP（18.7GB + MTP head 849MB） 为什么从 vLLM 换到 SGLang
三个原因：
- Radix cache：多轮对话的前缀复用，第二轮起 prefill 基本免费
- EAGLE 投机解码整合度：Qwen3.8 的 MTP head 直接用 EAGLE 跑，accept rate 实测 0.95（accept len 3.85，接近官方 DFlash2 验证水平）
- 官方 Cookbook：SGLang 官方文档现在有 Qwen3.8-27B 专属部署指南（docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B），照着调就行
现役启动参数（可直接抄）
python3 -m sglang.launch_server \ --model-path /path/to/twolven-Qwen3.8-27B-abliterated-AWQ-MTP \ --served-model-name qwen3.8-27b \ --tp-size 2 \ --trust-remote-code \ --mem-fraction-static 0.94 \ --kv-cache-dtype fp8_e5m2 \ --chunked-prefill-size 2048 \ --max-prefill-tokens 8192 \ --max-running-requests 2 \ --enable-cache-report \ --mamba-track-interval 2048 \ --speculative-algorithm EAGLE \ --speculative-num-steps 3 \ --speculative-eagle-topk 1 \ --speculative-num-draft-tokens 4 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder几个关键点：
- EAGLE 3/1/4 是官方 Cookbook 的 MTP 推荐配方（NEXTN 就是 EAGLE 的 alias，同一个算法）
--kv-cache-dtype fp8_e5m2只压 KV cache，不碰权重——3090 是 Ampere 架构，没有原生 FP8 硬件，FP8 权重量化在 30 系上是假命题（白皮书里 GA102 Tensor Core 只有 FP16/BF16/TF32/INT8/INT4）- 权重走 AWQ W4A16 group128，单用户解码是带宽瓶颈，W4 读一半字节 = 2 倍速，AWQ 还保护 1% 关键权重
实测数据（附测法）
场景 速度 测法 常规对话（游记创作） 88 t/s 600 tokens 输出计时，3 次取中位 中文散文 178 t/s 2048 tokens 输出 工具调用 3.2–4.2s 完整轮 带 tool schema 的完整往返 多轮 radix 命中 第二轮 2.77s 同前缀第二轮含 300 tokens 输出 思考档 medium 6.1 ms/tok reasoning_effort 三档实测，medium 是甜点 踩过的坑（省你几天时间）
- 模板坑：上游模型的 chat template 有工具调用陷阱（静默丢 tool 定义），换 froggeric/Qwen-Fixed-Chat-Templates 的 v22.4 解决
- parser 必设：
--reasoning-parser qwen3 --tool-call-parser qwen3_coder不设的话 thinking 标签会污染输出 - MTP head 必须与主权重同源：试过一个 obliterated 版（借了别的 abliterated 模型的 MTP head），EAGLE accept 直接崩，速度掉到 47 t/s——比不开投机还慢
- HiCache 别乱开：单 agent 场景 L2 命中≈0，开着输出速度砍半（论坛里也有同测）；多 agent 共享前缀的生产线再考虑
- 模型切换走 systemd：SSH 后台启动的进程断线会被 SIGHUP 干掉
- 30 系别折腾 FP8/NVFP4：都是给 Hopper/Blackwell 的bolded text
现在的问题，想请大神指点
- mamba 系参数（
mamba-full-memory-ratio等）在 TP=2 双卡下的最佳值，官方 calculator 是单卡口径，双卡怎么算？ - HiCache 在「多 agent 并发」场景的实测，谁跑过？命中率和速度折损大概什么量级？
- 还有没有比 EAGLE K=3 更好的投机解码配置？
数据都附了测法，欢迎复现打脸。配置有任何问题也请直接说，谢谢各位。
-
@starryskyknight 三个问题分开说，都是能直接上手验证的：
1. mamba 参数在 TP=2 下怎么算
--mamba-full-memory-ratio（默认 0.2）是给 mamba state 池预留的显存比例，不是绝对值。TP=2 时 state 张量按 hidden 维切到两张卡上，每 rank 只存一半——所以官方单卡 calculator 算出的 state 需求，落到每张卡上直接减半，0.2 这个默认值双卡下通常够用甚至偏松。别拍脑袋调：你反正开着--enable-cache-report，跑一轮长对话看 mamba 段实际占用和有没有 state 淘汰/重建日志——有淘汰就 +0.05，占用离上限很远就降到 0.15，把显存让给 KV。--mamba-track-interval 2048保持默认就行。2. HiCache 多 agent 并发
机制是三层 KV（GPU→RAM→NVMe），收益完全取决于前缀重叠度：多个 agent 共享同一套 system prompt + 工具 schema + 长文档时前缀命中率高，这正是它设计的场景（TID:1341 单卡 32GB 三层 KV 实测就是这类）；每个 agent 上下文完全独立时 L2/L3 命中≈0，跟你单 agent 的结论一致。量级上注意：262K 满上下文的 KV 是 GB 级，RAM 层换入零点几秒，SSD 层换入秒级——所以多 agent 场景要把热数据钉在 GPU/RAM 层，SSD 只放真冷会话。开
--enable-cache-report看各层 hit-len 统计，比问谁都准。顺带一句：TID:1329 Ben Lee 那个 HiCache 崩staged_write_back.cuh是 kernel 层问题（换 NVFP4 可绕），跟你在 3090 上跑不是一回事，别被吓到。3. 比 EAGLE K=3 更好的配置
你 accept len 3.85 ≈ K=3 的草稿窗口已经打满，瓶颈在窗口长度不在接受率——直接试
--speculative-num-steps 4~5+--speculative-num-draft-tokens 5~6，accept len 还能再涨，预期 +5~15%；每多一步多一次 verify 开销，收益递减，K=5 基本到顶。--speculative-eagle-topk 1是对的，topk>1 只对采样多样性有意义。DFLASH2 是 DeepSeek 系专属（TID:1340 那台 4090 48G 110 tok/s 就是它），Qwen 走 EAGLE/MTP 就是正解，不用换。另外 88 vs 178 的差距是输出长度摊薄固定开销的正常现象，不是配置问题。一个提醒：
--mem-fraction-static 0.94很激进，--max-running-requests 2正好压住；以后要多开 agent 记得降到 0.90 左右留余量。 -
精彩的分享
mamba-full-memory-ratio 官方默认为0.9，对于个人使用非常浪费显存。
最佳值需要根据mem-fraction-static和max-running-requests的值结合日志来看。
比如你需要：
max-running-requests = 4 ，那么你需要的max_mamba_cache_size应该为：44=16 (extra_buffer_lazy的情况下)
接下来查看启动日志：
max_mamba_cache_size是否为16
大于16就调小，比如0.35，小了就调大，直到这个值为16就是最佳值
如果没有开启extra_buffer_lazy的情况，这个值应该是45=20，这个看自己选择了。
另外
MTP+HiCache 目前确实性能冲突，推理速度腰斩是可能的。
只是开启HiCache的情况下，我的测试中推理速度影响为5%左右。
在内存配置为kv缓存1.5倍以上时，多会话能大幅减少prefill，减少首字吐字延迟。
如果配置了NVME，重启sglang可以完美命中之前会话的kv缓存。 -
精彩的分享
mamba-full-memory-ratio 官方默认为0.9，对于个人使用非常浪费显存。
最佳值需要根据mem-fraction-static和max-running-requests的值结合日志来看。
比如你需要：
max-running-requests = 4 ，那么你需要的max_mamba_cache_size应该为：44=16 (extra_buffer_lazy的情况下)
接下来查看启动日志：
max_mamba_cache_size是否为16
大于16就调小，比如0.35，小了就调大，直到这个值为16就是最佳值
如果没有开启extra_buffer_lazy的情况，这个值应该是45=20，这个看自己选择了。另外
MTP+HiCache 目前确实性能冲突，推理速度腰斩是可能的。
只是开启HiCache的情况下，我的测试中推理速度影响为5%左右。
在内存配置为kv缓存1.5倍以上时，多会话能大幅减少prefill，减少首字吐字延迟。
如果配置了NVME，重启sglang可以完美命中之前会话的kv缓存。 -
感谢分享，同双 3090 NVLink 4-link + SGLang 0.5.18，果断换去了AWQ。我同时测了 shawnw3i/Qwen3.8-27B-AWQ-MTP（标准）和 twolven/...-abliterated-AWQ-MTP（去审查）：
实测对比（正确的 token 口径）
另外加一点：功率墙有甜点。 我的机器有功率限制，扫了一遍：180W→62 t/s、220W→116、260W→162、300W→170。260W 是甜点（往上只 +5%，往下掉 28%）。如果楼主那台想控温/控电，可以试 260W，几乎不掉速。
-
感谢分享，同双 3090 NVLink 4-link + SGLang 0.5.18，果断换去了AWQ。我同时测了 shawnw3i/Qwen3.8-27B-AWQ-MTP（标准）和 twolven/...-abliterated-AWQ-MTP（去审查）：
实测对比（正确的 token 口径）另外加一点：功率墙有甜点。 我的机器有功率限制，扫了一遍：180W→62 t/s、220W→116、260W→162、300W→170。260W 是甜点（往上只 +5%，往下掉 28%）。如果楼主那台想控温/控电，可以试 260W，几乎不掉速。
-
，
T terry 固定了此主题
-
，T terry 将此主题从 LLM讨论区 移至此处
-
，系统 取消固定了此主题
-
@Leon-Y 二位的主板和CPU是什么样的呢？ @applejuice
-
感谢分享，同双 3090 NVLink 4-link + SGLang 0.5.18，果断换去了AWQ。我同时测了 shawnw3i/Qwen3.8-27B-AWQ-MTP（标准）和 twolven/...-abliterated-AWQ-MTP（去审查）：
实测对比（正确的 token 口径）另外加一点：功率墙有甜点。 我的机器有功率限制，扫了一遍：180W→62 t/s、220W→116、260W→162、300W→170。260W 是甜点（往上只 +5%，往下掉 28%）。如果楼主那台想控温/控电，可以试 260W，几乎不掉速。
@Leon-Y 感谢同配置实测，260W 甜点的数据很有参考价值！涡轮卡起飞噪音我也深受其害，回头照你的区间测一下 245-260W。
顺便更新我这边的最新状态（9/1 实测，SGLang main + zlab DFLASH2 draft）：
- 单路端到端（2500 token 长输出含 prefill）：82-84 t/s
- 双路并发 aggregate：151 t/s，峰值 161
之前帖子里说的 108/133 都是并发口径，单路口径一直就是这个数。DFLASH2 相比 EAGLE 的提升在并发场景更明显（+40% 左右）。
另外这两天 SGLang main 更新比较勤，我做了 A/B 对比（8/29 版 vs 9/1 版），性能一致无 regression，可以放心 pull。
你那边 162/150 是单路还是并发口径？想对齐一下数据。
-
@Leon-Y 感谢同配置实测，260W 甜点的数据很有参考价值！涡轮卡起飞噪音我也深受其害，回头照你的区间测一下 245-260W。
顺便更新我这边的最新状态（9/1 实测，SGLang main + zlab DFLASH2 draft）：
- 单路端到端（2500 token 长输出含 prefill）：82-84 t/s
- 双路并发 aggregate：151 t/s，峰值 161
之前帖子里说的 108/133 都是并发口径，单路口径一直就是这个数。DFLASH2 相比 EAGLE 的提升在并发场景更明显（+40% 左右）。
另外这两天 SGLang main 更新比较勤，我做了 A/B 对比（8/29 版 vs 9/1 版），性能一致无 regression，可以放心 pull。
你那边 162/150 是单路还是并发口径？想对齐一下数据。
-
@starryskyknight
我这边 162 是单路口径，而且单路下测出来跨度很大：内容 单路解码
数字计数（高可预测） ~162-168 t/s
JSON/结构化 ~168 t/s
Python 代码 ~130 t/s
英文/中英混合 ~98-102 t/s
中文散文（典型） ~77-85 t/s@Leon-Y 感谢分享!同为双 3090 NVLink,你的 260W 功率墙下 MTP 单路 162-168 t/s 已经很猛了。我们刚从 MTP 换到 DFLASH2,用同口径数据做个对照:
唯一干净的同口径(单路端到端):
场景 你的(SGLang 0.5.18 + MTP) 我们的(dev507 + DFLASH2) 中文散文 77-85 t/s 85.4 t/s 中文散文我们只赢 5-10%——中文可预测性低是共同天花板,DFLASH2 在这类场景优势不大,这和你的观察一致。
高可预测场景(口径不同,仅供参考):
- 你:数字计数单路 decode 162-168 / JSON 168 / Python 130
- 我们:JSON 并发 280.5(峰 303.7)/ Python 并发 254 / 短 prompt 单路 297.3
我们没测「数字计数单路 decode」这个口径,不能直接比。但 DFLASH2 一次接受的 token 数(代码场景平均 6.69)比 MTP 3 token 高一倍多,越可预测的场景差距越大。
三个差异点:
- 引擎代差:dev507 是 dev 分支,比 0.5.18 稳定版多了 DFLASH2 等一大票新特性
- 你的 260W 甜点(260→162 vs 300→170 只差 5%)很有价值,涡轮卡控温控噪刚需
- 我们没功率限制,满血跑
欢迎来 1502 帖子交流,那边有我们 DFLASH2 完整部署踩坑记录,以及「DFLASH 牺牲视觉」的实测辟谣(视觉任务思考开/关的 A/B 数据都有)。
-
@Leon-Y 感谢分享!同为双 3090 NVLink,你的 260W 功率墙下 MTP 单路 162-168 t/s 已经很猛了。我们刚从 MTP 换到 DFLASH2,用同口径数据做个对照:
唯一干净的同口径(单路端到端):
场景 你的(SGLang 0.5.18 + MTP) 我们的(dev507 + DFLASH2) 中文散文 77-85 t/s 85.4 t/s 中文散文我们只赢 5-10%——中文可预测性低是共同天花板,DFLASH2 在这类场景优势不大,这和你的观察一致。
高可预测场景(口径不同,仅供参考):
- 你:数字计数单路 decode 162-168 / JSON 168 / Python 130
- 我们:JSON 并发 280.5(峰 303.7)/ Python 并发 254 / 短 prompt 单路 297.3
我们没测「数字计数单路 decode」这个口径,不能直接比。但 DFLASH2 一次接受的 token 数(代码场景平均 6.69)比 MTP 3 token 高一倍多,越可预测的场景差距越大。
三个差异点:
- 引擎代差:dev507 是 dev 分支,比 0.5.18 稳定版多了 DFLASH2 等一大票新特性
- 你的 260W 甜点(260→162 vs 300→170 只差 5%)很有价值,涡轮卡控温控噪刚需
- 我们没功率限制,满血跑
欢迎来 1502 帖子交流,那边有我们 DFLASH2 完整部署踩坑记录,以及「DFLASH 牺牲视觉」的实测辟谣(视觉任务思考开/关的 A/B 数据都有)。
@starryskyknight DFlash或者DSpark会更有前途，因为工作原理有差距，它草稿模型先工作，主模型验证，这样很多时候连显卡风扇都不转。
-
@starryskyknight DFlash或者DSpark会更有前途，因为工作原理有差距，它草稿模型先工作，主模型验证，这样很多时候连显卡风扇都不转。
