一個叫 Swiftlet 的 Swift + Metal 運行時正在重新定義"大模型能跑在哪"。它專門伺候 Qwen3-Next 和 Qwen3.5/3.6這一族 MoE 混合模型，核心思路很狡猾:只讓模型的小型稠密核心常駐內存，真正的大頭——那些路由專家權重——平時躺在 SSD 裏，用到時才按需求流式取出來。

效果直接體現在數字上。在 M5Mac 上，Qwen3.6-35B-A3B 的4-bit 版本磁盤佔18GB，但峯值內存只有2.6GB，解碼速度7到11tok/s;更誇張的是 Qwen3-Next-80B-A3B 的4-bit 版，磁盤要42GB，可峯值內存竟壓到4.3GB，速度4.5到5tok/s。35B 版本如今還能在 iPhone17上跑起來，內存約2.5GB，速度大約1tok/s——據開發者所知，這是該量級模型第一次在手機上原生運行，全程不碰服務器。

image.png

項目已經端到端可用，兩個模型都能吐出經過驗證的正確輸出。開發者也坦白了一個代價:每個 token 實際只激活約3B 參數，所以這些模型在對話和寫作時像個大模型，事實記憶上卻還是個小模型。

拆開它的工作原理，門道在於調度的精細度。每一層會把每個 token 路由到512個專家裏的10個（80B 版）或256個專家裏的8個(35B 版)。Swiftlet 把稠密權重——注意力、DeltaNet 投影、路由器、共享專家、嵌入向量——牢牢釘在內存裏，4-bit 下約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 加近期性淘汰、固定步長打包讓一次讀取即一次 fetch。但其餘部分基本從零寫起，約一萬行 Swift 和 Metal 代碼，硬啃下了架構完全不同的 Qwen 混合體系:Gated DeltaNet 線性注意力、門控 GQA，以及帶共享專家的高稀疏 MoE。它甚至在 Metal 裏實現了 MLX 風格的 int4/int8分組量化計算，用字節尋址內核和64位偏移撐起數 GB 的分片。

想上手機，要求並不苛刻:Apple Silicon、macOS14+ 或 iOS17+，再加上足夠的 SSD 空間（35B 要18GB，80B 要42GB）。iPhone 端目前可在 App Store 的 Priv AI 應用裏開啓 Experimental Models 下載，該功能隨新版本發佈，尚在審覈通道中，想立刻體驗也可從源碼自構建。整個項目以 Apache2.0釋出，模型權重單獨下載並遵循各自條款。