Swiftlet 在 Mac 和 iPhone 上以低 RAM 使用量启用 35B 和 80B Qwen 模型

概览

Swiftlet 是一个 Swift + Metal 运行时，能够在普通 Apple 设备上运行 Qwen3‑Next‑80B‑A3B 和 Qwen3.6‑35B‑A3B 混合专家模型。它只将每个模型的小型密集核驻留在内存中，并根据需要从存储流式传输路由的专家权重，使得 35B 模型能够在约 2.5 GB RAM 的 iPhone 上运行，而 80B 模型能够在约 4.3 GB RAM 的 Mac 上运行。

专家流式传输的工作原理

核心洞察是每个 token 仅激活约 3 B 的模型参数。对于每一层，模型将 token 路由到一小部分专家（80B 模型为 512 中的 10，35B 模型为 256 中的 8）。Swiftlet：

将密集权重（注意力、DeltaNet 投影、路由器、共享专家、嵌入）保持驻留：在 4‑bit 量化下，35B 模型约为 1.3 GB，80B 模型约为 2.5 GB。
将数万个路由的专家重新打包为固定大小的专家槽位，并在带有 LFU 加最近使用淘汰的有限池中缓存热门专家。由于 Apple SSD 能够吸收缺失，缓存大小对速度影响甚微。
使用运行时编译的着色器在 Metal 上执行完整的前向传播，因此构建时不需要 Metal 工具链，且相同的二进制文件可在 iOS 上运行。
对 75 % 的层使用 Gated DeltaNet 线性注意力，这保持了固定大小的循环状态，并且无论上下文长度如何都不会导致 KV 缓存增长。

性能和资源使用情况

模型	磁盘大小	峰值 RAM	解码速度（M5 Mac）	iPhone 17 速度
Qwen3.6‑35B‑A3B (4‑bit)	18 GB	2.6 GB	7‑11 tok/s	~1 tok/s
Qwen3‑Next‑80B‑A3B (4‑bit)	42 GB	4.3 GB	4.5‑5 tok/s	未测量
这些数字来源于项目的 README。低 RAM 占用是因为只有密集核和一小部分活跃的专家集驻留在内存中；其余权重根据需要从 SSD 流式传输。

入门指南

要在 Mac 上尝试 Swiftlet：

克隆仓库并构建发布二进制文件：

git clone https://github.com/leonickson1/Swiftlet.git && cd Swiftlet
swift build -c release

从 Hugging Face 下载模型容器（可恢复）：

.build/release/swiftlet-repack \
  --from-hf Leonickson/Qwen3.6-35B-A3B-qpack \
  --output ~/models/qwen3.6-35b.qpack

或针对 80B 模型：

.build/release/swiftlet-repack \
  --from-hf Leonickson/Qwen3-Next-80B-A3B-qpack \
  --output ~/models/qwen3-next-80b.qpack

运行聊天会话：

.build/release/swiftlet chat ~/models/qwen3.6-35b.qpack \
  "Who wrote One Hundred Years of Solitude?" \
  "What language did he write it in?"

生成带统计信息的文本：

.build/release/swiftlet generate ~/models/qwen3.6-35b.qpack \
  --gpu --chat --prompt "Explain expert streaming in one paragraph."

启动 OpenAI‑兼容服务器（仅回环）：

.build/release/swiftlet-server --model ~/models/qwen3.6-35b.qpack --port 8080

相同的 swiftlet-repack 命令可以重新打包原始 MLX 检查点（--from-hf mlx-community/... 或 --source /path/to/checkpoint）。要求：Apple Silicon，macOS 14+ 或 iOS 17+，以及足够的 SSD 空间（约 18 GB 用于 35B，约 42 GB 用于 80B）。

使用选项

Swiftlet 首先被设计为库，具有四种主要使用方式：

Swift 包 – 将 SwiftletCore 添加到任何 macOS 或 iOS 应用中，并使用 SwiftletSession 进行带有流式增量、对话缓存、采样控制和内存压力处理的聊天。
命令行界面 – swiftlet chat 和 swiftlet generate 用于本地使用和基准测试；swiftlet-repack 用于从 MLX 检查点构建容器，包括直接从 Hugging Face 流式传输并支持断点续传。
OpenAI‑兼容服务器 – swiftlet-server 在回环上实现 chat‑completions API，使得任何与 OpenAI‑兼容端点通信的 UI 都能使用流式本地模型。
iOS 应用 – App Store 上的 Priv AI 应用将 SwiftletCore 作为其流式模型引擎嵌入。用户可以通过设置 → 实验模型下载 35B 模型，并在设备上无需服务器即可聊天。该应用的源代码可在 leonickson1/localLLM 获得；自行构建需要将 Swiftlet 仓库克隆为 swiftlet 并放置在其旁边，然后打开 Xcode 项目。

正确性验证

前向传播的每一层（Gated DeltaNet 循环、门控 GQA 注意、稀疏 MoE 路由）均与 mlx‑lm 参考实现进行验证，既包括 FP32 也包括 int4 量化形式。增量解码经过完整序列处理的检查。Metal 内核经过精确 CPU 参考的测试，且快速和标量 GPU 内核产生完全相同的输出。容器可以与源检查点进行字节级验证，且流式放置永不改变模型语义：无论专家来自缓存还是磁盘，其给出的答案都是相同的。

与 TurboFieldfare 的关系

Swiftlet 建立在 TurboFieldfare 为 Mac 上的 Gemma 所展示的专家流式传输思想之上。它采用了一些已发表的设计经验：通过 pread 将专家流式传输到有限槽位池中，使用 LFU 加最近使用进行淘汰，以固定步幅打包专家使得一次读取等于一次获取，通过将下载的字节直接路由到其最终容器位置进行安装，并在运行时编译着色器。然而，Swiftlet 是从零开始编写的（约 10 k 行 Swift 和 Metal 代码），并在以下几方面有所不同：

支持包含 Gated DeltaNet 线性注意力、门控 GQA 和具有共享专家的高稀疂ity MoE 的 Qwen 混合栈，而 TurboFieldfare 针对的是经典的密集 Gemma 架构。
在 Metal 中实现了 MLX 仿射 int4/int8 组量化，使用带有 64‑bit 偏移的字节寻址内核以处理多吉字节碎片，提供合作的 simdgroup GEMV 快速路径以及显式的风险管理。
提供了经过验证的 CPU 参考实现和夹具基础设施，以保护每个内核更改。
包含 .qpack 容器和重新打包器，一个可恢复的 Hugging Face 流式安装程序，具备停顿恢复和下载取消功能。
添加了聊天会话层，用于处理思考和非思考的 Qwen 变体，带有存在和频率惩罚的采样、最小长度和句子完成停止、带有 delta 预填充的对话缓存以及 iOS 内存压力协调。
提供端到端的 iPhone 支持，包括应用引擎集成。该项目承认从 colibrì 获得缓存和放置政策的灵感，并在整个过程中使用 mlx‑lm 作为正确性参考。Swiftlet 是在与 Claude Code 合作下构建的。

社区反馈和局限性

Hacker News 帖子的评论突显了热情与担忧：

乐观观点：一些人认为这是迈向消费设备能够高效运行大型模型未来的进步，有一位评论者指出 "this is how progress happens"，另一人表示 "Running a 35B on iPhone at 1 tok/s with 2.5 GB RAM… this is the future of on-device inference."
对存储磨损和速度的担忧：多位用户警告频繁的专家流式传输可能会磨损 SSD，并且解码速度较低（例如 "At what, 10 tokens per hour? These disk swapping methods all have the same drawbacks - kill your drive early, and slow as hell." 以及 "prefill becomes the bottleneck… half an hour to process 10k tokens on an M5 seems… not great"）。
对可调 RAM 使用的需求：一位拥有 32 GB Mac 的用户询问 RAM 使用是否可以配置以利用额外内存实现更快执行。
对 Claude Code 合作的疑问：评论者好奇 "built in collaboration with Claude Code" 这一说法是否表示与 Anthropic 的正式合作，还是仅仅指出 AI 辅助开发。
与其他项目的比较：分享了类似的流式权重尝试的链接（例如 iPhone 上声称的 400B 模型）以及对诸如 BigMoeOnEdge 之类的替代实现的引用。
平台特定的询问：用户询问 Android/Linux/Windows 支持以及该方法是否可以移植到其他平台。

这些反馈体现了专家流式传输固有的权衡：以低 RAM 占用为代价，增加了 SSD 流量和延迟，尤其是在预填充阶段。

结论

Swiftlet 展示了通过仅将少量密集核保留在内存中并从存储流式传输路由的专家，Mixture‑of‑Experts 模型可以在消费级 Apple 设备上运行。该方法使得 35B Qwen 模型能够在约 2.5 GB RAM 的 iPhone 上运行，而 80B Qwen 模型能够在约 4.3 GB RAM 的 Mac 上运行，实现了适用于实验性设备端聊天的 token‑per‑second 速度。虽然该方法降低了 RAM 需求，但将瓶颈转移到了存储带宽和磨损，为未来的缓存策略、预取优化和硬件加速的专家访问留下了空间。