276B模型从固态硬盘流式加载，24GB苹果迷你机能跑多快？

混合专家模型每个词元只激活少数几个专家，这与稠密模型每次前向传播都要触碰全部权重不同。因此权重可以留在磁盘上，只读取每个词元路由到的部分。问题就从“模型能否装进内存”变成了“固态硬盘有多快”，这让远超机器标称容量的模型变得可以运行，只是受限于一定的词元速率。 我想知道这个速率究竟是多少。最初的问题很具体：Inkling-Small（总参数2760亿，激活参数120亿）能否在24GB内存的苹果迷你机上运行？答案应该来自算术，而不是猜测。这就是算术与机器相遇后发生的事情。 第一幕：不能出错的预测才有价值 我写了一个约250行、无依赖、不下载权重的成本模型。每个输入都是config.json或manifest.json，每个输出都是从配置推导出的字节数。它按照磁盘上的实际存储方式对MLX仿射分组量化建模：每个量化投影包含权重字节，加上输入维度上每64个值一组的一个bf16缩放系数和一个bf16偏置。 明显的失败模式是模型被调到只与检查过的对象一致。所以它被两道门控约束，对照的是我完全没有参与制作的产物。第一道门：逐字节复现一个真实容器。Swiftlet是第三方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%所显示的要大。第一道门不受影响，仍然精确。后续文章会展开这一点。 两道门在每次调用时都会运行，只要有一道失败，脚本就拒绝输出任何词元速率估计。这一点后来很重要。有趣的结构性结果是，总量 特别