llm-atlas/research/K3_GROK_LEADS.md

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. 处置状态

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