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 位偏移量來支援千兆位元組的分片。