之前接了个内部需求把一套生成式大模型从GPU实验环境迁到昇腾910系列NPU上做大模型训练的正式跑批。整个过程从环境搭建、脚本迁移到分布式调试、规模训练前前后后踩了无数个坑。昇腾不是简单改一行device就能跑通的它有完整的CANN软件栈报错规律、性能瓶颈的表现形式都跟CUDA生态有明显差异但训练全流程的思路又是共通的。这篇文章我把昇腾大模型训练调试调优过程中最值得记录的经验整理出来从全局规划、迁移准备、启动期排查、收敛与性能瓶颈定位写到多机多卡稳定性保障。适合正在做昇腾适配、准备规模化训练或者想了解昇腾训练栈底层逻辑的工程同学参考。我不会把代码逐行贴出来重点是讲清楚每步操作背后的判断依据和排查方向。1. 昇腾大模型训练调优要先建立全局视图1.1 昇腾训练栈里到底有什么先把我自己的理解说清楚。昇腾侧跑训练接触到的从上到下大概可以分成几层业务代码层模型定义、数据加载、优化器逻辑、checkpoint管理。框架适配层如果用的是PyTorch就是torch_npu如果直接走MindSpore就省掉这层适配。CANN软件栈包含图编译、算子调度、通信库等核心能力对应GPU场景大致可以理解为CUDA加cuDNN加NCCL的综合体。驱动与固件层NPU设备的驱动、芯片固件由npu-smi这类工具管理。硬件层昇腾910系列NPU、HBM显存、HCCS内部高速互联、跨机网络的RoCE或高速网卡。这个视图是排障的基础。很多人第一次看到昇腾报错都不知道去哪查原因就是没搞清错误来自哪一层。如果是“module not found”那是Python环境和适配层问题如果是“HCCL timeout”多半在通信层如果是“device side assert”那就是执行到某个NPU算子时数据或shape不满足约束。先把报错定位到具体层再动手处理效率会高很多。提示不要一上来就重装CANN或者重启机器。先看报错前缀、堆栈入口、日志时间点很多时候问题就出在代码里一个张量没有搬运到NPU上。1.2 训练全流程到底分几个阶段大模型训练全流程我习惯分成四个阶段来管理阶段主要目标核心关注点失败时的典型表现开发调试期代码能在单卡或单机上稳定跑通环境、接口、单步loss频繁OOM、算子报错、启动即崩小规模收敛期小数据量验证模型可以收敛loss趋势、精度对齐loss不降、过拟合、梯度异常规模化训练期多卡多机下吞吐和稳定性通信效率、数据管线、超参step效率低、训练中断、收敛震荡交付回归期最终指标验收评测指标、量化精度、复现性评测不过、量化后精度劣化严重每个阶段的调试调优手段侧重点不一样。开发期更多是代码级修复收敛期是超参与数值问题规模化训练期是系统性问题交付期则要综合看精度和算力成本。我见过不少团队在第一个阶段就急着上大规模并行8卡还没跑稳就开始64卡训练结果一个HCCL timeout问题定位了两周。老老实实把全流程的每个阶段划分清楚风险和成本才会可控。1.3 调试方法核心先复现、再二分、后对照昇腾环境的调试调优我个人体会到最有效的三个原则是什么呢先复现多卡训练崩了先想办法用单卡或者更小的并行度复现。如果一个bug只在64卡出现优先检查通信和同步如果单卡就能复现就不用怀疑网络和HCCL配置了。二分离把复杂问题拆成两块来对照。比如loss一直是nan先分别排查数据侧和模型侧做一个只用随机数据跑几步的测试看还会不会有nan。能快速缩小嫌疑范围。后对照对照CPU或已正常运行的GPU基线。同一个模型在CPU上跑出来的数值分布是合理的那么NPU侧如果遇到NaN就可以快速怀疑是混合精度策略或者某个算子行为差异而不是模型逻辑本身出问题。这套方法论看起来朴素却是整个训练调试调优过程中最底层的方法论。遇到一个诡异问题如果不用这套流程很容易东试一个参数西改一个接口最后越改越乱。2. 训练启动前的准备直接决定效率2.1 版本组合要严格配套别乱升级昇腾的版本依赖比NVIDIA生态更敏感。CANN版本、驱动固件版本、torch_npu版本、PyTorch版本之间有一个经过验证的组合矩阵随意升级其中一个经常会把另外几层搞挂。我踩过一次很深的坑为了图新功能单独升级了CANN toolkit结果torch_npu还是旧版运行时报了一堆符号找不到的错后来发现是框架适配层和CANN版本对不上。虽然最后定位也就花了半天但那种报错信息非常反直觉。建议在同一批机器上先固定一套经过验证的版本组合修改前记录当前版本并留下回滚方案。环境里的版本信息可以通过这些方式快速确认npu-smi info cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg pip show torch-npu python -c import torch; print(torch.__version__)重要在昇腾环境里不是版本越新越好而是配套最重要。遇到算子行为异常先问一句“这套组合在官方文档里是否被验证过”2.2 并行策略算好显存再决定DP、TP、PP大模型训练里的并行策略在昇腾侧同样适用核心就是数据并行DP、张量并行TP、流水线并行PP以及ZeRO显存优化。每个策略解决的问题不一样代价也不同。并行方式切分对象通信开销适用场景DP数据复制模型并行训练每步通信梯度量级模型大小模型显存占用不超单卡时最优先TP层内参数切分多卡计算高每层内多次AllReduce单卡已装不下时使用PP层间切分流水线计算低仅传输激活边界超大规模模型配合DP/TPZeRO参数/梯度/优化器状态分片中等按需通信节省显存但不想引入TP时怎么选我通常先粗算一下单卡HBM容量能不能同时放得下模型权重、梯度、优化器状态和激活值。以7B模型在BF16训练为例光权重就是14GB左右Adam优化器状态就更吃显存单张没那么富裕的卡直接跑数据并行其实很勉强。这时候要么上ZeRO要么用TP/PP降低单卡参数持有量然后再叠加数据并行去扩吞吐。昇腾多机通信通常走HCCL单机内部又有HCCS高速互联。多机时TP这类通信频繁的并行策略会比单机慢很多这是硬件拓扑决定的。所以我会尽量在单机内做TP跨机做DP或PP让频繁通信落在高速链路上。2.3 数据管线和中文语料清洗最容易拖后腿训练调试调优阶段大家关注模型结构和loss的时间最多数据管线和语料质量反而容易被忽略。实际上很多“模型不收敛”最后都查到了数据上。我做中文NLP语料全流程实战时总结了一套清洗步骤无论你是做预训练还是微调都值得参考格式解码与转码统一编码到UTF-8处理BOM头转义HTML实体去掉控制字符。噪音还原与过滤除空白、去重行、删除非文本片段广告、导航、免责声明这类重复区块要专门做模板过滤。语言与质量过滤用简单的启发式规则或小型分类器筛掉乱码、夹杂大量英文的文本、无意义字符串。语义去重URL去重、全文哈希可以去掉完全重复的样本SimHash或MinHash可以做近似去重。隐私与合规过滤识别并去除电话号码、身份证号、银行卡号等PII信息。采样抽检清洗后按来源或聚类方式抽样人工浏览一遍确认没有误伤高质量内容。此外数据管线的吞吐也会直接影响整体训练效率。有一次模型step time忽高忽低观察NPU利用率后发现大量时间在等数据。解决办法很常规开多个prefetch worker、启用异步数据加载、把数据先缓存在本地高速盘预处理尽量从训练主程序中分离出来。调试调优不能只盯着计算Host端的数据供给同样重要。3. 模型迁移与首次启动的实战调试3.1 GPU代码搬到昇腾第一轮至少要改这些位置如果你的模型原本是PyTorch加CUDA写的迁移到昇腾最直接的方案是换用torch_npu适配层。名义上是“换卡”实际要改动的地方还是不少。基础样例是这样import torch import torch_npu torch_npu.npu.set_device(0) device torch.device(npu:0) model create_model().to(device) optimizer create_optimizer(model.parameters()) # 原来调用 model.cuda(); 现在改 model.npu()但要小心这只是第一步。工程里常见的还有很多隐藏依赖torch.cuda.xxx系列接口要逐步替换为torch.npu.xxx例如torch.cuda.synchronize()对应torch.npu.synchronize()。apex里的混合精度和FusedAdam等优化器不一定有昇腾侧的直接实现更稳妥的做法是改造为torch_npu提供的AMP接口和原生优化器。自定义CUDA算子需要迁移到昇腾的算子实现团队如果积累了大量CUDA Kernel这部分工作量不会小。模型中存在依赖纯CUDA行为的逻辑比如某些原子操作或自定义AllReduce要特别谨慎。所以每次迁移前我会先跑一个静态扫描把代码里所有cuda调用点列出来再逐个处理而不是启动后靠报错来找。提示迁移不是“格式化替换”。有些地方命名上不是cuda实际却隐式把Tensor搬到了GPU这类问题往往要靠运行时报错才能发现。先写一个只有少量测试样本的冒烟脚本把每个模块过一遍是最高效的验证方式。3.2 首次启动后的三看看资源、看状态、看日志很多同学迁移成功后看到loss正常往下掉就放心跑着了但我建议首次启动后不要急着看loss先做“三看”。一看资源占用。用npu-smi info确认每张NPU的HBM占用、温度、功耗和利用率是否都在合理范围。如果只有一张卡在跑而其他卡空闲并行配置十有八九有问题。二看通信状态。多卡场景下观察HCCL是否能正常建链启动日志里有没有节点握手信息。分布式集合通信如果初始化失败一般会在前几百行日志里暴露出来。三看日志节奏。昇腾侧运行日志分散在不同层级除了应用自己的日志还要了解plog这类设备侧日志。出现CANN层异常时应用层堆栈往往不完整plog反而能看到更底层的错误细节。如果环境里装了CANN性能工具可以在首轮训练时顺手做一次profiling看算子执行时间和通信等待时间。基础命令示例msprof --applicationbash train_script.sh --output./profiling_dir不过具体参数在不同CANN版本里可能存在差异建议以官方工具指导为准。首次训练宁可多采集一份profile也不要等跑出性能问题再回过头来补数据。3.3 启动期最常遇到的报错长什么样启动期的报错通常可以归成几类我整理了个速查表报错或表现可能方向处理思路module not found / no module named torch_npu环境与版本确认torch_npu安装和Python环境版本是否匹配device-side assert triggeredshape或数值不满足算子约束打印输入shape、dtype和值范围核对模型本身out of memoryHBM不足或碎片化降低batch size、开启重计算、用ZeRO或并行策略HCCL timeout分布式通信异常检查网卡、rank配置、防火墙、单机内HCCS链路loss不更新参数没参与训练或通信异常先单卡验证再检查梯度聚合无论遇到哪个先把场景缩小到最小复现单元比盲目改参数重要得多。我第一次跑7B模型时报了一个非常隐晦的设备侧错误后面不断减小batch和seq_len才定位到是某个样本长度组合触发了算子的边界条件。4. 收敛问题与性能瓶颈逐层调优4.1 loss曲线不对先别急着动超参模型能跑起来只是第一步训练全流程里最磨人的阶段是在大规模训练前把收敛问题调干净。loss曲线不对常见的形态有几种loss直接变成NaN或inf大概率是数值异常不再止步于“调小学习率”要先看梯度里是否有inf、激活值是否有异常、混合精度的loss scaling是否合理。loss长期不降先确认数据标签是否错乱、模型参数有没有被优化器更新。有时候是训练脚本里不小心把某个参数requires_grad设成了False。loss下降然后震荡反弹学习率过大、batch size变化导致梯度噪声变化、数据分布不均匀都可能造成不要一次性调很多参数。loss卡在某个值不动了看看是不是某个分支把loss直接掩码掉或者模型输出range遇到了饱和区域。遇到NaN时我的排查顺序通常是这样先固定随机种子用小数据跑几步逐步关闭混合精度切到FP32看是否还出现NaN。如果FP32正常问题基本可以锁定在混合精度或某个数值敏感算子如果FP32依然NaN那就要回到数据侧。注意混合精度训练里loss scaling的初始值和动态调整策略非常关键。在昇腾环境里虽然框架适配层自动做了很多工作但梯度中出现inf时还是要优先检查scaling策略而不是一股脑把学习率调低。4.2 用Profiling数据判断瓶颈在哪性能调优不能靠猜要用数据说话。step time不达标先区分瓶颈是卡在计算、数据还是通信。具体做法是先做一次profiling然后看三个指标NPU计算密度AI Core利用率是否达到较高的水位。如果很低说明计算不是瓶颈。Host侧耗时占比如果数据加载和Python预处理耗时占比很高说明数据管线在拖后腿。把预处理放到独立的DataLoader加大预取和缓冲。通信等待时间多卡训练中每个step里等待AllReduce或者其他集合通信的时间。如果通信等待占大头先看并行策略和网络拓扑是否合理。举例来说有次单机8卡训练7B模型发现单卡AI Core利用率不错但整体step time不稳定。后来profiling发现Host端每步都会调用一些同步接口导致Device反复等待。把那几个不必要的npu.synchronize删掉整体吞吐直接上了一个台阶。profiling是调优中投资回报最高的工具不要只会用time.time()包在训练循环外面测总时长。看分布、看占比、看热点比看平均时间更能暴露真实问题。4.3 算子级别优化融合和减调度开销如果瓶颈确认在算子计算段就需要深入到算子和图层面了。昇腾侧训练时CANN会经过图编译很多小算子会被自动融合但并不是所有情况都完美。我见过最典型的性能问题有两种第一种是小算子过多。一个Transformer layer内的逐元素操作、shape处理如果拆得太散Kernel启动和调度开销就会很高。解决方向是尽量使用融合算子比如把LayerNorm、激活函数、线性层组合成计算图上更大的节点。CANN图优化会处理一部分但模型代码本身写法上的冗余也要清理。第二种是动态shape触发重编译。如果训练过程中输入长度频繁变化或者某些分支导致shape不确定图编译会反复进行性能损耗非常大。大模型训练通常会把序列长度固定下来动态shape在推理阶段做验证还能接受在训练阶段会让性能非常难看。算子调优不可能在团队里每个人都做得非常深但至少要掌握一个判断模型脚本改成更融合的写法后profiling里算子的总执行时间是不是真的下降了。这个能力在昇腾调试调优里很值钱。4.4 混合精度和INT8量化调优要分开看大模型训练全流程里BF16/FP16混合精度几乎是标配。昇腾910系列对FP16、BF16的支持已经比较成熟实际使用中需要注意几点FP16的动态范围较小容易产生梯度下溢或溢出。训练初期可以比较FP32和FP16的loss曲线差异。BF16的指数范围更大训练稳定性更好但尾数精度低对需要高精度的累积计算要设置得当。GradScaler在昇腾侧要用框架适配层提供的AMP模块实现不要直接搬CUDA版的老写法。很多团队训练完成后还希望做INT8量化再部署比如对Qwen这类模型做INT8量化节省推理资源。调优时要知道训练调优和量化调优是两回事任务环节精度类型典型目标主要风险模型训练FP32/BF16/FP16收敛、稳定、精度达预期数值溢出、loss不稳定训练后量化INT8压缩体积、提升推理吞吐精度劣化、敏感算子异常量化感知训练QAT模拟量化算子减少量化精度损失训练流程复杂、超参敏感对量化模型做精度验收时不要只看整体指标最好按领域或类别拆分评测。某些边角case精度损失会显著高于平均如果只关注整体loss容易漏掉真实劣化。5. 多机多卡规模化训练的稳定性调优5.1 HCCL分布式通信最怕静默卡死模型跑通到多机多卡后训练稳定性成了最大的坑。我个人体会是性能问题往往有一个明确的瓶颈曲线而稳定性问题则更折磨人因为它可能跑十几个小时才复现一次。HCCL在昇腾分布式训练里的角色类似NCCL负责跨卡同步和通信。多机训练中HCCL建链、网络拓扑检查、rank配置如果任何一个环节不对都会导致超时或者同步中断。遇到“训练卡住不动、日志也不报错”的情况第一件事不是杀进程而是观察所有进程的状态。单机多卡还容易处理多机之间就要确认每台机器的网卡、IP、rank顺序是否完全一致。排障时我常用这三板斧先查npu-smi info看每张NPU的HBM和利用率如果全部为0且没有新日志大概率是死锁或等待。把通信范围缩小到单机8卡如果能正常跑但加上跨机就卡重点查网络链路。查看三方库是否出现HCCL相关错误逐步调高通信超时时间但不能只靠调超时来掩盖根本问题。提示多机训练前建议先完成一次单独的集合通信测试确认拓扑和带宽都满足要求再启动真实的业务训练。直接启动大任务去验证环境出了问题既难定位又浪费机时。5.2 断点续训checkpoint不能只存模型权重一次大规模训练跑几天甚至几周中间单卡故障或者机房断电不是小概率事件。断点续训如果做得不完整损失的不只是时间有可能造成模型状态被破坏。一份可靠的checkpoint至少应该包含checkpoint { model: model.state_dict(), optimizer: optimizer.state_dict(), lr_scheduler: lr_scheduler.state_dict(), epoch: epoch, global_step: global_step, rng_state: torch.get_rng_state(), npu_rng_state: torch.npu.get_rng_state(), dataloader_state: dataloader_snapshot, } torch.save(checkpoint, fcheckpoint_step_{global_step}.pt)为什么需要存rng_state不存的话即使模型恢复到之前的精度后续训练的数据顺序和数据增强序列也和断点前不一致复现性和稳定性都会受影响。多卡训练时每张卡的随机状态要分别保存。恢复时要特别注意模型状态在CPU还是NPU。加载权重后需要调用对应的.to(device)或.npu()回到NPU上优化器状态也需要重新构建。很多恢复后loss异常的情况都是因为状态加载不全或加载到了错误的设备。5.3 长时间训练的监控与巡检训练稳定性不只是代码问题还涉及硬件和运维。昇腾设备长时间高负载训练下散热、电源、HBM健康都可能出现隐患。建议在训练环境里做一套基础巡检每5分钟记录一次npu-smi输出包括NPU温度、功耗、HBM使用量。对日志做关键字告警覆盖error、timeout、assert、oom等高频故障词。训练进程崩溃后要有自动重启脚本重启前保存当前checkpoint并记录崩溃现场。很多人会忽略一个细节一旦训练任务跑起来日志会被大量step信息淹没。不要把告警阈值设得过高否则一个小故障出现十几分钟训练半天白跑。我会把所有训练日志单独归档打印关键节点保存权重、梯度统计、eval结果时加上时间戳方便事后回溯。6. 从大模型训练的通用方法到更多场景迁移6.1 三维重建等生成式任务的调试调优同样适用大模型训练一词容易让人以为只有NLP或基础大模型才需要这套流程。实际上昇腾侧近几年也越来越多地跑三维重建、生成式模型这类任务比如3DGS三维重建。如果是图形学团队的人刚接触昇腾他们的挑战往往不在模型结构而在训练流程和算子习惯差异上。三维重建任务的特征是样本量极大且每个场景独立优化调试时很像“一个场景一次小训练”。它同样会遇到显存峰值过高、梯度不稳定、多卡吞吐上不去这些问题。我接触过的3DGS调优场景里最大的瓶颈其实是数据和预处理位姿数据、相机参数、图像分辨率只要稍有异常训练过程就会产生大量无效迭代。这跟我们做NLP训练时语料清洗、质量抽检的逻辑完全一样。不要把昇腾调优理解成只服务于大语言模型。它的本质是NPU训练任务的全流程管理数据准备、模型适配、数值检查、性能分析和可靠性保障这些在不同任务形态里是通用的。6.2 使用开源训练平台与工具链的组合拳很多同学还会问“昇腾大模型训练有没有开源的大模型训练平台可以用”这取决于需求层级。如果你只求环境管理昇腾官方生态里有对应的框架源码和模型样例可供参考如果你需要完整的训练、监控、调度能力开源社区也有不少可组合的方案。我在实际项目中倾向于组合开源工具而不是押注某一个大而全的平台。比如用PyTorch加torch_npu做训练框架用HCCL相关的通信测试脚本去验证集群用CANN自带的profiling工具做性能分析再用开源的日志采集组件做告警。整个链路里的每个环节都可以单独验证、替换遇到问题定位也更清楚。训练平台不是越复杂越好。大而全的平台虽然省事但出了问题你往往不知道它内部在做什么这对调试调优其实是很大的负担。建议先盘点自己团队的实际需求是缺算力调度还是缺实验管理还是缺可视化训练看板。针对性地补组件比直接上一套复杂系统更可控。昇腾大模型训练的调试调优本质上就是在一条还不算完全标准化、但已经有清晰生态雏形的技术栈上做事。我的体会是不要把它当作“换卡”要把它当作一次完整的工程迁移和全流程打磨。版本组合固定好、数据侧先做扎实、调试方法按复现到对照来闭环、性能分析依赖profiling而不是猜测、checkpoint和日志按故障恢复标准做扎实这几件事做对了哪怕换了新任务新模型这套方法也能帮团队少走很多弯路。