Swiftlet: 在 Mac 和 iPhone 上執行 80B 與 35B Qwen 模型
Swiftlet 讓大型混合專家 (MoE) 模型，特別是 Qwen3-Next 與 Qwen3.5/3.6 系列，能在消費級 Apple 硬體上執行。透過按需從儲存裝置串流路由權重，而非將整個模型載入記憶體，Swiftlet 讓 80B 參數模型能在 Mac 上以 4.3 GB RAM 執行，並讓 35B 參數模型在 iPhone 上以 2.5 GB RAM 執行。
專家串流架構
Swiftlet 藉由利用 MoE 模型的稀疏性來實現低記憶體佔用，在任何給定 token 時，只有一小部分參數是處於活動狀態的。在 Qwen 混合模型中，每個 token 僅約有 3B 參數處於活動狀態。
記憶體管理與權重串流
為了最小化 RAM 使用量，Swiftlet 採用了特定的記憶體策略：
- 常駐密集權重 (Resident Dense Weights)： 執行環境會將必要的密集權重——包括 attention、DeltaNet projections、routers、shared experts 與 embeddings——永久保留在記憶體中。在 4-bit 量化下，這對於 35B 模型需要約 1.3 GB，對於 80B 模型則需要約 2.5 GB。
- 固定步長 Blob (Fixed-Stride Blobs)： 路由專家被重新封裝進一個使用固定步長 blob 的
.qpack容器中。這讓系統能透過單次pread操作從 SSD 取得特定的專家，從而避免mmap的開銷與 page-cache thrashing。 - LFU 快取： 一個有界池透過結合近期汰換 (recency eviction) 的最不常用 (LFU) 策略來快取「熱點」專家。由於 Apple SSD 提供高吞吐量，即使在快取命中率介於 43% 到 70% 之間時，系統仍能維持效能。
硬體加速
Swiftlet 是使用 Swift 與 Metal 編寫的，利用執行時編譯的 shader 來在 GPU 上執行前向傳播 (forward pass)。這種方法不需要在建置時使用 Metal 工具鏈，並確保了在 macOS 與 iOS 上的相容性。
效能與模型支援
Swiftlet 支援 Qwen MoE 混合系列的 4-bit 量化版本。效能因裝置與模型大小而異：
| Model | Disk Space | Peak RAM | Decode Speed (M5 Mac) |
|---|---|---|---|
| Qwen3.6-35B-A3B | 18 GB | 2.6 GB | 7 to 11 tok/s |
| Qwen3-Next-80B-A3B | 42 GB | 4.3 GB | 4.5 to 5 tok/s |
在 iPhone 17 上，35B 模型在約 2.5 GB RAM 下以每秒約 1 個 token 的速度執行。
架構權衡
雖然模型維持了大型模型的對話與寫作能力，但作者指出，由於每個 token 僅有 3B 參數處於活動狀態，它們「回憶事實的能力就像小型模型一樣」。
實作與工具
Swiftlet 被設計為以函式庫為首要目標，提供四種主要與模型互動的方式：
- Swift Package：
SwiftletCore可以透過SwiftletSession整合進 macOS 或 iOS App，用於對話、串流 delta 與處理記憶體壓力。 - CLI 工具：
swiftlet chat與swiftlet generate用於本地使用，以及swiftlet-repack用於將 MLX checkpoint 轉換為.qpack容器。 - OpenAI 相容伺服器：
swiftlet-server提供一個 loopback API，讓任何 OpenAI 相容的 UI 都能連接到本地模型。 - iOS App： App Store 上的 Priv AI App 嵌入了 SwiftletCore，以提供原生的裝置端對話體驗。
技術譜系與正確性
Swiftlet 建立在 TurboFieldfare 為 Gemma 模型證明的「專家串流論點」之上。它採用了 TurboFieldfare 的幾項設計經驗，包括使用 pread 進行串流、LFU 汰換以及執行時 shader 編譯。
為了確保正確性，前向傳播的每一層——包括 Gated DeltaNet 遞迴與稀疏 MoE 路由——都使用 f32 與 int4 量化形式的每層 fixture，針對 mlx-lm 參考實作進行了驗證。
社群觀點
使用者之間的討論突顯了這種方法的潛力與實際限制：
硬體損耗： 一些使用者對持續的磁碟交換可能會導致 SSD 提早損耗（「NAND burners」）表示擔憂。
預填充瓶頸 (Prefill Bottlenecks)： 評論者指出，雖然解碼速度可以接受，但預填充階段（處理初始提示詞）對於長上下文而言可能會成為顯著的瓶頸。
可擴展性： 一些使用者建議 RAM 快取應該是可調的，讓擁有更多 RAM（例如 32 GB）的使用者可以增加快取大小以進一步提升速度。
裝置端 AI 的未來： 支持者認為，這是在邁向未來的一個必要步驟，即大型模型能在消費級硬體上執行，並可能將昂貴的 GPU 集群替換為負擔得起的 SSD 儲存裝置。