CANN 上 LongCat-Flash-Lite 专家并行EP路径分阶段优化实战从 273ms 到 8.10ms 的 Decode 演进记录【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer导读本文基于 cann-recipes-infer 开源仓库中 LongCat-Flash-Lite 样例的 EP 路径优化过程归档progress_ep.md完整还原一条从「TP8 eager 基线」到「EP8 图模式 MLA Prolog 融合」的五阶段性能演进路径并行切分、Paged Attention Flash Attention、融合算子、MC2 专家通信算子、GE 图整图编译与 MLA Prolog 前置融合。读完本文你将掌握LongCat-Flash-Lite 这类「MLA Sparse MoE N-gram Embedding」架构在 Atlas A2/A3 上做专家并行部署的切分决策依据、每阶段对应的源码级改造点、yaml 配置方法以及如何用统一推理入口复现各阶段性能数据。一、模型与部署背景1.1 模型结构概览LongCat-Flash-LiteLongcatFlashNgramForCausalLM是采用「MLA Sparse MoE N-gram Embedding」架构的稀疏专家混合大语言模型14 层 × 双 sublayer 结构每个 sublayer 含 1 个 MLA attentionq_lora1536、kv_lora512、32 head Dense MLP shortcut MoE256 routed 128 identity experttop-12routed_scaling_factor6.0。词表 131072 N-gram 12 个 sub-table × 10.22 M 行 × 256 维。总参数量约 69 B其中 N-gram Embedding 约 31 B、MoE 约 34 B。该模型有三个关键特殊性直接决定了 EP 路径的切分方案详见 optimization_report_ep.md §2特殊点说明对部署的影响N-gram 子表占比巨大12 个子表共约 31 B 参数占总参约 46%单卡显存硬约束必须按 TP 切分MoE 双层结构256 routed 128 zeroidentityexpertzero expert 每卡持有、不参与 EP 切分Dual sub-layer attention每层 2 个 attention 1 个共享 MoEMoE 输出经 shortcut 与第二子层相加跨子层存在依赖是后续多流重叠的结构前提1.2 部署目标与并行拓扑EP 路径面向「中等 batch、吞吐优先」场景部署目标为 8 × Atlas A2 / A3、BF16 量化、1024 token 输入、128 token 输出见 progress_ep.md「部署目标」。最终确定的并行配置为差异化切分模块切分通信形式MLA Attentionattn_tp4按 head 切每卡 8 head、attn_dp2RowParallel AllReducedecode/ RSAGprefill SPDense MLPDP每卡完整权重无MoE routed expertsEP8每卡 32 expertMC2 dispatch_v2 / combine_v2decodedouble-routing AllToAllprefillMoE shared / identity本卡通过copy_expert_num折进 MC2主 EmbeddingDP1无N-gram EmbeddingTP8AllReduceLM HeadTP8AllGather这套拓扑在 longcat_flash_lite_rank_8_8ep.yaml 中落地为parallel_configparallel_config: world_size: 8 attn_tp_size: 4 dense_tp_size: 1 moe_tp_size: 1 embed_tp_size: 1 lmhead_tp_size: 8 model_config: exe_mode: ge_graph # [ge_graph, eager, npugraph_ex] custom_params: ngram_embed_tp_size: 8 # ngram sub-tables TP size; 0 follow embed_tp_sizengram_embed_tp_size是 EP 路径新引入的独立 TP 维度N-gram 子表与主 embed 解耦主表走 DP 复制、子表单独 TP8 切分避免主 embed 的逐层 AllReduce该参数的解析与默认逻辑在 inference_config.py 中默认 0 表示跟随embed_tp_size。二、阶段 0TP8 eager 基线4475 ms / 273 msEP 路径的优化起点是旧版 TP8 全张量并行实现全部模块含 MoE沿张量维切分attention 用手写 manual SDPAMoE 用 Python for-loop 逐 expert 计算。该基线的两项核心瓶颈为MoE 矩阵碎片化expert_intermediate1024在 TP8 下每卡只剩 128 维cube 利用率极低Python 级调度开销manual SDPA Python MoE loop 带来大量 host 侧下发与逐 expert 循环。基线实测数据Prefill 4475 ms、Decode 273 msbatch2attn_tp8见 progress_ep.md「进度概览」。EP 路径各阶段的目标就是逐项消灭这两个瓶颈。三、阶段 1并行切分改造Prefill 207 ms / Decode 151 ms3.1 候选方案推演阶段 1 首版分析推导出两个候选方案见「阶段 1 - 并行策略分析」归档D1纯 TP8全部张量并行包括 MoE。被否原因MoE 切 1024/8128 维成碎矩阵cube 利用率差D3attn_tp8 EP8attention 走 TP、MoE 走 EP最终被采纳。后续按客户方案进一步细化为dense_tp1 ngram_embed_tp8的差异化切分形成本文 §1.2 的最终拓扑。该方案的核心逻辑见 optimization_report_ep.md §4Dense MLP 走 DP-replicated避免逐层 AllReduce 同步开销单卡多放 1.4 GB 权重在 32 GB HBM 下负担得起MoE 走 EP8每卡持完整 32 个 expertGMM 单次调度的有效算力更高N-gram 子表独立 TP8约 31 B 参数必须切与主 embed 解耦后主表可走 DPattn_tp4 attn_dp2q/k/v/o 矩阵保持较大尺寸提升 cube 利用率batch2 时 MoE GMM 接近峰值。3.2 与旧 EP8 实现的差异旧ep8_optimize配置为「attn_tp8 dense_tp8 embed_tp8」一刀切Dense MLP 与主 Embedding 也沿 TP 切每层 AllReduceN-gram 子表与主 embed 共用embed_tp且强制batch % attn_tp 0校验BSPR check。新旧差异汇总progress_ep.md「阶段 1 - 并行化改造完成归档」模块旧 ep8新 ep8本次实现Dense MLPTP8 AllReduceDP1不切主 EmbeddingTP8 AllReduceDP1不切N-gram 子表与主 embed 共用 embed_tp独立ngram_embed_tp_size与主 embed 解耦MoEEP8 double-routingEP8 double-routing一致AttentionTP8TP8 / TP4 双套配置BSPR check强制batch % attn_tp 0已移除与 MLA 切头不冲突3.3 框架与代码改动文件变更inference_config.py新增ngram_embed_tp_size默认 0 → 取embed_tp_sizecomm_manager.py新增ngram_embed_tp_group与embed_tp_group/attn_tp_group智能复用infer.py删除batch_size_per_rank % attn_tp_size 0校验仅 Qwen3 BSH 切 batch 路径需要modeling_longcat_flash_lite.pyLongcatFlashMLP切到dense_tp_groupNgramEmbedding独立 tp 参数longcat_flash_lite_rank_8_8ep.yamldense_tp_size1embed_tp_size1ngram_embed_tp_size83.4 实测性能与关键观察配置PrefillDecode对比基线输出验证baseline旧 TP84475 ms273 ms——ep8 attn_tp8 batch1198 ms161 ms−41% decode与 baseline 输出对齐ep8 attn_tp4 batch2207 ms150 msper req 75 ms−45% decode输出对齐归档中记录的三条关键经验progress_ep.md「阶段 1 - 并行化改造完成归档」客户方案Dense DP合理性虽然每卡多 1.4 GB 权重但省下来的 AllReduce 通信时间显著32 GB HBM 下完全负担得起attn_tp4 batch2 优于 attn_tp8 batch1attn_tp 更小时 q/k/v/o 矩阵更大、cube 利用率更高且 batch2 让 MoE GMM 更接近峰值N-gram 子表 TP8 不必转 ReduceScatter当前 AllReduce 形式已能并行、没有 SP 串接转换无收益。阶段 1 验证数据attn_tp8 batch1 下 Prefill 198 ms / Decode 161 ms / 单卡显存峰值 19.6 GBattn_tp4 batch2 下 Prefill 220 ms / Decode 150 ms / 显存 20.4 GB输出均与 baseline 对齐。四、阶段 2KVCache Flash Attention 改造Decode 151 → 145 ms4.1 实施内容阶段 2 将 manual SDPA 替换为 Paged AttentionPA框架 Flash Attention v2progress_ep.md「阶段 2」替换_forward_legacy中的 manual SDPA 路径新增_forward_prefill_paNTD_TNDFA npu_kv_rmsnorm_rope_cache与_forward_decode_paTND_NTDFA absorb path新增LongcatFlashNgramForCausalLM.process_weights_after_loading→ 调用_init_absorb_weights拆分kv_b_proj为kv_b_proj_w_k/kv_b_proj_w_v新增init_pa_cache(...)按batch_size_per_dp_rank × ceil(max_seq / block_size)分配cache_nope、cache_rope、block_table删除 legacy 的k_cache / v_cache等属性避免model_worker._init_kvcache误分配约 336 MB legacy buffer。MLA 压缩 KV 与 PA 框架对接后每 token 仅缓存 576 维 latent KV512 nope 64 rope相比原 4-KV-head GQA 展开的 1280 维节省 55% 显存block_size128cache_modePA_NZ配合 FA v2 直读见 optimization_report_ep.md §5.1。4.2 性能验证与已知问题配置PrefillDecode输出对齐阶段 1 baseline207 ms151 ms基线阶段 2 PA FA455 ms145 ms与 baseline 输出一致Prefill 出现120% 退化对比 TP 路径同阶段仅 −1.6%归档中记录的待定位怀疑点包括旧 cache 残留后已修复、双 BMM 在 attn_tp4每卡 8 head时 launch 开销显著、npu_kv_rmsnorm_rope_cache在 attn_dp2 模式下首次 launch 被序列化。Decode 与 TP 路径一致持平图模式阶段 4才能拿到收益——这正是后续阶段的主攻方向。五、阶段 3融合算子替换Decode 145 → 124 ms阶段 3 把热点小算子替换为 torch_npu 融合算子消除逐算子 launch 开销progress_ep.md「阶段 3」改动说明LongcatFlashRMSNorm.forward用npu_rms_norm/npu_add_rms_norm融合 add norm支持(x, residual)接口LongcatFlashMLP合并gate_proj up_proj→MergedColumnParallelLinearnpu_swiglu1 GEMM 1 fused activation 替代原 2 GEMM 2 element-wiseLongcatFlashDecoderLayer.forward残差链式传递4 处npu_add_rms_norm节省 28 layer × 4 112 个独立 launch / stepload_weights支持 Dense MLPgate_proj/up_proj→gate_up_proj装载兼容 checkpoint 格式实测attn_tp4batch2seq1024Prefill 从 455 ms 降至244 ms阶段 2 的 120% 退化回收至 18%Decode 从 145 降至124 ms−18%输出与 baseline 一致。归档指出 Prefill 剩余 ~37 ms 差距疑似来自kv_b_proj_w_k/w_v双 BMM 的 ND→NZ 转换开销留待图模式验证。六、阶段 3.5MC2 dispatch_v2 接入Decode 68.55 → 43.17 ms6.1 实施记录EP Decode 路径的 MoE token 分发从 double-routing AllToAll 改为 MC2 通信算子npu_moe_distribute_dispatch_v2/npu_moe_distribute_combine_v2改动集中在 modeling_longcat_flash_lite.py_set_mc2_kwargs源码 modeling_longcat_flash_lite.py:904-937增加 4 个 expert 类型字段copy_expert_num self.zero_expert_num等于 128对应 identity expert、zero_expert_num 0、shared_expert_num 0、const_expert_num 0moe_infer_ep_decode删除routed_topk_ids[~routed_mask] 0掩码逻辑直接把含 256383 范围 identity expert id 的原始topk_ids传给dispatch_v2combine_v2调用增加ori_xhidden_states参数——API 要求copy_expert_num 0时必传op 内部按output ori_x × topk_weight处理 copy expert不再调用_compute_identity_output、不再做 identity_output累加forward()用is_prefill路由Prefill 仍走moe_infer_ep_prefilldispatch_v2 BS 上限 1024Prefill BS2048 会超限Decode 走新 MC2 路径。6.2 源码佐证Decode 的 MC2 调用链从源码看_forward_ep_decodemodeling_longcat_flash_lite.py:1039-1090在拿到 router 的topk_weight / topk_idx后output torch_npu.npu_moe_distribute_dispatch_v2( xhidden_states_2d, expert_idstopk_idx, **self.dispatch_kwargs, ) # ... FusedMoEGMM 专家计算 ... hidden_states_2d torch_npu.npu_moe_distribute_combine_v2( expand_xexpert_output, expert_idstopk_idx, assist_info_for_combineexpand_idx, expert_scalestopk_weight.to(torch.float32), ep_send_countsep_recv_counts, tp_send_countstp_recv_counts, ori_xhidden_states_2d, **self.combine_kwargs, )MC2 算子要求独占通信域因此set_mc2_kwargs使用独立的moe_ep_group_mc2通信域comm_algfullmesh_v2framework 为其分配专用 HCCL buffer见 comm_manager.py。6.3 实测A3attn_tp4batch2eager项阶段 3阶段 3.5ΔPrefill (post-warmup)162.2 ms161.4 ms−0.8 msDecode mean (n126)68.55 ms43.17 ms−25.4 ms−37%Decode min / max65.1 / 79.2 ms42.3 / 48.8 ms−23 / −30输出文本与阶段 3 baseline 完全一致。值得注意的是MC2 替换的是 Decode 路径的通信形态AllToAll → 专用 all-to-all 算子而 Prefill 因 dispatch_v2 的 BS 上限仍保留 double routing_dispatch_double_routing源码 modeling_longcat_flash_lite.py:939-954含.cpu().tolist()host sync。七、阶段 4GE 图整图编译Decode 43.17 → 9.11 ms7.1 框架就绪与改造清单阶段 4 参考 TP 路径经验用 torchairge_graph后端把 Decode 前向完整入图。框架侧已就绪executor/utils/execute_helper.py的compile_model_forward在compile_mode ge_graph时自动tng.compilerunner 通过is_prefill路由 Prefill → eager / Decode → graph。改造重点落在 modeling_longcat_flash_lite.py按依赖顺序#改动1顶部import torchair as tng2LongcatFlashMLA.__init__增self.fa_ops tng.ops if graph in compile_mode else torch.ops.npuDecode 内 FA 走self.fa_ops.npu_fused_infer_attention_score(...)3NgramEmbeddingngram_context改register_buffer新增init_ngram_cache(B, device)_shift_right_ignore_eos用 cummax / scatter 向量化去掉.item/ for-loop /if分支forward 中cat改copy_(...)写入 buffer4LongcatFlashNgramForCausalLM类属性_can_compile_fullgraph Trueinit_pa_cache末尾调init_ngram_cacheprocess_weights_after_loading()对kv_b_proj_w_k/w_v等用torch._dynamo.mark_static_address(...)P0LM headlist-basedall_gather改dist.all_gather_into_tensor少 dynamo breakP1MoE_set_mc2_kwargs中 host 字符串 / dict 在__init__缓存避免每步重建EP8 特有点TP 路径没有Decode MoE 走npu_moe_distribute_dispatch_v2/combine_v2longcat-flash 主仓已在 ge_graph 验证可行Prefill 走_dispatch_double_routing含.cpu().tolist()保留 eagerframework 用is_prefill自动分流LongcatFlashMoe.forward中if is_prefill:分支因is_prefill是 Python booldynamo 直接选支路 trace、不会 break。7.2 关键修复cummax 无 GE converter跑通过程中遇到 1 处代码修改_shift_right_ignore_eos_vectorized使用torch.cummax(...)GE 后端没有 cummax 的 ge converter报错ERR03-006: register operator [cummax] failed。修复方式是把cummax换成 Python 静态展开的 prefix-max chain参考 TP modeling line 1073-1077seq_len 在 N8 时只展开 8 步绕过缺失的 GE op。7.3 实测结果A3batch2attn_tp4exe_modege_graph指标值备注Decodecompile warmup 后稳态mean9.11ms / median 9.09 ms / min 9.04 / max 9.17n128 步含 dispatch_v2 combine_v2Prefill首次含编译8500 ms编译 ~7.8 s 实际 Prefill 700 msPrefill编译后稳态238.6 ms重新跑同 prompt输出对齐与 eager 完全一致—对比阶段 3.5eager dispatch_v2Decode 43.2 → 9.11 ms−79% / 4.74× 加速超出阶段 4 预设目标12–18 ms。收益来源与 TP 路径阶段 3.5 经验一致去 host dispatch 与整图编译收益。八、阶段 5MLA Prolog v3 接入Decode 9.11 → 8.10 ms8.1 实施记录阶段 5 在 Decode 路径接入npu_mla_prolog_v3融合算子progress_ep.md「阶段 5」关键改动LongcatFlashMLA.__init__增加self.enable_mla_prolog、self.weight_dq_prolog、self.weight_dkv_kr_prolog新增prepare_prolog_weights(enable_nzTrue)方法源码 modeling_longcat_flash_lite.py:311-331transposeq_a_proj/kv_a_proj_with_mqa权重并执行 NZ castnpu_format_cast(w, 29)29 FRACTAL_NZforward()在 Decode 路径增加 prolog 分支enable_mla_prolog and weight_dq_prolog is not None时走_forward_decode_prolog路由见 modeling_longcat_flash_lite.py:334-345新增_forward_decode_prolog方法modeling_longcat_flash_lite.py:505-626process_weights_after_loading增加 prolog 权重构建 mark_staticYAML 增加enable_mla_prolog: true默认 ge_graph 下开启。8.2 融合语义与源码佐证npu_mla_prolog_v3在单次调用内完成q_a_proj → RMSNorm → q_b_proj → split → interleaved RoPE → absorb-via-K与kv_a_proj_with_mqa → RMSNorm → RoPE → scatter 写入 PA cache替代 6–7 个独立小算子。核心调用modeling_longcat_flash_lite.py:537-555q_nope, q_pe, _, _, _ torch_npu.npu_mla_prolog_v3( hidden_states_2d, self.weight_dq_prolog, # (He, Hcq)q_a_proj 转置 NZ self.q_b_proj.weight, self.kv_b_proj_w_k, # absorb 用 self.weight_dkv_kr_prolog, # (He, Hckv Dr) self.q_a_layernorm.weight, self.kv_a_layernorm.weight, rope_sin, rope_cos, # TND 友好(num_tokens, qk_rope_head_dim) self.cache_nope, self.cache_rope, cache_indexcache_index, rmsnorm_epsilon_cqself.q_a_layernorm.variance_epsilon, rmsnorm_epsilon_ckvself.kv_a_layernorm.variance_epsilon, cache_modePA_NZ, qc_qr_scalefloat(self.mla_scale_q_lora), # Q-LoRA scale 折进 kernel kc_scale1.0, # cache 写入保持未缩放 )关键的数值约定kc_scale1.0让 cache 写入保持未缩放与 Prefill 路径npu_kv_rmsnorm_rope_cache共享同一尺度约定KV-LoRA scale 改为在q_nope输出上应用q_nope q_nope * self.mla_scale_kv_loraFA v2 输出端再乘一次mla_scale_kv_lora覆盖 V 侧。prolog 输出后的 attention 复用self.fa_ops.npu_fused_infer_attention_score_v2input_layoutTND_NTDV absorb 通过npu_transpose_batchmatmul完成。8.3 实测结果与风险项 (A3)阶段 4阶段 5ΔDecode mean (ms)9.118.10−11%Prefill steady (ms)238.6239~0输出文本与阶段 4 略有 token 分叉BF16 数值漂移语义保持一致参考 TP 阶段 57.14 → 5.49 ms −23%同类收益量级。归档中记录的三条风险npu_mla_prolog_v3精确参数名如rmsnorm_epsilon_cqvsrmsnorm_epsilon_q需实测确认prepare_prolog_weights在process_weights_after_loading之后调用此时q_a_proj/kv_a_proj_with_mqa权重已过quant_method后处理EP 路径当前用nn.Linear应未被替换若 EP 后续启用量化需要在prepare_prolog_weights里走 INT8 路径源码 modeling_longcat_flash_lite.py:183 注释也确认npu_mla_prolog_v3无 W8A8 入参MLA 必须保持 BF16。此外npu_mla_prolog_v3内部 BF16 累加顺序与拆解 op 不完全一致从中后段 Decode token 起可能出现 token 级选词差异语义保持等价属于可接受的数值行为。九、A2 / A3 跨硬件 stage-by-stage 实测归档文档记录了每个版本独立 checkout、清空 kernel_meta 后在 A2 / A3 两代硬件上的对照数据统一跑executor/scripts/infer.sh --model longcat_flash_lite --yaml longcat_flash_lite_rank_8_8ep.yamlattn_tp4、batch2、eager阶段A2 Prefill / Decode (ms)A3 Prefill / Decode (ms)A3 vs A2 Decode阶段 1并行切分207 / 151142.7 / 84.11.80×阶段 2PA FA455 / 145171.9 / 75.51.92×阶段 3融合算子244 / 123162.2 / 68.551.81×阶段 3.5MC2 dispatch_v2—161 / 42.5Decode −37% vs 阶段 3阶段 4GE graph—239 / 9.10Decode median 9.09 msn127稳态关键观察A3 上阶段 2 Prefill 仅 20%A2 上 120%combine_tokens.cpu().tolist()的 host sync 在 A3 上影响明显小A3 Decode 普遍快 1.8×与 TP 路径 A2→A3 的速比一致阶段 4 graph 模式将 Decode 从 68.55 → 9.10 ms与「去 host dispatch 整图编译」收益相符。十、复现方法与配置参考10.1 统一推理入口本样例通过 infer.sh 统一入口运行仅支持离线推理--mode默认offlinebash executor/scripts/infer.sh --model longcat_flash_lite --yaml longcat_flash_lite_rank_8_8ep.yaml参数含义取值示例--model模型目录名对应models/下的子目录longcat_flash_lite--yamlconfig/下的 yaml 文件名longcat_flash_lite_rank_8_8ep.yaml10.2 关键配置开关EP 路径 yaml 的核心字段longcat_flash_lite_rank_8_8ep.yamlparallel_config.attn_tp_size: 4attn_dp由 world_size 推导dense_tp_size: 1embed_tp_size: 1lmhead_tp_size: 8差异化切分拓扑model_config.custom_params.ngram_embed_tp_size: 8N-gram 子表独立 TP 切分model_config.exe_mode: ge_graph图模式后端可切换eager/npugraph_ex后者为 torch_npu 注册的 torch.compile backend同一份模型代码通过该字段切换无需改码model_config.enable_cache_compile: true将图编译产物缓存到config/cache_compile/重复启动复用缓存、跳过重新编译见 README.md「推理执行」。10.3 性能基线README 口径最终部署形态在 A3 8 卡上的基线数据README.md「性能基线」配置量化Global BatchSeq (in/out)卡数Prefill (ms)TPOT (ms)吞吐 (tokens/s)rank_8_8tp.yamlTP低延迟BF1611024/1288×A347.845.76174rank_8_8ep.yamlEP平衡BF1621024/1288×A3678.10247rank_8_8ep.yamlbatch_size8EP高吞吐BF1681024/1288×A3129.389.54838rank_8_8ep_w8a8.yamlEP量化 多流W8A884096/10248×A3—7.121124上表中的 8.10 ms TPOT 与本文阶段 5 的 8.10 ms Decode 对应同一最终形态详细性能拆解逐阶段贡献、A2/A3 对比、W8A8 与多流重叠拆解见 optimization_report_ep.md 与 optimization_report_tp.md。十一、总结EP 路径性能演进全景按 optimization_report_ep.md §10 的累计口径A3 平台 batch2 下各阶段 Decode 演进如下行间累加最右列对照初始 TP8 eager 基线路径关键改造Decode (ms/token)vs 基线基线 (TP8 eager)manual SDPA Python MoE loop2731.0× 并行切分EP8 Dense DP N-gram TP84.13.25× KVCache FAPA npu_fused_infer_attention_score_v275.53.62× 算子融合RMSNorm / SwiGLU / AddRMSNorm68.53.99× MC2 dispatch_v2npu_moe_distribute_dispatch_v2/combine_v243.26.32× GE 图整图torchair full-graph decode9.1030.0× MLA Prolog 融合npu_mla_prolog_v38.1033.7×EP 路径 A3 Decode 单步从 273 ms 降至 8.10 ms累计加速33.7×。这一演进的核心方法论可以提炼为三条① 切分形态服从算力形态MoE 走 EP 保 GMM 算力、Dense DP 省 AllReduce、N-gram 独立 TP 解耦显存约束② 通信替换优先于算子替换MC2 dispatch_v2 单步砍掉 37% Decode图模式再砍 79%③ 融合算子与整图编译是 Decode 收益的两级放大器融合算子回收 Prefill 退化并降 Decode 18%GE 图把 host 下发串行开销从关键路径彻底移除。后续如需在此基础上继续深入可对照 modeling_longcat_flash_lite.py 中各阶段改动位置逐段研读或在exe_mode三档eager / ge_graph / npugraph_ex之间切换复现各阶段差异。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CANN 上 LongCat-Flash-Lite 专家并行（EP）路径分阶段优化实战：从 273ms 到 8.10ms 的 Decode 演进记录
CANN 上 LongCat-Flash-Lite 专家并行EP路径分阶段优化实战从 273ms 到 8.10ms 的 Decode 演进记录【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer导读本文基于 cann-recipes-infer 开源仓库中 LongCat-Flash-Lite 样例的 EP 路径优化过程归档progress_ep.md完整还原一条从「TP8 eager 基线」到「EP8 图模式 MLA Prolog 融合」的五阶段性能演进路径并行切分、Paged Attention Flash Attention、融合算子、MC2 专家通信算子、GE 图整图编译与 MLA Prolog 前置融合。读完本文你将掌握LongCat-Flash-Lite 这类「MLA Sparse MoE N-gram Embedding」架构在 Atlas A2/A3 上做专家并行部署的切分决策依据、每阶段对应的源码级改造点、yaml 配置方法以及如何用统一推理入口复现各阶段性能数据。一、模型与部署背景1.1 模型结构概览LongCat-Flash-LiteLongcatFlashNgramForCausalLM是采用「MLA Sparse MoE N-gram Embedding」架构的稀疏专家混合大语言模型14 层 × 双 sublayer 结构每个 sublayer 含 1 个 MLA attentionq_lora1536、kv_lora512、32 head Dense MLP shortcut MoE256 routed 128 identity experttop-12routed_scaling_factor6.0。词表 131072 N-gram 12 个 sub-table × 10.22 M 行 × 256 维。总参数量约 69 B其中 N-gram Embedding 约 31 B、MoE 约 34 B。该模型有三个关键特殊性直接决定了 EP 路径的切分方案详见 optimization_report_ep.md §2特殊点说明对部署的影响N-gram 子表占比巨大12 个子表共约 31 B 参数占总参约 46%单卡显存硬约束必须按 TP 切分MoE 双层结构256 routed 128 zeroidentityexpertzero expert 每卡持有、不参与 EP 切分Dual sub-layer attention每层 2 个 attention 1 个共享 MoEMoE 输出经 shortcut 与第二子层相加跨子层存在依赖是后续多流重叠的结构前提1.2 部署目标与并行拓扑EP 路径面向「中等 batch、吞吐优先」场景部署目标为 8 × Atlas A2 / A3、BF16 量化、1024 token 输入、128 token 输出见 progress_ep.md「部署目标」。最终确定的并行配置为差异化切分模块切分通信形式MLA Attentionattn_tp4按 head 切每卡 8 head、attn_dp2RowParallel AllReducedecode/ RSAGprefill SPDense MLPDP每卡完整权重无MoE routed expertsEP8每卡 32 expertMC2 dispatch_v2 / combine_v2decodedouble-routing AllToAllprefillMoE shared / identity本卡通过copy_expert_num折进 MC2主 EmbeddingDP1无N-gram EmbeddingTP8AllReduceLM HeadTP8AllGather这套拓扑在 longcat_flash_lite_rank_8_8ep.yaml 中落地为parallel_configparallel_config: world_size: 8 attn_tp_size: 4 dense_tp_size: 1 moe_tp_size: 1 embed_tp_size: 1 lmhead_tp_size: 8 model_config: exe_mode: ge_graph # [ge_graph, eager, npugraph_ex] custom_params: ngram_embed_tp_size: 8 # ngram sub-tables TP size; 0 follow embed_tp_sizengram_embed_tp_size是 EP 路径新引入的独立 TP 维度N-gram 子表与主 embed 解耦主表走 DP 复制、子表单独 TP8 切分避免主 embed 的逐层 AllReduce该参数的解析与默认逻辑在 inference_config.py 中默认 0 表示跟随embed_tp_size。二、阶段 0TP8 eager 基线4475 ms / 273 msEP 路径的优化起点是旧版 TP8 全张量并行实现全部模块含 MoE沿张量维切分attention 用手写 manual SDPAMoE 用 Python for-loop 逐 expert 计算。该基线的两项核心瓶颈为MoE 矩阵碎片化expert_intermediate1024在 TP8 下每卡只剩 128 维cube 利用率极低Python 级调度开销manual SDPA Python MoE loop 带来大量 host 侧下发与逐 expert 循环。基线实测数据Prefill 4475 ms、Decode 273 msbatch2attn_tp8见 progress_ep.md「进度概览」。EP 路径各阶段的目标就是逐项消灭这两个瓶颈。三、阶段 1并行切分改造Prefill 207 ms / Decode 151 ms3.1 候选方案推演阶段 1 首版分析推导出两个候选方案见「阶段 1 - 并行策略分析」归档D1纯 TP8全部张量并行包括 MoE。被否原因MoE 切 1024/8128 维成碎矩阵cube 利用率差D3attn_tp8 EP8attention 走 TP、MoE 走 EP最终被采纳。后续按客户方案进一步细化为dense_tp1 ngram_embed_tp8的差异化切分形成本文 §1.2 的最终拓扑。该方案的核心逻辑见 optimization_report_ep.md §4Dense MLP 走 DP-replicated避免逐层 AllReduce 同步开销单卡多放 1.4 GB 权重在 32 GB HBM 下负担得起MoE 走 EP8每卡持完整 32 个 expertGMM 单次调度的有效算力更高N-gram 子表独立 TP8约 31 B 参数必须切与主 embed 解耦后主表可走 DPattn_tp4 attn_dp2q/k/v/o 矩阵保持较大尺寸提升 cube 利用率batch2 时 MoE GMM 接近峰值。3.2 与旧 EP8 实现的差异旧ep8_optimize配置为「attn_tp8 dense_tp8 embed_tp8」一刀切Dense MLP 与主 Embedding 也沿 TP 切每层 AllReduceN-gram 子表与主 embed 共用embed_tp且强制batch % attn_tp 0校验BSPR check。新旧差异汇总progress_ep.md「阶段 1 - 并行化改造完成归档」模块旧 ep8新 ep8本次实现Dense MLPTP8 AllReduceDP1不切主 EmbeddingTP8 AllReduceDP1不切N-gram 子表与主 embed 共用 embed_tp独立ngram_embed_tp_size与主 embed 解耦MoEEP8 double-routingEP8 double-routing一致AttentionTP8TP8 / TP4 双套配置BSPR check强制batch % attn_tp 0已移除与 MLA 切头不冲突3.3 框架与代码改动文件变更inference_config.py新增ngram_embed_tp_size默认 0 → 取embed_tp_sizecomm_manager.py新增ngram_embed_tp_group与embed_tp_group/attn_tp_group智能复用infer.py删除batch_size_per_rank % attn_tp_size 0校验仅 Qwen3 BSH 切 batch 路径需要modeling_longcat_flash_lite.pyLongcatFlashMLP切到dense_tp_groupNgramEmbedding独立 tp 参数longcat_flash_lite_rank_8_8ep.yamldense_tp_size1embed_tp_size1ngram_embed_tp_size83.4 实测性能与关键观察配置PrefillDecode对比基线输出验证baseline旧 TP84475 ms273 ms——ep8 attn_tp8 batch1198 ms161 ms−41% decode与 baseline 输出对齐ep8 attn_tp4 batch2207 ms150 msper req 75 ms−45% decode输出对齐归档中记录的三条关键经验progress_ep.md「阶段 1 - 并行化改造完成归档」客户方案Dense DP合理性虽然每卡多 1.4 GB 权重但省下来的 AllReduce 通信时间显著32 GB HBM 下完全负担得起attn_tp4 batch2 优于 attn_tp8 batch1attn_tp 更小时 q/k/v/o 矩阵更大、cube 利用率更高且 batch2 让 MoE GMM 更接近峰值N-gram 子表 TP8 不必转 ReduceScatter当前 AllReduce 形式已能并行、没有 SP 串接转换无收益。阶段 1 验证数据attn_tp8 batch1 下 Prefill 198 ms / Decode 161 ms / 单卡显存峰值 19.6 GBattn_tp4 batch2 下 Prefill 220 ms / Decode 150 ms / 显存 20.4 GB输出均与 baseline 对齐。四、阶段 2KVCache Flash Attention 改造Decode 151 → 145 ms4.1 实施内容阶段 2 将 manual SDPA 替换为 Paged AttentionPA框架 Flash Attention v2progress_ep.md「阶段 2」替换_forward_legacy中的 manual SDPA 路径新增_forward_prefill_paNTD_TNDFA npu_kv_rmsnorm_rope_cache与_forward_decode_paTND_NTDFA absorb path新增LongcatFlashNgramForCausalLM.process_weights_after_loading→ 调用_init_absorb_weights拆分kv_b_proj为kv_b_proj_w_k/kv_b_proj_w_v新增init_pa_cache(...)按batch_size_per_dp_rank × ceil(max_seq / block_size)分配cache_nope、cache_rope、block_table删除 legacy 的k_cache / v_cache等属性避免model_worker._init_kvcache误分配约 336 MB legacy buffer。MLA 压缩 KV 与 PA 框架对接后每 token 仅缓存 576 维 latent KV512 nope 64 rope相比原 4-KV-head GQA 展开的 1280 维节省 55% 显存block_size128cache_modePA_NZ配合 FA v2 直读见 optimization_report_ep.md §5.1。4.2 性能验证与已知问题配置PrefillDecode输出对齐阶段 1 baseline207 ms151 ms基线阶段 2 PA FA455 ms145 ms与 baseline 输出一致Prefill 出现120% 退化对比 TP 路径同阶段仅 −1.6%归档中记录的待定位怀疑点包括旧 cache 残留后已修复、双 BMM 在 attn_tp4每卡 8 head时 launch 开销显著、npu_kv_rmsnorm_rope_cache在 attn_dp2 模式下首次 launch 被序列化。Decode 与 TP 路径一致持平图模式阶段 4才能拿到收益——这正是后续阶段的主攻方向。五、阶段 3融合算子替换Decode 145 → 124 ms阶段 3 把热点小算子替换为 torch_npu 融合算子消除逐算子 launch 开销progress_ep.md「阶段 3」改动说明LongcatFlashRMSNorm.forward用npu_rms_norm/npu_add_rms_norm融合 add norm支持(x, residual)接口LongcatFlashMLP合并gate_proj up_proj→MergedColumnParallelLinearnpu_swiglu1 GEMM 1 fused activation 替代原 2 GEMM 2 element-wiseLongcatFlashDecoderLayer.forward残差链式传递4 处npu_add_rms_norm节省 28 layer × 4 112 个独立 launch / stepload_weights支持 Dense MLPgate_proj/up_proj→gate_up_proj装载兼容 checkpoint 格式实测attn_tp4batch2seq1024Prefill 从 455 ms 降至244 ms阶段 2 的 120% 退化回收至 18%Decode 从 145 降至124 ms−18%输出与 baseline 一致。归档指出 Prefill 剩余 ~37 ms 差距疑似来自kv_b_proj_w_k/w_v双 BMM 的 ND→NZ 转换开销留待图模式验证。六、阶段 3.5MC2 dispatch_v2 接入Decode 68.55 → 43.17 ms6.1 实施记录EP Decode 路径的 MoE token 分发从 double-routing AllToAll 改为 MC2 通信算子npu_moe_distribute_dispatch_v2/npu_moe_distribute_combine_v2改动集中在 modeling_longcat_flash_lite.py_set_mc2_kwargs源码 modeling_longcat_flash_lite.py:904-937增加 4 个 expert 类型字段copy_expert_num self.zero_expert_num等于 128对应 identity expert、zero_expert_num 0、shared_expert_num 0、const_expert_num 0moe_infer_ep_decode删除routed_topk_ids[~routed_mask] 0掩码逻辑直接把含 256383 范围 identity expert id 的原始topk_ids传给dispatch_v2combine_v2调用增加ori_xhidden_states参数——API 要求copy_expert_num 0时必传op 内部按output ori_x × topk_weight处理 copy expert不再调用_compute_identity_output、不再做 identity_output累加forward()用is_prefill路由Prefill 仍走moe_infer_ep_prefilldispatch_v2 BS 上限 1024Prefill BS2048 会超限Decode 走新 MC2 路径。6.2 源码佐证Decode 的 MC2 调用链从源码看_forward_ep_decodemodeling_longcat_flash_lite.py:1039-1090在拿到 router 的topk_weight / topk_idx后output torch_npu.npu_moe_distribute_dispatch_v2( xhidden_states_2d, expert_idstopk_idx, **self.dispatch_kwargs, ) # ... FusedMoEGMM 专家计算 ... hidden_states_2d torch_npu.npu_moe_distribute_combine_v2( expand_xexpert_output, expert_idstopk_idx, assist_info_for_combineexpand_idx, expert_scalestopk_weight.to(torch.float32), ep_send_countsep_recv_counts, tp_send_countstp_recv_counts, ori_xhidden_states_2d, **self.combine_kwargs, )MC2 算子要求独占通信域因此set_mc2_kwargs使用独立的moe_ep_group_mc2通信域comm_algfullmesh_v2framework 为其分配专用 HCCL buffer见 comm_manager.py。6.3 实测A3attn_tp4batch2eager项阶段 3阶段 3.5ΔPrefill (post-warmup)162.2 ms161.4 ms−0.8 msDecode mean (n126)68.55 ms43.17 ms−25.4 ms−37%Decode min / max65.1 / 79.2 ms42.3 / 48.8 ms−23 / −30输出文本与阶段 3 baseline 完全一致。值得注意的是MC2 替换的是 Decode 路径的通信形态AllToAll → 专用 all-to-all 算子而 Prefill 因 dispatch_v2 的 BS 上限仍保留 double routing_dispatch_double_routing源码 modeling_longcat_flash_lite.py:939-954含.cpu().tolist()host sync。七、阶段 4GE 图整图编译Decode 43.17 → 9.11 ms7.1 框架就绪与改造清单阶段 4 参考 TP 路径经验用 torchairge_graph后端把 Decode 前向完整入图。框架侧已就绪executor/utils/execute_helper.py的compile_model_forward在compile_mode ge_graph时自动tng.compilerunner 通过is_prefill路由 Prefill → eager / Decode → graph。改造重点落在 modeling_longcat_flash_lite.py按依赖顺序#改动1顶部import torchair as tng2LongcatFlashMLA.__init__增self.fa_ops tng.ops if graph in compile_mode else torch.ops.npuDecode 内 FA 走self.fa_ops.npu_fused_infer_attention_score(...)3NgramEmbeddingngram_context改register_buffer新增init_ngram_cache(B, device)_shift_right_ignore_eos用 cummax / scatter 向量化去掉.item/ for-loop /if分支forward 中cat改copy_(...)写入 buffer4LongcatFlashNgramForCausalLM类属性_can_compile_fullgraph Trueinit_pa_cache末尾调init_ngram_cacheprocess_weights_after_loading()对kv_b_proj_w_k/w_v等用torch._dynamo.mark_static_address(...)P0LM headlist-basedall_gather改dist.all_gather_into_tensor少 dynamo breakP1MoE_set_mc2_kwargs中 host 字符串 / dict 在__init__缓存避免每步重建EP8 特有点TP 路径没有Decode MoE 走npu_moe_distribute_dispatch_v2/combine_v2longcat-flash 主仓已在 ge_graph 验证可行Prefill 走_dispatch_double_routing含.cpu().tolist()保留 eagerframework 用is_prefill自动分流LongcatFlashMoe.forward中if is_prefill:分支因is_prefill是 Python booldynamo 直接选支路 trace、不会 break。7.2 关键修复cummax 无 GE converter跑通过程中遇到 1 处代码修改_shift_right_ignore_eos_vectorized使用torch.cummax(...)GE 后端没有 cummax 的 ge converter报错ERR03-006: register operator [cummax] failed。修复方式是把cummax换成 Python 静态展开的 prefix-max chain参考 TP modeling line 1073-1077seq_len 在 N8 时只展开 8 步绕过缺失的 GE op。7.3 实测结果A3batch2attn_tp4exe_modege_graph指标值备注Decodecompile warmup 后稳态mean9.11ms / median 9.09 ms / min 9.04 / max 9.17n128 步含 dispatch_v2 combine_v2Prefill首次含编译8500 ms编译 ~7.8 s 实际 Prefill 700 msPrefill编译后稳态238.6 ms重新跑同 prompt输出对齐与 eager 完全一致—对比阶段 3.5eager dispatch_v2Decode 43.2 → 9.11 ms−79% / 4.74× 加速超出阶段 4 预设目标12–18 ms。收益来源与 TP 路径阶段 3.5 经验一致去 host dispatch 与整图编译收益。八、阶段 5MLA Prolog v3 接入Decode 9.11 → 8.10 ms8.1 实施记录阶段 5 在 Decode 路径接入npu_mla_prolog_v3融合算子progress_ep.md「阶段 5」关键改动LongcatFlashMLA.__init__增加self.enable_mla_prolog、self.weight_dq_prolog、self.weight_dkv_kr_prolog新增prepare_prolog_weights(enable_nzTrue)方法源码 modeling_longcat_flash_lite.py:311-331transposeq_a_proj/kv_a_proj_with_mqa权重并执行 NZ castnpu_format_cast(w, 29)29 FRACTAL_NZforward()在 Decode 路径增加 prolog 分支enable_mla_prolog and weight_dq_prolog is not None时走_forward_decode_prolog路由见 modeling_longcat_flash_lite.py:334-345新增_forward_decode_prolog方法modeling_longcat_flash_lite.py:505-626process_weights_after_loading增加 prolog 权重构建 mark_staticYAML 增加enable_mla_prolog: true默认 ge_graph 下开启。8.2 融合语义与源码佐证npu_mla_prolog_v3在单次调用内完成q_a_proj → RMSNorm → q_b_proj → split → interleaved RoPE → absorb-via-K与kv_a_proj_with_mqa → RMSNorm → RoPE → scatter 写入 PA cache替代 6–7 个独立小算子。核心调用modeling_longcat_flash_lite.py:537-555q_nope, q_pe, _, _, _ torch_npu.npu_mla_prolog_v3( hidden_states_2d, self.weight_dq_prolog, # (He, Hcq)q_a_proj 转置 NZ self.q_b_proj.weight, self.kv_b_proj_w_k, # absorb 用 self.weight_dkv_kr_prolog, # (He, Hckv Dr) self.q_a_layernorm.weight, self.kv_a_layernorm.weight, rope_sin, rope_cos, # TND 友好(num_tokens, qk_rope_head_dim) self.cache_nope, self.cache_rope, cache_indexcache_index, rmsnorm_epsilon_cqself.q_a_layernorm.variance_epsilon, rmsnorm_epsilon_ckvself.kv_a_layernorm.variance_epsilon, cache_modePA_NZ, qc_qr_scalefloat(self.mla_scale_q_lora), # Q-LoRA scale 折进 kernel kc_scale1.0, # cache 写入保持未缩放 )关键的数值约定kc_scale1.0让 cache 写入保持未缩放与 Prefill 路径npu_kv_rmsnorm_rope_cache共享同一尺度约定KV-LoRA scale 改为在q_nope输出上应用q_nope q_nope * self.mla_scale_kv_loraFA v2 输出端再乘一次mla_scale_kv_lora覆盖 V 侧。prolog 输出后的 attention 复用self.fa_ops.npu_fused_infer_attention_score_v2input_layoutTND_NTDV absorb 通过npu_transpose_batchmatmul完成。8.3 实测结果与风险项 (A3)阶段 4阶段 5ΔDecode mean (ms)9.118.10−11%Prefill steady (ms)238.6239~0输出文本与阶段 4 略有 token 分叉BF16 数值漂移语义保持一致参考 TP 阶段 57.14 → 5.49 ms −23%同类收益量级。归档中记录的三条风险npu_mla_prolog_v3精确参数名如rmsnorm_epsilon_cqvsrmsnorm_epsilon_q需实测确认prepare_prolog_weights在process_weights_after_loading之后调用此时q_a_proj/kv_a_proj_with_mqa权重已过quant_method后处理EP 路径当前用nn.Linear应未被替换若 EP 后续启用量化需要在prepare_prolog_weights里走 INT8 路径源码 modeling_longcat_flash_lite.py:183 注释也确认npu_mla_prolog_v3无 W8A8 入参MLA 必须保持 BF16。此外npu_mla_prolog_v3内部 BF16 累加顺序与拆解 op 不完全一致从中后段 Decode token 起可能出现 token 级选词差异语义保持等价属于可接受的数值行为。九、A2 / A3 跨硬件 stage-by-stage 实测归档文档记录了每个版本独立 checkout、清空 kernel_meta 后在 A2 / A3 两代硬件上的对照数据统一跑executor/scripts/infer.sh --model longcat_flash_lite --yaml longcat_flash_lite_rank_8_8ep.yamlattn_tp4、batch2、eager阶段A2 Prefill / Decode (ms)A3 Prefill / Decode (ms)A3 vs A2 Decode阶段 1并行切分207 / 151142.7 / 84.11.80×阶段 2PA FA455 / 145171.9 / 75.51.92×阶段 3融合算子244 / 123162.2 / 68.551.81×阶段 3.5MC2 dispatch_v2—161 / 42.5Decode −37% vs 阶段 3阶段 4GE graph—239 / 9.10Decode median 9.09 msn127稳态关键观察A3 上阶段 2 Prefill 仅 20%A2 上 120%combine_tokens.cpu().tolist()的 host sync 在 A3 上影响明显小A3 Decode 普遍快 1.8×与 TP 路径 A2→A3 的速比一致阶段 4 graph 模式将 Decode 从 68.55 → 9.10 ms与「去 host dispatch 整图编译」收益相符。十、复现方法与配置参考10.1 统一推理入口本样例通过 infer.sh 统一入口运行仅支持离线推理--mode默认offlinebash executor/scripts/infer.sh --model longcat_flash_lite --yaml longcat_flash_lite_rank_8_8ep.yaml参数含义取值示例--model模型目录名对应models/下的子目录longcat_flash_lite--yamlconfig/下的 yaml 文件名longcat_flash_lite_rank_8_8ep.yaml10.2 关键配置开关EP 路径 yaml 的核心字段longcat_flash_lite_rank_8_8ep.yamlparallel_config.attn_tp_size: 4attn_dp由 world_size 推导dense_tp_size: 1embed_tp_size: 1lmhead_tp_size: 8差异化切分拓扑model_config.custom_params.ngram_embed_tp_size: 8N-gram 子表独立 TP 切分model_config.exe_mode: ge_graph图模式后端可切换eager/npugraph_ex后者为 torch_npu 注册的 torch.compile backend同一份模型代码通过该字段切换无需改码model_config.enable_cache_compile: true将图编译产物缓存到config/cache_compile/重复启动复用缓存、跳过重新编译见 README.md「推理执行」。10.3 性能基线README 口径最终部署形态在 A3 8 卡上的基线数据README.md「性能基线」配置量化Global BatchSeq (in/out)卡数Prefill (ms)TPOT (ms)吞吐 (tokens/s)rank_8_8tp.yamlTP低延迟BF1611024/1288×A347.845.76174rank_8_8ep.yamlEP平衡BF1621024/1288×A3678.10247rank_8_8ep.yamlbatch_size8EP高吞吐BF1681024/1288×A3129.389.54838rank_8_8ep_w8a8.yamlEP量化 多流W8A884096/10248×A3—7.121124上表中的 8.10 ms TPOT 与本文阶段 5 的 8.10 ms Decode 对应同一最终形态详细性能拆解逐阶段贡献、A2/A3 对比、W8A8 与多流重叠拆解见 optimization_report_ep.md 与 optimization_report_tp.md。十一、总结EP 路径性能演进全景按 optimization_report_ep.md §10 的累计口径A3 平台 batch2 下各阶段 Decode 演进如下行间累加最右列对照初始 TP8 eager 基线路径关键改造Decode (ms/token)vs 基线基线 (TP8 eager)manual SDPA Python MoE loop2731.0× 并行切分EP8 Dense DP N-gram TP84.13.25× KVCache FAPA npu_fused_infer_attention_score_v275.53.62× 算子融合RMSNorm / SwiGLU / AddRMSNorm68.53.99× MC2 dispatch_v2npu_moe_distribute_dispatch_v2/combine_v243.26.32× GE 图整图torchair full-graph decode9.1030.0× MLA Prolog 融合npu_mla_prolog_v38.1033.7×EP 路径 A3 Decode 单步从 273 ms 降至 8.10 ms累计加速33.7×。这一演进的核心方法论可以提炼为三条① 切分形态服从算力形态MoE 走 EP 保 GMM 算力、Dense DP 省 AllReduce、N-gram 独立 TP 解耦显存约束② 通信替换优先于算子替换MC2 dispatch_v2 单步砍掉 37% Decode图模式再砍 79%③ 融合算子与整图编译是 Decode 收益的两级放大器融合算子回收 Prefill 退化并降 Decode 18%GE 图把 host 下发串行开销从关键路径彻底移除。后续如需在此基础上继续深入可对照 modeling_longcat_flash_lite.py 中各阶段改动位置逐段研读或在exe_mode三档eager / ge_graph / npugraph_ex之间切换复现各阶段差异。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 时间 O(1) 空间的动态规划优化（LeetCode 题解）)
