免费电子书:Pretraining a Mini Kimi K3

大模型训练这件事，过去几年被讲成了两套话术：要么是「算力即一切」，几张万卡、十亿美元训练完发个 SOTA；要么是「普通人勿碰」，模型架构藏在闭源报告里，连训练入口都不告诉你。

Raj Dandekar 的这本《Pretraining a Mini Kimi K3》（预训练一个迷你 Kimi K3）想打破的就是这个叙事。它把 Moonshot AI 在 2026 年 7 月刚刚发布的 Kimi K3 旗舰架构，逐行拆开、整体缩小、再在自己的脚本里跑通——单卡 252 美元，50 亿 token，一个 10.2 亿参数的复刻版 MoE。

但这本书真正值钱的部分，不是终态那个 33.4% HellaSwag 的模型，而是它记录失败的方式。官方代码跑不起来的 4 个未文档化问题、MoE router 第 20 步就杀掉 94.5% 专家的专家坍塌、3 个不崩溃但悄悄出错的分布式 bug、一整章提速实验只有 3 次成功——全都原样写下来。

《Pretraining a Mini Kimi K3》是 Vizuara Books 上架的免费电子书之一，作者 Raj Abhijit Dandekar 是 MIT 博士、Vizuara AI Labs 联合创始人，也是 YouTube 系列 Build DeepSeek from Scratch 的主讲人。Vizuara Books 一共 49 本插图风格 AI 教材，这本是 2026 年 8 月刚发布的新作。

全书 30 个 capsule（Vizuara 的章节单位），按作者自己的话，是「一份跑完的预训练工作日志」：

整本书没有任何公式推导是凑出来的「为了显得专业」的部分，每一节都对应一次具体的训练实验或一次具体的代码改动。读完五小时，但你会在第四章、第五章的踩坑描述里反复回看。

想理解 Raj 的「缩小算术」，得先知道他在缩什么。2026 年 7 月 16 日，Moonshot AI 在 WAIC 2026 上海发布了 Kimi K3；7 月 27 日完整权重在 Hugging Face 开源，采用自定义的 Kimi K3 License——并非中文媒体广泛误传的「修改版 MIT」，其中对月活超 1 亿或 MaaS 年营收超 2000 万美元的场景设有额外授权条款。它也是目前参数量最大的开源模型之一。

一句话把它的配置讲清楚：

表里能看到三件对缩小至关重要的设计选择：第一，93 层的 KDA : Gated MLA = 3 : 1，是 Moonshot 在 Kimi Linear 系列里就坚持的混搭比例，Raj 把它原样搬到 12 层上；第二，top-k 路由（官方 16 / 总 896，复刻 6 / 更小专家池）保留了 MoE 的「稀疏激活」这个核心机制；第三，163,840 词表的 tokenizer 直接沿用官方，省掉重新训练分词器、重新对齐 embedding 的两个月。

另一个常被忽略的细节是 K3 用的不是 RoPE 而是 NoPE（No Positional Embeddings）——直接取消显式位置编码，靠注意力层内部的机制隐式感知位置。Raj 复刻时也保留了这个选择，没有为了「看着像主流」就改回 RoPE。

这是第 4 到第 8 capsule 的核心：怎么把 2.8T 缩到 1.02B，又不缩成「另一个模型」。

很多人的第一反应是「线性缩放」——所有维度除以同一个常数。但 Raj 在 capsule 5 Scaling it down without lying about it 里明确说这种做法会「骗」：最后实际采用的方案，每个维度的缩放比都不一样——hidden 维度缩约 14 倍、层数缩 7.75 倍、专家池只缩 3.5 倍、词表干脆 1 倍不动。没有统一的「缩放系数」，只有一个总参数约 2745 倍的目标，再按各维度对训练行为的实际影响分别定比例。

他的做法是「结构比例原样保留，容量按训练预算剪」：

capsule 8 专门做了一次「Counting the parameters, and checking the counter」：把 KDA、Gated MLA、AttnRes、LatentMoE 各自的参数贡献逐项相加，最后在 PyTorch 里用真实 forward 跑一次参数计数核对。手算和跑出来的数字一致才敢下笔。这个「自检」环节，是他把「不变成另一种模型」落到实处的关键。

很多人以为「预训练 = 把数据塞进去训」，于是对数据这一章期待不高。Raj 用 5 个 capsule（capsule 9–13）证明这是个错觉。

训练前准备的语料是 104.8B token，从 6 个公开来源混合：FineWeb-Edu（62.1B token）、FineWeb web-diverse（13.4B）、StarCoder2 的 code-python（14.9B）、FineMath（6.4B）、OpenWebMath（4.4B）、Cosmopedia（3.7B）。实际真正跑完的是 5,000,003,584 token（约 50 亿）——为什么没把 104.8B 跑完？就是预算：按 $252 的租金和实测吞吐，能跑到头的正好就是这个量级。

真正出彩的是 去污染（decontamination）。Raj 用 13-gram 匹配，对 8 个 benchmark（MMLU、ARC-Challenge、HellaSwag、GSM8K、HumanEval、PIQA、WinoGrande、TriviaQA）的测试集做了滑动窗口去重。这套做法从 GPT-3 论文传下来、SmolLM 团队也在用，但工程细节上有几个魔鬼：

• 归一化相当「粗暴」：大小写折叠之外，所有非字母数字字符一律按字节表替换成空格再切 13-gram——不精细，但可复现、无歧义；
• 数字层面：全库扫描 107,291,411 个 token、移除 138,064 个（约 0.13%）；八个基准的受污染程度差别很大，HumanEval 的平均 n-gram 匹配次数高达 88.78，是最「脏」的一个；
• filter 在空批次上仍然会触发——capsule 11 专门记了一节「When a filter fires on nothing」，这类边角案例通常没人愿意写；
• mix 配置文件里的 bug：capsule 13 记了一个险些让 token 流的源比例悄悄偏离设定、跑出 5B 看似正常但实际有偏数据的 bug。

还有一个很工程但很关键的细节——shard 格式与 checkpoint 容灾。语料切成 1,063 个 shard，训练状态配齐 state.pt、loader.json、meta.json 和 COMPLETE 完整性标记，任何一次中断都能从最近的完整检查点无损续训。这不是可选项——Raj 用的 Modal 平台单次运行上限 24 小时，5B token 的训练必须主动切成 3 段、靠检查点接力跑完，每段之间一旦失败需要重算的风险窗口从 32 分钟压到 15 分钟。在云租卡的世界里，「断点续训」是设计出来的，不是靠运气。

第三章 5 个 capsule（capsule 14–18）是全书最值钱的章节。capsule 14 标题只有一句话：「The released code cannot train.」

Moonshot 在 7 月 27 日开源 K3 权重的同时，也把 modeling_kimi_linear.py、modeling_kimi_moe.py 等建模代码放到了 GitCode / Hugging Face 仓库。但 Raj 很快撞上一个没人明说的事实：这份发布的建模代码，根本不能直接拿来训练——不是缺依赖、不是显存不够，而是 4 个藏在代码里的未文档化问题：

Raj 没有去改 Moonshot 的源码（毕竟那是官方权威版本），而是自己写了一个训练循环绕开这 4 个点。capsule 15 标题就叫 The training loop（WSD）——他用了 WSD 学习率调度（Warmup-Stable-Decay，MiniCPM 团队推广的方案），自己手写 forward、backward、optimizer.step、gradient clipping、checkpoint 保存。

这一节的真正价值在于：它把「开源权重 ≠ 可复现」这件事戳破了。GitHub 上 8 千多 star 的旗舰模型仓库（Kimi-K3 目前约 8.4k star），README 写得很漂亮，但「直接 clone 下来跑」和「能跑出数字」之间，还隔着 4 个未文档化的工程坑。这条经验放到任何一个新模型上——DeepSeek、Qwen、Mistral——都成立。

第 16 capsule 是全书最让人紧张的一节：「Expert collapse, and the metric that missed it.」

MoE 的理想状态是「不同 token 走不同专家，专家利用率均匀」。但 Raj 在训练跑到第 20 step 时发现：94.5% 的专家被 router「杀死」——也就是所有 token 都集中到了剩下 5.5% 的专家头上，剩下的专家们一次都没被选过。

最可怕的是：路由熵（router entropy）的读数还是 0.9999——一个接近「完美均匀」的数字。专家已经死了一大半，监控却告诉你一切正常。这就是 capsule 16 标题里那个「the metric that missed it」的真正含义：不是没有监控，是监控指标本身在这种坍塌模式下失灵了。

修复方法不是「打开 aux loss 系数」——K3 的负载均衡本来就是 aux-loss-free 设计。真正的修复是把 noaux_tc 的 bias 更新规则接对：每个专家的偏置按 bias += gamma × sign(平均负载 − 自身负载) 动态调整，gamma 取 1e-2。DeepSeek-V3 论文用的是 1e-3，但 batch size 不同不能照抄——书里干脆做了一组 gamma 扫描实验，把这个超参的取舍过程也原样写了进去。

第五章（05 More Than One GPU）的 capsule 27 记了更阴险的「Three distributed bugs that do not crash」。这类 bug 在多卡训练时悄悄存在：训练不崩、loss 正常下降、checkpoint 一切完好，但模型就是错的。它们的共同审计原则是——「哪些量在定义时是跨整个 batch 的，哪些现在只是按 rank 算的」：

• Bug 1：每个 rank 读了相同的 token。
  数据加载器的 SourceStream 接受 seed 却从不保存，所有 rank 都从 shard 0、offset 0 确定性遍历——等效 batch 被缩成名义值的 1/world（双卡时直接减半）。修复用 round-robin 发牌 sorted(found)[rank::world]。
• Bug 2：负载均衡器平衡了「错误」的东西。
  各 rank 用本地切片计算 sign(平均负载 − 负载) 并各自更新自己的 bias 副本，导致「同一 token 走哪个专家取决于它在哪张卡上」；修复需在 early-return 之前加一次 all_reduce。
• Bug 3：SpikeGuard 让优化器失去同步。
  每个 rank 各自算 loss 再喂给 SpikeGuard，阈值作用在「两个不同的数」上，可能一个 rank 调 opt.step()、另一个调 zero_grad()，权重从此分叉却无人报错。

书中还顺带记了两个同类问题：router bias 被 fully_shard 变成 DTensor 后 in-place 加法直接报错（这是这群 bug 里唯一会崩的一个），以及 Decoder 层返回 view 张量需 clone——不在正文但同族，延伸阅读可翻原书。

这三个 bug 都不会让训练崩，跑完的模型只是一个「安静的错」——loss 正常收敛、benchmark 数字看上去能复现，但你拿去对比官方评测时总会差几个点。原因就是这种「悄悄出错」。

第四章 7 个 capsule（capsule 19–25）记的是整本书最容易让人「反共识」的部分。Raj 把 MFU（Model FLOPs Utilization，模型算力利用率）作为「单位时间到底换到了多少有效计算」的核心指标——按 6 × 激活参数 × tokens/s ÷ 峰值算力来算——并把整个优化写成 16 次编号实验（attempt 1–16），其中只有 3 次真正成功（其余失败也原样记录）。

关键数字：只有 3 次成功——17.5x、1.38x、3.2x，其余失败也原样记录，capsule 21 还专门写了一节六个没成功的想法。17.5x 来自 capsule 20 的专家循环：MoE 的专家分发原本要在 Python 里循环启动 3,840 次，改成 3 次批量矩阵乘后，单步时间从 3.999 秒降到 0.228 秒，MFU 从 0.1% 拉到 4.1%。1.38x 来自 capsule 23：把 SiTU 激活链上的一串零碎算子融合成一个 Triton kernel，MFU 5.6%→7.7%。3.2x 来自 capsule 25 的 silent fallback：dispatch 缓冲区超限时会静默回退到慢路径，auto-chunking 把这个「无声的慢」消掉（这个倍数在旗舰运行上测得）。