Swiftlet：让 80B 大模型跑在 4.3GB 内存里的专家流式推理

一台 16GB 内存的 Mac mini 跑 80B 参数的大模型，一台 iPhone 17 跑 35B 参数的模型——而且不是靠云端中转，全部在本地完成。开源项目 Swiftlet 用一种叫做「专家流式推理」（Expert Streaming）的技术做到了这一点，峰值内存占用分别只有 4.3GB 和 2.5GB。

Swiftlet 项目主页

Swiftlet 是一个用 Swift + Metal 编写的推理引擎，专门针对 Qwen3-Next 和 Qwen3.5/3.6 MoE 混合架构模型家族设计。它的核心思路：不把整个模型加载到内存里，而是只保留每个 token 都需要的那一小部分稠密权重常驻内存，其余几万个「专家」权重存在 SSD 上，用到时再按需读取。项目以 Apache 2.0 开源，代码和预封装模型权重均已上传 HuggingFace。

MoE 架构为什么能流式加载

理解 Swiftlet 的工作原理，需要先拆解它服务的模型架构。Qwen3-Next-80B-A3B 是阿里巴巴发布的一个 MoE（Mixture-of-Experts）模型，总参数量 80B，但每个 token 只激活约 3B 参数。它的 MoE 层有 512 个路由专家（routed experts）和 1 个共享专家（shared expert），每个 token 由路由器选出其中 10 个专家执行计算。Qwen3.6-35B-A3B 则有 256 个路由专家，每个 token 激活 8 个。

这意味着模型在推理时，80B 的权重中只有极小一部分被每个 token 使用。传统做法是把全部权重加载到 GPU 内存，这对 80B 模型意味着几十 GB 的内存占用。Swiftlet 反过来想：既然每一步只需要 10 个专家，为什么不能用到时再从磁盘读？

这正是「专家流式推理」的思路。这个概念并非 Swiftlet 首创——Apple 在 2023 年发表的论文《LLM in a Flash: Efficient Large Language Model Inference with Limited Memory》提出了在闪存上按需加载模型权重的基本框架。2026 年 7 月，开源项目 TurboFieldfare 首先在 Gemma 4 26B 上验证了这条技术路线的可行性：将稠密共享层常驻内存，路由专家放在 SSD 上按需读取，26B 模型在 8GB 内存的 M2 MacBook Air 上跑出了每秒 5-6 token 的解码速度。Swiftlet 把同样的思路扩展到了架构完全不同的 Qwen MoE 家族，并进一步推到了 iPhone 上。

Swiftlet 的四个核心设计

Swiftlet 在约一万行 Swift 和 Metal 代码中实现了四个关键工程决策。

1. 稠密核心常驻，专家按需读取

Swiftlet 把模型权重分成两类。第一类是每个 token 都需要的稠密部分：注意力投影、DeltaNet 投影、路由器、共享专家、嵌入表。这部分常驻内存，4-bit 量化后约 1.3GB（35B 模型）或 2.5GB（80B 模型）。第二类是路由专家，数万个被压缩进 .qpack 容器文件存在磁盘上。解码时，路由器为当前 token 选出需要的专家，引擎从 SSD 读取对应数据块，计算后释放。

模型	磁盘占用	峰值内存	解码速度（M5 Mac）
Qwen3.6-35B-A3B, 4-bit	18 GB	2.6 GB	7-11 tok/s
Qwen3-Next-80B-A3B, 4-bit	42 GB	4.3 GB	4.5-5 tok/s

35B 模型在 iPhone 17 上也能运行，内存占用约 2.5GB，解码速度约 1 tok/s。

2. 固定步长的 pread 读取

Swiftlet 没有使用 mmap 来映射专家权重。mmap 依赖操作系统的页面缓存管理，当读取模式高度稀疏（每层只取 8-10 个专家中的特定几个）时，页面缓存频繁换入换出会造成性能抖动。Swiftlet 用 POSIX pread 系统调用直接从文件描述符读取指定偏移量的数据，把数万个路由专家重新打包成固定步长（fixed-stride）的 blob——每个专家在容器中的位置可以通过计算精确定位，读取一个专家等于一次 pread 调用。

这种设计避免了页面缓存抖动，也避免了 mmap 带来的虚拟内存地址空间膨胀。代价是容器构建阶段需要预处理：swiftlet-repack 工具把 MLX 格式的 checkpoint 重新组织成 .qpack 格式，支持从 HuggingFace 直接流式下载（带断点续传）。

3. 专家缓存池与 LFU+LRU 淘汰

并非每次读取都需要触发磁盘 I/O。Swiftlet 在内存中维护一个有界专家缓存池，用 LFU（Least Frequently Used）加 LRU（Least Recently Used）的混合策略淘汰。实测中，缓存命中率在 43% 到 70% 之间波动，但对吞吐量的影响很小——因为 Apple Silicon 的 NVMe SSD 随机读取延迟足够低，未命中的惩罚被 GPU 计算时间掩盖了。

这一点很关键：如果 SSD 随机读延迟像传统机械硬盘那样在毫秒级，专家流式推理根本不可行。Apple Silicon 的统一内存架构和嵌入式 SSD 的高速随机读写能力，是这条技术路线能落地的硬件基础。

4. Gated DeltaNet 线性注意力

Qwen3-Next 的架构还有一个对内存友好的特性：75% 的层使用 Gated DeltaNet 线性注意力，替代传统的 Transformer 自注意力。Gated DeltaNet 维护固定大小的递归状态，不随上下文长度增长产生 KV cache。对于 25% 使用 Gated GQA 注意力的层，KV cache 仍然存在，但总量比全自注意力架构小得多。这意味着无论上下文拉到多长，Swiftlet 的注意力部分内存占用都是可控的，瓶颈始终在专家流式读取上。

Gated DeltaNet 来自 NVIDIA 和 MIT 的研究，核心是用门控增量规则（gated delta rule）维护一个固定维度的状态矩阵，每处理一个 token 对状态做增量更新，替代传统的注意力分数矩阵。Qwen3-Next 把它和 Gated GQA 混合使用，兼顾长上下文效率和关键位置的精确注意力。

四种使用方式

Swiftlet 提供了四种使用入口：

Swift 包。SwiftletCore 是一个 Swift Package，可以嵌入任何 macOS 或 iOS 应用。SwiftletSession 封装了聊天会话管理，支持流式输出增量、对话缓存、带重复控制的采样、以及 iOS 的内存压力协调。

命令行工具。swiftlet chat 和 swiftlet generate 用于本地交互和基准测试。swiftlet-repack 用于从 MLX checkpoint 构建 .qpack 容器，支持从 HuggingFace 流式下载（带断点续传和停顿恢复）。

bash

# 下载 35B 模型容器（支持断点续传）
swiftlet-repack \
  --from-hf Leonickson/Qwen3.6-35B-A3B-qpack \
  --output ~/models/qwen3.6-35b.qpack

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

OpenAI 兼容服务器。swiftlet-server 在本地端口启动一个兼容 OpenAI chat-completions API 的服务，任何支持 OpenAI 端点的聊天 UI 都可以直接对接。

iOS 应用。Priv AI 是 App Store 上线的 iOS 应用，内置 SwiftletCore 作为流式模型引擎。用户在应用的「实验性模型」中点击下载即可在手机上运行 35B 模型，所有计算在设备端完成，不连接任何服务器。应用本身也在 leonickson1/localLLM 开源。

正确性保证

Swiftlet 对每一层前向传播（Gated DeltaNet 递归、门控 GQA 注意力、稀疏 MoE 路由）都用 mlx-lm 参考实现做逐层验证。增量解码与整序列处理的结果做了交叉比对。Metal 内核与 CPU 参考实现做了逐位对比，快速路径和标量路径的输出经确认完全一致。.qpack 容器与源 checkpoint 做字节级校验。流式放置不改变模型语义：无论专家数据来自缓存还是磁盘，输出结果相同。

能力边界

Swiftlet 在 README 中诚实标注了一个认知：这两个模型每个 token 只激活约 3B 参数，所以它们的语言流畅度接近大模型，但事实回忆能力更像小模型。80B 参数的权重容量提供了更好的语言生成质量，但稀疏激活意味着它在需要精确知识回忆的场景下表现不如预期。

当前开发重点是内核速度优化。解码循环的瓶颈在 dispatch 调度而非 I/O，因此还有明确的提速空间。解码速度方面，80B 模型在 M5 Mac 上约 4.5-5 tok/s，35B 约 7-11 tok/s，iPhone 17 上约 1 tok/s——对于手机端运行 35B 模型来说，这个速度可以支撑基础的对话交互。

Swiftlet 明确致谢了 TurboFieldfare 项目（首先在 Gemma 上验证了专家流式推理在 Apple 硬件上的可行性）和 colibrì（缓存与放置策略的思路来源），以及 mlx-lm（贯穿始终的正确性参考）。项目使用 Claude Code 协助编写，README 中标注了这一事实。

这条技术路线意味着什么

MoE 模型的流式推理已经跨过概念验证阶段，进入可用工具阶段。当 Qwen3-Next 这类高度稀疏的 MoE 架构（80B 总参数，3B 激活）遇上 Apple Silicon 的低延迟 NVMe SSD，模型尺寸和内存需求之间出现了一条可以撬动的杠杆。Swiftlet 是这条技术线上的一个新节点：它把流式推理从 Gemma 的稠密 Transformer 架构扩展到了 Qwen 的混合注意力+稀疏 MoE 架构，并第一个把这种规模的模型推上了 iPhone。

同类项目在过去几周密集出现——TurboFieldfare、SwiftLM、flash-moe 等都从不同角度切入这个问题。Swiftlet 的差异在于：针对 Qwen 混合架构从零编写了完整的 Metal GPU 内核（包括 int4/int8 分组量化的 GPU 计算、cooperative simdgroup GEMV 快速路径），不依赖 Metal 工具链的编译期集成，而是运行时编译 shader；同时提供了端到端的 iPhone 支持，从引擎集成到 App Store 上架。

对于开发者而言，Swiftlet 降低了在消费级 Apple 设备上运行百亿参数模型的内存门槛。在 16GB Mac mini 上跑 80B 模型、在 iPhone 上跑 35B 模型，不再需要等待云端 API 响应，所有计算在本地完成，数据不出设备。

来源：

GitHub: leonickson1/Swiftlet
HuggingFace: Leonickson/Qwen3-Next-80B-A3B-qpack
Qwen3-Next 官方博客: qwen.ai
Apple 论文: LLM in a Flash: Efficient Large Language Model Inference with Limited Memory (2023)