本次 AI 摘要未能生成有效摘要。

🤖 AI Code Review

⚠️ 审查未能完成

本次代码审查未能完成，可能是临时性故障。

你可以在评论区输入 /ai review 重新发起审查。若多次失败，请联系管理员并附上下方追踪 ID。

追踪 ID: task-142266-run-136469

Thanks for your pull-request.
The full list of commands accepted by me can be found at here。
You can get sig-info at here

PR Approval Progress

✅ Congratulations! All modules have met the lgtm and approve requirements.

Module Approval Details

💡 Tip:

• Committer can comment /approve or /lgtm
• Commenting /approve implies both code review (lgtm) and intent to merge (approve)

CLA Signature Pass

vINyLogY, thanks for your pull request. All authors of the commits have signed the CLA. 👍

compile

compile

流水线任务触发成功
任务链接 [5716da4890fa4dcf8d55c4a93dba34a2][流水线指导]

[2026-08-01 13:44:26]    CI执行结束

评审意见（PR 239 · 评测镜像跨架构 + 950PR 支持）

评审基于 head bcc4971 对 merge-base 402c59f 的只读比对（8 个 docker 文件，+255/-67，无夹带无关改动）。

结论

跨架构（aarch64 / x86_64）与 950PR 接线在静态层面自洽、可成立，改动文件内未发现 🔴 阻塞。一处 🟡 建议合入前处理，另有几处只能靠真实 x86_64 / 950 构建运行确认。

✅ 静态已确认成立

跨架构参数化完整

• docker/base/Dockerfile 把三处架构相关路径全改 ${ARCH}：toolkit .run 下载（base/Dockerfile:87）、libhccl stub 落点 ${ARCH}-linux/lib64、ccec_compiler/bin 与 LD_LIBRARY_PATH；docker/eval/Dockerfile 已无任何 aarch64 字面量，改为继承 CANN_ARCH。
• 架构单向下传、防父子错配：base 经 ENV CANN_ARCH=${ARCH}（base/Dockerfile:108）发布，eval 层用 : "${CANN_ARCH:?}"（eval/Dockerfile:62）+ uname -m 断言（eval/Dockerfile:63）双重校验，build.sh 再从 docker image inspect 读 base 的 CANN_ARCH 做一致性校验（build.sh:75-83）。三道校验层次分明。
• uv.lock（本 PR 未改）确含两架构 wheel（torch_npu 的 x86_64 与 aarch64、torch 2.10.0+cpu 等），x86_64 主机 uv sync --frozen 能解析，README"同一份 lock 已含两架构 wheel"属实。

950PR 支持接线一致

• build.sh 按 NPU_ARCH 派生 OPS_PKG/OPS_MODE（build.sh:34-41）：ascend950 → OPS_PKG=950 / 默认 OPS_MODE=refonly；ops URL 用 Ascend-cann-${OPS_PKG}-ops_${CANN_VERSION}_linux-${CANN_ARCH}.run（eval/Dockerfile:72）。编译器 flag（ascend950）与包名（950）拼写差异有注释、分落两个变量，未混用。
• "950 不能用 OPS_MODE=none"在四处一致落实：Dockerfile 构建期拒绝（eval/Dockerfile:67-71）、build.sh 默认 refonly（build.sh:38）、run.sh 同一默认、self_test.py [2] 以裸 H2D 拷贝为可用性门槛并对 ERR01007/aclnnInplaceCopy 提示改 refonly。
• 950 kernel 编译路径经核 src/cann_bench_utils/build.sh 的 SoC 识别支持（Ascend910_95*|Ascend950*) NPU_ARCH="ascend950"）。910b/910_93 默认仍 none，与旧逻辑等价，不被 950 分支破坏。

其余

• build.sh/run.sh set -euo pipefail、uname -m 别名规范化（arm64→aarch64/amd64→x86_64）、未知架构/未知 NPU_ARCH 显式退出；tag cann-bench-eval:${VERSION}-${NPU_ARCH}-${ARCH}-ops${OPS_MODE} 编码了全部影响分数含义的维度，run.sh 用同一派生规则还原。无写死本地路径。
• self_test.py [2] 从"仅看 device_count"升级为裸 torch.arange(4).npu().cpu() 往返校验（正是 950 真会失败处）；[6] 反作弊语义调整正确（能下发内置算子→[WARN]、被拦→[INFO]，不计入 failed），错误码区分 none→500001/refonly→561103。
• 安全：8 个改动文件扫描 token/密钥/内网地址无实质命中，拉取源全为公开地址（Ascend OBS、pythonhosted、pytorch、华为云/南大镜像、triton-ascend、ghcr），wget 仅带 Referer 无鉴权。
• 三处 README 与 Dockerfile/脚本实际行为对齐。

🟡 建议合入前处理

docker/eval/entrypoint.sh:15 仍硬编码 aarch64-linux/lib64（该文件不在本 PR 改动集）
该行 export LD_LIBRARY_PATH=/usr/local/Ascend/ascend-toolkit/latest/aarch64-linux/lib64:...，在 x86_64 镜像里该目录不存在（真正的 stub 在 x86_64-linux/lib64）。x86_64 目前能跑，唯一原因是 base 新增 ENV BASH_ENV=/etc/cann-env.sh（base/Dockerfile:133）：非交互 bash 会先 source 它、按 ${ARCH} 正确加入 x86_64-linux/lib64，entrypoint 那行只是把一个不存在的 aarch64 目录前置。即 x86_64 可用性完全依赖 BASH_ENV 这条隐式链路，entrypoint 自身那行在 x86_64 上是失效且误导的字面量。一旦后续有人移除 BASH_ENV 或其 source，x86_64 镜像会在 import torch_npu 失败。建议改为引用 ${CANN_ARCH}（运行期 ENV 可用），或直接 source /etc/cann-env.sh 并删去这段冗余手工 set_env。跨架构改造应覆盖到这条。

🟡 次要（非阻塞）

• base 层缺少与 eval 对称的 uname == ARCH 断言：x86_64 主机不带 --build-arg ARCH 构建 base（默认 ARG ARCH=aarch64）会下载 aarch64 toolkit 并在执行 .run 时报 exec 格式错误，而非明确的架构不符提示。README 已要求 --build-arg ARCH=$(uname -m)，实际影响有限。
• run.sh 的架构 case 无 *) 兜底，未知架构原样拼进 tag（后果仅是 docker run 找不到镜像而失败，属可接受失败方式），与 build.sh 的严格校验略不对称。
• 镜像 tag 新增 -<ARCH>- 段属不兼容变更（有意、README 已说明）；按旧 tag 引用镜像的外部自动化会失配，合入方需知会依赖旧 tag 的调用方。
• README 把 x86_64/950 呈现得接近硬绑定，实则 ARCH（uname -m 定）与 NPU_ARCH（环境变量定）正交；建议一句点明二者可独立组合、仅 x86_64/950 这一组合经实测。

须真机验证（静态不可确认，950 支持成立与否的核心）

• 两个 OBS 包 URL 是否真实可下载：Ascend-cann-toolkit_9.0.1_linux-x86_64.run、Ascend-cann-950-ops_9.0.1_linux-x86_64.run（即 x86_64 toolkit 与 950 ops 的 x86_64 变体在 CANN 9.0.1 下存在、且 950 以 950 拼写）。
• Dockerfile/README/self_test 中作者声称的实测断言（950 上 none→ERR01007、matmul 被拦 561103、910B 500001、warmup 6.4ms/cache_clean 1.1ms 等），本地无 950 卡无法复核。

合入前置

建议修 entrypoint.sh:15 的硬编码（消除 x86_64 对 BASH_ENV 的隐式依赖），并以一次真实 x86_64 / 950 的 build.sh + run.sh self-test 确认两个 OBS 包 URL 可下载。其余 🟡 可选修。

Notification

This pull request has been changed(code update) or closed, so removes the following label(s): ci-pipeline-passed.

compile

流水线任务触发成功
任务链接 [1d14144c5c434b468403c189bbfa984b][流水线指导]

[2026-08-03 14:19:23]    CI执行结束

/lgtm
/approve

/lgtm