cann-recipes-train 仓库深度解读:昇腾平台下 DeepSeek-R1 与 Qwen2.5 强化学习训练优化实践

cann-recipes-train 仓库深度解读:昇腾平台下 DeepSeek-R1 与 Qwen2.5 强化学习训练优化实践

cann-recipes-train 仓库深度解读:昇腾平台下 DeepSeek-R1 与 Qwen2.5 强化学习训练优化实践

前言

自 DeepSeek-R1 发布以来,大模型的强化学习(RL)训练掀起了新一轮的技术热潮。各大厂商与开源社区纷纷投入实践,持续探索更高效的 RL 训练体系。本文将基于 cann-recipes-train 仓库,解读两个实践样例:DeepSeek-R1 的 RL 训练优化实践样例、基于 verl 框架的 Qwen2.5 强化学习实践样例

cann-recipes-train 仓库全景解析:昇腾训练优化的"实战底座"

在这里插入图片描述
大模型训练拼效率的阶段,CANN 直接帮我们搞定了底层异构硬件适配、资源调度这些麻烦事,不用再从零研究 GPU 和 NPU 怎么协同,现有模型代码也不用大改就能对接,训 LLM 或多模态模型时还能通过算子优化、内存复用提升速度、减少资源浪费

cann-recipes-train 仓库不搞抽象理论,全是能直接复用的代码样例,比如具体 LLM 的训练优化步骤、多模态模型的算子调试方法,帮我们跳过 “看官方文档懂了但不会用” 的坑,不用自己反复试错,快速掌握 CANN 的优化技巧,把精力集中在模型本身。

方便广大开发者在昇腾环境中高效开展大模型的微调与续训,将开源的 cann-recipes-train 仓库面向典型的 LLM 与多模态模型训练任务,提供基于 CANN 平台优化样例与实践指南,帮助开发者简单、快速、高效在昇腾平台上完成模型训练与优化部署。首批版本中,cann-recipes-train 将上线两个基于 Verl 强化学习框架 的典型训练样例,分别覆盖 Qwen2.5 与 DeepSeek-R1-671B 两大模型DeepSeek-R1 RL训练优化样例:基于开源veRL框架,搭配MindSpeed+vLLM-Ascend框架,在Atlas A3集群实现GRPO算法的高吞吐RL训练,并达到120TPS/卡的系统吞吐量基于verl框架的Qwen2.5强化学习(入门样例):基于Qwen2.5-1.5B-Instruct模型,采用verl强化学习框架,在MATH-lighteval数学推理数据集上进行了训练,只需要单卡Atlas A2环境,快速上手使用昇腾NPU完成RL训练任务

cann-recipes-train 仓库 GitCode NoteBook 部署准备

1、NoteBook 资源配置计算资源:NPU:1*NPU 910B 32vCPU + 64GB 内存容器镜像:ubuntu22.04-py3.11-cann8.2.rc1-sglang-main-notebook

2、NoteBook 启动成功后使用 npu-smi 查看 NPU 状态、利用率当前 Notebook 的昇腾 910B3 NPU 状态正常,功耗 96.5W、温 46℃,HBM 显存仅用 3.3G(总 64G),无运行进程,资源低负载



3、cann-recipes-train 克隆到本地



4、进入 cann-recipes-train/rl_train 目录,可以看到特定模型的 RL(强化学习)训练相关样例集合

deepseek:DeepSeek-R1 RL训练优化实践样例
qwen2_5:基于verl框架的Qwen2.5强化学习实践样例

DeepSeek-R1 RL训练优化实践样例

GitCode Notebook 部署
针对DeepSeek-R1模型,基于 verl 开源框架,配合MindSpeed-LLM和vLLM-Ascend框架,完成RL训练全流程的优化适配

硬件要求:产品型号:Atlas A3 系列最少卡数:128张A3
1、安装样例依赖基础环境适配(安装核心依赖(如verl、torch_npu等)虽有部分版本冲突,但不影响核心功能



2、下载依赖的开源框架代码:拉取 Verl(指定 Commit)、vLLM(v0.9.1)、vLLM-Ascend(打补丁)及 Megatron-LM、MindSpeed 等多个指定版本的 AI 相关依赖框架,将其复制到 cann-recipes-train/rl_train/deepseek/ 目录,为该目录下的 deepseek 样例运行搭建适配的依赖环境



3、修改verl代码(为了使能patch修改,需要修改以下verl源码)
DeepSeek-R1 RL训练优化点解读
在这里插入图片描述
如图是基于Atlas A3 SuperPoD超节点128卡集群,加载真实权重和随机初始化权重的两个场景中性能效果
框架适配:Verl × vLLM-Ascend 适配
vLLM-Ascend 社区已经做好了 DeepSeek-R1 的昇腾适配,能直接用它提推理性能,但要让 verl 和它兼容,得改关键接口,主要是初始化 vLLMRollout 对象的 vllm_rollout_spmd.py 文件:手动加 vLLM-Ascend 的 patch:导入 vLLM 前得先引这个 patch,不然有些类和函数不匹配配 DP 通信参数:设 VLLM_DP_MASTER_PORT 和 IP,保证每个 DP 组有独立通信端口,适应集群环境关 sleep 模式:NPU 多机下 sleep 会导致显存释放不了,还得避免显存被 vLLM 内存池接管,后续没法手动卸载调 token 参数:加载真实权重时,默认 max_num_batched_token=8192 容易 OOM,改成 1024 再开 chunked_prefill 就行
性能优化(一):训推一体化与参数重排(Reshard/Offload)实践
大模型 RL 的时候,训练和推理时,模型在显卡上的分片方式完全不一样,训练时 8 张卡分成两组各 4 张(EP4),流水线也拆成多段(PP2);推理时得把 8 张卡合并成一组(EP8),流水线也不分段了(PP1)

模型训练完更新参数后,得把参数从训练的分片方式改成推理能用的(reshard),在训练组内用 alltoallv 通信,参数重排的时候没冗余数据传输,这一步快了不少

另外Actor、Rollout、Ref 三个模型挤在同一批卡上,切换的时候,前一个模型占着显存呢,不挪走新模型根本装不下,所以得先把不用的模型挪到主机内存(offload)腾地方,再把要用的加载到显卡,这部分昇腾团队专门调了显存管理和数据迁移的细节,切换耗时降了不少

这两部分优化下来,训推切换会更加顺畅,迭代效率也会明显提高。
在这里插入图片描述
reshard 优化核心:专家参数用 AlltoAllV 定向传:只给目标推理 rank 发参数,不做全量广播,大幅减少带宽冗余,单卡增量内存从 14G 压到 0.0547G,降低 OOM 风险PP 域通信调顺序:先在 TP 域聚合参数,再用 PP 域 AlltoAll 广播,减少通信量如 p=8、t=4 时第一步通信量减半和通信次数

offload 优化核心:替代 vLLM 有问题的功能:用 onload/offload_model_weight、init/free_cache_engine,替换 NPU 多机下不好使的 vLLM wake_up/sleep省冗余步骤 + 后置初始化:省去训练后到推理前的冗余卸载 / 加载,把推理 init_cache_engine 放到 reshard、卸载训练权重之后,降内存峰值、提 vLLM 利用率
性能优化(二):训练侧优化策略与算子融合技术
复用MindSpeed训练优化

verl 目前对接了MindSpeed,因此训练侧主要复用了MindSpeed在内存、通信和计算方面的许多优化技术,包含Ascend Swap Optimizer和使能融合算子等,对应的配置脚本片段大概是这样old_log_prob免计算

GRPO 这类 on-policy 算法里,有个关键特性:训练时模型参数未更新前,old_log_prob 的计算结果,和 update_actor 环节前向计算得到的 log_prob 完全一致,毕竟两者依赖的是同一套模型参数

所以昇腾团队用 log_prob.detach () 直接替代 old_log_prob,省去一次训练模型的前向计算大幅节省耗时,考虑到 verl 原生不支持这一优化,团队专门为其补充实现了该功能,目前只需要将配置项 config.actor_rollout_ref.actor.recompute_old_log_prob 设为 False,就可以启用优化

性能优化(三):推理侧加速与吞吐率提升路径
在这里插入图片描述
DeepSeek-R1 “1K 推 3K” 的 RL 推理场景中,昇腾团队以 162 token/p/s 的基础吞吐为起点,通过多轮技术迭代实现推理性能的阶梯式跃升:基于 TorchAir 图模式 + AIV 加速 + vLLM-V1 框架 优化,吞吐提升至 419 token/p/s消除大 EP 场景下的 Transpose 冗余算子 + Cumsum 冗余计算,进一步提升至 456 token/p/s引入 MoE/MLA 多流并行 + router 逻辑优化,突破至 487 token/p/s优化零冗余 TP 转 EP 通信机制,性能达 519 token/p/s通过 DP 间 EOS 检测调度优化,推理吞吐成功突破 618 token/p/s

一系列优化大幅压缩了长序列 RL 推理的耗时占比,成为昇腾团队推动 RL 训练整体性能提升的核心突破口!

基于verl框架的Qwen2.5强化学习实践样例

基于 Qwen2.5-1.5B-Instruct 模型,搭配 verl 强化学习框架,在 MATH-lighteval 数学推理数据集上开展训练训练目标:提升小模型复杂数学问题的分步推理能力,生成逻辑严密、结果可验证的推理过程硬件门槛:最低仅需单卡 Atlas A2 环境,助力快速上手昇腾 NPU 的 RL 训练任务
配套优化版 MATH 任务奖励函数
针对原生奖励函数 “字符串等价性误判、奖励信号稀疏” 的问题,通过多维度分级评分引导模型精准学习
在这里插入图片描述
verl 框架下 MATH 任务的奖励函数总分 1 分,遵循 “答案正确性优先” 原则:

答案错误直接得 0 分,答案正确则分三维度打分:math_verify 做数学语义验证的准确度占 0.7 分符合指定标签样式且规范的格式占 0.2 分包含有序思考步骤与逻辑关键词的思维链占 0.1 分

同时答案错误时不评估格式、思维链,避免模型偏离精准求解目标,既解决了原生函数的误判问题,也通过多维度评分缓解了奖励稀疏,同时能引导模型生成更规范的表达、更完整的推理过程

cann-recipes-train 仓核心定位:连接 CANN 能力与训练业务的"桥梁"

从个人角度来看,Cann仓库诞生源于大模型训练的两大痛点:一是 CANN 平台的底层优化能力如算子调度、内存管理需要结合具体模型场景才能发挥价值,开发者缺乏场景化参考;二是强化学习等复杂训练流程的工程化落地难度高,需兼顾框架整合、硬件适配与性能调优,而 cann-recipes-train 通过 “典型模型 + 优化算法 + 可运行样例” 的组合,直接打通了 “CANN 能力→训练业务” 的链路,对开发者来说 cann-recipes-train 不算通用训练框架,更像 CANN 平台训练优化的实战手册。

场景聚焦:专门针对 LLM 与多模态模型的训练业务,覆盖强化学习(RL)核心训练场景,解决大模型训练中 高吞吐、易部署、低硬件门槛的实际需求

技术适配:深度整合 CANN 平台的异构计算能力,将抽象的加速算法转化为可直接运行的代码样例,避免重复造轮子

分层支持:提供单卡入门级样例,也包含集群高性能样例,覆盖不同阶段开发者的需求

总结与展望:cann-recipes-train 助力昇腾生态加速 AI 训练落地

在这里插入图片描述
cann-recipes-train 仓库针对 LLM、多模态训练场景中的典型模型、算法,提供基于 CANN 平台的优化样例,方便开发者简单、快速、高效等使用 CANN 进行模型训练首批开源样例

入门样例:基于 ver1 开源框架 & A2 单卡,Qwen2.5-1.5B RL 训练样例,低成本快速上手

优化样例:基于 ver1 开源框架 & A3 集群,DeepSeek-V3 RL 训练样例,实现大集群高吞吐训练沟通渠道:👉GitCode:CANN/cann-recipes-train

欢迎大家到仓库提交 ISSUE/PR,复现、捉虫、贡献新样例,和广大开发者交流讨论

Read more

ComfyUI保姆级安装指南:从零配置Python环境到共享WebUI模型库(避坑大全)

ComfyUI终极安装指南:复用WebUI资源与高效配置实战 第一次接触ComfyUI时,我被它那类似Blender的节点式界面震撼到了——这完全颠覆了我对AI绘画工具的认知。但随之而来的安装过程却让我这个有三年Stable Diffusion使用经验的老用户也踩了不少坑。最头疼的问题莫过于:如何在保留现有WebUI模型库的同时,让ComfyUI也能共享这些资源?毕竟谁也不想在已经塞满3TB硬盘的模型库里再复制一份几十GB的数据。 1. 环境预检与准备工作 在开始安装前,我们需要确保系统满足ComfyUI的基本运行要求。与WebUI不同,ComfyUI对环境的纯净度要求更高,特别是Python版本的管理。 1.1 硬件配置核查 最低配置: * 显卡:NVIDIA GTX 1060(4GB显存) * 内存:16GB DDR4 * 存储:SSD剩余空间≥50GB(仅系统+程序) 推荐配置: * 显卡:RTX 3060(12GB显存)及以上 * 内存:32GB DDR4 * 存储:NVMe SSD(模型库单独存放) 提示:显存不足8GB的用户建议关闭--hig

2026实测|DeepSeek-R1-Distill-Qwen-1.5B部署全攻略(vLLM+Open WebUI,0.8GB显存就能跑,告别服务器瓶颈)

2026实测|DeepSeek-R1-Distill-Qwen-1.5B部署全攻略(vLLM+Open WebUI,0.8GB显存就能跑,告别服务器瓶颈)

前言:2026年,轻量级大模型部署已成为开发者核心需求——专业GPU服务器成本高昂、边缘设备算力有限,多数1.5B级模型仍需3GB以上显存,让个人开发者与中小企业望而却步。而DeepSeek-R1-Distill-Qwen-1.5B(下称“DQ-1.5B”)的出现打破僵局,通过知识蒸馏技术在1.5B参数体量下实现接近7B级模型的推理能力,配合vLLM推理加速与Open WebUI可视化交互,实测0.8GB显存即可稳定运行,无需高端服务器,个人PC、边缘设备均可轻松落地。本文结合2026年最新实测数据,从核心原理、分步实操、实测验证、应用场景、落地案例到问题排查,打造零冗余、高可用的部署全攻略,兼顾专业性与实用性,助力开发者快速上手,轻松实现轻量级大模型本地化部署。 一、核心技术解析 部署前先理清三大核心组件的核心逻辑,无需深入底层源码,聚焦“为什么能用、为什么高效”,贴合开发者落地需求。 1.1 模型核心:DeepSeek-R1-Distill-Qwen-1.5B 优势解析 DQ-1.5B是DeepSeek团队基于Qwen-1.

SpringBoot+Vue+Netty+WebSocket+WebRTC 视频聊天实现

一、关于WebRTC(Web Real-Time Communication) WebRTC 是什么:是浏览器内置的实时通信技术,能让网页直接实现音视频通话、数据传输,无需安装插件。 ICE 是什么:ICE(Interactive Connectivity Establishment)是 WebRTC 中用于解决 NAT 穿透(简单说就是让不同网络下的设备能找到彼此)的框架,而 iceServers 就是给 ICE 提供 “辅助服务器” 的配置。 STUN 服务器:STUN(Session Traversal Utilities for NAT),直译是 “NAT 会话穿透工具”,它是一种轻量级的网络服务器,核心作用是:帮助处于 NAT(网络地址转换)后的设备(比如你的电脑 / 手机)