Qwen3.8-27B：vLLM 与 SGLang DFlash2 性能对比

本文记录一次内部 8 卡 RTX 3090 服务器上的可复跑对比测试。比较对象为同一份 Qwen3.8-27B 主模型权重：一侧使用 vLLM，另一侧使用 SGLang + DFlash2 投机解码。本文仅描述测试环境、方法和结果，不包含服务器地址、账号、密钥或业务数据。

1. 测试目的

本次测试关注三个问题：

1. 在两个 NUMA 节点分别绑定 CPU 与内存偏好后，两套服务是否能稳定运行。
2. 同一组确定性短题下，DFlash2 路径是否造成可见的正确性变化。
3. 单请求和 4 并发场景下，两条推理路径的端到端性能差异是多少。

2. 测试环境与服务配置

2.1 硬件与 NUMA 拓扑

• GPU：8 × NVIDIA GeForce RTX 3090，单卡 24GB。
• CPU：2 个 NUMA 节点，64 个逻辑 CPU。
• GPU0-3 位于 NUMA0；GPU4-7 位于 NUMA1。

为避免跨 NUMA 调度，本次复测前增加了 systemd 级亲和性配置：

服务	GPU	CPUAffinity	NUMAPolicy / NUMAMask
vLLM	GPU0-3	0-15 32-47	preferred / 0
SGLang + DFlash2	GPU4-7	16-31 48-63	preferred / 1

preferred 表示优先从本地 NUMA 节点分配内存；节点内存紧张时允许回退，避免严格绑定导致服务不可用。实际进程的 /proc/<pid>/numa_maps 分别显示 prefer:0 和 prefer:1。

2.2 推理服务

项目	服务 A：vLLM	服务 B：SGLang + DFlash2
主模型	Qwen3.8-27B	Qwen3.8-27B
草稿模型	无	Qwen3.8-27B-DFlash2
GPU / TP	GPU0-3 / TP=4	GPU4-7 / TP=4
数据类型	FP16	BF16
上下文配置	262144	262144
并发配置	4	4
KV/缓存	Prefix Cache	DFlash2 草稿 KV + Unified Radix Cache
CUDA Graph	由 vLLM 管理	decode/verify 图启用，最大 batch 配置 24；prefill 图关闭

需要注意：SGLang 服务虽然配置了 262144 的上下文长度，但 BF16 KV token 池当前实际为约 197295。本文没有进行 256K 长上下文压测，也不应将本文结果外推为 256K 能力对比。

3. 测试方法

3.1 能力测试

能力测试共 20 题，采用相同的 system prompt、temperature=0、max_tokens=128 和 enable_thinking=false。题目顺序执行，使用规则匹配进行自动判分，同时保留原始输出供人工复核。

编号	类别	测试点	期望答案
01	算术	17×23+19	410
02	算术	240 的 15%	36
03	算术	3/4 + 5/6	19/12
04	数列	2,6,12,20,30 的下一项	42
05	数制	二进制 101101 转十进制	45
06	位运算	37 XOR 12	41
07	程序	Python 平方和	55
08	程序	\\d+ 的匹配次数	3
09	程序	列表偶数位置过滤	['b','d']
10	日期	2024-02-29 是星期几	星期四
11	逻辑	三段论结论是否可推出	不能推出
12	逻辑	回文判断	是
13	中文	字符串逆序	前向敢勇
14	中文	按拼音排序	李四、王五、张三
15	格式	ISO 日期格式化	2026年8月22日
16	数据	CSV 分数列求和	40
17	数据	JSON 键排序	{"a":1,"b":2}
18	SQL	指定区域金额求和	26
19	阅读	库存出入库计算	36
20	单位	千米与米换算	3250

3.2 性能测试

• 在服务器本机执行，排除客户端网络传输影响。
• 先执行一次预热，预热不计入统计。
• 单请求：相同生成提示词，执行 3 次，max_tokens=128。
• 并发：4 个相同请求同时发起，单请求 max_tokens=96。
• 指标：端到端耗时和 completion_tokens / 端到端耗时。该指标包含 prefill 与生成，不等同于流式 TTFT 或纯 decode 吞吐。

4. 复测结果

4.1 能力结果

服务	正确数	正确率	错题
vLLM	18 / 20	90.0%	06、09
SGLang + DFlash2	18 / 20	90.0%	06、09

两端 20 题的最终输出完全一致。共同错误如下：

1. 37 XOR 12 两端均回答 43，正确答案为 41。
2. 列表偶数位置过滤两端均回答 ['a', 'c']，正确答案为 ['b', 'd']。

这符合预期：两侧使用同一主模型，DFlash2 的定位是投机解码加速，而不是修改模型知识或推理能力。本题集没有观察到 DFlash2 带来的质量损失，也没有观察到质量提升。

4.2 性能结果

指标	vLLM	SGLang + DFlash2	对比
单请求平均耗时	2.807s	0.650s	SGLang 快 76.8%
单请求端到端生成速率	45.60 tok/s	196.86 tok/s	4.32×
4 并发总完成时间	2.626s	0.873s	约 3.01×
4 并发端到端总吞吐	146.25 tok/s	439.62 tok/s	3.01×
4 并发成功数	4 / 4	4 / 4	均成功

NUMA 配置后的复测与配置前短基准的差异在约 1% 以内，未出现性能回退或稳定性问题。由于测试量较小、缓存已经预热，不能据此单独量化 NUMA 带来的收益；NUMA 配置的主要价值是保证 CPU 线程和主机侧内存优先靠近本地 GPU PCIe 根节点，降低跨节点访问风险。

5. 结果解读

在本次服务器、本次模型、固定并发 4 和短输出负载下，SGLang + DFlash2 具备明显的端到端性能优势，适合优先承接短到中等上下文的高频生成请求。

不过，不能把全部性能差异简单归因于 DFlash2。两套服务同时存在以下实现差异：

• vLLM 与 SGLang 的调度、缓存和内核实现不同；
• 一侧使用 FP16，另一侧使用 BF16；
• SGLang 侧启用了 DFlash2 草稿模型与受限 CUDA Graph；
• 两端的 KV Cache 管理策略不同。

因此，本文结论应理解为“当前两条生产部署路径的端到端对比”，而不是单独测得 DFlash2 的纯净增益。

6. 使用建议

1. 对短到中等上下文、并发请求较多的场景，优先选择 SGLang + DFlash2 服务。
2. 对严格要求单请求 256K 上下文的场景，当前应优先选择 vLLM 服务；SGLang 侧需要完成 FP8 KV Cache 或其他容量方案的长上下文质量验证后再切换。
3. 对工具调用场景，需单独复测两端的 tool_choice:auto、并行工具调用和结构化输出；本文未覆盖该项。
4. 对业务上线决策，应继续补充真实业务提示词、长输入、不同输出长度、流式 TTFT、峰值并发和持续压测。

7. 复现方式

测试脚本使用 Python 标准库，无额外第三方依赖。将脚本放到能够访问两个 OpenAI 兼容服务的主机后执行：

python3 compare_qwen_ports.py --host 127.0.0.1 --output qwen_port_comparison.json

脚本会生成逐题输出、判分结果和性能原始数据。发布文章时建议附上脱敏后的配置和汇总表，不要公开内网地址、账号、密钥或完整日志。

8. 小结

在 NUMA 亲和性已正确配置的前提下，两项服务均稳定运行。本次 20 题能力测试中，两端正确率均为 90.0%，输出完全一致；性能测试中，SGLang + DFlash2 的单请求端到端速率约为 vLLM 的 4.32 倍，4 并发总吞吐约为 3.01 倍。

测试日期：2026-08-22。