在 M4 Pro Mac Mini 上設置本地 LLM

Apple Silicon 上的本地 LLM 基礎設施

在配備 48GB 統一記憶體的 M4 Pro Mac Mini 上運行本地 LLM 伺服器，可以建立一個私密且成本可預測的 AI 後端，處理大約 80% 的日常任務，而無需依賴雲端 API。此設置利用 oMLX 進行推理，使用 Tailscale 進行安全的跨裝置網路連接，並結合混合專家模型 (MoE) 與密集模型 (dense models) 以平衡推理深度與系統效能。

硬體與軟體堆疊

此設置的核心是作為全天候伺服器的 M4 Pro Mac Mini (48GB RAM)。軟體堆疊旨在實現快速部署與跨裝置存取：

  • 推理伺服器：oMLX，提供帶有內建 HuggingFace 瀏覽器與 KV cache 持久化至 SSD 的管理儀表板，從而減少代理工作流 (agentic workflows) 的重新計算時間。
  • 網路：Tailscale，建立一個私密的網狀網路 (tailnet)，將 Mac Mini 與 iPhone 及 MacBook 連接起來，而無需將連接埠暴露於公開網際網路。
  • 主要模型：
    • Qwen3.6-35B-A3B-OptiQ-4bit：用於複雜推理與深度任務。作為一個 MoE 模型，它總共有 35B 參數，但每個 token 的啟動參數僅為 3B。
    • Gemma-4-E4B-it-OptiQ-4bit：輕量化模型，用於例行格式化與簡單對話任務。
  • 用戶端介面：
    • Hermes：運行在 Mac Mini 上的代理後端，可透過 MacBook 上的桌面用戶端與 iOS 上的 Telegram 存取。
    • Apollo (iOS)：透過 oMLX 端點進行類似 Claude 的快速隨意查詢。
    • Raycast AI：整合至 macOS 中處理雜項任務。
    • Pi：作為專用的編碼代理。

本地模型的記憶體管理

有效的本地 LLM 部署取決於理解總參數與啟動參數之間的區別，特別是在混合專家模型 (MoE) 架構中。

密集模型 vs. MoE 記憶體占用

在密集模型中，每個 token 都會啟動所有參數，這意味著一個 4-bit 量化後的 27B 模型僅僅為了權重就需要大約 14GB 的 RAM。 相比之下，一個像 Qwen3.6-35B-A3B 的 MoE 模型擁有 35B 總參數，但每個 token 僅啟動 3B 參數。雖然所有 35B 參數都必須保留在統一記憶體中（在 4-bit 下約佔 20GB），但在推理期間的 GPU/媒體記憶體占用量顯著較低，類似於一個 6B 的密集模型。

硬體相容性檢查清單

為了確定模型是否能放入特定的 Apple Silicon 硬體中，建議進行以下計算：

  1. 量化檔案大小：4-bit 模型的大小大約等於參數數量以 GB 為單位（例如，35B $\approx$ 17-20GB）。
  2. OS 覆蓋開銷：扣除 6-8GB 給 macOS。
  3. 上下文窗口 (Context Window)：為 KV cache 分配 8-16GB 以支援長對話。
  4. 緩衝區：保留 10-15% 的記憶體緩衝，以防止系統切換至 SSD (swapping)，這會嚴重降低效能。

本地推理的策略優勢

從雲端 API 轉向本地運算可以解決多項營運與財務風險：

  • AI 主權與隱私：本地硬體消除了第三方數據洩露的風險，並防止政府強制要求的模型限制或 API 服務條款的突然變動。
  • 成本可預測性：本地推理取代了變動的每 token 計費方式，轉而使用固定的硬體購買與電力成本。
  • 效能：本地設置消除了網路往返時間，為日常任務提供更低的延遲。M4 Pro 的媒體引擎可為大多數提示詞提供近乎即時的響應。
  • 無速率限制：本地運算消除了付費 API 層級中常見的流量限制 (throttling)。

社群洞察與效能基準測試

雖然 M4 Pro 功能強大，但社群討論強調了關於效能與硬體限制的幾點細微差別。

效能數據

使用者回報在 M1 Max (32GB) 上使用 oMLX 的類似設置，並記錄了以下 token 生成 (TG) 與提示詞處理 (PP) 速度：

  • Qwen3.6-35B-A3B-OptiQ-4bit：PP 342.6 tok/s, TG 44.4 tok/s。
  • Qwen3.6-35B-A3B-mxfp4：PP 389.6 tok/s, TG 47.6 tok/s。
  • Qwen3.8-27B-4bit：PP 66.3 tok/s, TG 11.8 tok/s。

反對觀點與限制

社群成員針對嘗試此設置的人提出了幾項關鍵考量：

"運行一個大型模型在本地，關鍵在於它實際在記憶體中需要多少 RAM。這不完全正確。關鍵在於記憶體以及記憶體頻寬。你可以擁有 1TB 的記憶體，但如果你的記憶體頻寬很差，你的 tok/s 也會很慢。"

其他使用者指出，雖然本地模型對於 80% 的任務都非常出色，預填充延遲 (prefill latency) 在 Apple Silicon 上與專用 H100/B300 集群相比仍可能成為瓶頸。此外，有人質疑使用 Telegram 作為本地模型的用戶端介面所帶來的隱私效益，因為 Telegram bot 帳號並非端到端加密。

Sources

相關