文章目录前言这个仓库放在哪它覆盖了哪些模型推理优化技术有哪些一个配方具体怎么用上游给了它什么武器跟训练配方什么关系视频模型的配方有什么不一样想跑起来怎么做前言说人话cann-recipes-infer 就是昇腾 CANN 生态里的菜谱合集——你想在昇腾 NPU 上部署一个大模型做推理这个仓库给你现成的配方照着做就行。为什么需要菜谱因为大模型推理不是把权重往显卡上一丢就完事的。DeepSeek-V3 有 6710 亿参数分到 8 张卡上怎么切KV Cache 怎么管MoE 的专家怎么分配每个模型都有自己的一套讲究。模型的架构不同、参数规模不同、硬件拓扑不同推理部署的方案就完全不一样。你想在 2 台 Atlas A2 上跑 Qwen2.5-72B和在 8 台上跑 DeepSeek-V3并行策略、显存分配、通信方式都是两码事。把这些差异逐个摸清楚至少得踩几周的坑。cann-recipes-infer 干的事就是把这些讲究整理成一份份可以直接执行的部署方案把踩坑的工作替你做了。这个仓库放在哪CANN 是昇腾异构计算架构分五层。cann-recipes-infer 坐在最顶上——应用层。底下四层干苦力活算子库算矩阵、加速库拼图、编译器翻译、运行时调度到了 cann-recipes-infer 这层就是把这些苦力活组合成一份完整的部署方案递到用户手上。用装修来打比方底层算子是砖头水泥ATB 加速库是预制板GE 图引擎是施工队。cann-recipes-infer 不生产任何材料它出的是装修方案——你照着方案走房子就装好了。从调用链路看更清楚。用户跑推理脚本时调用是这样一层层下去的cann-recipes-infer应用层第5层 └── ATB 融合算子加速库层第4层 ├── ops-transformer 底层算子算子层第3层 └── hccl 集合通信通信层第3层 └── GE 图引擎 / Runtime编译运行时第1-2层cann-recipes-infer 只跟 ATB 打交道不会直接调 ops-transformer 或 hccl。但配方里的并行策略、显存配置最终都通过 ATB 传递给底层执行。理解这条链路调试时就知道问题出在哪一层。它覆盖了哪些模型这是最核心的问题。目前 cann-recipes-infer 覆盖的大模型基本把主流的都包了文本大模型DeepSeekDeepSeek-V2/V3、DeepSeek-R1MoE 架构的代表性模型。V3 有 671B 参数、256 个专家推理时每个 token 只激活 8 个专家天然适合 EP 并行QwenQwen2/Qwen2.5 系列从 7B 到 72B 多个规格密集型 Transformer走融合算子 图模式优化路线GLMGLM-4 系列支持长上下文场景PageAttention 方案的重点适配对象KimiKimi-K2-Thinking支持 256K 长序列推理对 KV Cache 管理和显存规划要求极高多模态与视频模型HunyuanVideo腾讯混元视频生成模型Diffusion 架构的视频生成显存需求远超文本模型每份配方不是随便放个推理脚本就完事。一个典型的配方长这样# 看看仓库里有什么模型lscann-recipes-infer/# DeepSeek-V3/ Qwen2.5/ GLM-4/ HunyuanVideo/ Kimi-K2/每个模型目录里一般包含这几样东西tree cann-recipes-infer/DeepSeek-V3/# ├── infer.py # 推理入口脚本# ├── run.sh # 一键启动脚本# ├── configs/ # 并行策略、精度、batch size 等配置# └── README.md # 部署说明configs 目录下通常是 YAML 格式的配置文件把并行度、批次大小、KV Cache 参数等全写清楚# DeepSeek-V3 的典型配置parallel:tp:8# 张量并行度ep:8# 专家并行度infer:max_batch_size:32max_seq_len:4096kv_cache_dtype:float16推理优化技术有哪些不同模型用不同的优化组合。cann-recipes-infer 目前集成的核心技术有这么几类EP专家并行MoE 模型专用。把 256 个专家分到多张卡上每张卡只存一部分专家的权重推理时通过 hccl All-to-All 通信把 token 路由到对应专家所在的卡上。TP张量并行把一个大的矩阵乘法按列切分到多张卡上并行计算每张卡算一部分结果再通过 All-Reduce 聚合。适用于密集型 Transformer 模型。PageAttentionKV Cache 的显存管理策略。传统的做法是给每个请求预分配最大长度的 KV Cache但大多数请求用不满浪费严重。PageAttention 把 KV Cache 按页分配用多少给多少显存利用率高得多。融合算子ATB 提供的优化。把 LayerNorm Linear Activation、FlashAttention 这类连续操作合成一次调用省掉中间结果的显存读写开销。# 融合算子对比示意# 未融合3 次显存读写xlayer_norm(x)# 写一次中间结果xlinear(x)# 写一次中间结果xgelu(x)# 写一次最终结果# 融合后1 次显存读写xfused_ln_linear_gelu(x)# 中间结果留在 NPU 片上缓存不写回显存一个配方具体怎么用拿 DeepSeek-V3 举例。这个模型 671B 参数MoE 架构单卡根本放不下。cann-recipes-infer 给出的方案核心是 EP TP 的组合# 8 卡 Atlas A2 服务器上的启动方式cdcann-recipes-infer/DeepSeek-V3/bashrun.sh--tp8--ep8--max-batch-size32--tp 8是张量并行把一个矩阵乘拆到 8 张卡上算。--ep 8是专家并行MoE 模型里每个 token 只走部分专家EP 让每张卡只存一部分专家的权重省显存。两个一组合671B 的模型就能在合理显存里跑起来。如果机器更多比如 2 台 8 卡服务器共 16 张卡可以调整并行策略# 16 卡配置TP8 EP8跨机通信走 hcclbashrun.sh--tp8--ep8--nnodes2--node-rank0\--master-addr192.168.1.100 --master-port29500Qwen2.5 的配方又是另一套思路。它用的是 ATB 融合算子 图模式优化# Qwen2.5 配方里的关键配置片段fromtorch_npu.contribimporttransfer_to_npu modelAutoModel.from_pretrained(Qwen/Qwen2.5-72B)modeltransfer_to_npu(model)# 模型搬到 NPU 上# 融合算子会把 LayerNorm Linear Activation 合成一次调用# 省掉中间结果的读写速度能快不少GLM-4 走的是 PageAttention 方案——动态分配 KV Cache 的显存而不是预分配一大块。好处是显存利用率高能塞下更长的上下文# PageAttention 配置示意fromaccelerateimportinfer_config configinfer_config.PageAttentionConfig(block_size16,# 每页 16 个 token 的 KVmax_num_blocks1024,# 最多分配 1024 页dtypefloat16)Kimi-K2-Thinking 支持 256K 长序列KV Cache 的显存压力极大。配方里对 KV Cache 做了量化压缩用 8-bit 存储 KV 状态显存占用减半精度损失在可接受范围# Kimi-K2 长序列推理配置kv_cache:dtype:int8# KV Cache 8-bit 量化block_size:16max_seq_len:262144# 256Kparallel:tp:8上游给了它什么武器cann-recipes-infer 自己不写算子也不写加速库它的战斗力全靠上游三个仓库ATBascend-transformer-boostTransformer 加速库提供 FlashAttention、PagedAttention 这些融合算子。cann-recipes-infer 里 Qwen 和 GLM 的配方都直接调 ATB。ATB 把多个底层算子打包成一个个大算子对外暴露简洁的 API# ATB 的调用方式importtorch_npufromatbimportFlashAttention,FusedMLP attn_outputFlashAttention(query,key,value,causalTrue)mlp_outputFusedMLP(hidden_states,gate_weight,up_weight,down_weight)ops-transformer底层 Transformer 算子库ATB 底层就是调的它。MoE 类算子专家路由、专家计算、位置编码算子RoPE、ALiBi都在这里。如果你需要自定义一个新的注意力变体改这个仓库。hccl集合通信库多卡分布式推理时的数据同步全靠它。EP 和 TP 并行里每张卡之间的通信就是 hccl 在跑# hccl 在 EP 中的作用示意# 步骤1每张卡算出 token 应该路由到哪些专家# 步骤2hccl All-to-All 把 token 发到对应专家所在的卡# 步骤3目标卡上的专家计算完再 All-to-All 发回原卡调用链路很清楚用户脚本 → cann-recipes-infer 配方 → ATB 融合算子 → ops-transformer 底层算子 ↓ hccl 多卡通信跟训练配方什么关系cann-recipes-train 是 cann-recipes-infer 的兄弟仓库一个管推理一个管训练。分工很明确cann-recipes-train解决的是梯度回传、优化器状态管理、混合精度训练、数据并行这些训练特有的问题cann-recipes-infer解决的是 KV Cache 管理、请求批处理、推理延迟优化这些推理特有的问题两个仓库在模型覆盖上有重叠DeepSeek、Qwen 都有两个配方但优化方向完全不同。训练关注的是吞吐和收敛推理关注的是延迟和显存。两个仓库互补。比如你先用 cann-recipes-train 微调了一个 DeepSeek训练完直接切到 cann-recipes-infer 的推理方案部署上线整个链路都在昇腾上完成# 训练cann-recipes-traincdcann-recipes-train/DeepSeek-V3/bashrun.sh--dp8--tp8--epochs3# 微调完的权重直接用于推理cdcann-recipes-infer/DeepSeek-V3/bashrun.sh--tp8--ep8--checkpoint/path/to/finetuned/weights视频模型的配方有什么不一样HunyuanVideo 是个视频生成模型跟文本推理的差别很大。文本模型是输入一段话输出一段话视频模型是输入一段描述输出一堆帧。难点在于显存。生成一段 5 秒 720p 的视频可能要几百 GB 显存来存中间帧。cann-recipes-infer 的 HunyuanVideo 配方用的是时序分片策略——不是一次性算完所有帧而是把时间维度切成多段每段单独算前一段的隐状态传给下一段# 视频推理的时序分片思路伪代码forchunkinsplit_frames(total_frames,chunk_size16):# 每个 chunk 16 帧单独在 NPU 上算hiddenmodel.generate(chunk,prev_hiddenhidden)# hidden 从上一个 chunk 传过来保证时序连续性save_frames(chunk,output_dir)这样 8 张 Atlas A2 就能跑 HunyuanVideo 了。跟文本模型相比HunyuanVideo 配方还需要额外处理帧间的注意力掩码和条件注入这些都封装在配方的推理脚本里用户不需要自己处理。想跑起来怎么做直接去仓库找你感兴趣的模型目录按 README 跑就行。前提是你手上有昇腾硬件Atlas A2/A3 或 Ascend 950和 CANN 环境。环境准备一般就两步# 1. 安装 CANN 驱动和固件按昇腾官方文档来# 2. 安装 Python 依赖pipinstalltorch_npu transformers accelerate仓库地址https://atomgit.com/cann/cann-recipes-infer模型支持列表会持续更新。如果当前没有你需要的模型也可以参考已有配方的写法把对应模型的权重路径和并行策略改一改大半情况能跑通。遇到问题就去仓库提 Issue社区响应还挺快的。