Kimi Linear 与 K2 → K2.5 → K2.6 → K2.7-Code → K3：主线升级与外部分支

1. 先按 checkpoint，而不是营销名称，建立演进表

判断一代模型改了什么，要分别查看基础架构、模态输入、预训练、后训练、agent 编排和托管产品，不能只按参数规模排版本。下面的表格列出正文采用的证据。

Kimi Linear 是独立公开的架构研究线：它先用 48B-A3B checkpoint 证明 KDA 与周期性 MLA 可以共同工作。K2.6 和 K2.7-Code 则沿用 K2.5 型骨架改善 agent 轨迹、长程稳定性和 coding 行为。K3 把 KDA 带入新的 2.8T 主干。SWE-1.7 与 Composer 从较早 checkpoint 分叉，不能按发布时间接在 K3 后面当成同一条 Moonshot 版本链。

2. K2 是什么：MoE、MLA 与可服务的状态账本

K2 的 decoder 是 MoE。每个 token 先经过 router，再只执行 top-k experts；与此同时，模型仍需要使所有 expert 权重在本地或跨设备可访问。把 active 32B 当成‘只需装 32B 模型’是常见错误：前者描述每 token 的被激活计算，后者仍由全部权重、量化格式、workspace 与 KV 共同决定。

MLA 的工程价值是压缩 attention 中需要持久化的表示，因此直接连接到 KV cache 容量与传输量。它不消灭 KV，也不自动给出某个服务端的每 token 字节数；这些还要由 heads、latent ranks、精度、block allocator 和 context length 决定。

3. K2.5：为什么视觉 Agent 不是‘在文字模型前接一个图片接口’

K2.5 在 K2-Base 上继续预训练约 15T 混合视觉/文本 token，并公开 MoonViT 400M、统一视觉-文本训练、256K context 和联合视觉 RL。图像特征因此与文本 token 一起进入主干的注意力序列，服务端不能把它只记作工具调用后的旁路描述。

服务端因此需要分别测量媒体 decode/resize、视觉 encoder、视觉 token prefill、语言 decoder 以及工具暂停恢复。把整个请求只压成‘生成了多少文本 token’会遗漏实际的首 token 和显存来源。

4. 预训练、zero-vision SFT 与联合 RL：能力提升放在哪里

论文给出的训练顺序很明确：在 K2-Base 上继续做视觉-文本预训练，接着用 zero-vision SFT 学习视觉任务的格式和工具协议，再用联合 RL 训练视觉判断、网页或桌面操作、任务分解和多 agent 协作。若 RL 只覆盖文本，视觉 encoder 与后续行为容易脱节；若训练停在视觉分类，模型又学不到多步骤工具轨迹。

Agent Swarm / PARL 处理的是训练和测试时的任务树。多个子 Agent 可以并行探索，orchestrator 负责汇总或继续展开；这不意味着一次 forward 中的 Transformer 层可以绕过因果依赖并行执行。

5. K2.6 与 K2.7-Code：同架构并不等于没有技术变化

K2.6 官方模型卡明确：与 K2.5 架构相同，部署方法可复用；其发布重点是更长程的 code/design、主动后台执行和更大规模的 subagent 协作。这里可严谨地写成 post-training、agent policy 和产品运行时更新，而不是凭 benchmark 曲线断言新的 attention、expert 数或隐藏维度。

K2.7 的公开 checkpoint 名为 Kimi-K2.7-Code。官方说明它建立在 K2.6 上，与 K2.5/K2.6 同架构，定位为 coding agent；其思考 token 量约少三成，并使用强制 thinking / preserve-thinking 的交互约束。对部署来说，短思考轨迹可能降低平均 decode 工作量，但端到端成本仍取决于接受率、工具等待、并发和重试，不应直接等同为三成成本下降。

6. Kimi Linear：KDA 在 K3 之前已经完成公开验证

Kimi Linear 的核心就是 Kimi Delta Attention（KDA）。它在每个 head、每个 feature channel 上使用更细粒度的门控，按 delta rule 擦除与当前 key 冲突的旧关联，再把新的 key/value 关联写入固定形状的递推状态。模型不需要在每个 KDA 层保存随序列长度增长的完整 KV，但状态更新、短卷积、门控和 chunkwise scan 都需要专用 kernel。

官方公开的 Kimi-Linear-48B-A3B 使用 48B total、3B active、1M context，并采用 3 个 KDA block : 1 个 global MLA block 的层组合。周期性 MLA 保留对显式 token history 的全局读取，KDA 则以固定递推状态承担大多数层的序列建模。论文在自身实验设置下报告，最长上下文场景可减少最多 75% KV cache，并在 1M context 上达到最高约 6× decoding throughput；这些是 Kimi Linear 对 full MLA 基线的实验结果。

7. K3：从 Kimi Linear 的 KDA 走向 69 KDA + 24 Gated MLA

K3 的总参数为 2.8T，Stable LatentMoE 每次路由选择 896 个 experts 中的 16 个。官方模型仓库给出的 93 层 attention 组成是 69 KDA + 24 Gated MLA：它延续 Kimi Linear 的 KDA/MLA 混合思路，同时加入 Attention Residuals（AttnRes）并扩展 MoE 稀疏度。

主干以 3 × KDA + 1 × Gated MLA 为重复模式，最终模型汇总为 69 个 KDA 层和 24 个 Gated MLA 层。KDA 把序列信息写进受门控的 delta-style 状态，Gated MLA 周期性保留显式 attention 路径；AttnRes 让后续 block 学习组合多层 attention 输出，而不是只沿相邻 residual 顺序传递。Stable LatentMoE 将 shared 与 routed experts 放在稳定的 latent 路径中，目标是提高扩大 expert 数量后的训练稳定性。

官方还列出 Quantile Balancing、Per-Head Muon、SiTU 与 Gated MLA 等改动，并报告相对 K2 约 2.5× overall scaling efficiency。

8. K3 的训练精度、推理拓扑与 cache 为什么一起变了

K3 从 SFT 阶段开始做量化感知训练，官方目标格式是 MXFP4 weights + MXFP8 activations。每张卡除量化权重外，还要容纳 scale、非量化张量、路由/通信 buffer、KDA/MLA 状态、视觉前端、CUDA graph 和 workspace。发布页建议使用 64 张以上加速卡组成的 supernode，因此网络域和 expert placement 与容量同样关键。

训练基础设施使用 balanced expert-parallel strategy、静态 shape，并避免 critical path 上的 host synchronization。推理侧继续使用 Mooncake disaggregation；官方报告 coding workload 的 cache hit rate 超过 90%。KDA 会让 prefix cache 同时管理递推状态与周期性 MLA 状态，cache identity 和迁移协议要与执行图一致。

Kimi Code 文档还明确：切换 model 或 reasoning effort 会使已有 cache 失效并触发重新 prefill。调用方应把模型 ID、effort、模板、工具 schema 和模态 processor 都放进 cache identity；仅按 prompt 文本做 key 会错误复用不同执行图的状态。

官方 benchmark 中，Terminal-Bench 2.1 为 88.3、FrontierSWE 为 81.2、BrowseComp 为 91.2、GPQA Diamond 为 93.5、MMMU-Pro 为 81.6。表格沿用 Moonshot 的 max-reasoning 配置与各项 harness。

9. SWE-1.7：从 K2.7 Code 继续做大规模 agentic RL

Cognition 的训练报告明确写明 SWE-1.7 从 Kimi K2.7 Code 起步。K2.7 本身已经做过大量 RL，Cognition 又在 Devin harness 中继续训练长程、异步的软件工程任务。因此 SWE-1.7 展示了 1 个已重度后训练的开放 MoE 基座如何通过新的 RL recipe、数据和系统继续改变能力与行为。

训练稳定性首先处理 rollout policy 与 trainer policy 不一致。Cognition 在 rollout 时使用 top-p，并记录当时允许采样的 token kept-set；trainer 再用相同 mask 重新归一化概率，这个方法称为 sampling distribution replay。报告称它让训练—推理 divergence 保持有界，并抑制长 RL run 中的 entropy collapse。Muon、确定性 trainer 操作和此前使用的 routing replay / 低精度 rollout 对齐共同服务于同一个目标：不要让训练器优化一套与实际采样不同的分布。

系统层把 1 个紧耦合 trainer cluster 与分布在 4 个数据中心、3 个大洲的 rollout inference clusters 分开。trainer 每隔若干 gradient steps 计算权重增量，经 XOR diff 与 zstd 压缩后写入 object storage；各 cluster 的 weight controller 拉取 manifest 和分片，在本地树状广播并预取到 CPU。报告给出的口径是：1T 参数模型的跨洲更新端到端约 1–2 分钟，权重压缩超过 99%，应用更新时 inference 暂停约 3–4 秒。object storage 还回传 routing matrices 与 top-p masks，使 trainer 能重放 rollout 时真实使用的路由和采样分布。

容错同样按状态边界拆开。rollout engine 只保留当前权重和进行中的 session，NVIDIA Dynamo 负责实例生命周期与重路由；trainer 是昂贵的单点紧耦合组件，因此每步异步写本地 checkpoint 并把 shard 复制给 peers，节点故障时可以缩减整个 data-parallel replica，容量回来后再扩展。长任务则用 self-compaction：接近上下文上限时，模型总结自己的工作状态，再从摘要继续。训练中的 rollout 最长达到 6 小时；交替 length penalty 在无预算阶段追求成功，在预算阶段按 token、turn 和 tool time 压缩已会做的任务。

数据管线检查 verifier 的 false positive / false negative，只保留既不是总能成功也不是总会失败、仍有学习信号的任务，并通过隔离评分路径、移除 git history/reference artifact、限制网络和作弊签名检查降低 reward hacking。Cognition 报告 SWE-1.7 在 FrontierCode 1.1 Main、Terminal-Bench 2.1 和 SWE-Bench Multilingual 上分别为 42.3%、81.5% 和 77.8%，对应 Kimi K2.7 Code 为 30.1%、72.7% 和 73.5%。这些数字沿用 Cognition 的 harness 与评测口径。

SWE-1.7 通过 Devin 提供，并由 Cerebras 以官方宣称的 1000 tokens/s 路径服务。它从 Kimi K2.7 Code 起步，是 Cognition 的外部派生线。

10. Composer 2 / 2.5：从 K2.5 出发的另一条派生线

Cursor 的 Composer 2 技术报告和 Composer 2.5 发布都把基础 checkpoint 写为 Kimi K2.5，之后在代码数据上 continued training，并用大规模 agentic RL 做工具、终端与代码库任务。Composer 2.5 公开的 targeted RL with textual feedback 在错误轨迹的局部插入反馈，让 student 在 on-policy 分布上学习修复，并把长 rollout 的最终失败定位到具体步骤。

其系统层还公开提及 25× synthetic RL tasks、Sharded Muon 和 dual-mesh HSDP：将 expert 与非 expert 通信分开并尝试重叠 all-to-all、正交化和训练计算。这些材料适合用来理解训练 infra 如何影响 post-training；其中的 mesh、GPU 数和线上服务属于 Composer 自身部署。

11. 从 K2 到 K3：实际 serving 的权重、EP、P/D 与状态账本

Moonshot 为 K2 系列公开了 vLLM、SGLang、KTransformers 以及兼容 OpenAI/Anthropic 的 API 路径；Kimi Linear 还公开了 KDA kernel 和 vLLM 实现。K2 部署指南列出 TP、DP+EP、DeepEP、DeepGEMM、IB 设备和 P/D 分离的参考配置。K3 的 KDA、896 experts、QAT 格式和 1M context 要按官方 K3 config 与 runtime 单独建账，不能套用 K2 的 MLA-only 假设。

1. 权重格式：固定实际 checkpoint 和 tensor index，再计算每 rank 的权重、scale 与非量化张量。
2. 并行网格：TP 分担层内投影，EP 处理 token 到 experts 的路由；K3 的 16-of-896 路由要把 supernode 内外带宽分开测。
3. 状态：Kimi Linear 和 K3 都同时存在 KDA recurrent state 与周期性 MLA cache；K3 还加入视觉 token 和 AttnRes 执行依赖。
4. 任务生命周期：Agent 等待工具时，服务端要在状态留驻 HBM、下沉和重算之间选择；1M session 不能直接套用一次性聊天 QPS。

开权重自部署页和 托管 API 页分别维护自部署与托管服务的配置边界。

12. 如何自己验证版本差异，而不是被版本号带着走

1. 固定具体 repo revision、chat template、tool schema、视觉 processor、推理引擎和量化格式。
2. 将纯文本、图像理解、浏览/终端 agent、长上下文和多 agent 任务拆开测，记录输入 token、视觉 token、工具时间和输出 token。
3. 服务测试分别报 TTFT、TPOT、KDA state/MLA cache 命中率、expert load、P95/P99、abort/retry 与 agent wall-clock。
4. 对于 K2.6/2.7，先做 logits 或短生成一致性烟测，再比较 post-training 行为。
5. 对于 Kimi Linear 与 K3，分别记录 KDA kernel、周期性 MLA cache、context length 与并行配置。
6. 对于 SWE-1.7 与 Composer，使用各自公开 harness 和 API 评测。

13. 一手来源