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

一台加速卡跑不下、几百张卡又容易互相等待时，问题就不再只是“算力够不够”，而是谁负责算、谁负责搬、状态放在哪里、下一步在等什么。本文以知乎学习笔记为线索，回到原始论文逐项核验，用“超级厨房”“专家快递”和“共享图书馆”三个直觉，解释 CloudMatrix384 服务 DeepSeek-R1 的四个关键机制。

小 batch LLM 推理并不总是被矩阵乘法本身限制。数十到数百个 kernel 的启动边界、kernel 尾部气泡、中间张量写回 HBM，以及 MoE 的 Dispatch/Combine 通信，都可能让计算单元等数据、让内存等指令、让互联等计算。MegaKernel 的核心不是“把代码写得更大”，而是把 host 侧的算子调度下沉为 GPU 内部的任务系统。

本文沿三条路线展开：Hazy Research 的手写整模型 MegaKernel、MPK 的编译器与常驻运行时、DeepSeek MegaMoE 的 expert-wave 通信计算流水。结论是：这类优化用更强的静态专用化和片上资源约束，换取更少的启动边界与更细的就绪事件；收益必须与寄存器、共享内存、HBM、互联、功耗和动态路由一起核算。

“降低显存”不是一种动作。它可能是在减少对象大小、限制同时在途的对象数量、把对象搬到 CPU、缩短对象生命周期，也可能只是把 allocator 中未占用的缓存块归还给驱动。

本文固定到 XTuner 397b 分支 commit e949653，从一个第一次接触训练显存优化的读者视角，拆解原始清单中的 13 个技术点。每项都回答：大对象是什么、为什么形成峰值、执行时序怎样、数据流经过哪里、伪代码如何写、适用于什么条件，以及效果边界在哪里。

MoE 和模型压缩看似方向相反：前者扩大总参数，后者缩小部署对象。它们实际都在重写“每个 token 访问哪些参数”。DeepSpeed-MoE/MoE Inference 管理稀疏路由和专家放置；Model Compression/MoQ 管理层、权重和精度的删减。

Kimi K3 的 NPU 适配不是给现有 MLA-MoE 模型换一组配置。它同时引入 Kimi Delta Attention（KDA）、Block Attention Residuals（AttnRes）和 Stable LatentMoE，分别改变层内状态、跨层残差和专家通信。

截至 2026 年 7 月 20 日，官方已确认 K3 是 2.8T 参数、原生多模态、1M 上下文、896 专家激活 16 个，并采用 3× KDA + 1× Gated MLA；但完整权重、精确 config 和技术报告仍待发布。因此本文严格区分 已确认事实、组件证据、工程推导和发布后必验项，目标是形成可执行的 NPU bring-up 与性能优化计划，而不是制造一份猜测配置。

XTuner 的 Domino EP 不是一种新的 EP 通信算子，而是位于 MoE 层内部的跨微批调度方法：把多个原本独立做梯度累积的 micro-batch 一起送入模型，用异步通信流把一个 micro-batch 的 token dispatch/combine 与另一个 micro-batch 的专家计算重叠。

普通 EP 定义专家如何切分；All-to-All、DeepEP、AGRS 决定 token 如何搬运；Domino EP 决定多个 micro-batch 如何交错；MC2 则把相邻通信和矩阵乘融合进一个算子。只有先分清这些层次，才能正确讨论它们的优劣和组合关系。

HybridEP 论文进一步提出了一个更上游的问题：跨数据中心带宽太低、通信已经无法完全隐藏时，是否还应坚持“专家不动、所有 token 都跨域搬运”？它通过比例 (p) 在 token All-to-All 与压缩 expert AllGather 之间选择，改变的是通信对象与专家放置，而不是给 DeepEP 或 MC2 换一个名字。

2026 年 8 月的增量观察再补两层：MoonEP 与 UltraEP 都根据当前 micro-batch 的真实路由结果复制热点 expert，但 MoonEP 自己拥有 dispatch/combine 并追求每 rank 固定 S×K 行，UltraEP 则把配额规划、跨层副本 buffer 和权重/梯度同步做成独立运行时，继续复用外部 dispatcher 与 Grouped GEMM。HyperParallel-MoE 则在 Ascend A3 上把 Dispatch、两次 GMM、SwiGLU 和 Combine 编译成 AIC/AIV 瓦片任务流。这些路线分别回答“热点怎么摊平”和“单个 MoE-FFN 怎么细粒度交错”，都不是 XTuner 当前已有开关。

模型训练建模不是先问“MFU 有多高”，而是先把模型结构、硬件账本、并行切分、调度路径和实测校准放到同一个估算器里。MFU 是其中最干净的计算口径：它把模型理论必需 FLOPs、设备峰值和实测步时连在一起；但显存能不能放下、通信会不会卡住、padding 是否浪费、EP/TP/SP 是否合适，必须另算。

GMM 在 Qwen3.5 MoE 里的接入点是 routed experts 的两次矩阵乘：hidden -> gate/up 和 intermediate -> hidden。shared_expert 仍是普通 Qwen3_5MoeMLP，attention 不动，Dense 版 Qwen3.5 的普通 MLP 也不是替换对象。

PR #2664 的公开 diff 主要是给 mindspeed_mm.fsdp.ops.moe_ops.gemm.grouped_matmul 增加 fused/eager 一致性 UT，并放宽 unpermute UT 容差；它可以作为 GMM wrapper 接口被测试覆盖的证据，不能写成完整功能接入 PR。[^gmm-pr-api][^gmm-pr-files]

MC2 的核心不是异步通信，而是 fused operator 内部的计算/通信切分与流水。MindSpeed-LLM 文档里的典型场景是 TP/SP 下的 matmul + all_reduce/all_gather/reduce_scatter；MindSpeed-MM PR #2480 接入的是 MoE expert parallel 下的 AllToAllv + GroupedMatmul 和 GroupedMatmul + AllToAllv。

本文只记录可迁移信息：PR 改了哪些文件、ep_mc2_forward 怎么跑、迁移前检查什么、怎么验证、哪些结论不能从公开资料直接外推。