AI 纪元 追踪人工智能最新进展,深度解读前沿技术

910C和H200混部,坑在环境里

昇腾910C和H200放进同一套集群,难点不只是驱动安装。CANN、CUDA、HCCL、容器环境和调度策略都要拆开看,尤其要避免环境变量、通信库和拓扑配置互相干扰。

0 次阅读 约 2359 字 5 分钟 AI 生成
A conceptual editorial image showing two distinct, isolated server racks or network paths merging into a single complex infrastructure, symbolizing mixed-hardwa
A conceptual editorial image showing two distinct, isolated server racks or network paths merging into a single complex infrastructure, symbolizing mixed-hardwa

910C和H200混部,坑在环境里

一台H200服务器已经跑着CUDA任务,旁边新上架的昇腾Atlas节点准备接推理负载。看起来只是把两类设备纳入同一个资源池,实际落地时,最先出问题的往往不是模型,而是驱动、环境变量和通信库。

华为在2025年全联接大会上提到,华为云AI研发团队从春节开始到4月30日,经过多团队协同,使Ascend 910B/910C的推理能力达成客户的基本需求。这个背景很关键:910C已经进入更多实际部署场景,但它和H200不是同一种工程习惯。把GPU和NPU混在一起用,不能指望一套脚本跑到底。

驪动先别急着装,版本关系要对齐

在NVIDIA环境里,很多人习惯先装CUDA,再处理驱动和框架。昇腾侧要换一种思路。CANN、驱动、固件、框架适配包之间有对应关系,顺序和版本都不能随便混。

华为昇腾相关资料里常见的安装方式,是通过类似 Ascend-hdk-910-npu-driver_23.0.rc1_linux-aarch64.run 的run包安装驱动,并指定安装目录,例如 /usr/local/Ascend。这类命令本身不复杂,真正容易踩坑的是安装前检查不够:内核头文件、系统架构、已有驱动残留、安装路径权限,任何一个没对上,后面都会变成运行时报错。

如果这台机器以前跑过CUDA任务,还要检查NVIDIA相关模块、/usr/local/cuda 软链接和全局环境变量。反过来也一样,H200节点不应该被昇腾环境变量污染。混部不是把所有库都塞进一台机器,而是让每个任务只看到自己该看的东西。

环境变量,比驱动更容易埋雷

npu-smi info 能看到910C,不代表任务能正常跑。很多问题出在运行时环境。

H200任务通常依赖CUDA相关路径;910C任务则会依赖CANN目录、昇腾运行库和适配后的框架包。最常见的事故是把这些路径写进全局 .bashrc,结果一个Shell里刚跑完CUDA任务,另一个Shell启动NPU任务就开始找不到库,或者加载到了不该加载的版本。

生产环境里更稳的做法是容器隔离。H200任务用对应的NVIDIA容器运行环境,910C任务使用昇腾侧所需的CANN和框架镜像。不要让两个体系共享一套Python环境,也不要把CUDA版PyTorch和昇腾适配包混装在同一个虚拟环境里。

如果临时必须在同一台机器上切换,至少把环境变量拆成两个脚本,比如 env_cuda.sh 和 env_ascend.sh,需要时手动 source。这不高级,但能减少很多莫名其妙的 ImportError 和算子加载失败。

HCCL不是NCCL的替身,配置方式要单独看

单卡能跑,只能说明驱动和框架基本可用。到了多卡、多节点,通信库才开始决定稳定性。

华为云开发者学堂的昇腾学习路径中,把HCCL通信库列为昇腾计算执行引擎基础内容之一。也就是说,在910C集群里,HCCL不是可有可无的组件,而是分布式任务绕不开的部分。

混部环境里要特别避免一种误判:Kubernetes或Slurm能识别设备,不等于通信链路已经准备好。910C节点要看HCCL配置、网卡绑定、节点间网络和拓扑关系;H200节点则是另一套CUDA/NCCL习惯。调度器如果只按“有空卡”分配任务,很容易把作业发到环境没配完整的节点上。

排查HCCL问题时,不要只盯训练脚本。先确认节点间网络是否连通,再看HCCL相关配置文件和日志。拓扑信息也要看,尤其是网卡、PCIe、NUMA之间的关系。通信问题表现出来可能是初始化失败,也可能是训练速度异常慢,日志未必直接告诉你根因。

混部的边界要提前画清楚

昇腾社区官网展示的产品形态里,既有Atlas 900 A3 SuperPoD超节点,也有Atlas 900 A2 PoD集群基础单元。这说明昇腾本身已经是按集群和系统工程来设计的,不只是单卡设备。

但把910C和H200放在一起时,最好不要把它们当成“同一种算力”。更合理的方式是拆成不同资源池:GPU任务走CUDA生态,NPU任务走CANN和昇腾适配框架。上层平台可以统一调度入口,但底层环境、镜像、监控指标和故障处理要分开。

模型侧也要承认差异。同一个Transformer模型,在H200上可能直接走CUDA版PyTorch;到了910C上,则要确认对应框架、算子和编译链路是否支持。能自动化就不要人工改命令,CI/CD里最好把不同后端的构建和测试分开跑。

真正的避坑,是不要假装没有差异

910C和H200混部,最怕的是用“统一算力池”掩盖底层差异。统一入口可以有,统一运维界面也可以有,但驱动、运行库、通信库、框架包和镜像版本不能混着来。

工程上更可靠的顺序是:先让单节点跑通,再验证多卡通信;先固定镜像和版本,再接入调度;先把GPU和NPU资源池拆清楚,再谈弹性分配。

这不是一句“国产芯片适配”能概括的工作。它更像一次系统整理:把CANN、CUDA、HCCL、容器和调度策略各自放回正确的位置。位置对了,910C和H200才有可能在同一套基础设施里稳定干活。

参考来源:

相关阅读