执行摘要
本PR通过将CuteDSL KDA内核的导入从顶层移至CUDA条件检查内部，修复了AMD/ROCm平台因加载CUDA专用模块而导致的启动崩溃问题。这是一个针对跨平台兼容性的关键修复，确保了使用线性注意力的模型（如Qwen3.5）在非CUDA硬件上可正常启动，对异构部署场景有直接积极影响。
功能与动机
问题根源：PR #21203引入了CuteDSL KDA解码内核支持，但在kda_backend.py中添加了顶层导入语句：
from sglang.srt.layers.attention.linear.kernels.kda_cutedsl import CuteDSLKDAKernel
该导入链会触发cuda.bindings.driver模块的加载，而该模块仅在CUDA平台存在。导致AMD/ROCm用户在启动任何使用线性注意力的模型时立即遇到ModuleNotFoundError: No module named 'cuda'异常。
修复目标：允许AMD/ROCm平台正常启动服务器，同时保持CUDA平台原有功能不变。
实现拆解
仅修改了python/sglang/srt/layers/attention/linear/kda_backend.py文件，具体变更如下：
| 位置 |
变更前 |
变更后 |
作用 |
| 文件顶部 |
包含from ...kda_cutedsl import CuteDSLKDAKernel |
移除该导入语句 |
消除顶层导入触发的模块加载 |
__init__方法内 |
无对应代码 |
在decode_backend.is_cutedsl()分支中添加条件导入：
from ...kda_cutedsl import CuteDSLKDAKernel |
仅当后端选择CuteDSL且平台为CUDA时才导入内核 |
关键逻辑流程：
- 非CUDA平台不会进入
decode_backend.is_cutedsl()分支（因为该分支包含if not is_cuda(): raise ValueError(...)检查）。
- CUDA平台在需要时才动态导入
CuteDSLKDAKernel，避免了AMD/ROCm平台的模块加载错误。
评论区精华
review讨论较为简单，但PR body中的一条互动值得关注：
yiakwy-xpu-ml-framework-team: Is there any plan to support FlyDSL (python dsl of hip, but more like triton) as equivalent CuteDSL (python DSL version of Cutlass) ?
作者回复: Yes, the support is work in progress.
这表明团队正在规划为HIP平台提供类似CuteDSL的FlyDSL支持，延续了跨硬件DSL生态的建设思路。
风险与影响
技术风险：
- 回归风险低：CUDA平台逻辑未变，延迟导入不会影响功能正确性，但需确认无性能开销。
- 兼容性扩展：当前修复仅针对AMD/ROCm，其他非CUDA加速器（如NPU）若进入CuteDSL分支仍会触发错误，但通过
is_cuda()检查已规避。
影响范围：
- 用户：AMD/ROCm用户可正常使用线性注意力模型，修复了之前完全不可用的问题。
- 系统：提升了SGLang在异构硬件环境下的部署能力。
- 团队：为处理平台特定依赖提供了延迟导入的参考模式。
关联脉络
- 直接关联：本PR是#21203的修复补丁，解决了该PR引入的AMD/ROCm兼容性回归。
- 横向关联：与#21408（NPU支持）同属硬件适配范畴，体现了项目对多硬件平台支持的持续投入。
- 演进趋势：从PR讨论中可见，团队正在推进FlyDSL支持，未来可能形成CUDA（CuteDSL）与HIP（FlyDSL）并行的DSL内核生态，进一步强化跨平台能力。
参与讨论