Monarch Chrysalis v1：桌面 CPU 跑通的稀疏 MoE 推理模型

Monarch Chrysalis v1 是一款稀疏混合专家（MoE）模型，其核心特征是把推理从 token 空间搬到了潜在空间（latent space）。项目方近日宣布，首次训练已完成，架构经过验证可以端到端运行，并已在桌面级 CPU 上成功加载——一台普通的 Ryzen 7 5700X 加 31 GiB DDR4 内存，无需租用集群或显卡，冷启动 80 秒后即可在终端中对话，每一轮回答旁边都会同步打印潜在推理轨迹。

模型架构与规模

该模型共有 69.3 亿参数，每层设置 64 个专家，每个 token 激活其中 8 个，约 64.4 亿参数集中在专家堆栈中，整体采用稀疏路由策略。在专家堆栈之上叠加了一个潜在循环（latent loop），并配备一个学得的停止头（halting head），用来决定每次生成需要消耗多少个潜在推理槽位。

文章特别区分了两种「潜在推理」路径：

• 深度递归（depth recurrence）：在相同的 token 位置上多次复用同一套层堆栈，共享权重，推理最终仍以文本形式输出，多数 MoE 与潜在计算结合的工作属于此类；
• 序列维度潜在推理（sequence-dimension latent reasoning）：在序列末尾追加新的位置但不进行解码，把最后一个隐藏状态写回，作为下一次输入的 embedding，用这些槽位替代显式的思维链 token。当前模型走的是这一路径。

两种思路在文献中都已经有成熟工作，本次项目的贡献是让两者组合在一起并验证其工程可行性。

三台机器上的 E[N] 复现

E[N] 是模型在自身停止分布下预期消耗的潜在步数。模型编译了 4 个槽位，但每次平均只使用约 1 个。

• Kaggle TPU v5e-8（训练端遥测，static 路径）：1.023 – 1.070
• Kaggle CPU（推理，static 路径）：1.068
• 本地 Ryzen 7 5700X（推理，sparse 路径）：1.04 – 1.18

这三行数据的关键在于彼此的差异：硬件不同、数值精度不同、MoE 实现不同（一个走 dense capacity-dispatch 路径，另一个是独立实现的 sparse top-k gather），实际激活的专家也不同。本地路径用 fp32 路由，训练端用 bf16 路由，在 bf16 精度无法分辨的概率边界处，两种实现约 2.5% 的路由决策会落到不同专家上。

在这些路由不同的行上，混合输出的相对偏差测得为 0.34。作者指出，路由器无法区分两个专家，并不意味着两个专家在做相似的事——约四十分之一的行结果差异显著，但 E[N] 在三种环境下仍稳定落在 1.02 到 1.19 之间。换言之，E[N] 对 dtype、实现方式，以及那些实质性改变约 2.5% 行结果的边界噪声是稳健的。

这一复现说明了什么

三台机器运行的是同一份权重，这是结果的有效边界。它排除的是仪器与实现层面的伪影。文章回顾了项目历史上的几次「测量陷阱」：halting 扩展被钉在 bf16 量化粒度上、权重移动量被同一量化粒度截断、曾经出现一份由错误仪器产出的已发表数字，以及本次工作中一度引用错误指标的验证脚本。作者认为，测量误差是该项目最高基率的失败模式，本次三机复现至少为 E[N] 排除了这一类错误。

它无法回答的，是机制层面的「为什么」：潜在步数坍缩是这套架构固有的，还是这次特定训练跑出来的产物？两种假设都预测了相同的 E[N] 数值，因为所有测量都跑的是同一个 checkpoint。一项无法区分两个假设的实验，在它排除了第三个假设时仍然有价值，前提是清楚说明它排除了哪一个。

因此，作者强调，让模型真正展开到完整深度，仍然是后续需要做的决定性实验。本次三机复现的作用，是让那次实验值得去做，而不是把盲测变成冗余。