SGLang 搭配 TileLang，在 ROCm 上跑出大模型推理新速度

2600_96323192

320人浏览 · 2026-06-30 16:32:35

2600_96323192 · 2026-06-30 16:32:35 发布

打破带宽瓶颈：SGLang 与 TileLang 的协同优化

在 AMD Instinct GPU 上部署大模型服务，很多算法工程师的第一反应往往是关注“能不能跑通”。随着 ROCm 生态的成熟，基础运行早已不是难题，真正的挑战在于如何榨干硬件性能，尤其是在高并发推理场景下。对于追求极致吞吐量的团队来说，单纯依赖通用的推理框架往往不够，我们需要更精细的组合拳：SGLang 负责调度层面的连续批处理，而 TileLang 则深入到底层算子，解决特定架构下的带宽瓶颈。

这套组合的核心逻辑非常清晰：SGLang 通过高效的内存管理让 GPU“忙起来”，TileLang 则确保每个计算单元都“跑得对”。特别是在处理长序列或高负载请求时，两者的协同效应能带来显著的性能跃升。

SGLang：构建高吞吐的推理基座

SGLang 之所以在非 NVIDIA 环境下备受青睐，关键在于其独特的 Continuous Batching（连续批处理） 机制。传统的静态批处理需要等待整个批次完成才能接纳新请求，这导致 GPU 在请求长短不一时出现大量空闲气泡。SGLang 打破了这一限制，它允许在迭代过程中动态地加入新请求或移除已完成的请求，从而极大地提升了显存利用率和计算密度。

在 AMD Instinct 系列显卡上部署 SGLang，首要任务是确保后端正确对接 ROCm。启动服务时，需明确指定后端参数以调用 HIP 运行时。例如，在配置启动脚本时，应关注 KV Cache 的管理策略。针对 MI300X 等大显存卡，可以适当调大 --mem-fraction-static 参数，预分配更多显存用于缓存上下文，减少运行时的内存碎片整理开销。

此外，SGLang 对量化格式的支持也是提升吞吐的关键。在显存受限的场景下，加载 FP8 或 INT8 量化后的模型权重，不仅能降低显存占用，还能利用 AMD GPU 的矩阵核心加速计算。实际测试中，开启量化后，在保持精度损失可控的前提下，吞吐量往往能有 20% 以上的提升。不过，量化模型的适配需要底层算子的支持，这就引出了下一个关键环节。

TileLang：算子级的深度定制

通用框架虽然解决了大部分问题，但在面对 AMD 独特的硬件架构时，默认的算子实现往往无法发挥全部潜力。AMD GPU 的计算单元组织方式与 NVIDIA 不同，其核心调度单位是 Wavefront（类似 CUDA 的 Warp），且拥有独特的本地数据共享（LDS）层级。如果直接沿用从 CUDA 迁移过来的算子，很容易出现线程束发散或内存访问不合并的问题，导致显存带宽利用率低下。

这时，TileLang 的作用就凸显出来了。作为一种领域特定语言（DSL），TileLang 允许开发者以高层次的描述定义矩阵分块（Tiling）策略和数据流动方式，并将其编译为针对特定 GPU 架构高度优化的内核代码。

在实际优化过程中，最典型的案例莫过于 Attention 机制 的调优。我们曾遇到一个具体场景：在复现某大模型的注意力计算时，发现尽管 GPU 利用率显示正常，但实际吞吐量始终上不去。通过 rocprof 进行性能分析，发现瓶颈在于全局内存访问延迟过高，带宽并未跑满。

问题的根源在于 Block Size 的配置与当前 GPU 的 Wavefront 大小不匹配。默认的算子可能沿用了 NVIDIA 的线程块配置（如 128 或 256），这在 AMD 架构上会导致部分线程闲置或频繁的 LDS 银行冲突（Bank Conflict）。

利用 TileLang，我们重新设计了分块策略：

对齐 Wavefront：将线程块大小调整为 AMD CDNA 架构推荐的倍数（如 64 的倍数），确保每个 Wavefront 都能满载运行。
优化 LDS 布局：通过 TileLang 显式控制数据在共享内存中的排布，减少全局内存的重复读取。
架构特化：针对 gfx942（MI300 系列）增加特化分支，利用其最新的矩阵指令集。

经过这一系列调整，我们将该算子的执行效率提升了近 30%。这个案例充分说明，在非 NVIDIA 环境下，算子级的微优化是突破性能天花板的关键。你不需要成为汇编专家，只要理解硬件的基本调度原理，利用 TileLang 提供的抽象能力，就能快速产出高效内核。

社区协作：从发现问题到解决问题

优化过程并非闭门造车，开源社区的协作机制在其中扮演了重要角色。当我们遇到上述带宽瓶颈时，最初也尝试过独自调试，但进展缓慢。随后，我们在 GitHub 上向 SGLang 和 TileLang 项目提交了详细的 Issue，附上了复现步骤和 rocprof 的性能热点图。

社区的响应速度出乎意料。维护者迅速指出了 Block Size 配置的问题，并引导我们使用 TileLang 的分块原语进行调整。这种互动不仅解决了具体问题，更让我们深入理解了 HIP 编译器如何进行指令调度，以及为什么某些内存访问模式会导致性能下降。最终，我们将优化后的代码提交为 PR，被合并入主分支，成为了社区共建的一部分。

对于算法工程师而言，参与这种协作是提升技术深度的绝佳途径。你不需要从头造轮子，只需聚焦于特定场景的性能痛点，提供清晰的数据和复现路径，就能与全球开发者共同推动生态进步。

实战配置与性能验证建议

在具体落地时，建议关注以下几个配置维度和验证指标：

启动参数建议：
- --block-size: 根据模型特性调整，通常 16 或 32 较为通用，但在长序列场景下可尝试更大值以配合 TileLang 优化。
- --sched-policy: 选择 fcfs 或 lpm，根据业务请求分布测试哪种策略延迟更低。
- --quantization: 若显存紧张，务必开启 fp8 或 int8，并确认底层算子已适配。
性能对比维度：
- 吞吐量（Tokens/s）：在不同并发数（Batch Size）下测试，观察 SGLang 连续批处理带来的增益。
- 首字延迟（TTFT）：重点关注长上下文场景下的表现，验证 TileLang 优化后的 Attention 算子是否降低了预处理时间。
- 显存带宽利用率：使用 rocprof 监控，确认优化后是否接近理论峰值。