仙尸风流争霸记大型语言模型（LLMs）参数规模的爆炸式增长、混合专家（MoE）架构的应用以及上下文长度的扩展，使得人工智能基础设施正面临日益严峻的挑战。传统AI集群在计算强度、内存带宽、芯片间通信和延迟方面出现诸多瓶颈。实际部署LLMs时，需应对多样化的突发工作负载、变长输入和不平衡的专家激活等挑战，并且还需要满足严格的服务质量目标。

　　针对上述挑战，华为推出了CloudMatrix384超节点，将384个昇腾910C NPU、192个鲲鹏CPU以及其他硬件组件通过超高带宽、低延迟的统一总线（Unified Bus，UB）网络互联，使得计算、内存和网络资源能够动态池化、统一访问以及独立扩展。在此基础上，进一步提出了CloudMatrix-Infer，这是一套全面的LLM服务系统，优化了大规模MoE模型的部署。

　　CloudMatrix架构从底层重新构思了AI数据中心基础设施，突破了传统的CPU中心化层次设计。通过全面点对点（Fully Peer-to-Peer）的高带宽互联，CloudMatrix实现CPU、NPU、DRAM、SSD、网卡等其他资源的高性能通信，且不依赖CPU进行中介协调。

　　（1）可扩展的 TP/EP 通信。通过UB互联，实现NPU之间点对点通信，张量并行（TP）和专家并行（EP）组能够突破单节点边界，实现高效的跨节点通信。

　　（2）针对异构工作负载（Heterogeneous Workloads）的灵活资源组合。CloudMatrix将 CPU、NPU 和内存解耦为独立的资源池，能够基于工作负载需求进行细粒度的资源配置，提高了资源分配的灵活性。

　　（3）支持融合工作负载的统一基础设施。高带宽的UB网络在单一可扩展的基础设施中，能够同时支持AI和数据密集型应用，实现LLM的推理、训练、模拟和分析等任务的融合执行。

　　（4）基于解耦内存池的类内存级存储。CloudMatrix 将集群中各节点CPU连接的DRAM 整合为一个共享的高性能内存池，并通过UB进行访问。该设计有效消除了传统 I/O 架构中的性能瓶颈，显著加速了KV缓存复用、参数加载以及模型检查点等关键操作。

　　CloudMatrix384是一个AI超级节点，在实际部署中可以通过多个CloudMatrix384超级节点互联，构建更大规模的人工智能数据中心。CloudMatrix384 集成了384块昇腾910C NPU和192块鲲鹏CPU，每块NPU、CPU都通过UB网络互联，使得节点间的通信性能接近同一节点内部的水平。

　　为了支持多样化的流量模式，同时需要与传统数据中心网络基础设施保持兼容，CloudMatrix384集成了三种网络平面：

　　UB平面构成了超级节点内部的主要超高带宽扩展网络，采用无阻塞的全互连拓扑结构直接连接384块NPU和192块CPU。通过UB网络，能够实现细粒度并行策略（张量并行和专家并行）的高效部署，支持跨节点的大规模并行。同时，UB 还支持快速访问共享内存池（包括NPU和CPU内存），对于模型权重和KV缓存的高效缓存至关重要。

　　RDMA平面用于CloudMatrix384超级节点之间的扩展通信以及与外部RDMA兼容系统的通信，采用RoCE协议以确保兼容标准RDMA栈。该平面仅由NPU参与，每个NPU提供高达400Gbps的单向 RDMA带宽，并将RDMA流量控制和存储操作隔离。其主要功能包括：在推理过程中高速传输预填充与解码阶段之间的活跃KV缓存数据；支持基于RDMA兼容框架的分布式训练与推理；在多集群部署中实现跨超级节点的低延迟互联。

　　VPC平面通过高速网卡将CloudMatrix384超级节点连接到更广泛的数据中心网络，提供每节点高达 400Gbps的单向带宽。其主要功能包括：处理管理与控制平面操作，如部署、监控和调度； 提供持久存储服务，包括对象存储服务（OBS）、弹性卷服务（EVS）和可扩展文件系统服务（SFS）；支持CPU的工作负载与外部服务之间的通信，例如数据库和用户界面。

　　CloudMatrix384中的每个计算节点集成了8个昇腾910C NPU、4个鲲鹏CPU以及7 个板载UB交换芯片。这12个处理器（8个NPU和4个CPU）通过UB连接到板载交换芯片，在节点内部构建出一个单层的UB平面。每个NPU配置超过392GB/s的单向UB带宽，而每个鲲鹏CPU插槽可提供约160GB/s的单向UB带宽。板载的单个UB交换芯片为超级节点网络中的下一级交换层提供448GB/s的带宽容量。

　　在CPU复合体内部，4个鲲鹏CPU插槽通过全互连的NUMA拓扑结构相互连接，每个CPU都可以直接访问其他CPU所连接的DRAM。其中一块CPU上安装了Qingtian网卡，这是一个专用的数据处理单元（DPU）。这个DPU不仅仅提供了高速网络接口，还承担了一些重要的节点级资源管理功能。

　　驱动层：这是昇腾NPU软件栈的基础部分，由内核模块和固件组成，是操作系统与昇腾NPU之间的低层接口，负责管理设备初始化、资源分配、命令调度以及NPU间通信的建立等关键硬件交互操作。

　　运行时层：这是应用程序在昇腾NPU上的核心执行引擎，负责监督应用生命周期、协调模型计算，并提供全面的设备控制、内存管理等。这些功能主要通过ACL API（Ascend Computing Language API）进行访问。

　　库层：为了加速处理各种不同的AI工作负载，库层提供了一系列高度优化的软件组件。包括领域特定加速库（AOL）、华为集体通信库（HCCL）、预优化算子包（OPP）、神经网络加速的引擎（NNAE）和离线推理的引擎（NNRT）。此外，还支持通过Ascend C等方式进行自定义操作符开发，并能与第三方库集成，以进一步增强其功能。

　　除了核心软件层之外，图引擎（Graph Engine, GE）负责编译和优化来自PyTorch、TensorFlow、MindSpore等框架的计算图。它通过全局图优化技术（如算子融合、内存规划、动态形状处理和调度），连接高层模型与底层执行，有效降低运行开销，提升在昇腾NPU上的执行效率。

　　CANN支持PyTorch、TensorFlow、ONNX 等主流框架，使开发者能够更轻松地在昇腾NPU上部署现有的AI项目。

　　MatrixResource管理超级节点内的物理资源配置，包括基于拓扑感知调度的计算实例分配；

　　CloudMatrix-Infer的架构设计遵循解耦与对等通信（peer-to-peer communication）两大核心原则，将LLM的推理流程拆分为可独立扩展的组件，同时充分利用 CloudMatrix384的高带宽互联能力实现高效的系统协作。

　　CloudMatrix-Infer将系统划分为三个功能子系统：预填充（Prefill）、解码（Decode）和缓存（Caching），即 PDC 架构。每个子系统独立运行，并通过显式的 KV 缓存传输接口进行通信。这种设计使得每个子系统能够根据负载需求弹性扩展，从而最大化资源利用率和端到端性能。各子系统通过CloudMatrix384的高带宽网络紧密连接，形成一个高效集成的推理流水线。

　　预填充集群（Prefill Cluster）：一组专门用于处理用户查询或上下文中的所有 token 的NPU，目的是生成第一个输出Token并构建初始的KV缓存。

　　解码集群（Decode Cluster）：一组独立的 NPU，负责通过读取和更新KV缓存，自回归生成后续Token，直至输出结束标记或达到最大输出长度。

　　缓存集群（Caching Cluster）：一个基于解耦内存池并通过UB网络连接的缓存层，提供两种功能：（i）上下文缓存：通过重用 KV 缓存加速预填充过程；（ii）模型缓存：加快模型块的加载速度，降低冷启动延迟。

　　CloudMatrix-Infer在解码阶段的优化策略主要包括四个方面：

　　CloudMatrix-Infer 基于微批次（microbatch）实现了一条非对称 AIC与AIV切分的解码流水线。该流水线由两个交错执行的流组成，各自负责解码过程中的不同阶段，并根据计算需求配置了不同的 NPU 资源：

　　流1（MoE路径）：负责处理MoE流程中的Gate、Dispatch、MLP 和 Combine 操作。由于涉及计算与通信两个阶段，虽然其计算负载较低，但通信开销较高，因此分配了 8 个 AIC 和 16 个 AIV，仅为流 0 的一半资源。

　　通过这种非对称的资源配置方式，两个流在每层的执行时间接近，从而实现了两个微批次之间的高效重叠执行。此外，系统支持根据运行时条件动态调整两个流的资源分配，这种弹性机制有效维持了延迟平衡，确保在多样化的负载场景下保持稳定的性能表现。

　　多Token预测（Multiple-Token Prediction，MTP）是DeepSeek-R1中使用的一种推测解码技术，其核心思想是在每次解码步骤中预测接下来的 𝑘个token，并在后续步骤中对这些预测结果进行验证。通过在每次解码时生成多个Token，MTP能够显著提升推理吞吐量。然而，传统的MTP由于CPU 与NPU之间需要频繁同步，从而引发pipeline中断，造成性能下降。CloudMatrix-Infer的pipeline MTP优化主要包括两个部分：

　　聚合元数据初始化（Aggregated Metadata Initialization）：在每个解码步骤开始时，统一预计算并批量处理所有元数据张量，并将其直接存储在NPU内存中。这种方式消除了 CPU的重复干预，使NPU上的执行更加流畅，并具备对元数据的感知与处理能力。

　　无CPU干预的NPU内采样（CPU-Free In-NPU Sampling）：将必要的采样操作（如 Token 概率排序、累积和计算、候选过滤等）迁移至NPU上执行，并将其融合进MTP 和LLM验证计算图中。通过在设备端完成整个采样过程，避免了MTP阶段与LLM验证阶段之间的执行停顿，使得各计算图能够连续执行，无需主机干预，从而实现更高效的流水线式推理流程。

　　预填充阶段负责处理输入prompt并生成初始KV缓存，影响大模型推理中首Token生成时间（Time-to-First-Token, TTFT）和系统整体吞吐量。由于该阶段通常为计算密集型任务，因此在预填充过程中实现高效的NPU利用率至关重要。

　　然而，预填充阶段面临诸多挑战，例如因输入序列长度不均导致的负载不平衡问题，以及通信开销较大，这些问题在MoE等复杂模型架构中尤为突出。为应对这些挑战CloudMatrix-Infer提出了三项关键优化措施：

　　CloudMatrix-Infer的混合并行方案将MLA分解为三个阶段，并在每个阶段中采用不同的并行策略：

　　第一阶段包括输入处理和down_proj操作，第三阶段包含o_proj操作。这两个阶段的计算不依赖于Token在序列中的位置信息，因此采用序列并行（Sequence Parallelism, SP）结合序列打包的方式替代传统的纯数据并行。将多个请求的prompt序列拼接成一个“超级序列”，然后将其切片分布到各个SP节点上，从而实现跨 NPU芯片的负载均衡，有效缓解因输入长度不一导致的资源浪费。

　　第二阶段包括q_up_proj、kv_up_proj以及核心的FlashAttention。由于注意力计算与 Token的位置密切相关，采用张量并行（Tensor Parallelism, TP），将注意力头均匀分配至各个NPU芯片，以实现计算负载的均衡分布。

　　在不同阶段之间切换并行策略时，需要对激活数据进行重分片和重新分布。为此，在第一阶段与第二阶段之间插入All-Gather操作，在第二阶段与第三阶段之间插入All-to-All操作，以确保数据能够正确地在各节点间传输。值得注意的是，All-Gather是在维度缩减操作（由down_proj实现）之后执行的，因此作用在尺寸较小的张量上；而All-to-All主要用于重新分发注意力机制中的张量并行分片，这些分片已在TP阶段被拆分，因此每个节点交换的数据量小。在具备高带宽UB平面的CloudMatrix384架构下，这两种通信操作的开销相对较小，不会显著影响整体性能。

　　为缓解专家并行（Expert Parallelism）带来的通信开销，昇腾910C提供了一种异构计算架构，包含三种主要组件：AIC（AI Core），专用于矩阵运算；AIV（AI Vector Core），负责轻量级向量化计算；SDMA引擎，用于高效的数据搬移。为了充分利用这种异构计算架构，为CloudMatrix384设计了一种优化后的基于微批次的预填充流水线：

　　首先，将低强度的辅助计算任务卸载到AIV上执行，使AIC能专注于ATTN和MLP等计算密集型操作。

　　通过将核心计算任务分配给AIC、辅助向量任务交给AIV执行，并由SDMA负责通信，这种面向硬件的任务分配策略显著提升了NPU的利用率和整体吞吐量。

　　在预填充-解码分离的服务架构中，预填充阶段负责生成首个Token并构建相应的KV缓存，随后该缓存必须被传输至解码阶段以启动自回归生成过程。为防止预填充干扰解码的性能，CloudMatrix-Infer 在系统层面提出了三项优化措施：

　　基于RDMA平面的KV Cache传输：在预填充完成后，通过RDMA平面传输KV Cache至指定的解码节点，在物理和逻辑上与UB平面上上的解码操作（如Token分发和专家输出合并）隔离。

　　异步预填充调度：为进一步减少预填充和解码阶段之间的相互干扰，将预填充调度和KV Cache传输任务卸载到解码调度器中的一个专用后台线程中执行。当一个新的推理请求到达时，推理引擎会立即将控制权交还给该后台线程，由其异步地完成以下步骤：

　　（iii）在预填充完成后触发基于RDMA的缓存传输。这种策略确保解码线程不会因预填充计算或数据传输而被阻塞，从而实现连续的解码调度并提升系统响应能力。

　　负载均衡的预填充-解码连接映射：为了避免通信热点，当预填充阶段与解码阶段采用不同的并行配置时采用一种确定性的分组连接机制，确保KV Cache传输负载的均衡分布。

　　高效的缓存策略对于LLM在云环境中的部署至关重要，主要服务于两个关键场景：一是利用历史 KV 缓存优化上下文预填充（Context Caching），二是通过缓存模型参数实现快速模型部署与切换（Model Caching）。华为云的弹性内存服务（EMS）基于CloudMatrix384的UB驱动解耦内存池，实现了对上述两类缓存功能的支持。

　　为了在昇腾910C上实现对DeepSeek-V3/R1等大规模MoE模型的高吞吐、低延迟推理，研究者设计并实现了一种无需训练、具有分层结构的模型权重与激活值INT8量化方案。

　　该方案主要包括混合精度策略、自适应缩放因子搜索、异常值抑制与结构变换、高效的INT8矩阵乘法核以及分块裁剪与误差补偿五项技术，共同构成一个稳健且分层的INT8量化方案，能够在最大化计算效率、降低内存占用的同时，控制模型精度损失。

　　在不同的TPOT（Time-Per-Output-Token）目标、输入Prompt、输出长度下评估CloudMatrix-Infer的解码吞吐量。结果表明，CloudMatrix-Infer能够动态调整批处理大小来满足多样化的延迟约束，在保持高解码吞吐量的同时，也能应对严格的实时推理需求。

　　在16个公开基准上进行对比实验，涵盖英文理解、代码生成、数学推理和中文理解等任务。可以看出，CloudMatrix-Infer在昇腾 910C 上的INT8量化DeepSeek-R1模型，与DeepSeek-R1官方API及其技术报告中发布的结果相当。

　　CloudMatrix384 的“超节点”理念可以在多个维度上进一步扩展，主要包括：统一VPC与RDMA 网络平面，通过整合网络通信以支持大规模AI集群的构建；实现更大规模的超节点，适应未来更大规模和更复杂的工作负载；CPU的物理解耦与资源池化，提高资源利用率和灵活性。

　　随着底层超节点架构的演进，LLM服务系统也需要同步发展。关键方向是从粗粒度解耦（如预填充-解码分离）转向更细粒度的组件级解耦及智能、自适应部署策略。这些方法旨在提升资源利用率、增加吞吐量，并支持日益多样化的异构工作负载和硬件配置。

　　这篇论文首次系统性地介绍了CloudMatrix的设计动机与架构愿景，并详述CloudMatrix384的软硬件体系结构。其次，提出了基于CloudMatrix384实现DeepSeek推理的端到端最佳实践方案，并展示了三项具有差异化优势的核心技术创新：