作者/机构: Pengfei Zuo, Huimin Lin, Junbo Deng, Nan Zou, Xingkun Yang, Yingyu Diao, Weifeng Gao, Ke Xu, Zhangyu Chen, Shirui Lu, Zhao Qiu, Peiyang Li, Xianyu Chang, Zhengzhong Yu, Fangzheng Miao, Jia Zheng, Ying Li, Yuan Feng, Bei Wang, Zaijian Zong, Mosong Zhou, Wenli Zhou, Houjiang Chen*, Xingyu Liao*, Yipeng Li*, Wenxiao Zhang*, Ping Zhu*, Yinggang Wang*, Chuanjie Xiao*, Depeng Liang*, Dong Cao*, Juncheng Liu*, Yongqiang Yang, Xiaolong Bai, Yi Li, Huaguo Xie, Huatao Wu, Zhibin Yu, Lv Chen, Hu Liu, Yujun Ding, Haipei Zhu, Jing Xia, Yi Xiong, Zhou YuB, Heng LiaoB
(Huawei *SiliconFlow)

A1 主要贡献

本文针对大型语言模型（LLM）因参数规模增长、专家混合（MoE）架构采用和上下文长度扩展而对AI基础设施带来的前所未有的挑战，介绍了华为CloudMatrix，一个旨在重塑AI基础设施基础的下一代AI数据中心架构。

核心问题与研究目标:
LLM的快速发展，如DeepSeek-R1、LLaMA-4和Qwen-3，参数量已达数千亿甚至万亿级别，加上MoE架构和百万级令牌的上下文窗口，对计算能力、内存容量与带宽、芯片间通信以及延迟提出了严苛要求，使传统AI集群达到可扩展性极限。在生产环境中，系统还需处理可变长度输入、不均衡的专家激活和突发性用户查询等动态异构工作负载，同时满足严格的服务等级目标（SLO）。这些挑战要求对软硬件堆栈进行根本性的重新架构和协同设计。

主要创新与贡献:
为应对上述挑战，本文介绍了华为CloudMatrix架构及其首个生产级实现CloudMatrix384，并提出了一个全面的LLM服务解决方案CloudMatrix-Infer。
1. 华为CloudMatrix384架构：这是一个为大规模AI工作负载设计的AI超级节点。它集成了384个昇腾910 NPU和192个鲲鹏CPU，通过名为统一总线（UB）的超高带宽、低延迟网络实现全对全互连。与传统分层设计不同，该架构允许计算、内存和网络资源被动态池化、统一访问和独立扩展，特别有利于MoE专家并行和分布式KV缓存访问等通信密集型操作。
2. CloudMatrix-Infer服务解决方案：该方案为在CloudMatrix384上部署大规模MoE模型（如DeepSeek-R1）提供了最佳实践，包含三大核心创新：
* 点对点服务架构：将LLM推理系统分解为预填充（prefill）、解码（decode）和缓存（caching）三个独立可扩展的资源池。与传统的以KV缓存为中心的架构不同，它利用UB网络实现对解耦内存池中缓存数据的高带宽、统一访问，从而降低了数据局部性约束，简化了任务调度，并提高了缓存效率。
* 大规模专家并行（LEP）策略：利用UB网络实现高效的令牌分发和专家输出合并，支持极高的专家并行度（如EP320），使每个NPU die能承载一个专家，从而最小化专家间的串行执行，降低解码延迟。
* 硬件感知优化套件：专为CloudMatrix384定制的一系列优化，包括高度优化的昇腾算子、基于微批处理的流水线以及INT8量化，以提升执行效率和资源利用率。

核心成果:
在CloudMatrix384上使用6710亿参数的DeepSeek-R1模型进行的评估显示，CloudMatrix-Infer在不牺牲准确性的前提下实现了业界领先的效率。
* 预填充（Prefill）阶段：每个NPU的吞吐量达到6,688 tokens/s，计算效率为4.45 tokens/s/TFLOPS。
* 解码（Decode）阶段：在TPOT（每个输出令牌的时间）低于50毫秒的约束下，每个NPU的吞吐量为1,943 tokens/s，计算效率为1.29 tokens/s/TFLOPS。这两项效率指标均超过了已发布的SGLang在NVIDIA H100上和DeepSeek在NVIDIA H800上的结果。
* 吞吐量与延迟权衡：在更严格的TPOT低于15毫秒的约束下，系统仍能维持每个NPU 538 tokens/s的解码吞吐量。
* INT8量化准确性：在16个基准测试中，昇腾910上的INT8量化保持了与官方DeepSeek-R1 API相当的模型准确性。

这些结果证明了CloudMatrix384与CloudMatrix-Infer相结合，构成了一个可扩展、高吞吐量的生产级大规模LLM部署平台。

A3 背景知识与设计原则

2 LLM趋势及其对数据中心基础设施的挑战

2.1 LLM趋势

不断增长的参数数量。实证的扩展法则表明，增加LLM中的参数数量可以提高模型在各种任务上的性能【33，Scaling Laws for Neural Language Models, 2020】。近期的发展体现了这一趋势：Meta的Llama 4 Behemoth拥有近2万亿参数，而其对应版本Llama 4 Maverick则包含4000亿参数【39，Llama 4: Multimodal Intelligence at Scale, 2025】。DeepSeek-AI开发的DeepSeek-V3包含6710亿参数【15，DeepSeek-V3 Technical Report, 2024】。谷歌的PaLM模型包含5400亿参数【8，PaLM: Scaling Language Modeling with Pathways, 2023】，xAI的Grok-1拥有3140亿参数【54，Grok-1: 314B Parameter Mixture-of-Experts Model, 2024】。这些模型凸显了业界为增强推理、多语言理解和代码生成能力而持续扩展LLM规模的追求。

通过MoE实现稀疏性。为了管理不断升级的训练和推理成本，现代LLM越来越多地采用稀疏激活的专家混合（MoE）架构，这将模型的总容量与每个令牌的计算需求解耦。著名的实现包括Mixtral 8×7B，总参数为467亿，但每个令牌只激活129亿，通过将每个令牌路由到每层8个专家中的2个，实现了与GPT-3.5相当的性能，同时保持了计算效率【32，Mixtral of Experts, 2024】。Databricks的DBRX采用细粒度MoE架构，总参数为1320亿，每个令牌激活360亿，通过从16个较小的专家中选择4个，提高了吞吐量并降低了延迟【19，Introducing DBRX: A New State-of-the-Art Open LLM, 2024】。Meta的Llama 4系列在开源模型中引入了MoE，其中Llama 4 Maverick使用128个专家，Llama 4 Scout使用16个专家，两者都保持每个令牌170亿的激活参数【39，Llama 4: Multimodal Intelligence at Scale, 2025】。DeepSeek-V3在其前身的基础上，将每层路由的专家数量从160个增加到256个，从而在不按比例增加计算负载的情况下增强了模型容量【14，DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model, 2024; 15，DeepSeek-V3 Technical Report, 2024】。阿里巴巴的Qwen3-235B模型包含128个专家，每个令牌激活220亿参数，平衡了大规模容量与计算效率【49，Qwen3: Think Deeper, Act Faster, 2025】。华为的盘古Ultra MoE模型扩展到7180亿参数，每个令牌激活390亿参数，其MoE架构每层有256个专家，每个令牌激活其中的8个【52，Pangu Ultra MoE: How to Train Your Big MoE on Ascend NPUs, 2025】。这些模型共同凸显了LLM扩展策略的范式转变，强调架构稀疏性而非纯粹的参数数量来实现增强的性能和效率。

上下文窗口的扩展。LLM中上下文窗口的扩展使得能够处理更长的序列，这对于需要扩展推理和连贯性的任务至关重要。近期的进展反映了这一转变：OpenAI的GPT-4.5支持128,000个令牌的上下文窗口【45，Introducing GPT-4.5, 2025】，而谷歌的Gemini 2.5 Pro提供高达100万个令牌的上下文窗口【21，Gemini 2.5: Our Most Intelligent AI Model, 2025】。像LongBench【6，LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding, 2024】这样的基准测试量化了扩展上下文窗口在问答、摘要和多步推理等任务中的好处。然而，用长提示词喂给LLM会显著增加计算成本并延长推理延迟。为了降低这些成本，生产系统采用上下文缓存，将早期提示片段生成的键值（KV）块存储起来，并在后续轮次或请求中重用。这种方法消除了对提示词的冗余注意力计算，从而减少了延迟并提高了效率【20，Cost-Efficient Large Language Model Serving for Multi-turn Conversations with CachedAttention, 2024; 48，Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot, 2025】。

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利用率不足。

图1. 华为的CloudMatrix架构愿景从根本上重新构想了AI数据中心基础设施。通过打破传统的孤岛式设计，它通过统一的超高性能网络实现了CPU、NPU、内存、NIC和其他资源的完全点对点解耦和池化，为可扩展的、AI原生数据中心奠定了基础。

3 华为CloudMatrix

为了应对AI工作负载中这些新兴的挑战，华为提出了CloudMatrix，这是一种旨在重塑AI基础设施基础的下一代AI数据中心架构。这一架构愿景的核心是构建一个统一、紧密耦合的计算结构，能够高效支持现代AI应用的规模、异构性和通信需求。CloudMatrix384是这一愿景的首次生产级实现，提供了一个为大规模AI工作负载专门优化的平台。

3.1 华为CloudMatrix的愿景

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网络在单个横向扩展基础设施内同时支持AI和数据密集型应用。这使得LLM推理、训练、模拟和分析工作负载的融合执行成为可能，这对于混合AI流水线来说是一个日益普遍的需求。
4. 通过解耦内存池实现内存级存储。CloudMatrix将集群中CPU附加的DRAM聚合成一个共享的高性能内存池，可通过UB访问。该基础为弹性内存服务（EMS）【26，Huawei Cloud Elastic Memory Service (EMS), 2025】等服务提供支持，通过消除传统的I/O瓶颈，加速了如KV缓存重用、参数加载和模型检查点等延迟关键操作。

CloudMatrix384是这一架构愿景的首次生产级实现，专门设计用于满足下一代AI工作负载在规模上的计算、内存和通信需求。

3.2 CloudMatrix384概览：一个完全点对点的硬件架构

超级节点设计。CloudMatrix384被设计为一个AI超级节点，集成了384个昇腾910神经网络处理单元（NPU）和192个鲲鹏中央处理单元（CPU），如图2所示。CloudMatrix384的一个决定性特征是其点对点、全互连、超高带宽的网络，通过UB协议连接所有NPU和CPU。CloudMatrix384的UB设计是【38，UB-Mesh: a Hierarchically Localized nD-FullMesh Datacenter Network Architecture, 2025】中提出的UB-Mesh的前身。384个NPU和192个CPU中的每一个都通过UB交换机连接，使得节点间通信性能非常接近节点内水平。节点间带宽下降不到3%，节点间延迟增加小于1微秒。鉴于现代AI工作负载主要是带宽密集型而非延迟敏感型，这种微小的延迟开销对AI任务的端到端性能影响可以忽略不计。总体而言，这种设计使CloudMatrix384能够作为一个紧密耦合的大规模逻辑节点运行，具有全局可寻址的计算和内存，便于统一的资源池化和高效的工作负载编排。

三平面网络。为了支持多样化的流量模式并与遗留数据中心网络保持兼容性，CloudMatrix384集成了三个不同但互补的网络平面：
1. UB平面。UB平面构成了超级节点内的主要超高带宽扩展（scale-up）结构。它以非阻塞的全对全拓扑直接互连所有384个NPU和192个CPU。UB能够：(1) 高效实现细粒度的并行策略，如TP和EP，不受节点边界的限制；(2) 快速点对点访问池化内存（跨越CPU和NPU内存），这对于高效缓存模型权重和KV缓存至关重要。
2. RDMA平面。RDMA平面支持跨CloudMatrix384超级节点和外部RDMA兼容系统的横向扩展（scale-out）通信。它目前采用RDMA over Converged Ethernet (RoCE)以确保与标准RDMA堆栈的兼容性。NPU是该平面唯一的参与者，将RDMA流量与控制和存储操作隔离开来。其主要功能包括：(1) 在推理期间，在预填充和解码NPU之间高速传输活动的KV缓存数据；(2) 使用符合RDMA的框架支持分布式训练和推理；(3) 在多集群部署中实现跨超级节点的低延迟互连。
3. VPC平面。虚拟私有云（VPC）平面通过高速NIC（华为的擎天卡）将CloudMatrix384超级节点连接到更广泛的数据中心网络。它在标准以太网和IP协议上运行，可选择性地增强UB-over-Ethernet (UBoE)。VPC平面处理：(1) 管理和控制平面操作，如部署、监控和调度；(2) 访问持久存储，包括对象存储服务（OBS）、弹性卷服务（EVS）和可扩展文件系统服务（SFS）；(3) 来自CPU驻留工作负载的外部服务通信，例如数据库和用户界面。

未来愿景。尽管CloudMatrix的长期愿景是如图1所示，将RDMA和VPC平面融合为一个统一的平面，但当前的CloudMatrix384将它们分开以确保与遗留数据中心基础设施的后向兼容性。我们将在§6.1.1中讨论未来统一VPC和RDMA平面的工作。

图2. CloudMatrix384超级节点的点对点硬件架构，具有用于超级节点内扩展的超高带宽统一总线（UB）平面、用于超级节点间通信的RDMA平面，以及用于与数据中心网络集成的虚拟私有云（VPC）平面。所有报告的网络带宽值表示单向带宽。

3.3 硬件组件

3.3.1 昇腾910芯片

核心架构。CloudMatrix 384的核心是海思昇腾910 NPU，这是华为2024年时代的旗舰AI加速器。昇腾910是一个双Die封装：两个相同的计算Die共同封装，共享八个片上内存堆栈，并通过高带宽的跨Die结构连接，如图3所示。每个Die包含24个AI立方核（AIC），用于优化矩阵和卷积工作负载，以及48个AI向量核（AIV），用于逐元素操作。所有计算引擎都支持FP16/BF16和INT8数据类型。8位量化可以用INT8精度实现，使得计算效率与原生FP8硬件相当，而无需专门的FP8支持。两个Die通过片上互连进行通信。每个昇腾910 Die都与两个不同的网络平面接口。1) UB平面：该Die集成了七个高速收发器连接到扩展的UB平面。2) RDMA平面：另外，每个Die都包含一个用于横向扩展RDMA平面的专用接口。

图3. 华为昇腾910芯片的逻辑概览，突出了其双Die架构。所有报告的网络带宽值表示单向带宽。

3.3.2 昇腾910节点

节点构成。CloudMatrix384中的每个计算节点集成了8个昇腾910 NPU、4个鲲鹏CPU和7个板载UB交换芯片，如图4所示。这12个处理器（8个NPU和4个CPU）通过UB链路连接到这些板载交换机，在节点内创建了一个单层UB平面。每个板载UB交换芯片都连接到超级节点结构中的下一级交换层。只有NPU参与次级的RDMA平面。

CPU复合体。在CPU复合体内部，四个鲲鹏CPU插槽通过全网状NUMA拓扑互连，实现了跨所有CPU附加DRAM的统一内存访问。其中一个CPU承载了节点的擎天卡，这是一个专用的数据处理单元（DPU），不仅集成了高速网络接口，还执行了关键的节点级资源管理功能。这张擎天卡作为节点主要的南北向出口点，与第三个不同的网络平面——数据中心的VPC平面——进行接口。

图4. CloudMatrix384内一个昇腾910节点的逻辑概览。所有报告的网络带宽值表示单向带宽。

3.3.3 UB交换系统

超级节点拓扑。CloudMatrix384超级节点横跨16个机架：12个计算机架，共容纳48个昇腾910节点（总共384个NPU），以及4个通信机架。这些通信机架容纳了第二层（L2）UB交换机，用于互连超级节点内的所有节点。

无阻塞设计。图5展示了板载第一层（L1）UB交换机（位于每个昇腾910节点内部）与机架级L2 UB交换机之间的拓扑结构。该网络被设计为无阻塞的，这意味着在L2交换层没有带宽超订。L2交换机被划分为7个独立的子平面。每个子平面包含16个L2 UB交换芯片，每个L2交换芯片提供48个端口。

连接配置。在每个节点内部，7个板载L1 UB交换芯片与这7个L2子平面一一对应。每个L1交换芯片通过16条链路（每条链路连接到其对应子平面中的每个L2交换芯片）扇出。这种配置确保了节点到L2结构的总上行带宽与其内部UB容量完全匹配，从而在整个超级节点上保持了无阻塞特性。

3.4 软件栈

3.4.1 昇腾NPU的CANN

CANN简介。华为为昇腾NPU开发了一个全面的软件生态系统，称为神经网络计算架构（CANN）【29，CANN: Compute Architecture for Neural Networks, 2025】。CANN作为一个中间件软件层，实现了高级AI框架（如PyTorch【46，PyTorch: An Imperative Style, High-Performance Deep Learning Library, 2019】和TensorFlow【2，TensorFlow: A System for Large-Scale Machine Learning, 2016】）与昇腾NPU底层硬件接口之间的高效集成。通过将这些框架生成的抽象计算图转换为优化的、硬件可执行的指令，CANN简化了开发者与昇腾硬件的交互，促进了软硬件协同设计，并旨在最大化昇腾架构上的应用性能。

图5. CloudMatrix384中的UB交换系统。所有报告的网络带宽值表示单向带宽。

CANN架构。CANN软件栈（图6）由三个主要层次组成：驱动层、运行时层和库层，其架构类似于NVIDIA的CUDA生态系统【40，CUDA Toolkit, 2024】。
1. 驱动层：位于底层，昇腾NPU驱动程序，包括内核模块和固件，作为操作系统和昇腾NPU之间的低级接口。它管理关键的硬件交互，包括设备初始化、资源分配（内存、流）、命令调度和NPU间通信设置。
2. 运行时层：CANN运行时是昇腾NPU上应用程序的核心执行引擎。它负责应用程序的生命周期管理，协调模型计算，并为模型和算子提供全面的设备控制、内存管理和执行管理。这些功能主要通过昇腾计算语言（ACL）API访问。
3. 库层：该层提供了一套高度优化的软件组件，以加速各种AI工作负载。关键元素包括领域特定的加速库（AOL）、用于分布式任务的华为集体通信库（HCCL）、包含预优化内核的广泛算子包（OPP），以及神经网络加速引擎（NNAE）和离线推理引擎（NNRT）。还支持自定义算子开发（例如，通过Ascend C）和与第三方库的集成，以进一步增强其能力。

图引擎(GE)。除了核心层之外，图引擎（GE）编译和优化来自PyTorch、TensorFlow和MindSpore【28，MindSpore: An Open Source Deep Learning Framework, 2020】等框架的计算图。它通过应用算子融合、内存规划、动态形状处理和调度等全图优化，连接了高级模型和低级执行。这些优化减少了开销，并提高了在昇腾NPU上的执行效率。

框架集成。CANN为流行的AI框架提供了广泛支持，显著降低了在新旧AI项目中采用昇腾NPU的门槛：
* PyTorch：通过PyTorch昇腾适配器（torch_npu）【4，Ascend Extension for PyTorch, 2025】，开发者可以在现有的PyTorch工作流中无缝利用昇腾NPU加速。华为通过预构建的Python wheel包提供简单的安装，提供关于API兼容性和最佳实践的全面文档，以及将基于CUDA的代码迁移到CANN的简化工具或指南。
* TensorFlow：CANN的TF_Adapter【5，TensorFlow Adapter For Ascend, 2025】将昇腾加速能力直接集成到TensorFlow框架中，使得基于TensorFlow的AI项目能够以最少的代码修改实现高性能和直接采用。
* ONNX：华为为ONNX运行时提供了一个专用的CANN执行提供者【43，CANN Execution Provider, 2025】。这使得能够高效执行以开放神经网络交换（ONNX）格式【42，ONNX: Open Neural Network Exchange, 2019】导出的模型，促进了广泛的模型兼容性，并简化了在包含昇腾NPU的异构硬件环境中的部署。
* MindSpore：由华为内部开发的MindSpore【28，MindSpore: An Open Source Deep Learning Framework, 2020】与昇腾硬件提供原生且高度优化的集成。该框架旨在在华为的AI生态系统内提供卓越的性能和易用性，提供了一个紧密耦合的软硬件解决方案。

总结。CANN提供了一个垂直集成的软件栈，包括驱动、运行时和库，与NVIDIA的CUDA相当，但为昇腾NPU量身定制。其GE将全图表示编译为高度优化的执行计划，丰富的框架适配器使得移植现有工作负载几乎无摩擦。这些组件共同使开发者能够以最少的代码更改利用昇腾硬件，同时在广泛的AI应用中实现接近峰值的设备性能。

图6. 华为昇腾NPU的CANN软件栈。

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, 2025】。它包括：ModelArts Lite，用于通过裸机和容器化环境直接访问昇腾硬件；ModelArts Standard，支持完整的AI开发和MLOps流水线；ModelArts Studio，提供模型即服务（MaaS）能力，用于快速部署和定制LLM及其他模型。

协同作用。这些组件共同使用户能够在CloudMatrix384上高效地构建和部署大规模AI应用，在保持性能的同时抽象了底层复杂性。

图7. 用于部署CloudMatrix384的云基础设施软件栈。

3.5 DeepSeek模型的适用性分析

3.5.1 DeepSeek模型及其在NVIDIA H800上的部署

DeepSeek模型架构。DeepSeek-AI凭借其DeepSeek-V3和R1模型成为LLM领域的重要参与者，这些模型共享一个为高效训练和推理而优化的通用架构【13，DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025; 15，DeepSeek-V3 Technical Report, 2024】。这些模型集成了多项系统级创新：一个671B参数的专家混合（MoE）架构，通过在256个路由器专家中进行top-8路由，每个令牌仅激活37B参数；多头潜在注意力（MLA），将KV缓存大小减少高达93.3%；多令牌预测（MTP），通过解码时验证实现多令牌生成；以及FP8量化，以在保持准确性的同时提升性能。DeepSeek的模型共同体现了以训练和推理效率为中心的设计理念。这些创新共同促使模型能够在降低计算和内存需求的情况下提供高质量的输出。

在H800上的部署。DeepSeek将其V3和R1模型部署在NVIDIA H800 GPU集群上，每个GPU配备80 GB内存，节点内通过NVLink连接，节点间通过400 Gbps InfiniBand连接【11，Day 6: DeepSeek-V3/R1 Inference System Overview (Open Source Week), 2025】。该部署采用了解耦的预填充-解码架构。在预填充阶段，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。all-to-all的UB拓扑确保了以最小的开销快速交付。同样，在组合阶段，多个专家的输出必须通过在分布式计算单元上进行加权求和来合并。UB平面的高带宽使得能够高效收集专家输出，优于传统架构，在传统架构中网络性能会严重阻碍MoE推理吞吐量。
内存容量和管理：容纳大型模型和KV缓存。DeepSeek-R1的参数数量接近671B，需要大量的内存资源来存放权重和激活值，包括注意力KV缓存。CloudMatrix384提供了巨大的NPU附加内存总量，通过张量、流水线和专家并行的组合，实现了模型权重的分布式存储。除了模型权重，LLM的注意力机制还维护着庞大的KV缓存，尤其是在长上下文或高批次工作负载下。CloudMatrix384的充裕内存足迹支持这些场景，但跨NPU高效地分区和同步KV缓存仍然至关重要。
上下文缓存重用：加速缓存访问。LLM工作负载，尤其是在多轮对话和长上下文应用中，从前缀缓存重用中获益匪浅，DeepSeek-AI报告的缓存命中率超过56%。在传统系统中，从片外DRAM甚至更慢的存储层检索历史KV缓存会引入显著的延迟，妨碍推理性能。CloudMatrix384通过使NPU能够通过高带宽的UB平面直接访问解耦的、CPU附加的DRAM池来缓解这一瓶颈（§4.4.1）。这种架构为远程KV缓存访问提供了内存级的带宽和延迟。因此，它最小化了冗余的预填充计算，显著降低了首个令牌生成时间（TTFT），并能高效扩展到长上下文工作负载，而不会耗尽有限的NPU内存。
量化以提高效率：INT8支持。昇腾910支持INT8计算（如§3.3.1所述），为优化DeepSeek模型的推理性能提供了宝贵的机会。将模型权重和激活值从较高精度格式（如FP16或BF16）量化为INT8，可以显著减少模型的内存占用，降低计算开销，并减轻执行期间的内存带宽需求。这些好处可以转化为更高的吞吐量和更低的延迟。

总结。CloudMatrix384的架构，包括其大规模NPU计算、广泛的内存容量、高带宽UB互连和基于DRAM池的缓存，与大规模LLM服务的需求紧密对齐。这些协同作用为后续章节中介绍的优化推理架构提供了坚实的基础。

A2 方法细节

图8. 我们提出的在AI软件栈不同层次的优化技术概览。

为了充分利用CloudMatrix384的能力，我们提出了CloudMatrix-Infer，一个全面的LLM服务解决方案，它为部署大规模MoE模型建立了最佳实践。我们以DeepSeek-R1模型为代表性例子，来说明我们推荐的架构和技术，这些技术利用跨层优化在CloudMatrix384上实现高效的LLM服务。图8概述了在AI软件栈多个层次上提出的优化技术。

4.1 概览：基于PDC解耦的点对点服务架构

设计原则。CloudMatrix-Infer的架构设计遵循解耦和点对点通信的原则，将LLM推理工作流分解为独立可扩展的组件，同时利用CloudMatrix384的高带宽互连进行高效协调。基于这些原则，我们提出了一个独特的点对点服务架构，将系统分为三个功能子系统，即预填充（prefill）、解码（decode）和缓存（caching）（PDC），每个子系统独立运行，并通过显式的KV缓存传输接口进行通信，如图9所示。这种点对点设计使得每个子系统可以根据工作负载需求弹性伸缩，从而最大化资源利用率和端到端性能。

三大子系统。这些子系统通过CloudMatrix384的高带宽网络互连，形成一个紧密集成的推理流水线：
* 预填充集群：一组专门用于处理输入提示的NPU，包含用户查询或上下文中的所有令牌，以生成第一个输出令牌并构建初始KV缓存。
* 解码集群：一个独立的NPU组，负责通过消费和更新KV缓存来自回归地生成后续令牌，直到发出序列结束令牌或达到输出长度限制。
* 缓存集群：一个通过UB连接的缓存层，建立在解耦内存池之上，提供(i)上下文缓存，通过KV缓存重用加速预填充，以及(ii)模型缓存，以加快模型块加载并减少冷启动延迟。

与KVCache中心架构的对比。为了更好地理解我们设计动机和有效性，有必要将其与现有的主导LLM服务系统的KVCache中心架构【41，NVIDIA Dynamo Open-Source Library Accelerates and Scales AI Reasoning Models, 2025; 48，Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot, 2025】进行对比。现有的LLM服务系统，如NVIDIA Dynamo和Mooncake，遵循KVCache中心设计，其中请求调度与KV缓存的局部性紧密耦合。在这些系统中，请求通常被路由到已经持有先前交互相应KV缓存的特定计算节点。这种缓存感知调度对于减轻远程内存访问的显著性能损失至关重要，因为节点内内存访问（例如，通过PCIe约256 GB/s）远超节点间带宽（通常约25 GB/s或200 Gbps）。然而，这种设计引入了不小的调度复杂性，并有降低负载均衡的风险，尤其是在动态工作负载下。此外，它限制了全局资源效率，因为解码节点上的DRAM通常是孤立且未被充分利用的。

点对点架构的优势。我们的CloudMatrix-Infer中的点对点服务架构充分利用了CloudMatrix384的超高带宽UB互连。这使得能够统一访问建立在解耦内存池上的分布式缓存集群（第4.4节）。至关重要的是，所有NPU，无论它们是服务于预填充还是解码任务，都可以直接访问这个跨越预填充和解码节点的共享解耦内存池。这种完全点对点的设计有效地扁平化了内存层次结构，弥合了本地和远程访问延迟之间的传统差距。将请求调度与KV缓存放置解耦带来了几个关键优势。首先，它实现了轻量级的无状态调度，允许推理请求被分派到任何可用的NPU实例，而不受数据局部性的限制，从而显著改善了系统范围的负载均衡和NPU利用率。其次，它消除了对复杂、亲和性感知的调度机制的需求，从而降低了架构复杂性并简化了系统维护。第三，通过在预填充和解码节点之间池化DRAM资源，系统形成了一个统一、弹性的缓存基础，增强了内存利用率，提高了缓存命中率，并在偏斜或突发工作负载下提供了更大的弹性。

预填充和解码部署。与先前的工作【41，NVIDIA Dynamo Open-Source Library Accelerates and Scales AI Reasoning Models, 2025; 47，Splitwise: Efficient Generative LLM Inference Using Phase Splitting, 2024; 48，Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot, 2025; 57，DistServe: Disaggregating Prefill and Decoding for Goodput-Optimized Large Language Model Serving, 2024】一致，CloudMatrix-Infer采用将预填充和解码阶段解耦到不同NPU组的策略。通过解耦这两个具有不同性能瓶颈的阶段，CloudMatrix-Infer能够针对不同阶段进行特定的硬件分配、并行执行和独立扩展，以响应动态工作负载特性。
* 每个预填充实例在CloudMatrix384上配置16个昇腾910 NPU（32个die），并以32路专家并行（EP32）运行。专家配置包括每个rank 10个专家：一个共享专家、八个路由器专家和一个用于支持专家并行负载均衡（EPLB）的冗余路由器专家。为进一步提高效率，我们对MLA计算采用混合并行策略，并应用基于微批处理的流水线来重叠通信开销（§4.3）。
* 每个解码实例分配一个显著更大的NPU组，通常是160个昇腾910 NPU（320个die），以满足自回归生成的高吞吐量和低延迟需求。此设置对应于MoE层的320路专家并行（EP320）。每个rank承载一个专家，整体配置包括32个共享专家、256个不同的路由器专家和32个冗余路由器专家以促进EPLB。为进一步加速解码，我们引入了优化的昇腾原生算子、流水线解码策略和多令牌预测支持，详见§4.2。

图9. CloudMatrix384上具有预填充-解码-缓存（PDC）解耦的点对点服务架构，使所有NPU能够通过超高带宽UB网络统一访问共享缓存集群，该集群由解耦内存池支持。

异步真实世界工作负载的动态调整。在真实的在线服务场景中，解耦的PDC服务架构能够根据传入工作负载的统计特性，动态、细粒度地调整预填充、解码和缓存节点的数量。例如，具有较长输入提示的请求会增加对预填充节点的相对需求，而生成较长输出的工作负载则需要更多的解码能力。这些比例不是固定的，而是随时间自适应调整，以最大化效率并维持延迟SLO。此外，用户会话是异步到达和离开的，每个会话都有自己的开始时间、提示长度和生成持续时间。为了应对这种高度动态和不可预测的工作负载模式，CloudMatrix-Infer的责任是通过批处理和调度机制来强制执行伪同步执行。具体来说，它在令牌边界对齐请求，允许多个会话被共同调度和并发处理。这种批处理策略分摊了计算成本，提高了吞吐量，并确保了即使在完全异步的请求到达模式下也能实现高资源利用率。

4.2 紧密耦合的解码与大规模专家并行

本节概述了CloudMatrix-Infer中由CloudMatrix384上紧密耦合的UB平面所支持的解码阶段优化。要最小化MoE模型的TPOT延迟，需要细粒度的专家并行，每个专家放置在一个专用的NPU die上。在DeepSeek-R1模型中，部署了256个路由器专家，这使得大规模专家并行（LEP）成为核心要求。然而，由于令牌处理中的顺序依赖性和协调数百个NPU die所产生的大量通信开销，实现LEP并非易事。

为了应对这些挑战，我们引入了一套针对CloudMatrix384量身定制的硬件感知优化技术。首先，我们介绍了利用UB平面实现低延迟、高吞吐量MoE执行的融合通信算子设计（§4.2.1）。接下来，我们详细介绍了我们为昇腾910定制的MLA实现（§4.2.2），并描述了一个基于微批处理的解码流水线，该流水线通过重叠两个执行流来隐藏延迟（§4.2.3）。最后，我们解释了CloudMatrix-Infer如何支持多令牌预测（MTP），这是DeepSeek-R1用来提高解码吞吐量的一个特性（§4.2.4）。

4.2.1 用于LEP的融合通信算子

基本MoE流程及其低效性。图10a展示了一个基本的MoE计算流程。在门控机制为每个令牌选择Top-K（在DeepSeek R1中K=8）个激活的专家后，前馈网络（FFN）阶段之前需要两次all-to-all通信。第一次all-to-all操作在所有NPU之间交换路由元数据，如令牌到专家的分配。第二次all-to-all操作交换实际的令牌数据，通常是每个令牌一个7,168维的隐藏状态向量。这些数据最初以BF16格式存储，在每个NPU上被量化为INT8以减少通信和计算成本，然后由其分配的FFN处理。FFN计算后，第三次all-to-all通信将专家输出发送回其源ranks，每个NPU在此执行最终的令牌组合步骤以重构输出。然而，这种基本的MoE实现存在几个低效之处：(1) 通信开销：三次all-to-all通信引入了显著的延迟，且因通信域庞大（数百个NPU）而加剧。(2) 动态形状：由于分配给每个专家的令牌数量在每次解码迭代中都会变化，all-to-all通信的数据形状是动态的。这种动态性因需要动态内存分配和频繁的CPU-NPU同步而降低了执行效率。(3) 顺序依赖：MoE计算的顺序执行特性在步骤之间创建了依赖关系，降低了资源利用率和吞吐量。

融合算子设计。为了解决这些低效问题，我们开发了FusedDispatch和FusedCombine，这是两个集成了通信和计算的融合算子，专门为在CloudMatrix384上实现最佳解码性能而设计。首先，为了减少all-to-all通信的开销，这两个融合算子用send-receive原语替换了所有的all-to-all通信。我们进一步利用UB平面中NPU之间的直接写入来减少通信延迟，并将分发阶段的量化操作移至NPU间通信之前以减小消息大小。其次，为了消除与动态形状相关的开销，我们预先分配了算子所需的所有内存空间，从而实现了静态图执行。第三，为了减少顺序执行的开销，算子内的通信和计算步骤也被组织成一个流水线，提高了资源利用率和吞吐量。

(a) 带有all-to-all通信的基本MoE计算流程。

图10. 基本MoE计算流程与我们提出的带融合通信算子的MoE计算流程的比较。

(b) 我们提出的带有FusedDispatch和FusedCombine的MoE计算流程。

四项核心优化技术。
1. 跨NPU的AIV-Direct通信。传统的NPU间all-to-all通信通常依赖于系统直接内存访问（SDMA）引擎来传输数据（图11中的红线）。然而，SDMA会引入相当大的启动开销，这在超低延迟场景中成为关键性能瓶颈，尤其是在解码期间。为了克服这个瓶颈，我们设计了一种新的通信机制，我们称之为AIV-Direct。AIV-Direct使AI向量（AIV）核能够通过UB互连直接将数据写入远程NPU的内存，完全绕过了易产生延迟的SDMA路径（图11中的蓝线）。通过消除SDMA的启动开销，AIV-Direct为点对点通信提供了一条快速、轻量级的路径。这急剧减少了传输启动延迟，加速了NPU间的数据交换，显著提高了在解码等延迟敏感操作中的性能。

图11. 基于SDMA与AIV-direct的跨NPU通信。红线和蓝线分别表示使用SDMA和AIV-direct的数据传输路径。
2. 早期量化。在原始的MoE计算流程中（如图10a所示），BF16令牌数据在令牌分发期间传输，导致通信量很大。为了缓解这个问题，我们在FusedDispatch内部发送令牌数据之前执行INT8量化，引入了早期量化。具体来说，我们传输INT8量化后的数据及其缩放因子，而不是发送BF16数据。这减少了数据交换阶段的通信负载。对于一个7,168维的令牌数据，INT8表示每个令牌需要7KB。缩放因子占用4字节（INT32），但为了对齐，我们分配512B。因此，每个令牌的传输消息大小为7.5KB。这项优化显著减少了带宽最密集阶段的通信开销。
3. 通过共享内存预分配实现静态执行。为了避免动态内存分配及其相关的CPU-NPU同步开销，我们在每个NPU rank中静态预分配共享内存缓冲区，用于接收来自MoE层中每个其他rank的数据。所需的缓冲区大小为：$Buffer\_size = num\_ranks \times max\_tokens \times msg\_size$。其中$max\_tokens$是单个NPU可能发送给单个对等方的最坏情况令牌数，而$msg\_size$是每个令牌的消息长度（令牌分发INT8量化后为7.5 KB，令牌组合为14 KB）。有了这个预分配的空间，FusedDispatch和FusedCombine都通过AIV-direct通信直接将数据写入目标NPU的内存缓冲区，避免了中间的本地拷贝和随后的远程读取，从而减少了内存流量和同步延迟。由于FusedDispatch和FusedCombine是背靠背执行的，共享单个缓冲区会产生竞争条件：一个较快的NPU可能启动FusedCombine并覆盖对等方的缓冲区，而该对等方尚未完成消费前一个FusedDispatch的有效载荷，从而损坏数据。我们通过双缓冲消除了这个风险：为FusedDispatch和FusedCombine保留了不同的缓冲区，确保一个缓冲区始终对写入者可用，而另一个正在被读取。预分配的内存开销不大。在我们的实验设置中，每个die处理最多96个令牌的本地批次，并承载最多两个专家，得到$max\_tokens = 96 \times min(8, 1) = 96$。在320个ranks的通信域中，分发缓冲区占用$320 \times 96 \times 7.5 \text{ KB} \approx 225 \text{ MB}$，组合缓冲区占用$320 \times 96 \times 14 \text{ KB} \approx 420 \text{ MB}$。两个缓冲区总共每个die只消耗约645 MB内存。
4. 数据发送流水线。远程数据写入需要计算对等NPU预分配内存缓冲区内的目标偏移量。然而，顺序执行此计算和传输会使执行停顿。为避免这种情况，我们在每个融合算子内部设计了一个数据发送流水线，如图12所示，该流水线将以下三个阶段流水化：(1) 将下一个令牌复制到本地UBuffer；(2) 计算远程缓冲区偏移量并（如果启用）应用INT8量化；(3) 发出AIV-Direct写入到对等NPU的内存。令牌以单令牌微批次的形式流经此流水线。当一个微批次的第3阶段传输数据时，后续微批次的第1和第2阶段并行执行。这种重叠隐藏了计算和通信延迟，实现了持续高效的令牌分发。

融合算子工作流程。通过结合这些技术，包括AIV-direct通信、早期量化、预分配的双缓冲内存和数据发送流水线，FusedDispatch和FusedCombine算子相比基本实现显著降低了解码期间MoE层的延迟。这两个融合算子的工作流程如图10b所示。
* FusedDispatch算子分三步进行。第一步是流水化的令牌发送阶段（优化4）。每个rank遍历分配给远程专家的令牌。对于每个令牌，分发AIV核首先将相关的令牌数据从内存加载到本地UBuffer，然后将令牌数据量化为INT8格式（优化2）同时附加相关的缩放因子。路由元数据，包括源rank ID、批次槽ID和键偏移量，被附加到每个令牌数据上。系统然后确定每个专家ID的目标rank，并通过AIV-direct将数据包写入对等方的预分配共享内存缓冲区（优化1和3）。第二步，一旦所有数据包都已发出，一个屏障确保在发送标志之前所有令牌数据写入都已完成。分发核并行计算每个专家的令牌数，跨核同步，然后使用AIV-direct向相应的对等方发出完成标志和令牌数（优化1和3）。最后一步涉及协调和输出组装。每个rank轮询由远程ranks写入的标志，并等待所有标志都设置为'1'。然后它读取相关的令牌数以计算输出偏移量。最后，所有分发核并行工作，将从共享内存接收到的令牌数据、量化尺度和每个专家的令牌数组装成连续的输出缓冲区，为后续的FFN计算阶段做好准备。
* FusedCombine工作流程同样由三个主要步骤组成。第一步是流水化的数据发送阶段（优化4），其中每个组合AIV核循环遍历其分配的对等ranks。该核读取每个对等方的相应接收计数，并将相关的FFN结果数据复制到本地UBuffer。它使用令牌的源元数据——特别是源rank ID、批次槽ID和键偏移量——来计算对等方上的目标地址。然后通过AIV-direct将令牌数据传输回始发rank上的预分配缓冲区（优化1和3）。第二步，再次使用每个令牌的元数据来计算其标志更新的目标地址。组合AIV核通过AIV-direct发出一个原子加操作，以增加对等方上相应的标志，表示一个贡献已交付（优化1和3）。在最后一步，每个核等待其分配的批次的标志都设置为'1'，表示该令牌的所有专家输出都已收到。然后，组合核从共享内存中收集专家FFN输出，从内存中检索相应的缩放因子，执行逐元素的缩放，并对结果求和。组合后的专家输出然后被添加到共享的FFN输出中，以产生每个令牌的最终结果。

图12. 令牌分发的数据发送流水线，采用动态量化；以及组合的数据发送流水线，传输未量化数据。

4.2.2 MLA优化

MLA性能瓶颈。多头潜在注意力（MLA）由DeepSeek引入，利用低秩压缩来减少KV缓存的空间占用，并结合权重吸收技术来降低计算成本。虽然MLA可以部署在CloudMatrix384上，但直接将DeepSeek的算子迁移到昇腾910 NPU会暴露几个性能瓶颈：
1. 细粒度算子的启动开销：MLA引入了许多细粒度的操作，如RMSNorm、线性投影和RoPE编码，这些通常作为独立的NPU算子实现。每个算子调用都会产生不可忽略的启动延迟，源于CPU端的调度、参数加载、指令调度和平铺配置。虽然将这些算子捕获到图中可以通过分组操作来分摊CPU调度开销，但它并不能消除NPU上每个算子的启动成本。因此，这些小内核启动的累积在MLA执行路径中引入了显著的延迟。
2. KV缓存格式转换开销：为了支持高性能矩阵计算，昇腾910 NPU的AI立方核（AIC）的L1缓存最佳地以NZ格式存储数据（一种专门的混合行主序和列主序布局）。然而，KV缓存通常以标准的N维（ND）格式存储在NPU的内存中。因此，算子内部通常需要显式地将KV缓存数据转换为NZ格式，然后AIC才能执行矩阵计算。这种显式的格式转换消耗了内存带宽并影响了访问效率，从而降低了可用于计算的有效内存带宽。
3. 多令牌预测（MTP）下的负载不平衡：当启用MTP时，解码阶段必须验证上一步预测的多个令牌。这导致同一批次内不同查询的有效序列长度不同（详见§4.2.4）。注意力算子的原始平铺策略，通常假设是BNSD（批次，头数，序列长度，头维度）内存布局，可能导致显著的负载不平衡。具体来说，没有MTP时，解码步骤中的所有查询通常序列长度为1，允许基于N和D轴的平铺策略创建大小相等的计算任务，从而确保负载均衡。启用MTP后，序列长度S可能因查询而异。在这种情况下坚持N轴和D轴的平铺会导致NPU核之间的计算负载差异很大，从而延长了整体MLA计算时间。

NPU友好的优化。为了克服这些限制并充分利用昇腾NPU的能力，我们提出了以下NPU友好的优化：
* 融合算子：MLAProlog和Fused Attention (FA)。为了大幅减少MLA计算路径中众多小算子的启动开销，我们采用了激进的算子融合，如图13所示。首先，将多个预注意力操作，包括RMSNorm、Q/K/V投影和RoPE，合并成一个名为MLAProlog的复合算子。这种融合将多个独立算子的启动成本减少到只有一个。此外，MLAProlog设计有内部微并行性，将其工作负载划分为多个子任务，并在AIC和AIV单元之间以流水线方式执行。这种细粒度的AIC-AIV并行性使得这些异构核上不同子任务的计算时间能够有效相互掩盖，进一步最小化了融合算子的执行时间。其次，为了补充MLAProlog，我们开发了一个融合注意力（FA）算子，它将FlashAttention与相邻的数据整形操作（如预注意力的Concat和后注意力的Slice）集成在一起。这进一步最小化了内核启动次数并改善了整个注意力计算路径的数据局部性。

图13. MLAProlog和FA算子，我们MLA优化的关键组成部分。
* NZ格式的KV缓存。为了消除张量格式转换的开销，我们在NPU内存中以NZ格式原生存储KV缓存。在MLA计算期间，计算出的KV张量直接以这种NZ格式附加到KV缓存中。在解码阶段，随着新的KV张量逐个令牌生成，它们可以根据NZ格式规则高效地写入NPU内存。昇腾NPU提供的数据移动接口能够在内存写入期间进行动态格式转换。这种带格式转换的写入能力避免了对KV缓存进行显式的、独立的ND到NZ数据转换步骤，从而提高了有效的NPU内存带宽利用率。
* MTP感知的BSND布局平铺。为了在MTP下恢复负载均衡，我们从BNSD内存布局转向BSND，并沿批次（B）和序列（S）轴采用动态平铺策略，这两个轴在查询之间是变化的。由于在这些操作期间，头数（N）和头维度（D）的值保持相对稳定，这确保了AIC核之间任务大小的更好均匀性，减少了由落后的计算任务引起的尾部延迟。

这三种策略，包括算子融合、原生NZ存储和自适应平铺，共同最大化了在CloudMatrix384上基于MLA的推理性能，为DeepSeek模型带来了延迟和吞吐量的显著提升。

4.2.3 基于微批处理的解码流水线

流水线设计动机。虽然融合通信算子（§4.2.1）有助于减轻一些开销，但与专家并行通信相关的延迟仍然是解码阶段的一个重要因素。为了进一步提高效率，受DeepSeek微批处理流水线策略【56，DeepEP: an efficient expert-parallel communication library, 2025】的启发，我们为CloudMatrix384设计了一个量身定制的基于微批处理的解码流水线，通过在两个流上进行细粒度的延迟重叠，最大化资源利用率并减少执行延迟。

与DeepSeek方法的区别。我们提出的资源划分和流水线策略与DeepSeek的方法不同，这既是由于昇腾NPU的独特特性，也是由于我们对MoE模型的特定并行部署。与DeepSeek在NVIDIA H800上每个GPU共存三个专家（一个共享专家和两个路由器专家）的部署不同（如图14a所示），我们在CloudMatrix384上的部署涉及一个大的专家并行度（EP320），通常每个NPU die一个专家以实现低解码延迟。没有了共享专家的计算，仅ATTN-0的计算延迟不足以完全掩盖MoE分发延迟。这需要一种不同的负载均衡流水线策略。

非对称流水线设计。为了在这些条件下实现高效的延迟重叠，我们为CloudMatrix384实现了一个基于微批处理的流水线，具有非对称的AIC和AIV划分，如图14b所示。该流水线包括两个交错的执行流，每个流负责解码过程的不同部分，并配置了不同的计算能力：
* 流0（注意力路径）：执行MLAProlog、FusedAttention和O_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时每层延迟接近，从而实现了两个交错微批次的完美重叠。如图14b中交替颜色所示，流0为一个微批次处理注意力计算，而流1同时为另一个微批次执行MoE计算和通信。为了适应变化的运行时条件，如可变的KV缓存长度，可以自适应地调整分配给两个流的计算资源。这种弹性确保了延迟平衡得以保持，从而在各种工作负载下都能维持高性能。

(a) DeepSeek在NVIDIA H800上的解码流水线（ATTN-0：核心注意力前的MLA下/上投影；ATTN-1：核心注意力、注意力输出投影和MoE路由门控）。

(b) 我们提出的在CloudMatrix384上的基于微批处理的解码流水线（延迟示例为使用4K序列长度、每NPU批大小96并启用MTP的解码）。
图14. 解码流水线比较：(a) DeepSeek在H800上的方法和(b)我们提出的在CloudMatrix384上的流水线。交替的颜色表示两个交错的微批次。

4.2.4 多令牌预测支持

流水线中断问题。多令牌预测（MTP）是DeepSeek-R1中使用的一种推测性解码技术，其中在每个解码步骤中预测N个令牌。这些预测随后在后续步骤中得到验证。通过每次解码生成多个令牌，MTP可以显著提高吞吐量。然而，在现有推理框架中启用MTP通常会因紧密的CPU-NPU同步而导致效率低下，从而导致流水线中断和性能下降。我们称之为流水线中断问题。如图15b（朴素MTP流水线）所示，MTP通常在每个解码步骤触发N+1个计算图，N个用于推测模块，一个用于最终验证。每次图分派都会引入0.6-0.8毫秒的启动延迟。这种开销，特别是在CPU介导的编排下，会导致NPU上出现空闲气泡，削弱了MTP的优势。我们确定了这些障碍的两个主要来源：
* 动态元数据初始化的CPU干预：MTP模块和主LLM都依赖于元数据，例如在解码过程中动态变化的当前序列长度。这些元数据只有在前面模块执行完成后才能最终确定。例如，一个MTP模块需要前一个LLM验证后确定的序列长度。如图15b所示，CPU在分派每个图之前初始化并传输这些元数据，导致频繁的CPU-NPU同步障碍。
* CPU干预的采样打断NPU执行：在MTP模块和主LLM生成令牌分布后，需要进行采样以选择实际的令牌。这个过程涉及CPU程序和离散的NPU操作的混合。这些频繁的CPU-NPU交互会因主机和设备之间的数据复制而产生开销。至关重要的是，因为每个后续的计算图都依赖于前一个的采样输出，这引入了序列化，阻止了连续的NPU执行。

流水线化MTP优化。为了克服这些瓶颈，我们引入了一种流水线化的MTP执行技术（图15c），该技术消除了这些CPU依赖性，并实现了高效的图执行：
* 聚合元数据初始化。我们不是为N+1个图中的每一个单独进行元数据设置，而是在解码步骤开始时预先计算并批处理所有元数据张量。这些直接存储在NPU内存中的张量包括每个MTP模块的增量序列长度和一个用于验证图的元数据块。这消除了重复的CPU参与，并实现了在NPU上的无缝、元数据感知的执行。
* 无CPU的NPU内采样。为了消除由基于CPU的采样频繁引起的NPU执行停顿，我们将整个采样过程迁移到NPU上。该策略涉及将必要的采样操作，如令牌概率排序、累积和计算和候选过滤，实现为一系列NPU算子。此外，为了最小化可能因分派大量NPU采样算子而产生的启动开销，这些算子被融合到MTP和LLM验证图中。通过将采样完全保留在设备上，我们防止了MTP阶段和LLM验证阶段之间的执行停顿，允许计算图背靠背执行，无需主机干预。

图15. 昇腾NPU上的流水线化MTP优化。

这些增强功能共同消除了朴素MTP实现中由CPU-NPU协调引起的频繁流水线中断。当NPU执行一个计算图时，CPU同时调度下一个，实现了持续的并行性和连续的NPU执行。这实现了NPU上操作的无缝流程，最大化了其利用率，并充分实现了MTP的潜在延迟优势。

4.3 资源高效的预填充与混合并行及微批处理

预填充阶段负责处理输入提示以生成初始KV缓存，它显著影响首个令牌生成时间（TTFT）和系统吞吐量。鉴于其通常是计算密集型的特性，在预填充期间实现高NPU利用率至关重要。然而，这一阶段常面临负载不平衡（由于异构输入序列长度）和通信开销等挑战，尤其是在MoE等复杂架构中。为了解决这些问题并在CloudMatrix384上最大化效率，我们在CloudMatrix-Infer中提出了三项关键优化。

4.3.1 MLA计算的混合并行

纯数据并行的低效性。LLM的预填充是一个显著的计算瓶颈。尽管CloudMatrix384提供了强大的计算能力和高带宽互连，我们观察到，最初在DeepSeek的GPU部署中使用的纯数据并行（DP）进行MLA计算（§3.5.1），在昇腾NPU上导致了次优的负载均衡和资源利用。这种低效源于两个主要原因：
1. 序列长度偏斜：在实践中，传入的请求通常具有不同的输入序列长度。在典型的32路DP配置中，分配到较短序列的NPU会更早完成工作，然后空闲等待处理批次中最长序列的NPU，导致计算周期的浪费。
2. 并发不足：如果处理中的请求数量少于DP度（例如，对于DP32，少于32个请求），一些DP分片将没有工作。延迟处理以累积满32个请求的批次会增加TTFT，而处理部分批次则会使NPU资源利用不足。

分阶段混合并行策略。为了减轻这些低效，我们引入了一种为预填充阶段MLA计算优化的分阶段混合并行策略，如图16a和16b所示，与基本DP形成对比。我们将MLA分解为三个阶段，并对每个阶段应用不同的并行方案。
* 第一和第三阶段：序列并行（SP）。第一阶段（包括处理层输入和down_proj操作）和第三阶段（包括o_proj操作）的计算，其并行策略本质上不依赖于序列内的令牌位置。对于这些阶段，我们利用序列并行（SP）结合序列打包，取代纯DP。该方法涉及将多个请求的提示序列连接起来，然后将这个打包后的超序列的片段分发到SP ranks。因此，来自不同长度请求的令牌以近似均匀的方式分布在NPU die之间，无论单个请求长度如何，都能实现有效的负载均衡。
* 第二阶段：张量并行（TP）。第二阶段（包括q_up_proj、kv_up_proj和核心FlashAttention机制）严重依赖于令牌位置进行注意力计算。对于此阶段，我们应用张量并行（TP）来确保计算负载在NPU die之间的均衡分布。在我们的预填充实现中，MLA通常在没有某些权重矩阵吸收的情况下执行，以提高原始计算效率，使其可以被有效地视为一个标准的128头多头注意力（MHA）操作。鉴于MHA计算对于每个注意力头是独立的，我们通过将这些注意力头均匀地分布在NPU die上来应用TP。

数据重分布。在这些不同并行策略之间转换需要数据重分布。我们在阶段1和2之间插入一个All-Gather，在阶段2和3之间插入一个All-to-All，以正确地重新分片和分发激活数据。图17展示了这种混合并行数据流的示例，其中四个不同长度的输入在四个NPU rank上处理。这种混合方法在整个MLA计算过程中保持了负载均衡。与传统的DP策略（图16a）相比，这种混合并行引入了这两个额外的集体通信步骤。然而，它们的开销得到了仔细管理。All-Gather操作在降维步骤（由down_proj暗示）之后执行，因此作用于可能更小的张量。All-to-All集体主要重新分发注意力机制的张量并行分片。由于这些分片的大小已经被TP度减小，因此在此操作期间每个rank交换的数据量远少于可能处理完整、未分片张量的集体操作。在具有高带宽UB平面的CloudMatrix384上，这两个算子的通信开销相对较小。

图16. 预填充阶段纯DP的基本MLA流与我们提出的利用混合并行的MLA流的比较。

图17. 预填充中MLA计算的分阶段混合并行（SP-TP-SP）的数据流示意图。

4.3.2 基于微批处理的预填充流水线

DeepSeek H800流水线。为减轻专家并行引入的通信开销，原始的DeepSeek部署采用了双微批处理流水线。如图18a所示，这种方法在NVIDIA H800 GPU上交错处理来自两个并发微批次的计算和通信。通过将一个微批次的计算与另一个微批次的通信开销（即Dispatch和Combine）重叠，该方法在预填充阶段提高了流水线效率并分摊了延迟。

CloudMatrix384上的优化流水线。然而，由于架构不匹配，直接将此策略移植到CloudMatrix384上的昇腾910 NPU效率低下。H800上的流水线通常为其流式多处理器（SM）的一个子集保留用于通信任务，这虽然实现了并发，但减少了可用的计算资源。相比之下，昇腾910提供了一个异构计算结构，包括用于矩阵运算的AIC、用于轻量级计算的AIV和用于数据移动的SDMA引擎，从而实现了更细粒度的、特定角色的任务分配。为了充分利用这种异构性，我们为CloudMatrix384引入了一个优化的基于微批处理的预填充流水线，如图18b所示。我们的设计将工作负载分配到AIC、AIV和SDMA子系统，如下所示：
* AIV卸载辅助计算：我们将低强度的辅助计算卸载到AIV，使AIC能够专注于ATTN和MLP等计算密集型算子。诸如Dispatch前的令牌重排序和元数据生成（表示为DispatchCompute），以及Combine后的专家输出累积（表示为CombineCompute）等任务被分配给AIV。这些操作是轻量级且可向量化的，非常适合AIV执行。如图18b所示，AIV可以为一个微批次处理DispatchCompute，而AIC则为另一个微批次执行核心计算，实现了细粒度的算子级重叠。
* SDMA处理数据传输：我们明确地将大容量数据传输，如MoE Dispatch和Combine的All-to-All通信，路由到SDMA引擎。通过将这些内存操作隔离到一个专用的传输流中，我们防止了与AIC和AIV执行的竞争。这种分离确保了计算密集型操作可以不间断地进行，并且通信延迟被并发执行的AIC/AIV任务所重叠。

与解码流水线的区别。这种硬件感知的任务分配，即AIC用于主要计算，AIV用于辅助向量任务，SDMA用于通信，提高了并发性并最小化了执行停顿。值得注意的是，这种设计与我们的解码阶段流水线（§4.2.3）不同，后者由于不同的延迟和吞吐量要求，通信逻辑与计算流的耦合更紧密。在预填充中，处理更长序列和更大微批次的需求使其对计算饱和和带宽竞争更敏感。因此，通过专用执行单元分离关注点并在算子级别重叠任务，更符合CloudMatrix384的性能特点。

图18. 预填充流水线策略比较：(a) DeepSeek在H800上的方法，为通信保留计算单元，与(b)我们提出的在CloudMatrix384上的流水线，利用异构的AIC、AIV和SDMA单元进行专门任务执行和增强的计算-通信重叠。在两张图中，交替的颜色用于区分正在处理的两个交错微批次。

4.3.3 预填充与解码之间的低干扰传输

在预填充-解码解耦的服务架构中，预填充阶段负责生成第一个令牌并产生相应的KV缓存，然后必须将其传输到解码阶段以启动自回归生成。为防止延迟敏感的解码性能受到预填充活动的干扰，我们在CloudMatrix-Infer中引入了三项系统级优化：(1) 通过RDMA平面实现KV缓存传输的硬件级隔离，(2) 异步调度以将预填充执行与解码调度解耦，以及(3) 模型感知的连接分组以均衡预填充-解码通信流量。

基于RDMA平面的KV缓存传输。预填充阶段完成后，完整的KV缓存被传输到指定的解码节点。为消除对解码阶段通信的潜在干扰，这种NPU到NPU的传输通过RDMA平面进行，该平面在物理和逻辑上都与用于带宽密集型解码操作（如令牌分发和专家输出组合）的UB平面解耦。使用RDMA平面的专用路径，我们将KV缓存的移动与延迟关键的解码流量隔离开来。此外，由于每个请求的KV缓存只传输一次，RDMA平面提供了足够的带宽而不会成为性能瓶颈。
异步预填充调度。为进一步最小化两阶段之间的干扰，我们将预填充调度和KV缓存传输卸载到解码调度器中的一个专用后台线程。当新的推理请求到达时，推理引擎立即将控制权交还给后台线程，该线程异步执行以下步骤：(i) 在目标解码节点上分配一个KV缓存缓冲区，(ii) 将预填充任务路由到一个低负载的预填充节点，以及(iii) 在完成后触发基于RDMA的缓存传输。这种设计确保解码线程永远不会被预填充计算或数据传输阻塞，从而实现了连续的解码调度和更高的响应性。
负载均衡的预填充-解码连接映射。在PD解耦系统中，一个常见场景是预填充和解码阶段使用不同的并行配置。例如，解码阶段可能采用张量并行（TP）和数据并行（DP）的组合，而预填充阶段通常使用更大的TP度来加速长输入序列的处理。DeepSeek-R1模型的一个关键特性是，它使用带有单个潜在头的MLA，TP组（tp_rank）内的所有rank都持有相同、完整的KV缓存副本。虽然这种数据冗余提供了灵活性，但也引入了如果管理不当可能产生网络热点的风险。如果解码实例的所有rank都从同一个源预填充rank拉取KV缓存，那条单一的网络链路将成为严重的瓶颈。为防止这种情况，我们开发了一种确定性的组连接机制，以确保均衡的传输负载。该映射方案计算如下：
- 令 prefill_tp_size 为预填充实例的TP大小。
- 令 decode_tp_size 和 decode_dp_size 分别为解码实例的TP和DP大小。
- 令 decode_tp_rank_id 和 decode_dp_rank_id 分别为特定解码进程的TP和DP rank id。
- 首先，建立分组参数：ratio = prefill_tp_size / decode_tp_size 和 group_size = decode_dp_size / ratio。
- 随后，每个解码rank使用以下映射确定其源预填充rank：group_id = ⌊ decode_dp_rank_id / group_size ⌋ 和 prefill_tp_rank_id = (group_id × decode_tp_size) + decode_tp_rank_id。
  该方案确保了所有预填充-解码链路上的连接拓扑均衡，避免了通信热点并维持了高吞吐量。

4.4 UB驱动的分布式缓存与统一内存访问

LLM在云环境中的高效部署严重依赖于高性能的缓存策略。这些策略对于加速数据访问至关重要，主要针对两个关键场景：历史KV缓存以优化上下文预填充（上下文缓存），以及模型参数以促进快速模型部署和切换（模型缓存）。这些缓存层的有效实施显著减少了冗余计算，缩短了模型加载延迟，并增强了整体系统性能。支持此类缓存功能需要一个高性能、大容量、低延迟的中间内存层，战略性地定位以弥合NPU高速内存和较慢的持久存储服务（例如对象存储服务（OBS））之间的性能差距。

本节详细介绍了在CloudMatrix384上用于LLM服务的UB驱动的分布式缓存。我们首先描述了解耦内存池基础（§4.4.1），它利用高带宽的UB平面构建了一个具有统一内存访问的解耦内存池。然后，我们介绍了基于此池构建的两个关键缓存服务：上下文缓存（§4.4.2）和模型缓存（§4.4.3），两者都通过华为云的弹性内存服务（EMS）【26，Huawei Cloud Elastic Memory Service (EMS), 2025】提供。

4.4.1 解耦内存池

核心设计。EMS缓存服务的核心是一个逻辑上解耦的内存池，由CloudMatrix384内跨节点聚合的CPU附加DRAM组成。该池作为一个统一的高性能内存基底，用于缓存历史KV缓存和模型参数。该内存池的一个显著特点是与UB网络平面的深度集成，实现了对这个分布式DRAM的高效、统一内存访问，并允许NPU快速检索所需数据，无论其物理位置如何，从而促进了§4.1中提出的点对点服务架构。

软件架构。如图19所示，这个解耦的内存池由一个专用的、三组件的软件架构管理：
1. MP SDK：嵌入在AI应用程序的进程中，将上层缓存请求转换为分布式内存操作，并公开键值存储风格的API，如Put和Get。
2. MP Controller：一个集中的控制平面，维护元数据（例如，分布式哈希表（DHT）视图、命名空间），协调操作并编排资源管理。
3. MP Server：部署在贡献DRAM的节点上，管理本地内存，处理分层和恢复，并参与负载均衡。

图19. EMS中UB驱动的解耦内存池的部署架构。

关键机制与特性。这些软件组件与UB平面的相互作用实现了几个关键的操作机制和系统特性：
* 分布式数据索引和放置。为了确定键值对在解耦内存池中的放置位置并高效地定位它，内存池采用了一个全局一致性哈希索引。该索引将输入键映射到一个负责的MP Server节点。一个DHT视图支撑着这个方案，其整体一致性和元数据由MP Controller管理。
* 高性能远程内存访问。UB平面实现的一个关键功能是由NPU直接、高性能地访问远程DRAM。这涉及一个在MP Server实例和MP SDK客户端初始化期间建立的内存映射和注册过程。控制消息被协商以交换指定用于池的DRAM段的物理地址范围，然后这些地址范围被注册到UB结构和MP Controller。
* 细粒度的本地内存管理。为了有效管理其分配的DRAM段并对抗由可变大小数据对象（如KV缓存块或模型分片）引起的碎片化，每个MP Server采用了一个多粒度内存分配系统。一个关键方面是使用巨页来减少内存片分配的频率和相关的管理开销。对于数据分配，系统支持可变长度的内存分区，显著提高了内存利用率。
* 带持久性和恢复的内存分层。为了管理存储成本并确保数据持久性，解耦内存池集成了一个由MP Server管理的基于SSD的分层。该层利用云提供的弹性卷服务（EVS）SSD来提供大容量、持久的存储。分布式DRAM池作为EVS层之上的快速缓存，实现了对常用数据的低延迟访问。通过将所有数据写入EVS来强制执行持久性。该分层结构确保了故障恢复能力：如果内存中的数据丢失，可以从EVS层恢复。
* 命名空间隔离。为了支持多租户并管理不同上下文缓存和模型缓存实例的数据，解耦内存池提供了KV命名空间隔离。这主要由MP Controller编排，它管理命名空间的创建、删除和元数据。

4.4.2 上下文缓存

功能与实现。LLM推理的预填充阶段在处理长序列时计算密集。通过重用先前请求的历史KV缓存可以获得显著的性能提升，这在多轮对话、少样本提示等场景中尤其有价值。在我们的架构中，上下文缓存是指一个用于存储和高效检索这些历史KV缓存的专用机制。上下文缓存由华为云上的EMS服务【26，Huawei Cloud Elastic Memory Service (EMS), 2025】实现。EMS利用UB驱动的解耦内存池（§4.4.1）为历史KV缓存创建一个共享的分布式存储库。这些缓存根据模型特性和UB传输效率被组织成页块（例如，每块128–512个令牌）。

索引、去重和检索。EMS为上层LLM服务框架提供了一个专门的上下文缓存SDK，用于存储和检索历史KV缓存块。每个KV缓存块与一个从其令牌序列派生的唯一哈希键相关联，并用前缀哈希增强以实现内容可寻址索引。这允许快速查找和去重：相同的KV块只存储一次并在请求之间重用。分配给上下文缓存的解耦内存池部分受容量限制。当接近这些限制时，MP Server（§4.4.1）会触发将较冷的KV缓存块从DRAM驱逐到EVS支持的SSD层。

与PDC解耦的交互。EMS与解耦的预填充和解码流水线紧密集成：
* 预填充 - 重用和存储：收到新请求后，预填充引擎用输入前缀的哈希查询EMS以识别可重用的KV缓存块。如果找到，这些块通过UB平面获取并直接加载到NPU内存中，绕过冗余计算。然后引擎处理剩余的后缀并生成相应的KV缓存块。这些新块被异步存储回EMS，以便在未来的请求中重用，而不会阻塞正在进行的计算。
* 解码 - 选择性缓存存储：解码阶段生成的KV缓存可以用于非推理模型，但不能用于像DeepSeek-R1这样的推理模型。由于位置敏感的注意力机制，位置变化会破坏缓存的有效性。因此，解码生成的缓存通常不被存储。

4.4.3 模型缓存

挑战与解决方案。现代LLM服务基础设施必须高效支持多种模型，并适应动态模型切换。然而，从持久存储（如OBS）加载数十亿参数的LLM到NPU内存会产生显著的延迟。例如，从OBS加载一个671B参数的DeepSeek-R1模型，假设每个桶的标准访问带宽为2.5 GB/s，需要超过五分钟。为了应对这些挑战，我们集成了由EMS提供的模型缓存。EMS利用UB驱动的解耦内存池（§4.4.1）作为高性能、分布式的缓存基底，以支持全系统的低延迟模型访问。EMS提供了一个模型缓存SDK，公开了用于检查、预取和从缓存加载模型的API。

缓存管理策略。EMS将每个模型分解为内存块，并作为键值条目存储在解耦内存池中。一个集中的元数据服务跟踪从每个模型到其对应块集的映射。EMS通过协调的策略管理缓存的模型块，涵盖准入、驱逐和版本控制。对于准入和预取，EMS根据应用提示和观察到的访问模式将模型块加载到DRAM或SSD层。驱逐由解耦内存池的原生基于LRU的策略处理。对于版本控制，EMS通过维护版本感知的标识符来确保NPU始终执行正确的模型版本。

模型缓存的优势。EMS利用UB驱动的解耦内存池为模型缓存实现了两个关键优势。首先，高带宽、低延迟的UB平面促进了模型块从EMS内存层到NPU内存的快速传输，显著减少了模型加载延迟。其次，EMS使用统一的、集群范围的内存池，消除了数据冗余，允许一个缓存的模型版本被所有NPU实例共享。这减少了对持久存储带宽的压力和缓存所需的累积DRAM和SSD占用空间。表1通过对一个671B参数INT8量化模型的不同加载策略的性能比较，量化了这些优势。EMS将冷启动延迟从约2560秒减少到约320秒，并将DRAM开销从8倍减少到1倍，同时在模型切换场景中实现了100%的缓存命中率和约5秒的切换延迟。

表1. 加载一个671B INT8模型（约671GB数据大小）到CloudMatrix384内8个模型实例的模型加载策略性能比较。

4.5 INT8量化

为了在昇腾910平台上为DeepSeek-V3/R1等大规模MoE模型实现高吞吐量、低延迟的推理，我们设计并实现了一个无需训练、分层的INT8量化方案，用于模型权重和激活值。该方案旨在最大化计算效率和减少内存占用，同时仔细管理潜在的精度下降。我们方法的核心组成部分如下：

混合精度策略。我们的量化方案采用混合精度策略，根据算子对整体性能的影响（如计算负载、内存访问）和对数值精度的敏感性进行分类。计算最密集的操作，如前馈网络（FFN）和注意力机制中的大型矩阵乘法，被量化为INT8以利用最高吞to-end量。相反，对量化误差更敏感但占整体内存访问或计算负担较小的子模块或特定操作（如某些归一化层或关键的门控机制）则保留较高的精度，使用BF16或FP32。
自适应尺度搜索。有效的量化需要仔细地将浮点值的动态范围对齐到INT8整数的有限范围内。对于每个要进行INT8量化的权重张量和激活张量，我们引入了一个轻量级的、自适应的尺度搜索过程。该过程自动确定最优的缩放因子 $s^*$，以最小化量化误差。尺度搜索被形式化为一个优化问题：$\arg\min_s \| WX - Q(W \cdot s)(s^{-1} \cdot X) \|$。这里，$W$ 代表权重，$X$ 代表激活值，$Q(\cdot)$ 表示量化函数。此过程在后量化校准步骤中离线执行，因此在推理期间不产生额外的运行时开销。
异常值抑制和结构转换。大型模型中的某些组件，特别是MoE架构中的特定专家子网络或门控结构，可能表现出具有长尾或显著异常值的激活或权重分布。为减轻此问题，我们采用了一种涉及结构转换的异常值抑制技术。在量化之前，引入简单的线性变换，旨在将极端值重新分布到一个更平衡和量化友好的范围内，而不改变层的底层数学功能。
高效的INT8矩阵乘法内核。INT8量化的性能优势关键取决于高度优化的执行内核。我们利用混合粒度的量化方案进行矩阵乘法：激活值（$X$）按令牌进行量化（每个令牌确定动态范围），而权重（$W$）按通道进行量化（通常是每个输出通道，每个通道的范围是静态的）。这种方法平衡了适应快速变化的激活统计数据的需求与保持稳定权重表示的愿望。这种混合粒度，结合为权重和激活值精心对齐的内存布局，允许充分利用昇腾NPU上可用的专用整数矩阵乘法指令。
块级裁剪和误差补偿。为了进一步提高精度并处理大型权重张量内的局部变化，我们实现了块级裁剪和误差补偿。权重被统计分析并划分为更小的块。为每个块建立一个不同的、可容忍的裁剪范围。这个范围可以通过优化一个用于裁剪的缩放因子 $\alpha$ 来确定（例如，$\text{clip}_{\text{max}} = \alpha \cdot \max(W_{\text{block}})$ 和 $\text{clip}_{\text{min}} = \alpha \cdot \min(W_{\text{block}})$），该因子最小化了该特定块的量化误差，例如，通过求解：$\arg\min_\alpha \| W_{\text{block}} - Q(W_{\text{block}}; \alpha) \|$。这里，$Q(W; \alpha)$ 表示使用裁剪因子 $\alpha$ 对块内的权重 $W$ 进行量化。同时，轻量级的误差补偿项被战略性地插入到推理计算图中，以抵消或部分纠正量化在模型不同点引入的系统性误差。

A4 实验环境与结果

实验环境

本评估在华为云的ModelArts Lite（集群模式）服务提供的华为CloudMatrix384超级节点上进行。
* 硬件配置：
* NPU：使用了单个CloudMatrix384中的256个昇腾910 NPU及其关联的鲲鹏CPU。
* 集群划分：
* 解码集群：部署了1个解码实例，使用160个昇腾910 NPU（分布在20个计算节点，共320个NPU die）。
* 预填充集群：部署了6个预填充实例，每个实例分配16个昇腾910 NPU（每个实例2个计算节点，共32个NPU die），总共使用96个NPU。
* 缓存集群（EMS）：利用所有32个物理计算节点（解码20个+预填充12个）的主机CPU DRAM构建UB驱动的解耦内存池。
* 软件配置：
* 系统：部署了由华为和SiliconFlow共同优化的LLM推理引擎，以及必要的华为CANN软件包。
* 服务：华为云的弹性内存服务（EMS）预先部署在分配的计算节点上，提供分布式缓存能力。
* 模型与并行策略：
* 模型：DeepSeek-R1（671B参数版本），已量化为INT8。
* 解码并行：稀疏MoE层采用EP320专家并行，MLA和密集FFN层采用DP320数据并行。每个EP rank部署一个专家实例。
* 预填充并行：稀疏MoE层采用EP32专家并行，MLA组件采用混合并行策略。每个rank配置10个专家。
* 部署架构：遵循本文提出的具有PDC解耦的点对点服务架构。

实验结果

整体性能

预填充吞吐量。如表2所示，在默认配置下，CloudMatrix-Infer每个NPU处理5,655 tokens/s，计算效率为3.76 tokens/s/TFLOPS，显著高于SGLang在NVIDIA H100上的默认效率（3.18 tokens/s/TFLOPS）。在理想化的“完美EPLB”条件下，CloudMatrix-Infer达到6,688 tokens/s/NPU，效率为4.45 tokens/s/TFLOPS，超过了SGLang在H100上的理想效率（3.75 tokens/s/TFLOPS）和DeepSeek在H800上的profile数据（3.96 tokens/s/TFLOPS）。

表2. DeepSeek-R1的整体预填充吞吐量（每加速器）。

解码吞吐量。如表3所示，在TPOT（每个输出令牌的时间）低于50ms的SLO下，CloudMatrix-Infer（批大小96）的绝对吞吐量为1,943 tokens/s/NPU，高于DeepSeek在H800上的基线（1,850 tokens/s/GPU）。在计算效率方面，CloudMatrix-Infer达到了最高的1.29 tokens/s/TFLOPS，超过了SGLang在H100（1.10）和DeepSeek在H800（0.93/1.17）上的效率，表明其对计算资源的高效利用。

表3. DeepSeek-R1的整体解码吞吐量（每加速器）。

吞吐量与延迟的权衡。表4展示了在不同TPOT SLO和提示/输出长度下的解码吞吐量。结果表明，CloudMatrix-Infer能够通过动态调整批大小来满足不同的延迟约束。在宽松的50ms SLO下，批大小为96，吞吐量为1,943 tokens/s/NPU。当SLO收紧至15ms时，批大小降至8，吞吐量为538 tokens/s/NPU，展示了系统在严格实时需求下的适应性和可预测性能。

表4. CloudMatrix-Infer在不同TPOT SLO和提示/输出长度下的解码吞吐量。

准确性

为了评估在CloudMatrix384上部署的INT8量化版DeepSeek-R1的推理准确性，我们将其与官方DeepSeek-R1 API和技术报告中的结果进行了广泛的基准测试比较。测试涵盖了英语、代码生成、数学和中文四大类的16个不同基准。如表5所示，在昇腾910上实现的DeepSeek-R1 (INT8) 表现出的性能与官方API和原始技术报告中的指标基本相当。这表明，为在昇腾910上部署而应用的INT8量化有效地保留了模型在各种任务上的能力。

表5. DeepSeek-R1在昇腾910上的INT8量化、官方DeepSeek-R1 API以及DeepSeek-R1技术报告中报告的结果在多个基准测试上的准确性比较。

消融研究

微批处理流水线。
* 解码流水线：如图20所示，启用微批处理流水线后，解码吞吐量在不同批大小下提升了5.8%至9.4%。虽然提升幅度相对温和（因为CloudMatrix384的UB平面本身通信开销较低），但通过重叠注意力和MoE路径，总的每层延迟减少了约10%。
* 预填充流水线：如图21所示，启用微批处理流水线后，预填充吞吐量在不同提示长度下显著提升了23%至31%。这是因为通过将辅助计算卸载到AIV并将数据传输卸载到SDMA，核心计算（AIC）与通信的重叠效率大大提高，总的每层延迟减少了约24%。

图20. 有无微批处理流水线时的解码吞吐量和每层延迟分解。

图21. 有无微批处理流水线时的预填充吞吐量和每层延迟分解。

多令牌预测（MTP）。如图22所示，启用MTP（单个推测令牌）后，解码吞吐量相比非MTP基线提升了6%至49%，在小批次下增益更明显。尽管MTP使每层执行延迟增加了约44%（因为需要处理基础令牌和推测令牌），但由于70%的接受率意味着平均每次迭代产生1.7个令牌，吞吐量的提升超过了延迟的增加，证实了MTP的净积极影响。

图22. 有无MTP时的解码吞吐量和每层延迟分解。

上下文缓存。如图23所示，EMS上下文缓存能显著提升预填充性能。随着令牌重用率从12.5%增加到90%，使用UB网络的EMS预填充吞吐量提高了2.28倍，TTFT降低了59%。与使用VPC网络相比，使用UB平面可将预填充吞吐量提高多达1.52倍，这直接归因于UB的高带宽和低延迟，它加速了从分布式EMS缓存中加载KV块的过程。

图23. 使用不同配置的EMS上下文缓存时的整体预填充吞吐量和TTFT。

算子性能

通信算子。如表6所示，在MoE通信基准测试中，CloudMatrix384上的CANN实现（使用UB平面）在Dispatch和Combine操作上均优于NVIDIA H800上的DeepEP（使用RDMA）。Dispatch操作的延迟更低，在小EP度下带宽更高。Combine操作的优势更明显，延迟显著降低（例如，EP256下为149 µs vs. 360 µs），且在所有EP度下都实现了远高于H800的每rank带宽（例如，EP256下为103 GB/s vs. 40 GB/s）。

表6. 在NVIDIA H800（RDMA）和CloudMatrix384（UB平面）上，Dispatch和Combine操作在不同EP度下的通信算子性能（每rank的延迟和带宽）。

MLA算子。如表7和表8所示，在计算密集型场景下，CloudMatrix384上的CANN MLA实现了65.4%的TFLOPS利用率，与H800上的FlashMLA（66.7%）相当。在内存密集型场景下，CANN MLA实现了84.1%的内存带宽利用率，与H800上的89.6%也表现出相似的高效率。

表7. 在计算密集型设置下（BF16/FP16精度），NVIDIA H800和昇腾910 die（CloudMatrix384）上MLA算子的利用率。

表8. 在内存密集型设置下，NVIDIA H800和昇腾910 die（CloudMatrix384）上MLA算子的内存带宽利用率。

GEMM算子。如表9所示，昇腾910 die上的CANN INT8 GEMM内核在各种矩阵维度下表现出持续的高计算利用率，范围在77.4%至82.7%之间。同时，其实现的内存带宽远低于硬件峰值，这表明对于测试的矩阵维度，INT8 GEMM操作是计算密集型而非内存带宽密集型的，显示了NPU内部缓存层次和数据重用的高效性。

表9. 在昇腾910 die（CloudMatrix384）上，使用INT8输入和BF16输出的不同配置下，INT8 GEMM实现的内存带宽和计算利用率。

A7 补充细节

6.1 未来CloudMatrix的演进

CloudMatrix384体现的超级节点概念可以沿着多个维度进行扩展，以适应未来的AI工作负载。

6.1.1 统一VPC和RDMA平面

统一网络架构。如§3.2所述，CloudMatrix384目前为横向扩展（RDMA）和VPC流量采用独立的网络平面。然而，CloudMatrix支持将横向扩展通信集成到VPC网络中的潜力。在典型的AI训练和推理工作负载中，带宽密集的通信阶段（如张量、专家和序列并行）主要包含在超级节点内。相比之下，跨超级节点的通信（主要由数据和流水线并行引起）通常表现出低得多的带宽需求。通过分层DP通信和通信隐藏技术，VPC网络可以充分满足大多数AI工作负载的超级节点间通信需求。基于这一观察，一个基于VPC平面的统一网络架构可以支持在可用区（AZ）规模上构建大规模AI集群。

6.1.2 更大规模的超级节点

扩展超级节点的驱动因素。尽管CloudMatrix384提供了384个NPU的巨大规模，但预计下一代AI模型和应用场景将需要更大规模的超级节点。有几个关键因素推动着这一规模增长的轨迹：
1. 匹配模型演进的扩展。随着LLM在参数规模和架构复杂性上的持续扩展，服务它们的基础设施也必须相应演进。未来模型预计将具有更大的参数量、更长的输入序列和更多的稀疏激活专家。这些趋势对计算、内存和互连带宽提出了越来越高的要求。
2. 提高资源分配效率。扩大超级节点规模还能在真实的异构工作负载条件下提高全系统的资源利用率。如图24所示，更大的超级节点在各种平均块大小下都能持续实现更高的NPU分配率。例如，当平均块大小为10.08时，一个384-NPU的超级节点实现了超过94%的分配率，而一个224-NPU的超级节点则低于91%。
3. 几乎恒定的摊销网络成本。扩大超级节点的规模本身并不会导致每个NPU的网络成本更高。在相同的网络架构下（例如，2层Clos类交换拓扑），只要配置实现了完整的交换机端口利用，每个NPU的摊销网络基础设施成本在不同超级节点规模下几乎保持不变。如表10所示，192、288或384个NPU的配置都实现了100%的交换机利用率，每个NPU的摊销交换机成本相同。
4. 适应增加的资源异构性。未来的AI工作负载将需要在同一执行环境中支持日益多样化的硬件。除了NPU和CPU，下一代超级节点可能还会集成用于物理模拟、实时视频处理、无损数据压缩和密码计算等任务的专用加速器。

图24. 不同超级节点规模和紧密耦合块大小下的NPU分配率。
表10. 不同超级节点规模下的交换机利用率。注意，每个逻辑交换机由两个物理交换芯片组成，如§3.3.3所述。

6.1.3 CPU的物理分解和池化

物理分解的愿景。虽然当前的CloudMatrix384超级节点已经通过池化其计算节点中的CPU和NPU实现了一定程度的资源灵活性，但CloudMatrix架构的一个关键未来方向是更根本的CPU和NPU资源的物理分解，如图1所示。这设想了一个由不同、专门的节点类型构建的超级节点：密集封装AI加速器的以NPU为中心的节点，和提供大量通用计算、内存容量和I/O能力的以CPU为中心的节点。这些异构节点类型将通过高带宽、低延迟的UB网络平面互连，从而在超级节点级别实现粒度化、灵活和可扩展的资源池化。

物理分解的优势。尽管CloudMatrix384的点对点UB拓扑已经解耦了逻辑资源分配，但将CPU和NPU资源物理分离到专用资源池中可以解锁更多优势：
1. 独立和优化的扩展：物理上分离的以NPU为中心的节点和以CPU为中心的节点可以被开发出来。这使得超级节点的NPU计算能力和通用CPU/内存能力可以独立且更经济地扩展。
2. 增强的资源利用和专业化：专门的节点设计允许针对主要资源类型进行硬件优化。NPU节点可以专注于加速器的供电和散热，而CPU/内存节点可以优化内存密度、I/O带宽或特定的CPU指令集。

6.2 未来的服务系统增强

随着底层超级节点架构的不断演进，LLM服务系统必须协同演进以充分利用这些能力。一个关键方向是超越粗粒度的分解（例如，预填充-解码分离），向更细粒度的组件级分解和智能、自适应的部署策略发展。

6.2.1 组件级分解

更细粒度的分解。CloudMatrix384中采用的具有预填充-解码-缓存分解的点对点服务架构已被证明在分离LLM推理的主要阶段方面是有效的。然而，通过将模型执行分解为更细粒度的组件，这些组件可以独立管理、部署和扩展，从而可以实现进一步的改进。我们强调两个新兴方向：
1. 解码-注意力分解和卸载：Adrenaline系统【37，Injecting Adrenaline into LLM Serving: Boosting Resource Utilization and Throughput via Attention Disaggregation, 2025】表明，通过将内存密集型的注意力计算从解码路径中分解出来并卸载到未充分利用的预填充实例，可以实现额外的性能增益。这种方法提高了整体内存带宽利用率，并使解码实例能够支持更大的批大小，从而提高计算效率。
2. 注意力和MoE分解：MegaScale-Infer【59，MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism, 2025】提出将注意力和专家组件分解为独立的执行服务，从而能够采用不同的并行策略和硬件映射。处理每个令牌的注意力层在内存优化的节点上使用数据并行部署，而专家FFN则通过专家并行分布在专用的资源池中。这种分解执行减少了竞争，提高了吞吐量，并允许注意力和专家资源的独立扩展。

6.2.2 混合和自适应部署

微服务化部署。一旦LLM推理被分解为可以被视为细粒度微服务（如注意力执行、FFN计算、KV缓存管理或MoE专家门控）的组件，服务系统就获得了采用更复杂部署策略的显著灵活性。这些混合和自适应的部署模型使系统能够根据每个组件独特的计算和内存需求来定制资源分配，从而提高整体利用率和可扩展性。
1. 硬件感知的微服务放置：每个微服务可以根据其性能剖面映射到最合适的硬件类型。例如，通常受内存带宽限制的注意力层应优先分配给具有高内存吞吐量的NPU；计算密集型的FFN模块则受益于分配给具有强大计算能力的NPU。
2. 混合微服务共置：分解的微服务也可以动态地共置以提高整个超级节点的资源利用率。例如，解码阶段的内存密集型注意力操作可以卸载到内存未充分利用的预填充实例【37，Injecting Adrenaline into LLM Serving: Boosting Resource Utilization and Throughput via Attention Disaggregation, 2025】。
3. 微服务的自适应和独立扩展：微服务分解的一个关键优势是能够根据实时工作负载特性独立扩展每个组件。例如，在处理长上下文输入期间，注意力微服务可能会经历更高的负载并相应地进行扩展，而无需额外的FFN或专家资源。

智能编排。为了充分利用这些能力，服务基础设施必须集成一个复杂的编排层，能够持续剖析系统负载、预测性能瓶颈，并做出实时、SLO感知的调度和扩展决策。

A5 结论

本文介绍了华为CloudMatrix，一个体现华为先进AI基础设施愿景的下一代AI数据中心架构，并重点介绍了其首个生产级实现——华为CloudMatrix384。CloudMatrix384是一个为高效支持大规模AI工作负载而设计的AI超级节点，其特点是完全点对点的硬件互连设计，集成了384个昇腾910 NPU和192个鲲鹏CPU，通过超高带宽、低延迟的统一总线（UB）网络互连。

基于CloudMatrix384，我们提出了CloudMatrix-Infer，这是一个全面的服务解决方案，其特点是采用点对点服务架构，将推理工作流分解为独立的预填充、解码和缓存子系统。我们进一步设计并实现了先进的硬件感知技术，包括大规模专家并行（LEP）、优化的通信和MLA算子、基于微批处理的流水线以及INT8量化。

我们使用DeepSeek-R1模型的广泛评估表明，CloudMatrix-Infer实现了卓越的吞吐量，预填充阶段每个NPU达到6,688 tokens/s，解码阶段每个NPU达到1,943 tokens/s，同时始终保持低于50ms的低延迟。其计算效率在预填充和解码阶段分别达到4.45 tokens/s/TFLOPS和1.29 tokens/s/TFLOPS，均超过了SGLang在NVIDIA H100和DeepSeek在H800上已发布的效率。此外，INT8量化策略在众多基准测试中保持了与DeepSeek官方API相当的准确性。

展望未来，进一步增强CloudMatrix384的方向包括：统一VPC和RDMA网络平面，扩展到更大的超级节点配置，以及追求更深度的CPU资源分解和池化。此外，更细粒度的组件级分解和自适应部署策略为实现AI数据中心基础设施更大的灵活性、效率和可扩展性提供了有希望的途径。这些发现共同验证了华为CloudMatrix作为一个高效、可扩展且性能优化的平台，为部署大规模AI工作负载设定了基准。