feat: deepen Kimi K3 report guide

research/K3_GROK_LEADS.md

@@ -0,0 +1,137 @@
+# 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 个实验建立交互、公式与边界测试。
+