双 3090 NVLink 从vLLM 换到 SGLang 跑 Qwen3.8-27B:实测 108 t/s,262K 上下文全开

starryskyknight

双 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 更好的投机解码配置？

数据都附了测法，欢迎复现打脸。配置有任何问题也请直接说，谢谢各位。

Xiaote

@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 左右留余量。

neo

精彩的分享
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缓存。

starryskyknight

@neo 感谢大神指正！实测采纳了您的建议：max_mamba_cache_size 钉到 10（=2×5），mamba 池从 32 slots 降到 10（省 1.55GB/卡），KV 池 415K→518K tokens，health 正常。官方公式和您的说法完全一致，下次多 agent 并发再按 max-running-requests 反推。学习了！

Leon Y

感谢分享，同双 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，几乎不掉速。

applejuice

@Leon-Y 测一测 245-250 可能有150+- t/s

Leon Y

对，250W在～150左右
设功率墙只要是涡轮卡太吵了

stxpnet

@Leon-Y 二位的主板和CPU是什么样的呢？ @applejuice

applejuice

华南金牌 X10X99-8D, E5-2686 v4

h12d-8d, epyc7452 刚到这个周末希望能成功用上

显卡也刚回来寄回去卖家测试没问题结果又回来了
卖家说他们手上没有nvlink 也没有3090 库存
nvlink 测试不了所以nvlink 是彻底翻车了

所以我就顺便买了h12d-8d 希望两张卡不用跨cpu 速度快点

Leon Y

@stxpnet
CPU：i7-9700
板：技嘉 Z370XP SLI（双卡 PCIe x8/x8）
卡：2× 华硕 Turbo RTX 3090 24G + NVLink
内存：64G DDR4

starryskyknight

@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

@starryskyknight
我这边 162 是单路口径，而且单路下测出来跨度很大：

内容单路解码
数字计数（高可预测） ~162-168 t/s
JSON/结构化 ~168 t/s
Python 代码 ~130 t/s
英文/中英混合 ~98-102 t/s
中文散文（典型） ~77-85 t/s

starryskyknight

@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 数据都有)。

terry

@starryskyknight DFlash或者DSpark会更有前途，因为工作原理有差距，它草稿模型先工作，主模型验证，这样很多时候连显卡风扇都不转。

starryskyknight

@terry 没错感谢建议实装后目前主力是DFlash2 在另一篇贴文内就不转过来了感谢推荐

抡锤者