端側推論與開源執行時
Edge0 從 SSD 串流 MoE 專家，35B 模型短上下文僅需 2.9 GiB 活躍記憶體
新開源框架用預測式路由提前載入下一步專家，並以 Recover-LoRA 補償 int4 量化損失，讓 23GB checkpoint 不必整體常駐記憶體。官方在 M4 Pro 測得 14.9 至 17.7 token／秒，但目前僅支援 Apple Silicon，記憶體與品質數據也尚無獨立重現。
Edge0 將大型稀疏 MoE 的部署問題改寫為儲存層級管理：完整專家權重以 int4 格式保留在 SSD，執行時透過 memory mapping 只讀入當前 token 所需的專家，因此活躍記憶體取決於工作集，而非模型總參數。首批 Apache 2.0 預覽版包含以 Qwen3.5-MoE 為底的 35B-A3B，以及以 Ling 3.0 為底的 8B-A1B；模型、LoRA 與路由預測器以同一目錄發布，並可透過 OpenAI 相容的 `/v1/chat/completions` 端點服務。
直接按路由結果才從 SSD 載入權重，通常會讓每層等待 I/O。Edge0 因而訓練額外的 prerouter head，提前一個步驟預測將被選中的專家，使讀取與目前的 forward pass 重疊。專案聲稱此設計可讓解碼吞吐量最多增加 59%，但效果會隨 SSD 延遲、模型大小、路由寬度與預測命中率改變；錯誤預取還可能浪費頻寬。後端介面已與 MLX 實作分離，惟 CUDA 目前仍只是預留項目。
另一項 Recover-LoRA 以 FP16 教師蒸餾凍結的 int4 模型，試圖補回量化誤差，且不把 adapter 合併進基礎權重。官方以五項基準比較後，35B 版平均比 FP16 底模低 3.9 分，8B 版低 2.8 分；這仍是團隊自行執行的 OpenCompass 結果，且不同模型的底模並不相同。
在 24GB Mac mini M4 Pro、約 3,300-token 提示與 200 個計時解碼 token 的測試中，35B 版為 14.9–17.7 token／秒、短上下文活躍記憶體峰值 2.9 GiB；完整量化檔仍約 23GB並存放於磁碟。長上下文的 KV cache 會另行增長，因此「3GB 跑 35B」不能解讀成總儲存或系統記憶體需求。工程上接下來應關注手機實測、冷啟動與多請求抖動、SSD 寫入壽命，以及 CUDA 後端能否維持相同工作集與吞吐優勢。