# Kimi K3 Grok 候选线索台账

> 状态：**UNVERIFIED / 仅用于发现问题，不可作为课程证据引用。**
>
> 生成方式：2026-07-29 使用本机 Grok CLI Headless，限定只读取
> `research/sources/kimi-k3/k3_tech_report.txt` 与当时的
> `src/pages/k3/index.astro`，要求逐节对照并提出遗漏、疑点、实验和阅读节点。
> 所有候选结论必须回到 K3 官方报告、论文原文或官方代码核验后，才能进入
> `K3_RESEARCH.md` 与正式页面。

## 1. 候选审计结论

现有 K3 页面有一条可用的“序列—深度—宽度—系统”骨架，但把 47 页报告压缩得过度：

- 只覆盖 13 个正文入口、9 个一手来源和一个通用架构浏览器；
- Figure 1–16、Table 1–5 大多没有逐图解释；
- §3 预训练、§4 后训练、§5 系统、§6 评测、§7 案例与附录只保留了摘要；
- 关键数字、机制的适用边界、报告未披露事项尚未形成统一红线；
- 视觉训练段落疑似沿用了“后接视觉塔”的常见范式，需优先核验。

## 2. 候选问题清单

以下 32 个问题是第二轮深读的索引，不代表其答案已经核验：

1. 2.78T total 与 104.2B active 分别在计算和容量上意味着什么？
2. 报告所说约 2.5× scaling efficiency 的对照对象和口径是什么？
3. 3 KDA + 1 MLA 的比例在 93 层里怎样落地？
4. KDA 的状态更新与普通线性注意力有何不同？
5. delta rule 为什么是“纠错写入”，而不是简单累加？
6. `g_min=-5` 解决的数值与内核问题是什么？
7. chunkwise KDA 怎样同时实现训练并行与解码递归？
8. KDA/MLA 的全秩输入相关输出门做什么？
9. MLA 为什么采用 NoPE；位置从哪里来？
10. attention output 保持 FP32 在修复什么舍入问题？
11. Full AttnRes 与 Block AttnRes 的准确关系是什么？
12. LatentMoE 的 3584 维路由空间为何能降低通信？
13. shared experts 与 routed experts 怎样分工？
14. SiTU-GLU 的有界激活和具体参数是什么？
15. Quantile Balancing 如何由 Top-(k+1) cutoff 更新 bias？
16. 直方图近似如何让近千专家的分位统计可通信？
17. MoonViT-V2 是否从头训练；与 SigLIP 初始化对照是什么？
18. “原生多模态”在数据目标和共享主干上准确指什么？
19. Per-Head Muon 为什么按 attention head 分组？
20. 8K→64K→256K→1M 的 context curriculum 如何安排？
21. 九个专家如何由三领域 × 三 effort 形成？
22. MOPD 的 on-policy 稠密 token reward 如何定义？
23. reasoning effort 的 per-problem budget 怎样退火？
24. partial rollout 怎样处理 straggler 与 stale trajectory？
25. Agentic GRM 如何控制冗长 reward hacking？
26. KDA Context Parallelism 如何划分 1M 序列？
27. MoonEP 如何把路由不均转成静态执行形状？
28. prefix cache 为什么必须联合保存 KDA state 与 MLA KV？
29. 512-token hash boundary 与 6144-token physical block 为什么解耦？
30. 评测中的 effort、工具、harness、fallback 如何影响可比性？
31. 报告自己承认的 research reasoning / cyber 等弱项是什么？
32. 第三方评测分数、推理成本和公开权重应怎样并排展示？

## 3. 候选逐图任务

| 报告对象 | 候选解释任务 |
|---|---|
| Figure 1 | 把总体结果与“仍落后最强闭源模型”放在同一视图 |
| Figure 2 | 标出 3:1 KDA–MLA、Block AttnRes、Stable LatentMoE、MoonViT |
| Figure 3 | 交互展示无界与有界 log-decay 在 BF16 中的差异 |
| Figure 4 | 并排比较 GLU、SwiGLU、SiTU-GLU 的大输入行为 |
| Figure 5 | 动画解释 Top-(k+1) cutoff 与 Quantile Balancing |
| Figure 6 | 只在报告消融范围内解释 from-scratch ViT 稳定性 |
| Figure 7 | 区分训练 loss scaling、吞吐与下游能力 |
| Figure 8 | 并排画 RL FLOPs、平均 steps 与分数 |
| Figure 9 | 展示 knowledge graph→材料→任务→验证的合成链 |
| Figure 10 | 解释 AET curriculum 与独立 verifier |
| Figure 11 | 解释 pipeline / offload 中状态的移动 |
| Figure 12 | 动画解释物理块、hash block、KDA checkpoint |
| Figure 13 | 将第三方总分与 token/cost 放在同一坐标系 |
| Figure 14 | 明确 kernel agent 的 24h 个案边界 |
| Figure 15 | 明确 MiniTriton 的 L20 roofline 和个案边界 |
| Figure 16 | 可视化 XTML 选项、channel 与 message boundary |
| Table 1 | 做 K2→K3 的逐字段差异表 |
| Tables 2–5 | 按能力轴重排，并给每个数字附评测协议脚注 |

## 4. 候选交互实验

1. **Delta Rule 工作记忆**：反复写入相同 key，对比累加与纠错写入。
2. **有界 log-decay / BF16**：拖动下界、chunk 长度，观察累计倒数与溢出风险。
3. **Block AttnRes**：调层数和 block size，比较深度来源、缓存与通信。
4. **LatentMoE 通信账本**：调 full width、latent width、激活专家数，比较 token payload。
5. **SiTU-GLU 曲线**：调参数并对比 SwiGLU 的大正输入。
6. **Quantile Balancing**：模拟长尾 router score 和 bias 更新。
7. **MOPD / effort**：调 domain、budget multiplier、partial rollout threshold。
8. **BrowseComp 上下文管理**：比较大窗口直塞、压缩、prefix reuse 的代价。

## 5. 候选阅读节点

Grok 建议把报告参考文献扩成约 100 个可导航节点，按以下簇核验：

- Kimi 谱系：MoonViT、Kimi Linear、Kimi k1.5、K2、K2.5、K3；
- 注意力与状态：Transformer、FlashAttention、linear attention、DeltaNet、
  Gated DeltaNet、Mamba、RWKV、RetNet、NoPE、长上下文扩展；
- 深度与宽度：residual、Highway/DenseNet、AttnRes、MoE、Switch、
  DeepSeekMoE、MLA、LatentMoE；
- 优化与数值：Muon、Muon scaling、weight clipping、BF16、MXFP4/8、QAT；
- 后训练：SFT、RLHF、PPO/GRPO 类方法、partial rollout、OPD、MOPD、
  speculative decoding、EAGLE-3、LK loss；
- 系统：FlashKDA、KCP、MoonEP、expert parallelism、KV/prefix cache、
  Firecracker、AgentENV、WarpDecode；
- Agent 与评测：white-box harness、AET、Agentic GRM、BrowseComp、
  SWE、TerminalBench、OSWorld、HLE、视觉基准；
- 开放实现：Kimi-K3、AgentENV、MiniTriton、nano-kpu 及报告明确列出的代码仓库。

这些节点只能在逐项核对标题、年份、主张与 URL 后进入正式论文链。

## 6. 候选红线

- 不把 2.78T total 写成每 token 计算量；
- 不把约 2.5× 写成推理加速或 KDA 单项收益；
- 不把 KDA 写成能够无损精确回忆全部历史；
- 不把 NoPE 写成“没有任何位置信息”；
- 不忽略 `g_min`、SiTU 参数、QB inference bias 冻结等实现条件；
- 不把路由负载平衡与系统执行平衡混成一个机制；
- 不把 MoonViT-V2 写成先接到已经训练好的语言模型；
- 不把 1M window 写成 1M 内容都能可靠利用；
- 不把 MOPD 写成九个模型在推理时投票；
- 不把 effort 写成一个固定全局 token 上限；
- 不把模型分数和 harness / tool 的系统分数混为一谈；
- 不省略评测日期、effort、工具、fallback、guard；
- 不把 kernel、MiniTriton、芯片案例推广为普遍外部结论；
- 不补写报告没有披露的总训练 token、精确数据比例、集群和成本。

## 7. 处置状态

- [x] Grok 候选审计已保存，与正式证据隔离。
- [x] “冻结语言模型再解冻”疑点已回到 K3 §2.4 / §3.3 核验，确认现页错误。
- [ ] 32 个问题逐项建立正式证据台账。
- [ ] 16 图、5 表逐项建立视觉契约。
- [ ] 100 个候选阅读节点逐项核验。
- [ ] 8 个实验建立交互、公式与边界测试。