CloudMatrix384：超节点与大模型系统的协同设计实践

本文参考自“《华为CloudMatrix384 SuperPod论文合集》”，大语言模型的演进正在从三个维度重塑AI基础设施的边界：参数规模跨入万亿级别、混合专家模型成为主流架构、上下文窗口扩展至百万token量级。这三重趋势叠加生产环境中请求长度不一、专家负载不均、流量突发等现实因素，使得传统数据中心架构在通信带宽、内存层次和资源调度上面临根本性挑战。

华为CloudMatrix384正是在这一背景下推出的AI超节点。它并非简单堆叠计算芯片，而是从硬件拓扑到软件栈、从通信原语到服务架构进行全栈重构的一次系统级实践。本文基于CloudMatrix- Infer在DeepSeek-R1模型上的部署经验，梳理其核心设计思想与关键技术决策。

一、硬件拓扑：全对等互联与三平面网络

CloudMatrix384集成了384颗昇腾910 NPU与192颗鲲鹏CPU，通过统一总线（UB）网络实现全对等互联。与传统的“节点内高带宽、节点间低带宽”层次结构不同，UB网络使任意NPU与CPU之间均可直接通信，节点间带宽衰减控制在3%以内，延迟增加不足1微秒。

系统配置了三张物理上独立的网络平面：

UB平面：超节点内部的主数据通路，承载张量并行、专家并行等细粒度通信，以及NPU对远端DRAM的访存请求。

RDMA平面：跨超节点通信通道，用于预填充与解码阶段之间的KV Cache迁移，以及多超节点集群部署。

VPC平面：管理控制面、持久存储访问及外部服务通信。

值得注意，RDMA与VPC平面的分离是出于与现有数据中心兼容的考虑，长期演进方向是将两者统一，以超节点为基本单元构建可用区级AI集群。

昇腾910芯片采用双Die封装，每Die含24个AI Cube核心（矩阵运算）与48个AI Vector核心（向量运算）。AIV核心可通过UB网络直接写入远端NPU片上内存，绕过传统的SDMA引擎启动开销——这一被称为AIV-Direct的机制，是后续MoE通信优化的硬件基础。

二、服务架构：PDC三平面解耦与对等调度

CloudMatrix- Infer采用的服务架构将推理流程拆解为三个独立子系统：预填充（Prefill）、解码（Decode）与缓存（Caching）。三者作为对等的资源池运作，而非围绕某个中心化调度器组织。

这一设计区别于Mooncake、NVIDIA Dynamo等KV Cache中心化架构。在后者中，请求调度必须感知KV Cache的物理位置——因为跨节点访问KV Cache的代价远高于本地访问。调度器需要在负载均衡与缓存亲和性之间做复杂权衡。而CloudMatrix- Infer将KV Cache置于通过UB网络统一访问的分布式内存池中，所有NPU对缓存的访问带宽与延迟一致。调度器不再需要关心数据在哪，只需看哪个实例负载最轻。这极大简化了调度逻辑，也使得资源池的弹性伸缩更加直接。

缓存子系统由弹性内存服务（EMS）承载，提供两层功能：上下文缓存复用历史KV Cache，模型缓存加速模型切换。EMS基于CPU侧DRAM构建分布式内存池，通过UB网络的DMA能力实现NPU对远端DRAM的零拷贝访问，访问带宽远高于传统VPC路径。

三、解码阶段：大规模专家并行的系统化优化

DeepSeek-R1的解码阶段部署了EP320专家并行——320个NPU Die各承载一个专家，其中256个路由专家、32个共享专家、另有32个冗余专家用于负载均衡。每Die本地批量为96时，全局批量达30720。如此规模的并行度，通信开销是首要矛盾。

FusedDispatch与FusedCombine

传统的All-to-All通信需三次数据交换：路由元数据交换、token数据交换、专家输出回传。CloudMatrix- Infer将这三个步骤融合为两个定制算子。其核心决策包括：

AIV-Direct写入：发送端AIV核心直接将数据写入接收端预分配的片上内存缓冲区，绕过SDMA引擎的启动延迟。

早期INT8量化：token数据在发送前即量化为INT8，每个token的通信量从14KB（BF16）降至7.5KB（含scale factor）。

双缓冲静态预分配：为Dispatch与Combine分别预留独立缓冲区（合计约645MB/Die），避免动态内存分配与竞态条件，支持静态图执行。

Token级流水线：将加载、量化/寻址、远端写入三个阶段以单个token为粒度流水，实现计算与通信的重叠。

实测数据显示，在EP256规模下，CANN EP实现相比DeepEP（H800）在Dispatch和Combine上的延迟均更低（Dispatch: 152μs vs 194μs；Combine: 149μs vs 360μs）。

MLA算子融合与NZ格式KV Cache

DeepSeek的MLA机制包含大量细粒度操作（RMSNorm、线性投影、RoPE编码等），逐个下发会累积可观的启动开销。CloudMatrix- Infer将预Attention阶段的操作融合为MLAProlog算子，将Attention核心与周边数据整形融合为Fused Attention算子，将多次内核启动压缩为两次。

KV Cache在昇腾芯片上以NZ格式存储（一种适配Cube核心矩阵乘法的混合布局），写入时即完成格式转换，避免推理时的ND-to-NZ显式转换，节省内存带宽。

微批次解码流水线

CloudMatrix- Infer的解码流水线将Attention路径与MoE路径分为两个Stream，并分配不对称的AIC/AIV资源（Attention路径16 AIC + 32 AIV，MoE路径8 AIC + 16 AIV），使两者在典型负载下均达到约600μs的延迟，从而实现两个微批次的完美重叠。流水线使整体每层延迟降低约10%，吞吐提升6%~9%。

流水线化MTP

DeepSeek-R1的Multi-Token Prediction在朴素实现中需k+1个图依次下发，每次下发均有0.6~0.8ms的CPU-NPU同步开销。CloudMatrix- Infer将k个MTP模块与主模型验证所需的所有元数据（如各阶段的序列长度）在步骤开始时一次性预计算并写入NPU内存，同时将采样操作完全迁移至NPU执行并融合到计算图中。NPU在图与图之间无需等待CPU，实现连续执行。

四、预填充阶段：混合并行与异构流水线

预填充阶段的核心矛盾是请求长度不一导致的负载不均。DeepSeek原生的纯数据并行（DP32）方案中，短请求先完成即闲置，长请求拖慢全局。

CloudMatrix- Infer将MLA计算拆为三阶段，应用不同的并行策略：

阶段1（down_proj）与阶段3（o_proj）：采用序列并行，将多个请求的token拼接后均匀切分至各NPU，消除长度差异影响。

阶段2（Q/K/V投影与FlashAttention）：采用张量并行，将注意力头均匀分布至各NPU。

阶段间通过All-Gather与All-to-All完成数据重分布。由于UB网络的高带宽，这两个额外通信的开销被有效控制。

预填充的微批次流水线则充分利用昇腾芯片的异构计算单元：AIC执行Attention与MLP等重计算，AIV负责Dispatch前的token重排序与元数据生成，SDMA引擎专司All-to-All数据搬运。三者在两个微批次间形成流水，预填充吞吐提升23%~31%。

五、分布式缓存：EMS的内存池化与两级缓存

EMS的核心价值在于利用UB网络将CPU侧DRAM构建为全局共享的内存池，并提供统一的Key-Value存取接口。其设计要点包括：

一致性哈希索引：由集中式Controller维护DHT视图，MP Server各自管理本地数据分片。

NUMA感知的大页内存管理：支持变长分配，降低碎片。

DRAM-SSD两级存储：DRAM为热数据缓存层，SSD（EVS）为持久化层。数据先写EVS保证持久性，DRAM按LRU策略淘汰。由于数据在48个节点间分片，即使数据落在SSD层，NPU也可从多节点并发拉取，聚合带宽达48×400Gbps。

命名空间隔离：支持多租户场景下的逻辑隔离与容量限制。

模型缓存的收益在671B模型加载场景中尤为明显：8个实例并发从OBS加载需2560秒（OBS单桶2.5GB/s带宽严重争用），经EMS共享加载降至320秒，且DRAM占用从8倍模型大小降为1倍。

六、INT8量化：无需重训的精度保持

昇腾910不支持FP8，而DeepSeek以FP8训练。CloudMatrix- Infer的INT8量化方案在不重新训练的前提下，在16个基准测试中保持了与官方API相当的精度。

其策略包括：

混合精度：FFN与Attention中的大矩阵乘用量化为INT8，敏感层（如Norm、Gating）保留BF16。

自适应Scale搜索：对每个权重与激活张量离线搜索最优缩放因子，最小化量化输出与原始输出的差异。

离群值抑制：对MoE门控等存在长尾分布的组件，通过线性变换重分布数值范围。

逐块裁剪与误差补偿：将大权重张量分块，每块独立确定裁剪范围，并插入轻量补偿项。

混合粒度量化：激活按token量化（动态范围），权重按channel量化（静态范围），适配昇腾的整数矩阵乘指令。

七、性能实测

在256颗NPU的配置下，CloudMatrix- Infer在DeepSeek-R1（671B INT8）上的表现如下：

预填充：吞吐6688 tokens/s/NPU，计算效率4.45 tokens/s/TFLOPS，超过SGLang on H100（3.75）与DeepSeek profile on H800（3.96）。

解码：TPOT 49.4ms，吞吐1943 tokens/s/NPU，计算效率1.29 tokens/s/TFLOPS，同样领先对比基线。在更严格的15ms TPOT约束下，系统将批量调至8，仍维持538 tokens/s/NPU。

上下文缓存：90%命中率下，预填充吞吐提升2.28倍，TTFT降低59%。UB平面相较VPC平面在缓存访问上带来最高1.52倍吞吐优势。

通信算子微基准测试显示，在EP256规模下，CANN EP的Dispatch与Combine延迟均低于DeepEP on H800，Combine带宽达103GB/s（H800为40GB/s），这直接得益于UB网络的低延迟与AIV-Direct机制。

八、未来演进方向

论文最后指出了几个明确的演进方向：

更大规模超节点：基于生产trace的仿真表明，超节点规模从384提升至更大尺寸可显著提高资源分配率（平均块大小10.08时，384节点分配率94% vs 224节点91%），且网络成本在满配交换机端口时几乎不变。

CPU物理解耦：当前CPU与NPU共板固定配比，未来倾向将CPU与NPU分置为独立节点类型，按需组合，实现NPU计算密度与CPU内存容量的独立扩展。

组件级解耦：将Attention与MoE进一步拆分为独立微服务，各自部署于最适合的硬件上，并支持独立弹性伸缩。Adrenaline系统已展示了将解码侧的Attention offload至空闲预填充实例的可行性。

网络平面统一：将RDMA与VPC融合为单一UBoE平面，以超节点为单元构建可用区级AI集群。

结语

CloudMatrix384与CloudMatrix- Infer的协同设计提供了一个值得审视的案例：当模型规模与硬件规模同时扩展时，系统软件的瓶颈往往不在于某个算子是否足够快，而在于调度是否被数据位置所束缚、通信是否能与计算充分重叠、资源是否能在不同阶段间灵活流动。解耦——无论是将预填充与解码解耦、将缓存与计算解耦、将Attention与MoE解耦，还是将CPU与NPU解耦——构成了贯穿整个系统设计的主线。这种解耦的代价是增加了系统各部分的协调复杂度，但在超节点规模下，它为吞吐、延迟与资源利用率带来的收益，已经足以覆盖这些额外成本。