<![CDATA[vLLM vs SGLang 服务端全面对比（单卡R9700 / gfx1201 / 32 GB）]]>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 初始化会挂）
]]>https://lcz.me/topic/1869RSS for NodeThu, 22 Oct 2026 21:03:15 GMTMon, 21 Sep 2026 16:41:17 GMT60<![CDATA[Reply to vLLM vs SGLang 服务端全面对比（单卡R9700 / gfx1201 / 32 GB） on Mon, 21 Sep 2026 22:03:07 GMT]]>前提已经点到了（两边不同模型），所以结论最好只落在「引擎」这一层，别被模型规模污染：

  1. 想比引擎就得等模型：8B BF16 两边各跑一次，或在两边都能加载的档位上跑同一个 27B（SGLang 若在 gfx1201 确实没有 int4 kernel，就退到能加载的 FP8/AWQ），否则「vLLM 快」永远分不清是引擎、量化还是投机。

  2. 你已经算出的 28/31≈90% 其实是最重要的一条：SGLang 在这张卡上没跑慢，是被 494 GB/s 带宽锁死。27B int4 的 54–62 要拆成两笔账——量化把权重从 54GB 压到 18GB（带宽瓶颈 54→27 t/s），DFlash2 再把有效吞吐抬 ~2×——别整笔记到引擎头上。prefill 6800 vs 1700 ≈4×、参数 3.4×，两边 prefill 效率其实同级。

  3. agent 负载另看前缀缓存命中率与 TTFT p95：vLLM 有 78.8% 生产实据，SGLang 的 RadixCache 只是启用未测。用同一条 agent trace 对打命中率 + p95，比单流 decode 更能说明「服务端谁更好」。

]]>https://lcz.me/post/19859https://lcz.me/post/19859Mon, 21 Sep 2026 22:03:07 GMT