HPC高性能计算圈子里不用 pip 和 conda——用 Spack。Spack 是一个专为科学计算设计的包管理器能同时管理一个软件包的多个版本不同编译器、不同依赖版本、不同架构每个变体独立安装在spack/opt/下互不冲突。cann-spack-package 把 CANN 的整套工具链编译器、算子库、驱动、运行时打包成 Spack 包让 HPC 中心可以一键在集群上部署 CANN。Spack 的核心理念Spack 的包管理哲学和 pip/conda 完全不同 pip install torch2.0.0 → 只能装一个版本的 PyTorch spack install py-torch2.0.0%gcc11.2.0 spack install py-torch2.0.0%gcc12.1.0 spack install py-torch2.1.0%gcc11.2.0cuda → 三个 PyTorch 2.0.0 实例共存 不同编译器、不同版本、不同 CUDA 支持 关键技术spec 字符串 py-torch2.0.0%gcc11.2.0cuda archlinux-rhel8-x86_64 ↑ ↑ ↑ ↑ ↑ 包名版本 编译器 变体(variant) 目标架构(arch)Spec 字符串是 Spack 的身份证——每个包的唯一标识。module load时直接指定 spec加载精确的那一个包。CANN 的 Spack 包cann-spack-package 把 CANN 的每个组件打包成 Spack 包# 查看 CANN 相关的 Spack 包spack list ascend# 输出# ascend-cann # CANN 全套工具链meta-package# ascend-toolkit # CANN 开发工具包编译器算子库# ascend-driver # NPU 驱动# ascend-firmware # NPU 固件# ascend-runtime # CANN 运行时# ascend-mindspore # MindSpore 框架CANN 后端# ascend-pytorch # PyTorch CANN 适配# ascend-ops-advanced # 进阶算子ops-transformer 等# 安装 CANN 8.0 全套spackinstallascend-cann8.0.0%gcc11.2.0archlinux-rhel8-x86_64# 这个命令会# 1. 安装 gcc11.2.0如果没装# 2. 安装 npu-driver依赖# 3. 安装 npu-firmware依赖# 4. 安装 ascend-toolkit核心# 5. 安装 ascend-runtime# 6. 安装 ascend-pytorch可选# 整个依赖树自动解析、自动安装、自动激活多版本共存HPC 集群的真实需求32 个节点22 个跑 CANN 8.0稳定版10 个跑 CANN 8.5 RC测试新特性。Spack 天然支持多版本共存。# 同时安装两个 CANN 版本spackinstallascend-cann8.0.0 spackinstallascend-cann8.5.0# 查看已安装的版本spackfindascend-cann# -- linux-rhel8-x86_64 / gcc11.2.0 -----------# ascend-cann8.5.0 /abc123# ascend-cann8.0.0 /def456# version 8.5.0 在上层默认# version 8.0.0 也在系统中可用不会冲突# 切换版本spack load ascend-cann8.0.0# 环境变量已更新# LD_LIBRARY_PATH → .../spack/opt/.../ascend-cann-8.0.0/...# ASCEND_HOME_PATH → .../spack/opt/.../ascend-cann-8.0.0/# 验证npU-smi version# CANN 8.0.0# 换到 8.5spack unload ascend-cann spack load ascend-cann8.5.0 npU-smi version# CANN 8.5.0两个版本共享同一个 Node通过 Spack 的module机制控制版本切换——不会污染系统级LD_LIBRARY_PATH。Spack 的环境锁定和 reproducibilityHPC 集群的一个关键需求是 reproducibility可重复性——3 个月前集群运行的训练结果现在重建集群应该跑出一模一样的结果。Spack 用spack.lock文件锁定所有依赖的精确版本。# 创建 spack environmentspackenvcreate cann-training-env spackenvactivate cann-training-env# 添加所有需要的包spackaddascend-cann8.0.0%gcc11.2.0 spackaddascend-pytorch2.1.0%gcc11.2.0 spackaddascend-ops-advanced8.0.0 spackaddpy-numpy1.24.0 spackaddpy-transformers4.36.0# 环境生效 → 每个包的精确依赖被锁定spackinstall# 导出锁文件spack.lock → 包含所有依赖的精确 hash 和版本spackenvlock# 3 个月后从锁文件重建一模一样的集群环境spackenvcreate cann-training-env-repro spackenvactivate cann-training-env-repro spackenvlock--file../cann-training-env/spack.lock spackinstall# 保证所有依赖版本和 3 个月前完全一致锁文件记录了 100 个依赖的精确 hash包括 gcc、cmake、mpi、python 本身在相同硬件上重现完全一致的软件栈。踩坑一Spack 的 concretization 时间过长Spack 的 concretization依赖解析是 NP 困难问题——100 个包各有 3-5 个版本选择3 个编译器版本树搜索空间巨大。CANN 的依赖树尤其深ascend-cann → ascend-toolkit → 20 个底层库。# 直接 concretize —— 可能卡几分钟spack spec ascend-cann8.0.0%gcc11.2.0# 输出截断# Input spec# --------------------------------# ascend-cann8.0.0%gcc11.2.0## Concretized# --------------------------------# ascend-cann8.0.0%gcc11.2.0 archlinux-rhel8-x86_64# ^ascend-toolkit8.0.0%gcc11.2.0# ^nccl2.18.3%gcc11.2.0# ^openmpi4.1.5%gcc11.2.0# ^hwloc2.9.1%gcc11.2.0# ^libxml22.10.3%gcc11.2.0# ^xz5.4.1%gcc11.2.0# ^ascend-runtime8.0.0%gcc11.2.0# ^ascend-driver8.0.0# ...100 行截断## Time: 3m42s ← 解析耗时优化用--reuse复用已 conreteized 的依赖。# 第一次 concretize耗时最长spackinstallascend-cann8.0.0# 第二次 concretize--reuse 复用之前的解析结果spackinstallascend-pytorch2.1.0--reuse# 大部分依赖已经在第一次 concretize 中解析过了# Time: 12s比 3m42s 快 18×踩坑二CANN 的固件和驱动版本锁定CANN 8.0 的 driver 8.0 和 firmware 8.0 是一对绑定的——用 CANN 8.0 的 driver 配合 8.5 的 firmware 会导致驱动兼容性问题。但 Spack 的版本管理不识别这种「硬绑定」关系——它只关心包级别的依赖不关心固件和驱动的物理兼容性。错误# 用户想「只升级 firmware 到 8.5」spackinstallascend-firmware8.5.0# Spack 不会报错——因为 ascend-firmware 和 ascend-driver 在 spec 上没有硬性依赖# 物理上8.5 firmware 8.0 driver → NPU 初始化失败正确在 Spack 包定义里添加conflicts约束。# cann-spack-package/packages/ascend-driver/package.pyclassAscendDriver(Package):version(8.0.0,sha256...)version(8.5.0,sha256...)depends_on(ascend-firmware8.0.0,when8.0.0)depends_on(ascend-firmware8.5.0,when8.5.0)# 显式冲突检查conflicts(8.0.0,msgascend-driver8.0 requires ascend-firmware8.0.0 (not 8.5.0))加了conflicts后Spack 的 concretizer 会自动拒绝不兼容的组合。踩坑三Spack 编译 CANN 时依赖的 C 标准库版本CANN 8.0 的某些组件内部用了 C17 特性std::optional、if constexpr。如果系统中只有 gcc7.5最大支持 C14编译会失败。# 错误系统默认 gcc 版本太老spackinstallascend-cann8.0.0%gcc7.5.0# 编译错误# error: if constexpr is a C17 feature# error: std::optional is not available with this compiler# Spack 不会自动升级 gcc——它用你指定的编译器正确在 Spack 包定义里加depends_onconflicts。classAscendCann(Package):# 显式声明最低编译器版本conflicts(%gcc:8.0,msgCANN requires GCC 8.1 (C17 support))depends_on(gcc8.1:,typebuild)如果系统 GCC 版本太老Spack 会自动先装 gcc8.1然后用这个编译器编译 CANN——这一切都是自动处理的。cann-spack-package 的价值在于把 CANN 融入 HPC 集群的标准化工作流。大多数 HPC 中心已经用 Spack 管理 GCC、OpenMPI、FFTW、NetCDF 等 200 个科学计算软件包——CANN 作为 Spack 包接入后可以一键部署、多版本并存、锁文件 reproducibility。这不是为开发者提供便利开发者用 pip 就够了而是为集群管理员提供便利——CANN 的生产环境部署需要统一管理工具链版本。