推理框架怎么选，vLLM 与 SGLang 在 AMD 上的表现

2600_96323197

69人浏览 · 2026-06-26 19:27:30

2600_96323197 · 2026-06-26 19:27:30 发布

为什么在 AMD 上选推理框架成了新难题

最近手头正好有一批 AMD Instinct MI300X 的资源，想着把大模型推理服务搭起来。以前在 NVIDIA 平台上，vLLM 几乎是默认选项，但在 AMD ROCm 生态里，情况变得有趣了起来。除了老牌劲旅 vLLM，新兴的 SGLang 也开始正式支持 ROCm 后端。很多开发者在选型时容易纠结：是求稳选 vLLM，还是为了长上下文和复杂逻辑选 SGLang？这篇文章不聊虚的理论，直接基于我在 ROCm 7.x 环境下的实测经历，聊聊这两个框架在 AMD 显卡上的真实表现和落地细节。

vLLM：生产环境的“定海神针”

如果你现在的目标很明确——就是要快速上线一个高并发、低延迟的 API 服务，那 vLLM 依然是首选。在 ROCm 7.x 版本中，vLLM 的适配已经非常成熟，几乎可以说是“原生级”的支持。

最核心的优势在于它的 PagedAttention 机制。在大模型推理中，显存管理是命门。vLLM 通过将 KV Cache 分页存储，极大地减少了显存碎片。我在 MI300X 上部署 Llama 3 70B 时发现，只要将 --gpu-memory-utilization 参数设置在 0.90 到 0.92 之间，就能稳稳跑满显存而不爆 OOM（内存溢出）。相比之下，其他框架往往需要预留更多冗余，这在昂贵的 HBM 显存上是一种浪费。

安装过程相对顺滑，但有一个坑必须注意：编译时必须指定正确的架构代码。对于 MI300 系列，环境变量 PYTORCH_ROCM_ARCH 必须设为 gfx942。如果漏了这一步，运行时大概率会报 illegal instruction 错误。一旦环境配好，vLLM 的稳定性令人放心，特别是在多卡张量并行（Tensor Parallelism）场景下，它利用 RCCL（ROCm 版的 NCCL）进行通信，吞吐量的线性加速比表现非常出色，非常适合生产环境的大流量场景。

SGLang：长上下文与复杂逻辑的利器

如果说 vLLM 是稳健的“工程派”，那 SGLang 更像是灵活的“研发派”。最近在尝试一些复杂的提示词工程（Prompt Engineering）和长上下文任务时，SGLang 给了我不少惊喜。

SGLang 的核心亮点在于 RadixAttention 算法。在处理多轮对话或需要复用前缀上下文的场景时，它能构建一棵前缀树，自动缓存和复用 KV Cache。这意味着，当你让模型基于同一段长文档回答不同问题时，SGLang 不需要重复计算前面的部分，首字延迟（TTFT）显著降低。我在测试一个 32k 上下文的法律文档问答任务时，SGLang 的响应速度明显优于传统静态批处理框架。

不过，在 AMD 平台上使用 SGLang 目前还属于“早期采用者”阶段。虽然官方已宣布支持 ROCm 后端，但在算子覆盖度上还不如 vLLM 全面。特别是在 BF16 精度下，某些自定义算子可能会触发 fallback 到高精度计算，导致性能波动。如果你主要做原型验证、科研探索，或者业务强依赖复杂的控制流（如循环生成、条件分支），SGLang 的编程模型会灵活得多；但如果是追求极致稳定的线上服务，可能还需要再观察一下社区的修复进度。

实战对比：安装难度与算子兼容性

为了让大家更直观地感受两者的差异，我整理了一份基于 ROCm 7.x 的对比清单：

安装复杂度：
- vLLM：中等。主要通过 pip install 或源码编译。关键在于 Triton 编译器版本的匹配，以及上述提到的 PYTORCH_ROCM_ARCH 设置。社区文档丰富，报错容易搜到解决方案。
- SGLang：较高。除了基础依赖，还需要额外配置其特定的后端接口。在 AMD 环境下，偶尔会遇到 HIP 内核编译失败的情况，需要手动修补部分算子代码或等待社区更新。
显存管理：
- vLLM：基于 Block Table 的静态/动态混合管理，碎片率极低，适合固定批大小的持续服务。
- SGLang：基于 Radix Tree 的动态管理，适合变长序列和前缀复用，但在极高并发下，树结构的维护开销可能会略微增加延迟。
算子覆盖：
- vLLM：覆盖了主流模型（Llama, Qwen, Yi 等）的绝大多数算子，FlashAttention 在 ROCm 上优化良好。
- SGLang：核心算子支持不错，但对于一些较新的模型架构或特殊的量化格式（如 FP8 在某些特定层），可能会出现不支持的情况，需要回退到慢速路径。