别再问 AMD 显卡能不能跑 AI，SGLang 加 TileLang 组合拳给你答案

2026/6/24 2:25:20

用实测数据打破偏见：SGLang + TileLang 在 AMD 显卡上的硬核表现

“AMD 显卡能不能跑大模型？”这几乎成了技术社区里的“月经贴”。每次有人提起 ROCm，评论区总少不了几句“驱动不稳定”、“算子缺失”或者“只能跑跑 Demo"的质疑。作为长期在一线折腾 GPU 算力的开发者，我深知这种顾虑的来源：早期的生态确实不够完善，踩坑是常态。但如果你还停留在两年前的印象里，那真的错过了太多。

今天不聊虚的理论，直接上干货。我最近在一台搭载 AMD Instinct MI300X 的服务器上，部署了SGLang推理框架，并配合TileLang对关键算子进行了深度定制。结果出乎意料地丝滑：不仅复杂的大模型推理跑得飞起，在高并发压力测试下也稳如老狗。这篇文章就带大家复盘整个实战过程，看看这套“组合拳”是如何粉碎偏见的。

拒绝 PPT 造车：SGLang 原生适配的真实体验

很多质疑者认为 AMD 显卡跑大模型需要大量的“魔改”代码，甚至要手动重写底层内核。但在 ROCm 7.x 时代，情况已经发生了根本性逆转。以 SGLang 为例，这个以高效显存管理和灵活编程模型著称的框架，现在已经实现了了对 ROCm 后端的原生支持。

在我的测试环境中，部署过程异常顺畅。不需要像以前那样到处找非官方的 Patch，也不需要修改源码去硬凑兼容。只需正确设置PYTORCH_ROCM_ARCH环境变量（针对 MI300X 设为gfx942），SGLang 就能自动识别硬件架构并加载对应的优化后端。

为了验证其处理复杂任务的能力，我特意选择了一个长上下文场景：让模型处理一篇长达 32k token 的技术文档并进行多轮问答。SGLang 核心的RadixAttention机制在这里发挥了巨大作用。它通过复用 KV Cache 树结构，极大地减少了重复计算的开销。在实测中，首字延迟（TTFT）控制在毫秒级，生成速度稳定且流畅。如果你看过当时的终端录屏，会发现输出节奏紧凑，完全没有那种“卡顿一下、吐几个字”的廉价感。这证明了 SGLang 在 AMD 架构上不仅仅是“能跑”，而是已经具备了生产级的可用性。

TileLang 加持：自定义算子带来的性能飞跃

当然，光靠框架的原生支持还不够，要想彻底榨干硬件性能，必须深入到底层算子。这也是很多人对 AMD 望而却步的地方：担心缺少针对特定模型的优化算子。这时候，TileLang就成了破局的关键。

TileLang 是一种专为张量程序设计的语言，它能让我们以更高级的方式编写和编译 GPU 算子。在测试初期，我发现默认的注意力机制在特定 Batch Size 下，显存带宽利用率并没有达到理论峰值。与其等待官方更新，不如自己动手优化。

利用 TileLang，我快速编写了一个针对 MI300X 内存层级特性的定制 Kernel。通过调整分块策略（Tiling Strategy）和优化寄存器分配，我们成功减少了全局内存的访问次数。这个过程并不像我想象中那么痛苦，TileLang 的抽象层次很高，让我能专注于算法逻辑而非繁琐的汇编指令。

重新编译并替换算子后，性能提升立竿见影。在相同的并发请求下，吞吐量（Tokens/s）提升了近30%。这不是实验室里的理想数据，而是在真实负载下的实测结果。这一举动有力地证明了：AMD 生态并非封闭的黑盒，开发者完全有能力通过开源工具链，针对具体业务场景进行深度调优，甚至做到比通用方案更高效。

高并发压测：稳定性才是硬道理

跑通 Demo 容易，扛住流量才是本事。为了检验这套方案的稳定性，我使用压测工具模拟了高并发场景：持续发送混合长度的请求，涵盖短问答和长文本生成，并发数从 50 逐步攀升至 200。

在整个压测过程中，系统表现令人印象深刻。

显存管理稳健：即便在并发峰值期，显存占用也始终保持在预设阈值内，没有出现常见的 OOM（内存溢出）崩溃。SGLang 的动态显存调度机制与 ROCm 的驱动配合得非常默契。
延迟抖动极小：监控图表显示，P99 延迟曲线非常平滑，没有因为垃圾回收或调度问题出现剧烈的毛刺。
长时间运行无泄漏：连续运行 12 小时后，服务依然稳定，资源占用无明显增长。

这些数据直接回击了关于"AMD 驱动不稳定”的旧论调。事实上，只要工具链搭配得当，ROCm 栈的鲁棒性完全不输其他平台。对于企业级应用而言，这种确定性比单纯的峰值性能更重要。