RTX PRO 6000 Blackwell 跑 Qwen3.8-27B-FP8：从 46 到 251 tok/s 的 SGLang 部署

2026-08-20 · SGLang · Blackwell SM120 · 投机解码

这篇记录一次完整的「工作站级 Blackwell 上部署大模型推理服务」的实战：在一台 8× NVIDIA RTX PRO 6000 Blackwell（单卡 96GB GDDR7，计算能力 SM120）的节点上，用 SGLang 部署 Qwen3.8-27B-FP8（混合 GDN 线性注意力 + 全注意力的视觉语言模型），并叠加投机解码，最终把单流 decode 从基线 46 tok/s 推到 251 tok/s（5.4×），高并发 C16 聚合 3524 tok/s。

它有意思的地方不在「调参」，而在三个容易被忽略的结构性事实：① 你买到的 Blackwell 不一定是数据中心那块（SM120 和 SM100 的 FP8 栈不通用，这是第一道墙）；② 对带宽受限的 decode，投机解码才是 GDDR7 上的正确杠杆（而不是继续抠 FP8 GEMM）；③ 两种 draft 架构（DSpark 的独立 Markov 头 vs DFlash2 的候选选择器）差距完全由一个指标决定 —— accept length。下面按「约束 → 方案 → 实测 → 坑」的顺序走。

1. 第一道墙：你的 Blackwell 是 SM120，不是 SM100

部署前最该先确认的一件事，是这块 Blackwell 的计算能力。RTX PRO 6000 / RTX 50 系属于 SM120（工作站 / 专业级 Blackwell），而 B100 / B200 / GB200 数据中心卡是 SM100。两者虽然都叫 Blackwell、都原生支持 FP8，但预编译的 kernel 栈不通用：

• FlashInfer 预编译 cubin 包只带 SM100，SM120 必须走 源码 JIT 编译；
• trtllm_mha 等数据中心 attention 后端是 SM100-only，SM120 用不了；
• FlashInfer 要求 CUDA ≥ 12.9 才会把 SM12.x 识别进编译目标。

这个区分的直接后果：一套在 B200 上「开箱即用」的 FP8 推理栈，搬到 SM120 上会连环报错（DeepGEMM "Unknown recipe"、flashinfer "trtllm not supported on capability 120"、cutlass/triton 吐垃圾 token）。所以第一性结论是：先按「SM120 需要自己 JIT、且工具链门槛更高」来选版本——SGLang 要用 0.5.17+（Day-0 支持 Qwen3.8 + SM120），而不是社区跑 B200 的旧版本。

2. 部署方案

2.1 硬件与拓扑

选 GPU6+7 做 TP2 是因为它们在拓扑表里是 PIX（同一 PCIe switch 下的 P2P 直连，同 NUMA1）——TP 的 allreduce 走这条最便宜的路。跨 NUMA（SYS）的卡对会多一层 UPI，TP 通信变慢，不选。

2.2 软件栈：为什么要两套 venv

关键约束：DFlash2 的候选选择器（CandidateSelector / selector_rank / conv_group）在官方 0.5.17 里不存在，是 8/19 才合进 master 的（#35371）。所以要么把生产 venv 升到 master（会破坏正在跑的 DSpark 依赖），要么另起一个隔离 venv 装 master。后者风险最低——两套 venv 并存，各自 CUDA_VISIBLE_DEVICES 不重叠即可。这是「不为了新特性去动生产环境」的朴素工程判断。

2.3 模型与架构

Qwen3.8-27B-FP8 是一个混合架构的视觉语言模型，理解它的层布局是理解整套部署参数的前提：

• 总 64 层 = 16 组 × [ 3×(GDN→FFN) + 1×(GQA→FFN) ]；
• 48 层是 GDN（Gated DeltaNet 线性注意力），16 层是 GQA 全注意力；
• hidden 5120，FFN 17408；FP8 e4m3 blockwise（[128,128]）动态量化；原生上下文 262144（可扩到 1M）。

这个「48 线性 + 16 全注意力」的混合结构，直接决定了后面两个参数为什么那样取（KV cache 只给 16 层全注意力用、GDN 另有一套 state 池）。

2.4 为什么是投机解码：decode 是带宽受限的

先讲清楚「为什么投机解码在这台机器上是正确的杠杆」，否则后面的数字没有解释力。27B 模型单流 decode 时，每生成一个 token 都要把 ~29GB 权重从显存读一遍——这是典型的内存带宽受限（memory-bound）：算得再快，也快不过搬数据。FP8 已经把权重体积砍半，但单流 decode 的瓶颈仍是「每个 token 一次全量权重读」。

投机解码的本质是把多次权重读摊薄：用一个很小的 draft 模型先「猜」出 γ 个候选 token，再用目标模型一次 forward 并行验证这 γ+1 个位置（一次权重读换最多 γ+1 个 token）。只要接受率足够高，等效于把「每 token 一次权重读」变成「每 ~5 个 token 一次权重读」。所以收益的天花板完全由 accept length（平均每次验证接受几个）决定——这也是后面对比 DSpark vs DFlash2 时唯一的根指标。

2.5 启动参数与「为什么」

服务监听 0.0.0.0:8000，同时提供 OpenAI（/v1/chat/completions）与 Anthropic（/v1/messages）双协议，共享同一模型实例和投机加速，未设 --api-key（内网可信，任意 key 即可）。并发上限 max_running_requests=48（受 GDN state 槽位约束）。

2.6 两种 draft 策略：DSpark vs DFlash2

这次部署先后试了两套 draft 架构，它们的差异是整篇性能故事的核心：

一句话：DFlash2 用「目标模型自己的 lm_head 出候选」比 DSpark「独立小 Markov 头出候选」更自洽，加上更长的 verify 窗口，accept len 从 3.3 拉到 5.1——这就是它全面更快的根本原因，后面用数字坐实。

3. 实测性能

3.1 测试方法（口径先说清）

• 脚本 benchmark.py（urllib + 线程池），每请求独立测避免日志交叉污染；
• 统一用代码生成 prompt（写一个带错误处理 / 类型标注 / docstring 的 CSV 解析函数）、256 token 输出、temperature=0.3、reasoning_effort=none（关掉思维链，纯测 decode）；
• 单流 C1 取 5 次均值；并发 C4/C16 为聚合吞吐 总 token / wall 时间；
• 口径提醒：投机解码吞吐对 prompt 领域高度敏感（接受率随领域变）。代码 / 数学类接受率最高，创意 / 长文类明显更低。下表的 DSpark/DFlash2 都是代码 prompt 的「好情形」；同一 DSpark 在通用 prompt 下 C16 只有 ~805 tok/s（vs 代码 prompt 的 1929）。跨表比时先看 prompt 是否同口径。

3.2 单流 decode：5.4× 的台阶

下面是单流 C1 从基线到主服务的完整台阶（代码 prompt，256 tok）。横轴是按优化顺序排的：

台阶拆开看，三个正交的贡献各自独立可归因：

• 加投机（基线 46.6 → DSpark TP1 110，2.4×）：纯投机解码的收益，单卡。等价于「每 ~3.3 token 一次权重读」。
• 同 TP1 换 DFlash2（110 → 163.7，+49%）：同卡数、同 TP，只换 draft 架构。增益全部来自 accept len 3.3→5.1。
• 同 DFlash2 上 TP2（163.7 → 251.6，+54%）：把最贵的 verify forward 摊到两张卡，单卡 compute 减半，PCIe P2P allreduce 足够便宜。

注意 DSpark TP2（171.5）其实略低于 DFlash2 TP1（163.7）之上——也就是说「TP2 + 弱 draft」不如「TP1 + 强 draft」：单流场景下，先把 accept len 做高（换 DFlash2）比先上 TP 更划算。TP2 是在强 draft 之上再叠一层。

3.3 并发吞吐：C1 / C4 / C16 全矩阵

把「无投机基线」也放进并发矩阵，能看到投机解码在高并发下依旧大幅领先（因为它和 batching 是正交的两个杠杆）：

两个观察：

• TP2 在单流收益最大（C1 +54%），并发越高收益收窄：DFlash2 TP1→TP2 在 C1 +54%、C4 +44%、C16 +25%。高并发时两卡已接近饱和，TP 的 PCIe 通信开销占比上升。所以交互式 / Agent 单流场景 TP2 最香，纯高吞吐批量场景 TP1 的显存和并发上限反而更从容。
• DFlash2 在所有并发档都压过 DSpark（C1 +49%、C4 +53%、C16 +54%），且高并发下优势不衰减——因为它的 selector 折进了 CUDA graph，没有随 batch 放大的额外验证开销。

3.4 为什么 DFlash2 快：accept len 是唯一的根指标

把 DSpark 和 DFlash2 的差异压到一个数上，就是 accept length（平均每次 verify 接受几个 token）。TP2 下 DFlash2 ~5.1 vs DSpark ~3.3（+55%）。accept len 越高，「一次权重读换到的 token」越多，decode 吞吐近似线性受益。它高的原因拆成两块：更长的 verify 窗口（block 8 vs 7）+ 更准的候选（目标 lm_head top_k=16 vs 独立 Markov 头）。两者叠加，就是 §3.2 台阶里那 46% 的全部来源。没有玄学，就是一个指标。

3.5 TTFT 与长上下文

TTFT 低是混合 GDN 架构送的红利：48 层线性注意力的 prefill 是 O(n)（状态固定大小），只有 16 层全注意力是 O(n²)。所以 2k prompt 首 token 才 60ms 量级——这是「模型架构」给的，不是「部署」给的，但值得在选型时记住。

3.6 与社区数据交叉验证 + 实测复核

本次 251.6 tok/s 高于社区记录的 141（EAGLE），除 DFlash2 更强外，本机是 Server Edition（600W）而非社区的 Max-Q（350W）卡，供电/持续性能更高。两个因素都朝同一个方向，不矛盾。社区 DFlash2 论文在 B200 上报 4.24–4.76×（相对 MTP3 基线），与本机「相对无投机基线 5.4×」量级一致（注意基线不同，不直接比）。

4. 九个部署坑（这篇最值钱的部分）

坑都踩过并定位到根因，按「启动会死 → 跑得慢 → 装不上」分类。

4.1 启动直接失败

4.2 版本 / 依赖

4.3 环境 / 运维

5. 运维体系：用户级 systemd

最终主服务收敛成一个用户级 systemd unit（sglang-dflash2），这是「能长期跑」的关键，而不是一个 nohup 脚本：

实测：SIGKILL 主进程 → 5s 内自动拉起 → ~45s 恢复监听 → API 200，C1 重启后仍 276 tok/s 一致。运维一键：./ops/sglang_ops.sh status|restart|logs|tail|enable。

关键环境变量（已写进 unit，避免每次手设）：

Environment=CUDA_VISIBLE_DEVICES=6,7
Environment=CUDA_HOME=/usr/local/cuda-13.2        # 坑1：SM120 必需
Environment=SGLANG_DISABLE_CUDNN_CHECK=1           # 坑6
Environment=FLASHINFER_DISABLE_VERSION_CHECK=1     # 坑5
Environment=HF_HUB_DISABLE_XET=1
Environment=HF_ENDPOINT=https://hf-mirror.com
# 注意：不要设 PYTORCH_CUDA_ALLOC_CONF=expandable_segments   # 坑3

6. 结论与选型建议

把整件事收成几条可迁移的判断：

1. 先认卡再选栈：Blackwell 分 SM120（工作站）/ SM100（数据中心），FP8 栈不通用。看到 SM120 就按「要自己 JIT + 工具链 ≥ CUDA 12.9 + attention 只能 flashinfer」来选版本，别抄 B200 的配方。
2. 杠杆要打在带宽上：27B 单流 decode 是带宽受限，继续抠 FP8 GEMM 对单流无效；投机解码（摊薄权重读）才是单流的杠杆，FP8 + batching 才是高并发的杠杆，两者正交、都要上。
3. accept len 是投机解码的北极星：换 draft 架构时只看这一个指标。DFlash2（目标 lm_head 出候选 + 更长窗口）把 accept len 从 3.3 拉到 5.1，就是全部 46% 增益的来源。
4. TP2 给单流，TP1 给批量：交互 / Agent 单流选 TP2（+54%）；纯高吞吐批量选 TP1（并发上限和 KV 容量更从容，TP 通信开销更小）。按 PIX 卡对选 TP 卡。
5. 长期跑就上 systemd：nohup 不是部署。用户级 systemd（绕 SELinux）+ linger + 自动重启 + 双路日志，才是「服务」而不是「进程」。

7. 附录

7.1 主服务启动命令（去敏，路径为示意）

CUDA_VISIBLE_DEVICES=6,7 \
CUDA_HOME=/usr/local/cuda-13.2 \
SGLANG_DISABLE_CUDNN_CHECK=1 FLASHINFER_DISABLE_VERSION_CHECK=1 \
python -m sglang.launch_server \
  --model-path ~/sglang/models/Qwen3.8-27B-FP8 \
  --host 0.0.0.0 --port 8000 --tp-size 2 \
  --attention-backend flashinfer --sampling-backend flashinfer \
  --kv-cache-dtype fp8_e4m3 --chunked-prefill-size 2048 \
  --mem-fraction-static 0.88 \
  --mamba-full-memory-ratio 6.08 --mamba-ssm-dtype bfloat16 \
  --mamba-radix-cache-strategy extra_buffer \
  --speculative-algorithm DFLASH \
  --speculative-draft-model-path ~/sglang/models/Qwen3.8-27B-DFlash2 \
  --speculative-draft-attention-backend flashinfer \
  --speculative-draft-model-quantization unquant \
  --speculative-dflash-block-size 8 \
  --served-model-name Qwen3.8-27B-FP8 \
  --reasoning-parser qwen3 --tool-call-parser qwen3_coder \
  --trust-remote-code

7.2 客户端接入（OpenAI 兼容）

# base_url 换成实际节点地址（内网示例 192.0.2.1，占位）
export OPENAI_API_KEY="not-needed"
export OPENAI_BASE_URL="http://192.0.2.1:8000/v1"

from openai import OpenAI
c = OpenAI()  # 自动读上面两个环境变量
r = c.chat.completions.create(
    model="Qwen3.8-27B-FP8",
    messages=[{"role": "user", "content": "解释什么是 GPU Roofline 模型"}],
    temperature=0.6, max_tokens=1024,
)
print(r.choices[0].message.content)          # 正文
print(r.choices[0].message.reasoning_content)  # 思维链（Qwen3 系）

同样支持 Anthropic /v1/messages（Claude Code 直连）。鉴权未开（内网可信），需要时加 --api-key。推理参数建议：temperature=0.6（对话/代码）、0（抽取/分类确定性），交互场景开 stream=true。

7.3 数据口径与来源

• 所有吞吐为代码 prompt / 256 token 输出的聚合值；单流 C1 为 5 次均值。投机解码吞吐随 prompt 领域波动（见 §3.1 口径提醒）。
• 「无投机基线 46.6」来自单流 512-token 测量；并发矩阵基线 46/176/632 为 256-token 同口径。
• 主服务实测复核值（2026-08-20）：C1 234.4 / C4 1653 / C16 3479，与文档值同波动带。
• 本文已去敏：内网 IP 以 192.0.2.1（RFC 5737 保留段）占位，部署路径以 ~/sglang 示意，主机名 / 用户名不出现。模型仓库（Qwen/Qwen3.8-27B-FP8、RadixArk/Qwen3.8-27B-DSpark、z-lab/Qwen3.8-27B-DFlash2）与 hfd.sh gist 均为公开来源。