执行摘要

• 一句话：修复 AMD ROCm Docker 镜像中 aiter 模块因导入机制变更导致的启动失败。
• 推荐动作：该 PR 值得快速浏览以理解 Docker 镜像构建中 Python 可编辑安装模式的陷阱。重点关注 editable_mode=compat 如何解决导入路径冲突，以及 review 中未解决的 sh -c 使用风险，可作为未来基础设施代码改进的参考点。

功能与动机

根据 PR body 和关联 Issue #22279，v0.5.10 版本的 AMD ROCm Docker 镜像（rocm700 和 rocm720）在启动时若设置 SGLANG_USE_AITER=1 会抛出 ImportError: cannot import name 'dynamic_per_tensor_quant' from 'aiter' (unknown location)。此问题源于 #19203 合并后，docker/rocm.Dockerfile 中 aiter 的安装方式从 python setup.py develop 改为 python setup.py build_ext --inplace + pip install -e .。新的严格可编辑模式（strict editable mode）使用自定义导入查找器，而默认的 PathFinder 因工作目录在 /sgl-workspace 优先发现了无 init.py 的 git 仓库根目录，导致 aiter 被解析为空命名空间包，实际模块内容无法导入。

实现拆解

1. 变更入口：修改 docker/rocm.Dockerfile 中构建 aiter 模块的安装命令。
2. 核心逻辑：将文件中所有 pip install -e . 实例替换为 pip install --config-settings editable_mode=compat -e .，共三处。这通过 --config-settings editable_mode=compat 参数强制 pip 使用兼容模式，该模式会写入简单的 .pth 路径条目到 site-packages，使 PathFinder 优先找到正确的 /sgl-workspace/aiter/aiter/__init__.py，恢复与旧版 setup.py develop 相同的可靠机制。
3. 配套改动：无其他测试、配置或部署配套改动。PR 仅聚焦于修复 Docker 镜像构建步骤中的安装命令。

关键文件：

• docker/rocm.Dockerfile（模块 部署脚本；类别 infra；类型 infrastructure）: 这是唯一变更的文件，直接修复了 AMD ROCm Docker 镜像中 aiter 模块的安装命令，解决了导入失败问题。

关键符号：未识别

关键源码片段

docker/rocm.Dockerfile

这是唯一变更的文件，直接修复了 AMD ROCm Docker 镜像中 aiter 模块的安装命令，解决了导入失败问题。

# 修复 aiter 模块安装，使用兼容的可编辑模式确保正确导入
RUN cd aiter \
    && sed -i '/c1 = torch.empty((M, D, S1 + S3), dtype=dtype, device=x.device)/i\ config = dict(config)' aiter/ops/triton/gemm/fused/fused_gemm_afp4wfp4_split_cat.py \
    && if [ "$BUILD_AITER_ALL" = "1" ] && [ "$BUILD_LLVM" = "1" ]; then \
        # 使用 --config-settings editable_mode=compat 替代默认的严格可编辑模式
        sh -c "HIP_CLANG_PATH=/sgl-workspace/llvm-project/build/bin/ PREBUILD_KERNELS=1 GPU_ARCHS=$GPU_ARCH_LIST python setup.py build_ext --inplace" \
        && sh -c "HIP_CLANG_PATH=/sgl-workspace/llvm-project/build/bin/ GPU_ARCHS=$GPU_ARCH_LIST pip install --config-settings editable_mode=compat -e ."; \
    elif [ "$BUILD_AITER_ALL" = "1" ]; then \
        sh -c "PREBUILD_KERNELS=1 GPU_ARCHS=$GPU_ARCH_LIST python setup.py build_ext --inplace" \
        && sh -c "GPU_ARCHS=$GPU_ARCH_LIST pip install --config-settings editable_mode=compat -e ."; \
    else \
        # 默认分支也应用相同修复
        sh -c "GPU_ARCHS=$GPU_ARCH_LIST pip install --config-settings editable_mode=compat -e ."; \
    fi \
    && echo "export PYTHONPATH=/sgl-workspace/aiter:\${PYTHONPATH}" >> /etc/bash.bashrc

评论区精华

review 中仅有一条来自 gemini-code-assist[bot] 的评论，指出 sh -c 包装器是冗余的且可能因变量未加引号而不安全，同时手动设置的 PYTHONPATH 导出可能不再必要。但该评论未提供具体的代码修改建议，且 HaiShaw 直接批准了 PR，因此这些潜在问题未被进一步讨论或解决。

• sh -c 包装器的冗余与安全风险 (design): 评论未提供具体修改建议，且 PR 被直接批准，因此这些问题未被解决或进一步讨论。

风险与影响

• 风险：技术风险较低，但存在细微隐患：
  1. 回归风险：修复依赖 pip 的 editable_mode=compat 配置，若未来 pip 版本行为变更或该配置被弃用，可能再次引发类似导入问题。
  2. 安全风险：review 中提及的 sh -c 包装器内变量未加引号可能导致意外的 shell 扩展，但当前上下文（GPU_ARCH_LIST 等环境变量）风险可控。
  3. 兼容性风险：仅影响 AMD ROCm Docker 镜像的构建，对非 Docker 部署或其他硬件平台无影响。
• 影响：1. 对用户的影响：修复后，v0.5.10 及后续版本的 AMD ROCm Docker 镜像将能正常启动，恢复 aiter 模块功能（如量化支持），提升 AMD GPU 用户的体验和系统可用性。
  2. 对系统的影响：仅修改 Docker 镜像构建流程，不影响运行时逻辑或核心代码库。
  3. 对团队的影响：解决了跨版本（#19203 引入）的构建问题，防止未来类似镜像构建错误，但未触及 review 中提到的潜在代码质量隐患（如 sh -c 使用）。
• 风险标记：依赖外部工具行为, 潜在shell注入风险

关联脉络

• PR #19203 [AMD] Update rocm.Dockerfile to use same Dockerfile for rocm700 and rocm720: 该 PR 统一了 rocm700 和 rocm720 的 Dockerfile，并引入了 pip install -e . 安装方式，导致当前 PR 修复的导入问题。
• PR #22870 [AMD][MoRI] bump MoRI to v1.1.0: 同属 AMD 相关基础设施变更，也修改了 docker/rocm.Dockerfile，但关注点不同（依赖升级 vs 安装命令修复）。