Swiftlet 打包 80B Qwen 进入 Mac，内存占用 4.3GB；iPhone 17 将原生运行 35B 模型

一个名为 Swiftlet 的 Swift + Metal 运行时正在重新定义“大模型可以在哪里运行”。它专门针对 Qwen3-Next 和 Qwen3.5/3.6 系列的 MoE（混合专家）模型进行了定制。其核心思路非常巧妙：模型的小型密集核心部分保留在内存中，而大型部分——即路由专家权重——通常存储在 SSD 上，并在需要时流式加载。

从数据中可以清楚地看到结果。在 M5 Mac 上，Qwen3.6-35B-A3B 的 4 位版本在磁盘上占用 18GB，但内存峰值仅为 2.6GB，解码速度为每秒 7 到 11 个 token；更令人印象深刻的是 Qwen3-Next-80B-A3B 的 4 位版本，它在磁盘上需要 42GB，但内存峰值仅为 4.3GB，速度为每秒 4.5 到 5 个 token。35B 版本现在可以在 iPhone 17 上运行，内存约为 2.5GB，速度约为每秒 1 个 token——据开发者称，这是此类模型首次在手机上原生运行而无需接触服务器。

该项目完全端到端可用，两个模型都能产生经过验证的正确输出。开发者也承认这是一种权衡：每个 token 实际上激活了约 30 亿参数，因此这些模型在对话和写作时表现得像大模型，但在事实记忆方面仍表现得像小模型。

其工作原理在于细粒度的调度。每一层将每个 token 路由到 512 个专家中的 10 个（对于 80B 版本）或 256 个专家中的 8 个（对于 35B 版本）。Swiftlet 将密集权重——注意力机制、DeltaNet 投影、路由器、共享专家和嵌入向量——牢牢保留在内存中，4 位量化下分别占用约 1.3GB（35B）或 2.5GB（80B）。数千个路由专家被重新打包为固定步长的数据块，存储在 .qpack 容器中。获取一个专家只需要对 SSD 进行一次 pread 操作，无需 mmap，也不会干扰页面缓存。热门专家使用 LFU 加上最近性策略的淘汰机制缓存在有限的池中；命中率在 43% 到 70% 之间，缓存大小对速度几乎没有影响，因为 Apple 的 SSD 可以处理未命中的开销。

整个前向传播过程使用运行时编译的着色器在 Metal 上运行，因此构建期间不需要 Metal 工具链，相同的代码可以直接部署到 iOS。更有趣的是，75% 的层使用具有固定大小循环状态的 Gated DeltaNet 线性注意力，这意味着无论上下文长度如何，它都不会产生扩展的 KV 缓存——长文本对话的隐藏负担被悄然卸载。

Swiftlet 不仅仅是一个命令行玩具。它有四个专为自身设计的身份。作为库，SwiftletCore 可以嵌入到任何 macOS 或 iOS 应用中，提供带有流式增量输出和对话缓存的聊天功能；作为命令行工具，swiftlet chat 和 swiftlet generate 处理本地执行和基准测试，而 swiftlet-repack 直接从 MLX 检查点构建容器，并支持从 Hugging Face 恢复下载。作为服务器，swiftlet-server 在回环地址上提供与 OpenAI 兼容的 chat-completions 接口，允许任何与 OpenAI 兼容的聊天界面连接到本地模型；作为应用程序，iOS 版本的 Priv AI 将 SwiftletCore 嵌入为流式模型引擎，允许普通用户只需下载即可开始聊天。

关于正确性，每一层的前向传播都与 mlx-lm 参考实现逐层进行比较，涵盖 f32 和 int4 量化形式。增量解码也与完整序列结果进行了比较，Metal 内核经过反复验证，与精确的 CPU 参考一致。容器还可以对源检查点执行字节级验证——无论专家是从缓存还是磁盘读取，答案完全相同。

其灵感路径解释得很清楚：TurboFieldfare 首先验证了在 Mac 上对 Gemma 进行专家流式传输的可行性，Swiftlet 从中借鉴了一些公开的设计经验，例如使用 pread 将专家流式传输到有界槽池中，使用 LFU 加上最近性进行淘汰，以及使用固定步长打包使得一次读取等于一次获取。然而，其余部分都是从头编写的，包含约 10,000 行 Swift 和 Metal 代码，解决了完全不同的 Qwen 混合架构：Gated DeltaNet 线性注意力、门控 GQA 和高稀疏 MoE 带有共享专家。它甚至在 Metal 中实现了 MLX 风格的 int4/int8 组量化计算，使用字节寻址内核和 64 位偏移量来支持千兆字节的分片。