执行摘要

• 一句话：移除 pip pybind11，修复 ROCm ABI 不匹配崩溃
• 推荐动作：值得快速浏览而不是精读：它演示了从“上游一个 unpinned 依赖发布”到“运行时 ABI 崩溃”的完整因果链，对镜像依赖治理有警示价值。关注两点：一是 aiter 侧 include 优先级缺陷（issue #4770）何时在 JIT 工具链中修复；二是 #49925 是否会把 pybind11 纳入统一管理。若团队在意长期稳定性，可考虑在镜像构建后增加 pybind11 internals 版本一致性检查。

功能与动机

PR body 说明：AITER kernels 在 Dockerfile.rocm_base 中基于 pybind11 3.0.4 构建，而 Dockerfile.rocm 通过 uv pip install 安装了 2026-08-08 发布的 pybind11 3.1.0，API 不兼容会破坏 Kimi K2.6/K3 等模型。关联 issue ROCm/aiter#4770 进一步定位根因：aiter 运行时 JIT 编译模块优先使用 pip 的 include 路径（internals v12），与 wheel 预编译二进制（internals v11）之间无法共享 pybind 注册类型，导致 fmha_fwd_bf16_opus_fwd() 抛出 TypeError，自 2026-08-11 nightly 起阻断 MLA prefill 后端 ROCM_AITER_FA 的 warmup。

实现拆解

1. 根因确认：结合 ROCm/aiter#4770 的 strings 证据，确认镜像内 module_aiter_core.so 使用 pybind11_internals_v11，而运行时 JIT 编译的 module_fmha_fwd_bf16_opus.so 使用 v12，二者类型注册互相隔离，与参数正确性无关。
2. 最小改动：在 docker/Dockerfile.rocm 约第 400 行的 uv pip install --system 指令中，从 meson meson-python pybind11 pyyaml types-PyYAML 移除 pybind11，使 pip 版 pybind11 不再进入用户 include 路径，aiter JIT 编译回落到 torch 自带的 pybind11（internals v11）。
3. 验证与配套：单个 commit，无源码或测试联动；合并者在评论区触发 /ci run，由 Buildkite CI #83989 对 head commit 714c66a 做镜像构建验证。长期收敛方向记录在 #49925（ROCk 切换，统一 Dockerfiles）中。

关键文件：

• docker/Dockerfile.rocm（模块 镜像构建；类别 infra；类型 infrastructure）: 唯一变更文件：在 uv pip install 构建依赖列表移除 pybind11，消除 pip 版 pybind11 与 torch 自带版本之间的 include 优先级冲突，是修复 ROCm nightly 镜像上 Kimi K2.6/K3 模型崩溃的关键动作。

关键符号：未识别

关键源码片段

docker/Dockerfile.rocm

唯一变更文件：在 uv pip install 构建依赖列表移除 pybind11，消除 pip 版 pybind11 与 torch 自带版本之间的 include 优先级冲突，是修复 ROCm nightly 镜像上 Kimi K2.6/K3 模型崩溃的关键动作。

# 关键：此阶段不要安装 pip 版 pybind11。
#
# 背景：aiter 运行时 JIT 编译模块优先使用 pip 的 include 路径（internals v12），
# 与 rocm_base 预构建二进制所用的 torch 自带 pybind11 (internals v11) 不兼容，
# 导致 Kimi K2.6/K3 等模型的 fmha_fwd_bf16_opus 调用抛出 TypeError。
# 结论：只安装其余构建依赖，pybind11 相关编译 flags 统一交给 torch 提供。
RUN --mount=type=cache,target=/root/.cache/uv \
    uv pip install --system meson meson-python pyyaml types-PyYAML \
    auditwheel build patchelf pytest tomlkit "setuptools>=80.9.0"

评论区精华

本 PR 没有发生实质性技术争论：claude[bot] 仅提示 fork 场景下自动化 review 被禁用；合并者 AndreasKaratzas 直接 approve。唯一可见的验证动作是评论区的 /ci run 触发 Buildkite CI #83989。技术权衡（为何删除而非升降级 pybind11）主要沉淀在关联 issue ROCm/aiter#4770 与 #49925 中，而非本 PR 评论。

• CI 验证镜像构建 (testing): CI 已触发；评论中未出现失败反馈，随后由 AndreasKaratzas approve。
• fork 自动化 review 说明 (other): AndreasKaratzas 以人工 approve 完成审核，未产生额外技术讨论。

风险与影响

• 风险：
  1. 构建链隐性依赖：删除 pybind11 后，若 Dockerfile.rocm 后续阶段存在显式 import pybind11 或依赖 pip include 的编译步骤，可能失败；但按 PR 描述 aiter 相关二进制已在 rocm_base 基于 torch 自带 pybind11 构建，此阶段的 pip 安装属于多余且有害。
  2. 规避而非根治：aiter 侧 cpp_extension.py 中 user include 优先于 torch include 的 FIXME 仍然存在（issue #4770），一旦 torch 自带 pybind11 的 internals 版本再变化，问题可能复发；#49925 的 ROCk 统一镜像才是彻底方案。
  3. 可复现性反而受益：移除 unpinned 的 pybind11 后，镜像构建不再受上游 2026-08-06 之后的版本漂移影响，构建产物更可复现；不过其他依赖仍未 pin 死，漂移风险只是局部下降。
     - 影响：用户影响：ROCm nightly 镜像用户从 2026-08-11 起遇到的 Kimi K2.6/K3 启动崩溃（TypeError: fmha_fwd_bf16_opus_fwd）得到修复，此前只能通过 --attention-config '{"mla_prefill_backend": "FLASH_ATTN"}' 绕过。系统影响：Dockerfile.rocm 构建阶段不再被 pip pybind11 版本漂移污染，镜像产物行为更可预期。团队与流程影响：改动范围仅限镜像构建阶段，不触及 Python 源码路径，为 ROCk 统一镜像（#49925）争取了时间；后续应在该长期工作中固化依赖一致性校验。
     - 风险标记：依赖隐式版本耦合, 临时规避非根治, 依赖镜像 CI 验证

关联脉络

• PR #49925 [ROCm] Switch to the Rock, Keep Python 3.12 and Ubuntu 22.04: PR body 明确将 ROCk 切换（#49925）列为未来统一 Dockerfiles 的长期方案；本 PR 是该项工作落地前的临时规避措施，两者属于同一条演进线的不同阶段。