Kimi K2 → K2.5 → K2.6 → K2.7-Code：架构不变时，能力为何仍会跃迁

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

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

K2.6 和 K2.7-Code 都是在 K2.5 型骨架上继续改善 agent 轨迹、长程稳定性和 coding 行为。公开资料中，只有 K2.5 明确扩展了视觉-文本架构与训练方法。

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. Composer 2 / 2.5：基于 K2.5，不等于 Kimi 官方新 checkpoint

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 中‘最终失败，但不知道哪一步错’的 credit assignment 问题。

其系统层还公开提及 25 倍 synthetic RL tasks、Sharded Muon 和 dual-mesh HSDP：将 expert 与非 expert 通信分开并尝试重叠 all-to-all、正交化和训练计算。读者可以用它学习‘训练 infra 如何影响 post-training’，但不能把 Cursor 内部 mesh、GPU 数或线上部署声称为可复现的 Kimi 服务配置。

7. 从 K2 的 MoE 到实际 serving：权重、EP、P/D 与 INT4

Moonshot 为 K2 系列公开了 vLLM、SGLang、KTransformers 以及兼容 OpenAI/Anthropic 的 API 路径。K2 部署指南还列出 TP、DP+EP、DeepEP、DeepGEMM、IB 设备和 P/D 分离的参考配置。K2.5、2.6、2.7 都要锁定具体 revision；其中 K2.6 和 2.7 明确复用 K2.5 的同架构部署路径。

1. 权重格式：确定使用 BF16、FP8 还是 native INT4 checkpoint。设备容量按 total 权重计算，不能只看 active 参数。
2. 并行网格：TP 分担层内投影，EP 处理 token 到 experts 的路由，DP 增加副本。P/D 分离还要核算状态传输和尾延迟。
3. MTP/投机：验证 batch 可以减少目标模型的 decode 次数，效果要同时报告 acceptance 和 TPOT。
4. 任务生命周期：Agent 等待工具时，服务端要在 KV 留驻 HBM、下沉和重算之间选择。持续任务不能直接套用一次性聊天的 QPS。

这些官方配置是可复现的起点，不能据此推断 Moonshot 托管 API 的物理集群。开权重自部署页会继续说明两者的区别。

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

1. 固定具体 repo revision、chat template、tool schema、视觉 processor、推理引擎和量化格式。
2. 将纯文本、图像理解、浏览/终端 agent、长上下文和多 agent 任务拆开测，记录每项的输入 token、视觉 token、工具时间和输出 token。
3. 服务测试分别报 TTFT、TPOT、KV 命中率、expert load、P95/P99、abort/retry 与 agent wall-clock。
4. 对于 K2.6/2.7，先做 logits 或短生成一致性烟测，再把差异归因到 post-training 行为，而不是假设 config 一定不同。
5. 对于 Composer，只在其可观察 API 行为范围内评测；不能由产品效果反推出未公开的 checkpoint 或网络设计。

9. 一手来源