Swiftlet 使 35B 與 80B Qwen 模型能在 Mac 與 iPhone 上以低 RAM 使用量運行

總覽

Swiftlet 是一個 Swift + Metal 執行階段，能在普通蘋果設備上運行 Qwen3‑Next‑80B‑A3B 和 Qwen3.6‑35B‑A3B 混合專家模型。它僅將每個模型的小型密集核心常駐於記憶體中，並依需求從儲存裝置串流路由專家權重，使得 35B 模型能在 iPhone 上以約 2.5 GB RAM 運行，而 80B 模型能在 Mac 上以約 4.3 GB RAM 運行。

專家串流運作方式

核心見解在於每個 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 作為其串流模型引擎嵌入。使用者可透過 Settings → Experimental Models 下載 35B 模型，並在無伺服器參與的情況下在設備上進行聊天。該應用程式的原始碼位於 leonickson1/localLLM；自行建置需要將 Swiftlet 儲存庫克隆為 swiftlet 並放置於該目錄旁，然後開啟 Xcode 專案。

正確性驗證

前向傳遞的每一層（Gated DeltaNet 遞迴、gated GQA 注意、稀疏 MoE 路由）均與 mlx‑lm 參考實作進行驗證，無論是 FP32 還是 int4 量化形式。增量解碼會與完整序列處理進行對比檢查。Metal 內核會與精確的 CPU 參考進行測試，且快速與純量 GPU 內核產出完全相同。容器可針對其來源檢查點進行位元組驗證，且串流放置永不改變模型語義：無論專家來自快取還是磁碟，其給出的答案皆相同。

與 TurboFieldfare 的關係

Swiftlet 建基於 TurboFieldfare 在 Mac 上對 Gemma 示範的專家串流理念。它採用了幾項已發表的設計經驗：透過 pread 將專家串流到有限槽位池中，以 LFU 加上近期淘汰進行淘汰，以固定步幅打包專家使一次讀取等於一次讀取，透過直接將下載的位元組路由到最終容器位置進行安裝，並在運行時編譯著色器。然而，Swiftlet 是從頭重新編寫的（約 10 k 行 Swift 與 Metal），並在多個方面有所不同：

支援 Qwen 混合堆疊，包含 Gated DeltaNet 線性注意力、gated GQA 和具共享專家的高稀疏 MoE，而 TurboFieldfare 則針對傳統密集 Gemma 架構。
在 Metal 中實作 MLX affine 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 證明了混合專家模型可以透過僅將小型密集核心常駐於記憶體中，並從儲存裝置串流路由專家來在消費者蘋果設備上運行。此方法使得 35B Qwen 模型能在 iPhone 上以約 2.5 GB RAM 運行，而 80B Qwen 模型能在 Mac 上以約 4.3 GB RAM 運行，達到適合實驗性設備端聊天的 token‑per‑second 速度。雖然該方法降低了 RAM 需求，但將瓶頸移至儲存頻寬與磨損，留給未來工作在快取策略、預取優化及硬體加速專家存取方面的改進空間。