本機推論／系統
JustFit 壓縮並即時調度 KV 狀態，讓 24 GiB MacBook 跑完 21 萬 token 工作負載
JustFit 在 MLX 中結合四位元 KV、元件駐留管理與跨請求狀態轉換，讓 27B 模型在 24 GiB 統一記憶體完成長上下文推論。6.93 倍容量增幅來自單機特定模型測試，且部分歷史環境與檢查點身分尚不能完整重現。
JustFit 將本機大型模型的瓶頸從「權重能否放入記憶體」擴展到整個執行期 live set：量化權重之外，KV cache、重建工作區、推測解碼器、輸出頭及並行請求狀態都會爭用 Apple Silicon 的統一記憶體。作者以 MLX 與 Qwen3.8-27B MXFP4 為基礎，提出三個互相配合的元件。
KVExec 以 TurboQuant 衍生的四位元表示保存 KV，使用 256-token page，解碼時直接讀取壓縮狀態；prefill 則在每層就地解包、反 Hadamard 旋轉，再立即交給標準 SDPA，避免同時保留所有層的浮點 KV。論文估算該模型每個位置的 KV payload 由 FP16 的 65,536 bytes 降至 16,640 bytes，但強調壓縮本身不夠，因為 192K context 的單層重建仍可能需要約 768 MiB。
PhaseSwap 依執行階段及「擁有者租約」卸載或恢復元件，例如中段 prefill 暫時釋放約 644 MiB 的輸出頭；StateTrans 則在請求加入、完成或由單請求推測解碼轉成連續批次時，保留目標模型 cache、回收 page 引用並協調元件生命週期。這讓狀態切換不必重建整條上下文。
在設有 21,000 MiB 程序上限的 M4 Pro MacBook 上，三次測試均完成 196,608-token 輸入加 16,384-token 輸出，共 212,992 個位置；論文所用 mlx-vlm 基線只能完成 30,720 個位置。另一項 32K 輸入測試達 19.11 token/s，AIME 2026 單次種子評估則答對 29/30。
這些數字不能混為同一效能結論：容量、吞吐與數學評估採不同工作負載，資料亦跨數個程式修訂。作者公開 mlx-vlm 分支與部分固定快照，但承認歷史 GPU 核心數、macOS、Python、MLX 版本及原始檢查點位元身分並不完整。後續重點是固定映像的第三方重現、其他模型與硬體的泛化，以及長上下文品質是否隨 KV 壓縮穩定維持。