276B混合专家模型：24GB苹果迷你机能跑多快

混合专家（MoE）模型的特点是每个词元只会激活少数几个专家，这不同于稠密模型在每次前向传播都要触及全部权重。因此可以把大部分权重保留在磁盘上，只在需要时读取路由到的那一小部分。问题也由“模型能否放入内存”变为“固态硬盘的读取速度能否跟上”，这使得远超机器名义内存容量的模型有机会运行，但受限于每秒可处理的词元速率。我关心的就是这个速率到底是多少。最初的问题很具体：Inkling‑Small（总参数约2760亿、激活参数约120亿）能否在只有24GB内存的苹果迷你机上运行？这个问题应当用算术而不是猜测来回答——于是我把算术和机器放在一起验证。

我写了一个约250行、无外部依赖且不下载权重的成本模型。输入是config.json或manifest.json，输出是从配置推导出的字节数。模型按磁盘上实际的MLX分组仿射量化（grouped affine quantization）格式建模：每个量化投影包含权重字节，外加每64个输入维度一组的bf16缩放系数和偏置（各一份）。这样可以精确估算物理存储布局和大小。

为避免过拟合到单一容器，我设计了两道验证门槛。第一道门是逐字节复现一个已知容器：使用第三方Swiftlet（一个以自有磁盘格式存储MoE权重的Swift/Metal运行时）的实际config.json去预测它发布的布局。由于这些计数是整数，预测必须精确相等而不是近似。对四项关键计数的预测均完全一致，整体容器大小的误差在0.137%以内，残差来自我没有建模的部分（如分词器和聊天模板）。 球友会

第二道门是预测另一个由不同转换器产生的模型的磁盘大小。我预测的是151.8GB，而发布值为153.5GB，偏差约1.1%，在我设定的2%容差内。剩余偏差可以解释为模型没有建模的一些组件：视觉和音频编码器、RMS归一化、8位路由器门控、以及safetensors格式的头部等。

但在2026年8月14日我做了更正：第二道门不再通过。之前看起来只有1.1%的误差实际上是两个错误相互抵消的结果——我误以为存在一个稠密的MLP层，然而模型头文件显示是两个稠密层，因此我把混合专家层数算成了41层，实际为40层。修正后预测降到148.23GB，与公布值的偏差扩大到3.4%，超出2%的容差。多算的那一层把预测抬高了约3.54GB，而真正未建模的部分把预测压低了约5.27GB，两者几乎相互抵消，因此早先的1.1%掩盖了更大的误差。第一道门不受影响，仍然精确。

这两个验证门在每次运行脚本时都会执行：只要有一道失败，脚本就会拒绝输出任何关于词元速率的估计。这一点在后续分析中显得很重要。 球友会