xDeepServe on CloudMatrix384

导言

本文逐段精翻并解释 xDeepServe 团队的论文 Huawei Cloud Model-as-a-Service on the CloudMatrix384 SuperPod。全文以 arXiv v6 为准，把摘要、正文、结论与贡献者段落编号为 P001–P129，并完整收录论文的 20 幅原图。除忠实翻译外，本文还从物理拓扑、因果链、运行流程、组件时序与张量流五个视角解释 XCCL、FlowServe、Transformerless 和可靠性机制。原论文采用 CC BY 4.0 许可；本文对图像做了裁切，对文字做了中文翻译、结构化重排与解释性扩写，改动不代表原作者观点。

先看结论

xDeepServe 的核心不是某一个高性能算子，而是一次面向 384 芯片共享内存 SuperPod 的全栈协同设计：

1. XCCL 把网络通信改写成远端内存协议。 AIV 核直接通过 MTE 或 DMA 访问其他 NPU 的片上内存，以元数据、环形缓冲区和轮询/确认协议构造点到点与 All-to-All 原语。
2. FlowServe 把服务控制面分散到 DP group。 每个 DP group 自带调度、缓存、执行与输出链路；中心 TE-shell 只保留一次性请求分派、专家重排和健康协调。
3. Transformerless 把 Transformer 拆成可独立扩缩的资源单元。 系统先分离 Prefill 与 Decode，再分离 Attention 与 MoE，最终目标是去掉全局同步的数据流服务。
4. 2400 tokens/s/chip 是受控峰值，不是线上平均值。 峰值实验使用固定 2K 输入、固定 2K 输出、ignore-eos、贪心采样和 17,280 或 46,080 的全局 batch；代表性生产配置报告的是 900 ms TTFT、34.8 ms 平均 TPOT。
5. 论文仍保留关键证据缺口。 没有公开 xDeepServe/XCCL 生产代码，也没有成本、能耗、可复现实验脚本或完整尾延迟分布；此外，P124 把单层耗时写成 700 ns，但总时延按 0.7 ms 计算，两者相差 1000 倍。

图 A：补充概念图。左侧表示 Prefill、Attention 与 MoE 共享资源时互相阻塞；右侧表示拆分后可以独立扩缩，但必须承担 KV、逐层 token 和控制状态的搬运成本。

阅读约定

• 段落编号：P001–P129 对应 arXiv v6 HTML 中的语义段落；原文列表项也单独编号。
• 精翻：尽量保留原文的断言强度、限定词、数字和引用关系，不把作者的设想写成已验证事实。
• 解释：是本文的编辑性说明，用来补足术语、因果链、张量形状、适用边界和实验解读。
• 证据版本：论文版本为 arXiv:2508.02520v6，2026 年 3 月 1 日修订。机制图依据 v6 的章节与图号绘制，并非源码逆向结果。
• 实现边界：论文没有公开生产代码，因此伪代码只表达论文描述的协议语义，不冒充可运行实现。

图 1：xDeepServe 横跨控制面、FlowServe 执行引擎、XCCL 通信层和 CloudMatrix384 硬件。

摘要

P001 精翻： 向外扩展的 MoE 大语言模型与向上扩展的 SuperPod，为生产级模型即服务（MaaS）带来了新的系统挑战：服务必须支持资源解耦、低延迟通信与去中心化执行。本文介绍 xDeepServe——华为云 CloudMatrix384 上 MaaS 服务背后的生产推理系统。CloudMatrix384 是由 48 台服务器、384 颗 Ascend 910C 芯片组成的 SuperPod，芯片间通过高带宽 UB fabric 和全局共享内存连接。系统承载的模型包括 DeepSeek、Kimi、GLM、Qwen 与 MiniMax 等。

解释： “scale-out MoE”指模型容量通过更多专家横向增长，“scale-up SuperPod”指单个一致性较强的互连域扩展到数百芯片。论文试图回答的不是“怎样实现一个 MoE 算子”，而是当模型稀疏性与硬件共享内存同时扩大时，生产服务栈应如何重构。

P002 精翻： xDeepServe 以 Transformerless 为核心。这是一种解耦执行架构，把 Transformer 推理解构为 Attention、前馈网络与 MoE 等模块，并支持 Prefill-Decode 解耦及 MoE-Attention 解耦部署。为使这种解耦可行，作者开发了 XCCL：一个提供微秒级点到点通信和可扩展 All-to-All 原语的内存语义通信层；同时扩展 FlowServe，引入去中心化 DP group，并缓解拖尾任务与同步方差。在峰值 Decode 配置中，xDeepServe 在约 50 ms TPOT 下达到每颗 Ascend 910C 芯片 2400 tokens/s。

解释： 三个系统部件形成依赖链：Transformerless 提出资源边界，XCCL 支付跨边界的数据搬运成本，FlowServe 管理跨边界的请求与同步。最后的性能数字必须与 P122–P124 的固定长度、大 batch、MTP 设定一起阅读。

引言

P003 精翻： 大语言模型持续增大规模与复杂度。为同时提升质量和效率，DeepSeek、Kimi K2、Qwen 等近期模型采用了混合专家（MoE）架构。MoE 每个 token 只激活少量专家，以较低计算成本扩展模型容量并维持较高质量。与此同时，AI 硬件也在向上扩展。华为 CloudMatrix384 用数百 GB/s 的高速互连连接 384 颗 Ascend 910C，为整个 Pod 提供紧耦合的内存与计算环境。

解释： MoE 的“参数多、激活少”降低了每个 token 的算术量，却把系统压力转向路由、跨卡通信和最慢专家。SuperPod 提供更强互连，恰好能承接这种通信密集型结构，但前提是软件不再沿用普通集群的边界。

P004 精翻： 当向外扩展的 MoE 与向上扩展的 SuperPod 相遇时，新问题随之出现。MoE 需要在数百 NPU 间完成细粒度专家路由、同步与负载均衡。SuperPod 提供覆盖数百 NPU 的全局共享内存和均匀低延迟访问，但传统 LLM 服务系统并未围绕这些特性设计。要释放 SuperPod 基础设施的潜力，需要一种能运行解耦工作负载、控制尾延迟并高效扩展到数百 NPU 的新系统。

解释： 这里的矛盾是：硬件把远端内存访问变得更像本地 load/store，软件却仍以“节点 + 网卡 + 集中调度器”为基本假设。xDeepServe 的方案是把内存语义一直暴露到通信库，再把独立扩缩一直暴露到服务引擎。

P005 精翻： 本文介绍 xDeepServe——华为云面向 SuperPod 规模部署的自研 LLM 服务系统。

解释： 这是论文的主张范围：一个已用于华为云 MaaS 的生产系统报告，不是通用硬件性能白皮书，也不是可复现实验论文。

P006 精翻： 作者主张把资源解耦作为大规模服务的基础设计原则。解耦把系统组件分成可独立扩缩的单元，改善故障隔离，并允许系统灵活演进。为实现这些收益，作者提出 Transformerless：把基于 Transformer 的 LLM 拆为 Attention、前馈网络和 MoE 模块，在专用 NPU 上独立运行。该设计解耦计算与内存，减少阶段间干扰，并支持分别扩缩。

解释： “Transformerless”不是删除 Transformer 数学结构，而是删除“整层 Transformer 必须由同一组设备同步执行”的部署约束。逻辑模型仍是 Transformer，物理资源拓扑变成模块化流水线。

P007 精翻： 作者实现了两种解耦形式。

解释： 两种形式不是平行的小优化，而是递进关系：先按请求阶段拆 Prefill/Decode，再在 Decode 的每一层内部拆 Attention/MoE。

P008 精翻： 第一种是 Prefill-Decode 解耦，用于减少计算受限的 Prefill 与内存受限的 Decode 之间的干扰。Splitwise、TetriServe 和 DistServe 已探索这一方向，但本文针对 SuperPod 上采用专家并行的大型 MoE。系统进一步采用异构部署：Prefill 同时运行在 Ascend 910B 与 910C，Decode 只放在 CloudMatrix 的 910C 节点，以利用高带宽互连。该设计在成本与性能之间取平衡，并在大规模下实现高吞吐与低延迟。

解释： Prefill 的大矩阵乘更吃计算，Decode 的小 batch 自回归更吃权重/KV 带宽。分离后可为两阶段选择不同并行策略和芯片，但新增了KV cache 跨阶段转移、背压与语义配对问题。

P009 精翻： 第二种进一步把 MoE 与 Attention 解耦，让专家与 Attention 在不同 NPU 上运行，以降低资源争用并提高利用率。作者在 768 个 Ascend 910C die 上部署 DeepSeek-V3/R1：288 个 die 负责 MoE，480 个 die 负责 Attention。分离会造成计算不平衡：MoE 无状态、随 batch size 扩展；Attention 保存 KV cache、随序列长度扩展。作者为此提出三项技术：用 trampoline 转发的 A2E/E2A 协议处理不对称 NPU 配额；用新的 DP domain 在不缩小 batch 的情况下进行组间调度；用跨计算与通信流的 persistent kernel 消除 CPU 开销。整个 SuperPod 的 dispatch 延迟保持在 200 μs 以下。

解释： 关键不是简单地把两个算子放到不同卡，而是要让 288 个专家 die 与 160×3 个 Attention DP group 形成可持续流水线。trampoline 解决扇出，DP domain 解决流水线粒度，persistent kernel 解决微秒内核不能等待毫秒级 CPU 调度的问题。

P010 精翻： 为支撑完全解耦执行，作者提出 XCCL：在 CloudMatrix384 共享内存 fabric 上提供内存语义点到点与 All-to-All 原语的新通信库。XCCL 支持微秒级延迟，并覆盖超过 30 万个 NPU 对。系统用它实现 KV cache 传输、MoE dispatch/combine 与 MoE-Attention 通信。

解释： 384 颗芯片若按有向关系组合，潜在通信对约为 \(384\times383\)，若进一步按 die/AIV 细分会更大。论文的“30 万对”强调预建元数据与缓冲管理的规模，而不是说同一时刻存在 30 万条满带宽流。

P011 精翻： xDeepServe 还构建了面向 SuperPod 的可扩展服务引擎 FlowServe。它引入 DP group 抽象：每组独立管理包括 tokenization、SPMD 执行、缓存与网络在内的完整流水线，不依赖集中协调。FlowServe 通过消除单点扩展瓶颈而扩展到数百 NPU，并用系统技术降低 MoE dispatch/combine 屏障下的延迟，包括 DP 间负载感知路由、主动垃圾回收和专家负载均衡。它还支持多 token 预测（MTP）与 INT8 量化，以在严格 SLA 下提高吞吐和硬件利用率。

解释： 去中心化并非完全取消中心组件。TE-shell 仍进行低频或每请求一次的全局决策；高频的逐 token 执行与流式输出下沉到 DP group，避免中心路径随 token 速率线性膨胀。

P012 精翻： 为确保 SuperPod 规模的可靠性，xDeepServe 在故障检测与恢复路径中加入多层机制。系统用多级心跳和链路探测检测进程挂起与静默 KV 传输停滞；恢复策略从粗粒度集群重启演进为细粒度组件恢复，包括 Prefill/Decode 独立故障切换、专家 rank 动态重配置，以及网络或内存瞬态错误下的选择性 token 重算。即使发生硬件中断，系统仍能维持可用性和吞吐。

解释： MoE 的全局屏障会放大单卡故障，所以“能发现 crash”远远不够；系统还要区分执行循环卡死、Decode 容量饱和与链路失效，才能选择不会扩大故障域的恢复动作。

P013 精翻： xDeepServe 已在生产中服务大型 DeepSeek、GLM、Kimi 和 Qwen 模型。峰值 Decode 配置达到每颗 Ascend 910C 芯片 2400 tokens/s、约 50 ms TPOT；生产环境多数情况下以 TTFT 小于 2 s、TPOT 35 ms 为 SLA 目标。

解释： 50 ms 是峰值吞吐实验中的 TPOT，并非“满足 35 ms SLA”的证明。生产结果 P127 才对应异长真实流量，报告 34.8 ms 平均 TPOT，但没有给出 P95/P99。

P014 精翻： 论文的贡献如下。

解释： 后四段是贡献列表，应理解为作者声称“本文描述或提出了什么”，而不是对每项收益都提供了同等强度的消融证据。

P015 精翻： 作者展示了 xDeepServe：在 CloudMatrix384 SuperPod 上运行大型 MoE LLM 的生产 MaaS 服务系统。

解释： 系统价值来自生产规模与全栈覆盖，但闭源使外部验证主要依赖论文内部数据。

P016 精翻： 作者描述了 Transformerless，包括 SuperPod 规模的 Prefill-Decode 解耦和 MoE-Attention 解耦部署。

解释： “Transformerless”是部署架构名称，不是模型架构名称。

P017 精翻： 作者介绍了 XCCL：建立在 CloudMatrix384 分布式共享内存之上的通信层，为服务负载提供微秒级点到点与 All-to-All 原语。

解释： XCCL 的特别之处是协议建立在远端内存可读写能力上，而不仅是对常规集合通信接口调优。

P018 精翻： 作者给出 FlowServe 的 SuperPod 级服务设计，包括去中心化 DP group、负载感知调度、专家负载均衡和可靠性机制。

解释： 这些机制共同服务于一个目标：减少全局屏障看到的最慢参与者，而不是只优化平均算子耗时。

P019 精翻： 论文余下部分先介绍 CloudMatrix384 架构，再介绍底层通信库、服务引擎、Transformerless 服务架构，最后讨论可靠性机制。

解释： 本文保留同一主线，但在每个机制后加入“对象—状态—流程—边界”解释。

背景

xDeepServe

P020 精翻： xDeepServe 是华为云全托管、Serverless 的 LLM 服务平台，面向大规模多租户负载。它从作者此前的 DeepServe 系统演进而来，新增了面向 CloudMatrix384 规模的能力。xDeepServe 已在大型 Ascend NPU 集群生产运行一年以上，提供微调、Agent 托管和模型服务的行业标准 API。面对生成式 AI 服务需求增长，它处理的生产难题包括任务时长异构、分布式有状态执行和动态资源需求。

解释： 这里的 Serverless 指用户不管理实例生命周期，不意味着底层推理无状态。相反，KV cache、专家权重、图缓存和流式会话都使服务端高度有状态。

P021 精翻： xDeepServe 通过四个核心组件应对上述问题：其一，用 request-job-task 模型构造 Serverless 抽象，统一后训练与推理任务；其二，集成微内核式自研引擎 FlowServe，以 NPU 为中心并采用 SPMD 并行；其三，提供同时支持 Prefill-Decode 解耦与合设模式的调度策略；其四，用预热 Pod、DRAM 预加载和 NPU fork 等系统优化实现快速弹性，可在数秒内扩到 64 个实例。

解释： request-job-task 负责控制面生命周期，FlowServe 负责数据面执行，调度器负责放置，预热/预加载/fork 负责缩短扩容关键路径。四者覆盖了从 API 到设备状态的不同时间尺度。

P022 精翻： 前一篇论文介绍了 xDeepServe 核心架构；本报告聚焦部署到 CloudMatrix384 后出现的新挑战与技术，展示利用其向上扩展能力支撑下一代 LLM 服务的系统设计。

解释： 因而本文不会重新完整描述 DeepServe/RTC/DistFlow 的全部细节；阅读 P098–P103 时需要把这些组件视为已有基础。

CloudMatrix384

P023 精翻： 图 2 概览了 CloudMatrix384 与 910C NPU 芯片。

解释： 这是理解 XCCL 的硬件前提图：要区分服务器级 VPC、跨域 RoCE、SuperPod 内 UB，以及 910C 芯片内两个 die 的 NoC。

图 2：48 台服务器共 384 颗 910C；每颗芯片含两个 die，UB 把 CPU 与 NPU 纳入同一向上扩展互连域。

P024 精翻： 一个 CloudMatrix384 SuperPod 是由 48 台服务器构成的单一 scale-up 域，提供数百 PFLOPs FP16 算力、数 TB 片上内存和每秒数 TB 内存带宽。每台服务器包含多个 CPU、NIC 与 8 颗 Ascend 910C。SuperPod 集成三类网络：VPC 连接外部系统或云服务；scale-out RoCE 连接全部 NPU，并可延伸到多个 SuperPod 与 910B 服务器；scale-up UB 使 CloudMatrix384 成为 SuperPod，在域内以 All-to-All 方式连接 CPU 与 NPU，带宽比 RoCE 高数倍。

解释： 三张网承担不同半径：VPC 面向服务入口，RoCE 面向跨 Pod/异构 Prefill，UB 面向 Pod 内细粒度解耦。Transformerless 的 MoE-Attention 方案依赖的是最后一种。

P025 精翻： scale-up UB 带来两项新特性。第一，它提供覆盖全部 CPU DRAM 与 NPU 片上内存的全局共享地址空间，任意芯片可访问任意其他芯片的内存，并同时支持传统 DMA 与内存语义。第二，系统消除了服务器内 NUMA 局部性：CPU 访问同一服务器内 8 颗 NPU 的延迟是均匀的。

解释： “共享地址空间”不等于缓存一致的普通 CPU 内存，也不等于远端访问没有代价。它表示通信库可以用地址、读写和顺序协议表达数据移动，从而绕过部分主机控制路径。

P026 精翻： 一颗 Ascend 910C 由两个通过片上网络连接的 die 构成。每个 die 采用 DaVinci 架构，包含等量的 AI Cube（AIC）与 AI Vector（AIV）核、若干 AI CPU 和多个 DMA 引擎。AIC 执行矩阵内核，AIV 处理向量操作；两类核心都有标量单元和独立控制流，通过外部片上内存交换数据。每个 AIV 含 KB 级 Unified Buffer 与两个内存传输引擎 MTE2/MTE3：MTE2 把片上内存读入 Unified Buffer，MTE3 再写回片上内存。

解释： XCCL 把 AIV 当作可编程通信处理器：标量单元推进协议状态，MTE2/MTE3 搬运小块数据，Unified Buffer 做 ping-pong 暂存。

P027 精翻： AIV 的 MTE2/MTE3 与 DMA 是 CloudMatrix384 实现全局共享内存的基础。它们都能经 UB 读写 SuperPod 内任意 NPU 的片上内存。通常 MTE2/MTE3 用于低延迟通信，DMA 用于高吞吐传输：前者提供内存语义 API，在 Unified Buffer 与片上内存间移动数据，单次受数百 KB Buffer 限制；后者采用 DMA 语义，支持最高数 GB 的批量搬运。更多细节可参考 Ascend C 编程手册。

解释： 这是一个典型的启动延迟—吞吐量权衡。小消息优先 MTE，避免 DMA 启动成本；大消息或希望减少 AIV 占用时优先 DMA。选择阈值会受消息大小、并发流和计算争用影响，论文没有给出自动选择算法。

NPU 执行模式

P028 精翻： Ascend NPU 支持两种执行模式，xDeepServe 在 LLM 服务的不同阶段采用不同模式以平衡灵活性与性能。PyTorch 等框架把神经网络表示为计算图，算子是节点，数据依赖是边；这些图可用单算子模式或图模式执行。

解释： 两种模式对应 Prefill/Decode 的输入形状差异，并进一步说明为什么两阶段不能简单共用同一个后端。

P029 精翻： 单算子模式是 PyTorch 默认模式。Python 每调用一个算子，就把它分派到 NPU 算子队列，下一次同步时结果可见。它支持任意控制流、动态张量形状和原生调试，并在依赖允许时提供有限 CPU-NPU 并发；但每个算子启动都产生主机—设备通信，若算子执行时间短于下一算子的分派时间，NPU 会空闲。对计算密集型算子，这一成本可以接受，因此 Prefill 使用该模式处理动态输入形状。

解释： Prefill 的长序列矩阵算子足以摊薄 launch 开销，而动态长度、序列并行和 prefix cache 又需要 eager 灵活性。

P030 精翻： 图模式会追踪并编译静态计算图，把整图作为一个单元分派到 NPU，从而消除逐算子 launch 开销并提高设备利用率。华为 TorchAir（基于 PTA）支持 Ascend 图模式推理。如图 3(b)，CPU 一次 kernel launch 即可把整图交给 NPU。Decode 输入形状较小且大多静态，所以使用图模式以获得最佳性能。

解释： Decode 每步算子短而重复，图模式能把 host dispatch 气泡压缩到图级；代价是形状和控制流不如 eager 灵活，图编译与 guard 也可能形成抖动源。

图 3：单算子模式逐个从 CPU 下发，图模式一次下发静态图；xDeepServe 分别用于 Prefill 与 Decode。

XCCL：共享内存上的通信库

P031 精翻： 要充分利用 CloudMatrix384 的 scale-up UB fabric，高性能通信库不可或缺。作者提出为 SuperPod LLM 服务定制的 XCCL。它在全局共享内存之上设计分布式内存协议，以构造高效网络原语；协议风格类似基于单边 RDMA verbs 的经典远端内存系统。

解释： 传统集合通信通常从“发送消息”出发，XCCL 从“远端地址可访问”出发。数据通路、通知和确认都要由库自己定义，因此更灵活，也更容易把一致性、复用和背压写错。

P032 精翻： 后文分别描述：用于 Prefill-Decode 解耦的点到点 API；用于专家并行的 dispatch/combine API；用于 MoE-Attention 解耦的 A2E/E2A API。

解释： 三类 API 的数据对象分别是 KV block、token hidden state/专家输出，以及跨异构模块的逐层 token。它们共用共享内存基础，但扇出、同步和生命周期不同。

点到点原语

P033 精翻： 本节介绍 CloudMatrix384 上的 send/receive 点到点 API。它们支撑 Prefill-Decode 解耦、序列并行和通过 NPU fork 快速扩容等场景。论文以 Prefill NPU 向 Decode NPU 传输 KV cache 为例。XCCL 可在任意 NPU 对之间执行收发，因此设计需要扩展到约 30 万个潜在配对。

解释： KV cache 是有生命周期和层/rank 语义的块，不是任意字节流。XCCL 负责可靠搬运，DistFlow 在更高一层保证“哪个 Prefill block 对应哪个 Decode request/rank”。

P034 精翻： 下面给出设计细节。

解释： 细节分为内存布局与分布式协议，缺一不可：协议引用的指针、计数器和 ring slot 都必须有稳定所有权。

P035 精翻： 每颗 NPU 的片上内存分为三块：应用数据区、元数据区和托管数据区。应用区保存 KV cache 等由服务引擎直接使用的数据。元数据区保存健全性检查与分布式协议的控制信息；为支持 AIV 并行，每对 AIV 核有一个字段。CloudMatrix384 有 384 颗 NPU，每颗 2 个 die、每 die 最多 48 个 AIV，字段总数为

\[ 384\times 2\times 48\times 2\approx 74\,000. \]

每个 32 字节字段包含用户定义、用于检查的 eventID，kernel 生成、用于追踪分块传输的 chunkID，以及指向数据区 ring buffer 的 tailPtr。元数据区总计预留 4 MB。托管数据区负责 NPU 间交换；每个 NPU 对维护固定数量、固定槽大小的专用 ring buffer。元数据区与托管区都由 XCCL 管理。当前实现并非零拷贝：调用 API 时，数据还要在应用区与托管区之间复制。

解释： 三块内存分别对应业务所有权、协议状态、传输所有权。固定配对和固定槽换来常数时间寻址，但会消耗预留内存并限制突发深度。论文图注称另有直接操作应用区的零拷贝版本，正文却把“当前实现”描述为非零拷贝；本文按正文保守理解，零拷贝的适用条件与一致性责任尚未公开。

对象	生产者	消费者	作用域	生命周期	关键约束
eventID	Serving engine	收发 kernel	一次逻辑传输	调用开始至确认	两端必须匹配
chunkID	XCCL kernel	对端 kernel	一个分块	进入 ring 至消费	防止乱序/槽复用混淆
tailPtr	发送端 kernel	接收端 kernel	NPU 对/AIV 对	持久	更新后数据必须可见
Managed slot	发送端	接收端	NPU 对	ACK 前占用	固定容量，需要背压
App KV block	Prefill	Decode	请求/层/rank	Decode 接管前	语义由 DistFlow 配对

P036 精翻： 图 4 展示发送端到接收端的分布式内存协议。步骤 1：发送端服务引擎调用 send，传入应用数据区源缓冲区、eventID、接收 NPU ID 与使用的 AIV 数量；XCCL 在发送 NPU 启动 kernel，各 AIV 用 MTE2 并行把源数据读入 Unified Buffer。步骤 2：kernel 从元数据区读取目标片上内存地址，用 MTE3 把 Unified Buffer 写入接收端托管数据区；Unified Buffer 采用 ping-pong，使 MTE2 与 MTE3 并发。也可以用 DMA 直接从应用区写到远端托管区，绕过 Unified Buffer，但启动延迟更高。步骤 3：发送 kernel 用 MTE3 更新接收端 tailPtr，表明已传字节数。步骤 4：发送 kernel 忙轮询本地元数据，等待接收端确认。步骤 5：接收端服务引擎调用 receive，传入应用区目标缓冲、eventID、发送 NPU ID 与 AIV 数量；接收 kernel 轮询本地元数据。步骤 6：发现数据后，用 MTE2/MTE3 ping-pong 把托管区数据复制到应用区。步骤 7：完成后，接收 kernel 更新发送端元数据作为 ACK，并返回 CPU 与调用者。步骤 8：发送 kernel 发现 ACK，返回 CPU，send 完成。除同步协议外，XCCL 还提供避免忙轮询的异步模式。

解释： 正确性关键是“先数据、后 tailPtr；先消费、后 ACK”。如果远端写入可见性没有在元数据发布前建立，接收端会读到未完成数据；如果 ACK 提前，发送端可能复用 ring slot。论文没有公开具体 memory fence，所以不能从文字证明其内存序实现。

图 4：红色虚线表示元数据，蓝色路径表示数据；MTE2/MTE3 经 Unified Buffer 完成 ping-pong 搬运。

下面的伪代码只复述协议状态机，不代表 XCCL 实际接口：

procedure XCCL_SEND(src, event_id, receiver, aiv_count):
    slots = RESERVE_RING_SLOTS(receiver, SIZE(src))
    chunks = PARTITION(src, slots, aiv_count)
    for each chunk in chunks in parallel:
        local_buf = MTE2_LOAD(chunk.app_range)
        MTE3_REMOTE_STORE(receiver, chunk.managed_slot, local_buf)
    MEMORY_RELEASE_FENCE()
    REMOTE_WRITE(receiver.metadata[event_id].tail_ptr, END(slots))
    while LOCAL_READ(metadata[event_id].ack) != event_id:
        DEVICE_RELAX()
    RELEASE_RING_SLOTS(receiver, slots)
    return SUCCESS

procedure XCCL_RECEIVE(dst, event_id, sender, aiv_count):
    while LOCAL_READ(metadata[event_id].tail_ptr) == EMPTY:
        DEVICE_RELAX()
    MEMORY_ACQUIRE_FENCE()
    chunks = DISCOVER_READY_CHUNKS(event_id, sender)
    for each chunk in chunks in parallel:
        local_buf = MTE2_LOAD(chunk.managed_slot)
        MTE3_STORE(chunk.dst_range, local_buf)
    MEMORY_RELEASE_FENCE()
    REMOTE_WRITE(sender.metadata[event_id].ack, event_id)
    return SUCCESS

P037 精翻： XCCL 的 send/receive 达到微秒级延迟。图 5 在不同数据量与每次 kernel 使用不同 AIV 数量下测量从 send 开始到完成、覆盖全部协议步骤的端到端延迟。作者随机选择不同服务器上的两个 NPU die，利用 UB 的均匀带宽。小于 1 MB 的 payload 即使只用 2 个 AIV，延迟也低于 20 μs；数据增大后，并行度带来收益：传输 9 MB 时，48 个 AIV 比 2 个 AIV 快 2.5 倍以上。

解释： 结论是“消息越大，才越值得占用更多 AIV”。图中没有并发流、拥塞或计算共置条件，因此不能直接外推到满载生产环境的尾延迟。

图 5：XCCL 点到点性能随数据量与 AIV 并行度变化。

图 B：补充机制图。从物理连线、因果关系、协议流程、组件时序和数据流同时观察 XCCL 点到点通信。

合设 MoE-Attention 的 All-to-All

P038 精翻： 本节介绍大型专家并行使用的两种 All-to-All 原语：dispatch 与 combine。dispatch 根据 gating 分数把每个 token 的 hidden state 送往 top-\(k\) 专家；combine 以同一分数加权聚合专家输出。两者合计至少占 MoE 执行时间的 25%。与点到点原语类似，作者用远端内存语义而不是 DeepEP 一类传统网络 verbs 实现它们；正文详述 dispatch，combine 采用类似模式。

解释： 若输入 hidden state 为 \(X\in\mathbb{R}^{B\times H}\)，路由索引与权重可写作 \(I,W\in\mathbb{R}^{B\times k}\)。dispatch 形成按目标 rank 重排的 token 包，专家计算后，combine 按原 token 位置和 \(W\) 做逆向聚合。通信量与 \(B\times k\times H\) 近似成正比。

P039 精翻： 每颗 NPU 同样分为三个内存区。元数据区对每个 rank 保存一个 32 字节字段，包含用于检查的 event ID、该 rank 在托管数据区的 buffer offset，以及从该 rank 收到的 token 数。最大元数据字段数量与点到点原语相近。托管数据区按 rank ID 分区，每颗 NPU 获得一个由最大 batch size 决定的定长块。

解释： dispatch 不能只传数据，还要先让每个接收 rank 知道“从谁收多少 token、放在哪里”。固定最大 batch 的分区避免动态分配，却把容量规划前置到部署阶段。

P040 精翻： dispatch 有两个主要阶段：先广播各 rank 应接收的 token 数，再进行实际数据传输。图 7 的步骤为：1）服务引擎传入应用区源缓冲、event ID 等参数，发送 NPU 启动 kernel，并用 MTE2 把数据并行读入各 AIV Unified Buffer；2）若启用量化，用向量指令把 FP16/BF16 转为 INT8；3）按目标 rank 把 token 写入托管数据区；4）更新各目标 rank 的元数据，写入其接收 token 数；5）每颗 NPU 轮询本地元数据，直到收到全部 rank 的元数据；6–7）随后根据 offset 与 token count，用 MTE2 从对端拉 token 到 Unified Buffer，再由 MTE3 写入应用区目标缓冲。

解释： 这是“先交换尺寸，再按尺寸 pull 数据”的两阶段协议。它让接收端决定读取位置，适合全局共享内存；但第 5 步仍是全参与者屏障，任一 rank 的路由/计算抖动都会扩散。

图 7：红色虚线为 token count/offset 元数据，实线为 token 数据。

procedure DISPATCH(x, route_rank, event_id, world_size):
    local_counts = HISTOGRAM(route_rank, bins=world_size)
    packed, offsets = PACK_BY_RANK(x, route_rank)
    if COMMUNICATION_INT8_ENABLED:
        packed, scales = TOKENWISE_QUANTIZE_INT8(packed)
    for rank in 0 .. world_size - 1:
        REMOTE_WRITE(rank.metadata[event_id],
                     {count: local_counts[rank], offset: offsets[rank]})
    WAIT_UNTIL_METADATA_FROM_ALL_RANKS(event_id, world_size)
    recv_layout = PREFIX_SUM(RECEIVED_COUNTS(event_id))
    for peer in 0 .. world_size - 1 in parallel:
        bytes = REMOTE_PULL(peer.managed[offsets_from(peer)],
                            RECEIVED_COUNTS(event_id)[peer])
        STORE(app_output[recv_layout[peer]], bytes)
    return app_output, recv_layout, scales

procedure COMBINE(expert_output, token_index, gate_weight):
    returned = REVERSE_DISPATCH(expert_output, token_index)
    result = ZEROS([ORIGINAL_TOKEN_COUNT, HIDDEN_SIZE])
    for item in returned in parallel:
        result[item.token] += item.value * gate_weight[item.token, item.expert]
    return result

P041 精翻： 图 6 在固定 DeepSeek-R1、EP128 下改变每 die batch size，评估 dispatch/combine。小 batch 时，dispatch 因多出量化步骤而略慢于 combine；量化把数据体积减半，所以每 die batch 超过 32 后 dispatch 反而更快。作为量级参考，单 die batch 为 96、EP128 时，全局 batch 为

\[ 96\times128=12\,288. \]

解释： 这说明通信量化存在固定成本与带宽收益的交叉点。这个“32”只适用于该模型、消息维度、EP128 和硬件环境，不应当作普适阈值。

图 6：小 batch 时量化开销占优，大 batch 时减半的数据量占优。

解耦 MoE-Attention 的 All-to-All

P042 精翻： 本节介绍用于 MoE-Attention 解耦部署的 A2E（attention-to-expert）与 E2A（expert-to-attention）原语，使 token 能在大规模 Attention NPU 与专家 NPU 之间高效路由和聚合。

解释： dispatch/combine 的参与者通常对称，而 A2E/E2A 跨越两类数量不同、职责不同的设备池。

P043 精翻： A2E 与 dispatch 类似，根据 gating 分数把每个 token 的 hidden state 从 Attention NPU 送到 top-\(k\) 专家 NPU；E2A 与 combine 类似，收集所选专家输出、按相同 gating 分数加权，再送回 Attention NPU。两者复用分布式共享内存基础和类似数据结构。

解释： 数据往返构成一层 MoE 的闭环：

\[ X_{\text{attn}}\xrightarrow{\text{A2E}} \{X_e\}\xrightarrow{\text{Expert}} \{Y_e\}\xrightarrow{\text{E2A}} Y_{\text{token}}. \]

P044 精翻： 关键差别是 Attention 与专家模块位于不同 NPU die，资源分配不对称。典型 DeepSeek-R1/V3 配置有 288 个专家 NPU、仅 160 个 Attention NPU。若使用朴素 pull-based dispatch，每个 Attention NPU 都要向全部专家 NPU推送元数据并等待对方拉取；高扇出与 AIV 有限的标量吞吐会迅速降低效率。

解释： 单个 Attention rank 的控制工作量从“处理本地 batch”膨胀成“管理 288 个目标”，数据量未必先成为瓶颈，元数据 fan-out 和轮询状态数会先成为瓶颈。

P045 精翻： 作者为此提出 trampoline forward。选择与 Attention NPU 数量相同的一部分专家 NPU 作为跳板；它们先接收 Attention NPU 的全部数据，再转发给其余专家 NPU。两段式路由降低元数据开销，并在不对称设备间平衡流量，完整数据流见图 8。

解释： trampoline 把 \(N_A\to N_E\) 的直接高扇出拆成 \(N_A\to N_A\) 与 \(N_A\to N_E\) 两段。代价是多一次 hop、更多缓冲和阶段同步；收益是把源 Attention NPU 的控制扇出限制在可管理范围内。

P046 精翻： 为提高通信效率，作者采用 NPU-Direct URMA，类似 GPU 上的 IBGDA：AIV 可直接向 DMA 引擎发远端内存访问请求，绕过 host CPU 与 AI CPU。它的启动延迟高于 MTE2/MTE3，但有三项优势：减少 AIV 消耗，使更多 AIV 留给通信或计算；适合高吞吐，DMA 可传数 GB 而 MTE 受 Unified Buffer 限制；避免与计算流竞争 MTE2，尤其适用于同一 die 上计算与通信共存的场景。

解释： 因此路径选择不只由字节数决定，还由AIV 是否稀缺、MTE2 是否与计算争用、是否需要异步提交决定。论文没有给出统一决策模型。

P047 精翻： 作者在单个 SuperPod 上评估 A2E/E2A：3 个 DP domain，每个含 160 个 TP=1 的 DP group，外加 288 个专家 NPU；DeepSeek-R1 每 die batch 为 96，全局 batch 为

\[ 96\times3\times160=46\,080. \]

该配置下，A2E 延迟为 172 μs，E2A 为 193 μs，说明在高并发和大规模部署中两种原语仍保持低延迟。

解释： 这是一个大 batch、固定拓扑的单点结果。它证明目标配置可运行，但未报告 batch 扫描、并发租户、失败注入或 P99。

图 8：A2E 先从 Attention 送到 trampoline 专家，再转发到其余专家；E2A 反向执行。

图 C：补充机制图。重点标出对称 dispatch/combine 与非对称 A2E/E2A 的差异、trampoline 的控制扇出和 barrier 边界。

FlowServe：SuperPod 级服务系统

总览

P048 精翻： LLM 通过 MoE 向外扩展，硬件通过 CloudMatrix384 向上扩展；华为云的目标是让服务系统同样扩展，以在 SuperPod 上高效运行大型 MoE。扩展要求合适的抽象、高效调度，并消除性能瓶颈与单点故障。

解释： 通信库只能降低数据搬运时间，不能决定请求放到哪个 DP，也不能消除最慢请求/专家；FlowServe 解决的是更高层的排队、状态和屏障方差。

P049 精翻： 为此，作者把 FlowServe 从单节点系统重构为图 9、图 10 所示的 SuperPod 分布式系统，重构围绕三个组件展开。

解释： 三个方向分别是控制面扩展、同步方差控制、单次 forward 效率。

P050 精翻： 第一，引入受 SGLang 启发的 DP group 抽象。每个 DP group 封装完整服务流水线，包括 tokenization、API 解析、SPMD executor、Relational Tensor Cache（RTC）和 DistFlow 网络栈。请求调度与响应处理都分散到 DP group，从而消除瓶颈与单点。

解释： DP group 是服务级而不只是训练框架里的并行 rank 集合。它同时拥有控制对象、缓存对象和执行对象，因而可以独立接收并推进请求。

P051 精翻： 第二，实现系统级优化以缩短全局同步造成的延迟。请求虽能独立分配到数百 NPU 上的 DP group，但 MoE 仍引入 dispatch 与 combine 两个全局屏障。作者用 DP 级负载均衡和主动 GC 降低 dispatch 延迟方差，用 MoE 负载均衡优化 combine。

解释： dispatch 吸收的是各 DP 先前 Attention 计算的方差；combine 吸收的是各专家计算负载的方差。两端需要不同治理手段。

P052 精翻： 第三，优化模型执行以提高 forward 效率。服务 DeepSeek-R1/V3 时，FlowServe 实现了高效 MTP 与 Dynamic MicroBatching，以提高硬件利用率和吞吐。

解释： MTP 减少每个被接受 token 的主模型迭代数；Dynamic MicroBatching 则调节流水线粒度。两者都可能改变 batch、同步与尾延迟，需要与 SLA 联合调参。

P053 精翻： 下文逐项介绍这些优化。

解释： 后续顺序是 DP group、请求负载均衡、抖动控制、专家负载均衡、MTP 和 INT8。

图 9：每个 DP group 都复制完整服务栈，TE-shell 只承担少量全局职责。

图 10：dispatch 前的 Attention 方差与 combine 前的专家负载不均，分别形成两类同步等待。

可扩展 DP group

P054 精翻： 在 MoE Decode 阶段，FlowServe 对 MoE 层采用专家并行（EP），对 Attention 层采用数据并行（DP）。DP 数可扩展到数百，因此单个 FlowServe 实例能每秒生成数十万 token。关键挑战是把 FlowServe 演进成没有单一扩展瓶颈的去中心化架构。

解释： Attention 的请求状态天然按 DP 分片，MoE 专家却被这些 DP 共享；“局部独立 + 层间全局”正是同步屏障产生的结构原因。

P055 精翻： 图 9 展示演进后的 FlowServe。可扩展性的原则是让每个 DP 成为自包含软件栈，并消除跨 DP 通信。scheduler、output processor、RTC engine 与 EP 负载均衡模块都在各 DP 内复制。TE-shell 仍是跨 DP 的中心编排器，但只承担三项职责：跨 DP 分派请求、触发专家负载均衡，以及协调全部 DP 的健康检查。

解释： “消除跨 DP 通信”指服务软件的常规控制路径，不包括模型本身在 MoE dispatch/combine 中必需的集合通信。TE-shell 的动作频率低于逐 token 数据面，因此中心化尚可承受。

P056 精翻： 每个请求由 TE-shell 中心化的 DP load balancer 利用全局视图分派；每请求只发生一次，成本可接受。但流式输出必须去中心化。FlowServe 使用 output shortcutting：每个 DP master 派生独立子进程，专门执行 detokenization、输出流解析（如抽取推理内容或工具调用结果），并把消息直接转发给 xDeepServe frontend。

解释： 若所有生成 token 都回到 TE-shell，中心带宽与解析 CPU 会随输出 token 速率增长。shortcut 让中心只处理 \(O(\text{requests})\) 的入口，DP 子进程处理 \(O(\text{tokens})\) 的出口。

DP 负载均衡

P057 精翻： 在多 DP 的大模型推理中，用户请求分配到多个 Attention DP group，而这些组共享同一 MoE backbone。每个 MoE dispatch 点形成隐式同步屏障：每个 DP 都要等待最慢组完成前一段 Attention 计算。Attention 时间不均时，快组空等拖尾组，增加 dispatch 的整体尾延迟。因此，谨慎地在 DP 间路由请求，是避免 MoE 同步延迟并维持高吞吐的关键。

解释： 调度目标不是让“请求数”相等，而是让下一屏障前的预计完成时间接近。序列长度、KV 使用量、prefix hit 和 batch 饱和度都会改变这个时间。

P058 精翻： Prefill 使用新的单级调度。初版沿用单 DP 引擎，构造两级 scheduler：请求先进入某个 DP 队列，再由该 DP 本地调度；这容易产生拖尾，例如某 DP 选短 batch，另一个却处理长 batch。Chunk-prefill 能缓解，但引入切块开销并需要自适应块大小。序列并行也有问题：长请求要求全部 DP 参与，同一组 SP rank 同时处理 32K 与 128K 序列并不高效。FlowServe 因而采用单级协作 scheduler：所有已 tokenize 请求在 DP 间共享，DP-0 的 leader 每步用 all-gather 收集状态，再依据 prefix cache 命中率等成本模型分配 batch。全局视图让 DP 协同决策；该调度只在存在 pending request 时触发。

解释： 两级调度的问题是第一次路由过早绑定，局部 scheduler 看不到全局组合机会。单级调度延后绑定，但引入 leader 和 all-gather；论文没有量化其调度开销或 leader 故障切换。

P059 精翻： Decode DP 的负载由并发请求数与 KV cache 内存共同决定。每个 DP 有固定 batch 上限；满载时必须阻塞新请求，增加 TTST 与 TPOT。KV 使用量反映活跃序列内存；分布不均会使 MLA 执行时间失衡，甚至触发 swap。调度先排除达到 batch 上限的 DP，再在其余组中选择 KV 使用量最低者，并计入长输出所需的预留空间。TE-shell 在请求分派/完成时更新 pending 数，并周期采集 KV 指标，从而以较低开销做全局决策。

解释： 这里采用容量优先的启发式，而非完整预测器。它直接保护两个硬约束：batch slot 与 KV block。

procedure ROUTE_DECODE(request, dp_groups):
    candidates = []
    for dp in dp_groups:
        predicted_batch = dp.active_requests + dp.pending_requests
        if predicted_batch < dp.batch_limit:
            reserve = ESTIMATE_OUTPUT_KV(request.max_output_tokens)
            score = dp.kv_used + dp.kv_reserved + reserve
            candidates.APPEND({dp: dp, score: score})
    if EMPTY(candidates):
        return BACKPRESSURE
    target = ARGMIN(candidates, key=score).dp
    target.pending_requests += 1
    target.kv_reserved += ESTIMATE_OUTPUT_KV(request.max_output_tokens)
    return target

主动 GC 抑制抖动

P060 精翻： 随 FlowServe 部署规模扩大，作者观察到明显的图启动抖动。它在第一次 dispatch 算子处最突出，例如 DeepSeek 第 4 层或 Kimi K2 第 2 层，因为这里首次发生全 die 全局同步；某些情况下抖动超过 100 ms。大规模 EP 让一次 forward 涉及数百 NPU/CPU 核，系统因而对拖尾者极其敏感。

解释： 第一个全局屏障像“方差显影剂”：此前独立积累的 CPU 调度、图 guard、GC 和算子时间差在这里一次性暴露。

P061 精翻： 作者用三项关键优化缓解抖动。

解释： 三项分别控制操作系统调度、框架编译/guard 与 Python 运行时停顿。

P062 精翻： 绑核： 每个 executor 固定到专用 CPU 核，减少 kernel 调度噪声和上下文切换。

解释： 绑核降低 CPU 端 launch 时序方差，但会提高核资源占用，并要求避免与系统守护进程争用。

P063 精翻： PTA 缓存： 配置 PyTorch Air 缓存已编译图，绕过昂贵的运行时 guard 检查，缩短启动延迟。

解释： 前提是 Decode 形状足够静态；若 shape/profile 变化频繁，缓存命中率会下降。

P064 精翻： 手动 Python GC： 在受控间隔主动调用垃圾回收，例如每数百次 forward 后执行一次，避免 GC 在关键 dispatch 期间随机暂停。

解释： 这不是消除 GC 成本，而是把不可预测暂停搬到可控窗口。部署必须同时监控对象增长，避免过长间隔造成内存膨胀。

专家负载均衡

P065 精翻： 专家负载均衡对 CloudMatrix384 上的大规模 EP 至关重要。DeepSeek 部署采用 EP288：256 个 routed expert 与 32 个 shared expert。专家负载不均会使全部 288 个 NPU 因拖尾效应减速，图 11 展示了这一问题。

解释： gating 的目标通常是模型质量，不保证系统负载均匀。图 11 的 ShareGPT 样本中，20% 专家高于平均负载，最热专家达到平均值的 30 倍。

图 11：左侧是高度偏斜的专家 token 分布，右侧比较理想均匀路由、原生路由与 EPLB。

P066 精翻： 作者采用数据驱动方案：周期分析 token 路由，识别过载热专家，并把它们复制到多个 NPU。每层在每个 NPU 上预留冗余槽；推理时用预计算映射把 token 均匀分给副本。系统持续收集激活数据并更新副本分配，专家权重异步换入，避免严重不均时中断推理吞吐。

解释： 这是“测量—规划—搬权重—切映射—分流”闭环。副本消耗显存/片上内存，且历史热度可能滞后，所以更新周期和冗余预算决定稳定性。

P067 精翻： 图 12 展示该设计的五个关键组成部分。

解释： 正文实际按四个 Step 展开，其中 Step 2 同时包含“选择副本”和“放置副本”，所以可理解为五个逻辑部件。

P068 精翻： 步骤 1，收集专家负载。专家负载定义为给定时间窗内路由到该专家的 token 总数，它同时反映 dispatch/combine 通信量与 Expert MatMul 计算量。每个 MoE 层在 gating 后插入 Collect kernel，统计各 NPU 分给每个专家的 token 数并写入片上 buffer。各 NPU executor 在 DP group 内聚合，周期性（例如每分钟）发送到 TE-shell。频繁采集会产生开销，因此要在准确性与效率间取舍。

解释： token count 是简单、可在线获取的代理指标，但没有区分 token shape、量化路径或不同专家 kernel 效率；论文假设同层专家的单位 token 成本接近。

P069 精翻： 步骤 2，EPLB 算法与分配。给定负载数据，EPLB 为每层选择冗余专家以平衡工作量。层 \(\ell\) 在时间片 \(t\) 的最热专家定义为：

\[ h_{\ell,t}=\arg\max_e \operatorname{token\_count}[\ell][e][t]. \]

解释： 候选集合只取各时间片曾经最热的专家，缩小搜索空间，但可能漏掉长期第二热、累积贡献更大的专家。

P070 精翻： 层 \(\ell\) 的总负载指标为：

\[ L_\ell=\sum_{t\in T} \operatorname{token\_count}[\ell][h_{\ell,t}][t]. \]

解释： 这不是全部专家 token 总和，而是每个时间片的最大专家负载之和，直接近似 barrier 所见的拖尾成本。

P071 精翻： 给定冗余预算 \(R\)，按后续步骤选择冗余专家。

解释： \(R\) 控制额外权重槽数量；论文没有给出如何依据内存或 SLA 自动确定 \(R\)。

P072 精翻： 计算当前总负载 \(L_\ell\)。

解释： 它是贪心算法每轮的基线目标值。

P073 精翻： 对每个曾在任一时间片成为热点的候选专家 \(c\)，模拟把 token 均匀拆到它的所有副本，并计算新的总负载 \(L_\ell(c)\)。

解释： 模拟隐含“副本间能理想均匀分流”的假设，后面的按 token 位置轮转就是用来近似实现它。

P074 精翻： 选择使模拟负载最小的候选 \(c^\*\)，加入冗余列表。

解释： 每轮只选一个、立即更新，是预算约束下的贪心近似，不保证全局最优。

P075 精翻： 更新已选专家的 token count，反映其 token 已在副本间均分。

解释： 更新后再选下一副本，防止预算反复投入同一热点而忽视新的瓶颈。

P076 精翻： 选出冗余专家后，对它们进行 NPU 放置。先对每个冗余专家跨时间片求总负载，并按负载从高到低排序；依次把专家放到仍有冗余槽且当前负载最低的 NPU，每次放置后更新该 NPU 负载。

解释： 这是 largest-first 的贪心装箱：先放重对象可减少最后被迫把大负载塞入剩余槽的概率。

procedure SELECT_AND_PLACE_REPLICAS(token_count, layer, budget, npu_slots):
    replicas = []
    simulated = COPY(token_count[layer])
    repeat budget times:
        candidates = UNIQUE(ARGMAX_EXPERT(simulated[t]) for t in TIME_SLICES)
        best = NONE
        best_tail_sum = INFINITY
        for expert in candidates:
            trial = SPLIT_EVENLY(simulated, expert, COPIES(expert) + 1)
            tail_sum = SUM(MAX_EXPERT_LOAD(trial[t]) for t in TIME_SLICES)
            if tail_sum < best_tail_sum:
                best = expert
                best_tail_sum = tail_sum
        if best == NONE:
            break
        replicas.APPEND(best)
        simulated = SPLIT_EVENLY(simulated, best, COPIES(best) + 1)

    ordered = SORT_DESCENDING(replicas, key=TOTAL_LOAD)
    placement = []
    for expert in ordered:
        target = LEAST_LOADED_NPU_WITH_FREE_SLOT(npu_slots)
        placement.APPEND({expert: expert, npu: target})
        target.load += TOTAL_LOAD(expert) / (COPIES(expert) + 1)
        target.free_slots -= 1
    return placement

P077 精翻： 步骤 3，冗余专家重配置分四阶段：先从存储预取新专家权重到内存；修改逻辑—物理映射，暂时禁用冗余槽；异步把预取权重加载到目标槽；最后恢复映射，重新启用冗余槽。这样可在不中断进行中推理的情况下更换权重；之后的 forward 使用新映射均匀分流。

解释： 正确切换需要版本化映射或等价机制，确保某次 forward 不会看见“映射已启用、权重未就绪”的中间态。论文描述了顺序，但没有公开原子切换实现。

P078 精翻： 步骤 4，在 forward 中平衡专家副本 token。系统要把 gating 产生的逻辑 expert ID 映射到实际 NPU 上的物理 expert ID，同时控制延迟与通信开销。直接收集全部 NPU 的实时激活计数过于昂贵，作者采用两种办法：其一，用 PyTorch gather 并行把 gating 矩阵映射为物理副本；其二，根据 token 在 batch 中的位置轮转副本分配，无需 NPU 间通信即可近似均匀。图 11(b) 中 forward 延迟改善超过 40%。

解释： 位置轮转不需要反馈，是低开销 open-loop 均衡；若 token 的专家选择与 batch 位置强相关，仍可能偏斜，因而需要周期测量闭环纠正。

P079 精翻： 图 12 展示逻辑专家如何按 token 位置轮转到物理副本。例子每步有 4 个 token、256 个逻辑专家，映射表形状为 [4, 256]：行对应 token，列对应逻辑专家。若逻辑专家 1 有主副本 slot 2 与冗余副本 slot 1，则第一列在 4 个 token 间轮转 1、2，使两者以相同概率接收 token。

解释： 对副本列表 \(R_e\)，可把物理槽写成

\[ \operatorname{physical}(i,e)=R_e[i\bmod |R_e|], \]

其中 \(i\) 是 batch 内 token 位置。这保证计数差最多为 1，但不保证每个副本的实际 kernel 时间完全相同。

图 12：从负载收集、EPLB 规划、权重重配置到逻辑—物理副本轮转。

多 Token 预测

P080 精翻： DeepSeek 的 Multi-Token Prediction（MTP）把传统 next-token prediction 扩展为按序预测多个未来 token。推理时，MTP 先一次提出多个 token，再由主模型验证，从而加速自回归生成。

解释： 若一次主模型 forward 平均接受 \(a>1\) 个 token，则有效 TPOT 约为“该轮总耗时 / \(a\)”。收益取决于接受率，而不是草稿长度本身。

P081 精翻： 本节说明 FlowServe 如何把 MTP 接入 Prefill-Decode 解耦流程以提高 Decode 效率，完整流水线见图 13。

解释： 除模型计算外，优化目标还包括 sampling、accept check 与 CPU 调度之间的气泡。

P082 精翻： Prefill 阶段，主模型与 MTP 一同处理 prompt，建立 KV cache 并生成首 token；随后把 KV cache 和相关 hidden state 传到 Decode。Decode 使用紧凑的五步循环消除 CPU 气泡。初版沿用 vLLM 中 EAGLE 的调度，但出现明显停顿，作者改为定制流水线：1）MTP forward 生成 \(k\) 个 draft token；2）从 MTP 输出采样候选；3）主模型验证 draft；4）从主模型输出再次采样；5）检查最终 logits 并决定接受哪些 token。

解释： 主模型验证仍然是正确性锚点；MTP 只改变提议方式。若拒绝发生，系统必须只提交已验证前缀，并维护主模型与 MTP 的 KV/hidden state 一致。

procedure MTP_DECODE_STEP(state, k):
    drafts, draft_state = MTP_FORWARD(state, k)
    candidates = SAMPLE_MTP(drafts)
    verified_logits, verified_state = MAIN_MODEL_VERIFY(state, candidates)
    verified_tokens = SAMPLE_MAIN(verified_logits)
    accepted_count = LONGEST_ACCEPTED_PREFIX(candidates, verified_tokens)
    committed = COMMIT_PREFIX(verified_tokens, accepted_count)
    state = UPDATE_KV_AND_HIDDEN(verified_state, committed)
    return committed, state

P083 精翻： DeepSeek 公开的参数只有一个 MTP 层。多数负载中，该层接受率为 70%–90%，固定 batch 下最多降低 40% 延迟。为做更深 speculation，作者曾直接复用该权重作为第二个 MTP 层，无重训时生产数据仅达到每步 2.26 token。随后冻结主模型和原 MTP，使用 FlowServe 从内部 prompt 生成 28 万训练样本，专门训练第二 MTP；结果达到每步 2.35 token，相对复用基线提高 9%。

解释： 文中“9%”与 2.26 到 2.35 的直接相对增幅并不一致：

\[ \frac{2.35-2.26}{2.26}\approx 3.98\%. \]

若 9% 指其他基线或指标，正文没有说明。这是第二处应谨慎对待的数值口径问题。

图 13：MTP 提议、sampling、主模型验证、再次 sampling 与接受检查形成一轮。

DeepSeek INT8 量化

P084 精翻： CloudMatrix384 的 Ascend 910C 不原生支持 FP8 算术。为部署原以 FP8 训练的 DeepSeek-R1/V3，作者用后训练量化（PTQ）把模型转换为 INT8，并针对 DeepSeek 结合 SmoothQuant 与 GPTQ。

解释： 这里不是把 FP8 bit pattern 直接改成 INT8，而是用校准数据重新确定 scale，并用平滑与误差补偿控制精度损失。

P085 精翻： INT8 覆盖 MLA、MoE 与 MLP。作者加入量化误差补偿；激活采用 token-wise 量化（每 token 一个 scale），权重采用 channel-wise 量化（每输出通道一个 scale）。推理使用硬件加速的 npu_quant_matmul（QMM）执行 INT8 矩阵乘。

解释： 若激活 \(x_i\) 的 scale 为 \(s_i\)，权重输出通道 \(j\) 的 scale 为 \(s^w_j\)，近似计算为

\[ y_{ij}\approx s_i s^w_j \sum_k q(x_{ik})q(w_{jk}). \]

更细粒度 scale 提高精度，但也增加 scale 计算、存储与融合要求。

P086 精翻： 图 14 用四个组件总结量化方案。

解释： 四个对象是 MLA、MLP/MoE 权重、通信张量与 KV cache，分别对应计算带宽、模型容量、网络带宽和序列状态内存。

图 14：MLA 与 MLP/MoE 使用定制 PTQ，MoE 通信融合量化，KV cache 选择性量化。

P087 精翻： MLA 用低秩压缩处理 Q/K/V 并结合 RoPE。作者把 Wq_a、Wkv_a、Wq_b 与输出投影 Wo 等关键权重量化为 INT8。激活动态范围比权重大 10–100 倍，因此先用 smoothing 在激活与权重间重新分配量化难度，再采用基于 GPTQ 的 channel-wise 量化，以 Hessian 引导的迭代更新补偿剩余 FP 权重。图 15 展示 DeepSeek-R1 某线性层在 smoothing 前后的激活与权重幅值。

解释： SmoothQuant 等价于对输入通道做可逆缩放：压低激活 outlier，同时把逆缩放吸收到权重；GPTQ 再利用二阶信息尽量减少输出误差。

图 15：右侧平滑后的极值范围收窄，使 INT8 网格更有效。

P088 精翻： DeepSeek 前部使用 MLP，后部使用 MoE；MoE 的 shared/routed expert 约占总参数 90%。作者把 MLP 的 up_proj、gate_proj、down_proj 与全部专家权重量化为 INT8，用 GPTQ 动态更新尚未量化的权重以减小误差。因专家激活取决于输入，校准集被扩大，保证每个专家至少看到 \(n=4\) 个样本，实际通常为 40–128 个。推理时还把 up_proj 与 gate_proj 融合到一个硬件 kernel。

解释： “每专家至少 4 样本”只是下限，极稀有专家的分布估计仍可能不稳定。论文没有给出量化前后任务精度表，不能仅凭方法描述判断线上质量损失。

P089 精翻： 为降低通信开销，专家输入与输出在跨节点发送前量化为 INT8；推理时把量化/反量化直接融合进通信算子。

解释： 融合避免额外读写中间张量，并解释了 P041 中 dispatch 在大 batch 时优于 combine：前者多了量化计算，却把传输字节减半。

P090 精翻： MLA 的 KV cache 包含 RoPE 与 non-RoPE 两部分，长序列下显著占用内存。作者把数值分布较稳定的 non-RoPE 部分量化到 INT8；对精度不敏感的 Attention 层，进一步让 Attention 计算全程使用 INT8。

解释： 这是选择性状态量化：不稳定或敏感分量保留更高精度。可部署性取决于逐层敏感度分析，但论文未公开判断阈值与准确率消融。

图 D：补充机制图。把 DP group 的物理复制、同步方差因果链、请求流程、组件生命周期与 MoE token 流放在同一张图中。

Transformerless：走向完全解耦

P091 精翻： 作者主张把资源解耦作为现代模型服务系统的核心架构原则。解耦使组件可独立扩缩、改善故障隔离并允许软件灵活演进，而网络带宽是其基础。过去 40 Gb/s scale-out 网络曾使传统负载的内存与操作系统解耦成为可能；今天 400 GB/s scale-up 互连让 AI 模型服务解耦成为可能。

解释： 400 GB/s 与 40 Gb/s 相差的不只是十倍：前者以字节计，后者以比特计，名义量级约相差 80 倍。不过带宽并不能自动消除延迟、同步和小消息控制开销，XCCL/FlowServe 正是为这些非带宽成本服务。

P092 精翻： 为实现解耦收益，作者提出 Transformerless，把 Transformer LLM 分解为 Attention、FFN 与 MoE 等模块，分别在高速互连 NPU 上执行。CloudMatrix384 数百 GB/s 的 UB 支持激进解耦而不牺牲推理性能。作者设想三个阶段（图 16）：第一，Prefill-Decode 解耦，把计算受限 Prefill 与内存受限 Decode 放到不同 NPU；第二，MoE-Attention 解耦，让 MoE 按 batch size、Attention 按序列长度独立扩缩；第三，SuperPod 级 dataflow serving，彻底打破全局同步，使每个服务组件真正独立扩缩。

解释： 前两阶段是已实现并报告数据的系统，第三阶段是愿景。演进过程中同步边界逐渐细化：请求阶段边界 → Transformer 子模块边界 → 异步张量边界。

图 16：从 PD 合设到 PD 解耦、MoE-Attention 解耦，最终走向完全异步数据流。

Prefill-Decode 解耦

P093 精翻： Splitwise、TetriServe 与 DistServe 几乎同时提出 Prefill-Decode 解耦，以减少计算受限 Prefill 与内存受限 Decode 的竞争，Mooncake 与 MemServe 又进一步完善了该方向。

解释： xDeepServe 的差异不在“首次提出 PD 解耦”，而在大型 MoE、Ascend 异构芯片与 SuperPod 内存 fabric 上的工程化。

P094 精翻： 即使该架构已被采用，为大型 EP MoE 构建高效、稳健的 PD 流水线仍有两项困难。第一，Prefill 与 Decode 因序列长度不同而需要不同并行策略：Prefill Attention 使用 TP=4，Decode 使用 TP=1，于是 DP 分组不同，合设低效。第二，后端执行模式不同：Prefill 使用 eager graph 支持动态长度、序列并行与 prefix cache，Decode 用 static graph 获取最大吞吐。

解释： 若强行合设，要么为 Prefill 牺牲静态图效率，要么为 Decode 复制 KV/降低 DP；物理分离让每阶段选择自己的 TP、DP、图模式和硬件。

P095 精翻： 作者用图 17 所示的完全解耦流水线解决这些问题。

解释： 流水线同时包含请求控制流与 KV 数据流；两者可以先后到达，必须通过任务元数据与地址正确会合。

图 17：多个 Prefill TE 与 Decode TE 全互连，JE 负责阶段选择，DistFlow/XCCL 延迟执行 KV transfer。

P096 精翻： 请求先到随机选择的 Job Executor（JE）。JE 综合 cache 状态、系统负载和请求长度，为其选择 Prefill Task Executor（TE）。长度感知很重要：把长短请求放入同一 DP group 会产生拖尾，显著恶化尾延迟与 TTFT。

解释： 随机 JE 用于入口分散，JE 内部的 TE 选择才是负载感知决策。cache 命中与长度可能冲突：命中高的 TE 未必当前最快。

P097 精翻： Prefill TE 再把请求调度到一个 DP group 执行计算。

解释： TE 决定部署实例，DP scheduler 决定实例内具体并行组与 batch。

P098 精翻： Prefill 完成后，DP master 向 RTC-DistFlow 注册一个 PD-transfer task。任务只包含元数据与相关 KV block 地址；真实传输延迟到 Decode 阶段触发。

解释： 这是控制与数据分离：先发布“可转移句柄”，Decode 有容量时再拉数据，避免把尚无接收空间的 KV 推入网络。

P099 精翻： 同时，JE 根据实时系统负载把请求分发给一个 Decode TE，以平衡吞吐。

解释： Prefill 与 Decode TE 的选择独立，因此形成 \(M\times N\) 潜在连接，DistFlow 必须隔离每一对的状态。

P100 精翻： Decode TE 通过负载感知路由，把请求调度到合适的 DP group。

解释： 这里使用 P059 的 batch/KV 容量约束，不能只按最短队列。

P101 精翻： Decode DP 检查是否有可用 KV block slot。容量不足就推迟 RECV，向上游施加背压；容量充足则向 DistFlow 提交异步 RECV，底层使用 XCCL 点到点收发。

解释： 背压把 Decode 的内存容量变成显式流控信号，防止传完数据后无处放置。它也会延长 KV 在 Prefill 端的持有时间，所以 Prefill 必须保留 block 至完成通知。

P102 精翻： DistFlow 编排真实 KV 传输，处理 SEND/RECV 握手、顺序保证和 TP rank 同步。KV block 本身不携带完整语义，DistFlow 保证 Prefill/Decode DP 的正确配对。每对 Prefill/Decode TE 使用隔离的 DistFlow 实例以限制故障域，但多个实例可以共享 XCCL buffer 以节省 NPU 片上内存。

解释： 隔离控制状态却共享数据缓冲会形成复用风险，至少需要 buffer 配额、event namespace 与异常回收；论文没有公开这些策略。

P103 精翻： 每个 DP 轮询自己的 DistFlow completion queue。传输完成后，Prefill DP 释放 KV block，Decode DP 把请求加入计算队列。

解释： completion 是所有权交接点：此前 Prefill 不能复用源块，之后 Decode 才能消费目标块。

procedure HANDLE_PD_REQUEST(request):
    prefill_te = SELECT_PREFILL_TE(request.cache_key,
                                   request.input_length,
                                   PREFILL_LOADS)
    prefill_dp = prefill_te.SCHEDULE(request)
    kv_blocks, hidden = prefill_dp.RUN_PREFILL(request)
    transfer = prefill_dp.REGISTER_TRANSFER(request.id, kv_blocks, hidden)

    decode_te = SELECT_DECODE_TE(DECODE_LOADS)
    decode_dp = decode_te.ROUTE_BY_BATCH_AND_KV(request)
    while not decode_dp.HAS_KV_SLOTS(transfer.block_count):
        APPLY_BACKPRESSURE(request.id)
        decode_dp.WAIT_FOR_CAPACITY()

    recv_handle = decode_dp.SUBMIT_ASYNC_RECV(transfer.metadata)
    DISTFLOW_PAIR_SEND_RECV(transfer, recv_handle)
    WAIT_COMPLETION(prefill_dp.completion_queue, transfer.id)
    WAIT_COMPLETION(decode_dp.completion_queue, transfer.id)
    prefill_dp.RELEASE(kv_blocks)
    decode_dp.ENQUEUE_DECODE(request, recv_handle.kv_blocks)
    return ACCEPTED

P104 精翻： 为提高成本效率，Prefill 与 Decode 运行在异构 NPU 上。Prefill 是计算受限、对互连带宽不太敏感，因此同时使用 scale-out 910B 与 scale-up 910C；Decode 只放在 910C CloudMatrix384 上，用高速互连加速 MoE dispatch/combine，以满足 35 ms TPOT SLA。910B Prefill 到 910C Decode 通过 RoCE 或 VPC 传 KV，FlowServe 按网络 fabric 选择 DistFlow backend。对于 DeepSeek、Kimi K2 等 MLA 模型，两类互连都能满足 TTFT/TPOT SLA。

解释： 最后一项是作者的生产结论，但没有给出 RoCE/VPC 的 KV 大小、带宽、尾延迟与跨域故障数据。其成立依赖 MLA 的 KV 压缩程度和 Prefill 传输能否被 TTFT 预算吸收。

MoE-Attention 解耦

P105 精翻： FastDecode、Lamina 与 InstAttention 等工作率先把 Attention 与 FFN 分到不同资源执行，MegaScale-Infer 又扩展到 MoE；但先前工作主要研究小模型和有限规模，是否适用于 DeepSeek 这类大型 MoE 仍不明确。

解释： 本节的主要新证据是 768 die 的全 SuperPod 部署，以及与之匹配的非对称集合通信和调度结构。

P106 精翻： 为填补这一空白，作者在 CloudMatrix384 上构建大型 MoE-Attention 解耦系统，在 Decode 阶段运行 DeepSeek-V3/R1。部署覆盖整套 CloudMatrix384 的 768 个 NPU die：288 个运行 EP288（256 routed expert + 32 shared expert），480 个运行 MLA。相同设计也适用于 Kimi K2 与 Qwen。

解释： “384 颗芯片”和“768 个 die”是同一套硬件的两种计数粒度。论文吞吐按 chip 报告，而并行布局多按 die 报告，比较时必须乘除 2。

P107 精翻： 关键挑战是提高 MoE NPU 利用率。MoE 无状态，计算量主要随 batch size 变化，执行时间可预测；MLA 保存 KV cache，计算量同时随 batch 与序列长度变化。这种不匹配使 microbatch 或计算—通信重叠不足以持续填满 MoE NPU。

解释： Attention 的每个 DP 可能因序列长度不同而完成时间不同；若 MoE 只等待一个大同步 batch，就会间歇饥饿。过度切 microbatch 又降低专家 GEMM 的矩阵规模。

P108 精翻： 作者用图 18、图 19 所示的三项技术解决这些问题。

解释： 三项分别作用于通信拓扑、调度粒度、设备端 launch。

图 18：480 个 MLA die 组成 3 个 DP domain，每个 160 个 TP=1 DP group；288 个 die 专门执行 EP288。

P109 精翻： 第一，设计 A2E/E2A 原语。DeepSeek-R1/V3 的 288 个 MoE NPU 与 160 个 Attention NPU 配额不对称，传统 pull 机制低效。trampoline forward 让与 Attention 数量相同的一组 MoE NPU 先接收数据，再转给其余 MoE NPU，降低元数据开销并平衡带宽。图 19 中 A2E/E2A 是第一段，A2E′/E2A′ 是第二段。

解释： 这里复用 P045 的通信机制，但放到流水线时间轴后可以看见第二 hop 必须与 MoE 计算、其他 domain 的通信协调。

P110 精翻： 第二，引入 DP domain：每个 domain 封装多个 DP group。系统可有多个 domain，但任一时刻只有一个 domain 通过 A2E/E2A 与 MoE NPU 交互。若没有 domain，所有 DP group 同时通信，重叠计算与通信只能依赖 microbatch；过度 microbatch 会降低有效 batch，损害 MoE 效率。DP domain 提供 domain 间并行，microbatch 提供 domain 内并行。图 18 有 3 个 domain，每个 160 个 TP=1 DP group；图 19 每 domain 切两个、大小各 96 的 microbatch，两级并行共同提高吞吐与利用率。

解释： DP domain 是粗粒度流水级：一个 domain 在 MoE 通信时，其他 domain 可做 MLA；microbatch 是域内细粒度流水级。二者一起避免把 batch 切得过小。

P111 精翻： 第三，在 MoE NPU 上用 persistent kernel 实现零 CPU 开销调度。系统使用三条并发 stream：A2E 接收、MoE 计算、E2A 发送；每条 stream 运行持续忙轮询、不返回 CPU 的 persistent kernel。MoE kernel 通常只有微秒级，任何毫秒级 CPU 交互都会引入调度延迟并降低性能。

解释： “零开销”指 steady-state 不经历 CPU launch，并非没有轮询成本。persistent kernel 会长期占用核心与功耗，并需要设备端状态机处理停止、错误和重配置。

kernel PERSISTENT_A2E_STREAM(queue_in, queue_compute):
    while SYSTEM_STATE != STOPPED:
        if queue_in.HAS_READY_DOMAIN():
            batch = A2E_TWO_STAGE_RECEIVE(queue_in.POP())
            queue_compute.PUSH(batch)
        else:
            DEVICE_RELAX()

kernel PERSISTENT_MOE_STREAM(queue_compute, queue_out):
    while SYSTEM_STATE != STOPPED:
        if queue_compute.NOT_EMPTY():
            batch = queue_compute.POP()
            expert_result = RUN_MOE(batch)
            queue_out.PUSH(expert_result)
        else:
            DEVICE_RELAX()

kernel PERSISTENT_E2A_STREAM(queue_out):
    while SYSTEM_STATE != STOPPED:
        if queue_out.NOT_EMPTY():
            result = queue_out.POP()
            E2A_TWO_STAGE_SEND(result)
        else:
            DEVICE_RELAX()

图 19：三个 DP domain 交错推进；MoE 侧用 A2E、计算、E2A 三条 persistent stream 串成设备端流水线。

数据流服务愿景

P112 精翻： 只要全局同步仍在数据路径上，系统就无法真正扩展。MoE-Attention 解耦虽把两类计算放到不同 NPU，仍依赖 A2E/E2A 两个紧同步原语，因此任一组件故障或拖尾都可能卡住全系统并造成级联延迟。作者设想下一代 LLM 服务摆脱全局同步，像经典 dataflow 架构一样让张量在组件间异步流动。实现它需要：重写通信协议以容忍时延变化而不使用同步屏障；把调度与准入控制改为去中心化事件驱动；在部分结果或输入延迟时仍保证一致性与正确性。

解释： 这部分没有实现或评测。真正异步化需要为每个 token/层携带版本与依赖，处理乱序、重复、重放和有界缓冲；它把“等待最慢者”问题转换为“状态爆炸与一致性”问题。

图 E：补充机制图。展示 PD 与 MoE-Attention 两层解耦后，资源、请求、KV、逐层 hidden state 和控制状态的不同生命周期。

可靠性

P113 精翻： 在 CloudMatrix384 上服务大型 LLM 时，可靠性是关键挑战，尤其是 MoE group communication 会把单设备故障放大成全系统中断。本节介绍高层可靠性机制，省略 Kubernetes health probe、依赖降级与流控等工程细节。

解释： 本节证据主要是设计演进，没有给出 MTBF、恢复时间、故障注入成功率或可用性曲线，因此适合学习故障模型，不能据此量化 SLA。

故障检测

P114 精翻： xDeepServe 的及时、准确故障检测尤其困难，因为每个 FlowServe engine 可在数十节点上派生数百进程。Crash 较容易识别，而因 group communication 算子挂起等原因造成的进程卡死更难发现。

解释： “进程存在”不等于“请求还能推进”。检测必须覆盖进程存活、事件循环进展和异步数据链路三层。

P115 精翻： 作者实现多级心跳。xDeepServe control plane 周期向每个 FlowServe engine 的 TE-shell 发心跳，TE-shell 再转发给各 DP group master，两级周期可独立配置。每个 DP master 运行单线程 event loop，只有循环活跃时才响应；若 executor 在回复 master 前挂起，master 循环也会停住并不再响应，从而正确暴露故障。

解释： 这种心跳不是独立线程“无论业务是否卡住都回复”，而是把回复嵌入进展路径，因此能检测 fail-stop 与部分 hang。代价是长时间合法操作也可能触发超时，需要按阶段设置阈值。

P116 精翻： 有些故障发生在主 event loop 之外，典型是 Prefill 与 Decode 间异步 KV-transfer pipeline，普通心跳不可见。KV 未能转移往往来自资源饱和，而非传输错误。作者加入 link probing：监控 KV 传输结果并向通道注入 dummy payload，以区分 Decode 侧饱和与链路故障——饱和会延迟 dummy，链路故障会阻断所有传输。该方法为静默停滞提供根因判断，补充心跳路径。

解释： 探测包与真实流量共享通道，诊断逻辑可概括为：业务慢、探测最终通，倾向容量问题；业务与探测都不通，倾向链路问题。仍需防止探测被不同优先级/队列路径误导。

故障恢复

P117 精翻： 分布式执行跨数百 NPU 与多个阶段，稳健恢复至关重要。xDeepServe 的策略经历三阶段：从粗粒度全量重启，逐步演进到细粒度组件恢复，在复杂度、可用性和效率间权衡。

解释： 这是典型生产系统成熟路径：先追求确定恢复，再缩小故障域，最后对高频瞬态错误做在线修复。

P118 精翻： 阶段 1，Restart-the-World。早期使用小集群，例如 4 个 Prefill、1 个 Decode（4P1D），任一故障就重启整个 engine。检测到 NPU 故障后，Kubernetes taint 节点，使 xDeepServe 不再使用；为保证降级集群仍能运行跨节点 Decode，优先重启 Decode，再重启 Prefill。方案简单可靠，但小集群因请求共享池有限而利用率低，且单个 Prefill 故障也会带走全部关联 Decode，恢复慢。

解释： 全量重启把状态清理问题交给进程生命周期，正确性容易保证；代价是故障域等于整个小集群。

P119 精翻： 阶段 2，Prefill/Decode 独立切换。共享集群包含多个 Prefill/Decode 实例，提高资源利用率并支持工作负载专门化，例如用专用 Prefill 处理长序列，减少队头阻塞，Decode 容量则统一池化。这要求独立 failover，并带来 KV 处理问题。Decode 跨多个 NPU（如 8 die），单卡故障会让其余卡空闲。早期采用“kill-P-to-preserve-D”：终止 Prefill 释放资源以重启 Decode。后来与 EP-LB 协同，支持 Decode 纵向缩容：减少 DP group 和 EP rank，用更少 NPU 继续运行；每个专家至少保留一个副本，多余副本平滑移除。

解释： EPLB 在这里不只是性能优化，也成为弹性冗余结构。前提是所有逻辑专家仍有至少一个物理副本，否则模型语义不完整。

P120 精翻： 阶段 3，细粒度错误处理。很多瞬态错误无需重启 engine。网络抖动（如交换机 flap、BGP 收敛）可能暂时中断通信，FlowServe 因而使用 token 重算：检测到特定错误码时，所有 DP group 协同回滚到上一迭代；专用线程广播 rollback，使忙轮询中的 DP 也能收到，然后重做该迭代。片上内存故障则与 CANN runtime 协作，重映射虚拟内存并屏蔽坏区；虽然可能丢失部分 KV、使个别请求失败，系统仍在线服务其他请求。

解释： token 重算需要迭代边界具备幂等性：输出 token 尚未对外提交，KV 写入可回滚或覆盖，所有 DP 对回滚 epoch 达成一致。论文没有说明流式输出已发送后的补偿策略。

procedure HANDLE_RUNTIME_FAULT(error, current_epoch):
    if error.kind == TRANSIENT_NETWORK:
        rollback_epoch = current_epoch - 1
        BROADCAST_TO_ALL_DPS({type: ROLLBACK, epoch: rollback_epoch})
        for dp in ALL_DP_GROUPS:
            dp.DISCARD_UNCOMMITTED_STATE_AFTER(rollback_epoch)
            dp.RESTORE_KV_CHECKPOINT(rollback_epoch)
        BARRIER_ON_ROLLBACK_EPOCH(rollback_epoch)
        REEXECUTE_ITERATION(rollback_epoch + 1)
        return RECOVERED

    if error.kind == ON_CHIP_MEMORY:
        bad_range = CANN_IDENTIFY_FAULT_RANGE(error)
        CANN_REMAP_VIRTUAL_MEMORY(bad_range)
        failed_requests = INVALIDATE_KV_OVERLAPPING(bad_range)
        FAIL_ONLY(failed_requests)
        return DEGRADED

    return ESCALATE_TO_COMPONENT_FAILOVER

图 F：补充机制图。将多级心跳、KV 链路探测、P/D 独立切换、token 回滚与内存坏区屏蔽放到统一故障生命周期中。

评测

峰值 Decode

P121 精翻： 作者评估在 CloudMatrix384 上运行 DeepSeek 的最大 Decode 性能。

解释： “maximum”意味着这是容量/峰值实验，应与后面的 production workload 分开。

P122 精翻： 实验使用单个 CloudMatrix384 中的 18 台 Ascend 910C 服务器，共 288 个 NPU die，Prefill 与 Decode 合设。系统配置 DP288、EP288：256 个 die 各放一个 routed expert 和一个冗余专家，另 32 个 die 各放一个 shared expert 和一个冗余专家；启用一个 MTP 层。每 DP/die 本地 batch 为 60，全局 batch 为

\[ 60\times288=17\,280. \]

所有请求先完成 Prefill，再同时进入 Decode。负载是从 ShareGPT 手工构造的固定 2K-token prompt，输出固定 2K token；开启 ignore-eos，MTP 与主模型均使用 greedy sampling。

解释： 这组设置主动移除了线上最难的变量：到达过程、长短序列混合、提前 EOS、sampling 分支与 Prefill/Decode 干扰。因此它适合测硬件/系统稳态上限，不代表单请求体验。

P123 精翻： 平均 TPOT 为 50 ms。一次 Decode iteration 包含 MTP forward、sampling、主模型与最终 sampling，约耗时 93 ms；迭代间 scheduler gap 约 2 ms。全部 DP 的 MTP 接受率约 90%，所以平均每轮产生 1.9 个有效 token：

\[ \operatorname{TPOT}=\frac{93+2}{1.9}\approx 50\text{ ms}. \]

每颗芯片有两个 die，每 die batch 为 60，因此单芯片吞吐为：

\[ 2\times60\times\frac{1000}{50}=2400 \text{ tokens/s/chip}. \]

DP288 总吞吐达到 345K tokens/s。图 20 给出约 3K 序列长度时一次 Decode 的 kernel 级分解。Attention 同时随序列长度与 batch 增长，占 21.8%，长序列下会继续增加。UB 使 dispatch/combine 较高效，但两者仍占总延迟约 36%。这些全局同步 kernel 方差很大，最大可达最小的 10 倍：dispatch 吸收所有 DP 的 MLA 计算方差，combine 吸收各专家的 MoE 不均衡。

解释： 公式的单位与计数一致，\(345\,000\approx 288\times60\times1000/50\)。但“2400 tokens/s/chip”依赖 60 的本地 batch；它不是单流 token rate。图中同步方差说明平均 50 ms 掩盖了明显尾部风险。

图 20：左侧是 kernel 时间占比，右侧是主要 kernel 的 min/max 方差；dispatch/combine 的全局屏障方差最突出。

P124 精翻： 作者还在一个包含 768 个 NPU die 的完整 CloudMatrix384 上评估 MoE-Attention 解耦 Decode，Prefill 在其他服务器执行。480 个 die 组成 3 个 DP domain，每个有 160 个 DP group；其余 288 个 die 运行 EP288。每 DP/die batch 为 96，全局 batch 为

\[ 96\times3\times160=46\,080. \]

负载同样固定为 2K 输入 + 2K 输出，启用 ignore-eos 与 greedy sampling。系统在 50 ms TPOT 下达到 2400 tokens/s/chip。正文称每层的 MLAProlog、MLA、Gating 与第一段 A2E 各约为 700 ns。TPOT 同时包含 MTP 与主模型 forward；最后一层第二个 microbatch 不能重叠。计入 2 ms scheduler、5 ms MTP、逐层计算 \((0.7\times2\times61)\) ms，以及 A2E 0.17 ms、MoE 0.12 ms、E2A 0.19 ms，总 forward 约 93 ms；MTP 接受率 90% 时：

\[ \operatorname{TPOT}=\frac{93}{1.9}\approx49\text{ ms}. \]

解释： 原文存在 1000 倍单位冲突。 若真是 \(700\text{ ns}=0.0007\text{ ms}\)，则

\[ 0.0007\times2\times61=0.0854\text{ ms}, \]

不可能构成 93 ms 的主要部分；正文后续明确使用 \(0.7\text{ ms}\)，即 700 μs。最合理的推断是“700 ns”为笔误，但在作者更正前，本文只能标注冲突，不能替作者改写证据。此外，逐项按文字简单相加时还需知道哪些算子被 0.7 ms 汇总、哪些另计，否则无法独立重建 93 ms。

生产负载

P125 精翻： 作者评估 xDeepServe 在生产负载下的性能。

解释： 这部分比峰值实验更接近用户体验，但只给一个代表性配置与平均指标。

P126 精翻： 生产 LLM 服务的难点是输入/输出长度高度变化且延迟要求严格。DeepSeek 与 K2 多数场景目标为 TTFT 小于 2 s、TPOT 35 ms。DeepSeek-R1 reasoning 模型支持最长 96K 输入、最多 32K reasoning token 与 32K 输出，受 128K context window 限制。长序列与短序列本质不同：长输入处理可达 30 分钟，Attention 复杂度使延迟随长度增加。为减少干扰，系统分配专用资源处理极端长请求，与短流量隔离。

解释： 专池隔离牺牲一部分统计复用，换取短请求尾延迟稳定。文中“30 分钟”是极端长输入处理时间陈述，但没有说明具体长度、并行配置与 TTFT 口径。

P127 精翻： 一个代表性生产部署包含 16 台 Ascend 910C 服务器、4 个 Prefill TE 与 1 个 Decode TE。每个 Prefill TE 跨 2 台服务器，配置 DP8、EP32；Decode TE 跨 8 台服务器，配置 DP128、EP128。工作负载输入为 0–64K token，平均 13K；平均输出 2.1K。该配置达到 900 ms TTFT 与 34.8 ms 平均 TPOT。

解释： 34.8 ms 略低于 35 ms 目标，但论文未报告并发量、QPS、输出 token 总量、缓存命中、P95/P99、错误率或硬件利用率，不能据此判断“多数请求满足 SLA”的比例。

怎样正确理解性能数字

场景	设备/并行	负载	报告结果	可以说明	不能说明
合设峰值	288 die，DP288/EP288	固定 2K+2K，batch 60/die	50 ms TPOT，2400 tokens/s/chip	稳态容量上限	异长线上尾延迟
MA 解耦峰值	768 die，3×160 DP + EP288	固定 2K+2K，batch 96/die	49–50 ms TPOT，2400 tokens/s/chip	解耦拓扑可达到同量级峰值	单位冲突下的逐项复算
代表性生产	16 server，4P1D	0–64K，均值 13K+2.1K	900 ms TTFT，34.8 ms 平均 TPOT	一组真实混合长度均值	P99、QPS、成本与普适性

结论

P128 精翻： xDeepServe 展示了如何通过全系统协同设计，在 SuperPod 基础设施上高效服务大型 MoE。它解耦 Transformer 组件、引入内存语义通信层，并用 FlowServe 去中心化执行，从而在数百 NPU 上维持高吞吐与低延迟。系统在生产中运行 DeepSeek，并以 50 ms TPOT 达到 2400 tokens/s/chip。作者认为，随着模型与硬件持续扩展，解耦执行将成为未来 LLM 推理系统的基础。

解释： 论文最强的贡献是把硬件共享内存、通信协议、服务调度、模型解耦和故障恢复连接成同一设计；最弱的部分是可复现性和证据完整度。最后一句属于趋势判断，数据流化阶段仍有一致性与状态管理难题。

贡献者

P129 精翻： 本段为贡献者姓名列表，专有名词不作翻译，按 v6 原序保留：

Ao Xiao、Bangzheng He、Baoquan Zhang、Baoxing Huai、Bingji Wang、Bo Wang、Bo Xu、Boyi Hou、Chan Yang、Changhong Liu、Cheng Cui、Chenyu Zhu、Cong Feng、Daohui Wang、Dayun Lin、Duo Zhao、Fengshao Zou、Fu Wang、Gangqiang Zhang、Gengyuan Dan、Guanjie Chen、Guodong Guan、Guodong Yang、Haifeng Li、Haipei Zhu、Hao Feng、Hao Huang、Hao Xu、Hengrui Ma、Hengtao Fan、Hui Liu、Jia Li、Jiang Liu、Jiang Xu、Jie Meng、Jinhan Xin、Junhao Hu、Juwei Chen、Lan Yu、Lanxin Miao、Liang Liu、Linan Jing、Lu Zhou、Meina Han、Mingkun Deng、Mingyu Deng、Naitian Deng、Nizhong Lin、Peihan Zhao、Peng Pan、Pengfei Shen、Ping Li、Qi Zhang、Qin Zhang、Qingrong Xia、Qingyi Zhang、Qunchao Fu、Ren Guo、Ruimin Gao、Shaochun Li、Sheng Long、Shentian Li、Shining Wan、Shuai Shen、Shuangfu Zeng、Shuming Jing、Siqi Yang、Song Zhang、Tao Xu、Tianlin Du、Ting Chen、Wanxu Wu、Wei Jiang、Weinan Tong、Weiwei Chen、Wen Peng、Wenli Zhou、Wenquan Yang、Wenxin Liang、Xiang Liu、Xiaoli Zhou、Xin Jin、Xinyu Duan、Xu Li、Xu Zhang、Xusheng Chen、Yalong Shan、Yang Gan、Yao Lu、Yi Deng、Yi Zheng、Yingfei Zheng、Yiyun Zheng、Yizhou Shan、Yong Gao、Yongqiang Yang、Yuanjin Gong、Yue Yu、Yuetao Chen、Yukun Zhu、Yulong He、Yusu Zhao、Yuyan Wu、Zenan Zhang、Zhaojin Zhuo、Zhaoyang Ji、Zhefeng Wang、Zheng Wang、Zhenhua Yang、Zhenli Sheng、Zhibin Yu、Zhigang Ji、Zhihao Ren、Zhipeng Bian、Zhixia Liu、Zhiyu Dong、Zhonghua Li、Zhou Yu、Zhuoming Shen、Zhuwei Peng、Zi Ye、Zihao Xiang、Zimin Fu、Zixuan Zhang。

解释： 论文署名为 xDeepServe Team，本段列出完整贡献者群体，说明这是跨硬件、通信、框架、服务与运维的大型工程项目。

方法对象总账

机制	输入	输出	持久状态	通信/同步	主要失败边界
XCCL P2P	KV/任意 buffer、event ID、peer	远端应用 buffer	pair ring、metadata	tail publish + ACK	slot 泄漏、乱序、远端写不可见
Dispatch/Combine	hidden state、top-\(k\)、gate weight	专家输入/聚合 token	rank 分区 buffer	全 rank 元数据屏障	最慢 DP/专家扩散
A2E/E2A	Attention token、专家输出	专家输入、Attention token	trampoline buffer	两阶段路由	trampoline 拖尾或故障
PD 解耦	request、KV block 地址	Decode-ready request	RTC/DistFlow task、KV 所有权	异步 SEND/RECV + TP 对齐	接收容量、语义错配
EPLB	分时专家 token count	副本选择与放置	权重槽、映射版本	周期上报、异步换权重	热点漂移、映射中间态
MA 解耦	每层 Attention 输出	每层 MoE 输出	DP domain 队列、persistent state	A2E/MoE/E2A 流水	全局屏障与忙轮询
可靠性	心跳、探测、错误码	failover/rollback/remap	epoch、KV checkpoint、专家映射	广播回滚/健康协调	误判、非幂等提交

局限与待验证问题

1. 代码与复现：没有公开 xDeepServe、XCCL、FlowServe 生产实现、部署清单或实验脚本。
2. 指标完整性：生产只报告平均 TTFT/TPOT，缺少 P95/P99、QPS、错误率、资源利用率与多租户干扰。
3. 基线与消融：没有系统比较 NCCL/HCCL/DeepEP、集中式 FlowServe、无 EPLB、无 GC 控制、无 Transformerless 的端到端结果。
4. 成本与能耗：没有每百万 token 的芯片时、功耗、机器成本或网络成本。
5. 模型质量：INT8 与 KV 量化缺少公开精度表；第二 MTP 使用内部 28 万样本，数据分布不可验证。
6. 数值一致性：P083 的 9% 与 2.26→2.35 不符；P124 的 700 ns 与 0.7 ms 相差 1000 倍。
7. 数据流愿景：无全局同步的设计尚未实现，乱序、部分结果、一致性、背压与故障恢复仍待解决。

不要把峰值吞吐当成单请求速度

2400 tokens/s/chip 是高并发 batch 在一颗双 die 芯片上的聚合吞吐。在 50 ms TPOT 下，单条序列仍大约每秒产生 20 个 token；吞吐来自每 die 同时推进 60 或 96 条序列。

可迁移的设计原则

即使没有 CloudMatrix384，也可以复用四个思路：把计算受限与内存受限阶段分池；让高频 token 路径绕开中心控制器；把全局屏障前的方差作为首要优化对象；为状态所有权交接设置显式 completion 与 backpressure。

原图清单

本文已收录 v6 PDF 中全部 20 个编号 Figure：

1. xDeepServe 总体架构
2. CloudMatrix384 与 Ascend 910C
3. 单算子与图模式
4. XCCL Send/Receive
5. Send/Receive 评测
6. Dispatch/Combine 评测
7. Pull-based Dispatch
8. A2E/E2A
9. FlowServe 架构
10. DeepSeek 执行时间线
11. 专家负载均衡动机与性能
12. EPLB 总览
13. MTP 流程
14. INT8 量化总览
15. 激活/权重平滑
16. Transformerless 演进
17. Prefill-Decode 解耦
18. MoE-Attention 解耦架构
19. MoE-Attention 执行流水线
20. Decode kernel 延迟分解

另补充 5 幅可编辑机制图与 1 幅概念插图；它们用于解释，不属于原论文证据。

参考资料

• xDeepServe Team. Huawei Cloud Model-as-a-Service on the CloudMatrix384 SuperPod, arXiv:2508.02520v6, 2026.
• Huawei. Ascend C Programming Guide.
• Zhong et al. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, 2024.
• Jiang et al. MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism, 2025.
• 原论文的其他引用与完整 BibTeX 以 v6 PDF 为准。

评论