Star334
155
代码
代码
Issues106
Pull Requests73
Actions
项目讨论
Wiki
分析
Star334
155
cann-robotcann-robotchore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实
f3f0abe2创建于 8月27日历史提交
文件最后提交记录最后更新时间
Dockerfile
chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Co-authored-by: Xinxian Chen<chenxinxian1@huawei.com> # message auto-generated for no-merge-commit merge: !270 merge chore/cann-9.1.0 into master chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Created-by: vINyLogY Commit-by: Xinxian Chen Merged-by: cann-robot Description: ### PR功能描述 / 为什么需要这个合入**: 镜像的默认 CANN 版本一直停在 9.0.1,而 CI 流水线的评测 pod 和 q7 都已经在跑 9.1.0 —— 也就是说"评测镜像"和"实际跑 ST 的地方"不是同一个 CANN。 !239(标题带 9.1.0)做的是"**让** 9.1.0 可用":删掉 docker/eval 里硬编码的版本与 ops URL,改成从 base 继承 + 可推导,并核实了四个 .run 都在。默认值本身没在那次的改动范围内,ARG CANN_VERSION=9.0.1 从 718a75d 建立起就没动过。 docker/dev 的情况更直接:它的默认基础镜像 ascendhub/cann:9.0.0-910b-ubuntu22.04-py3.12 **已经从 AscendHub 下架**(2026-08-17 docker manifest inspect 核实:no such manifest),按默认值已经建不出镜像了。 ### 该PR关联的issue 无关联 issue。 ### 希望检视人员了解: **torch_npu 必须跟着一起动,不动才是脱表。** 查[官方配套表](https://gitcode.com/Ascend/pytorch/blob/master/COMPATIBILITY.md)后发现:torch_npu 2.10 这条线**只配 CANN 9.1.0**(2.10.0.post4 ↔ torch 2.10.0 ↔ CANN 9.1.0),表里**没有 9.0.1 这一行**,而此前钉的 2.10.0.post2 在任何 CANN 版本下都不在表内。所以本 PR 是把这个组合**第一次**放进官方配套表,不是让它离开。docker/base/Dockerfile 顶部那句注释也一并更正了 —— 它原本写着 "torch_npu 2.10.0.post2 ↔ CANN 9.0.x",没有依据。 **报告里的 docker 字段此前在说谎。** _detect_docker() 硬编码返回 "cake-ci / CANN 9.0.0"(源码里自己标着 TODO)。镜像换代、CANN 升到 9.1.0 之后这行字仍原样出现在每一份报告里 —— 一份真实产出的报告同时写着 environment.cann = 9.1.0 和 Docker = cake-ci / CANN 9.0.0,读的人无从判断哪个可信。现在改为三级取值:镜像注入的 CANN_BENCH_IMAGE(docker/eval/build.sh 把自己的 tag 传进去)→ 容器内但未注入时返回 "container" → 不在容器里返回 None。CANN 版本一律取实际探测值,与 environment.cann 同源,不会再自相矛盾。该字段此前**没有任何测试**,这次补了 6 个。 **docker/dev 的 -devel 提成了 ARG 而不是写死。** AscendHub 的 tag 多了一段 variant 后缀,带编译工具链的是 -devel;评测要编译提交,必须用它。核实过的取值(docker manifest inspect,2026-08-17):CANN_VERSION 9.0.1 / 9.1.0 存在,9.0.0 已下架,9.2.0 未发布;DEVICE 910 / 910b / 950 / a3 / 310p 存在,**910c 不存在**(旧注释写错了);9.1.0 的 910b 与 950 的 -devel 均为 arm64 + amd64 双架构。README 里加了一句提醒:上游 tag 会下架,换版本前先 manifest inspect —— 这次就是没人查,默认值悄悄失效了。 **根 uv.lock 顺带补上了 build。** 它列在根 pyproject.toml 的依赖里,但旧 lock 中没有,已经陈旧;这次重锁时被带出来了。 **已知的、本 PR 没有处理的:** docker/base/uv.lock 与 docker/eval/uv.lock 之间 filelock 和 fsspec 两个包版本不一致(3.29.7/3.32.0、2026.6.0/2026.7.0)。这个漂移**在改动前就存在**,重锁前后完全一致,故未在本 PR 中处理。 ## 改动类型 / Change Type - [ ] Bug 修复 / Bug Fix - [ ] 新功能 / New Feature - [ ] 性能优化 / Performance - [ ] 代码重构 / Refactoring - [x] 文档更新 / Documentation - [ ] 测试相关 / Test - [x] 其它 / Other(依赖版本与镜像基线提升) ## 测试信息 / Testing **UT** —— 1172 passed(mac / CPU-only)。新增 tests/ut/test_setup_info.py 6 个用例覆盖 docker 字段的三条取值路径;**退回改动前 6 个全部失败**(3 fail + 3 error)。另有 6 个 auto_pipeline 进程树用例在 mac 上先前就失败,与本改动无关。 **实机(q7 / 910B2 / aarch64)** —— 用本分支的 lock 重建 docker/base 镜像成功,容器内实测: CANN_VERSION (ENV) = 9.1.0 torch = 2.10.0+cpu torch_npu = 2.10.0.post4 NPU 可用 = True | 卡数 1 H2D/D2H = [0.0, 2.0, 4.0, 6.0] 反作弊姿态保持:docker/base 仍是 toolkit-only(无 ops → 无 libopapi),容器内 torch.matmul 在 NPU 上**失败**,即内置算子仍不可达。(实测报错为 SetPrecisionMode:...LazyInitAclops NPU function error;与 docker/eval 文档记录的 561103 症状不同,本 PR 未深究该差异,只确认姿态未被升级破坏。) 改后的 docker 字段实机实测: 裸镜像(未注入) docker = container / CANN 9.1.0 注入 tag 后 docker = cann-bench-eval:1.0.0-ascend910b-aarch64-opsnone / CANN 9.1.0 **未做的:** docker/eval 镜像本身没有在本分支上重建过(9.1.0 的 eval 层此前由 !239 验证过,本 PR 只改默认值);docker/dev 未重建(其 torch/torch_npu 由 AscendHub 基础镜像自带,本仓库不钉,故无 lock 改动)。 - [x] 单元测试通过 / UT passed - [ ] 集成测试通过 / ST passed - [x] 人工验证通过 / Manual verified ## 检查清单 / Checklist - [x] 代码符合规范 / Code follows style guide - [x] 测试添加并通过 / Tests added and passed - [x] 文档已更新 / Docs updated if needed - [x] 无硬编码敏感信息 / No secrets hardcoded - [x] 提交信息符合规范 / Commit message follows convention See merge request: cann/cann-bench!270
1 个月前
README.md
chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Co-authored-by: Xinxian Chen<chenxinxian1@huawei.com> # message auto-generated for no-merge-commit merge: !270 merge chore/cann-9.1.0 into master chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Created-by: vINyLogY Commit-by: Xinxian Chen Merged-by: cann-robot Description: ### PR功能描述 / 为什么需要这个合入**: 镜像的默认 CANN 版本一直停在 9.0.1,而 CI 流水线的评测 pod 和 q7 都已经在跑 9.1.0 —— 也就是说"评测镜像"和"实际跑 ST 的地方"不是同一个 CANN。 !239(标题带 9.1.0)做的是"**让** 9.1.0 可用":删掉 docker/eval 里硬编码的版本与 ops URL,改成从 base 继承 + 可推导,并核实了四个 .run 都在。默认值本身没在那次的改动范围内,ARG CANN_VERSION=9.0.1 从 718a75d 建立起就没动过。 docker/dev 的情况更直接:它的默认基础镜像 ascendhub/cann:9.0.0-910b-ubuntu22.04-py3.12 **已经从 AscendHub 下架**(2026-08-17 docker manifest inspect 核实:no such manifest),按默认值已经建不出镜像了。 ### 该PR关联的issue 无关联 issue。 ### 希望检视人员了解: **torch_npu 必须跟着一起动,不动才是脱表。** 查[官方配套表](https://gitcode.com/Ascend/pytorch/blob/master/COMPATIBILITY.md)后发现:torch_npu 2.10 这条线**只配 CANN 9.1.0**(2.10.0.post4 ↔ torch 2.10.0 ↔ CANN 9.1.0),表里**没有 9.0.1 这一行**,而此前钉的 2.10.0.post2 在任何 CANN 版本下都不在表内。所以本 PR 是把这个组合**第一次**放进官方配套表,不是让它离开。docker/base/Dockerfile 顶部那句注释也一并更正了 —— 它原本写着 "torch_npu 2.10.0.post2 ↔ CANN 9.0.x",没有依据。 **报告里的 docker 字段此前在说谎。** _detect_docker() 硬编码返回 "cake-ci / CANN 9.0.0"(源码里自己标着 TODO)。镜像换代、CANN 升到 9.1.0 之后这行字仍原样出现在每一份报告里 —— 一份真实产出的报告同时写着 environment.cann = 9.1.0 和 Docker = cake-ci / CANN 9.0.0,读的人无从判断哪个可信。现在改为三级取值:镜像注入的 CANN_BENCH_IMAGE(docker/eval/build.sh 把自己的 tag 传进去)→ 容器内但未注入时返回 "container" → 不在容器里返回 None。CANN 版本一律取实际探测值,与 environment.cann 同源,不会再自相矛盾。该字段此前**没有任何测试**,这次补了 6 个。 **docker/dev 的 -devel 提成了 ARG 而不是写死。** AscendHub 的 tag 多了一段 variant 后缀,带编译工具链的是 -devel;评测要编译提交,必须用它。核实过的取值(docker manifest inspect,2026-08-17):CANN_VERSION 9.0.1 / 9.1.0 存在,9.0.0 已下架,9.2.0 未发布;DEVICE 910 / 910b / 950 / a3 / 310p 存在,**910c 不存在**(旧注释写错了);9.1.0 的 910b 与 950 的 -devel 均为 arm64 + amd64 双架构。README 里加了一句提醒:上游 tag 会下架,换版本前先 manifest inspect —— 这次就是没人查,默认值悄悄失效了。 **根 uv.lock 顺带补上了 build。** 它列在根 pyproject.toml 的依赖里,但旧 lock 中没有,已经陈旧;这次重锁时被带出来了。 **已知的、本 PR 没有处理的:** docker/base/uv.lock 与 docker/eval/uv.lock 之间 filelock 和 fsspec 两个包版本不一致(3.29.7/3.32.0、2026.6.0/2026.7.0)。这个漂移**在改动前就存在**,重锁前后完全一致,故未在本 PR 中处理。 ## 改动类型 / Change Type - [ ] Bug 修复 / Bug Fix - [ ] 新功能 / New Feature - [ ] 性能优化 / Performance - [ ] 代码重构 / Refactoring - [x] 文档更新 / Documentation - [ ] 测试相关 / Test - [x] 其它 / Other(依赖版本与镜像基线提升) ## 测试信息 / Testing **UT** —— 1172 passed(mac / CPU-only)。新增 tests/ut/test_setup_info.py 6 个用例覆盖 docker 字段的三条取值路径;**退回改动前 6 个全部失败**(3 fail + 3 error)。另有 6 个 auto_pipeline 进程树用例在 mac 上先前就失败,与本改动无关。 **实机(q7 / 910B2 / aarch64)** —— 用本分支的 lock 重建 docker/base 镜像成功,容器内实测: CANN_VERSION (ENV) = 9.1.0 torch = 2.10.0+cpu torch_npu = 2.10.0.post4 NPU 可用 = True | 卡数 1 H2D/D2H = [0.0, 2.0, 4.0, 6.0] 反作弊姿态保持:docker/base 仍是 toolkit-only(无 ops → 无 libopapi),容器内 torch.matmul 在 NPU 上**失败**,即内置算子仍不可达。(实测报错为 SetPrecisionMode:...LazyInitAclops NPU function error;与 docker/eval 文档记录的 561103 症状不同,本 PR 未深究该差异,只确认姿态未被升级破坏。) 改后的 docker 字段实机实测: 裸镜像(未注入) docker = container / CANN 9.1.0 注入 tag 后 docker = cann-bench-eval:1.0.0-ascend910b-aarch64-opsnone / CANN 9.1.0 **未做的:** docker/eval 镜像本身没有在本分支上重建过(9.1.0 的 eval 层此前由 !239 验证过,本 PR 只改默认值);docker/dev 未重建(其 torch/torch_npu 由 AscendHub 基础镜像自带,本仓库不钉,故无 lock 改动)。 - [x] 单元测试通过 / UT passed - [ ] 集成测试通过 / ST passed - [x] 人工验证通过 / Manual verified ## 检查清单 / Checklist - [x] 代码符合规范 / Code follows style guide - [x] 测试添加并通过 / Tests added and passed - [x] 文档已更新 / Docs updated if needed - [x] 无硬编码敏感信息 / No secrets hardcoded - [x] 提交信息符合规范 / Commit message follows convention See merge request: cann/cann-bench!270
1 个月前
pyproject.toml
chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Co-authored-by: Xinxian Chen<chenxinxian1@huawei.com> # message auto-generated for no-merge-commit merge: !270 merge chore/cann-9.1.0 into master chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Created-by: vINyLogY Commit-by: Xinxian Chen Merged-by: cann-robot Description: ### PR功能描述 / 为什么需要这个合入**: 镜像的默认 CANN 版本一直停在 9.0.1,而 CI 流水线的评测 pod 和 q7 都已经在跑 9.1.0 —— 也就是说"评测镜像"和"实际跑 ST 的地方"不是同一个 CANN。 !239(标题带 9.1.0)做的是"**让** 9.1.0 可用":删掉 docker/eval 里硬编码的版本与 ops URL,改成从 base 继承 + 可推导,并核实了四个 .run 都在。默认值本身没在那次的改动范围内,ARG CANN_VERSION=9.0.1 从 718a75d 建立起就没动过。 docker/dev 的情况更直接:它的默认基础镜像 ascendhub/cann:9.0.0-910b-ubuntu22.04-py3.12 **已经从 AscendHub 下架**(2026-08-17 docker manifest inspect 核实:no such manifest),按默认值已经建不出镜像了。 ### 该PR关联的issue 无关联 issue。 ### 希望检视人员了解: **torch_npu 必须跟着一起动,不动才是脱表。** 查[官方配套表](https://gitcode.com/Ascend/pytorch/blob/master/COMPATIBILITY.md)后发现:torch_npu 2.10 这条线**只配 CANN 9.1.0**(2.10.0.post4 ↔ torch 2.10.0 ↔ CANN 9.1.0),表里**没有 9.0.1 这一行**,而此前钉的 2.10.0.post2 在任何 CANN 版本下都不在表内。所以本 PR 是把这个组合**第一次**放进官方配套表,不是让它离开。docker/base/Dockerfile 顶部那句注释也一并更正了 —— 它原本写着 "torch_npu 2.10.0.post2 ↔ CANN 9.0.x",没有依据。 **报告里的 docker 字段此前在说谎。** _detect_docker() 硬编码返回 "cake-ci / CANN 9.0.0"(源码里自己标着 TODO)。镜像换代、CANN 升到 9.1.0 之后这行字仍原样出现在每一份报告里 —— 一份真实产出的报告同时写着 environment.cann = 9.1.0 和 Docker = cake-ci / CANN 9.0.0,读的人无从判断哪个可信。现在改为三级取值:镜像注入的 CANN_BENCH_IMAGE(docker/eval/build.sh 把自己的 tag 传进去)→ 容器内但未注入时返回 "container" → 不在容器里返回 None。CANN 版本一律取实际探测值,与 environment.cann 同源,不会再自相矛盾。该字段此前**没有任何测试**,这次补了 6 个。 **docker/dev 的 -devel 提成了 ARG 而不是写死。** AscendHub 的 tag 多了一段 variant 后缀,带编译工具链的是 -devel;评测要编译提交,必须用它。核实过的取值(docker manifest inspect,2026-08-17):CANN_VERSION 9.0.1 / 9.1.0 存在,9.0.0 已下架,9.2.0 未发布;DEVICE 910 / 910b / 950 / a3 / 310p 存在,**910c 不存在**(旧注释写错了);9.1.0 的 910b 与 950 的 -devel 均为 arm64 + amd64 双架构。README 里加了一句提醒:上游 tag 会下架,换版本前先 manifest inspect —— 这次就是没人查,默认值悄悄失效了。 **根 uv.lock 顺带补上了 build。** 它列在根 pyproject.toml 的依赖里,但旧 lock 中没有,已经陈旧;这次重锁时被带出来了。 **已知的、本 PR 没有处理的:** docker/base/uv.lock 与 docker/eval/uv.lock 之间 filelock 和 fsspec 两个包版本不一致(3.29.7/3.32.0、2026.6.0/2026.7.0)。这个漂移**在改动前就存在**,重锁前后完全一致,故未在本 PR 中处理。 ## 改动类型 / Change Type - [ ] Bug 修复 / Bug Fix - [ ] 新功能 / New Feature - [ ] 性能优化 / Performance - [ ] 代码重构 / Refactoring - [x] 文档更新 / Documentation - [ ] 测试相关 / Test - [x] 其它 / Other(依赖版本与镜像基线提升) ## 测试信息 / Testing **UT** —— 1172 passed(mac / CPU-only)。新增 tests/ut/test_setup_info.py 6 个用例覆盖 docker 字段的三条取值路径;**退回改动前 6 个全部失败**(3 fail + 3 error)。另有 6 个 auto_pipeline 进程树用例在 mac 上先前就失败,与本改动无关。 **实机(q7 / 910B2 / aarch64)** —— 用本分支的 lock 重建 docker/base 镜像成功,容器内实测: CANN_VERSION (ENV) = 9.1.0 torch = 2.10.0+cpu torch_npu = 2.10.0.post4 NPU 可用 = True | 卡数 1 H2D/D2H = [0.0, 2.0, 4.0, 6.0] 反作弊姿态保持:docker/base 仍是 toolkit-only(无 ops → 无 libopapi),容器内 torch.matmul 在 NPU 上**失败**,即内置算子仍不可达。(实测报错为 SetPrecisionMode:...LazyInitAclops NPU function error;与 docker/eval 文档记录的 561103 症状不同,本 PR 未深究该差异,只确认姿态未被升级破坏。) 改后的 docker 字段实机实测: 裸镜像(未注入) docker = container / CANN 9.1.0 注入 tag 后 docker = cann-bench-eval:1.0.0-ascend910b-aarch64-opsnone / CANN 9.1.0 **未做的:** docker/eval 镜像本身没有在本分支上重建过(9.1.0 的 eval 层此前由 !239 验证过,本 PR 只改默认值);docker/dev 未重建(其 torch/torch_npu 由 AscendHub 基础镜像自带,本仓库不钉,故无 lock 改动)。 - [x] 单元测试通过 / UT passed - [ ] 集成测试通过 / ST passed - [x] 人工验证通过 / Manual verified ## 检查清单 / Checklist - [x] 代码符合规范 / Code follows style guide - [x] 测试添加并通过 / Tests added and passed - [x] 文档已更新 / Docs updated if needed - [x] 无硬编码敏感信息 / No secrets hardcoded - [x] 提交信息符合规范 / Commit message follows convention See merge request: cann/cann-bench!270
1 个月前
run.sh
chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Co-authored-by: Xinxian Chen<chenxinxian1@huawei.com> # message auto-generated for no-merge-commit merge: !270 merge chore/cann-9.1.0 into master chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Created-by: vINyLogY Commit-by: Xinxian Chen Merged-by: cann-robot Description: ### PR功能描述 / 为什么需要这个合入**: 镜像的默认 CANN 版本一直停在 9.0.1,而 CI 流水线的评测 pod 和 q7 都已经在跑 9.1.0 —— 也就是说"评测镜像"和"实际跑 ST 的地方"不是同一个 CANN。 !239(标题带 9.1.0)做的是"**让** 9.1.0 可用":删掉 docker/eval 里硬编码的版本与 ops URL,改成从 base 继承 + 可推导,并核实了四个 .run 都在。默认值本身没在那次的改动范围内,ARG CANN_VERSION=9.0.1 从 718a75d 建立起就没动过。 docker/dev 的情况更直接:它的默认基础镜像 ascendhub/cann:9.0.0-910b-ubuntu22.04-py3.12 **已经从 AscendHub 下架**(2026-08-17 docker manifest inspect 核实:no such manifest),按默认值已经建不出镜像了。 ### 该PR关联的issue 无关联 issue。 ### 希望检视人员了解: **torch_npu 必须跟着一起动,不动才是脱表。** 查[官方配套表](https://gitcode.com/Ascend/pytorch/blob/master/COMPATIBILITY.md)后发现:torch_npu 2.10 这条线**只配 CANN 9.1.0**(2.10.0.post4 ↔ torch 2.10.0 ↔ CANN 9.1.0),表里**没有 9.0.1 这一行**,而此前钉的 2.10.0.post2 在任何 CANN 版本下都不在表内。所以本 PR 是把这个组合**第一次**放进官方配套表,不是让它离开。docker/base/Dockerfile 顶部那句注释也一并更正了 —— 它原本写着 "torch_npu 2.10.0.post2 ↔ CANN 9.0.x",没有依据。 **报告里的 docker 字段此前在说谎。** _detect_docker() 硬编码返回 "cake-ci / CANN 9.0.0"(源码里自己标着 TODO)。镜像换代、CANN 升到 9.1.0 之后这行字仍原样出现在每一份报告里 —— 一份真实产出的报告同时写着 environment.cann = 9.1.0 和 Docker = cake-ci / CANN 9.0.0,读的人无从判断哪个可信。现在改为三级取值:镜像注入的 CANN_BENCH_IMAGE(docker/eval/build.sh 把自己的 tag 传进去)→ 容器内但未注入时返回 "container" → 不在容器里返回 None。CANN 版本一律取实际探测值,与 environment.cann 同源,不会再自相矛盾。该字段此前**没有任何测试**,这次补了 6 个。 **docker/dev 的 -devel 提成了 ARG 而不是写死。** AscendHub 的 tag 多了一段 variant 后缀,带编译工具链的是 -devel;评测要编译提交,必须用它。核实过的取值(docker manifest inspect,2026-08-17):CANN_VERSION 9.0.1 / 9.1.0 存在,9.0.0 已下架,9.2.0 未发布;DEVICE 910 / 910b / 950 / a3 / 310p 存在,**910c 不存在**(旧注释写错了);9.1.0 的 910b 与 950 的 -devel 均为 arm64 + amd64 双架构。README 里加了一句提醒:上游 tag 会下架,换版本前先 manifest inspect —— 这次就是没人查,默认值悄悄失效了。 **根 uv.lock 顺带补上了 build。** 它列在根 pyproject.toml 的依赖里,但旧 lock 中没有,已经陈旧;这次重锁时被带出来了。 **已知的、本 PR 没有处理的:** docker/base/uv.lock 与 docker/eval/uv.lock 之间 filelock 和 fsspec 两个包版本不一致(3.29.7/3.32.0、2026.6.0/2026.7.0)。这个漂移**在改动前就存在**,重锁前后完全一致,故未在本 PR 中处理。 ## 改动类型 / Change Type - [ ] Bug 修复 / Bug Fix - [ ] 新功能 / New Feature - [ ] 性能优化 / Performance - [ ] 代码重构 / Refactoring - [x] 文档更新 / Documentation - [ ] 测试相关 / Test - [x] 其它 / Other(依赖版本与镜像基线提升) ## 测试信息 / Testing **UT** —— 1172 passed(mac / CPU-only)。新增 tests/ut/test_setup_info.py 6 个用例覆盖 docker 字段的三条取值路径;**退回改动前 6 个全部失败**(3 fail + 3 error)。另有 6 个 auto_pipeline 进程树用例在 mac 上先前就失败,与本改动无关。 **实机(q7 / 910B2 / aarch64)** —— 用本分支的 lock 重建 docker/base 镜像成功,容器内实测: CANN_VERSION (ENV) = 9.1.0 torch = 2.10.0+cpu torch_npu = 2.10.0.post4 NPU 可用 = True | 卡数 1 H2D/D2H = [0.0, 2.0, 4.0, 6.0] 反作弊姿态保持:docker/base 仍是 toolkit-only(无 ops → 无 libopapi),容器内 torch.matmul 在 NPU 上**失败**,即内置算子仍不可达。(实测报错为 SetPrecisionMode:...LazyInitAclops NPU function error;与 docker/eval 文档记录的 561103 症状不同,本 PR 未深究该差异,只确认姿态未被升级破坏。) 改后的 docker 字段实机实测: 裸镜像(未注入) docker = container / CANN 9.1.0 注入 tag 后 docker = cann-bench-eval:1.0.0-ascend910b-aarch64-opsnone / CANN 9.1.0 **未做的:** docker/eval 镜像本身没有在本分支上重建过(9.1.0 的 eval 层此前由 !239 验证过,本 PR 只改默认值);docker/dev 未重建(其 torch/torch_npu 由 AscendHub 基础镜像自带,本仓库不钉,故无 lock 改动)。 - [x] 单元测试通过 / UT passed - [ ] 集成测试通过 / ST passed - [x] 人工验证通过 / Manual verified ## 检查清单 / Checklist - [x] 代码符合规范 / Code follows style guide - [x] 测试添加并通过 / Tests added and passed - [x] 文档已更新 / Docs updated if needed - [x] 无硬编码敏感信息 / No secrets hardcoded - [x] 提交信息符合规范 / Commit message follows convention See merge request: cann/cann-bench!270
1 个月前
uv.lock
chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Co-authored-by: Xinxian Chen<chenxinxian1@huawei.com> # message auto-generated for no-merge-commit merge: !270 merge chore/cann-9.1.0 into master chore(docker): 评测镜像默认升到 CANN 9.1.0, 并让报告的 docker 字段属实 Created-by: vINyLogY Commit-by: Xinxian Chen Merged-by: cann-robot Description: ### PR功能描述 / 为什么需要这个合入**: 镜像的默认 CANN 版本一直停在 9.0.1,而 CI 流水线的评测 pod 和 q7 都已经在跑 9.1.0 —— 也就是说"评测镜像"和"实际跑 ST 的地方"不是同一个 CANN。 !239(标题带 9.1.0)做的是"**让** 9.1.0 可用":删掉 docker/eval 里硬编码的版本与 ops URL,改成从 base 继承 + 可推导,并核实了四个 .run 都在。默认值本身没在那次的改动范围内,ARG CANN_VERSION=9.0.1 从 718a75d 建立起就没动过。 docker/dev 的情况更直接:它的默认基础镜像 ascendhub/cann:9.0.0-910b-ubuntu22.04-py3.12 **已经从 AscendHub 下架**(2026-08-17 docker manifest inspect 核实:no such manifest),按默认值已经建不出镜像了。 ### 该PR关联的issue 无关联 issue。 ### 希望检视人员了解: **torch_npu 必须跟着一起动,不动才是脱表。** 查[官方配套表](https://gitcode.com/Ascend/pytorch/blob/master/COMPATIBILITY.md)后发现:torch_npu 2.10 这条线**只配 CANN 9.1.0**(2.10.0.post4 ↔ torch 2.10.0 ↔ CANN 9.1.0),表里**没有 9.0.1 这一行**,而此前钉的 2.10.0.post2 在任何 CANN 版本下都不在表内。所以本 PR 是把这个组合**第一次**放进官方配套表,不是让它离开。docker/base/Dockerfile 顶部那句注释也一并更正了 —— 它原本写着 "torch_npu 2.10.0.post2 ↔ CANN 9.0.x",没有依据。 **报告里的 docker 字段此前在说谎。** _detect_docker() 硬编码返回 "cake-ci / CANN 9.0.0"(源码里自己标着 TODO)。镜像换代、CANN 升到 9.1.0 之后这行字仍原样出现在每一份报告里 —— 一份真实产出的报告同时写着 environment.cann = 9.1.0 和 Docker = cake-ci / CANN 9.0.0,读的人无从判断哪个可信。现在改为三级取值:镜像注入的 CANN_BENCH_IMAGE(docker/eval/build.sh 把自己的 tag 传进去)→ 容器内但未注入时返回 "container" → 不在容器里返回 None。CANN 版本一律取实际探测值,与 environment.cann 同源,不会再自相矛盾。该字段此前**没有任何测试**,这次补了 6 个。 **docker/dev 的 -devel 提成了 ARG 而不是写死。** AscendHub 的 tag 多了一段 variant 后缀,带编译工具链的是 -devel;评测要编译提交,必须用它。核实过的取值(docker manifest inspect,2026-08-17):CANN_VERSION 9.0.1 / 9.1.0 存在,9.0.0 已下架,9.2.0 未发布;DEVICE 910 / 910b / 950 / a3 / 310p 存在,**910c 不存在**(旧注释写错了);9.1.0 的 910b 与 950 的 -devel 均为 arm64 + amd64 双架构。README 里加了一句提醒:上游 tag 会下架,换版本前先 manifest inspect —— 这次就是没人查,默认值悄悄失效了。 **根 uv.lock 顺带补上了 build。** 它列在根 pyproject.toml 的依赖里,但旧 lock 中没有,已经陈旧;这次重锁时被带出来了。 **已知的、本 PR 没有处理的:** docker/base/uv.lock 与 docker/eval/uv.lock 之间 filelock 和 fsspec 两个包版本不一致(3.29.7/3.32.0、2026.6.0/2026.7.0)。这个漂移**在改动前就存在**,重锁前后完全一致,故未在本 PR 中处理。 ## 改动类型 / Change Type - [ ] Bug 修复 / Bug Fix - [ ] 新功能 / New Feature - [ ] 性能优化 / Performance - [ ] 代码重构 / Refactoring - [x] 文档更新 / Documentation - [ ] 测试相关 / Test - [x] 其它 / Other(依赖版本与镜像基线提升) ## 测试信息 / Testing **UT** —— 1172 passed(mac / CPU-only)。新增 tests/ut/test_setup_info.py 6 个用例覆盖 docker 字段的三条取值路径;**退回改动前 6 个全部失败**(3 fail + 3 error)。另有 6 个 auto_pipeline 进程树用例在 mac 上先前就失败,与本改动无关。 **实机(q7 / 910B2 / aarch64)** —— 用本分支的 lock 重建 docker/base 镜像成功,容器内实测: CANN_VERSION (ENV) = 9.1.0 torch = 2.10.0+cpu torch_npu = 2.10.0.post4 NPU 可用 = True | 卡数 1 H2D/D2H = [0.0, 2.0, 4.0, 6.0] 反作弊姿态保持:docker/base 仍是 toolkit-only(无 ops → 无 libopapi),容器内 torch.matmul 在 NPU 上**失败**,即内置算子仍不可达。(实测报错为 SetPrecisionMode:...LazyInitAclops NPU function error;与 docker/eval 文档记录的 561103 症状不同,本 PR 未深究该差异,只确认姿态未被升级破坏。) 改后的 docker 字段实机实测: 裸镜像(未注入) docker = container / CANN 9.1.0 注入 tag 后 docker = cann-bench-eval:1.0.0-ascend910b-aarch64-opsnone / CANN 9.1.0 **未做的:** docker/eval 镜像本身没有在本分支上重建过(9.1.0 的 eval 层此前由 !239 验证过,本 PR 只改默认值);docker/dev 未重建(其 torch/torch_npu 由 AscendHub 基础镜像自带,本仓库不钉,故无 lock 改动)。 - [x] 单元测试通过 / UT passed - [ ] 集成测试通过 / ST passed - [x] 人工验证通过 / Manual verified ## 检查清单 / Checklist - [x] 代码符合规范 / Code follows style guide - [x] 测试添加并通过 / Tests added and passed - [x] 文档已更新 / Docs updated if needed - [x] 无硬编码敏感信息 / No secrets hardcoded - [x] 提交信息符合规范 / Commit message follows convention See merge request: cann/cann-bench!270
1 个月前
README

cann-bench docker/base -- 最小 toolkit-only 直调基础镜像

与 docker/dev(AscendHub 完整 CANN,含 ops/nnal 的调试/CI 镜像)互补,并且是 docker/eval (评测镜像)的底座。本镜像只装 CANN toolkit(bisheng + AscendC 头 + acl runtime)+ torch(cpu)/torch_npu 胶水,不装 ops (libopapi + kernel blob)/nnal,面向 直调(direct-launch)风格提交 -- 提交自带 bisheng 编译的 AscendC/CCE kernel,经 KNAME<<<grid, nullptr, stream>>> 直接下发,不走 aclnn,故 ops 是死重。

docker/dev(AscendHub 全量) docker/base(本镜像)
base AscendHub 完整 CANN(cann:<ver>-<device>-...,per-device) debian:12-slim,从 .run 自装 toolkit
ops / nnal 有 无(0 ops)
chip per-DEVICE tag chip-agnostic(chip 只进 mounted driver + bisheng --soc)
CPU 架构 per-tag ARCH build-arg(aarch64 / x86_64),原生构建;写入 ENV CANN_ARCH 供下游继承
py / env ubuntu22.04 + py3.12 uv 管理的 py3.13 standalone(uv.lock 锁定)
适用 全量评测(含 aclnn baseline + perf 开箱) 直调提交:精度独立可跑;perf 见下

为什么(直调 / 反作弊)

直调 kernel 自带实现,不蹭内置优化算子 -- 这正是反作弊(anti-cheat)想要的形态。本镜像根本不含 内置 kernel 树,提交无从蹭起;相比在完整镜像上运行时搬走 4.2G kernel 树的做法(见 scripts/anti_cheat/),这里天然如此,且镜像更小、chip-agnostic、自包含(不依赖体积大且受限的 AscendHub per-device 镜像)。

Build

cd docker/base/
docker build --build-arg ARCH=$(uname -m) -t cann-toolkit-base:9.1.0-py3.13 .

镜像架构由 ARCH build-arg 决定(aarch64 / x86_64,默认 aarch64),必须在目标架构的 机器上原生构建 —— 没有交叉编译、没有 --platform。两种架构都已实测跑通(aarch64/910B2 与 x86_64/950PR:装 toolkit、同一份 lock uv sync --frozen、stub libhccl、编 cann_bench_utils、 认卡)。构建结果会把架构写进 ENV CANN_ARCH,docker/eval 继承它来挑对应架构的 ops 包 —— 所以下游不该、也不需要再声明自己的 ARCH。

python 依赖由 pyproject.toml + uv.lock 锁定(hash 校验),uv sync --frozen 装入 /opt/venv。

镜像源(每个都默认走官方/全球源;受限网络用 --build-arg 换在区镜像)

build-arg 默认(官方) 换镜像示例(CN)
BASE_OS debian:12-slim(docker.io) docker.m.daocloud.io/library/debian:12-slim
UV_IMAGE ghcr.io/astral-sh/uv:0.11.29 ghcr.m.daocloud.io/astral-sh/uv:0.11.29
APT_MIRROR (空 = deb.debian.org) mirrors.huaweicloud.com
UV_PYTHON_INSTALL_MIRROR (空 = github releases) https://mirror.nju.edu.cn/github-release/astral-sh/python-build-standalone
PYPI_MIRROR (空 = files.pythonhosted.org) https://mirrors.huaweicloud.com/repository/pypi
TORCH_MIRROR (空 = download.pytorch.org) https://mirror.nju.edu.cn/pytorch/whl/cpu
CANN_VERSION 9.1.0 toolkit .run 版本(从 OBS 拉取);落到 ENV CANN_VERSION 供 docker/eval 继承
CANN_TOOLKIT_URL 空(由 CANN_VERSION + ARCH 推导) 只在该版本不按常规命名/不在常规 bucket 时设,见下
ARCH aarch64 aarch64 / x86_64;决定 toolkit .run、<arch>-linux/ 路径,并落到 ENV CANN_ARCH

换 CANN 版本

正常只需 --build-arg CANN_VERSION=<版本> —— toolkit 和 ops 两个包在 ascend-repo.obs.cn-east-2 上的命名跨版本一致,docker/eval 会继承 ENV CANN_VERSION 去推导同版本的 ops:

# base
docker build --build-arg CANN_VERSION=<版本> --build-arg ARCH=$(uname -m) \
             -t cann-toolkit-base:<版本>-py3.13 .
# eval (build.sh 用 CANN_VERSION 只是为了拼 BASE_IMAGE 的 tag)
CANN_VERSION=<版本> NPU_ARCH=ascend950 bash ../eval/build.sh

换版本时 torch_npu 要按官方配套表 重新选:把 docker/base/pyproject.toml 与 docker/eval/pyproject.toml 的 torch-npu 改成 新 CANN 版本在表里对应的串号,再重新 uv lock。表里没有对应行的 CANN 版本不要用 —— 那样钉出来 的组合官方没有验证过,理由见下一节。

CANN_TOOLKIT_URL 是给例外准备的:部分版本发在 ascend-cann-open.obs.cn-north-4 上, 或以合并包 Ascend-cann_<版本>_linux-<arch>.run 的形式发布(而非 Ascend-cann-toolkit_...)。

为什么是 9.1.0 + torch_npu 2.10.0.post4

官方配套表里 torch_npu 2.10 这条线只配 CANN 9.1.0(2.10.0.post4 ↔ torch 2.10.0 ↔ CANN 9.1.0),表里没有 9.0.1 这一行,2.10.0.post2 也不在表内。所以本镜像此前的 9.0.1 + 2.10.0.post2 是表外组合; 现在这一档是第一次落在表内。Python 3.13 在该行的支持范围内。

9.1.0 的 toolkit/ops × aarch64/x86_64 四个包均已核实存在。实测(q7 / 910B2 / aarch64): base + eval(OPS_MODE=refonly,顺带验了 9.1.0 的 ops 包)全部建成,--self-test 全绿、 内置算子仍被挡住,一次真实三阶段评测 4/4 通过、得分 74.10(9.0.1 同一提交同一算子是 73.00)。 安装布局也没变(cann-9.1.0/ + latest 符号链接 + ascend-toolkit/set_env.sh)。

PYPI_MIRROR/TORCH_MIRROR 就地改写 uv.lock 里的 canonical wheel URL(同 hash,--frozen 仍校验), 换源不破坏可复现性。CN 全量示例:

docker build -t cann-toolkit-base:9.1.0-py3.13 \
  --build-arg BASE_OS=docker.m.daocloud.io/library/debian:12-slim \
  --build-arg APT_MIRROR=mirrors.huaweicloud.com \
  --build-arg UV_IMAGE=ghcr.m.daocloud.io/astral-sh/uv:0.11.29 \
  --build-arg UV_PYTHON_INSTALL_MIRROR=https://mirror.nju.edu.cn/github-release/astral-sh/python-build-standalone \
  --build-arg PYPI_MIRROR=https://mirrors.huaweicloud.com/repository/pypi \
  --build-arg TORCH_MIRROR=https://mirror.nju.edu.cn/pytorch/whl/cpu .

Run(NPU host)

run.sh 负责 device 挂载 + 把 host driver runtime libs 放上 LD_LIBRARY_PATH(dev 镜像从 AscendHub base 继承,本镜像需显式设):

bash run.sh smoke     # torch_npu device_count / name
bash run.sh shell     # 交互 shell,NPU 已绑入
bash run.sh dev       # 后台 sleep infinity,供 docker exec 调试

评测直调提交

挂载本仓库(src/ + tasks/)+ 提交源码进容器,跑 scripts/run_evaluation.sh:

  • 精度(--no-perf):0 ops 即可,独立可跑。golden 走 CPU,提交 kernel 走 NPU,CPU 对比。
  • 性能:另需两项(均 lean-side,非 ops)——
    • 框架 warmup 算子 cann_bench_utils:无 ops 镜像上内置 torch.matmul / torch.max (升频 / 清 cache)因 LazyInitAclops 不可用,需自定义直调 warmup 顶替(参见 PR #207)。
    • libsqlite3:已烘入本镜像 -- msprof 导出 kernel_details.csv(perf stage 经 torch_npu.profiler 触发)import sqlite3 需要它,debian-slim 默认不带。

不适用

  • aclnn baseline 或任何需内置算子的评测:内置 torch_npu 算子在本镜像上 LazyInitAclops 失败 -> 走 docker/dev 镜像(需 ops),或 docker/eval --build-arg OPS_MODE=full。本镜像专供直调 kernel。