4.3 资源高效预填充与混合并行和微批次

预填充阶段负责处理输入提示以生成初始 KV 缓存，对首令牌时间（TTFT）和系统吞吐量有显著影响。鉴于其通常是计算密集型特性，在预填充期间实现高 NPU 利用率至关重要。然而，该阶段经常面临诸如异构输入序列长度导致的负载不平衡以及通信开销等挑战，特别是在像 MoE 模型这样的复杂架构中。为了解决这些问题并最大化 CloudMatrix384 上的效率，我们在 CloudMatrix-Infer 中提出了三个关键优化。首先，我们为 MLA 计算引入了一种_分阶段混合并行方案，以克服传统数据并行（DP）的固有低效性（§4.3.1）。其次，我们提出了一种基于微批次的预填充流水线，利用昇腾 910C NPU 的异构计算和通信单元来最大化延迟重叠并减少争用（§4.3.2）。最后，我们介绍了预填充和解码阶段之间的传输优化，以最小化对解码的干扰（§4.3.3）。

4.3.1. MLA 计算的混合并行

LLM 中的预填充是一个显著的计算瓶颈。尽管 CloudMatrix384 提供了强大的计算能力和高带宽互连，但我们观察到，在昇腾 NPU 上，DeepSeek GPU 部署中最初使用的纯数据并行（DP）（§3.5.1）导致次优的负载平衡和资源利用率。这种低效率源于两个主要原因：

序列长度倾斜（Sequence-Length Skew）： 在实践中，传入的请求通常具有不同的输入序列长度。在典型的 32 路 DP 配置下，分配到较短序列的 NPU 更早完成工作，然后空闲等待那些处理批次中最长序列的 NPU，导致计算周期浪费。

并发不足（Insufficient Concurrency）： 如果正在处理的请求数量少于 DP 度（例如，对于 DP32 少于 32 个请求），一些 DP 分片接收不到工作。延迟处理以累积满 32 个请求的批次会增加 TTFT，而使用部分批次进行则会利用不足 NPU 资源。

为了缓解这些低效率问题，我们为预填充阶段的 MLA 计算引入了一种优化的分阶段混合并行策略，在图 16a 和 16b 中与基本 DP 进行了视觉对比。我们将 MLA 分解为三个阶段，并对每个阶段应用不同的并行方案。

图 16：使用纯 DP 的基本 MLA 流与我们在预填充阶段利用混合并行的提议 MLA 流的比较

第一阶段（包括处理层输入和 down_proj 操作）和第三阶段（包括 o_proj 操作）涉及的计算在并行化策略上本质上不依赖于令牌在序列中的位置。对于这些阶段，我们利用_序列并行（SP）结合序列打包（sequence packing），取代纯 DP。该方法涉及将多个请求的提示序列连接起来，然后将打包的超序列的分段分布在 SP 等级上。因此，来自不同长度请求的令牌以近似均匀的方式分布在 NPU 芯片上，实现有效的负载平衡，不受单个请求长度影响。

第二阶段，包括 q_wp_proj、kv_wp_proj 和核心 FlashAttention 机制，关键依赖于令牌位置进行注意力计算。对于此阶段，我们应用张量并行（TP）以确保跨 NPU 芯片的计算负载均衡分配。在我们的预填充实现中，MLA 通常在没有某些权重矩阵吸收的情况下执行，以增强原始计算效率，允许将其有效地视为标准的 128 头多头注意力（MHA）操作。鉴于 MHA 计算对每个注意力头是独立的，我们通过将这些注意力头均匀分布在 NPU 芯片上来应用 TP。

跨阶段在这些不同并行策略之间转换需要数据重分布。我们在阶段 1 和 2 之间插入一个 All-Gather，在阶段 2 和 3 之间插入一个 All-to-All，以在等级之间正确重新分片和分布激活数据。

图 17 通过四个不同长度输入（输入 0、1、2、3）在四个 NPU 等级上处理的示例说明了这种混合并行数据流

图 17 提供了使用四个不同长度输入（输入 0、输入 1、输入 2、输入 3）在四个 NPU 等级上处理的这种混合并行数据流的说明性示例。最初，在阶段 1，来自这些输入的令牌被打包并使用 SP 分布。每个等级处理打包序列的一个连续片段，确保所有等级接收大致相同数量的令牌，从而尽管原始查询长度不同也能平衡负载。对于阶段 2，在 All-Gather 之后，数据为 TP 重新分布。在这里，每个等级处理来自所有四个输入的所有令牌的一个分片（例如，一个注意力头子集）。图中此阶段的彩色块表示每个等级现在处理每个输入的一部分。最后，在通过 All-to-All 操作从 TP 阶段收集结果之后，阶段 3 执行其计算，数据再次按照类似于阶段 1 的 SP 组织。此示例突显了混合方法如何在 MLA 计算过程中保持负载平衡。

与传统的 DP 策略（图 16a）相比，这种混合并行引入了这两个额外的集合通信步骤。然而，它们的开销被仔细管理。All-Gather 操作在维度缩减步骤（由 down_proj 隐含）之后执行，因此操作在潜在更小的张量上。All-to-All 集合主要重新分布注意力机制的张量并行分片。由于这些分片已经被 TP 度减小了大小，因此在此操作期间每个等级交换的数据远少于可能处理完整未分片张量的集合操作。在具有高带宽 UB 平面的 CloudMatrix384 上，两个算子的通信开销相对较小。

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

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

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

然而，由于架构不匹配，将此策略直接移植到 CloudMatrix384 上的昇腾 910C NPU 效率低下。H800 上的流水线通常保留其部分流式多处理器（SM）用于通信任务，实现并发但减少了可用的计算资源。相比之下，昇腾 910C 提供了异构计算结构，包括用于矩阵操作的 AIC、用于轻量级计算的 AIV 以及用于数据移动的 SDMA 引擎，支持更细粒度的、特定角色的任务分配。

为了充分利用这种异构性，我们为 CloudMatrix384 引入了一种优化的基于微批次的预填充流水线，如图 18b 所示。我们的设计编排了跨 AIC、AIV 和 SDMA 子系统的工作负载分配，如下所示：

首先，我们将低强度的辅助计算卸载到 AIV，释放 AIC 专注于计算密集型算子，如 ATTN 和 MLP。诸如分发前令牌重新排序和元数据生成（表示为 DispatchCompute）以及组合后专家输出累积（表示为 CombineCompute）等任务被分配给 AIV。这些操作是轻量级且可向量化的，非常适合 AIV 执行。如图 18b 所示，当 AIC 为另一个微批次执行核心计算时，AIV 可以为一个微批次处理 DispatchCompute，实现细粒度的算子级重叠。

其次，我们将高容量数据传输（例如用于 MoE 分发和组合的 All-to-All 通信）显式路由到 SDMA 引擎。通过将这些内存操作隔离到专用的传输流，我们防止了与 AIC 和 AIV 执行的争用。这种隔离确保计算密集型操作可以不受干扰地进行，并且通信延迟被并发执行的 AIC/AIV 任务所重叠。鉴于预填充工作负载由密集矩阵操作和通信主导，通过 SDMA 显式引导数据流在保持峰值 NPU 吞吐量方面起着关键作用。

这种硬件感知的任务分配，即 AIC 用于主要计算，AIV 用于辅助向量任务，SDMA 用于通信，提高了并发性并最小化了执行停滞。

此外，这种设计明显不同于我们的解码阶段流水线（§4.2.3），由于不同的延迟和吞吐量要求，通信逻辑在那里与计算流更紧密地耦合。在预填充中，需要处理更长的序列和更大的微批次，使其对计算饱和和带宽争用更敏感。因此，通过专用执行单元分离关注点并在算子级别重叠任务更符合 CloudMatrix384 的性能特征。

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 度来加速长输入序列的处理。使用具有单个潜在头的 MLA 的 DeepSeek-R1 模型的一个关键特征是，TP 组（tp_rank）内的所有等级持有相同的、完整的 KV 缓存副本。

虽然这种数据冗余提供了灵活性，但如果管理不当，也会带来创建网络热点的风险。如果一个解码实例的所有等级都从同一个源预填充等级拉取 KV 缓存，那么该单一网络链路将成为严重的瓶颈。为了防止这种情况，我们开发了一种确定性分组连接机制以确保均衡的传输负载。此映射方案计算如下：

令 prefill_tp_sizeprefill_tp_size 为预填充实例的 TP 大小。

令 decode_tp_sizedecode_tp_size 和 decode_dp_sizedecode_dp_size 分别为解码实例的 TP 和 DP 大小。

令 decode_tp_rank_iddecode_tp_rank_id 和 decode_dp_rank_iddecode_dp_rank_id 为特定解码进程的 TP 和 DP 等级 ID

和 .

和prefill_tp_rank_id = (group_id×decode_tp_size)+decode_tp_rank_id。此方案确保所有预填充-解码链路之间均衡的连接拓扑，避免通信热点并维持高吞吐量。

总之，这三种技术实现了从预填充到解码的无缝、低干扰切换，在解耦架构下保持系统效率并确保大规模 LLM 的高性能服务。

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

在云环境中高效部署 LLM 关键依赖于高性能缓存策略。这些策略对于加速数据访问至关重要，主要针对两个关键场景：用于优化上下文预填充的历史 KV 缓存（上下文缓存），以及用于促进快速模型部署和切换的模型。

参数（模型缓存）。这些缓存层的有效实施显著减少了冗余计算，削减了模型加载延迟，并提高了整体系统性能。支持此类缓存功能需要一个高性能、大容量和低延迟的中间内存层，战略性地定位以弥合 NPU 高速内存和较慢持久存储服务（例如对象存储服务（OBS））之间的性能差距。

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

4.4.1 解耦内存池化

EMS 缓存服务的核心是一个逻辑上解耦的内存池，由 CloudMatrix384 内跨节点聚合的 CPU 连接 DRAM 组成。该池充当历史 KV 缓存和模型参数的统一高性能内存基础。该内存池的一个显著特征是其与 UB 网络平面的深度集成，实现对分布式 DRAM 的高效、统一内存访问，并允许 NPU 快速检索必要的数据，无论其物理位置如何，促进了 §4.1 中提出的点对点服务架构。该设计的有效性关键由以下 UB 的硬件能力驱动：1) 高速点对点结构： UB 网络支持快速的节点间数据传输，允许任何 NPU 或 CPU 高效访问其他节点上的 DRAM；2) UB 上的 DMA： 通过直接内存访问（DMA）实现零拷贝数据传输，绕过 CPU 仲裁并减少传输延迟；3) 低级内存原语： UB 协议公开了用于远程内存注册和访问的原语，允许软件栈维护全局内存视图。

如图 19 所示，此解耦内存池由专用的三组件软件架构管理：

1. MP SDK： 嵌入在 AI 应用程序的进程中，它将上层缓存请求转换为分布式内存操作，暴露键值存储风格的 API，如 Put 和 Get；

2. MP 控制器（Controller）： 一个集中的控制平面，维护元数据（例如分布式哈希表（DHT）视图、命名空间），协调操作并编排资源管理；

3. MP 服务（Server） ： 部署在DRAM-contributing 的节点上，管理本地内存，处理分层（tiering）和恢复，并参与负载平衡。

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

这些软件组件与 UB 平面的相互作用实现了几个关键的操作机制和系统特性：

分布式数据索引和放置。 为了确定键值对在解耦内存池中的放置位置并高效定位它，内存池采用全局一致性哈希索引。该索引将输入键映射到负责的 MP 服务器节点。一个 DHT 视图支撑此方案，其整体一致性和元数据由 MP 控制器管理。各个 MP 服务器通过管理其本地数据部分并响应路由请求来参与 DHT。MP SDK 利用此机制将密钥分发到特定节点和 DRAM 地址以进行数据访问。

高性能远程内存访问。 UB 平面支持并由软件组件管理的一个关键功能是 NPU 对远程 DRAM 的直接、高性能访问。这涉及在 MP 服务器实例和 MP SDK 客户端初始化期间建立的内存映射和注册过程。协商控制消息以交换指定用于池的 DRAM 段的物理地址范围，然后在 UB 结构和 MP 控制器处注册。此跨节点映射能力利用了 CloudMatrix384 超级节点对全局统一内存寻址和路由的支持，允许 UB 交换机将 NPU SDMA 驱动的访问请求直接路由到目标 MP 服务器管理的 DRAM。

细粒度本地内存管理。 为了有效管理其分配的 DRAM 段并应对来自可变大小数据对象（如 KV 缓存块或模型分片）的碎片，每个 MP 服务器采用多粒度内存分配系统。一个关键方面是使用大页（huge pages）来减少内存片分配频率和相关管理开销。对于数据分配，系统支持可变长度内存分区，与固定大小分配器相比显著提高了内存利用率。此外，MP 服务器允许在其管理的 DRAM 内不同粒度之间进行动态内存流动，基于工作负载相关的使用模式增强资源效率。

具有持久性和恢复功能的内存分层。 为了管理存储成本并确保数据持久性，解耦内存池集成了一个基于 SSD 的分层，由 MP 服务器管理。该层利用云提供的弹性卷服务（EVS）SSD 来提供大容量、持久存储。基于 EVS 的分层的替代方案是使用云的可扩展文件系统服务（SFS），但这会产生更高的成本。在此层次结构中，分布式 DRAM 池充当位于 EVS 层之上的快速缓存，实现对常用数据的低延迟访问。持久性通过将所有数据写入 EVS 来强制执行。由于 EVS 卷容量有限，系统采用本地驱逐策略，例如最近最少使用（LRU），在需要时释放空间。MP 服务器独立管理 DRAM 驻留，使用其自己的 LRU 驱逐逻辑和 DRAM 层的容量阈值。从 DRAM 驱逐的数据仍然持久存储在 EVS 中，除非后来被 EVS 自身的空间管理例程移除。这种分层结构确保了容错能力：如果内存中的数据丢失（例如由于节点故障），并且尚未被 EVS 自身驱逐，则可以从 EVS 层恢复。

重要的是，虽然通过擎天卡访问 EVS 的每节点带宽相对适中，通常低于 400 Gbps，但 CloudMatrix384 中的解耦内存池聚合了所有 48 个节点的带宽，产生高达 48×400 Gbps 的总 EVS 访问带宽。由于数据被划分为细粒度块并分布在节点间，NPU 可以通过高带宽 UB 平面同时从多个节点获取这些块。这使得即使请求的数据驻留在 EVS 层，也能实现高聚合负载带宽，通过系统范围的并行有效地分摊每节点 EVS 访问的限制。

命名空间隔离。 为了支持多租户和管理不同上下文缓存和模型缓存实例的数据，解耦内存池提供 KV 命名空间隔离。这主要由 MP 控制器编排，它管理命名空间的创建、删除和元数据。每个 MP 服务器都知晓活动命名空间，并确保数据操作被限制在指定的命名空间内，在共享池内提供逻辑数据隔离和容量使用限制。

总之，CloudMatrix384 的 UB 驱动解耦内存池为 LLM 推理提供了一个高吞吐量、可扩展的内存层。通过将硬件级点对点访问与分布式内存管理软件相结合，系统支持对 KV 缓存和模型参数的高效缓存，构成了 EMS 的支柱。

4.4.2. 上下文缓存

LLM 推理的预填充阶段负责处理输入提示并生成初始 KV 缓存，是计算密集型的，特别是对于长序列。通过重用先前请求的历史 KV 缓存可以获得显著的性能提升。这在涉及重复前缀的场景中特别有价值，例如多轮对话、少样本提示（few-shot prompting）和重复的系统指令。在我们的架构中，上下文缓存指的是用于存储和高效检索这些历史 KV 缓存的专用机制。

上下文缓存由华为云上的服务 EMS 实现。EMS 利用 UB 驱动的解耦内存池（§4.4.1）为历史 KV 缓存创建一个共享的分布式存储库。这些缓存根据模型特性和 UB 传输效率组织成分页块（例如，每块 128-512 个令牌）。服务集群中的所有 NPU 都可以通过 EMS API 访问或贡献于此缓存。

索引、去重和检索。 EMS 向上层 LLM 服务框架提供专门的上下文缓存 SDK（即 API 层）用于存储和检索历史 KV 缓存块。在内部，此 EMS SDK 利用 MP SDK（§4.4.1）的 API 与底层分布式 DRAM 和分层存储交互。每个 KV 缓存块与一个唯一的哈希键相关联，该哈希键源自其令牌序列，并辅以前缀哈希以实现内容可寻址索引。这允许快速查找和去重：相同的 KV 块存储一次并在请求间重用。

分配给上下文缓存的解耦内存池部分受容量限制。当接近这些限制时，MP 服务器（§4.4.1）触发将较冷的 KV 缓存块从 DRAM 驱逐到 EVS 支持的 SSD 层。如果 SSD 容量也受限，则基于 LRU 类策略完全删除数据。此驱逐过程确保在统一池内上下文和模型缓存之间公平高效地共享资源。

与 PDC 解耦的交互。 EMS 与解耦的预填充和解码流水线紧密集成：

预填充 - 重用和存储： 收到新请求时，预填充引擎使用输入前缀的哈希查询 EMS 以识别可重用的 KV 缓存块。如果找到，这些块通过 UB 平面获取并直接加载到 NPU 内存中，绕过冗余计算。引擎然后处理剩余的后缀并生成相应的 KV 缓存块。这些新块被异步存储回 EMS，以便在未来的请求中重用，而不会阻塞正在进行的计算。

解码 - 选择性缓存存储： 解码阶段生成的 KV 缓存可用于非推理模型重用，但不适用于像 DeepSeek-R1 这样的推理模型。这些推理模型发出中间推理令牌，后跟最终响应令牌。中间令牌通常在后续轮次中不会被重新摄取，因此当包含在后续提示中时，最终响应令牌的位置会发生变化。这种位置变化由于位置敏感的注意力而破坏了缓存有效性。因此，解码生成的缓存通常被排除在存储之外。然而，如果系统采用容忍位置变化的近似 KV 重用技术，有选择地存储最终响应令牌的缓存块可以提供性能优势。

4.4.3. 模型缓存

现代 LLM 服务基础设施必须高效支持大小、架构和任务专业化各异的多样化模型组合。这些基础设施还必须适应动态模型切换以响应波动的服务需求和持续的模型更新。然而，从持久存储（例如对象存储服务（OBS））将具有数十亿参数的 LLM 加载到 NPU 内存会产生显著的延迟。例如，从 OBS 加载具有 671B 参数的 DeepSeek-R1 模型（假设每个桶的标准访问带宽为 2.5 GB/s）需要超过五分钟。此延迟严重限制了动态模型切换的实用性，并损害了服务响应性，特别是在模型更新或 A/B 测试期间。因此，快速缓存机制不仅对于减轻这些开销至关重要，而且对于确保响应迅速、敏捷的模型部署也必不可少。

为了应对这些挑战，我们纳入了由 EMS 提供的模型缓存。其核心是，EMS 利用 UB 驱动的解耦内存池（§4.4.1）作为高性能分布式缓存基础，支持跨系统的低延迟模型访问。为了与上层服务框架集成，EMS 提供了模型缓存 SDK，公开用于从缓存中检查、预取和加载模型的 API。具体来说，SDK 允许用户查询模型当前是否缓存在 EMS 内存池中，启动从持久存储到 EMS 的模型块异步预取，以及触发模型块加载到目标 NPU 内存以进行推理。当模型已部分缓存时，预取充当提示，将块从较慢层（例如 SSD）提升到较快层（例如 DRAM），进一步优化访问延迟。

缓存管理策略。 在内部，EMS 将每个模型分解为内存块，并将它们作为键值条目存储在解耦内存池中。集中的元数据服务跟踪从每个模型到其相应块集的映射，实现细粒度的分片模型加载和推理期间的高效检索。EMS 通过跨准入、驱逐和版本控制的协调策略管理缓存的模型块。对于准入和预取，EMS 基于应用程序提示和观察到的访问模式将模型块加载到 DRAM 或 SSD 层。驱逐由解耦内存池的原生基于 LRU 的策略处理，由于模型块的连贯访问行为，该策略通常在模型级粒度运行，即整个模型或大段一起被驱逐，避免碎片状态。对于版本控制，EMS 通过维护版本感知标识符并将每个模型与其相应的块集关联，确保 NPU 始终执行正确的模型版本。当部署新版本时，服务框架显式请求它，而陈旧版本通过自然缓存驱逐逐渐淘汰。

UB 驱动解耦内存池的模型缓存优势。 EMS 利用 UB 驱动解耦内存池为模型缓存实现两个关键优势。首先，高带宽、低延迟的 UB 平面促进了从 EMS 内存层（例如 DRAM 或 SSD）到 NPU 内存的模型块快速传输，大幅减少模型加载延迟。其次，EMS 使用统一的、集群范围的内存池，消除了数据冗余，允许多个 NPU 实例共享单个缓存模型版本。此设计减少了对持久存储带宽的压力以及缓存所需的累积 DRAM 和 SSD 占用空间，从而提高了可扩展性和资源效率。

表 2. 在 CloudMatrix384 内将 671B INT8 模型（约 671GB 数据大小）加载到 8 个模型实例的模型加载策略性能比较（模型最初存储在带宽为 2.5GB/s 的 OBS 桶中。我们考虑两种场景：1) 模型加载：所有 8 个实例使用不同的加载策略同时加载同一模型以比较其加载延迟和 DRAM 开销；2) 模型切换：有 8 个不同的活动模型，当一个实例随机切换到这 8 个模型中的一个时，我们比较模型切换延迟和缓存命中率。延迟是说明性的，代表定义场景。 ¹ 当 8 个实例同时从共享 OBS 桶加载同一模型时，反映了显著的争用。 ² 假设 EMS 的容量正好容纳所有 8 个不同的 671B 活动模型版本

表 2 通过对具有 INT8 量化的 671B 参数模型的不同模型加载策略进行性能比较来量化这些优势。当不使用缓存时，所有 8 个同时从 OBS 加载同一模型的实例，由于共享的 2.5 GB/s OBS 带宽上的严重争用，每个实例的冷启动延迟约为 2,560 秒。本地 DRAM 缓存在此冷启动延迟上没有改进，因为每个节点仍然独立地从 OBS 获取完整模型。相比之下，EMS 通过内存池启用共享加载并跨实例重用模型块，将冷启动延迟减少到仅 ~320 秒。

除了延迟之外，EMS 还提高了内存效率。本地 DRAM 缓存导致 8 倍的 DRAM 开销，其中 8 个实例中的每一个都存储一个完整的模型副本。相比之下，EMS 仅需要 1 倍的 DRAM 占用空间来服务所有实例，同时保持相同的 ~5 秒热启动延迟。在模型切换场景中，EMS 实现了 100% 的缓存命中率和平均 ~5 秒的切换延迟，显著优于本地 DRAM 缓存（后者仅产生 12.5% 的命中率和 ~281 秒的延迟）。这些结果突显了 EMS 作为在大规模推理环境中最小化模型访问延迟和内存资源开销的高效解决方案。

4.5 INT8 量化

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

混合精度策略。 我们的量化方案采用混合精度策略，根据其对整体性能（例如计算负载、内存访问）的影响与对数值精度的敏感性之间的权衡，对模型中的不同算子进行分类。关键执行路径中最计算密集的操作，如前馈网络（FFN）和注意力机制中的大型矩阵乘法，被量化为 INT8 以利用最高吞吐量。相反，对量化误差更敏感但构成整体内存访问或计算负担较小部分的子模块或特定操作（例如某些归一化层或关键门控机制）使用 BF16 或 FP32 保留更高精度。这种灵活的分区确保了整个模型可以在统一的硬件流水线中高效执行，同时避免了关键、数值敏感路径中的精度瓶颈。

自适应缩放因子搜索。 有效的量化需要仔细对齐浮点值的动态范围到 INT8 整数的有限范围。对于每个目标为 INT8 量化的权重张量和激活张量，我们引入了一个轻量级的自适应缩放因子搜索过程。此过程自动确定最优缩放因子 s∗，以最小化量化误差，有效对齐量化前后的值分布。缩放搜索被表述为一个优化问题：

离群值抑制和结构转换。 大型模型中的某些组件，特别是 MoE 架构中的特定专家子网络或门控结构，可能表现出具有长尾或显著离群值的激活或权重分布。这些离群值可能不成比例地影响量化范围，导致大多数值精度的损失。为了缓解这种情况，我们采用了一种涉及结构转换的离群值抑制技术。在量化之前，引入简单的线性变换（概念上类似于应用学习的正交基旋转或将缩放因子吸收到前/后层中）。这些变换旨在将极值重新分配到更平衡和量化友好的范围内，而不改变层的底层数学函数。通过减少离群值的影响，此方法最大程度地降低了大量化误差的风险，并抑制了通过网络后续的错误放大。

高效的 INT8 矩阵乘法内核。 INT8 量化的性能优势关键依赖于高度优化的执行内核。我们为矩阵乘法利用混合粒度量化方案：激活（X）按每个令牌量化（动态范围按令牌确定），而权重（W）按每个通道量化（通常按输出通道，每个通道静态范围）。此方法平衡了适应快速变化的激活统计数据的需要与保持稳定权重表示的需求。这种混合粒度，结合权重和激活的精心对齐的内存布局，允许充分利用昇腾 NPU 上可用的专用整数矩阵乘法指令。与等效的 BF16 或 FP16 实现相比，这些优化的 INT8 内核在相同硬件上可以提供数倍的推理吞吐量提升，同时确保任何精度损失保持在应用可接受的容忍范围内。

块级裁剪和误差补偿。 为了进一步优化精度并处理大型权重张量内的局部变化，我们实现了块级裁剪和误差补偿。对权重进行统计分析并划分为较小的块。对于每个块，建立一个独特的、可容忍的裁剪范围。该范围可以通过优化裁剪的缩放因子 α 来确定（例如，

这里， (W;α)表示使用裁剪因子 α量化块内的权重 W。同时，轻量级的误差补偿项被策略性地插入到推理计算图中。这些项旨在抵消或部分纠正量化在不同模型点引入的系统性误差，从而减轻量化噪声对最终模型输出的累积影响。该方法的一个显著优势是它不需要修改原始模型训练过程，也不依赖于额外的微调阶段，便于快速部署和迭代。

总之，这五种策略形成了一个健壮的分层 INT8 量化框架，使 DeepSeek-V3/R1 等海量模型能够在昇腾硬件上实现高性能推理，仔细平衡计算效率与模型精度保持。

5. 评估

在本节中，我们对先前在 §4 中详述的、部署在 CloudMatrix384 上的提议服务系统 CloudMatrix-Infer 进行全面性能评估。我们首先概述评估中使用的通用实验设置（§5.1）。随后，我们分析性能和功效的几个关键方面：包括整体系统性能（§5.2）；使用我们的 INT8 量化方案实现的推理精度（§5.3）；一项消融研究，调查所采用的不同优化技术的具体贡献（§5.4）；最后，考察关键底层算子的性能（§5.5）。

5.1 实验设置

我们的评估在华为云 ModelArts Lite（集群模式）服务提供的华为 CloudMatrix384 超级节点上进行。具体来说，我们使用来自单个 CloudMatrix384 的 256 个昇腾 910C NPU 及其关联的主机鲲鹏 CPU 的配置。服务系统由华为和 SiliconFlow² 共同优化的 LLM 推理引擎组成，部署了必要的华为 CANN 软件包。华为云中的弹性内存服务（EMS），如 §4.4 所述提供分布式缓存能力，已在分配的计算节点上预部署。整个部署遵循我们提出的具有 PDC 解耦的点对点服务架构（§4.1），每个逻辑集群的具体配置如下：

解码集群： 我们部署一个解码实例，使用 160 个昇腾 910C NPU（跨越 20 个计算节点，产生 320 个 NPU 芯片）。该实例对稀疏 MoE 层采用 320 路专家并行（EP320）。对于其他组件，如 MLA 和密集 FFN 层，在 NPU 芯片上使用 320 路数据并行（DP320）。在这 320 个 EP 等级中，我们在每个等级部署一个专家实例。专家配置包括 32 个共享专家副本、256 个不同的路由专家以及额外的 32 个冗余路由专家以促进专家并行负载平衡（EPLB）。

预填充集群： 预填充集群包含 6 个预填充实例，每个实例分配 16 个昇腾 910C NPU（每个实例两个计算节点，产生 32 个 NPU 芯片）。预填充集群总共使用 96 个 NPU。每个预填充实例对稀疏 MoE 层采用 32 路专家并行（EP32）。预填充实例内的 MLA 组件使用 §4.3.1 详述的混合并行策略。在每个 32 等级的预填充实例中，我们配置每个等级 10 个专家，包括 1 个共享专家、8 个路由选择专家和 1 个冗余路由专家以实现有效的 EPLB。

缓存集群（EMS）： EMS 提供的分布式缓存通过利用构成预填充和解码集群的所有物理计算节点的主机 CPU DRAM 实现。这些 32 个计算节点（20 个用于解码集群 + 12 个用于预填充集群）上的鲲鹏 CPU 及其关联的 DRAM 共同构成了 UB 驱动的解耦内存池。

EMS 利用此池进行模型缓存（§4.4.3）和上下文缓存（§4.4.2）。从所有 NPU 访问此共享内存池由 CloudMatrix384 的高速 UB 平面实现。

此实验配置作为后续章节精度和性能评估的基础。评估的 DeepSeek-R1 模型是 671B 参数版本，已量化为 INT8（§4.5）以在昇腾 910C NPU 上执行。

5.2 整体性能

在本节中，我们评估 CloudMatrix-Infer 相对于领先基线的整体性能，测量原始吞吐量和硬件效率（tokens/s/TFLOPS），包括预填充和解码阶段。我们将这些指标与 DeepSeek 在 NVIDIA H800 GPU 上服务 [12] 和 SGLang 在 NVIDIA H100 GPU 上 [53] 的公开性能数据进行比较。我们的评估独立评估预填充和解码阶段的性能，反映比较来源中报告的实验设置以便清晰分析。

预填充吞吐量。 我们首先检查预填充吞吐量，这是高效处理输入提示的关键因素。表 3 详细列出了这些每加速器的比较。有效的 MoE 模型服务在预填充期间也显著依赖于强大的 EPLB，正如 SGLang 的分析所强调 [53]。DeepSeek (Profile) 数据具有高吞吐量（每个 GPU 7,839 tokens/s），可能反映了接近理想专家负载平衡下的性能。为了提供与此类优化场景可比较的分析基线，表 3 包括 SGLang 和 CloudMatrix-Infer 的完美 EPLB（Perfect EPLB）配置。这些结果代表了在完美负载分布跨专家的理想化假设下的预测性能。

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

在其默认配置中，CloudMatrix-Infer 处理每个 NPU 5,655 tokens/s。考虑到每个昇腾 910C NPU 的计算能力为 1,504 TFLOPS (INT8)，这产生了 3.76 tokens/s/TFLOPS 的计算效率。这比 NVIDIA H100 上的 SGLang 默认配置（3.18 tokens/s/TFLOPS）效率显著更高，尽管后者的原始吞吐量略高。在测试的理想化“完美 EPLB”条件下，CloudMatrix-Infer 达到每个 NPU 6,688 tokens/s，转化为 4.45 tokens/s/TFLOPS 的效率，超过了 H100 上的 SGLang 理想效率（3.75 tokens/s/TFLOPS）和 H800 上的 DeepSeek profile（3.96 tokens/s/TFLOPS）。这些比较突显了 CloudMatrix-Infer 的强大潜力，而我们的默认结果和理想结果之间的差距凸显了负载平衡算法进一步改进的机会。

解码吞吐量。 接下来，我们分析自回归解码阶段的性能，如表 4 详述。我们评估目标为低于 50 ms 的每输出令牌时间（TPOT）SLO 的绝对解码吞吐量（tokens/s），并评估按加速器计算能力归一化的吞吐量（tokens/s/TFLOPS）作为计算效率的指标。值得注意的是，SGLang (模拟 MTP) 和 CloudMatrix-Infer 配置都使用多令牌预测（MTP），假设单个推测令牌的有效接受率为 70%。

表 4 DeepSeek-R1的总体解码吞吐量

配置批次大小为每个 NPU 96，KV 缓存长度为 4,096 令牌，CloudMatrix-Infer 实现了优异的 TPOT 49.4 ms。在绝对系统吞吐量方面，CloudMatrix-Infer 在批次大小为 96 时产生每个 NPU 1,943 tokens/s。这高于 DeepSeek (博客) H800 基线（每个 GPU 1,850 tokens/s）。虽然在数值上低于 H800 上的 DeepSeek (Profile)（每个 GPU 2,325 tokens/s）和 H100 上的 SGLang（每个 GPU 2,172 tokens/s），但后两个系统是使用更大的批次大小 128 进行基准测试的。每 TFLOPS 吞吐量指标提供了对系统计算效率的进一步洞察。CloudMatrix-Infer 实现了最高的计算效率（1.29 tokens/s/TFLOPS），高于 H100 上的 SGLang（1.10 tokens/s/TFLOPS）、H800 上的 DeepSeek (博客)（0.93 tokens/s/TFLOPS）和 H800 上的 DeepSeek (Profile)（1.17 tokens/s/TFLOPS）。这表明我们的服务解决方案在解码期间有效利用了 CloudMatrix384 的可用计算能力。

我们还评估了 CloudMatrix-Infer 在不同 TPOT 服务级别目标（SLO）和不同提示及输出长度下的解码吞吐量，如表 5 所示。结果显示出明显的趋势：解码吞吐量随着组合提示和输出长度的缩短而显著增加。例如，当提示和输出长度各为 1,024 令牌时，解码吞吐量达到每个 NPU 2,733 tokens/s。当提示长度增加到 2,048 令牌，输出减少到 256 令牌时，此值降至每个 NPU 2,360 tokens/s。这种改进归因于更短的总长度减少了每个请求所需的 KV 缓存空间，从而允许更大的批次大小。此外，随着 TPOT SLO 变得更加严格，从 50 ms 到 15 ms，CloudMatrix-Infer 相应地调整批次大小以满足延迟目标。在宽松的 50 ms SLO 下，CloudMatrix-Infer 支持批次大小 96 并实现每个 NPU 1,943 tokens/s 的吞吐量，同时满足延迟约束。当 SLO 收紧到 30 ms 和 15 ms 时，批次大小分别减少到 24 和 8，导致更低的吞吐量，分别为每个 NPU 974 和 538 tokens/s。这些发现证明了 CloudMatrix-Infer 通过动态调整批次大小以满足不同延迟约束的能力，即使在严格的实时需求下也能保持高解码吞吐量。

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

5.3 准确性

为了全面评估量化为 INT8 并部署在 CloudMatrix384 上的 DeepSeek-R1 的推理精度（以下简称 DeepSeek-R1 (INT8)），我们基于广泛使用的基准测试进行了广泛测试。我们的评估重点是将 SilliconFlow 实现的 INT8 量化（§4.5）的精度与官方 DeepSeek-R1 API [10] 的结果及其技术报告 [13] 中发布的结果进行比较。鉴于原始的 DeepSeek-R1 技术报告未完全公开每个基准测试的所有测试参数，这可能导致直接复现存在差异，我们采用了针对实时 DeepSeek-R1 API 的并行评估方法，以确保对实际性能进行公平直接的比较。

我们的评估套件源自 DeepSeek-R1 技术报告和其他广泛使用的基准测试中的广泛列表，包含 16 个不同的基准测试，用于多方面的评估。排除的包括 AlpacaEval 2.0 [17] 和 Arena-Hard [36]，因为它们依赖 GPT-4 进行评估（超出了我们当前的设置），以及 CodeForces³，因为缺乏现成的自动化评估脚本。选定的基准测试涵盖了广泛的能力：英语（MMLU [23], MMLU-Pro [9], DROP [16], IFEval [58], GPQA Diamond [50], SimpleQA [44]）、代码生成（LiveCodeBench [31], HumanEval [7]）、数学（AIME 2024 [3], MATH-500 [24], CNMO 2024 [1], MGSM [51]）和中文（CLUEWSC [55], C-Eval [25], C-SimpleQA [22], C-MMLU [35]）。我们相信这个精选集为评估精度提供了坚实的基础。

为了评估的一致性，诸如 MMLU、DROP、MGSM、GPQA Diamond、HumanEval、MATH-500、SimpleQA 和 C-SimpleQA 等基准测试的提示来源于 simple-evals 框架。其他，包括 CMMLU、C-Eval、LiveCodeBench、IFEval 和 CLUEWSC，使用 OpenCompass 框架⁴。遵循 DeepSeek-R1 技术报告中的方法，MMLU-Pro、C-Eval 和 CLUEWSC 在零样本（zero-shot）设置下测试，而其他测试集遵循其原始协议。数学竞赛基准测试（AIME 2024 和 CNMO 2024）各经过 32 次重复测试运行以准确估计其 pass@1 指标。对于官方评估报告使用各种 GPT-4 版本的MATH-500、SimpleQA 和 C-SimpleQA 基准测试，我们使用 Qwen2.5-72B-Instruct⁵ 作为评分模型来评估 DeepSeek-R1 (INT8) 和 DeepSeek-R1 API 的输出。虽然此选择确保了本研究的内部一致性，但在将我们的分数与依赖基于 GPT-4 评分的 DeepSeek-R1 技术报告中的分数比较时，可能会导致差异。关键生成参数包括温度 0.6 和 top-p 0.95，与 DeepSeek-R1 技术报告 [13] 中指定的设置一致。

比较精度结果呈现在表 6 中。总体而言，我们在昇腾 910C 上的 DeepSeek-R1 (INT8) 实现展示了与官方 DeepSeek-R1 API 和原始技术论文中报告的指标基本相当的性能。这表明为在昇腾 910C 上部署而应用的 INT8 量化在广泛的任务范围内有效保留了模型的能力。

表 6. DeepSeek-R1 在昇腾 910C 上使用 INT8 量化的精度与官方 DeepSeek-R1 API [10] 以及 DeepSeek-R1 技术报告 [13] 中报告的结果在多个基准测试上的比较（已排除测试配置被认为不一致的基准测试结果）

5.4 消融研究

为了理解 CloudMatrix-Infer 中采用的关键优化技术的个体贡献和有效性，我们进行了一系列消融研究。这些研究分离了我们的基于微批次的流水线策略（用于预填充和解码阶段）、多令牌预测（MTP）机制以及基于 EMS 的上下文缓存的影响。

5.4.1 基于微批次的流水线

此消融研究量化了基于微批次的流水线策略的性能影响，通过比较启用和禁用这些微批次优化时的系统性能。

解码流水线。 我们首先评估了解码阶段的基于微批次流水线（先前在 §4.2.3 中详述）。消融比较了系统在有和没有此微批次优化下的性能。

图 20：启用和未启用基于微批次的流水线时的解码吞吐量和每层延迟分解。所有请求的 KV 缓存长度为 4,096 令牌。在 (b) 中，“总体”带微批次表示重叠两个微批次（微批次 0 和微批次 1）后的每层延迟

图 20a 展示了不同批次大小下的解码吞吐量。我们观察到，启用基于微批次的流水线将批次大小为 64、96 和 128 时的解码吞吐量分别提高了 5.8%、9.4% 和 6.9%。尽管有益，但与为其他平台报告的潜在改进相比（例如 SGLang [53] 在 NVIDIA H100 集群上引用 35%），这种增益相对温和。这种差异主要归因于 CloudMatrix384 上 MoE 分发和组合通信开销固有的较低，这得益于其高性能 UB 平面（如第 5.5.1 节所述），而 NVIDIA GPU 集群通常使用 RDMA。在 UB 平面上较小的 MoE 通信停滞下，通过微批次隐藏通信的改进上限自然对 CloudMatrix384 更有限。

图 20b 提供了批次大小为 96 时解码执行的每层延迟分解。它显示，尽管像门控（Gating）、分发（Dispatch）和 MoE 这样的阶段的单个微批次执行延迟由于每个流的计算资源减少（例如 AIC 从 24 减少到 16）而略有增加，但基于微批次的流水线显著受益于整体性能。这是通过有效地为不同的微批次重叠注意力路径（流 0）和 MoE 路径（流 1）实现的，导致整体每层延迟减少约 10%，并相应显著提高了端到端解码吞吐量。

预填充流水线。 接下来，我们检查了提出的基于微批次的预填充流水线（在第 4.3.2 节详述）的影响。图 21a 显示了在各种提示长度下启用和未启用此流水线时的预填充吞吐量。我们观察到启用基于微批次的流水线显著提高了预填充吞吐量，在测试的配置中提高了 23% 到 31%。此外，预填充吞吐量随着提示长度的增加而降低。这种趋势发生是因为注意力计算的每令牌执行延迟随提示长度增加。

图 21b 提供了对应请求执行（4K 提示长度）的每层延迟分解。数据显示，当微批次流水线激活时，每层的整体执行延迟减少了约 24%。这种显著增益主要是通过将与通信相关的轻量级计算任务（例如 DispatchCompute、CombineCompute）卸载到 AIV，并指定 SDMA 引擎用于批量数据传输（例如用于 MoE 的 All-to-All）来实现的。该策略允许它们的执行延迟与在 AIC 上执行的核心计算（如 ATTN 和 FFN）有效重叠，从而提高了 NPU 利用率并减少了端到端预填充时间。

图 21：启用和未启用基于微批次的流水线时的预填充吞吐量和每层延迟分解。所有实验均在每个 NPU 批次包含 16K 总令牌下执行。在 (b) 中，“总体”带微批次表示重叠微批次 0 和微批次 1 后的每层延迟

5.4.2 MTP

为了具体量化 MTP 机制在典型条件下的性能贡献，我们进行了一项有针对性的消融研究。此评估侧重于 MTP 在每个解码步骤生成单个推测令牌的场景，在 CloudMatrix384 上使用一致的输入序列长度 4K 令牌。我们将启用 MTP 的性能与在相同工作负载参数下的标准单令牌自回归解码（即禁用 MTP）基线进行比较。

图 22：启用和未启用 MTP 时的解码吞吐量和每层延迟分解。所有实验使用输入序列长度 4,096 令牌。在 (b) 中，“总体”指重叠两个微批次后的每层延迟，算子延迟表示单个微批次的延迟

如图 22a 所示，我们观察到，与禁用 MTP 的基线相比，启用带有单个推测令牌的 MTP 在不同批次大小下将解码吞吐量提高了 6% 到 49%。观察到这种加速比在较小的批次大小下更为显著。这种现象可能是因为在较小的批次大小下，基线非 MTP 系统离其峰值效率更远（例如，由于固定每次迭代开销分摊较少）。通过 MTP 接受的额外令牌（以 70% 的接受率）则提供了更大的相对吞吐量增益。随着批次大小的增加，虽然 MTP 仍然能提供绝对收益，但其相对加速可能会减弱，因为基线系统本身变得更加饱和，或者 MTP 自身的开销变得更加突出。

然而，这种吞吐量提升伴随着启用 MTP 时每解码层迭代执行延迟的增加。如图 22b 所示（批次大小 96），使用 MTP 使每层执行延迟增加了约 44%（例如，从基线 874 us 增加到启用 MTP 的 1,260 us）。这主要是因为每个启用 MTP 的 LLM 解码步骤从上一次迭代中处理每个请求的两个输入令牌：一个基础令牌和一个推测令牌。这种更大的每迭代有效批次大小自然导致核心操作（如 Attention Core、Gating、Dispatch、MoE 和 Combine）的执行时间更长。

尽管每次迭代延迟增加，但整体吞吐量提高了。以 70% 接受率成功验证推测令牌意味着，平均而言，每个启用 MTP 的迭代产生 1.7 个令牌（1 个基础令牌 + 0.7 个推测令牌）。这种每迭代令牌增益超过了约 44% 的更长迭代时间，确认了我们的 MTP 实现在 CloudMatrix384 上用于 4K 序列长度工作负载的净积极影响。

5.4.3 上下文缓存

在 §4.4 中引入的 EMS-上下文缓存机制通过存储和重用先前请求的 KV 缓存块来加速预填充阶段。此消融研究定量评估了 EMS-上下文缓存在 CloudMatrix384 上的有效性，特别关注底层网络结构如何影响缓存访问性能。具体来说，我们测量了输入长度为 4K 令牌、批次大小包含每个 NPU 16K 总令牌时的预填充吞吐量和首令牌时间（TTFT）。为了评估不同缓存命中率下的性能，我们调整了令牌重用率，该比率控制重用的历史 KV 前缀的比例。本研究的一个核心目标是比较 EMS 在两种网络配置下的性能：一种利用高带宽 UB 互连，另一种回退到较慢的 VPC 网络平面进行缓存访问。

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

图 23 展示了作为令牌重用率函数的性能趋势。如图 23a 所示，两种网络配置下，吞吐量与重用率之间存在强正相关。对于带 UB 的 EMS，将重用率从 12.5% 增加到 50% 导致预填充吞吐量增加了 1.42 倍。在 90% 重用率下，吞吐量比未使用 EMS 的基线提高了 2.28 倍。这种显著提升发生是因为更高的重用率意味着输入序列中更大比例的 KV 缓存直接从 EMS 缓存加载而不是重新计算，显著减少了预填充 NPU 上的计算负载。此外，在比较两种网络配置时，带 UB 的 EMS 始终优于带 VPC 的 EMS。使用 UB 平面使预填充吞吐量提高了高达 1.52 倍。这种增益直接归因于 UB 平面显著更高的带宽和更低的延迟，加速了从分布式 EMS 缓存到 NPU 的 KV 缓存块加载。

同时，随着令牌重用率的增加，TTFT 显著降低，如图 23b 所示。例如，使用带 UB 的 EMS，50% 的令牌重用率相比无上下文缓存将 TTFT 减少了 861 ms（34%），而 90% 重用率导致 TTFT 减少了 1,505 ms（59%）。这种 TTFT 的显著减少是绕过大量预填充计算（当缓存命中时）的直接结果。快速从 EMS 加载历史 KV 缓存的能力，特别是通过高带宽 UB 平面访问并可能从解耦内存池的 DRAM 层提供服务，直接转化为更快的初始令牌生成。类似地，在所有重用率下，通过 UB 平面访问 EMS 缓存比通过 VPC 平面产生始终更低的 TTFT，突显了高性能互连对于延迟敏感缓存检索的重要性。

5.5 算子性能

理解基本计算和通信算子的性能是诊断系统瓶颈和指导软件优化工作的关键。在本小节中，我们提出了与 LLM 服务相关的关键算子的微基准分析，具体是 MoE通信原语、MLA 计算和通用矩阵乘法（GEMM）内核。我们评估了它们在 CloudMatrix384（每个昇腾 910C 芯片）上的性能，并与 NVIDIA H800 GPU 上的代表性性能进行了比较。

5.5.1 通信算子

我们在 CloudMatrix384 上使用 CANN 实现对关键的 MoE 通信算子（特别是分发（Dispatch）和组合（Combine））进行了基准测试。此实现详述于我们融合通信算子的设计中（§4.2.1）。性能与 DeepSeek 在 NVIDIA H800 GPU 上的 DeepEP 实现 [56] 进行了比较，如表 7 所示。该表展示了在不同 EP 度（#EP），从 8 到 256 个等级，每个等级批次为 128 的情况下，延迟和每等级实现的带宽。

表 7：在 NVIDIA H800 (RDMA) 和 CloudMatrix384 (UB 平面) 上，Dispatch 和 Combine 操作在不同 EP 度下的通信算子性能（延迟和每等级带宽）

对于分发操作，CloudMatrix384（CM384）上的 CANN EP 实现在所有测试的 EP 度下始终显示出比 H800 上的 DeepEP 更低的延迟。例如，在 EP 度 8 时，CM384 实现 116 us 的延迟，而 H800 记录为 163 us。CM384 的这种延迟优势随着 EP 度的增加而持续，在 EP256 时 CM384 显示 152 us，而 H800 为 194 us。在分发的每等级带宽方面，CM384 在较小的 EP 度下表现出优越的性能（例如，在 EP8 时为 71 GB/s 对比 46 GB/s）。然而，在大的 EP 度下，我们观察到 CANN EP 在 CloudMatrix384 上的有效带宽显著下降。这种下降突显了当前 EP 实现中的可扩展性瓶颈，我们将其留作未来优化的途径。

组合操作揭示了 CANN 在 CM384 上更显著的性能优势。在所有 EP 规模下，CM384 上的延迟显著降低。例如，在 EP8 时，CM384 的延迟为 118 us，而 H800 为 318 us。这种显著的延迟减少一直保持到 EP256（CM384 为 149 us 对比 H800 360 us）。此外，CM384 上组合操作的每等级实现带宽显著高于 H800。在 EP8 时，CM384 提供 131 GB/s 每等级，几乎是 H800 46 GB/s 的三倍。这种带宽优势在所有测试的 EP 度上持续，CM384 在 EP256 时提供强劲的 103 GB/s 每等级，而 H800 提供 40 GB/s。

这些结果突显了 CANN 集合通信库以及 CloudMatrix384 的 UB 平面对于 MoE 特定通信模式的高效性。在 CloudMatrix384 上实现的持续较低延迟和较高每等级带宽对于缓解大规模专家并行中固有的通信瓶颈至关重要。

5.5.2 MLA 算子

我们评估了在 CM384 上我们的 CANN MLA 实现的 TFLOPS 利用率和内存带宽利用率，与 NVIDIA H800 上的 DeepSeek 的 FlashMLA 在计算密集型和内存密集型设置下进行比较。

表 8：在计算密集型设置下（BF16/FP16 精度），NVIDIA H800 和昇腾 910C 芯片（CloudMatrix384）上 MLA 算子的 TFLOPS 利用率

表 8 展示了当工作负载主要是计算受限时 MLA 算子的 TFLOPS 利用率。H800 上的 DeepSeek FlashMLA 实现了 660 TFLOPS (BF16/FP16)，报告硬件峰值为 989 TFLOPS，利用率为 66.7%。我们同样在 BF16/FP16 下运行的 CANN MLA 在 CloudMatrix384 上实现了 246 TFLOPS，NPU 配置的硬件峰值为 376 TFLOPS，产生了可比较的利用率 65.4%。这表明虽然由于硬件能力不同实现的绝对 TFLOPS 不同，但在计算密集型场景下，利用可用计算能力进行 MLA 的效率在两个平台上是相似的。

表 9：在内存密集型设置下，NVIDIA H800 和昇腾 910C 芯片（CloudMatrix384）上 MLA 算子的内存带宽利用率

在内存密集型设置下，有效利用可用内存带宽至关重要。表 9 展示了这一比较。H800 上的 DeepSeek FlashMLA 实现了令人印象深刻的 3,000 GB/s 内存带宽，占其 3,350 GB/s 硬件内存带宽的 89.6%。我们在昇腾 910C 芯片上实现的 CANN MLA 在所用 NPU 配置下实现了 1,346 GB/s，硬件内存带宽为 1,600 GB/s，产生了同样高的利用率 84.1%。

5.5.3 GEMM 算子

通用矩阵乘法（GEMM）是几乎所有深度学习模型的基本计算内核。GEMM 操作的效率，特别是在 INT8 等较低精度下，对于实现高推理吞吐量至关重要。我们在单个昇腾 910C 芯片（在 CloudMatrix384 系统内）上对 CANN 提供的 INT8 GEMM 内核进行了基准测试。结果详见表 10，展示了实现的 TFLOPS、相对于芯片峰值 INT8 硬件 TFLOPS 的计算利用率，以及这些操作期间的持续内存带宽。这些测试使用常见的 GEMM 分片维度（BM × BN = 128 × 152），操作涉及 INT8 输入和 BF16 输出。

表 10：在昇腾 910C 芯片（CloudMatrix384）上使用 INT8 输入和 BF16 输出的不同配置下的 INT8 GEMM 性能和实现的内存带宽。分片：BM × BN = 128 × 152

表 10：在昇腾 910C 芯片（CloudMatrix384）上使用 INT8 输入和 BF16 输出的不同配置下的 INT8 GEMM 性能和实现的内存带宽。分片：BM × BN = 128 × 152。

如表 10 所示，昇腾 910C 芯片上的 CANN INT8 GEMM 内核在不同矩阵形状（M, N, K）和组数下，始终展示了高计算利用率，范围从 77.4% 到 82.7%，基于芯片的 752 峰值 INT8 TFLOPS。例如，使用 4 组，维度 M=7168, N=4096, K=8192，内核实现了 622 TFLOPS，对应 82.7% 的利用率。这种高效率在不同配置下得以保持，表明昇腾 910C 芯片上 INT8 计算单元的稳健性能。

该表还报告了这些 GEMM 操作期间实现的持续内存带宽，范围从 195 GB/s 到 327 GB/s。这些值远低于昇腾 910C 芯片的峰值内存带宽（1,600 GB/s，如 MLA 算子分析 §5.5.2 所述）。结合高计算利用率数据，这一观察强烈表明，对于测试的矩阵维度，这些 INT8 GEMM 操作主要是计算受限而非内存带宽受限。这种特性表明在 NPU 的内部缓存层次结构和寄存器中实现了高效的数据重用，允许计算单元在其峰值能力的高比例下运行，而不会持续因来自内存的数据传输而匮乏。

6. 未来方向讨论

AI 模型的快速演进及其普遍应用继续对 AI 基础设施提出日益严格的要求。虽然 CloudMatrix384 代表了扩展紧密耦合 AI 计算的一个重要架构里程碑，但需要进一步演进以满足新兴工作负载的需求。在本节中，我们讨论了 CloudMatrix 架构及其构建的 LLM 服务系统的潜在未来方向，旨在进一步增强可扩展性、灵活性、效率和性能。

6.1 CloudMatrix 的未来演进

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

6.1.1 统一 VPC 和 RDMA 平面

如 §3.2 所述，CloudMatrix384 目前为横向扩展（scale-out）和 VPC 流量使用独立的网络平面。然而，CloudMatrix 具有将横向扩展通信集成到 VPC 网络中的潜力。在典型的 AI 训练和推理工作负载中，带宽密集型通信阶段（如张量、专家和序列并行（TP/EP/SP））主要包含在超级节点内。相比之下，跨超级节点通信，主要源自数据和流水线并行（DP/PP），通常表现出低得多的带宽需求。通过分层 DP 通信和通信隐藏技术，VPC 网络可以充分满足大多数 AI 工作负载的跨超级节点通信需求。

基于此观察，基于 VPC 平面的统一网络架构可以在可用区（AZ）规模上实现大规模 AI 集群的构建。它容纳了不同代的 AI 硬件，支持使用超级节点作为基本单元进行灵活和模块化扩展，并通过数据中心网络（DCN）技术实现跨区域的无缝互连。

6.1.2. 更大规模的超级节点

尽管 CloudMatrix384 提供了 384 个 NPU 的庞大规模，但下一代 AI 模型和应用场景预计将需要更大规模的超级节点。几个关键因素推动着向更大规模的趋势：

1. 扩展以匹配模型演进： 随着 LLM 在参数规模和架构复杂度上的持续扩展，服务它们所需的基础设施也必须相应演进。未来的模型预计将具有显著更大的参数数量、更长的输入序列以及越来越多的稀疏激活专家，特别是在 MoE 设计中。这些趋势对每个推理会话中的计算、内存和互连带宽提出了更高的要求。此外，新兴的架构模式，例如用于专业推理的模块化子网络、检索增强生成或混合稠密-稀疏计算，需要模型组件之间更紧密的耦合，导致模型内通信和同步增加。高效支持这些工作负载需要将计算和内存共置在单个紧密集成的超级节点内，以最小化通信延迟并维持高吞吐量。因此，扩展超级节点容量不仅对于满足原始资源需求至关重要，而且对于维持下一代 LLM 所需的细粒度局部性和性能特征也至关重要。

2. 提高资源分配效率： 扩大超级节点规模也提高了现实世界异构工作负载条件下系统范围的资源利用率。基于真实的生产跟踪，我们通过将每个 AI 任务建模为一组紧密耦合块（tightly-coupled blocks）来模拟未来的 NPU 请求模式，其中每个块是必须在单个超级节点内供应的连续 NPU 组，以满足任务内带宽和延迟约束。如图 24 所示，在广泛的平均块大小范围内，更大的超级节点始终实现更高的 NPU 分配率。例如，在平均块大小 10.08 时，384-NPU 超级节点实现了超过 94% 的分配率，而 224-NPU 超级节点则降至 91% 以下。这种改进源于减少的碎片和更好的统计复用——更大的资源池为非均匀作业大小提供了更大的放置灵活性。相反，对于固定大小的超级节点，增加块大小会导致分配效率降低，因为打包困难。当平均块大小达到 11.28 时，224-NPU 超级节点的分配率降至 85% 以下。这些结果突显了在现实工作负载分布下，扩展超级节点规模显著提高了系统吞吐量和效率。
   

   图 24. 不同超级节点规模和紧密耦合块大小下的 NPU 分配率

3. 几乎恒定的分摊网络成本： 扩大超级节点的规模并不会导致更高的每 NPU 网络成本。在相同的网络架构下，例如类似 2 层 Clos 的交换拓扑，只要配置实现交换机端口的完全利用，每 NPU 的网络基础设施分摊成本在不同超级节点规模下几乎保持不变。如表 11 所示，具有 192、288 或 384 个 NPU 的配置都实现了 100% 的交换机利用率，且每节点分摊交换机成本相同。中间配置，如 256 或 352 个 NPU，存在交换机未充分利用的问题，略微增加了每节点成本。这些结果表明，将超级节点规模扩展到给定交换层的上限不会引入额外的成本开销，从网络角度来看是一种成本效益高的策略。

表 11. 不同超级节点规模下的交换机利用率。注意：每个逻辑交换机由两个物理交换芯片组成，如 §3.3.3 所述

4. 适应增加的资源异构性： 未来的 AI 工作负载将需要在同一执行上下文中支持日益多样化的硬件。除了 NPU 和 CPU，下一代超级节点可能会纳入专用加速器，用于物理模拟、实时视频处理、无损数据压缩和密码计算等任务。这些单元正在成为端到端 AI 流水线中必不可少的组成部分，特别是对于多模态或特定领域的应用。为了有效利用，此类异构资源必须共享相同的高带宽、低延迟互连结构，并在超级节点内作为一流计算对等体可访问。在大规模支持这种多样性需要扩展超级节点规模和更灵活的互连架构，进一步强化了朝着更大、更异构的计算域发展的趋势，以处理紧密耦合、跨功能的 AI 工作负载。

6.1.3. CPU 的物理解耦与池化

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

物理解耦的动机源于传统 CPU-NPU 配对在固定节点配置中的僵化性，其中静态的 NPU 与 CPU 比例限制了系统匹配工作负载需求的能力。例如，一些推理工作负载需要密集的 CPU 前/后处理或大型内存支持的缓存，导致 CPU 瓶颈，而 NPU 闲置。相反，训练工作负载可能使 NPU 饱和，而 CPU 资源未充分利用。在这种情况下，紧密耦合的 CPU-NPU 配置导致硬件利用次优和扩展不灵活。

尽管 CloudMatrix384 的点对点 UB 拓扑已经将逻辑资源分配解耦，实现了跨超级节点的灵活 CPU-NPU 匹配，但将 CPU 和 NPU 资源物理分离为专用资源池释放了进一步的优势：

1. 独立和优化的扩展： 可以开发物理上独立的以 NPU 为中心的节点（例如，具有用于基本管理的最小本地 CPU 但最大化 NPU 密度）和以 CPU 为中心的节点（例如，具有许多 CPU 核心、大容量 DRAM 和丰富 I/O 选项，作为超级节点主要的 CPU 和内存资源池）。这使得超级节点的 NPU 计算能力和通用 CPU/内存能力能够独立且更经济地扩展。数据中心运营商然后可以组合具有高度可变的 NPU 与 CPU/内存比例的超级节点，精确地针对主导工作负载（例如，用于训练的 NPU 密集型，用于数据密集型预处理或大规模 EMS 缓存的 CPU/内存密集型）进行定制。

2. 增强的资源利用率和专业化： 专用节点设计允许针对主要资源类型进行硬件优化。NPU 节点可以专注于加速器的电源输送和冷却，而 CPU/内存 节点可以优化内存密度、I/O 带宽或特定 CPU 指令集。与一刀切的混合节点设计相比，这可以带来更好的整体效率和每种资源类型的性能。

6.2 未来服务系统增强

随着底层超级节点架构的持续演进，LLM 服务系统必须共同演进以充分利用这些能力。一个关键方向是超越粗粒度解耦（例如预填充-解码分离），转向更细粒度的组件级解耦和智能的、自适应的部署策略。这些方法旨在提高资源利用率、提升吞吐量，并支持日益异构的工作负载和硬件配置。

6.2.1 组件级解耦

CloudMatrix384 中使用的具有预填充-解码-缓存（PDC）解耦的点对点服务架构已被证明在分离 LLM 推理的主要阶段方面是有效的。然而，通过将模型执行分解为更细粒度的组件（这些组件可以被独立管理、部署和扩展），可以实现进一步的改进。我们强调两个新兴方向：

1. 解码-注意力解耦与卸载： 虽然预填充实例是计算受限的，解码实例通常是内存受限的，但 Adrenaline 系统 [37] 表明，通过将内存密集型的注意力计算从解码路径中解耦并卸载到未充分利用的预填充实例，可以获得额外的性能提升。这种方法提高了整体内存带宽利用率，并在解码实例上支持更大的批次大小，从而提高计算效率。它依赖于低延迟同步、卸载任务的仔细共置以及 SLO 感知的卸载策略。结果是提高吞吐量而不影响延迟，例证了注意力解耦如何释放现有服务部署中的潜在容量。

2. 注意力和 MoE 解耦： 大规模 MoE 模型因稀疏专家激活和极端内存需求而带来独特挑战。MegaScale-Infer [59] 提议将注意力和专家组件解耦为独立的执行服务，实现不同的并行策略和硬件映射。处理每个令牌的注意力层部署在使用数据并行（DP）的内存优化节点上，而专家 FFN 则通过专家并行（EP）分布在专用资源池上。这种解耦执行减少了争用，提高了吞吐量，并允许独立扩展注意力和专家资源，这对于高效服务数万亿参数的 MoE 模型至关重要。

总之，这些解耦技术代表了一种将 LLM 视为松散耦合的微服务集合的转变，每个微服务具有不同的性能特征。这种细粒度允许更好地映射到异构硬件，并改善了超级节点上的负载平衡和可扩展性。

6.2.2 混合与自适应部署

一旦 LLM 推理被分解为组件，这些组件可以被视为细粒度的微服务，例如注意力执行、FFN 计算、KV 缓存管理或 MoE 专家门控，服务系统就获得了采用更复杂部署策略的显著灵活性。这些混合和自适应部署模型使系统能够根据每个组件的独特计算和内存需求定制资源分配，提高整体利用率和可扩展性。

1. 硬件感知的微服务放置： 每个微服务可以根据其性能特征映射到最合适的硬件类型。例如，通常受内存带宽限制的注意力层应优先放置在具有高内存吞吐量的 NPU 上；计算密集型的 FFN 模块受益于在具有强大计算能力的 NPU 上分配；而轻量级或延迟容忍的操作，如 KV 缓存索引，可以卸载到池化的 CPU 或低成本通用加速器上。这种细粒度的匹配能够更有效地利用异构硬件，并在不影响性能的情况下降低成本。

2. 混合微服务共置： 解耦的微服务也可以动态共置以提高整个超级节点的资源利用率。例如，来自解码阶段的内存受限的注意力操作可以卸载到内存未充分利用的预填充实例 [37]。这种混合共置策略有助于缓解资源瓶颈，提高各阶段间的利用率，并增加有效系统吞吐量，特别是在可变或突发工作负载下。

3. 微服务的自适应和独立扩展： 微服务解耦的一个关键优势是能够根据实时工作负载特征独立扩展每个组件。例如，在处理长上下文输入时，注意力微服务可能经历更高负载并相应扩展，而不需要额外的 FFN 或专家资源。这种细粒度防止了系统性过度配置，并允许系统弹性适应工作负载动态。

为了充分利用这些能力，服务基础设施必须包含一个复杂的编排层，能够持续分析系统负载，预测性能瓶颈，并做出实时、SLO 感知的调度和扩展决策。该编排器作为混合部署模型的控制平面，确保即使在工作负载和资源可用性波动时也能满足性能保证。

总之，由组件级解耦支持的混合和自适应部署策略代表了 LLM 服务系统设计的一个有前景的前沿。它们允许更精确的资源利用，跨异构硬件的无缝负载平衡，并能够满足日益复杂和多样化的模型架构带来的未来需求。

7. 结论

在本文中，我们介绍了华为 CloudMatrix，一个体现华为先进 AI 基础设施愿景的下一代 AI 数据中心架构。我们特别强调了华为 CloudMatrix384，这是这一创新架构理念的首个生产级实现。CloudMatrix384 是一个专为高效支持大规模 AI 工作负载而设计的 AI 超级节点，采用全点对点互连的硬件设计。它集成了 384 个昇腾 910C NPU 和 192 个鲲鹏 CPU，通过超高带宽、低延迟的统一总线（UB）网络互连。这种独特的架构促进了动态资源池化、简化的内存管理和卓越的节点间通信，有效解决了传统数据中心架构中常见的可扩展性和效率挑战。

利用 CloudMatrix384，我们提出了 CloudMatrix-Infer，一个全面的服务解决方案，其点对点服务架构将推理工作流解耦为不同的预填充、解码和缓存子系统。该架构通过实现对所有 NPU 的共享解耦内存池的统一访问，显著简化了调度，增强了负载平衡并优化了资源利用率。我们进一步设计和实现了先进的硬件感知技术，包括大规模专家并行（LEP）、优化的通信和 MLA 算子、基于微批次的流水线和 INT8 量化。这些技术共同提升了 MoE 和 MLA 计算吞吐量，提高了缓存效率，并为整体推理性能带来了显著提升。

我们使用 DeepSeek-R1 模型进行的广泛评估表明，CloudMatrix-Infer 实现了卓越的吞吐量，在预填充阶段达到每个 NPU 6,688 tokens/s，在解码期间达到每个 NPU 1,943 tokens/s，同时持续保持低于 50 ms 的每输出令牌延迟。这些结果对应于预填充 4.45 tokens/s/TFLOPS 和解码 1.29 tokens/s/TFLOPS 的计算效率，两者都超过了在 NVIDIA H100 上的 SGLang 和在 H800 上的 DeepSeek 等领先框架的已发布效率。此外，CloudMatrix-Infer 有效管理了吞吐量-延迟权衡，即使在更严格的低于 15 ms TPOT 约束下也能维持 538 tokens/s 的吞吐量。INT8 量化策略在广泛的基准测试中进一步保持了与 DeepSeek 官方 API 相当的精度。

展望未来，有几个令人兴奋的方向可以进一步增强 CloudMatrix384。未来的工作包括集成和统一 VPC 和 RDMA 网络平面以实现更简化的互连，扩展到更大的超级节点配置，以及追求 CPU 资源的更深层次解耦和池化。此外，更细粒度的组件级解耦和自适应部署策略为实现 AI 数据中心基础设施的更大灵活性、效率和可扩展性提供了有前景的途径。

总之，我们的研究结果验证了华为 CloudMatrix 作为部署大规模 AI 工作负载的高效、可扩展和性能优化的平台，为未来的 AI 数据中心基础设施树立了标杆。