SGLang AMD ROCm Wheel 构建与安装实战amd-sglang、sglang-kernel 与依赖排障指南【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang导读本篇指南以仓库 3rdparty/amd/wheel/README.md 为骨架系统讲解 SGLang 在 AMD ROCm 平台上的完整交付链路amd-sglang专用 wheel 的构建方法、ROCm 7.0.0 / 7.2.0 两套环境的安装命令以及 AITER、Triton、sgl-model-gateway、Mori、TileLang、FHT 等关键依赖的手动解析方案与经典报错修复。读完本文你将能够独立完成 ROCm 环境下 SGLang 的源码构建、pip 安装与常见故障排查并理解其背后pyproject.toml与 Docker 构建脚本的协作机制。一、为什么 AMD 平台需要独立的 Wheel 交付链路SGLang 默认的 Python 包sglang面向 NVIDIA CUDA 生态构建。AMD 平台使用 HIPHeterogeneous-computing Interface for Portability与 ROCm 运行时底层依赖的 PyTorch、Triton 均来自 AMD 的独立 wheel 源如repo.radeon.com因此需要一套专门的交付物sglang-kernel旧称sgl-kernelSGLang 的高性能算子内核库。将其构建并发布为 wheel 是整个发布流程的一部分参见仓库release-whl-kernel.yml发布工作流的说明其 ROCm 构建脚本位于 3rdparty/amd/wheel/sgl-kernel/ 目录。amd-sglangAMD 专属的 SGLang 包通过 3rdparty/amd/wheel/sglang/pyproject.toml 定义。它扩展了通用非 NVIDIA 平台的 python/pyproject_other.toml新增两个 ROCm 版本 extrasrocm700、rocm720来固定匹配的 torch / triton / torchaudio / torchvision /sglang-kernel版本并将包名重命名为amd-sglang。1.1amd-sglang的 extras 分层设计从 3rdparty/amd/wheel/sglang/pyproject.toml 源码可以看到完整的分层依赖设计Extra作用关键依赖示例runtime_common运行期公共依赖anthropic、transformers5.12.1、xgrammar0.2.1、smg-grpc-servicer 等rocm700ROCm 7.0.0 专属 wheel 固定torch 2.9.1.devrocm-rel-7.0.2 源、triton 3.5.1、sglang-kernel 0.4.0rocm700rocm720ROCm 7.2.0 专属 wheel 固定torch 2.9.1rocm-rel-7.2 源、triton 3.5.1、sglang-kernel 0.4.0rocm720srt_hipHIP 运行时内核依赖petit_kernel0.0.2、wave-lang3.8.2diffusion_hip扩散模型支持diffusers0.37.0、st_attn0.0.7、vsa0.0.4 等all_hip聚合入口srt_hipdiffusion_hip值得注意的实现细节rocm700extra 的注释明确说明每日构建的 rocm700 镜像依赖尚未公开的700-rc版本软件因此 pyproject 从rocm702渠道固定了一组最接近的版本如torch-2.9.1.dev20251204rocm7.0.2...。可见所谓固定版本实际是对齐到相邻 patch 渠道安装时仍需留意与镜像内实际 ROCm 版本的兼容性。此外pyproject 还通过[project.scripts]声明了sglang sglang.cli.main:main命令行入口对应 python/sglang/cli/main.py并通过[tool.setuptools.packages.find]/[tool.wheel]排除assets、benchmark、docs、dist、playground、scripts、tests目录仅打包srt/**/*与kernels/**/*数据文件保证 wheel 精简可分发。二、从源码构建 amd-sglang Wheel官方给出的构建操作非常精简核心思路是用 AMD 专属的pyproject.toml覆盖python/下的通用配置再交由 Python 标准构建后端出包$ git clone https://github.com/sgl-project/sglang.git cd sglang $ cp 3rdparty/amd/wheel/sglang/pyproject.toml python/pyproject.toml $ cd python python -m build这条命令链的关键点覆盖式构建cp操作把 AMD 配置替换为python/pyproject.toml。注意这会覆盖 python/pyproject_other.toml 对应的默认配置构建完成后如需恢复常规安装应还原原文件构建后端[build-system]声明了setuptools61.0、setuptools-scm8.0、wheel版本号通过setuptools_scm从 git 推导root ..fallback_version 0.0.0.dev0保证无.git元数据时仍可构建产出物命名构建出的包名为amd-sglang与 CUDA 版sglang区分从而支持在同一环境中独立安装与管理。2.1 sglang-kernel 的 ROCm 构建工具链amd-sglang依赖的sglang-kernel在3rdparty/amd/wheel/sgl-kernel/下有一套独立的 ROCm 构建脚本与其发布流程紧密相关build_rocm.sh接受700或720参数分别拉取lmsysorg/sglang:v0.5.8.post1-rocm700-mi35x与rocm/pytorch:rocm7.2_ubuntu22.04_py3.10_pytorch_release_2.9.1镜像设置AMDGPU_TARGETgfx942;gfx950安装对应 ROCm 的 torch/triton/torchaudio/torchvision wheel 与 CMake 3.31.1随后执行rocm_hipify.py最后用uv build --wheel出包rocm_hipify.py定义 HIP 化后的算子源文件清单如custom_all_reduce.hip、topk.hip等链接hiprtc、amdhip64、c10、torch等库rename_wheels_rocm.sh将 wheel 标签从linux重命名为manylinux2014并依据/opt/rocm-*版本追加rocm700/rocm720后缀与 pyproject 中sglang-kernel ...rocm700...whl的固定引用一一对应。由此可以推断amd-sglangwheel 的完整发布流程是先按上述脚本产出带 ROCm 后缀的sglang-kernelwheel 并发布再构建amd-sglangwheel并在rocm700/rocm720extras 中通过 URL 精确引用对应内核 wheel。三、安装 amd-sglang以 v0.5.9 为例官方 README 针对 v0.5.9 提供了两套安装命令分别面向 ROCm 7.0.0 与 ROCm 7.2.0。3.1 ROCm 7.0.0 环境pip uninstall sglang-kernel sglang amd-sglang pip install amd-sglang[all-hip,rocm700] -i https://pypi.amd.com/rocm-7.0.0/simple --extra-index-url https://pypi.org/simple3.2 ROCm 7.2.0 环境pip uninstall sglang-kernel sglang amd-sglang pip install amd-sglang[all-hip,rocm720] -i https://pypi.amd.com/rocm-7.2.0/simple --extra-index-url https://pypi.org/simple两条命令的关键点先卸载旧包sglang-kernel、sglang、amd-sglang三者都必须清理干净避免 CUDA 版sglang与 AMD 版amd-sglang的文件互相污染all-hip 版本 extraall-hip拉取srt_hip与diffusion_hip推理 扩散模型全量能力rocm700/rocm720负责把 torch、triton 等锁定到对应 ROCm 渠道版本双索引源-i指定 AMD 的 ROCm 专属 PyPI提供 torch/triton 等--extra-index-url保留 pypi.org 作为公共依赖的兜底来源。⚠️ 注意事项README 明确提示安装完成后AITER 与 triton 两个依赖必须手工解析见下文其余依赖可按实际应用场景按需选择并非必须全量安装all-hip。四、手动依赖解析AITER 与 Triton4.1 AITER必需依赖AITERAMD ROCm 生态的算子库是amd-sglang的基础依赖但其 wheel 化工作仍在进行中README 原文Wheel-izing it is ongoing目前无法在 pip 依赖中可靠固定因此需要手动安装。推荐路径是跟随 docker/rocm.Dockerfile 中的镜像配方对应 AITER 的构建 RUN 段约 L556-L645按AITER_COMMIT_DEFAULT固定 commit如4ad99832823dde2315b361cbd3b54b1c5c12acd5克隆并 checkout以AITER_USE_SYSTEM_TRITON1编译构建期先使用镜像自带 Triton安装完成后再升级 Triton避免依赖顺序问题通过GPU_ARCHS$GPU_ARCH_LIST pip install --config-settings editable_modecompat -e .完成安装。4.2 Triton 升级规避已知缺陷pip 默认安装的 triton 3.5.1 存在已知问题安装完成后需要升级ROCm 7.0.0 环境pip install triton3.6.0ROCm 7.2.0 环境直接安装带 ROCm 后缀的 wheelpip install https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2/triton-3.6.0%2Brocm7.2.0.gitba5c1517-cp310-cp310-linux_x86_64.whl注意该 wheel 为cp310构建仅适用于 Python 3.10 环境ROCm 7.2 镜像默认 py3.10与 docker/rocm.Dockerfile 中rocm/pytorch:rocm7.2_ubuntu22.04_py3.10_pytorch_release_2.9.1基镜像一致。五、经典报错KernelMetadata对象没有cluster_dims属性升级 Triton 后推理阶段 PyTorch Inductor 与 Triton 元数据交互时可能触发如下报错torch._inductor.exc.InductorError: AttributeError: KernelMetadata object has no attribute cluster_dims5.1 报错根因新版本 Triton 的KernelMetadata结构发生变更而 Inductor 的 Triton 启发式代码triton_heuristics.py在读取元数据时对binary.metadata.cluster_dims的访问没有做属性存在性守卫导致旧/新 Triton 元数据差异直接抛异常。5.2 官方建议的临时补丁在安装环境示例路径/opt/venv/lib/python3.10/site-packages/torch/_inductor/runtime/triton_heuristics.py中为约 L1759 处的元数据访问补充两个hasattr守卫--- a/opt/venv/lib/python3.10/site-packages/torch/_inductor/runtime/triton_heuristics.py b/opt/venv/lib/python3.10/site-packages/torch/_inductor/runtime/triton_heuristics.py -1759,6 1759,8 else ( (binary.metadata.num_ctas, *binary.metadata.cluster_dims) if hasattr(binary, metadata) and hasattr(binary.metadata, num_ctas) and hasattr(binary.metadata, cluster_dims) else () ) ),该补丁属于务实的临时绕过方案仅在属性存在时才读取num_ctas与cluster_dims属性缺失时回退到空元组从而避免 Inductor 与 Triton 元数据格式不一致导致的崩溃。README 将其定位为 workaround升级到与 Triton 完全匹配的 torch 版本后通常不再需要。六、分布式推理依赖解析6.1 sgl-model-gateway多节点 / 网关场景下需要编译安装sgl-model-gateway的 Python 绑定官方命令如下$ apt install openssl libssl-dev protobuf $ export PATH/$HOME/.cargo/bin:${PATH} \ curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y \ rustc --version cargo --version # Prepare for a rust toolchain $ python3 -m pip install --no-cache-dir setuptools-rust \ cd /sgl-workspace/sglang/sgl-model-gateway/bindings/python \ cargo build --release \ python3 -m pip install --no-cache-dir . \ rm -rf /root/.cache # Build and install sgl-model-gateway步骤拆解系统依赖openssl/libssl-dev/protobuf是 Rust 绑定编译所需Rust 工具链通过 rustup 安装并验证rustc、cargo版本setuptools-rust负责把 Rust crate 暴露给 Python 打包系统编译安装在sgl-model-gateway/bindings/python下先cargo build --release编译再pip install .安装绑定最后清理缓存。仓库中对应的 Rust 绑定源码位于 sgl-model-gateway/bindings/python 与 sgl-model-gateway/srcdocker/rocm.Dockerfile 中也有等价流程maturin build --release --features vendored-openssl。6.2 MoriMori 是 ROCm 生态的高速通信 / 显存传输组件用于增强分布式推理场景其构建入口在 docker/rocm.Dockerfile 的 MORI 段约 L880 起。镜像中默认ENABLE_MORI1时启用构建时会按NIC_BACKENDnone/ainic/bnxt安装对应 RDMA NIC 驱动如libionic-dev、bnxt-rocelib并通过MORI_GPU_ARCHS指定目标 GPU 架构如 gfx942、gfx950。README 提示按其镜像配方手动安装即可。七、DeepSeek-V3.2 专属依赖解析在 ROCm 平台运行 DeepSeek-V3.2 系列模型时还需要额外解析两个专属算子库7.1 TileLangTileLang基于 TVM 的 tile 级 DSL用于部分深度优化算子。ROCm 环境的编译流程在 docker/rocm.Dockerfile 的 TileLang 段约 L782-L862要点包括安装系统依赖含 GoogleTest 静态库、cmake4.3.4、ninja、scikit-build-core、定位 ROCm 的llvm-config必要时安装 LLVM 18、固定z3-solver4.15.4.0、以-DUSE_CUDAOFF -DUSE_ROCMON方式pip install -e .安装。7.2 FHTfast-hadamard-transformFHT 提供快速 Hadamard 变换算子。ROCm 构建入口同样位于 docker/rocm.Dockerfile约 L864-L870从rocm分支克隆、checkout 固定 commit46efb7d776d38638fc39f3c803eaee3dd7016bd1并以PYTORCH_ROCM_ARCH${GPU_ARCH_LIST} python setup.py install安装。从源码结构可以推断这两项依赖并非所有场景必需仅当模型推理路径真正触发 TileLang / FHT 对应算子时才需要安装日常小模型推理可先跳过按需补充。八、总结与最佳实践综合 3rdparty/amd/wheel/README.md 与仓库源码AMD ROCm 平台部署 SGLang 的推荐路径可以归纳为四条原则版本对齐优先amd-sglang的rocm700/rocm720extras 已经把 torch、triton、torchaudio、torchvision、sglang-kernel固定到匹配版本安装时应成套使用避免混装 CUDA 版 PyPI 包两大手动依赖必查AITER未 wheel 化需按 docker/rocm.Dockerfile 配方手动安装与 Triton装后升级到 3.6.0 或对应 ROCm wheel是 README 明确要求手工解析的依赖按场景按需补齐分布式推理补 sgl-model-gateway / MoriDeepSeek-V3.2 补 TileLang / FHT其余依赖跟随all-hip即可故障有章可循升级 Triton 后如遇KernelMetadata ... cluster_dims异常使用本文第五节的hasattr守卫补丁即可快速恢复。对于需要自定义内核或离线交付的场景可进一步研究 3rdparty/amd/wheel/sgl-kernel/build_rocm.sh 的镜像内构建流程与 rename_wheels_rocm.sh 的 wheel 重命名规则从而把内核 wheel 发布与amd-sglang的版本固定链路打通形成可复现的完整发布闭环。【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SGLang AMD ROCm Wheel 构建与安装实战：amd-sglang、sglang-kernel 与依赖排障指南
SGLang AMD ROCm Wheel 构建与安装实战amd-sglang、sglang-kernel 与依赖排障指南【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang导读本篇指南以仓库 3rdparty/amd/wheel/README.md 为骨架系统讲解 SGLang 在 AMD ROCm 平台上的完整交付链路amd-sglang专用 wheel 的构建方法、ROCm 7.0.0 / 7.2.0 两套环境的安装命令以及 AITER、Triton、sgl-model-gateway、Mori、TileLang、FHT 等关键依赖的手动解析方案与经典报错修复。读完本文你将能够独立完成 ROCm 环境下 SGLang 的源码构建、pip 安装与常见故障排查并理解其背后pyproject.toml与 Docker 构建脚本的协作机制。一、为什么 AMD 平台需要独立的 Wheel 交付链路SGLang 默认的 Python 包sglang面向 NVIDIA CUDA 生态构建。AMD 平台使用 HIPHeterogeneous-computing Interface for Portability与 ROCm 运行时底层依赖的 PyTorch、Triton 均来自 AMD 的独立 wheel 源如repo.radeon.com因此需要一套专门的交付物sglang-kernel旧称sgl-kernelSGLang 的高性能算子内核库。将其构建并发布为 wheel 是整个发布流程的一部分参见仓库release-whl-kernel.yml发布工作流的说明其 ROCm 构建脚本位于 3rdparty/amd/wheel/sgl-kernel/ 目录。amd-sglangAMD 专属的 SGLang 包通过 3rdparty/amd/wheel/sglang/pyproject.toml 定义。它扩展了通用非 NVIDIA 平台的 python/pyproject_other.toml新增两个 ROCm 版本 extrasrocm700、rocm720来固定匹配的 torch / triton / torchaudio / torchvision /sglang-kernel版本并将包名重命名为amd-sglang。1.1amd-sglang的 extras 分层设计从 3rdparty/amd/wheel/sglang/pyproject.toml 源码可以看到完整的分层依赖设计Extra作用关键依赖示例runtime_common运行期公共依赖anthropic、transformers5.12.1、xgrammar0.2.1、smg-grpc-servicer 等rocm700ROCm 7.0.0 专属 wheel 固定torch 2.9.1.devrocm-rel-7.0.2 源、triton 3.5.1、sglang-kernel 0.4.0rocm700rocm720ROCm 7.2.0 专属 wheel 固定torch 2.9.1rocm-rel-7.2 源、triton 3.5.1、sglang-kernel 0.4.0rocm720srt_hipHIP 运行时内核依赖petit_kernel0.0.2、wave-lang3.8.2diffusion_hip扩散模型支持diffusers0.37.0、st_attn0.0.7、vsa0.0.4 等all_hip聚合入口srt_hipdiffusion_hip值得注意的实现细节rocm700extra 的注释明确说明每日构建的 rocm700 镜像依赖尚未公开的700-rc版本软件因此 pyproject 从rocm702渠道固定了一组最接近的版本如torch-2.9.1.dev20251204rocm7.0.2...。可见所谓固定版本实际是对齐到相邻 patch 渠道安装时仍需留意与镜像内实际 ROCm 版本的兼容性。此外pyproject 还通过[project.scripts]声明了sglang sglang.cli.main:main命令行入口对应 python/sglang/cli/main.py并通过[tool.setuptools.packages.find]/[tool.wheel]排除assets、benchmark、docs、dist、playground、scripts、tests目录仅打包srt/**/*与kernels/**/*数据文件保证 wheel 精简可分发。二、从源码构建 amd-sglang Wheel官方给出的构建操作非常精简核心思路是用 AMD 专属的pyproject.toml覆盖python/下的通用配置再交由 Python 标准构建后端出包$ git clone https://github.com/sgl-project/sglang.git cd sglang $ cp 3rdparty/amd/wheel/sglang/pyproject.toml python/pyproject.toml $ cd python python -m build这条命令链的关键点覆盖式构建cp操作把 AMD 配置替换为python/pyproject.toml。注意这会覆盖 python/pyproject_other.toml 对应的默认配置构建完成后如需恢复常规安装应还原原文件构建后端[build-system]声明了setuptools61.0、setuptools-scm8.0、wheel版本号通过setuptools_scm从 git 推导root ..fallback_version 0.0.0.dev0保证无.git元数据时仍可构建产出物命名构建出的包名为amd-sglang与 CUDA 版sglang区分从而支持在同一环境中独立安装与管理。2.1 sglang-kernel 的 ROCm 构建工具链amd-sglang依赖的sglang-kernel在3rdparty/amd/wheel/sgl-kernel/下有一套独立的 ROCm 构建脚本与其发布流程紧密相关build_rocm.sh接受700或720参数分别拉取lmsysorg/sglang:v0.5.8.post1-rocm700-mi35x与rocm/pytorch:rocm7.2_ubuntu22.04_py3.10_pytorch_release_2.9.1镜像设置AMDGPU_TARGETgfx942;gfx950安装对应 ROCm 的 torch/triton/torchaudio/torchvision wheel 与 CMake 3.31.1随后执行rocm_hipify.py最后用uv build --wheel出包rocm_hipify.py定义 HIP 化后的算子源文件清单如custom_all_reduce.hip、topk.hip等链接hiprtc、amdhip64、c10、torch等库rename_wheels_rocm.sh将 wheel 标签从linux重命名为manylinux2014并依据/opt/rocm-*版本追加rocm700/rocm720后缀与 pyproject 中sglang-kernel ...rocm700...whl的固定引用一一对应。由此可以推断amd-sglangwheel 的完整发布流程是先按上述脚本产出带 ROCm 后缀的sglang-kernelwheel 并发布再构建amd-sglangwheel并在rocm700/rocm720extras 中通过 URL 精确引用对应内核 wheel。三、安装 amd-sglang以 v0.5.9 为例官方 README 针对 v0.5.9 提供了两套安装命令分别面向 ROCm 7.0.0 与 ROCm 7.2.0。3.1 ROCm 7.0.0 环境pip uninstall sglang-kernel sglang amd-sglang pip install amd-sglang[all-hip,rocm700] -i https://pypi.amd.com/rocm-7.0.0/simple --extra-index-url https://pypi.org/simple3.2 ROCm 7.2.0 环境pip uninstall sglang-kernel sglang amd-sglang pip install amd-sglang[all-hip,rocm720] -i https://pypi.amd.com/rocm-7.2.0/simple --extra-index-url https://pypi.org/simple两条命令的关键点先卸载旧包sglang-kernel、sglang、amd-sglang三者都必须清理干净避免 CUDA 版sglang与 AMD 版amd-sglang的文件互相污染all-hip 版本 extraall-hip拉取srt_hip与diffusion_hip推理 扩散模型全量能力rocm700/rocm720负责把 torch、triton 等锁定到对应 ROCm 渠道版本双索引源-i指定 AMD 的 ROCm 专属 PyPI提供 torch/triton 等--extra-index-url保留 pypi.org 作为公共依赖的兜底来源。⚠️ 注意事项README 明确提示安装完成后AITER 与 triton 两个依赖必须手工解析见下文其余依赖可按实际应用场景按需选择并非必须全量安装all-hip。四、手动依赖解析AITER 与 Triton4.1 AITER必需依赖AITERAMD ROCm 生态的算子库是amd-sglang的基础依赖但其 wheel 化工作仍在进行中README 原文Wheel-izing it is ongoing目前无法在 pip 依赖中可靠固定因此需要手动安装。推荐路径是跟随 docker/rocm.Dockerfile 中的镜像配方对应 AITER 的构建 RUN 段约 L556-L645按AITER_COMMIT_DEFAULT固定 commit如4ad99832823dde2315b361cbd3b54b1c5c12acd5克隆并 checkout以AITER_USE_SYSTEM_TRITON1编译构建期先使用镜像自带 Triton安装完成后再升级 Triton避免依赖顺序问题通过GPU_ARCHS$GPU_ARCH_LIST pip install --config-settings editable_modecompat -e .完成安装。4.2 Triton 升级规避已知缺陷pip 默认安装的 triton 3.5.1 存在已知问题安装完成后需要升级ROCm 7.0.0 环境pip install triton3.6.0ROCm 7.2.0 环境直接安装带 ROCm 后缀的 wheelpip install https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2/triton-3.6.0%2Brocm7.2.0.gitba5c1517-cp310-cp310-linux_x86_64.whl注意该 wheel 为cp310构建仅适用于 Python 3.10 环境ROCm 7.2 镜像默认 py3.10与 docker/rocm.Dockerfile 中rocm/pytorch:rocm7.2_ubuntu22.04_py3.10_pytorch_release_2.9.1基镜像一致。五、经典报错KernelMetadata对象没有cluster_dims属性升级 Triton 后推理阶段 PyTorch Inductor 与 Triton 元数据交互时可能触发如下报错torch._inductor.exc.InductorError: AttributeError: KernelMetadata object has no attribute cluster_dims5.1 报错根因新版本 Triton 的KernelMetadata结构发生变更而 Inductor 的 Triton 启发式代码triton_heuristics.py在读取元数据时对binary.metadata.cluster_dims的访问没有做属性存在性守卫导致旧/新 Triton 元数据差异直接抛异常。5.2 官方建议的临时补丁在安装环境示例路径/opt/venv/lib/python3.10/site-packages/torch/_inductor/runtime/triton_heuristics.py中为约 L1759 处的元数据访问补充两个hasattr守卫--- a/opt/venv/lib/python3.10/site-packages/torch/_inductor/runtime/triton_heuristics.py b/opt/venv/lib/python3.10/site-packages/torch/_inductor/runtime/triton_heuristics.py -1759,6 1759,8 else ( (binary.metadata.num_ctas, *binary.metadata.cluster_dims) if hasattr(binary, metadata) and hasattr(binary.metadata, num_ctas) and hasattr(binary.metadata, cluster_dims) else () ) ),该补丁属于务实的临时绕过方案仅在属性存在时才读取num_ctas与cluster_dims属性缺失时回退到空元组从而避免 Inductor 与 Triton 元数据格式不一致导致的崩溃。README 将其定位为 workaround升级到与 Triton 完全匹配的 torch 版本后通常不再需要。六、分布式推理依赖解析6.1 sgl-model-gateway多节点 / 网关场景下需要编译安装sgl-model-gateway的 Python 绑定官方命令如下$ apt install openssl libssl-dev protobuf $ export PATH/$HOME/.cargo/bin:${PATH} \ curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y \ rustc --version cargo --version # Prepare for a rust toolchain $ python3 -m pip install --no-cache-dir setuptools-rust \ cd /sgl-workspace/sglang/sgl-model-gateway/bindings/python \ cargo build --release \ python3 -m pip install --no-cache-dir . \ rm -rf /root/.cache # Build and install sgl-model-gateway步骤拆解系统依赖openssl/libssl-dev/protobuf是 Rust 绑定编译所需Rust 工具链通过 rustup 安装并验证rustc、cargo版本setuptools-rust负责把 Rust crate 暴露给 Python 打包系统编译安装在sgl-model-gateway/bindings/python下先cargo build --release编译再pip install .安装绑定最后清理缓存。仓库中对应的 Rust 绑定源码位于 sgl-model-gateway/bindings/python 与 sgl-model-gateway/srcdocker/rocm.Dockerfile 中也有等价流程maturin build --release --features vendored-openssl。6.2 MoriMori 是 ROCm 生态的高速通信 / 显存传输组件用于增强分布式推理场景其构建入口在 docker/rocm.Dockerfile 的 MORI 段约 L880 起。镜像中默认ENABLE_MORI1时启用构建时会按NIC_BACKENDnone/ainic/bnxt安装对应 RDMA NIC 驱动如libionic-dev、bnxt-rocelib并通过MORI_GPU_ARCHS指定目标 GPU 架构如 gfx942、gfx950。README 提示按其镜像配方手动安装即可。七、DeepSeek-V3.2 专属依赖解析在 ROCm 平台运行 DeepSeek-V3.2 系列模型时还需要额外解析两个专属算子库7.1 TileLangTileLang基于 TVM 的 tile 级 DSL用于部分深度优化算子。ROCm 环境的编译流程在 docker/rocm.Dockerfile 的 TileLang 段约 L782-L862要点包括安装系统依赖含 GoogleTest 静态库、cmake4.3.4、ninja、scikit-build-core、定位 ROCm 的llvm-config必要时安装 LLVM 18、固定z3-solver4.15.4.0、以-DUSE_CUDAOFF -DUSE_ROCMON方式pip install -e .安装。7.2 FHTfast-hadamard-transformFHT 提供快速 Hadamard 变换算子。ROCm 构建入口同样位于 docker/rocm.Dockerfile约 L864-L870从rocm分支克隆、checkout 固定 commit46efb7d776d38638fc39f3c803eaee3dd7016bd1并以PYTORCH_ROCM_ARCH${GPU_ARCH_LIST} python setup.py install安装。从源码结构可以推断这两项依赖并非所有场景必需仅当模型推理路径真正触发 TileLang / FHT 对应算子时才需要安装日常小模型推理可先跳过按需补充。八、总结与最佳实践综合 3rdparty/amd/wheel/README.md 与仓库源码AMD ROCm 平台部署 SGLang 的推荐路径可以归纳为四条原则版本对齐优先amd-sglang的rocm700/rocm720extras 已经把 torch、triton、torchaudio、torchvision、sglang-kernel固定到匹配版本安装时应成套使用避免混装 CUDA 版 PyPI 包两大手动依赖必查AITER未 wheel 化需按 docker/rocm.Dockerfile 配方手动安装与 Triton装后升级到 3.6.0 或对应 ROCm wheel是 README 明确要求手工解析的依赖按场景按需补齐分布式推理补 sgl-model-gateway / MoriDeepSeek-V3.2 补 TileLang / FHT其余依赖跟随all-hip即可故障有章可循升级 Triton 后如遇KernelMetadata ... cluster_dims异常使用本文第五节的hasattr守卫补丁即可快速恢复。对于需要自定义内核或离线交付的场景可进一步研究 3rdparty/amd/wheel/sgl-kernel/build_rocm.sh 的镜像内构建流程与 rename_wheels_rocm.sh 的 wheel 重命名规则从而把内核 wheel 发布与amd-sglang的版本固定链路打通形成可复现的完整发布闭环。【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考