文章目录前言为什么需要训练配方架构拆解三层训练场景预训练从头训练的工程挑战微调SFT 与 LoRA 的效率取舍RLHF训练与推理的混合编排链路实战一个训练任务的启动流程在架构中的位置与其他仓库的协作关系前言把一个 70B 参数的大模型从单卡搬上多机多卡分布式训练需要调多少东西通信拓扑、并行策略、梯度同步、显存分配……随便漏一项就是 OOM 或者通信死锁。昇腾CANN 的 cann-recipes-train 仓库就是来解决这个问题的——它把大模型在昇腾 NPU 上的分布式训练部署方案打包成「配方」让开发者不用从零拼装直接按方抓药跑训练。为什么需要训练配方分布式训练不是「把代码丢到多张卡上就完事」。同样的 LLaMA-2 70BTP8 和 TP4PP2 的显存曲线完全不同MoE 模型的专家并行策略选错了通信开销能吃掉所有算力增益。训练配方的存在逻辑很清晰把「踩坑→调优→验证」这条路上的经验沉淀成可复用的方案而不是让每个团队都从头交一遍学费。传统开发模式下一个训练任务从立项到稳定运行通常要经历以下阶段首先确定模型架构和参数量级然后根据显存估算并行策略接着反复调整 TP/PP/EP 等并行维度配比还要处理集合通信的死锁问题最后才能跑通一个基础版本。这个过程对于 70B 甚至更大规模的模型来说可能需要数周甚至数月的迭代。而且不同团队之间这套经验基本无法复用——A 团队踩过的坑B 团队很可能要再踩一遍。cann-recipes-train 正是为了解决这个问题而诞生的。它不提供全新的训练框架而是把 PyTorch 生态中已经被验证过的分布式训练方案以「配方」的形式组织起来。每个配方本质上是一组经过实测的配置清单模型适配、并行策略、通信调优、显存分配、启动脚本……全都有。最重要的是这些配置不是理论推导而是基于真实集群测试得出的最优解或者接近最优的方案。cann-recipes-train 覆盖了预训练、微调、RLHF 三大训练场景每种场景下提供模型适配、并行配置、启动脚本等一揽子方案。本质上它不是训练框架本身而是训练框架的「最佳实践仓库」。架构拆解三层训练场景预训练从头训练的工程挑战预训练阶段的核心难题是规模——参数量大、数据量大、训练周期长任何效率损失都会被放大。cann-recipes-train 的预训练配方主要解决两件事并行策略选型和通信开销控制。并行策略的选择直接影响训练效率和显存使用。常见的并行维度包括 Tensor ParallelismTP、Pipeline ParallelismPP、Context ParallelismCP和 Expert ParallelismEP。对于 Dense 模型如 LLaMA 系列TPPP 组合是最常见的方案TP 减少单层计算耗时PP 把不同层分到不同设备上降低显存峰值。对于 MoE 模型还需要引入 EP 来处理专家并行的通信开销。# 典型预训练配置示意model_name:llama2-70bparallel_config:tensor_model_parallel_size:8pipeline_model_parallel_size:2context_parallel_size:1/expert_parallel_size:1training_config:batch_size_per_device:4gradient_accumulation_steps:8learning_rate:1e-4warmup_steps:2000num.training_steps:100000配方中会给出不同模型规模下的推荐并行度。这里的推荐并行度不是拍脑袋的数字而是经过显存压力测试和吞吐 benchmark 之后的结果。以 LLaMA-2 70B 为例如果使用 TP8PP2 的配置单机的 8 张 NPU 需要保证每张卡的显存不少于 80GB 才能安全运行如果改为 TP4PP4虽然单卡显存需求降到 40GB 左右但引入了额外的流水线通信开销会增加 15%~20%。这些 tradeoff 都已经在配方中标注清楚。下面是一个典型的大规模预训练环境变量配置用于设置分布式训练的各项参数# 环境变量配置模板exportASCEND_NPUS_PER_HOST8exportHCCL_COMM_WORLD_ROOT0exportRANK_TABLE_FILE/path/to/rank_table.jsonexportPYTORCH_CUDA_ALLOC_confmax_split_size_mb:512exportASCEND_GLOBAL_LOG_LEVEL3rank_table.json 是 HCCL 集合通信初始化所必需的文件描述了所有参与训练的 NPU 节点的 IP 地址和通信端口。配方目录中通常会提供一个脚本来自动生成这个文件开发者只需要修改其中的节点 IP 列表即可。微调SFT 与 LoRA 的效率取舍微调配方覆盖全参微调和参数高效微调PEFT两大类。全参微调Full Parameter Fine-tuningSFT指对模型所有参数进行更新而 PEFT 则只更新附加的部分原始模型参数保持冻结。LoRA 是 PEFT 中最流行的技术方案之一它通过在 Transformer 的注意力层注入低秩矩阵来实现参数高效微调。两者的核心差异在于显存需求和精度表现。全参微调的显存的求近似等于预训练阶段因为梯度、动量、优化器状态都需要存储而 LoRA 把可训练参数压缩到原模型的 0.1% 以下单卡就能跑 7B 参数模型的微调。# LoRA 配置示意frompeftimportLoraConfig,get_peft_model,TaskType lora_configLoraConfig(r16,# LoRA ranklora_alpha32,# scaling factorlora_dropout0.05,# dropout 概率target_modules[q_proj,v_proj,k_proj,o_proj],# 注入的目标模块biasnone,task_typeTaskType.CAUSAL_LM)# 将 LoRA 适配器挂载到基础模型上modelget_peft_model(base_model,lora_config)model.print_trainable_parameters()# 输出类似: trainable params: 4,194,304 || all params: 7,048,192,512 || trainable%: 0.0595但全参微调在精度敏感场景如指令跟随、对齐调优中仍有不可替代性。LoRA 虽然效率高但在某些任务上可能无法达到全参微调的精度水平特别是当需要模型全面学习新的知识体系时。配方会同时给出两条路径的启动方式和配置模板让用户根据自身的精度要求和硬件条件进行选择。微调阶段还需要注意的一个关键点是学习率的调整。由于预训练阶段使用的学习率通常较小全参数情况下约为 1e-4 到 5e-5直接沿用到微调阶段会导致 loss 不收敛或者震荡。经验做法是将学习率提升 10 倍左右同时减小 batch size 以防止过拟合。# 全参微调配置示意model_name:llama2-7bfinetune_config:method:full_parameter# 全参微调learning_rate:5e-5# 较预训练阶段提升batch_size_per_device:2gradient_accumulation_steps:16num_training_epochs:3save_interval_steps:500lora_config:null# 不使用 LoRARLHF训练与推理的混合编排RLHFReinforcement Learning from Human Feedback是目前大语言模型对齐训练的主流技术方案包括三个阶段预训练模型的有监督微调SFT、奖励模型Reward Model的训练、以及基于强化学习通常是 PPO 算法的对齐训练。整个流程涉及多个模型的协同工作是最复杂的训练场景。在 RLHF 的最后一个阶段PPO 训练需要同时运行 Actor 模型待对齐的语言模型、Critic 模型价值函数评估模型和 Reward 模型奖励信号来源。这三个模型的显存需求是叠加的而且 Actor 在生成阶段是推理模式在参数更新阶段是训练模式两者之间的切换会带来额外的开销。# RLHF 阶段 PPO 配置示意rlhf_config:stage:ppo# PPO 训练阶段actor_model:llama2-7bcritic_model:llama2-7breward_model:llama2-7b-rmkl_coeff:0.02# KL 散度惩罚系数ppo_epochs:4# 每个 batch 的 PPO 迭代轮数generate_max_length:512# 生成序列的最大长度device_placement:separated# 模型分离部署关于 device_placement 参数这里有一个容易踩的坑如果设置为「shared」共享部署即让 Actor、Critic 和 Reward Model 共用同一组 NPU那么显存峰值是三者之和很可能在生成阶段触发 OOM。如果设置为「separated」分离部署则需要额外增加节点间的通信来传递 reward 信号但显存压力会大大缓解。配方文档中会明确标注这两种拓扑的适用场景。在实际部署时还需要考虑 Actor 的生成inference和训练training之间的调度。通常的做法是把生成任务和训练任务放在不同的流stream上并行执行或者干脆分成两个独立的进程通过共享文件系统来传递生成的样本数据。# RLHF 中 Actor 模型的生成与训练分离实现思路classRLHFTrainer:def__init__(self,actor_model,critic_model,reward_model):self.actoractor_model self.criticcritic_model self.reward_fnreward_modeldefgenerate_samples(self,prompts,num_return_sequences4):使用推理模式的 Actor 生成多个回复样本withself.actor.inference_mode():responsesself.actor.generate(prompts,num_return_sequencesnum_return_sequences,max_lengthself.max_generation_length)returnresponsesdefppo_update(self,prompt_response_pairs):PPO 更新步骤withself.actor.train_mode():# 计算 reward、 advantage、 policy loss 等advantagesself.compute_advantages(prompt_response_pairs)# 执行 PPO 裁剪更新self.optimizer.step()链路实战一个训练任务的启动流程从拿到 cann-recipes-train 仓库到跑通第一个训练任务大致是这样一条链路# 1. 克隆仓库gitclone https://atomgit.com/cann/cann-recipes-train.gitcdcann-recipes-train# 2. 选择模型配方目录cdrecipes/llama2-70b/pretrain# 3. 检查环境npu-smi info# 确认 NPU 在位# 4. 修改配置文件中的数据路径和数据格式vimconfigs/llama2_70b_pretrain.yaml# 5. 启动训练bashscripts/run_pretrain.sh配置文件是整个配方的核心入口。它不是一个简单的 key-value 文件而是包含了并行策略、训练超参、数据加载、检查点保存等所有环节的完整声明。改一个tensor_model_parallel_size就能切换并行拓扑不需要动训练脚本。训练脚本内部通常会调用 torchtitan-npu 的分布式启动器来执行训练任务。torchtitan-npu 是基于 PyTorch 的分布式训练框架专门针对昇腾 NPU 进行了深度优化。# 启动脚本内部通常会调用 torchtitan-npu 的分布式启动器torchrun--nproc_per_node8\--master_port29500\ pretrain.py \--config configs/llama2_70b_pretrain.yamltorchrun 是 PyTorch 原生的分布式启动工具负责解析环境变量、建立进程组、初始化分布式通信。然后 pretrain.py 作为训练入口脚本会进一步调用 torchtitan-npu 框架的初始化接口完成模型构建、分布式 optimizer 设置、以及混合并行的切分逻辑。启动后torchtitan-npu 框架接管分布式调度底层 hccl 负责集合通信ops-transformer 提训算子——配方本身只是最上层的使用入口。整体的数据流可以概括为配置文件 → 配方启动脚本 → torchtitan-npu 调度层 → ops-transformer 算子层 → HCCL 通信层 → 昇腾 NPU 硬件。在架构中的位置cann-recipes-train 位于 CANN 五层架构的第 5 层应用层是距离终端用户最近的仓库。它的上游依赖关系清晰cann-recipes-train应用层第 5 层 ↑ torchtitan-npu训练框架层第 4 层 — 提供分布式启动、DDP/PP 封装、图优化pass ↑ ops-transformer算子层第 3 层 — 提供 FlashAttention、MoE dispatch、 RMSNorm 等训练专用算子 ↑ hccl通信层第 2 层 — 提供 AllReduce、AllGather、ReduceScatter 等集合通信原语 ↑ 昇腾 NPU硬件抽象层第 1 层torchtitan-npu 是 Cann Recipes Train 的直接上游。它在 PyTorch 分布式的基础上增加了对昇腾 NPU 硬件特性的适配包括混合精度训练、流水并行调度、通信 overlap、显存优化等技术。配方中的启动脚本只是传入配置参数真正的模型切分和分布式逻辑由 torchtitan-npu 完成。ops-transformer 提供了训练阶段专用的 CUDA/HCCL 算子比如融合版的 Attention 算子对标 FlashAttention、MoE 的路由dispatch算子、以及各种 fused kernel。这些算子对训练吞吐量有直接影响——相同模型和硬件条件下好的算子实现能带来 20%30% 的吞吐提升。hcclHierarchical Collective Communication Library工作在更底层提供了昇腾 NPU 之间高速互联的集合通信原语。所有上层的数据聚合操作梯度同步、模型参数同步、embedding gather 等最终都会翻译成 HCCL 的调用。下游就是终端用户——拿配方改改配置跑训练。没有更上层的消费者了。与其他仓库的协作关系cann-recipes-train 最紧密的关联仓库是 cann-recipes-infer。两者是训练-推理的镜像关系cann-recipes-train训练阶段的模型适配与并行方案解决的是「怎么把模型训练出来」的问题cann-recipes-infer推理阶段的模型适配与优化方案解决的是「怎么把训练好的模型部署出去」的问题同一个 LLaMA-2 70B 模型训练时关注 TP/PP 并行策略和梯度同步效率推理时关注 EP 并行和 KV Cache 管理。两个仓库的目录结构高度对称方便从训练无缝切换到推理部署。cann-recipes-train/recipes/llama2-70b/ ├── pretrain/ # 预训练配方 │ ├── configs/ │ ├── scripts/ │ └── README.md ├── finetune/ # 微调配方 │ ├── sft/ │ └── lora/ └── rlhf/ # RLHF 配方 ├── sft/ └── ppo/ cann-recipes-infer/recipes/llama2-70b/ └── decode/ # 推理配方 ├── configs/ ├── scripts/ └── README.md与 torchtitan-npu 的关系是上下游依赖。torchtitan-npu 是独立发布的训练框架而 cann-recipes-train 是 torchtitan-npu 的「配方合集」——每个配方本质上是一套经过验证的 torchtitan-npu 配置方案。用户使用配方时不需要关心 torchtitan-npu 内部的实现细节只需要修改配置并执行启动脚本即可。需要注意的是cann-recipes-train 和 torchtitan-npu 的版本需要严格对应版本不匹配可能导致配置解析失败或者运行结果不符合预期。与 ops-transformer 的关系更加间接——配方中指定的 Attention 实现方式、是否启用 fused kernel、MoE 的 router 类型等最终都会影响 ops-transformer 算子的选择。普通用户感知不到这层关系但如果遇到性能问题需要深入调优时可能会涉及到算子级别的调整。与 hccl 的关系同样隐蔽。配方不会直接暴露 HCCL 的 API 调用但并行策略的每一次调整TP 还是 PP 或者两者混合最终都会转化为 HCCL 内部集合通信模式和通信域的构建。如果出现通信死锁或者通信效率不如预期的情况可能需要检查 HCCL 的配置参数比如通信算法选择Ring 还是 Tree、是否启用 inplace 优化等。
