CANN 推理并行配置索引实战指南：TP/EP/CP/KVP 选型与已验证配置速查

CANN 推理并行配置索引实战指南TP/EP/CP/KVP 选型与已验证配置速查【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer本文以 CANN / cann-recipes-infer 仓库中「模型推理并行策略分析」技能skill的参考配置索引为核心系统梳理大语言模型Dense / MoE / MoEMLA在昇腾 NPU 上 Prefill、Decode、超长序列三大场景的并行度选型规律Decode 高吞吐的大 EP 模式、低时延的纯 TP 模式、Attention DP Dense TP MoE EP 的差异化并行以及 Prefill 的 CP / 大 TP 与超长序列的 KVP / Offload 方案。文中所有配置均来自仓库中已验证的 YAML 文件读者可据此为新模型快速锁定候选并行策略parallel_config再结合模块级拆解与定量估算确定最终取值。一、索引文档的定位并行策略分析的「候选种子库」在model-infer-parallel-analysisskill 的分析流程中references/config-index.md承担「第三步定量估算」之前的候选种子查阅环节分析时应读取最接近的参考模型配置对比推荐值与已验证配置的差异而不是直接套用整套配置。该 skill 面向昇腾 Atlas A2 / A3 系列单机部署决策范围是parallel_config中各*_tp_size、o_proj_tp_size、cp_size、kvp_size的取值并由此推导 DP / EP 度*_dp_size world_size // *_tp_size。索引按部署场景分为五大类Decode 高吞吐大 EP、Decode 低时延纯 TP、Decode 混合Attention DP Dense TP MoE EP、Prefill 长序列CP / 大 TP、超长序列KVP / Offload末尾附加oproj_tp_size使用规则、部署链路速查与设计文档匹配表。以下逐一展开。二、Decode 高吞吐大 EP128 卡主流模式MoE 模型 Decode 阶段的主流模式是Attention DP MoE 大 EPembed / lmhead 独立设 TP。索引中的已验证配置如下参考模型卡数attn_tpdense_tpmoe_tpembed_tplmhead_tpoproj_tp量化特殊配置配置路径DeepSeek-R11281111——W8A8moe_chunk65536, prefill_multi_cycledecode_r1_rank_128_128ep_a8w8.yamlDeepSeek-R11281111——W8A8C8MTP, perfect_eplb, SuperKerneldecode_r1_rank_128_128ep_a8w8c8_mtp_benchmark.yamlDeepSeek-R1161111616—W8A816EP, micro_batch0decode_r1_rank_16_16ep_a8w8.yamlDeepSeek-V3.2-Exp12814116168BF16cp_size128deepseek_v3.2_exp_rank_128_128ep_decode_benchmark.yamlDeepSeek-V3.2-Exp12814116164W8A8C8MTP3, cp_size128deepseek_v3.2_exp_rank_128_128ep_w8a8c8_decode_benchmark.yamlGLM-512814116164W8A8MTP3, cp_size128glm_5_rank_128_128ep_w8a8_decode_benchmark.yamlKimi-K212814116168—cp_size128kimi_k2_thinking_rank_128_128ep_decode_benchmark.yamlLongCat-Flash1281811168W8A8AFD, MTP2, perfect_eplb, SuperKernel, prefetchlongcat_flash_densetp8_ep128_gegraph_mtp_eplb_w8a8.yamlQwen3-MoE12811111——128EP 纯EP模式qwen3_235b_128ep.yaml以 DeepSeek-R1 的 128 卡 W8A8 配置为例其完整 YAML 如下decode_r1_rank_128_128ep_a8w8.yamlparallel_config: world_size: 128 attn_tp_size: 1 dense_tp_size: 1 moe_tp_size: 1 embed_tp_size: 1 lmhead_tp_size: 1注意其中没有o_proj_tp_size字段——DeepSeek-R1 是非 MLA 模型标准 GQA Attentiono_proj 跟随 attn_tp不需要独立设置。而 V3.2-Exp / GLM-5 / Kimi-K2 这类MLA 模型则设置了独立的o_proj_tp_size4 或 8其约束为attn_tp_size 1时才支持见 YAML 注释# only support when attn_tp_size 1。经验总结128 卡 Decode 通用模式attn_tp1, moe_tp1让 Attention 侧 DP 度最大化attn_dp 128MoE 侧 EP 度最大化moe_ep 128embed/lmhead_tp取决于词表大小V3.2-Exp / GLM-5 / Kimi-K2大词表V 100K用 16R1 / Qwen3小词表或全 MoE用 1dense_tp取决于模型结构V3.2-Exp / GLM-5 / Kimi-K2有 Shared Expert用 4LongCatDense FFN 大用 8R1全 MoE无独立 Dense 层用 1oproj_tp在 MLA 模型中独立设值4 或 8非 MLA 模型不需要。对比两个 DeepSeek-R1 128 卡配置可看到「进阶组合」decode_r1_rank_128_128ep_a8w8c8_mtp_benchmark.yaml在相同并行结构上叠加了force_eplb: Trueperfect_eplb 专家负载均衡、enable_superkernel: True、enable_multi_streams: True、enable_mla_prolog: True并通过next_n: 1启用 MTPMulti-Token Prediction投机解码batch_size也由 128 提升到 6144 以压测高吞吐。这体现了索引的用法并行结构TP 取值与算子优化开关MTP / EPLB / SuperKernel / 多流是两个独立维度可自由组合。三、Decode 低时延纯 TPDense 模型或小规模 MoEDense 模型或小规模 MoE 部署采用全 TP最小化通信延迟低时延场景 batch 小TP 的通信量可接受且无需 EP 的 AllToAll 开销。参考模型卡数attn_tpdense_tpmoe_tp量化配置路径DeepSeek-R116161616W8A8decode_r1_rank_16_16tp_a8w8.yamlQwen3-MoE16161616—qwen3_235b_16tp.yamlGPT-OSS 120B88—8—gpt_oss_120b_8tp.yamlGPT-OSS 20B11—1—gpt_oss_20b.yaml以 R1 16 卡纯 TP 为例decode_r1_rank_16_16tp_a8w8.yamlparallel_config: world_size: 16 attn_tp_size: 16 dense_tp_size: 16 moe_tp_size: 16 embed_tp_size: 16 lmhead_tp_size: 16该配置同时使用micro_batch_mode: 0、batch_size: 1是典型的低时延小 batch、S1 Decode形态。经验总结纯 TP 适合 Dense 模型GPT-OSS或 MoE 小规模部署≤16 卡all tp W所有模块 TP 度等于卡数最简单但通信量随 W 增长TP 的 AllReduce 在跨节点时性能急剧下降节点间 RDMA 带宽远低于节点内 HCCS因此纯 TP 必须控制在单节点内Dense 模型没有dense_tp字段只有attn_tp和moe_tp如 GPT-OSS 配置所示——这是因为 Dense 模型的 FFN 就是普通矩阵乘统一跟随 attn_tp 即可无需独立拆分。四、Decode 混合模式Attention DP Dense TP MoE EPMoE 模型的差异化并行各模块按计算 / 访存特性独立设 TP。这是「模块级拆解」思想的直接落地——Attention 在 Decode 阶段以 KV 访存为主用 DPDense FFN 是大矩阵用 TPMoE 专家分散到各卡用 EP。参考模型卡数attn_tpdense_tpmoe_tpoproj_tp量化特殊配置配置路径LongCat-Flash321811—eager, moe_chunk1024longcat_flash_densetp8_ep32.yamlLongCat-Flash321818—ge_graph, MTPlongcat_flash_densetp8_ep32_gegraph_mtp.yamlQwen3-MoE324—1——attn4tp8dpqwen3_235b_attn4tp8dp.yamlLongCat-Flash 32 卡配置的parallel_configlongcat_flash_densetp8_ep32_gegraph_mtp.yamlparallel_config: world_size: 32 attn_tp_size: 1 dense_tp_size: 8 moe_tp_size: 1 embed_tp_size: 1 lmhead_tp_size: 1 o_proj_tp_size: 8同时该配置将moe_chunk_max_len设为 1024相对 128 卡配置的 65536 显著调小用于控制 MoE 激活显存。经验总结混合模式核心思路Attention 用 DPDecode 时 KV 访存为主、Dense FFN 用 TP大矩阵、MoE 用 EP专家分散oproj_tp在图模式下需要和dense_tp匹配LongCat ge_graph 时 oproj8Qwen3 的attn4tp示例说明 Attention TP 可以取中间值不一定是 1 或 W32 卡下 attn_tp4 意味着 Attention 侧 DP8即「attn4tp8dp」在分摊 Attention 计算与保持 DP 度之间取折中。需要提醒的是模块间 TP 度不一致会在边界引入 AllGather / ReduceScatter 重排通信。这类切换通常远小于统一 TP 度带来的计算浪费但若切换频繁需评估其是否抵消模块级 TP 的收益。五、Prefill 长序列CP 与大 TP 两条路线Prefill 阶段以 TTFT 为目标长序列需要 CPContext Parallelism沿序列维度切分或大 TP 分摊计算和显存。参考模型卡数attn_tpdense_tpmoe_tpembed_tplmhead_tpoproj_tpcp_size序列长度量化配置路径DeepSeek-R132323213232——65536W8A8prefill_k2_rank_32_32sp_32tp_32ep_a8w8.yamlDeepSeek-R1321113232——4096W8A8prefill_r1_rank_32_32dp_32ep_a8w8.yamlDeepSeek-V3.2-Exp64111161686465536BF16deepseek_v3.2_exp_rank_64_64ep_prefill_benchmark.yamlDeepSeek-V3.2-Exp64111161616465536W8A8C8deepseek_v3.2_exp_rank_64_64ep_w8a8c8_prefill_benchmark.yamlGLM-564111161616465536W8A8glm_5_rank_64_64ep_w8a8_prefill_benchmark.yamlKimi-K264111161616465536—kimi_k2_thinking_rank_64_64ep_prefill_benchmark.yamlCP 配置的实际写法可参考 deepseek_v3.2_exp_rank_128_128ep_decode_benchmark.yaml128 卡、cp_size128与 glm_5_rank_128_128ep_w8a8_decode_benchmark.yamlYAML 中cp_size字段旁均注释# only active at prefill stage——即 CP 只在 Prefill 阶段生效Decode 阶段仍按并行配置正常推理。经验总结CP 是长序列 Prefill 的标准方案V3.2-Exp / GLM-5 / Kimi-K2 都用cp_size 卡数、attn_tp 1CP 模式下 Attention 不用 TPattn_tp1靠 CP 沿序列维度切分KV 也按序列分片存放DeepSeek-R1 65K 序列 Prefill 用的是大 TPattn_tp32而不是 CP——R1 没有 sparse attention标准 GQATP 更直接无需引入 CP 的 Send/Recv 通信R1 4K 短序列 Prefill 用纯 DPattn_tp1此时序列短单卡可容纳不需要分摊Prefill 的oproj_tp通常较小1 或 8因为 Prefill 阶段 o_proj 计算量相对不大embed/lmhead_tp在 Prefill 通常设为节点内 TP如 16分摊大词表显存与计算。一个值得注意的细节V3.2-Exp 在 128 卡 Decode 配置中oproj_tp8、64 卡 Prefill 配置中oproj_tp8而 W8A8C8 版本 Prefill 中降到 1GLM-5 Prefill 中也是 1——印证了「Prefill 阶段 oproj 计算占比小可取较小值」的规律。六、超长序列256KKVP 与 Offload256K 序列的 KV Cache 超出单卡显存需要 KVPKV ParallelKV Cache 按 head 维度切到多卡或 KVCache Offload。参考模型卡数kvp_sizeoproj_tp序列长度量化特殊配置配置路径LongCat-Flash3288131072W8A8decode_only, MLA_prologlongcat_flash_densetp8_ep32_kvp8_gegraph_w8a8.yamlDeepSeek-V3.2-Exp128—465536W8A8C8enable_offloadTdeepseek_v3.2_exp_rank_128_128ep_w8a8c8_offload_benchmark.yamlDeepSeek-R1128——65536W8A8C8dense_tp4, lmhead_tp16, moe_chunk512decode_r1_rank_128_128ep_a8w8c8_mtp_longseq.yaml经验总结KVPKV Cache 按 head 维度切到多卡每卡计算部分 Attention 后聚合。硬约束为oproj_tp kvp_size本仓库 KVP 实现约束。KVP 的完整设计可参阅 kv_cache_design.mdKVCache OffloadKV Cache 存主机内存利用 TopK 局部性约 60% 命中率减少 H2D 传输需要 GatherSelectionKvCache 算子支持。Offload 开关对应 YAML 中custom_params.enable_offload: True可在 deepseek_v3.2_exp_rank_128_128ep_w8a8c8_offload_benchmark.yaml 中看到R1 长序列方案不同不用 KVP / Offload而是dense_tp4moe_chunk512控制显存——因为 R1 全 MoE、无 MLA通过提高 dense TP 与调小 MoE 激活 chunk 即可压住显存峰值超长序列时moe_chunk_max_len要调小512–1024否则 MoE 激活显存爆炸。显存估算时注意KV Cache 在 Decode 长序列下是显存大头必须单独计算。MLA absorb 模式下缓存同时包含 nopekv_lora_rank与 ropeqk_rope_head_dim两部分仅按kv_lora_rank估算会低估约 12%。七、oproj_tp_size 使用规则速查oproj_tp_sizeo_proj 输出投影的 TP 度在 MLA 和复杂并行场景中独立于 attn_tp场景oproj_tp 取值约束参考无 MLA / 简单 TP不需要跟随 attn_tp—GPT-OSS, R1MLA Decode 大 EP4-8需整除num_heads * v_head_dimV3.2-Exp, GLM-5, Kimi-K2KVP 模式 kvp_size强制对齐LongCat-FlashPrefill CP 模式1 或 local_tp通常较小V3.2-Exp Prefill四条规则的底层逻辑非 MLA 模型的 o_proj 就是普通 GQA 输出投影直接跟随 attn_tp 切分无需独立字段MLA Decode 大 EP场景下 o_proj 是N_h × v_head_dim维大矩阵独立设置 4 或 8 的 TP 度可分摊其计算但数学上必须满足N_h * v_head_dim % oproj_tp 0本仓库 MLA o_proj 切分约束KVP 模式要求oproj_tp kvp_size因为 KV 按 head 切分后输出投影必须与之对齐才能完成部分 Attention 后的正确聚合Prefill CP 模式下 o_proj 计算量占比小取 1 或节点内小 TP 即可。另外注意 YAML 实现层面的约束o_proj_tp_size仅在attn_tp_size 1时支持V3.2-Exp / GLM-5 配置注释均明确标注这是本仓库当前实现的限制配置时需遵守。八、部署链路速查Prefill Decode 双配置一个模型通常需要Prefill Decode 两套配置按场景选择模型Prefill 配置Decode 配置设计文档DeepSeek-R132 卡 TP32 或 DP32128 卡 EP128docs/models/deepseek-r1/DeepSeek-V3.2-Exp64 卡 CP64128 卡 EP128dense_tp4docs/models/deepseek-v3.2-exp/GLM-564 卡 CP64128 卡 EP128dense_tp4docs/models/glm_5/Kimi-K264 卡 CP64128 卡 EP128dense_tp4docs/models/kimi-k2-thinking/LongCat-Flash—32/128 卡 dense_tp8EPdocs/models/longcat-flash/Qwen3-MoE—16 卡 TP16 / 128 卡 EP128docs/models/qwen3-moe/GPT-OSS—8 卡 TP8 / 单卡docs/models/gpt-oss/这份速查表的本质是「按序列长度与吞吐目标分流」短序列 / 低时延走 TP 或纯 EP长序列 Prefill 在 MLA 模型上优先 CP在 GQA 模型上优先大 TP超长序列叠加 KVP 或 Offload。需要注意的是CP 与 KVP 属于相对新的实施维度若目标模型需要这两类配置需参照仓内已有实现手动改造CP 参考 models/deepseek-v3.2-exp/ 的cp_size用法KVP 参考 models/longcat-flash/ 的 KVP 约束。九、设计文档匹配按模型特征找参考目标模型特征参考文档重点关注MoE MLA 大规模 EP Decodedocs/models/deepseek-r1/EP 通信调优、MTP 收益、moe_chunk 配置MoE MLA DSA/Sparse Attentiondocs/models/deepseek-v3.2-exp/CP vs TP 选择依据、KVCache Offload、MLA Absorb 权衡MoE MLA 超长序列256Kdocs/models/longcat-flash/KVP 约束、多流 core limiting、AFD、权重预取MoE 标准 GQA 中规模 TPdocs/models/qwen3-moe/head 切分、gateup 合并、npu_swiglu 融合MoE W4A16 混合精度docs/models/kimi-k2-thinking/混合精度策略、Flash DecodeDense 标准 GQAdocs/models/gpt-oss/纯 TP 配置、Fixed KV Cache十、使用建议从索引到最终 parallel_config索引给出的是「已验证候选种子」最终配置仍需按 skill 的完整流程落地这里给出四条可直接操作的建议模块级拆解优先不要整表照搬索引中每一行的parallel_config都是针对特定模型结构是否有 Shared Expert、是否有 Dense FFN、是否为 MLA、词表大小的验证结果。新模型应先拆解 Attention / Dense MLP / MoE Expert / Embedding / LMHead 各模块再按本节各表的「经验总结」匹配取值方向。参考配置只作为 sanity check 和候选种子不作为默认结论。核对硬约束最终取值必须满足world_size % *_tp_size 0、num_attention_heads % attn_tp_size 0、num_key_value_heads % attn_tp_size 0、num_experts % ep_size 0MLA 模型需检查N_h * v_head_dim % oproj_tp_size 0KVP 模式需oproj_tp kvp_size。通信控制在节点内tp_size不超过单节点卡数避免跨节点 TP。节点内 HCCS 带宽A2 约 56 GB/s与节点间 RDMA 差距很大跨节点 TP 性能急剧下降。MoE 大规模 Decode 用 EPAllToAll替代 TPAllReduce的动机正在于此。改动并行配置后注意权重处理若enable_online_split_weight: True运行时自动按配置切分权重无需重新转换若为 False权重与 parallel_config 绑定改配置后必须重新执行权重转换。最后需要强调本索引的两个适用前提其一是面向昇腾 Atlas A2 / A3 系列单机部署单机内 TP / EP 通信其二是parallel_config中dp_size/ep_size不直接在 YAML 中配置而是由框架按world_size // tp_size自动推导见 inference_config.py 与 executor_design.md。理解这两点后本索引即可作为日常并行策略分析的速查手册与验证基准使用。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考