第一次看到 Kimi K3 的参数，我的反应和很多人一样：

2.8 万亿参数，又是一场模型规模竞赛。

但把技术报告完整看下来之后，我发现自己一开始理解错了。

2.8 万亿只是最容易传播的数字，却不是 K3 最值得研究的地方。

真正重要的是，Kimi 在尝试同时解决四个过去很难一起解决的问题：

上下文越来越长，计算不能爆炸
网络越来越深，信息不能丢失
模型越来越宽，参数不能全部参与计算
Agent 工作越来越久，任务状态不能中断

官方公布的数据很夸张：

• 总参数量约 2.8 万亿；
• 每个 Token 实际激活约 1040 亿参数；
• 93 层网络；
• 896 个路由专家，每个 Token 选择 16 个；
• 69 层 KDA 与 24 层 Gated MLA；
• 原生支持图像输入；
• 上下文窗口达到 1,048,576 Token。

但这些数字放在一起看，真正暴露出的不是“模型有多大”，而是另一个问题：

一个拥有 2.8 万亿参数、100 万 Token 上下文的大模型，到底怎样才能训练出来，并且真的跑起来？

Kimi K3 给出的答案，不是一项神奇的新算法，而是一整套从模型结构、优化器、分布式训练、量化、缓存，到 Agent 强化学习的系统工程。(arXiv)

这篇文章不打算简单罗列 KDA、MoE、Muon 这些名词。

我想把它们重新串起来，讲清楚 Kimi K3 到底做了什么，以及这些技术为什么值得我们学习。

---

一、先别急着看技术名词，K3 实际只解决了四件事

理解 Kimi K3，最好的入口不是参数表，而是信息流。

一个大模型变大之后，信息需要沿着四个方向流动。

第一个方向：上下文长度

模型读到几十万甚至上百万 Token 后，怎样继续使用早期信息？

K3 使用 KDA 和 Gated MLA 的混合注意力处理这个问题。

第二个方向：网络深度

信息经过几十层 Transformer 后，怎样避免早期的重要特征被不断覆盖？

K3 使用 Attention Residuals，也就是 AttnRes。

第三个方向：模型宽度

模型拥有数万亿参数后，怎样只调用其中真正有用的一小部分？

K3 使用 Stable LatentMoE。

第四个方向：任务时间

Agent 连续工作几小时、调用几百甚至几千次工具后，怎样保持目标、文件和执行环境不丢失？

K3 使用长程强化学习、Partial Rollout、外部缓存和可恢复沙箱。

把这四个方向放在一起，K3 的整体结构就不再神秘了：

序列长度：KDA + Gated MLA
网络深度：Attention Residuals
模型宽度：Stable LatentMoE
任务时长：Long-Horizon RL + Cache + Sandbox

官方技术报告也明确把 K3 的架构概括为沿着序列长度、网络深度和模型宽度三个方向扩展信息流；后训练和基础设施又进一步把这种扩展延伸到了百万 Token 的长程 Agent 轨迹。(arXiv)

这就是读懂 K3 的总框架。

---

二、KDA 最反直觉的地方：它不是保存历史，而是修改记忆

过去我们理解长上下文，通常会有一个很自然的想法：

上下文越长，就把更多历史 Token 保存下来。

这正是传统 Attention 的工作方式。

假设项目群里依次出现四条消息：

9:00：项目正在开发
10:00：项目延期
11:00：项目已经审批通过
12:00：项目最终完成

现在问模型：

项目目前是什么状态？

传统 Attention 会把四条消息全部保存下来。

回答问题时，它重新查看这些历史消息，计算当前问题和每一条消息之间的关系，最后找到“项目已经完成”。

这种机制的优点很明显：原始历史都还在，模型随时可以回头查。

问题也同样明显。

上下文越长，需要保存的 Key 和 Value 越多；进行完整 Attention 时，Token 之间还要进行大规模的两两交互。到了几十万甚至上百万 Token，显存、带宽和计算成本都会急剧增加。

KDA 换了一种完全不同的记忆方式

KDA 不准备把每一条历史消息都作为独立档案永久保留下来。

它更像维护一份不断更新的项目状态表：

项目状态：已完成
审批状态：已通过
延期风险：已解除

但这里还有一个关键问题。

如果只是把每条新信息不断叠加进去，那么“开发中”“延期”“审批通过”“完成”可能全被写进同一份记忆，最后互相干扰。

KDA 使用的 Delta Rule，解决的正是这个问题。

它不是看到新信息后直接写入，而是先问：

根据我现在的记忆，我会预测出什么？

假设模型当前认为项目状态是“审批通过”，最新消息却告诉它“项目已经完成”。

这时 KDA 写入的重点，不是再复制一份“项目完成”，而是计算：

旧记忆预测：审批通过
最新真实状态：已经完成
两者之间的误差：需要把状态从审批通过修正为完成

然后用这个误差更新内部状态。

用一句不严谨但很好理解的话概括：

新记忆 = 保留下来的旧记忆 + 对旧记忆错误部分的修正

这也是 KDA 最值得学习的思想：

它把记忆从一份静态历史档案，变成了一个可以在线学习、持续纠错的内部模型。

KDA 还使用了按通道控制的保留机制。不同记忆通道可以拥有不同的遗忘速度：有的通道适合保存短期位置关系，有的适合保存长期语义，有的应该被快速覆盖，有的需要长期保留。官方报告将其描述为带有 channel-wise retention factor 的 Delta Rule 更新。(arXiv)

---

三、既然 KDA 这么高效，为什么 K3 还保留传统 Attention？

这个问题非常关键。

如果 KDA 可以把历史压缩进固定状态，K3 为什么不把全部注意力层都换成 KDA？

答案是：

压缩可以提高效率，但压缩不可能永远无损。

假设一百万 Token 的上下文中，有一段很早的代码：

MAX_RETRY_COUNT = 17

到了几十万 Token 以后，模型突然需要准确找回这个变量名和数值。

KDA 可以维护代码整体结构、业务目标和执行状态，但要在固定大小的记忆中永久保存每一个变量、数字和字符细节，并不容易。

因此，K3 没有押注单一注意力机制。

它采用了一种混合结构：

KDA
KDA
KDA
Gated MLA

每个 Block 包含 3 层 KDA 和 1 层 Gated MLA，这个 3:1 的结构贯穿整个主干网络，最后还额外放置了一层 Gated MLA，保证模型输出之前一定会进行一次全局注意力计算。(arXiv)

两种注意力形成了非常清晰的分工。

KDA 像不断整理资料的秘书

它负责：

• 持续更新状态；
• 压缩长期历史；
• 修正已有记忆；
• 用较低成本处理大部分上下文。

MLA 像定期翻查原始档案的审计员

它负责：

• 重新进行全局信息交互；
• 找回精确的远距离关系；
• 减少状态压缩造成的信息损失；
• 在关键位置给递归记忆纠偏。

所以 K3 的路线不是“线性注意力淘汰完整 Attention”。

它选择的是：

让便宜的递归记忆承担大部分工作，让昂贵的全局 Attention 定期校准。

在更早发布的 Kimi Linear 实验中，这种 3:1 混合架构在一百万 Token 场景下，KV Cache 最多降低约 75%，解码吞吐最高达到完整注意力基线的 6 倍。不过需要注意，这是 Kimi Linear 论文中的实验结果，不能直接等同于 K3 的线上推理提升。(arXiv)

这里真正值得学习的，是混合架构思维：

工程上很少存在一个模块同时拥有最高精度、最低成本和最好扩展性。成熟的方案通常是让不同模块处理自己最擅长的问题。

---

四、AttnRes：Transformer 解决了 Token 的传话问题，K3 又开始解决层的传话问题

KDA 解决了信息怎样沿着长序列传递。

但还有另一个很容易被忽略的问题：

模型拥有 93 层之后，信息怎样沿着网络深度传递？

传统 Transformer 虽然使用了残差连接，但网络整体仍然很像一条流水线：

第1层 → 第2层 → 第3层 → …… → 第93层

第 80 层接收到的，主要还是第 79 层已经加工过的状态。

第 79 层的状态又来自第 78 层。

信息就这样不断传递、混合和改写。

这和小时候玩的传话游戏非常像。

第一个人说：

今天下午三点在操场集合。

传到最后，可能只剩：

下午去操场。

信息通常不是突然消失的，而是在一次次加工中被慢慢稀释。

普通残差连接仍然存在一个隐蔽瓶颈

残差连接会把旧状态加回来，所以深层网络比过去更容易训练。

但它仍然把此前大量信息压缩进当前这一个状态中。

第 80 层不能明确地说：

我现在需要第 3 层识别出来的词法特征，再加上第 25 层形成的结构关系。

它只能继续接收前面层已经混合好的结果。

K3 的 Attention Residuals 做了一件很有意思的事：

把 Attention 从 Token 维度搬到了网络深度维度。

过去的 Attention 是：

当前 Token 应该关注哪些历史 Token？

AttnRes 问的是：

当前层应该关注哪些历史层？

于是每一层不再只是被动接收上一层的输出，而是可以根据当前需要，从早期层、当前 Block 和前面 Block 的表示中选择性取回信息。

官方报告对传统残差结构的描述很直接：标准残差连接会把此前信息压缩进单一状态，形成一个类似 RNN 时间递归的深度瓶颈；AttnRes 则允许当前层选择性访问此前表示。(arXiv)

为什么不保存全部 93 层的完整输出？

因为那又会带来新的存储和通信成本。

K3 使用的是 Block AttnRes。

它把网络划分成若干 Block，在 Block 内部积累信息，在 Block 之间保留阶段性表示。这样，后续层仍然可以访问早期阶段的特征，但不必长期保存每一层的完整输出。

报告显示，K3 按约 12 层一个 Block 进行组织，并通过 Block 级表示把存储和跨设备通信开销从与层数相关的形式，降低为与 Block 数量相关。(arXiv)

可以把它想象成写一篇长论文。

普通 Transformer 是一直往后写，每一章主要参考上一章。

AttnRes 则会为不同阶段保存目录和索引：

原始问题定义
第一阶段分析
第二阶段实验
第三阶段结论

写到最后一章时，不必依靠前一章转述，模型可以直接调取早期真正需要的信息。

这比“增加一条残差连接”重要得多。

KDA 解决的是序列方向的记忆瓶颈。

AttnRes 解决的是网络深度方向的记忆瓶颈。

---

五、2.8 万亿参数为什么没有让计算量一起爆炸？

答案当然是 MoE。

但只说“每次从 896 个专家中选 16 个”，还没有讲到 K3 的核心。

K3 总参数约 2.8 万亿，但每个 Token 实际激活约 1040 亿参数。模型包含 896 个路由专家，每个 Token 选择其中 16 个，另外还保留两个共享专家。(GitHub)

很多人看到这里，会直接计算：

2.8万亿 × 16 ÷ 896

然后认为这就是实际激活参数。

这种算法并不成立。

因为一次前向计算中，除了被选择的路由专家，还包括：

• 共享专家；
• Attention 模块；
• 路由器；
• 输入输出投影；
• Latent 空间的降维与升维；
• 视觉模块和其他公共参数。

所以真正应该区分的是：

总容量：模型一共可以存储多少知识和能力
激活参数：一次处理一个 Token 时真正参与计算多少参数

MoE 的价值，就是让这两个数字不再绑定在一起。

模型可以拥有非常大的总容量，但每个 Token 只调用其中一小部分。

---

六、Stable LatentMoE 真正巧妙的地方：专家不在完整空间里工作

普通 MoE 还有一个隐藏成本。

K3 的主干隐藏维度是 7168。

如果每个 Token 选择 16 个专家，并把完整的 7168 维表示分别发送给这些专家，就会产生大量通信和权重读取。

专家通常分布在不同 GPU 上。

这意味着每一层都可能发生：

Token 表示发送到多个 GPU
        ↓
不同 GPU 上的专家执行计算
        ↓
计算结果再跨 GPU 汇总

专家越多，激活专家越多，通信和显存访问压力就越大。

这也是很多 MoE 模型理论 FLOPs 不高，实际 GPU 利用率却不理想的原因。

LatentMoE 先把信息压缩，再交给专业专家

K3 的完整隐藏维度是 7168，而路由专家工作的 Latent 维度是 3584。

处理过程可以理解为：

完整 Token 表示：7168维
        ↓
压缩到 Latent Space：3584维
        ↓
发送给16个路由专家
        ↓
聚合专家输出
        ↓
重新映射回7168维

与此同时，两个共享专家仍然在完整宽度上工作，负责通用信息处理。

这种结构的逻辑非常像一家大型咨询公司。

共享专家负责所有项目都需要的基础工作：

• 语言理解；
• 通用知识；
• 基本逻辑；
• 公共特征处理。

路由专家则处理专业问题：

• 编程；
• 数学；
• 法律；
• 视觉关系；
• 某些高度专业化的语义模式。

但公司不会把客户全部原始材料复印 16 份，分别送给 16 位专家。

它会先把材料整理成结构化摘要，再交给专业团队。

这就是 LatentMoE 的核心价值：

在扩大专家数量和专业化能力的同时，控制专家之间的通信与计算宽度。

官方报告明确指出，普通 MoE 会让每个专家接收完整维度表示，通信量和专家权重流量会随着激活专家数量增长；LatentMoE 则把共享专家保留在完整宽度，让路由专家在更紧凑的潜在空间中工作。(arXiv)

---

七、为什么名字里还有一个 Stable？

当专家数量达到 896 个、模型达到 2.8 万亿参数后，最大的问题已经不再是“结构能不能表达”。

真正的问题变成：

它会不会在训练几个月后突然数值失控？

K3 给 LatentMoE 增加了三层稳定机制：

RMSNorm
SiTU-GLU
Quantile Balancing

1. RMSNorm：先把专家输出拉回稳定尺度

不同 Token 会选择不同的专家组合。

某些专家组合输出数值较大，某些较小。

如果这些结果直接升维并加入主干网络，内部数值尺度会不断漂移。

K3 在路由专家聚合之后、重新升维之前加入 RMSNorm，使路由分支先回到相对稳定的尺度，再与完整宽度的共享分支结合。官方消融结果显示，这种归一化既改善训练稳定性，也改善验证损失和下游表现。(arXiv)

2. SiTU-GLU：给极端激活加一个平滑限速器

很多大模型使用 SwiGLU。

它在正常数值范围内表现很好，但其两条乘法分支都没有严格上界。模型规模很大、又使用低精度计算时，偶然出现的极端激活可能带来溢出和训练不稳定。

K3 使用 SiTU-GLU，通过 tanh 对两条分支进行平滑限制。

它不是简单地把超过阈值的数值一刀切掉，而是让数值接近危险区域时逐渐进入饱和状态。

这就像汽车的电子限速器：

正常速度：不干预
接近极限：逐渐减少动力
超过安全范围：不再继续无限增长

K3 设置下，SiTU-GLU 的单坐标输出具有明确上界，而正常区域又尽量保持接近 SwiGLU 的响应。(arXiv)

3. Quantile Balancing：不只是让专家“公平工作”

普通 MoE 使用 Top-k 路由。

对于每个 Token，路由器选择得分最高的几个专家。

问题是，有些专家很容易持续获得高分。

最后可能出现：

专家1：1000个Token
专家2：700个Token
专家3：20个Token
专家4：0个Token

这不仅会导致部分专家训练不足，还会直接拖慢硬件。

专家 1 所在 GPU 需要计算很久，其他 GPU 却已经完成，只能等待。

Quantile Balancing 会根据每个专家路由分数的分位点，调整用于 Top-k 选择的专家偏置，让每个专家获得接近目标数量的 Token。

这里有个很重要的细节：

这个偏置只影响 Token 被送到哪个专家，不直接修改专家输出的混合权重。

因此，它能改善负载分配，又尽量不干扰路由器原本需要学习的内容相关性。(arXiv)

所以 Quantile Balancing 的核心，不只是让专家都有机会成长。

它更重要的价值是：

把内容驱动、极不规则的稀疏计算，转化为硬件更容易执行的规则任务。

---

八、MoE 最容易被误解的一件事：数学上稀疏，不代表 GPU 上高效

假设一个 MoE 模型每次只激活 2% 的专家。

从数学上看，计算量已经很低了。

但实际部署时，GPU 可能仍然很慢，因为 Token 需要在不同设备之间不断发送和汇总。

真正限制性能的，可能不是矩阵乘法，而是：

• All-to-All 通信；
• 专家负载不均；
• 动态 Tensor Shape；
• 内存碎片；
• Host 与 GPU 频繁同步；
• 中间结果复制。

K3 为此设计了 MoonEP。

MoonEP 会根据当前 Batch 和当前层的路由结果，动态规划冗余专家，并提前把热门专家迁移或复制到合适设备上，使不同 Expert Parallel Rank 获得相同规模的 Token 计算任务。(arXiv)

负载完全平衡以后，会出现几个连锁收益。

第一，每张 GPU 的计算量一致，不再有人做完以后等待最慢设备。

第二，计算 Shape 可以提前固定，不必每一层都让 CPU 查询 GPU：这次到底有多少 Token 被送给了每个专家。

第三，通信结果可以直接写入远端专家需要的位置，减少中间复制，也就是报告中强调的 Zero-copy communication。

第四，专家调度和计算更容易重叠，部分通信延迟可以被隐藏起来。(arXiv)

这也是 K3 最值得工程团队学习的一条规律：

稀疏模型的性能，最终不是由“激活了多少参数”单独决定的，而是由路由、通信、内存布局和计算调度共同决定的。

这和多 GPU 训练时经常遇到的问题完全一致。

显卡数量增加，并不代表速度按比例增加。

当单卡计算越来越快后，瓶颈经常会从算力转移到卡间通信。

---

九、Per-Head Muon 不是“每个注意力头使用不同学习率”

关于 Per-Head Muon，网上很容易出现一种解释：

每个 Attention Head 拥有自己的优化节奏。

这个说法可以帮助理解，但并不准确。

K3 沿用了 Kimi K2 的 Muon 优化器，并对 Attention 的 Q、K、V 投影做了更细的处理。

普通 Muon 会把整个投影矩阵作为一个整体，对它的动量矩阵进行近似正交化。

问题是，不同 Attention Head 的梯度尺度可能差异很大。

如果把所有 Head 混在一起处理，梯度较大的 Head 可能主导整个更新方向，梯度较小的 Head 得不到充分归一化。

Per-Head Muon 会先按照 Head 维度拆开 Q、K、V 的动量矩阵，再分别进行 Newton–Schulz 正交化。

它真正解决的是：

不是给每个Head设置不同学习率
而是让不同Head的更新尺度更均衡

官方报告认为，这种方法可以改善不同注意力头之间的学习平衡，提高大规模训练稳定性，同时略微降低优化器计算开销。(arXiv)

可以把它理解成一支跑步队伍。

普通方式是把所有人的步幅混在一起统一校正。

Per-Head Muon 则是分别纠正每个人的步幅，避免某几个步子特别大的人把整个队伍带偏。

---

十、量化最重要的变化：训练和部署开始真正合并

过去的大模型经常采用这样的流程：

先训练高精度模型
        ↓
训练完成后进行量化
        ↓
部署时发现能力下降
        ↓
再做补偿和校准

这里的问题很明显。

模型训练时一直生活在高精度环境中，部署时却突然被放进低精度环境。

它从来没有学过怎样抵抗量化误差。

K3 从 SFT 阶段开始，就引入了量化感知训练，并贯穿后续 RL。

但它并不是把整个模型粗暴压成 4 Bit。

K3 主要将最占参数存储的路由 MoE 专家权重量化为 MXFP4，激活使用 MXFP8；Attention 投影、LatentMoE 投影、共享专家和路由器等模块仍保持更高精度。(arXiv)

更重要的是，RL Rollout 和模型训练使用相同的量化方案。

为什么这件事对 Agent 特别重要？

因为普通问答中，一个很小的概率误差，可能只影响一句话的表达。

Agent 中的一个微小误差，却可能造成：

选错工具
    ↓
修改错文件
    ↓
测试结果异常
    ↓
后续几十步全部偏离

所以 K3 的 QAT 不只是为了省显存。

它体现了一种新的研发思想：

部署环境不再是模型训练完成以后才考虑的问题，而是从后训练阶段就必须进入模型设计。

---

十一、K3 最容易被低估的创新，其实是长程 Agent 训练

百万 Token 上下文听起来很强。

但能装下一百万 Token，不代表模型真的会使用这一百万 Token。

就像一个人拥有一本一百万字的笔记本，不代表他能连续工作十小时，并且一直记得：

• 最初目标是什么；
• 已经完成了哪些步骤；
• 哪些尝试失败了；
• 文件被修改到了什么状态；
• 下一步应该做什么。

长上下文解决的是“装得下”。

长程 Agent 解决的是“做得完”。

K3 训练的不是单次回答，而是完整行动循环

Agent 真正工作的过程是：

分析当前情况
    ↓
决定下一步行动
    ↓
调用工具
    ↓
观察工具返回
    ↓
检查结果是否正确
    ↓
修改计划
    ↓
继续执行

这个循环可能持续数百甚至数千次工具调用，累计上下文也可能超过单次一百万 Token。

K3 的强化学习覆盖三个领域：

• 通用推理与知识工作；
• 通用 Agent；
• 编程 Agent。

每个领域又分别训练 low、high、max 三种推理强度，因此一共形成九个领域与推理强度组合的专家模型，再通过多教师在线蒸馏整合到一个统一模型中。(arXiv)

这种思路很值得借鉴。

与其强迫一个模型从一开始同时学会所有能力，不如先让不同专家分别把某类行为学深，再把策略重新合并。

---

十二、Partial Rollout：为什么训练 Agent 不能等待所有任务完成？

普通强化学习训练通常会等待一批 Rollout 全部结束，然后统一更新模型。

短任务中问题不大。

但长程 Agent 的任务长度差异非常大：

任务A：30步完成
任务B：200步完成
任务C：调用网页后卡住
任务D：执行了1000多次工具

如果必须等待全部任务结束，整个训练集群都会被最慢的几个任务拖住。

K3 使用 Partial Rollout。

当一部分轨迹已经完成时，系统就暂停剩余长任务，先用完成的数据更新模型。

没有结束的任务被放入队列，下一轮再从中断位置继续执行。(arXiv)

这听起来很简单，但背后有一个很麻烦的问题：

任务暂停以后，模型和外部世界的状态都必须原样保留。

例如 Agent 已经：

• 创建了代码文件；
• 安装了依赖；
• 启动了服务；
• 修改了数据库；
• 打开了网页；
• 执行了一半测试。

下一轮继续时，如果给它一个全新的空环境，前面所有行动就白做了。

这也是为什么长程 Agent 必须依赖可恢复沙箱。

---

十三、沙箱不只是防止 Agent 乱删文件，它还是 Agent 的外部记忆

很多人第一次接触 Agent 时，会把沙箱理解成安全工具：

给模型一个隔离环境，防止它破坏宿主机。

这当然没错。

但 K3 展示了沙箱的另一个重要作用：

保存任务世界的状态。

K3 使用了包括容器、GPU 沙箱和基于 microVM 的 AgentENV 在内的多种运行环境。

AgentENV 支持：

• Pause and Resume；
• Fork；
• Snapshot；
• 增量检查点；
• 隔离的文件系统和运行环境。

报告中给出的检查点和恢复延迟最低分别约为 133 毫秒和 49 毫秒；暂停状态下的沙箱不占用 CPU 和内存资源。(arXiv)

这意味着一个真正能够长期工作的 Agent，至少拥有三种记忆：

第一层：模型内部的神经网络状态
第二层：对话、推理和工具调用历史
第三层：文件系统、应用程序和外部环境状态

只保存聊天记录是不够的。

假设模型记得“我刚刚已经修改了配置文件”，但沙箱里的配置文件没有保存，那么它的记忆和现实世界就发生了冲突。

对企业 Agent 来说，这一点尤其重要。

长任务的可恢复性，不只是“重新把 Prompt 发一次”。

它要求模型上下文、缓存、任务队列、文件状态和业务系统状态共同恢复。

---

十四、Prefix Cache：百万上下文真正省钱的关键，是不要重复读

长上下文最昂贵的情况，不一定是第一次读取。

在持续工作的 Agent 场景中，更常见的是：

前面已经有40万Token历史
本轮只新增4000 Token

如果每次交互都重新计算前面 40 万 Token，成本会非常高。

Prefix Cache 会复用已经计算过的历史前缀，只处理本轮新增部分。

但 K3 的缓存比普通 Transformer 更复杂。

因为它同时拥有两种不同的注意力状态：

KDA：固定大小的递归状态
MLA：随上下文长度增长的KV Cache

一个历史前缀想要真正复用，必须在同一个边界上同时恢复 KDA 状态和 MLA KV Cache。

只恢复其中一种，模型的内部状态就会前后不一致。

因此 K3 设计了 KDA-aware Prefix Cache，将两类缓存放入统一的分页管理体系，并保存可复用边界上的 KDA 状态检查点。(arXiv)

报告给出的典型编程场景是：

• 已有前缀约 40 万 Token；
• 本轮新增约 4000 Token。

缓存命中时只需要处理新增部分；缓存未命中时，则可能需要重新 Prefill 完整的 40 万 Token，两者成本可能相差几个数量级。(arXiv)

这还引出了一个很容易被忽略的集群调度问题。

假设用户的前缀缓存在 A 集群，本轮请求却被随机分配到了 B 集群。

要么跨集群搬运缓存，要么重新计算整个历史前缀。

两种方式都很贵。

所以 K3 还使用 Cache-aware affinity scheduling，尽量把同一会话继续调度到保存其缓存的集群。(arXiv)

到了这个层面，大模型优化已经不再只是 CUDA Kernel 的问题。

它开始进入：

• 会话路由；
• 缓存亲和性；
• 故障转移；
• 资源预算；
• 集群调度。

---

十五、K3 宣称的“2.5 倍效率”到底是什么意思？

官方表示，K3 相比 K2，整体 Scaling Efficiency 提升约 2.5 倍。(arXiv)

这个数字很容易被误解。

它不等于：

推理速度提升2.5倍
训练时间缩短到原来的40%
同一台服务器能跑2.5倍请求

这里的效率来自 Scaling Law 评估。

更接近的理解是：

达到相近验证损失时，K3 架构所需要的训练计算量明显低于 K2；或者在相同计算预算下，K3 可以达到更低的损失。

而且这项提升不是 KDA 单独带来的。

它是整套系统共同产生的结果：

• KDA 与 Gated MLA 混合注意力；
• Attention Residuals；
• Stable LatentMoE；
• 更多激活专家；
• SiTU-GLU；
• Quantile Balancing；
• Per-Head Muon；
• 数据和训练配方的改进。

所以更准确的说法应该是：

K3 整体架构与训练体系，在 Scaling Law 意义上相对 K2 获得约 2.5 倍效率提升。

---

十六、关于 K3，有几个说法需要特别纠正

“KDA 不再保存任何历史”

不准确。

KDA 不保存每个 Token 的完整 KV，但会维护递归状态。

而且 K3 不是纯 KDA 模型，它还保留 24 层 Gated MLA，因此仍然存在随上下文长度增长的 KV Cache，只是增长速度比全注意力模型更低。(GitHub)

“Quantile Balancing 是为了让所有专家公平成长”

不够准确。

它确实能减少长期闲置专家，但更直接的目标是控制专家负载，使专家并行训练更加平衡和规则。

“Per-Head Muon 是给每个注意力头设置不同学习率”

错误。

它是把 Q、K、V 的动量矩阵按 Head 拆分，再分别进行正交化，从而平衡不同 Head 的更新尺度。

“K3 每次只计算 2.8 万亿参数的 16/896”

错误。

模型还包含共享专家、Attention、投影、路由器和其他公共参数。官方给出的真实激活参数约为 1040 亿。(GitHub)

“K3 官方要求至少 64 张 GPU 才能部署”

Information Not Available。

目前官方仓库列出了 vLLM、SGLang 和 TokenSpeed 等推荐推理引擎，但没有把“至少 64 张 GPU”写成通用的官方部署门槛。具体硬件需求还会受到量化、上下文长度、并发量和推理框架影响。(GitHub)

“K3 是完全开源模型”

更严谨的说法是开放权重模型。

官方释放完整模型权重，并使用 Kimi K3 License；开放权重和传统开源软件定义下的完全开源，并不完全是一回事。(GitHub)

---

十七、真正值得我们从 K3 学走的五件事

看完 K3，我认为最值得普通开发者和 AI 工程团队学习的，不是某一条公式，而是下面五种思维方式。

第一，记忆不一定要无限堆积，也可以持续更新

传统系统习惯保存全部历史。

KDA 提醒我们，另一条路线是：

读取新信息
检查旧状态
发现预测误差
修改已有记忆

这对企业 Agent、用户画像、项目状态和长期任务记忆都很有启发。

第二，不要迷信单一架构

KDA 便宜，但会压缩细节。

MLA 成本更高，但拥有精确的全局访问能力。

K3 没有强行二选一，而是采用 3:1 混合。

优秀的工程设计，往往不是寻找一个全能组件，而是设计合理分工。

第三，模型结构必须和硬件一起设计

MoE 在数学上很稀疏，如果专家路由和 GPU 通信处理不好，现实中仍然可能很慢。

算法复杂度只是第一层。

真正的性能还取决于：

数据怎么移动
GPU怎么等待
内存怎么布局
计算能否重叠
Shape能否固定

第四，部署约束必须提前进入训练

QAT 不再是模型训练完成后的压缩补丁。

K3 从 SFT 和 RL 阶段就让模型适应未来的部署精度。

训练和推理不应该是两条彼此割裂的流水线。

第五，长上下文不等于长程 Agent

百万 Token 只能说明模型装得下很多信息。

真正的长程 Agent 还需要：

• 工具调用训练；
• 环境反馈；
• 可验证奖励；
• Partial Rollout；
• 外部缓存；
• 可恢复沙箱；
• 文件和应用状态持久化；
• 缓存感知的集群调度。

这也是我认为 K3 最有现实价值的地方。

---

写在最后

过去几年，大模型竞争最容易被看见的是参数量：

70B
400B
1T
2.8T

但 Kimi K3 展示出的趋势已经很明确。

下一阶段真正决定模型能力的，不只是参数还能不能继续扩大，而是整套系统能不能同时承受：

万亿级参数
百万级上下文
数百个专家
数千次工具调用
数小时连续任务

KDA 负责让信息在长序列中低成本流动。

AttnRes 负责让信息穿过深层网络时不被轻易冲淡。

Stable LatentMoE 负责把庞大的模型容量变成稀疏、可执行的计算。

Muon、Quantile Balancing 和 MoonEP 负责让训练不失控、GPU 不空等。

QAT、Prefix Cache 和集群调度负责让模型最终能够进入真实部署。

Partial Rollout 和可恢复沙箱，则让 Agent 不再只是回答一个问题，而是开始持续执行一个任务。

所以 K3 真正值得关注的信号，并不是：

大模型又变大了。

而是：

大模型正在从单一神经网络，演变成由模型架构、优化器、分布式系统、推理引擎、缓存、沙箱和强化学习共同组成的智能计算系统。

下一代 AI 的竞争，正在从模型竞赛，进入系统工程竞赛。

而 Kimi K3，只是把这条路线第一次非常完整地摆在了我们面前。