近期火爆的两篇论文，每个网络工程师都应该深读，均聚焦“规模化＋高效化”但侧重点不同。
• DeepSeek‑V3 提出 MLA 机制减少注意力通信开销，并通过低精度和均衡 MoE 激活优化模型分布式训练效率；
• CloudMatrix384 构建全互联统一总线网络，支持专家模型和 KV 缓存高效调度，显著提升推理时的带宽利用与通信效率。
翻译后的中文链接如下：
1、Insights into DeepSeek-V3
https://www.jianshu.com/p/b182ec1a7502
2、Serving Large Language Models on Huawei CloudMatrix384
01 https://www.jianshu.com/p/59d066353203
02 https://www.jianshu.com/p/06d49c49274a
在华为 CloudMatrix384 上服务大型语言模型
来源：arXiv:2506.12708v1 [cs.DC]
发布日期：2025年6月15日
摘要
大型语言模型（LLMs）的快速演进受益于参数规模的增长、专家混合（MoE）架构的采用，以及上下文长度的不断扩展，这些因素对AI基础设施提出了前所未有的要求。传统AI集群在计算强度、内存带宽、芯片间通信开销以及严格的延迟要求方面正面临严重限制。在真实场景中，还需应对工作负载的多样性与突发性、输入长度的变化，以及专家激活的不均衡等挑战，同时满足严格的服务级别目标。突破这些瓶颈，需要从根本上重构软硬件栈，进行协同设计。
本文介绍了华为的 CloudMatrix，这是新一代AI数据中心架构，体现了其重塑AI基础设施核心的愿景。CloudMatrix384是该愿景的首个生产级实现，它将384颗Ascend 910C NPU、192颗Kunpeng CPU以及其他硬件组件集成为一个统一的超级节点，通过高带宽、低延迟的统一总线（UB）网络互联。与传统分层架构不同，CloudMatrix384支持所有计算与内存资源之间的全互联访问，实现资源动态池化、统一访问和独立扩展。这些特性特别适用于通信密集型任务，如大规模MoE专家并行与分布式KV缓存访问，为下一代LLM部署提供了可扩展、高性能的基础。
为了充分发挥CloudMatrix384的能力，我们提出了CloudMatrix-Infer，一个完整的LLM推理解决方案，支持部署如DeepSeek-R1等大型MoE模型。其核心创新包括：（1）设计点对点服务架构，将预填、解码与缓存解耦并映射至独立可扩展的资源池，通过UB网络高带宽访问共享缓存，提高调度灵活性和缓存效率；（2）开发大规模专家并行策略，支持如EP320这样的并行度，每颗NPU封装一个专家，降低解码延迟；（3）提出一系列面向硬件的优化手段，包括算子优化、基于微批的流水线以及INT8量化等，以提升执行效率和资源利用率。
我们在DeepSeek-R1模型上的评估表明，CloudMatrix-Infer实现了业界领先的推理效率，在单个NPU上预填吞吐量达6688 tokens/s，解码吞吐量达1943 tokens/s，同时保持50ms以内的时间延迟，并在多个基准测试中保持与官方API一致的精度。该方案验证了CloudMatrix384结合CloudMatrix-Infer，作为大规模LLM服务的高吞吐、可扩展、可生产平台的可行性。
1 引言
近年来，大型语言模型（LLM）的格局经历了巨大的转变，这由几个决定性趋势驱动：参数规模的指数级增长、专家混合（MoE）架构的广泛采用以及上下文长度的显著扩展 [33]。现代 LLM，如 DeepSeek-R1 [13]、LLaMA-4 [39] 和 Qwen-3 [49]，通常扩展到数千亿甚至数万亿参数，对计算能力和内存能力提出了前所未有的需求。MoE 模型通过为每个令牌选择性地激活一小部分专家来引入结构稀疏性，从而在规模上实现更高的效率，同时在专家路由和同步方面引入了新的系统级挑战 [18; 30; 34]。同时，上下文窗口已从数万个令牌扩展到超过一百万个令牌 [21; 45]，给注意力计算和键值（KV）缓存存储带来了巨大压力。总 KV 缓存容量随并发用户数量线性增长，对如何在系统中分布、放置和访问 KV 缓存以支持高效推理提出了重大限制。这些趋势共同对 AI 基础设施造成了巨大压力，需要海量计算能力、高内存容量和带宽、密集的芯片间通信以及严格的延迟约束，最终将传统 AI 集群推向其可扩展性极限。
在生产环境中，服务此类模型因现实工作负载的动态性和异构性而进一步复杂化。具体来说，LLM 服务系统必须适应可变长度的用户输入、跨令牌的不平衡专家激活以及高度突发性的用户查询，同时维持严格的延迟和吞吐量目标。满足这些需求不仅仅是简单地扩展硬件资源。它需要全面的软硬件协同设计，包括紧密集成的计算、内存和网络硬件资源，辅以智能的任务调度、自适应的运行时编排以及能够动态响应不断演变的模型结构和波动工作负载的弹性资源管理策略。总之，随着 LLM 在规模和复杂性上的持续扩展，从根本上重新构想 AI 基础设施的设计变得至关重要。
为响应这些需求，我们提出了华为 CloudMatrix，一个基于完全点对点高带宽互连和细粒度资源解耦原则构建的下一代 AI 数据中心架构。我们特别强调 CloudMatrix384，这是这一创新架构理念的首个生产级实现。CloudMatrix384 是一个专为大规模 AI 工作负载构建的 AI 超级节点，采用全点对点互连的硬件设计。它包含 384 个昇腾 910C NPU 和 192 个鲲鹏 CPU，通过名为 统一总线（UB） 的超高带宽低延迟网络互连。特别是，这个 UB 网络支持所有计算和内存组件之间的直接全互联数据交换。与具有不均匀的节点内和节点间互连带宽的传统分层架构不同，CloudMatrix384 允许整个超级节点作为一个逻辑上统一、紧密耦合的计算实体运行，体现了“一切皆可池化、平等对待、自由组合”的全点对点原则。这些架构特性对于通信密集型操作特别有益，例如大规模 MoE 专家并行和分布式 KV 缓存访问，使 CloudMatrix384 成为下一代 LLM 服务的可扩展、高性能基础。
CloudMatrix384 的初始设计早于 MoE 架构的广泛采用 [15; 39; 49]，因为设计和部署这样一个全面的超级节点系统通常需要数年时间。尽管如此，CloudMatrix384 是专门为增强互连带宽和通信效率而构建的——这些核心能力对于扩展大型训练和推理工作负载至关重要。DeepSeek-R1 [13] 等大规模 MoE 模型的出现验证了这种架构的前瞻性，突显出现代 LLM 部署中通信带宽与计算和内存带宽能力同等重要。
为了充分利用 CloudMatrix384 的能力，我们提出了 CloudMatrix-Infer，这是一个全面的 LLM 服务解决方案，代表了部署 DeepSeek-R1 等大规模 MoE 模型的最佳实践。CloudMatrix-Infer 引入了三个核心创新点。
首先，我们设计了一种新颖的点对点服务架构，将 LLM 推理系统解耦为三个独立的子系统：预填充（prefill）、解码（decode）和缓存（caching）。点对点意味着这三个子系统作为平等且独立的资源池运行，不受中心化实体的编排。这与传统的以 KV 缓存为中心的架构 [41, 48] 形成鲜明对比，后者将请求调度与缓存 KV 块的物理位置紧密耦合，增加了调度复杂性并限制了资源分配的灵活性。通过利用高带宽 UB 互连，我们构建了一个解耦的内存池，提供跨系统的共享缓存服务。预填充和解码子系统中的所有 NPU 都可以以点对点方式、以统一的带宽和延迟直接从该池访问缓存的 KV 数据，而不管数据最初在何处计算或存储。这种设计将请求调度与数据局部性解耦，极大地简化了任务调度逻辑，提高了缓存效率，并增强了整体系统资源利用率。
其次，我们开发了一种专门为 MoE 模型优化的大规模专家并行（LEP）策略。LEP 的核心原理是聚合大量 NPU 的计算能力和内存带宽，以加速注意力和前馈网络的计算。这种加速的代价是由于令牌分发和专家输出组合而增加的通信开销。然而，CloudMatrix384 的超高带宽 UB 互连确保了这种通信延迟保持有界，不会成为主要的性能瓶颈。此外，我们的 LEP 策略支持极高的专家并行度，例如 EP320，使每个 NPU 芯片为 DeepSeek-R1 恰好托管一个专家。这种配置最小化了同一等级（rank）内专家之间的串行执行，从而降低了整体 MoE 执行延迟。这些设计选择共同实现了低解码延迟，并为基于 MoE 的推理带来了显著的端到端性能提升。
最后，我们引入了一套明确为 CloudMatrix384 定制的硬件感知优化，包括高度优化的昇腾算子、基于微批次的流水线和 INT8 量化。优化的算子加速了端到端执行，并为 LEP 提供了高效支持。基于微批次的流水线设计通过重叠两个连续微批次的处理，提高了资源利用率和系统吞吐量。INT8 量化提高了计算效率，并大幅减少了内存带宽消耗。这些优化共同与 CloudMatrix384 独特的架构特性（包括片上立方体（cube）、向量（vector）和通信引擎，以及高带宽 UB 互连）协同设计，以最大化整体执行效率。
我们在 CloudMatrix384 上使用 6710 亿参数的 DeepSeek-R1 模型对 CloudMatrix-Infer 进行的评估展示了令人印象深刻的性能和硬件效率。在预填充阶段，CloudMatrix-Infer 对于 4K 提示长度，实现了每个 NPU 6,688 tokens/s 的吞吐量。利用昇腾 910C 的 1,054 TFLOPS (INT8) 能力，这转化为 4.45 tokens/s/TFLOPS 的计算效率。在解码阶段，系统在维持每个输出令牌时间（TPOT）始终低于 50 ms 的同时，对于 4K KV 缓存长度，维持了每个 NPU 1,943 tokens/s 的吞吐量，产生了 1.29 tokens/s/TFLOPS 的效率。值得注意的是，这两个阶段的计算效率指标都超过了在 NVIDIA H100 上的 SGLang 和在 NVIDIA H800 上的 DeepSeek 等领先框架。CloudMatrix-Infer 还展示了在基本吞吐量-延迟权衡方面的有效管理。为了满足更严格的低于 15 ms TPOT 要求，CloudMatrix-Infer 可以动态调整其批次大小，实现每个 NPU 538 tokens/s 的解码吞吐量。
这突显了其在变化的服务级别目标（SLO）下可预测的性能和适应性。此外，INT8 量化在 16 个代表性基准测试中保持了与官方 DeepSeek-R1 API 相当的准确性。这些结果共同确立了 CloudMatrix384 与我们的点对点服务解决方案 CloudMatrix-Infer 相结合，作为大规模 LLM 部署的可扩展、高吞吐量、生产级平台。
本文的其余部分组织如下。第 2 节首先回顾关键的 LLM 趋势，并介绍传统数据中心基础设施固有的系统级挑战。第 3 节描述了华为 CloudMatrix 的愿景，并详细介绍了 CloudMatrix384 的设计。然后，我们在第 4 节介绍 CloudMatrix-Infer 中采用的服务系统架构和优化技术。第 5 节提供了详细的性能评估。最后，第 6 节概述了我们的未来研究方向，第 7 节对全文进行总结。
2. LLM 趋势及其对数据中心基础设施的挑战
在本节中，我们首先讨论塑造 AI 计算格局的大型语言模型（LLM）设计的最新趋势（§2.1）。然后，我们介绍这些趋势对传统数据中心基础设施施加的相应系统级挑战（§2.2）。
2.1 LLM 趋势
LLM 的快速发展以三个显著趋势为标志：模型参数数量不断增加、通过专家混合（MoE）架构采用稀疏性以及上下文窗口的扩展。这些发展旨在增强模型性能，同时解决计算效率和可扩展性问题。
越来越大的参数数量。 经验缩放定律表明，增加 LLM 中的参数数量可以改善模型在各种任务上的性能 [33]。近期的进展体现了这一趋势：Meta 的 Llama 4 Behemoth 拥有近 2 万亿参数，而其对应产品 Llama 4 Maverick 包含 4000 亿参数 [39]。DeepSeek-AI 开发的 DeepSeek-V3 包含 6710 亿参数 [15]。Google 的 PaLM 模型包含 5400 亿参数 [8]，xAI 的 Grok-1 拥有 3140 亿参数 [54]。这些模型强调了业界持续追求扩展 LLM 以增强推理、多语言理解和代码生成能力。
通过 MoE 实现稀疏性。 为了管理训练和推理不断上升的成本，现代 LLM 越来越多地采用稀疏激活的 MoE 架构，它将总模型容量与每令牌的计算需求解耦。著名的实现包括 Mixtral 8×7B，它包含 467 亿总参数，但通过将每个令牌路由到每层 8 个专家中的 2 个，仅激活每个令牌 129 亿参数，实现了与 GPT-3.5 相当的性能，同时保持计算效率 [32]。Databricks 的 DBRX 采用细粒度 MoE 架构，总参数 1320 亿，通过从 16 个较小的专家中选择 4 个，激活每个令牌 360 亿参数，提高了吞吐量并降低了延迟 [19]。Meta 的 Llama 4 系列在开源模型中引入了 MoE，其中 Llama 4 Maverick 使用 128 个专家，Llama 4 Scout 使用 16 个专家，两者均保持每个令牌 170 亿活跃参数 [39]。DeepSeek-V3 在其前身基础上扩展，将每层路由的专家数量从 160 增加到 256，从而在不按比例增加计算负载的情况下增强了模型容量 [14; 15]。阿里巴巴的 Qwen3-235B 模型包含 128 个专家，激活每个令牌 220 亿参数，平衡了大容量和计算效率 [49]。华为的盘古 Ultra MoE 模型扩展到 7180 亿参数，每个令牌激活 390 亿参数。它采用每层 256 个专家的 MoE 架构，其中每个令牌激活 8 个 [52]。总的来说，这些模型强调了 LLM 扩展策略的范式转变，强调架构稀疏性而非单纯参数数量，以实现增强的性能和效率。
上下文窗口的扩展。 LLM 中上下文窗口的扩展使得能够处理更长的序列，这对于需要扩展推理和连贯性的任务至关重要。最近的进展反映了这一转变：OpenAI 的 GPT-4.5 支持 128,000 个令牌的上下文窗口 [45]，而 Google 的 Gemini 2.5 Pro 提供高达 100 万个令牌的上下文窗口 [21]。LongBench [6] 等基准测试量化了扩展上下文窗口在问答、摘要和多步推理等任务中的好处。然而，向 LLM 输入长提示会显著增加计算成本并延长推理延迟。为了减轻这些成本，生产系统采用上下文缓存，其中从早期提示段生成的键值（KV）块在后续轮次或请求中被存储和重用。这种方法消除了提示的冗余注意力计算，从而减少了延迟并提高了效率 [20, 48]。
2.2 数据中心基础设施面临的挑战
这些 LLM 趋势对底层数据中心基础设施提出了严格的新要求。随着模型能力的持续扩展，它们推动了日益复杂的工作负载的出现，例如推理密集型推理、基于强化学习（RL）的训练后处理、交互式媒体生成和自主 AI 代理。这些应用不仅需要显著更大的计算和内存容量，还需要基础设施的根本性重新架构，以支持高带宽通信、低延迟存储访问和持续吞吐量，同时在动态、异构的现实条件下满足严格的服务级别延迟目标。在此背景下，我们确定了四个关键的系统级挑战：
挑战 1：扩展通信密集型并行性。 随着模型规模的增长，最先进的 AI 模型经常超出单个计算节点的容量，需要多节点并行策略。虽然现有的 AI 集群通过 RDMA 网络支持节点间通信，但其带宽和拓扑通常针对数据或流水线并行（DP/PP）进行了优化，这些并行方式涉及适度的节点间流量。然而，张量并行（TP）和专家并行（EP）需要频繁、细粒度和低延迟的通信，这在跨越节点边界时难以高效扩展。这迫使许多部署将 TP/EP 组限制在单个计算节点内，限制了可扩展性。
挑战 2：在异构 AI 工作负载下保持高利用率。 现代 AI 工作负载表现出高度多样化和动态的资源需求。训练通常是计算密集型的，推理（尤其是 LLM 的解码阶段）通常受内存带宽限制，而自动驾驶模型训练等任务涉及大量的 CPU 端数据预处理。固定的节点配置无法有效适应这种多样性，通常导致过度配置或利用率不足。为了最大化效率和适应性，现代 AI 基础设施必须支持异构资源（例如 NPU、CPU 和内存）的动态、细粒度组合，以适应每个工作负载的特定需求。
挑战 3：实现 AI 和数据密集型工作负载的融合执行。 AI 工作流越来越多地与数据摄取、预处理、检索、分析和模拟等传统数据密集型操作相交。同时，通用工作负载（例如数据库、大数据和 HPC）本身也在发展以融入 AI 能力。这些融合的执行模式要求高吞吐量、低延迟的通信和灵活的资源编排。然而，主要针对传统通用工作负载优化的传统数据中心基础设施难以满足这些严格的要求。实现 AI 和数据密集型任务的高效融合需要一个全新的基础设施。
挑战 4：提供内存级存储性能。 现代 AI 流水线在远超传统存储系统能力的前所未有的数据规模上运行。任务，例如摄取 PB 级数据集、管理多 TB 的模型检查点以及支持延迟敏感的推理（特别是在使用大型 KV 缓存和检索增强生成（RAG）模块时），需要具有内存级带宽、延迟和 IOPS 的存储子系统。围绕基于磁盘的访问模式设计的传统存储层次结构经常成为性能瓶颈，导致 NPU 因数据匮乏而利用率不足。
3 华为 CloudMatrix
为了应对 AI 工作负载中这些新兴的挑战，华为提出了 CloudMatrix，一个旨在重塑 AI 基础设施基础的下一代 AI 数据中心架构。这一架构愿景的核心是构建一个统一的、紧密耦合的计算结构，能够高效支持现代 AI 应用的规模、异构性和通信需求。CloudMatrix384 代表了这一愿景的首个生产级实现，提供了一个为大规模 AI 工作负载优化的专用平台。
本节首先概述 CloudMatrix 愿景（§3.1）。然后我们提供 CloudMatrix384 全点对点硬件架构的概述（§3.2），接着是其核心硬件组件的分解（§3.3）。接下来，我们介绍支持在华为云中部署 CloudMatrix 的软件栈（§3.4）。最后，我们分析其高效服务 DeepSeek-R1 等大规模 MoE 模型的适用性（§3.5）。
3.1 华为 CloudMatrix 愿景
为响应现代大规模 AI 工作负载不断增长的需求，华为推出了 CloudMatrix，一个开创性的下一代 AI 数据中心架构。该架构围绕完全点对点高带宽互连和细粒度资源解耦的原则精心设计。如图 1 概念性概述所示，CloudMatrix 超越了传统的以 CPU 为中心的分层设计。它促进了所有异构系统组件（包括 NPU、CPU、DRAM、SSD、NIC 和特定领域加速器）之间的直接、高性能通信，显著地不需要 CPU 仲裁。
该架构的核心是超高带宽、低延迟的统一总线（UB）网络，它促进了高效的全系统数据移动和协调。建立在此互连基础之上，CloudMatrix 提供了四个基础能力，共同定义了 AI 原生基础设施的新范式：
(1) 用于 TP/EP 的可扩展通信。 UB 互连支持跨 NPU 的直接、高吞吐量点对点通信，使 TP 和 EP 组能够扩展到单个节点的边界之外。这消除了节点间瓶颈，允许大型模型高效地分布在超级节点上。
(2) 面向异构工作负载的灵活资源组合。 CloudMatrix 将 CPU、NPU 和内存解耦为独立的池化资源，实现细粒度的、工作负载驱动的组合。这种灵活性允许基于工作负载需求进行细粒度的资源分配（例如，内存丰富的缓存节点、CPU 密集型的预处理节点），使部署摆脱固定的节点配置或基于 PCIe 的主机-设备耦合。
(3) 融合工作负载的统一基础设施。 高带宽 UB 网络支持在单个纵向扩展（scale-up）基础设施内运行 AI 和数据密集型应用。这实现了 LLM 推理、训练、模拟和分析工作负载的融合执行，这是混合 AI 流水线日益普遍的需求。
(4) 通过解耦内存池实现内存级存储。 CloudMatrix 将集群中连接到 CPU 的 DRAM 聚合到一个可通过 UB 访问的共享高性能内存池中。这一基础支撑了诸如弹性内存服务（EMS）[26] 等服务，通过消除传统的 I/O 瓶颈，加速了 KV 缓存重用、参数加载和模型检查点等延迟关键型操作。
下面描述的华为 CloudMatrix384 是这一架构愿景的首个生产级实现。它专门设计用于满足下一代 AI 工作负载在大规模下的计算、内存和通信需求。
3.2 CloudMatrix384 概述：全点对点硬件架构
CloudMatrix384 被设计为一个 AI 超级节点，集成了 384 个昇腾 910C 神经网络处理单元（NPU）和 192 个鲲鹏中央处理单元（CPU），如图 2 所示。
CloudMatrix384 的一个决定性特征是其点对点、全互连、超高带宽网络，该网络通过 UB 协议连接所有 NPU 和 CPU。CloudMatrix384 的 UB 设计是 [38] 中提出的 UB-Mesh 的前身。384 个 NPU 和 192 个 CPU 中的每一个都通过 UB 交换机连接，实现了节点间通信性能接近节点内水平。如表 1 所示，节点间带宽下降低于 3%，节点间延迟增加小于 1 us。鉴于现代 AI 工作负载主要是带宽密集型而非延迟敏感型，这种微小的延迟开销对 AI 任务的端到端性能影响可忽略不计。总体而言，这种设计使 CloudMatrix384 能够作为一个紧密耦合的大规模逻辑节点运行，具有全局可寻址的计算和内存，促进统一的资源池化和高效的工作负载编排。
为了支持不同的流量模式并保持与传统数据中心网络的兼容性，CloudMatrix384 包含三个不同但互补的网络平面：
UB 平面。 UB 平面构成了超级节点内主要的超高带宽纵向扩展（scale-up）结构。它直接以无阻塞（non-blocking）的全互联拓扑互连所有 384 个 NPU 和 192 个 CPU。每个昇腾 910C 贡献超过 392 GB/s 的单向带宽。UB 支持：(1) 高效实现细粒度并行策略，如 TP 和 EP，不受节点边界限制；(2) 快速点对点访问池化内存（跨越 CPU 和 NPU 内存），这对于高效缓存模型权重和 KV 缓存至关重要。
RDMA 平面。 RDMA 平面支持跨 CloudMatrix384 超级节点和外部 RDMA 兼容系统的横向扩展（scale-out）通信。它目前采用基于融合以太网的 RDMA（RoCE）以确保与标准 RDMA 栈兼容¹。每个 NPU 贡献高达 400 Gbps 的单向 RDMA 带宽。NPU 是该平面的唯一参与者，将 RDMA 流量与控制操作和存储操作隔离。关键功能包括：(1) 在推理过程中在预填充和解码 NPU 之间高速传输活跃的 KV 缓存数据；(2) 支持使用符合 RDMA 的框架进行分布式训练和推理；(3) 在多集群部署中跨超级节点的低延迟互连。
¹ 另一种设计，UB 上的 RDMA（RDMA over UB），利用 UB 对远程内存访问的原生支持，形成统一的 UB 域用于超级节点内和超级节点间通信。虽然这种方法提供了简化的语义并避免了协议转换开销，但当前实现选择 RoCE 以确保与现有 RDMA 库和工具的即时兼容性。
- VPC 平面。 虚拟私有云（VPC）平面通过高速 NIC（华为的擎天卡）将 CloudMatrix384 超级节点连接到更广泛的数据中心网络，每个节点提供高达 400 Gbps 的单向带宽。它在标准以太网和 IP 协议上运行，可选择通过以太网上的 UB（UBoE）进行增强。VPC 平面处理：(1) 管理和控制平面操作，如部署、监控和调度；(2) 访问持久存储，包括对象存储服务（OBS）、弹性卷服务（EVS）和可扩展文件系统服务（SFS）；(3) 来自 CPU 常驻工作负载（例如数据库和用户界面）的外部服务通信。
尽管 CloudMatrix 的长期愿景旨在将 RDMA 和 VPC 平面融合为如图 1 所示的单一统一平面，但当前的 CloudMatrix384 将它们分开以确保与遗留数据中心基础设施的向后兼容性。我们在 §6.1.1 中讨论了统一 VPC 和 RDMA 平面的未来工作。
3.3 硬件组件
3.3.1. 昇腾 910C 芯片
CloudMatrix 384 的核心是海思昇腾 910C NPU，这是华为 2024 年推出的旗舰 AI 加速器，接替了原始的昇腾 910B。910C 是一个双芯片（dual-die）封装：两个相同的计算芯片共封装在一起，共享八个封装上（on-package）内存堆栈，并通过高带宽跨芯片互连结构连接，如图 3 所示。
计算。 每个芯片维持约 376 TFLOPS 的稠密 BF16/FP16 吞吐量，每个封装总共有 752 TFLOPS。每个芯片包含 24 个 AI 立方体（AIC）核心，针对矩阵和卷积工作负载进行了优化，以及 48 个 AI 向量（AIV）核心用于逐元素操作。所有计算引擎都支持 FP16/BF16 和 INT8 数据类型。8 位量化可以使用 INT8 精度实现，实现与原生 FP8 硬件相当的计算效率，而无需专用的 FP8 支持。两个芯片通过封装上互连进行通信，提供高达 540 GB/s 的总带宽，每个方向 270 GB/s。
内存。 昇腾 910C 封装集成了八个内存堆栈（每个 16 GB），提供总共 128 GB 的封装上内存（每个芯片 64 GB）。该封装提供高达 3.2 TB/s 的总内存带宽，每个芯片可用 1.6 TB/s。
网络接口。 每个昇腾 910C 芯片接口连接两个不同的网络平面。1) UB 平面：芯片集成了七个高速收发器，每个工作在 224 Gbps，提供总计 196 GB/s 单向（或 392 GB/s 双向）带宽连接到纵向扩展 UB 平面。2) RDMA 平面： 另外，每个芯片包含一个专用接口，为横向扩展 RDMA 平面提供高达 200 Gbps 的单向带宽。
3.3.2 昇腾 910C 节点
CloudMatrix384 中的每个计算节点集成了 8 个昇腾 910C NPU、4 个鲲鹏 CPU 和 7 个板载 UB 交换芯片，如图 4 所示。12 个处理器（8 个 NPU 和 4 个 CPU）通过 UB 链路连接到这些板载交换机，在节点内创建一个单层 UB 平面。每个 NPU 配置高达 392 GB/s 的单向 UB 带宽，而每个鲲鹏 CPU 插槽接收约 160 GB/s 的单向 UB 带宽。单个板载 UB 交换芯片提供 448 GB/s 的上行链路容量，连接到超级节点结构中的下一级交换层。
只有 NPU 参与次要的 RDMA 平面。每个 NPU 设备为横向扩展 RDMA 流量贡献一个额外的 400 Gbps 单向链路，每个节点产生总计 3.2 Tbps 的 RDMA 带宽。
在 CPU 复合体中，四个鲲鹏 CPU 插槽通过全网格 NUMA 拓扑互连，实现跨所有 CPU 连接 DRAM 的统一内存访问。其中一个 CPU 承载节点的擎天卡，这是一个专用的数据处理单元（DPU），不仅集成了高速网络接口，还执行基本的节点级资源管理功能。这个擎天卡作为节点主要的南北向出口点，与第三个不同的网络平面：数据中心的 VPC 平面 对接。
3.3.3 UB 交换系统
CloudMatrix384 超级节点跨越 16 个机架：12 个计算机架，共同承载 48 个昇腾 910C 节点（总共 384 个 NPU），以及 4 个通信机架。这些通信机架容纳了连接超级节点内所有节点的第二层（L2）UB 交换机。
图 5 说明了板载第一层（L1）UB 交换机（位于每个昇腾 910C 节点内部）与机架级 L2 UB 交换机之间的拓扑结构。网络设计为无阻塞（non-blocking），意味着在 L2 交换层没有带宽超额认购（oversubscription）。L2 交换机被划分为 7 个独立的子平面_。每个子平面包含 16 个 L2 UB 交换芯片，每个 L2 交换芯片提供 48 ×28 GB/s 端口。
在每个节点内部，7 个板载 L1 UB 交换芯片与这 7 个 L2 子平面一一对应。每个 L1 交换芯片通过 16 个链路扇出（每个链路连接到其对应子平面中的每个 L2 交换芯片）。这种配置确保节点到 L2 结构的总上行链路带宽精确匹配其内部 UB 容量，在整个超级节点上保持无阻塞特性。
3.4 软件栈
3.4.1 昇腾 NPU 的 CANN
华为为昇腾 NPU 开发了全面的软件生态系统，称为神经网络计算架构（CANN）[29]。CANN 充当一个中间软件层，实现了高级 AI 框架（如 PyTorch [46] 和 TensorFlow [2]）与昇腾 NPU 底层硬件接口之间的高效集成。通过将这些框架生成的抽象计算图转换为优化的、硬件可执行的指令，CANN 简化了开发人员与昇腾硬件的交互，促进了软硬件协同设计，并旨在最大化昇腾架构上的应用程序性能。
CANN 架构。 CANN 软件栈（图 6）由三个主要层组成：驱动程序、运行时和库，这种架构类似于 NVIDIA 的 CUDA 生态系统 [40]。
驱动层： 在底层，昇腾 NPU 驱动程序（包括内核模块和固件）充当操作系统与昇腾 NPU 之间的低级接口。它管理基本的硬件交互，包括设备初始化、资源分配（内存、流）、命令调度和 NPU 间通信设置。
运行时层： CANN Runtime 是昇腾 NPU 上应用程序的核心执行引擎。它监督应用程序生命周期，编排模型计算，并为模型和算子提供全面的设备控制、内存管理和执行管理。这些功能主要通过昇腾计算语言（ACL）API 访问。
库层： 该层提供一套高度优化的软件组件，以加速各种 AI 工作负载。关键元素包括特定领域的加速库（AOL）、用于分布式任务的华为集合通信库（HCCL）、带有预优化内核的广泛算子包（OPP）以及神经网络加速引擎（NNAE）和离线推理引擎（NNRT）。支持自定义算子开发（例如通过昇腾 C）以及与第三方库的集成以进一步增强其能力。
在核心层之外，图引擎（GE） 编译并优化来自 PyTorch、TensorFlow 和 MindSpore [28] 等框架的计算图。它通过应用全图优化（如算子融合、内存规划、动态形状处理和调度）来桥接高级模型和低级执行。这些优化减少了开销，提高了昇腾 NPU 上的执行效率。
框架集成。 CANN 为流行的 AI 框架提供广泛支持，显著降低了现有和新 AI 项目采用昇腾 NPU 的门槛：
*PyTorch： 通过 PyTorch 昇腾适配器 (torch_npu) [4]，开发人员可以在其现有的 PyTorch 工作流中无缝利用昇腾 NPU 加速。华为通过预构建的 Python wheel 包提供简单安装，提供关于 API 兼容性和最佳实践的全面文档，并提供简化工具或指南，用于将基于 CUDA 的代码迁移到 CANN。
*TensorFlow： CANN 的 TF_Adapter [5] 将昇腾加速能力直接集成到 TensorFlow 框架中，使基于 TensorFlow 的 AI 项目能够以最少的代码修改实现高性能和直接采用。
*ONNX： 华为为 ONNX 运行时提供了一个专用的 CANN 执行提供程序（execution provider）[43]。这支持高效执行以开放神经网络交换（ONNX）格式 [42] 导出的模型，促进了在包括昇腾 NPU 在内的异构硬件环境中的广泛模型兼容性和简化部署。
*MindSpore： 由华为内部开发，MindSpore 提供与昇腾硬件的原生且高度优化的集成。该框架旨在在华为 AI 生态系统中提供潜在更优的性能和易用性，提供了一个紧密耦合的软硬件解决方案。
总之，CANN 提供了一个垂直集成的软件栈，包括驱动程序、运行时和库，与 NVIDIA 的 CUDA 相当，同时针对昇腾 NPU 定制。其 GE 将全图表示编译为高度优化的执行计划，丰富的框架适配器使得移植现有工作负载几乎无摩擦。这些组件共同使开发人员能够以最少的代码更改利用昇腾硬件，同时在广泛的 AI 应用中实现接近峰值的设备性能。
3.4.2 云部署的基础设施软件
为了在云环境中启用 CloudMatrix384 部署，华为云提供了一套复杂的基础设施软件，包括 MatrixResource、MatrixLink、MatrixCompute 和 MatrixContainer，旨在抽象硬件复杂性并通过标准云 API 实现无缝资源编排，如图 7 所示。
MatrixResource 管理超级节点内的物理资源供应，包括基于拓扑感知调度的计算实例分配。实例供应任务由在每个 CloudMatrix384 计算节点的擎天卡上运行的 MatrixResource 代理执行。
MatrixLink 为 UB 和 RDMA 网络提供面向服务的网络功能，支持 QoS 保证和动态路由。它管理链路级配置，并支持网络感知的工作负载放置，以实现最佳通信效率。这些任务也由每个计算节点擎天卡上的 MatrixLink 代理执行。
MatrixCompute 协调 CloudMatrix 实例的生命周期，从裸机供应到自动扩展和故障恢复。它跨多个物理节点编排资源组合，以创建紧密耦合的逻辑超级节点实例。
MatrixContainer 提供基于 Kubernetes 的容器服务，通过拓扑感知调度增强，以利用 CloudMatrix 的高性能互连。它使用户能够使用熟悉的容器化工作流部署分布式 AI 工作负载。
ModelArts 位于基础设施栈之上，提供端到端的 AI 平台服务 [27]。它包括：ModelArts Lite，用于通过裸机和容器化环境直接访问昇腾硬件；ModelArts Standard，支持完整的 AI 开发和 MLOps 流水线；ModelArts Studio，提供模型即服务（MaaS）能力，用于快速部署和定制 LLM 及其他模型。
这些组件共同使用户能够在 CloudMatrix384 上高效地构建和部署大规模 AI 应用程序，在保留性能的同时抽象底层复杂性。
3.5 DeepSeek 模型的适用性分析
3.5.1. DeepSeek 模型及其在 NVIDIA H800 上的部署
DeepSeek-AI 已成为 LLM 领域的重要参与者，特别是其 DeepSeek-V3 和 R1 模型，它们共享一个针对高效训练和推理优化的通用架构 (Krizhevsky et al., 2014; Krizhevsky et al., 2016)。这些模型集成了多项系统级创新：一个 671B 参数的专家混合（MoE）架构，使用跨 256 个路由专家的 top-8 路由，每个令牌仅激活 37B 参数；多头潜在注意力（MLA），将 KV 缓存大小减少高达 93.3%；多令牌预测（MTP），支持在解码时验证的多令牌生成；以及 FP8 量化，在保持准确性的同时提升性能。总之，DeepSeek 的模型体现了一种以训练和推理效率为中心的设计理念。这些创新共同促成了模型以更少的计算和内存需求提供高质量输出的能力。
DeepSeek 将其 V3 和 R1 模型部署在 NVIDIA H800 GPU 集群上，每个 GPU 配备 80 GB 内存，节点内通过 NVLink 连接，节点间通过 400 Gbps InfiniBand 连接 (Krizhevsky et al., 2017)。该部署采用了分离的预填充-解码架构。在预填充阶段，DeepSeek 将四个 H800 节点（总共 32 个 GPU）组织成一个部署单元。在每个单元内，256 个路由专家被策略性地分布在 GPU 上，每个 GPU 托管九个路由专家和一个共享专家。这种配置表示为 DP32+EP32，在 32 个 GPU 上采用专家并行（EP），而共享专家和 MLA 机制通过数据并行（DP）在同一组 GPU 上进行复制。在解码阶段，DeepSeek 将并行度进一步扩展到 DP144+EP144，将 18 个节点分组，总共 144 个 GPU。在此更大的部署下，每个 GPU 管理两个路由专家和一个共享专家，保持系统范围内 32 个路由专家副本的冗余。
为了优化吞吐量和延迟，DeepSeek 采用了双微批次流水线策略，有效重叠计算和全对全（all-to-all）通信。具体来说，当一个微批次参与 MoE 相关的分发和组合时，下一个微批次同时进行本地注意力或 MLP 计算。
这种精心编排的部署带来了显著的吞吐量收益。在预填充阶段，每个 H800 GPU 实现了高达 9,213 tokens/s 的吞吐量，得益于 56.3% 的上下文缓存命中率，当排除缓存命中时，有效吞吐量为 4,026 tokens/s。在解码期间，每个 GPU 维持平均 1,850 tokens/s 的吞吐量。
这些性能优化策略为即将在华为 CloudMatrix384 上部署 DeepSeek 模型提供了宝贵的参考。
3.5.2. CloudMatrix384 与 DeepSeek 模型之间的架构协同
本小节使用 DeepSeek-R1 作为代表性工作负载，分析华为 CloudMatrix384 的架构特性如何与大规模 MoE 模型服务的需求相一致。我们关注四个关键的协同维度：MoE 通信、内存可扩展性、缓存重用和量化支持。
MoE 通信协同：高效分发与组合。 DeepSeek-R1 采用 MoE 架构，这在令牌分发和专家输出组合期间对 NPU 间通信提出了大量需求。CloudMatrix384 的高带宽、低延迟 UB 互连特别适合这些要求。在分发期间，令牌必须从路由器路由到选定的专家，可能跨越数百个 NPU。全互联 UB 拓扑确保了最小的开销实现快速交付。类似地，在组合阶段，多个专家的输出必须通过跨分布式计算单元的加权求和进行合并。UB 平面的高带宽使得能够高效收集专家输出，优于传统架构（在这些架构中，网络性能会严重阻碍 MoE 推理吞吐量）。
内存容量与管理：容纳大型模型和 KV 缓存。 DeepSeek-R1 的参数数量接近 671B，需要巨大的内存资源用于权重和激活，包括注意力 KV 缓存。CloudMatrix384 提供总计 49.2 TB 的 NPU 连接内存（每个 NPU 128 GB × 384 个 NPU），支持通过张量并行、流水线并行和专家并行组合分布式存储模型权重。除了模型权重，LLM 的注意力机制还维护着庞大的 KV 缓存，特别是在长上下文或高批次工作负载下。CloudMatrix384 的充裕内存占用支持这些场景，但高效地跨 NPU 分区和同步 KV 缓存仍然至关重要。
上下文缓存重用：加速缓存访问。 LLM 工作负载，特别是在多轮对话和长上下文应用中，从前缀缓存重用中受益匪浅，DeepSeek-AI 报告缓存命中率超过 56%。在传统系统中，从片外 DRAM 甚至更慢的存储层检索历史 KV 缓存会引入显著的延迟，阻碍推理性能。CloudMatrix384 通过使 NPU 能够直接通过高带宽 UB 平面（§4.4.1）访问解耦的、CPU 连接的 DRAM 池来缓解这一瓶颈。该架构为远程 KV 缓存访问提供了内存级的带宽和延迟。因此，它最大限度地减少了冗余的预填充计算，显著降低了首令牌时间（TTFT），并能够高效地扩展到长上下文工作负载，而不会耗尽有限的 NPU 内存。
效率量化：INT8 支持。 昇腾 910C 对 INT8 计算的支持（如 §3.3.1 所述）为优化 DeepSeek 模型的推理性能提供了宝贵的机会。将模型权重和激活从更高精度格式（如 FP16 或 BF16）量化为 INT8 可以显著减少模型的内存占用，降低计算开销，并减轻执行期间的内存带宽需求。这些好处可以转化为更高的吞吐量和更低的延迟。
总之，CloudMatrix384 的架构，包括其大规模 NPU 计算、广泛的内存容量、高带宽 UB 互连以及基于 DRAM 池的缓存，与大规模 LLM 服务的需求紧密契合。这些协同作用为后续章节提出的优化推理架构奠定了坚实的基础。
4. 在华为 CloudMatrix384 上服务 DeepSeek
为了充分利用 CloudMatrix384 的能力，我们提出了 CloudMatrix-Infer，一个全面的 LLM 服务解决方案，为部署大规模 MoE 模型确立了最佳实践。我们使用 DeepSeek-R1 模型作为代表性示例来说明我们推荐的架构和技术，这些技术利用跨层优化在 CloudMatrix384 上实现高效的 LLM 服务。图 8 提供了跨 AI 软件栈多层提出的优化技术的概述。
在本节中，我们首先介绍一种基于预填充-解码-缓存（PDC）解耦的新颖点对点服务架构，它将预填充、解码和缓存职责解耦，并将它们映射到通过高性能 UB 互连连接的专用 NPU 和 CPU 组（§4.1）。然后，我们介绍我们的紧密耦合解码优化，它在数百个 NPU 芯片上扩展大规模专家并行（LEP）以加速 MoE 推理（§4.2）。接下来，我们描述资源高效预填充策略，它应用混合并行和流水线来提高计算效率（§4.3）。我们进一步阐述UB 驱动的分布式缓存机制，它统一了跨节点的内存访问，实现了模型和历史 KV 缓存的低延迟访问（§4.4）。最后，我们详细介绍了系统对INT8 量化的支持，这进一步提升了端到端推理效率（§4.5）。
4.1 概述：具有 PDC 解耦的点对点服务架构
CloudMatrix-Infer 的架构设计遵循解耦和点对点通信的原则，将 LLM 推理工作流分解为可独立扩展的组件，同时利用 CloudMatrix384 的高带宽互连进行高效协调。基于这些原则，我们提出了一种独特的点对点服务架构，将系统分为三个功能子系统，即预填充（prefill）、解码（decode）和缓存（caching）（PDC），每个子系统独立运行并通过显式的 KV 缓存传输接口进行通信，如图 9 所示。这种点对点设计使每个子系统能够基于工作负载需求弹性扩展，最大化资源利用率和端到端性能。这些子系统通过 CloudMatrix384 的高带宽网络互连，形成一个紧密集成的推理流水线：
*预填充集群（Prefill Cluster）： 一组专用于处理输入提示（prompt）的 NPU，包含用户查询或上下文中的所有令牌，以生成第一个输出令牌并构建初始 KV 缓存。
*解码集群（Decode Cluster）： 一个独立的 NPU 组，负责通过消耗和更新 KV 缓存来自回归地生成后续令牌，直到发出序列结束令牌或达到输出长度限制。
*缓存集群（Caching Cluster）： 一个构建在解耦内存池上的 UB 连接缓存层，提供 (i) 上下文缓存（context caching） 以通过 KV 缓存重用来加速预填充，以及 (ii) 模型缓存（model caching） 以加速模型块加载并减少冷启动延迟。
为了更好地理解我们提出的设计的动机和有效性，将其与主导现有 LLM 服务系统的以 KV 缓存为中心（KVCache-centric）架构 [41, 48] 进行对比是有益的。
以 KV 缓存为中心 vs. 点对点服务架构： 现有的 LLM 服务系统，如 NVIDIA Dynamo [41] 和 Mooncake [48]，遵循以 KV 缓存为中心的设计，其中请求调度与 KV 缓存局部性紧密耦合。在这些系统中，请求通常被路由到已经持有先前交互相应 KV 缓存的特定计算节点。这种缓存感知调度对于减轻远程内存访问的显著性能损失至关重要，因为节点内内存访问（例如通过 PCIe，约 ~256 GB/s）远快于节点间带宽（通常约 ~25 GB/s 或 200 Gbps）。因此，远程 KV 缓存加载通常会带来相当大的延迟。然而，这种设计引入了不小的调度复杂性，并存在负载平衡恶化的风险，尤其是在动态工作负载下。此外，这种设计限制了全局资源效率，因为解码节点上的 DRAM 通常是孤立的且未充分利用，无法为共享缓存容量做出有意义的贡献。
我们在 CloudMatrix-Infer 中的点对点服务架构充分利用了 CloudMatrix384 的超高带宽 UB 互连。这使得能够统一访问建立在解耦内存池上的分布式缓存集群（第 4.4 节）。至关重要的是，所有 NPU，无论它们是服务于预填充还是解码任务，都可以直接访问这个共享的解耦内存池，该池跨越预填充和解码节点。这种完全点对点的设计有效地扁平化了内存层次结构，弥合了传统本地和远程访问延迟之间的差距。
将请求调度与 KV 缓存放置解耦提供了几个关键优势。首先，它支持轻量级、无状态调度，允许推理请求被分派到任何可用的 NPU 实例，而不受数据局部性的约束。这显著改善了系统范围的负载平衡和 NPU 利用率。其次，它消除了对复杂的、亲和性感知调度机制的需求，从而降低了架构复杂性并简化了系统维护。第三，通过跨预填充和解码节点池化 DRAM 资源，系统形成了一个统一的、弹性的缓存基础，增强了内存利用率，提高了缓存命中率，并在倾斜或突发工作负载下提供了更强的弹性。
预填充和解码部署。 与先前工作 [41, 47, 48, 57] 一致，CloudMatrix-Infer 采用了将预填充和解码阶段解耦到不同 NPU 组的策略。通过解耦这两个阶段（每个阶段具有不同的性能瓶颈），CloudMatrix-Infer 能够针对动态工作负载特征实现特定阶段的硬件分配、并行执行和独立可扩展性。
每个预填充实例在 CloudMatrix384 上配置了 16 个昇腾 910C NPU（32 个芯片），并以 32 路专家并行（EP32）运行。专家配置包括每个等级（rank）10 个专家：一个共享专家，八个路由专家，以及一个用于支持专家并行负载平衡（EPLB）的冗余路由专家。为了进一步提高效率，我们采用混合并行策略进行 MLA 计算，并应用基于微批次的流水线来重叠通信开销（§4.3）。
每个解码实例分配了显著更大的 NPU 组，通常是 160 个昇腾 910C NPU（跨越 20 个计算节点，产生 320 个 NPU 芯片），以满足自回归生成的高吞吐量和低延迟需求。该设置对应于 MoE 层的 320 路专家并行（EP320）。每个等级托管一个专家，整体配置包括 32 个共享专家，256 个不同的路由专家，以及 32 个冗余路由专家以促进 EPLB。为了进一步加速解码，我们引入了优化的昇腾原生算子、流水线解码策略和多令牌预测支持，如 §4.2 所述。
针对异步现实工作负载的动态调整。 在现实的在线服务场景中，解耦的 PDC 服务架构能够根据传入工作负载的统计特征，动态、细粒度地调整预填充、解码和缓存节点的数量。例如，具有较长输入提示的请求增加了对预填充节点的相对需求，而生成较长输出的工作负载需要更多的解码能力。这些比例不是固定的，而是随时间调整以最大化效率并维持延迟 SLO。
此外，用户会话异步到达和离开，每个会话都有自己的开始时间、提示长度和生成持续时间。为了应对这种高度动态和不可预测的工作负载模式，CloudMatrix-Infer 的责任是通过批处理和调度机制强制执行伪同步执行。具体来说，它在令牌边界对齐请求，允许多个会话被协同调度并同时处理。这种批处理策略分摊了计算成本，提高了吞吐量，并确保了高资源利用率，即使在完全异步的请求到达模式下也是如此。
4.2 紧密耦合解码与大规模专家并行
本节概述了 CloudMatrix384 上紧密耦合的 UB 平面所支持的 CloudMatrix-Infer 解码阶段优化。最小化 MoE 模型的 TPOT 延迟需要细粒度的专家并行，每个专家放置在专用的 NPU 芯片上。在 DeepSeek-R1 模型中，部署了 256 个路由专家，使得大规模专家并行（LEP）成为核心需求。然而，实现 LEP 并非易事，因为令牌处理中存在顺序依赖关系，并且在协调数百个 NPU 芯片时会产生显著的通信开销。
为了应对这些挑战，我们引入了一套针对 CloudMatrix384 定制的硬件感知优化技术。首先，我们介绍利用 UB 平面实现低延迟、高吞吐量 MoE 执行的融合通信算子设计（§4.2.1）。接下来，我们详细介绍为昇腾 910C 定制的 MLA 实现（§4.2.2），并描述了一种基于微批次的解码流水线，该流水线重叠两个执行流以隐藏延迟（§4.2.3）。最后，我们解释了 CloudMatrix-Infer 如何支持多令牌预测（MTP），这是 DeepSeek-R1 利用来提高解码吞吐量的功能（§4.2.4）。
4.2.1. LEP 的融合通信算子
图 10a 展示了一个基本的 MoE 计算流程。在门控机制为每个令牌选择 Top-K（在 DeepSeek R1 中 K=8）激活专家后，前馈网络（FFN）阶段之前需要两个全对全（all-to-all）通信步骤。第一个全对全操作在所有 NPU 之间交换路由元数据，例如令牌到专家的分配。第二个全对全操作交换实际的令牌数据，通常是每个令牌一个 7,168 维的隐藏状态向量。该数据最初以 BF16 格式存储，在每个 NPU 上被量化为 INT8 以减少通信和计算成本，然后由其分配的 FFN 处理。在 FFN 计算之后，第三次全对全通信将专家输出发送回其源等级（rank），
每个 NPU 在此执行最终的令牌组合步骤以重建输出。然而，这种基本的 MoE 实现存在几个低效问题：
(1) 通信开销： 三个全对全通信引入了显著的延迟，在大的通信域（数百个 NPU）下加剧。
(2) 动态形状： 全对全通信的数据形状是动态的，因为分配给每个专家的令牌数量在每个解码迭代中都会变化。这种动态性由于需要动态内存分配和频繁的 CPU-NPU 同步而降低了执行效率。
(3) 顺序依赖： MoE 计算的顺序执行性质在步骤之间创建了依赖关系，降低了资源利用率和吞吐量。
为了解决这些低效问题，我们开发了 FusedDispatch 和 FusedCombine 两个融合算子，它们集成了通信和计算，专门设计用于在 CloudMatrix384 上实现最佳解码性能。首先，为了减少全对全通信的开销，这两个融合算子将所有全对全通信替换为发送-接收（send-receive）原语。我们进一步利用 UB 平面中 NPU 之间的直接写入来减少通信延迟，并将分发阶段的量化操作移到 NPU 到 NPU 通信之前以减少消息大小。其次，为了消除与动态形状相关的开销，我们为算子预分配所有必要的内存空间，从而实现静态图执行。第三，为了减少顺序执行的开销，算子内的通信和计算步骤也被组织成流水线，提高资源利用率和吞吐量。这些优化详述如下。
跨 NPU 的 AIV 直接通信： 传统的 NPU 间全对全通信通常依赖于通信固件，如系统直接内存访问（SDMA）引擎来传输数据（图 11 中的红线）。然而，SDMA 引入了相当大的启动开销，这在超低延迟场景下成为关键性能瓶颈，
特别是在解码期间。为了克服这个瓶颈，我们设计了一种新的通信机制，我们称之为 AIV-Direct。AIV-Direct 使 AI 向量（AIV）核心能够通过 UB 互连直接写入远程 NPU 的内存，完全绕过易延迟的 SDMA 路径（图 11 中的蓝线）。通过消除 SDMA 的启动开销，AIV-Direct 为点对点通信提供了一条快速且轻量级的途径。这显著减少了传输启动延迟并加速了 NPU 间的数据交换，显著提高了延迟敏感操作（如解码）的性能。
早期量化： 在原始的 MoE 计算流中，如图 10a 所示，在令牌分发期间传输 BF16 令牌数据，导致高通信量。为了缓解这个问题，我们在 FusedDispatch 内部发送令牌数据之前执行 INT8 量化，引入了早期量化。具体来说，我们不是发送 BF16 数据，而是传输 INT8 量化的数据及其缩放因子。这减少了数据交换阶段的通信负载。给定一个具有 7,168 维度的令牌数据，INT8 表示每个令牌需要 7 KB。缩放因子占用 4 字节（INT32），但为了对齐，我们分配 512 B。因此，每个令牌的传输消息大小为 7.5 KB。这种优化显著减少了最带宽密集型阶段的通信开销。
通过共享内存预分配实现静态执行： 为了避免动态内存分配及其相关的 CPU-NPU 同步开销，我们在每个 NPU 等级（rank）中为从 MoE 层中所有其他等级到达的数据静态预分配共享内存缓冲区。所需的缓冲区大小为：
buffer_size=rank_num×max_tokens×msg_size,
其中
max_tokens=local_batch×min(topK, experts_per_die)
max_tokens 是一个 NPU 可能发送给单个对等体的最坏情况令牌数量，msg_size 是每个令牌的消息长度（令牌分发的 INT8 量化后为 7.5 KB，令牌组合为 14 KB）。
通过预先分配此空间，FusedDispatch 和 FusedCombine 都通过 AIV-direct 通信直接将数据写入目标 NPU 内存缓冲区，避免了中间本地拷贝和随后的远程读取，从而减少了内存流量和同步延迟。
因为 FusedDispatch 和 FusedCombine 背靠背执行，共享单个缓冲区会产生竞争：更快的 NPU 可能启动 FusedCombine 并在对等体完成消费先前的 FusedDispatch 有效负载之前覆盖其缓冲区，导致数据损坏。我们通过双缓冲（double buffering）消除此危险：为 FusedDispatch 和 FusedCombine 保留不同的缓冲区，确保当一个缓冲区被读取时，另一个缓冲区始终可供写入器使用。
预分配的内存开销是适度的。在我们的实验设置中，每个芯片最多处理 96 个令牌的本地批次，并托管最多两个专家，产生 max_tokens = 96×min(8,1)=9696×min(8,1)=96。在 320 个等级的通信域中，分发缓冲区占用 320×96×7.5 KB≈225 MB，组合缓冲区 320×96×14 KB ≈420 MB。两个缓冲区一起每个芯片仅消耗约 645 MB 内存。
数据发送流水线： 远程数据写入需要计算对等 NPU 预分配内存缓冲区中的目标偏移量。然而，顺序执行此计算和传输会停滞执行。为了避免这种情况，我们在每个融合算子内部设计了一个数据发送流水线，如图 12 所示，它将以下三个阶段流水线化：(1) 将下一个令牌复制到本地 UBuffer；(2) 计算远程缓冲区偏移量，如果启用则应用 INT8 量化；(3) 发出对等 NPU 内存的 AIV-Direct 写入。令牌作为单令牌微批次流经此流水线。当一个微批次的阶段 3 在传输数据时，后续微批次的阶段 1 和阶段 2 并行执行。这种重叠隐藏了计算和通信延迟，实现了连续高效的令牌分发。
通过结合这些技术，包括 AIV-direct 通信、早期量化、预分配的双缓冲内存和数据发送流水线，与基本实现相比，FusedDispatch 和 FusedCombine 算子显著降低了 MoE 层在解码期间的延迟。两个融合算子的工作流如图 10b 所示。
FusedDispatch 算子分三个主要步骤进行。第一步是流水线化的令牌发送阶段（优化点 [baseline=(char.base)] [shape=circle,draw,inner sep=0pt] (char) 4; ）。每个等级遍历分配给远程专家的令牌。对于每个令牌，分发 AIV 核心首先将相关令牌数据从内存加载到本地 UBuffer，然后将令牌数据量化为 INT8 格式（优化点 [baseline=(char.base)] [shape=circle,draw,inner sep=0pt] (char) 2; ），同时附加关联的缩放因子。路由元数据，包括源等级 ID、批处理槽 ID 和键偏移量，附加到每个令牌数据。系统然后确定每个专家 ID 的目标等级，并通过 AIV-direct（优化点 [baseline=(char.base)] [shape=circle,draw,inner sep=0pt] (char) 1; 和 [baseline=(char.base)] [shape=circle,draw,inner sep=0pt] (char) 3; ）将数据包写入对等体的预分配共享内存缓冲区。在第二步中，一旦所有数据包发出后，一个屏障确保在发送标志之前完成所有令牌数据写入。分发核心并行计算每个专家的令牌计数，跨核心同步，然后使用 AIV-direct（优化点 1) 和 3)）向相应的对等体发出完成标志和令牌计数。最后一步涉及协调和输出组装。每个等级轮询远程等级写入的标志，并等待所有标志设置为 '1'。然后它读取关联的令牌计数以计算输出偏移量。最后，所有分发核心并行工作，将接收到的令牌数据、量化比例和每个专家的令牌计数从共享内存组装到连续的输出缓冲区中，为后续的 FFN 计算阶段做好准备。
FusedCombine 工作流类似地包括三个主要步骤。第一步是流水线化的数据发送阶段（优化点 4），其中每个组合 AIV 核心循环遍历其分配的对等等级。核心读取每个对等体的相应接收计数，并将关联的 FFN 结果数据复制到本地 UBuffer。它使用令牌的源元数据——特别是源等级 ID、批处理槽 ID 和键偏移量——来计算对等体上的目标地址。然后通过 AIV-direct 将令牌数据传输回源等级上的预分配缓冲区（优化点 1) 和 3)）。在第二步中，每个令牌的元数据再次用于计算其标志更新的目标地址。组合 AIV 核心发出一个通过 AIV-direct 的原子加（atomic-add）操作，以增加对等体端的相应标志，表示一个贡献已送达（优化点 1) 和 3)）。在最后一步中，每个核心等待其分配批次的标志全部设置为 '1'，表示该令牌的所有专家输出都已接收。然后组合核心从共享内存收集专家 FFN 输出，从内存中检索相应的缩放因子，执行逐元素缩放，并对结果求和。然后将组合的专家输出添加到共享 FFN 输出中，以产生每个令牌的最终结果。
4.2.2. MLA 优化
DeepSeek 引入的多头潜在注意力（MLA）利用低秩压缩来减少 KV 缓存的空间占用，并结合权重吸收技术来降低计算成本。虽然 MLA 可以部署在 CloudMatrix384 上，但将 DeepSeek 的算子直接迁移到昇腾 910C NPU 暴露了几个性能瓶颈：
(1) 细粒度算子的启动开销： MLA 引入了许多细粒度操作，例如 RMSNorm、线性投影和 RoPE 编码，这些操作通常作为单独的 NPU 算子实现。每个算子调用会产生不可忽略的启动延迟，源于 CPU 端分发、参数加载、指令调度和分片（tiling）配置。尽管将这些算子捕获到图中可以通过分组多个操作来分摊 CPU 分发开销，但它并不能消除 NPU 上每个算子的启动成本。结果，这些小内核启动的累积在 MLA 执行路径中引入了显著的延迟。
(2) KV 缓存格式转换开销： 为了支持高性能矩阵计算，昇腾 910C NPU 的 AI 立方体核心（AIC）的 L1 缓存以 NZ 格式（一种特殊的混合行主序和列主序布局，导致组合的 N 形和 Z 形遍历路径）最优地存储数据。然而，KV 缓存通常使用标准 N 维（ND）格式存储在 NPU 的内存中。因此，算子内部通常需要将 KV 缓存数据显式转换为 NZ 格式，然后 AIC 才能执行矩阵计算。这种显式格式转换消耗内存带宽并影响访问效率，从而降低了可用于计算的有效内存带宽。
(3) 多令牌预测（MTP）下的负载不平衡： 当启用 MTP 时，解码阶段必须验证在先前步骤中预测的多个令牌。这导致同一批次内不同查询的有效序列长度不同（详见 §4.2.4）。原始用于注意力算子的分片策略，通常假设 BNSD（批次、头数、序列长度、头维度）内存布局，可能导致显著的负载不平衡。具体来说，没有 MTP 时，解码步骤中的所有查询通常序列长度为 1，允许基于 BB 和 NN 轴的分片策略创建大小相等的计算任务（因为 SS 和 DD 每个任务恒定），从而确保负载平衡。启用 MTP 后，序列长度 SS 可能因查询而异。在这些条件下坚持 BB 轴和 NN 轴分片会导致 NPU 核心之间的巨大负载差异，延长整体 MLA 计算时间。
为了克服这些限制并充分利用昇腾 NPU 的能力，我们提出以下 NPU 友好的优化：
融合算子：MLAProlog 和 Fused Attention (FA)。为了大幅减少 MLA 计算路径中众多小算子的启动开销，我们采用了积极的算子融合，如图 13 概念性所示。
首先，多个注意力前操作，包括 RMSNorm、Q/K/V 投影和 RoPE，被整合到单个复合算子中，称为 MLAProlog。这种融合将许多单个算子的启动成本减少到仅一个。此外，MLAProlog 设计有内部微并行性，将其工作负载划分为多个子任务，在 AIC 和 AIV 单元之间以流水线方式执行。这种细粒度的 AIC-AIV 并行性允许这些异构核心上不同子任务的计算时间有效地相互掩盖，进一步最小化融合算子的执行时间。
其次，为了补充 MLAProlog，我们开发了一个融合注意力（FA）算子，它将 FlashAttention 与相邻的数据整形操作（例如用于准备 Q、K、V 的注意力前 Concat 和用于提取相关输出的注意力后 Slice）集成在一起。这进一步减少了内核启动次数，并改善了整个注意力计算路径中的数据局部性。
NZ 格式的 KV 缓存。 为了消除张量格式转换开销，我们在 NPU 内存中本地以 NZ 格式存储 KV 缓存。在 MLA 计算期间，计算出的 KV 张量直接以这种 NZ 格式附加到 KV 缓存。在解码阶段，随着新的 KV 张量逐个令牌生成，它们可以根据 NZ 格式规则高效地写入 NPU 内存。昇腾 NPU 提供了能够在内存写入期间动态进行格式转换的数据移动接口。这种带格式转换的写入（write-with-format-conversion）能力避免了 KV 缓存显式的、单独的 ND 到 NZ 数据转换步骤，从而提高了 NPU 内存带宽的有效利用率。
具有 BSND 布局的 MTP 感知分片。 为了在 MTP 下恢复负载平衡，我们从 BNSD 切换到 BSND 内存布局，并沿批次（BB）和序列（SS）轴采用动态分片策略，这些轴在查询之间变化。由于 NN（头数）和 DD（头维度）值在这些操作期间保持相对稳定，这确保了 AIC 核心之间任务大小更好的均匀性，减少了由落后计算任务引起的尾延迟。
总之，这三种策略，包括算子融合、原生 NZ 存储和自适应分片，最大化了在 CloudMatrix384 上基于 MLA 推理的性能，为 DeepSeek 模型带来了显著的延迟和吞吐量收益。
4.2.3 基于微批次的解码流水线
虽然融合通信算子（§4.2.1）有助于减轻一些开销，但与专家并行通信相关的延迟仍然是解码阶段的一个重要因素。为了进一步提高效率，受 DeepSeek 的微批次流水线策略 [56] 启发，我们为 CloudMatrix384 设计了一个定制的基于微批次的解码流水线，通过跨两个流的细粒度延迟重叠来最大化资源利用率并减少执行延迟。
我们提出的资源分区和流水线策略与 DeepSeek 的方法不同，这是由于昇腾 NPU 的独特特性以及我们为 MoE 模型部署的特定并行性。与 DeepSeek 在 NVIDIA H800 上的部署（每个 GPU 共置三个专家：一个共享专家和两个路由专家）不同，如图 14a 所示，我们在 CloudMatrix384 上的部署涉及部署大规模专家并行度（EP320），通常每个 NPU 芯片一个专家，以实现低解码延迟。没有共享专家计算，仅 ATTN-0 的计算延迟不足以完全掩盖 MoE 分发延迟。这需要一种不同的负载平衡流水线策略。
为了在这些条件下实现高效的延迟重叠，我们为 CloudMatrix384 实现了一个具有非对称 AIC 和 AIV 分区的基于微批次的流水线，如图 14b 所示。该流水线包含两个交错的执行流，每个流负责解码过程的不同部分，并配置不同的计算能力：
*流 0（注意力路径）： 执行 MLAProlog、FusedAttention 和 Q_PROJ。这些是计算密集型或内存密集型算子，因此分配了更多的 NPU 资源——16 个 AIC 和 32 个 AIV。在典型的解码条件下（4K 序列，批次大小 96，启用 MTP），该流每个微批次的延迟为 600 μs。
*流 1（MoE 路径）： 处理 MoE 序列：Gate、Dispatch、MLP 和 Combine。由于包含计算和通信阶段，该流被赋予 8 个 AIC 和 16 个 AIV，是流 0 资源的一半，但由于计算负载较低但通信延迟较高，实现了相当的延迟（600 μs）。
非对称分配确保了在执行流 0 和流 1 时每层延迟接近，从而实现两个交错微批次的完美重叠。如图 (b)b 中交替颜色所示，流 0 处理一个微批次的注意力计算，而流 1 同时为另一个微批次执行 MoE 计算和通信。
为了适应变化的运行时条件，例如可变的 KV 缓存长度，可以自适应地调整分配给两个流的计算资源。这种弹性确保延迟平衡得以保持，能够在多样化的工作负载下维持性能。
4.2.4 多令牌预测支持
多令牌预测（MTP）是 DeepSeek-R1 中使用的一种推测性解码技术，其中在每个解码步骤预测 k个令牌。这些预测在后续步骤中被验证。通过每个解码生成多个令牌，MTP 可以显著提高吞吐量。然而，在现有推理框架中启用 MTP 通常会导致效率低下，原因是紧密的 CPU-NPU 同步，导致流水线中断和性能下降。我们称之为流水线中断问题。
如图 (15)b（原生 MTP 流水线）所示，MTP 通常在每个解码步骤触发 k+1个计算图，k 个用于推测模块，一个用于最终验证。每个图分发引入约 0.6−0.8ms 的启动延迟。这种开销，尤其是在 CPU 调度的编排下，会导致 NPU 上的空闲气泡，削弱了 MTP 的好处。我们确定了这些障碍的两个主要来源：
*用于动态元数据初始化的 CPU 干预： MTP 模块和主 LLM 都依赖于元数据，例如当前序列长度，这在解码期间动态变化。此元数据只能在前一个模块执行完成后才能最终确定。例如，一个 MTP 模块需要在前一个 LLM 验证后确定的序列长度。如图 15b 所示，CPU 在分发每个图之前初始化和传输此元数据，导致频繁的 CPU-NPU 同步屏障。
*CPU 干预的采样中断 NPU 执行： 在 MTP 模块和主 LLM 生成令牌分布后，需要采样来选择实际的令牌。此过程涉及 CPU 过程和离散 NPU 操作的混合。这些频繁的 CPU-NPU 交互导致主机和设备之间数据拷贝的开销。至关重要的是，因为每个后续计算图都依赖于前一个图的采样输出，这引入了串行化，阻止了连续的 NPU 执行。
为了克服这些瓶颈，我们引入了一种流水线化的 MTP 执行技术（图 15c），消除了这些 CPU 依赖并实现了高效的图执行：
聚合元数据初始化。 不是为 k+1 个图中的每一个单独执行元数据设置，我们在解码步骤开始时预计算并批处理所有元数据张量。这些存储在 NPU 内存中的张量包括每个 MTP 模块的增量序列长度和用于验证图的元数据块。这消除了重复的 CPU 参与，并在 NPU 上实现了无缝的、元数据感知的执行。
无 CPU 的 NPU 内采样。 为了消除由基于 CPU 的采样经常引起的 NPU 执行停滞，我们将整个采样过程迁移到 NPU。此策略涉及将必要的采样操作（如令牌概率排序、累积和计算和候选过滤）实现为一系列 NPU 算子。此外，为了最小化因分发众多 NPU 采样算子可能产生的启动开销，这些算子被融合到 MTP 和 LLM 验证图中。通过将采样完全保留在设备上，我们防止了 MTP 阶段和 LLM 验证阶段之间的执行停滞，允许计算图在没有主机干预的情况下背靠背执行。
总之，这些增强功能消除了原生 MTP 实现中因 CPU-NPU 协调而导致的频繁流水线中断。当 NPU 执行一个计算图时，CPU 同时调度下一个图，实现了持续的并行性和连续的 NPU 执行。这在 NPU 上实现了操作的无缝流动，最大化其利用率并充分发挥了 MTP 的潜在延迟优势。
