当前位置：首页 > news >正文

LongCat-Flash与GLM-4.6V，昇腾CANN异构计算深水区突围详解

news 2026/3/26 19:32:44

自2024年下半年以来，大模型产业进入了一个充满张力的“双需求”周期。一方面，模型参数量持续向万亿级突破，以追求更强的智能涌现；另一方面，落地场景，尤其是在端侧交互与实时推理，对响应速度（Latency）的要求却近乎苛刻。

这种矛盾在MoE（混合专家）架构成为主流后变得尤为尖锐。虽然MoE凭借稀疏激活特性实现了“高参数、低计算量”，但其带来的通信风暴、专家调度复杂性以及负载不均衡难题，使其被业内称为推理部署的“噩梦”。

如何在算力底座上驯服这些庞然大物？近期，两个标志性事件给出了答案：美团发布的5600亿参数LongCat-Flash MoE模型，在昇腾Atlas A3平台上创下了TPOT（每Token生成时间）10ms的极致记录；而智谱AI最新的GLM-4.6V系列，则实现了在昇腾硬件上的0-Day首发适配。

在第三期的“昇腾CANN开源开放创享周”系列直播节目中，昇腾CANN生态技术专家郭光浩和昇腾CANN大模型技术专家许可对此进行了详细解读。

透过这两个独立但极具代表性的样本，我们大致可以窥见异构计算架构（CANN）在深水区的工程化解题思路。

拆解MoE困局：当“专家”变多，路就堵了

LongCat-Flash不仅参数量高达5600亿，其结构复杂度也极高：由MLA（Multi-Head Latent Attention）、DenseFFN以及MoE三个核心模块组成。其中MoE模块包含768个专家，分为512个路由专家和256个零计算专家。

在推理部署时，面对如此庞大的专家数量，通常采用EP（Expert Parallelism，专家并行）方案，将专家均匀切分到不同的计算卡上。然而，这直接引入了两个核心痛点：

1. 计算量的抖动：必须确保EP组内每张卡分配到的Token数量接近，否则会出现严重的负载不均衡。

2. 通信的瓶颈：Token需要在不同卡之间进行路由（Dispatch）和汇聚（Combine）。在多卡并行下，如果通信链路拥堵，专家的计算优势将被IO等待完全吞噬。

破局之道：多流并行与Single-Batch Overlap

许可介绍，为了解决上述问题，昇腾CANN团队在适配LongCat-Flash时，利用其SC-MoE（Shortcut-Connected MoE）架构特性，设计了一套深度的多流并行（Multi-Stream Parallelism）方案。

所谓的SC-MoE架构，具备“兵分两路”的特性：在前向传播中，一路结果直接给MoE模块，另一路则给DenseFFN及及第二个MLA模块。这为硬件层面的并行提供了绝佳的窗口——即Single-Batch Overlap (SBO)。

在具体的工程实现上，CANN将计算任务拆解到两条独立的计算流（Stream）上，Stream 1负责MLA、DenseFFN等算子，Stream 2负责MoE专家算子。

其关键在于引入了CV控核技术，通过精细控制Cube核（矩阵运算）和Vector核（向量运算）的资源分配，确保两路计算流互不抢占资源。最终达到的效果是：将MoE专家流中巨大的通信耗时和计算耗时，掩盖在另一路FFN和MLA的计算耗时之下。

此外，针对EP模式下频繁的跨卡通信，Atlas A3平台的Matrix Link高速互联能力发挥了关键作用，确保在增加部署卡数时，通信开销不会线性增长，从而避免了MoE专家流出现“长拖尾”现象。

压榨硬件极限：毫秒级时延是如何“抠”出来的？

宏观的架构优化解决了“路通”的问题，但要达到TPOT 10ms的极致性能，还需要在微观层面“抠”出每一个毫秒。在LongCat-Flash的优化案例中，许可分享的三项“微操”技术值得关注。

1. Super Kernel：消除调度的“碎片时间”

在大模型网络中，存在大量的小算子。虽然单个算子的执行时间很短，但成百上千的Task等待调度开销，积少成多后会成为隐形损耗。

CANN采用了Super Kernel技术，将网络中标定范围内的多个算子融合成一个“超级任务”进行下发。在LongCat-Flash中，研发团队分别在MLA段和两条并行流上标定了三个Super Kernel Scope，利用调度间隙优化算子的核启动时间，大幅降低了算子间的Overhead。

2. Weight Prefetching：让数据等算力

访存墙（Memory Wall）是制约大模型推理的另一大瓶颈。当算力足够强时，数据搬运往往跟不上计算速度。

权重预取（Weight Prefetching）技术利用了算子计算时的空闲带宽。例如，在进行AddLayerNorm融合算子计算时，后台已经开始将下一个MatMul算子所需的权重数据，从全局内存（GM）搬运到读写速度更快的L2 Cache中。当计算流推进到MatMul时，数据已经“在位”，从而实现了计算与访存的流水线掩盖。

3. MTP投机推理的进阶

为了进一步降低等效时延，LongCat-Flash在昇腾上从MTP1升级支持到了MTP2（Multi-Token Prediction）。

投机推理的本质是利用小模型（Draft Model）快速起草Token，再由主模型进行验证。在低时延场景下，通过提升单步推理的Token产出量（从预测1个变为预测2个甚至更多），可以显著摊薄整体的推理耗时，提升算力利用率。

融合算子的艺术：从“搭积木”到“定制模具”

在昇腾的优化哲学中，算子融合（Fusion）不是简单的物理拼接，而是对计算逻辑的深度重构。CANN提供了两类核心融合能力：

第一类是CV/VV融合。针对LongCat的MLA模块，CANN引入了MLA Prolog融合算子，它一次性替换了原有的QKV Proj、RoPE旋转位置编码以及KV Cache更新等一系列小算子逻辑。同时，FIA (FusedInferAttentionScore)融合算子替换了Core Attention的计算流程，将QKV计算与Softmax等操作完成融合，大幅提升了性能。

第二类是通算融合（MC2）。针对MoE网络特有的通信需求，MC2（MoE Dispatch & Combine）算子实现了通信与计算的算子级融合。这种细粒度的流水线设计，让Dispatch（分发）和Combine（汇聚）过程中的数据传输与计算逻辑相互掩盖，实现了“边传边算”。

另一个样本：GLM-4.6V与Host-Bound的系统级解法

如果说LongCat-Flash展示了CANN在模型架构层面的“微雕”能力，那么针对智谱AI的GLM-4.6V适配案例，则展示了其在推理引擎与系统调度层面的能力与通用性。

智谱AI近日上线并开源GLM-4.6V系列之时，昇腾作为自主创新的算力底座，首次支持了GLM系列开源模型与xLLM开源推理引擎的生态合作。不同于单纯追求单一模型的极致快，xLLM更关注服务层面的吞吐与稳定性。它采用了“服务-引擎分离”架构，配合昇腾硬件实现了动态PD分离和在离线潮汐调度，能够根据实时流量波动动态调整资源，解决了硬件利用率低的问题。

值得注意的是，在GLM系列的优化中，昇腾重点攻克了行业通用的Host-Bound（主机侧瓶颈）问题。

在高性能推理中，常出现Device侧（NPU）计算太快，而Host侧（CPU）下发指令来不及，导致NPU空转的现象，即“Host-Bound”。郭光浩介绍，CANN针对这一行业难题提供了两套系统级解法：

其一是ATB (Ascend Transformer Boost) 加速库。ATB对算子的Setup和Execute阶段进行了分离优化。在Setup阶段，通过Kernel Cache和InferShape复用，避免重复计算；在Execute阶段，将执行拆分为Pre-launch和Launch，通过分线程和全局Runner Pool机制，让算子下发更加紧凑，消除Device侧的空跑。

其二是ACL Graph（图下沉）技术，这是一个更彻底的方案。ACL Graph将Host侧需要频繁下发的算子Kernel缓存到Device侧。在第二次执行时，Host侧不再需要重新下发指令，而是直接触发Device侧重放（Replay）缓存的计算图。实测数据显示，在部分开源模型上，这种“图下沉”技术能带来高达300%的性能涨幅。

此外，GLM-4.6V带来的原生Function Call和“图像即参数”特性，对推理引擎的图文混排处理能力提出了新挑战，而xLLM引擎结合昇腾的全图化多层流水线架构，成功支撑了这种无需中间转换的高效多模态推理链路。