模型與本機推論
POCKET 將 35B 稀疏 MoE 壓至 8.2 GB，標準 llama.cpp 可在手機與純 CPU 執行
VIDRAFT 公開 POCKET 系列權重，把 35B 模型量化至最低 8.2 GB，並保留約 3B 的每 token 啟用參數。模型可直接使用上游 llama.cpp，但壓縮方法未公開，效能與品質證據目前也主要來自開發團隊。
韓國團隊 VIDRAFT 釋出 POCKET，一組以 Darwin-36B-Opus 為基礎的裝置端模型。其核心不是讓手機逐 token 掃描全部 35B 權重，而是利用含 256 個專家、每次只啟用 8 個專家的稀疏 MoE 架構，把實際啟用量控制在約 3B；再提供 IQ1_M 至 Q4_K_M 等 GGUF 量化版本，檔案大小由 8.2 GB 至 21 GB。另有針對韓文、英文與 Apple MLX 的獨立版本。
技術上較值得注意的是相容性：POCKET 宣稱不需修改版 runtime，可直接交給標準 llama.cpp，因此既有的 LM Studio、Ollama 或自建 CPU 推論流程不必維護專用 fork。團隊在相同 8-vCPU Hugging Face Space 測得約 20.5 token/s，對照 27B dense Bonsai 的約 6.1 token/s；16 執行緒 Xeon、M3 Pro 與 H100 解碼也取得較高吞吐量。這符合記憶體頻寬受限的解碼特性：稀疏模型每步搬運的有效權重較少，即使總參數較大，仍可能快過較小的 dense 模型。
但「35B 跑在 iPhone」不能等同實用的手機助手。團隊尚未公布自行量測的 iPhone token/s、首 token 延遲、峰值記憶體、持續負載溫度或耗電；公開品質比較也僅列出 400 題 HellaSwag，61% 與 Bonsai 的 60%不足以證明推理、中文或程式能力。權重採 Apache-2.0，但產生極低位元版本的壓縮配方仍是專有技術。工程團隊接下來應以真實裝置重測 prefill、長上下文記憶體與熱降頻，並確認最低位元版本是否出現領域性退化。