vLLM vs SGLang 服务端全面对比（R9700 / gfx1201 / 32 GB）

---

核心前提（必须先说明）：两者跑的不是同一个模型。

• vLLM 跑的是生产模型 Qwen3.8-27B（GPTQ int4 W4A16，18 GB）+ DFlash2 int4 draft。
• SGLang 跑的是官方示例 Meta-Llama-3.1-8B（BF16，16 GB）。
  硬约束：SGLang v0.5.15 在 gfx1201 上没有 int4 内核（源码级证据见可行性评估 §4），27B int4 模型在 SGLang 上根本加载不了；而 27B 若用 BF16 需 54 GB，超出 32 GB 显存。所以两者只能各跑各的模型。下文所有对比都在这个前提下展开。

---

1. 部署与技术栈对比

维度	vLLM（vllm102）	SGLang（sgl-test）
版本	vLLM 0.27.1 + radiance 0.9.3 fork（stilldeadcode/vllm-radiance:0.9.3）	SGLang 0.5.15（官方 rocm/sgl-dev:v0.5.15.post1-...-rocm10.0.0）
模型	Qwen3.8-27B，GPTQ W4A16 int4（17.93 GB）	Meta-Llama-3.1-8B，BF16（16 GB，官方示例/基础模型）
量化	int4（radiance fork 手写 RDNA4 W4A16 kernel）	无（BF16）
注意力后端	R4D（为 gfx1201 手写的 attention/GDN/瘦 GEMM kernel）	Triton（AITER 被官方文档强制禁用）
投机解码	DFlash2 int4 draft（1.19 GB），K=4，probabilistic 采样	无（本次未开）
镜像来源	第三方 fork	AMD 官方兼容性矩阵背书
部署方式	手工 docker run + warmup_vllm.sh（cron @reboot 自愈）	官方文档 docker run（无自愈脚本）
鉴权	有 API key	无（默认开放）

---

2. 性能对比（实测）

指标	vLLM（27B int4）	SGLang（8B BF16）	说明
单流 decode	54–62 tok/s（文档稳态，今日测）；重启后首请求 40.6 tok/s	≈28 tok/s	见下方「归一化解读」
prefill	≈1700–1820 tok/s（27B，2.4k 提示）	≈6800 tok/s（8B，1803 提示）	模型规模差 ~3.4×
TTFT	0.11 s（49 tok）/ 1.40 s（2412 tok）	0.266 s（1803 tok）	—
投机接受率	DFlash2 int4：acc/step≈1.54，~20.6 steps/s；MTP 各位置 72%→23%	无投机	vLLM 靠投机突破带宽上限
前缀缓存命中	78.8%（10.5 h 生命周期，agent 负载）	RadixCache 已启用，未实测命中率	vLLM 有生产实据

归一化解读（关键）

• SGLang 8B BF16 decode 28 tok/s 已接近硬件上限：16 GB 权重 ÷ R9700 实测带宽 494 GB/s ≈ 31 tok/s 理论上限，实际 28 = 理论值的 ~90%。也就是说 SGLang 在这张卡上「没有跑慢」，是被内存带宽锁死。
• vLLM 27B int4 能到 54–62 tok/s，是因为两件 SGLang 没有的东西：
  1. int4 量化把权重从 54 GB（BF16）压到 18 GB，内存带宽瓶颈降到 ~27 tok/s；
  2. DFlash2 投机解码一次并行 forward 提 4 个 token，把有效吞吐再抬到 54–62（≈2× 带宽上限）。
• 所以「vLLM 快」的本质是量化 + 投机解码 + 定制 kernel这三板斧，而不是 SGLang 本身慢。SGLang 在相同内存带宽下已做到 ~90% 效率。

---

3. 稳定性对比

参数	vLLM	SGLang
自愈能力	warmup_vllm.sh cron @reboot，容器停了自动 docker start + 6 种形状预热	无（手动 docker start）
启动/预热时间	暖启动 ~30–60 s（/cache/vllm 共享挂载，compiled graph 直接加载，实测 3.3–5.4 s）	️ 首启 ~5 min（Triton 对 gfx1201 编译）；后续会快
显存压力	️ 97%（31.1/32 GB，很紧，单卡独占）	️ 93%（模型 15 + KV 10.9 GB）
KV 缓存	fp8（省显存，6.46–8.5 GB）	bf16（10.94 GB，占更多）
并发设计	MAXSEQS=2（限并发、保单请求质量）	默认 max_running_requests=2048（灵活，但受显存约束实际并发有限）
鉴权	API key 保护（局域网暴露更安全）	默认无鉴权（若对局域网开放需自行加）
长稳运行	有 10.5 h 生命周期统计、0 抢占、RAS 干净	️ 仅短时验证（~10 min），无长稳数据
已知风险	依赖第三方 fork，升级/迁移受制于 radiance 维护节奏	R9700 官方已知问题：AITER 禁用、部分 MoE/Qwen3-ASR 模型可能不对

---

4. 功能特性对比

特性	vLLM	SGLang	谁更强
前缀缓存	block 级 prefix caching（实测 78.8% 命中）	RadixCache 树形缓存（更细粒度，同前缀共享更高效）	SGLang（理论上），vLLM（有生产实据）
结构化输出	支持（guided decoding）	原生强项（JSON schema / grammar / constrained）	SGLang
多 agent / 工具调用	支持（tool-call-parser qwen3_xml）	服务形态更适合多 agent 编排、多轮工具调用	各有所长
投机解码生态	DFlash2 / MTP / Eagle 全支持（本卡已用 DFlash2）	支持 MTP/Eagle 等，但本卡无 radiance 定制	vLLM
量化生态	本卡 int4（radiance fork 独占）	FP8/AWQ/MXFP4 等（但 MXFP4 门槛不认 gfx1201，int4 无）	vLLM（本卡）
官方 ROCm 维护	第三方 fork	AMD 官方镜像 + 兼容性矩阵背书，持续维护	SGLang
长上下文 / 大模型（MoE/MLA）	成熟	DeepSeek 系 MoE/MLA 优化是其强项	SGLang（大集群场景）

---

5. 优缺点总结

vLLM（当前生产）

优点

1. 本卡上唯一能跑 27B 生产模型的路径（radiance fork 的 RDNA4 int4 kernel + R4D 注意力 + DFlash2 投机解码）。
2. 性能深度调优，decode 54–62 tok/s（27B），远超 SGLang 在本卡能跑的任何模型。
3. 生产化程度高：API key、自愈脚本、预热、编译缓存、10.5 h 稳定运行实据、前缀缓存 78.8% 命中。

缺点

1. 依赖第三方 fork（stilldeadcode/vllm-radiance），升级/迁移/长期维护受制于人，不是官方路线。
2. 显存 97% 打满，无余量；并发被压到 MAXSEQS=2。
3. 定制 kernel + 覆盖层（rdna_hybrid_w4a16.py、qwen3_dflash.py）是「黑魔法」，跨版本脆弱。

SGLang（本次部署）

优点

1. AMD 官方镜像 + 兼容性矩阵背书，路线正规、持续维护，是「官方钦定」的推理栈。
2. 功能面更现代：RadixCache、结构化输出、多 agent/工具调用服务形态、DeepSeek 系 MoE/MLA 优化。
3. 部署即开箱（官方一条 docker run），无自写 kernel 负担。
4. 在硬件上限内效率不低（decode 达带宽上限 ~90%、prefill 6800 tok/s）。

缺点

1. 本卡上跑不了 27B 生产模型（缺 int4 内核，MXFP4 也不认 gfx1201）——这是硬伤。
2. 性能被 AITER 禁用 + Triton 注意力锁死（R9700 官方已知问题），decode 只能到带宽上限。
3. 无自愈脚本、无鉴权、无长稳验证——要当生产用还需补生产化工程。
4. 官方示例是基础模型（无 chat_template），对话需换 Instruct 版。

---

单卡成功案例Puget Systems 官方测评（主流背书）（1× R9700，vLLM FP16）

模型	单用户吞吐
Qwen2.5 3B	53.3 tok/s
DeepSeek-R1-Distill-Llama-8B	34.5 tok/s
Llama 3.1 8B	29.1 tok/s
Qwen3 8B	27.7 tok/s

关键交叉验证：Puget 的 Llama 3.1 8B = 29.1 tok/s（vLLM），本机实测 SGLang 同一模型 = 28 tok/s。几乎一样——证实 8B BF16/FP16 上 SGLang 与 vLLM 引擎同量级，都被内存带宽锁死。

6. 建议

一句话结论：生产 27B 继续用 vLLM，SGLang 定位为「官方路线的观察点 + 小模型/agent 试验台」，两者不互斥。

具体建议

1. 27B 生产服务：维持 vLLM（vllm102），不要迁 SGLang。
   理由：SGLang v0.5.15 在本卡根本跑不了 27B int4（缺内核），且即便跑小模型 decode 也只有 28 tok/s，无法替代 vLLM 的 54–62 tok/s。迁移不仅无收益，反而掉档。

2. SGLang 的合理用途（如果想继续用）：

   • 小模型（≤8B）+ agent 工具调用 / 结构化输出 / 多轮短上下文场景：这正是 SGLang 的 RadixCache + structured output + 多 agent 服务形态强项，也是 vLLM 当前 MAXSEQS=2、97% 显存所服务不到的低延迟轻负载。
   • 同卡时间片切换：需先 docker stop vllm102 再 docker start sgl-test（32 GB 无法共存），适合夜间/维护窗口，不适合白天生产时段。

3. 如果要把 SGLang 当第二服务长期跑，需补三件事（否则别上生产）：

   • 换 NousResearch/Meta-Llama-3.1-8B-Instruct（补 chat_template，让 /v1/chat/completions 可用）；
   • 加 --api-key 鉴权（当前无鉴权直接暴露 0.0.0.0:30000）；
   • 补 warmup 自愈脚本（对标 vLLM 的 warmup_vllm.sh）。

4. 触发重评的观察点（何时结论会变）：

   • AMD/SGLang 为 gfx1201 补 int4 或 MXFP4 内核 → 27B 4-bit 路径打开，届时 SGLang 才具备替代 vLLM 的资格，值得重做 §2 的性能对比；
   • R9700 的 AITER 已知问题被修复 → SGLang 注意力从 Triton 切回 AITER，decode 有望显著提速；
   • radiance fork 停更/失修 → 若 vLLM 定制栈无人维护，SGLang 的官方路线价值上升。

5. 想得到真正「同模型」的公平基准：可在同一维护窗口，让两者各跑同一个 8B BF16 模型（vLLM 也能跑 8B BF16），测同模型 decode/prefill/并发，才能剥离「模型规模」变量做纯引擎对比。

---

7. 对单卡 + 27B 场景的结论

之前结论（基于 v0.5.15）	修正后准确版本
SGLang 跑不了 27B	官方 v0.5.15 跑不了；但 v0.5.20 + 70 补丁（社区）+ 2 卡 + FP8/AWQ 能跑，22.5 tok/s
SGLang 引擎弱	同精度下 SGLang 不弱——27B FP8 单用户，SGLang 22.5 > 原版 vLLM 15.88
2 卡才能"生产"	1 卡能生产（int4 27B 或 8B）；2 卡只是"27B 高精度"的门槛

对「单卡 + 27B 生产」，结论不变甚至更强：

vLLM（radiance fork，int4 + DFlash2 投机解码，单卡 54–62 tok/s）仍是单卡最优：

• 它用 int4（18GB）让 27B 塞进单卡，靠 DFlash2 投机解码拉到 54–62 tok/s；
• SGLang 27B 要 2 卡 + 补丁 + FP8 才 22.5 tok/s；原版 vLLM 27B FP8 也要 2 卡才 15.88 tok/s；
• 等于用 1 张卡 打出别人 2 张卡 + MTP 才有的水平（62.75 tok/s）。

---

8. 明确结论

• "单流 decode 在 RDNA4 上是内存带宽受限的"
• "单卡 R9700 能跑 8B FP16；27B 用 Q4_K_M（~17.6GB）单卡就能装下；只有 27B 的 FP8/BF16 高精度才需要两张卡"
• 双卡多 GPU 必须裸机运行（KVM/VFIO 虚拟化下 RCCL 初始化会挂）

---