Kimi K3公开了不少秘密，但最重要的Infra却很难抄

Kimi K3 的技术报告终于公布了，而且这次诚意不小——不仅模型架构讲得细，连 Infra 层面也披露了不少细节。

先说 Infra 是什么。简单来说，硬件是手机外壳，AI 是 App，那 AI Infra 就是中间的操作系统——没有它，硬件就是一块砖头。

行业里有个共识越来越清晰：国产开源大模型未来的商业化，一个重要支撑点在于大模型厂商自己部署模型时，成本可以比第三方低好几倍。这个差距，靠的就是 Infra 上的技术积累和经验。

OpenAI 的核心工程师翁家翌之前说过一句话：大模型训练的核心差距在 Infra，工程师的主要工作就是给 Infra 修 bug。

这句话点出了关键——当模型架构逐渐趋同、公开数据和蒸馏技术让部分能力复现门槛降低之后，Infra 工程能力就成为拉开训练成本、部署效率和运行稳定性的核心差距之一。

那么，Kimi K3 的技术报告有没有把 Infra 的秘密说透？从商业角度推测，大概率是有所保留的。这意味着，一百个公司部署一百个 Kimi K3，可能跑出一百种不同的效率。

不过，既然公布了这么多细节，该学的还是要学。而且 Infra 对很多非从业者来说确实是个比较陌生的领域，所以这篇文章就借 Kimi K3 技术报告里一些有趣的 Infra 技巧，来聊聊 AI Infra 的核心原则。

为什么 Infra 如此重要？

前面提到，OpenAI 工程师说训练大模型主要就是修 Infra 的 bug。那这个 bug 到底指什么？

在大模型团队的日常语境里，Infra bug 既包括那种导致结果错误、训练不稳定或任务中断的传统 bug，也包括那些不影响数学正确性、却会造成 GPU 等待、内存浪费、通信阻塞和吞吐下降的系统性问题。

更直白地说，就是在保证计算逻辑正确的前提下，看 GPU 是被充分利用了，还是大量算力在闲置。就算 GPU 满负荷运转，还要看有没有大量不必要的重复计算，计算负载是否均衡、是否稳定。要满足这些条件，还需要大量通信在 GPU 之间做负载协调，而通信本身又可能成为新的瓶颈。

是评估训练效率的核心指标，它是“观测吞吐量”与“理论最大吞吐量”的比值。理论最大吞吐量假设达到峰值浮点运算的 100%。

从行业数据来看，大模型训练效率还有很大提升空间。目前公开可验证的万卡、千亿参数、完整 LLM 预训练案例中，字节跳动的 MegaScale 以 55.2% 的 MFU 仍是最有代表性的最高纪录之一。今年 4 月甚至出现了一个极端反面案例——据《The Information》报道，

，远低于业界 35%-45% 的正常水准，也不及 Meta（43%）、谷歌（46%）等竞争对手，可以说是相当尴尬。

更高的训练效率意味着更短的训练周期、更低的训练成本、更多可尝试的实验、更大的数据量或模型规模。这些价值是不言而喻的。

不过，由于没有足够的数据和参数参考，很难独立判断技术报告中哪些 Infra 技术最重要或贡献最大。所以，这里主要从 Kimi K3 自主提出的架构设计入手——比如 KDA、AttnRes、MoonEP——看看它们背后的 Infra 技巧体现了哪些核心原则，

。

总体设计

先看看 Kimi K3 的分布式系统设计。它采用的并行方法都比较经典，比如流水线并行、专家并行、ZeRO 分片等。

大模型训练的“并行化”可以这样理解：训练过程包含大量串行步骤，比如从前向传播到反向传播，必须一步步来。但细节上又存在大量矩阵计算，而这些计算天生可以并行。此外，单张 GPU 的内存也装不下超大参数规模的所有数值。

所以，大模型训练通常从模型参数、训练数据和中间激活值等不同维度进行切分，把计算和存储任务分配到多张 GPU 上，通过合理的并行策略和调度机制，尽量减少 GPU 等待和空转。

举个例子，可以把模型的不同神经网络层放到不同 GPU 上依次计算，这叫

。由于后面的 GPU 必须等前面的 GPU 产生中间结果，流水线中容易出现部分 GPU 空闲的“气泡”。实际训练中通常会把一个 batch 切成多个微批次，让不同 GPU 同时处理不同微批次，提高流水线利用率。

如果模型的某一层规模很大，单张 GPU 无法容纳，或者单卡计算速度不足，还可以把这一层中的权重矩阵和矩阵运算拆分到多张 GPU 上共同完成，这叫

。张量并行会在同一层计算过程中频繁交换数据，对 GPU 之间的互联带宽和通信延迟要求很高。当通信耗时接近甚至超过计算耗时时，就需要在并行规模、计算效率和通信开销之间权衡。

以上只是原理层面的简单科普，

补充一个值得注意的细节：技术报告显示“MoE 层使用在各 EP rank 之间复制的共享专家”，

。这样共享专家可以尽可能吸收数据中的共有特征（rank 可以理解为一个参与分布式通信的计算进程，实际部署中通常一个 rank 对应一张 GPU，为简单起见，本文把 rank 都理解为单个 GPU）。

接下来，我们重点看看 Kimi K3 的模型架构核心机制——KDA 和 AttnRes，在匹配的 Infra 设计上有什么巧思，以及 Kimi K3 为优化 MoE 架构专家并行特有难题提出的 MoonEP，体现了什么原则。

KDA

先看混合 KDA 注意力机制。

KDA 全称 Kimi Delta Attention，

。如何理解它的“线性”特点？

标准注意力机制的核心在于注意力的计算，用每个输入 token 计算出对应的 Query、Key、Value 向量（简称 Q、K、V）。

借用搜索引擎的比喻：Q、K、V 好比搜索查询词、网页索引库、网页内容。标准注意力机制会先让搜索查询词和网页索引库配对——也就是 Q 和 K 先相乘，然后再去匹配网页内容。

——数学上是一个随着输入长度增长而平方增长的矩阵，这也是制约大模型 Scaling Law 的核心因素。在自回归推理中，还需要保存随序列长度线性增长的 KV cache。

KDA 的改变在于：让网页索引库和网页内容先配对——也就是 K 和 V 先相乘，再用查询搜索词去匹配。K 和 V 相乘好比是对可检索的网页内容先进行总结，

在更精细的结构中，KDA 继承 Gated DeltaNet，加入并精细化了这个“总结网页内容”也就是模型记忆库的管控结构，使其可以在推进推理的过程中，合理地忘记部分内容，并记住新内容（所以严谨来说，KDA 实际还包含遗忘门，并不是简单地把所有 K 和 V 相乘后累加）。

KDA 绕开了标准注意力机制的完整记忆矩阵，但这也是有代价的——引入了串行依赖：后一个 token 的状态必须等前一个 token 计算完成。

所以，这个方法在 Kimi K3 这个参数体量下，也会遇到算力瓶颈——它是串行更新的，而 GPU 天然偏好大规模、高带宽并行计算，容易导致算力利用率不足和浪费。

优化方式基本就是把其中

。

月之暗面提出了 FlashKDA，把 token 进行分块（chunk）计算，chunk 内部可以并行计算，chunk 之间仍需依次传递递归状态。

在不同设备（或 GPU）之间，Kimi K3 采用更进一步的 KDA 上下文并行（KCP）方法，来提升并行度。

对于标准的线性注意力记忆递归计算，每个输入序列分段的状态转移可以在不知道输入状态的情况下独立求值，随后再精确合成递归链条。

通俗来说，

。

但对于 KDA，这样并不直接可行，因为其状态转移函数具有前面提到的记忆遗忘机制，在数学上导致一些额外困难。KCP 的做法是，把状态转移中可以独立计算的部分尽可能拆解出来，再分到不同的 GPU 进程中去独立、并行计算。细节比较复杂，这里就不展开了。

AttnRes

接下来看注意力残差 AttnRes 机制。

标准残差连接是指，一层神经网络在处理前面层传入的输入时，不是把原来的信息完全替换掉，而是只学习“需要修改或补充的部分”，再把这部分加回原输入，即“输出 = 原输入 + 本层计算结果”。

，使原始信息和梯度能沿网络直接传递，从而让很深的模型更容易训练，也减少信息在多层处理中被破坏或遗忘。

但随着神经网络深度增加，也会稀释靠前每一层的贡献。注意力残差 AttnRes 就是为了克服这一点而提出的，它让对原输入的继承更加建立在基于语义理解的筛选上。

然而，额外引入的注意力机制在大参数模型中，也会带来新的内存负担，

Block AttnRes 将神经网络层分为多个块，块内使用标准残差连接，块间使用注意力机制。研究表明，在约 8 个块的情况下，它能达到 AttnRes 的大部分性能优势。

当然，Block AttnRes 本身引入的内存开销也不可忽视，仍然需要进一步优化。

注意力机制是在块间进行的，且需要随着前向传播的演进计算多次。

所以，块表示只需要计算一次，就可以长期保留在 GPU 中并重复使用。比如按 6 层为一个块，前 6 层的块表示可以被后 6 层在注意力计算时使用，也可以被后 7 到 12 层使用。

AttnRes 相比标准残差连接需要额外计算注意力机制相关的中间结果，比如注意力分数等，这些结果在反向传播中也要用到。但如果一直保留到反向传播阶段，会占用大量内存。

因此 Kimi K3 选择在前向传播时不在内存中保存这部分中间结果，等反向传播阶段再重新计算这些数值，

。

此外，由于训练还采用了流水线并行——模型不同的层放在不同的 GPU 上——它们在计算注意力残差时需要用到其它块的块表示，而这些块表示还保存在其它块所在 GPU 上。

由于这些层之间存在串行关联，

。比如，把 GPU0 的 Block_0 的表示 B_0 传递给 GPU1 的 Block_1 之后，GPU1 将 B_0 缓存；等 Block_1 计算出表示 B_1 后，将 B_0、B_1 一起传递给 GPU2 的 Block_2，GPU2 将 B_0、B_1 缓存。

最后，这些块表示仅限于在一个微批次的训练数据中可重复使用，因此在微批次训练结束后可以释放。

综合以上手段，Block AttnRes 的优化方案做到了：

- 不重复计算同一个块；

- 不保存可以重算的中间激活；

- 不重复传输已经缓存的块；

- 不保留已经失效的微批次块；

MoonEP

最后看 MoonEP 的机制原理。

在 MoE 架构的大模型中，每个输入 token 可能激活不同的专家。反过来，对于任意一段输入 token，输入每一个专家的 token 数量可能都不同，进而造成激活形状的动态变化。

在传统专家并行中，每个专家固定放在某个 GPU 上，而路由器不会保证 token 被平均分配给这些专家。

同时，路由专家每轮收到的 token 数不断变化，使中间张量时大时小，GPU 需要频繁申请和释放不同大小的显存块，留下许多难以复用的不连续空洞，从而浪费显存、增加分配开销。在这种内存碎片化的情况下，虽然零散的剩余显存总量可能不少，但单个新的张量或通信缓冲区需要一块足够大的可用空间，分散的小块无法直接拼成一次有效分配。

为此，Kimi K3 提出了 MoonEP 方法，

——接收 S×K 个 token，其中 S 是序列长度，K 是每个 token 选择的专家数量。

而一个 GPU 里不同的专家还是可能分配到不同的任务量，所以需要在 GPU 中配置冗余专家，以应对随时增加的计算负载。

冗余专家本身是一个高负载专家（即被分配了较多 token 的专家）的复制，作用是为高负载专家分摊计算任务，从而缩短最忙碌 GPU 的工作时间。

（比如专家总数为 100，参与专家并行的 GPU 数量是 20，每个 GPU 最多需要 100/20=5 个冗余专家），。

过去的方案一般会设置固定的冗余专家数量，或设置单个 GPU 的 token 上限，容易因为无法满足条件使训练被迫终止。

，并确保冗余专家数量不超过上限。

写在最后

回顾一下，以上三个 Infra 技巧关注不同的方面：KDA 关注串行过程的并行化，AttnRes 关注计算的重复性，MoonEP 关注负载均衡。

凡是串行链条，就寻找可并行拆解的部分；凡是重复计算、存储和通信，就判断能否重算、缓存或增量传输；凡是动态负载，就尽可能把它转化为可预测、可调度的静态形状。

单个优化看起来可能只节省几个百分点，但当模型扩大到万亿参数、训练持续数月时，每个百分点都会被放大成巨额算力、时间和资金。

不过需要提醒的是，本文关注的这三个点，相对于技术报告的整个 Infra 章节也只是冰山一角。

不同芯片、网络、模型结构和业务场景，都会产生不同的最优解。技术报告能帮助后来者少踩一些已知的坑，但真正决定部署效率的，仍然是团队能否在长期运行中发现并修复自己遇到的 Infra bug。

总之，模型架构决定了能力的可能性，而 Infra 决定了这种可能性能否以可承受的成本，稳定地变成现实。