Apple 開源 MLX 更新：Mac 桌面跑 816B 模型

Apple 於二零二六年十月十六日為開源框架 MLX 發布更新，透過 macOS 26.2 的 Thunderbolt 5 RDMA 驅動與新的 jaccl 通訊後端，讓多部 Mac Studio 能以管線或張量平行方式共同推論。官方測試顯示，四部 M5 Ultra 串聯後可讓 816B 參數的 Muse Spark Open 達到每秒 36.73 代幣，單機 M5 Ultra 的首字延遲亦比上一代 M3 Ultra 快最多 4.6 倍。本文整理這次更新的技術內容、基準數據與實際部署步驟，供評估本地推論的團隊參考。

MLX 這次更新了什麼？

MLX 是 Apple 的開源陣列框架，這次加入 Thunderbolt 5 的 RDMA 通訊支援與 jaccl 後端，讓多部 Mac 能共同推論超大模型。

MLX 由 Apple 的機器學習研究團隊維護，定位是讓研究人員與開發者在自己持有的 Apple 晶片硬件上，執行最新的模型與方法，而無須把資料送往外部服務。此次更新的核心並非單一模型，而是三項底層能力的組合：對 M5 系列 GPU 神經加速器的軟件支援、以 Thunderbolt 5 為基礎的低延遲機間通訊，以及對混合專家等熱門架構的高效實作。

官方說明，macOS 26.2 引入 Thunderbolt 5 的 RDMA 驅動，MLX 由 v0.30.1 起在此之上提供新的通訊集合操作，代號 jaccl。這組能力讓分散式推論從資料中心規格的功能，變成一般工作室可以實際架設的方案。

單機層面的改善同樣明顯。M5 Ultra 的 GPU 神經加速器支援專用的矩陣乘法運算，直接反映在首字延遲上；統一記憶體頻寬亦由 M3 Ultra 的每秒 819GB 提升至每秒 1.2TB。兩者分別對應運算密集與頻寬密集的兩個推論階段，是這次效能數字的來源。

為什麼要在本機執行大型語言模型？

本機推論讓資料留在自有硬件，適合處理敏感內容；同時免除按用量計費的服務成本，並在無網絡環境維持可用，代價是硬件前期投入與維護心力。

把模型放在自己的機器上執行，最直接的好處是資料邊界清楚。研究資料、內部程式碼與客戶文件不需離開本地環境，對受監管行業或涉及未公開研究的團隊而言，這往往比效能更重要。

成本結構亦不同。雲端服務按代幣計費，用量難以預測；自建方案則是一次性硬件支出加上電力與維護。Apple 在文章中特別比較功耗，指出 M3 Ultra 的 Mac Studio 峰值耗電約 200W，M5 Ultra 約 300W，相當於一部家用烤麵包機的水平，因此可安放於任何家居或辦公室環境，不需為機房條件另作安排。

代理式工作流程是另一個推動因素。代理程式經常需要極長上下文與連續多步的工具呼叫，若每次請求都送往外部服務，延遲與費用會隨步數放大。本地伺服器可把這類重複而瑣碎的推論留在區網之內。

多部 Mac Studio 如何分擔同一個模型？

管線平行按層切分模型，前段機器算完再把中間結果傳給後段；張量平行則按層寬切分，每部機器各持有部分參數并行計算，通訊量較大但擴展性更高。

當模型體積超出單機記憶體，就需要把權重分散。官方以 Muse Spark Open 為例，該模型在原生 BF16 精度下需要超過 1.6TB 記憶體存放參數，即使轉為 4 位元 NVFP4 量化，權重仍約佔 493GB，加上推論時的中間運算，單機無法容納。

管線平行把模型按深度切開，第一部 Mac Studio 執行前半的層，再把輸出交給第二部執行後半。由於層仍是依序計算，解碼速度與單機相近，只有中間結果需要交換，通訊開銷低。在六萬五千餘代幣的長上下文下，這種做法把前綴處理分段流水線化，官方量測可較單機快約 1.8 倍。

張量平行則按寬度切分，每部機器持有每一層的一部分，單層運算本身被并行化，因此速度提升更明顯。代價是實作複雜度高，且長上下文的前綴階段通訊量較大；官方指出在機器數量增加後，這種做法的效益才會充分顯現。兩部 Mac Studio 之間以兩條 Thunderbolt 連接線相連，以加倍鏈路頻寬。

官方公布的效能表現如何？

四部 M5 Ultra 以張量平行執行時，816B 的 Muse Spark Open 達每秒 36.73 代幣，27B 的 Qwen 3.8 達 50.89 代幣。

官方以 mlx_lm.benchmark 在兩代 Mac Studio 上實測三款模型，量度首字延遲、生成速度與峰值功耗三項指標。Muse Spark Open 為 816B 總參數、42B 啟用參數的混合專家模型，Mistral Medium 3.5 為 128B，Qwen 3.8 為 27B。

首字延遲屬運算密集階段，最能反映神經加速器的作用。下表列出六萬五千餘代幣上下文下的量測值，單位為秒。

生成速度屬頻寬密集階段，數值以每秒代幣計，數值越高越理想。

值得留意的是，兩部 M5 Ultra 以管線方式執行 128B 模型時，生成速度與單機相同，反映層仍是依序計算的特性；只有增加機器並改用張量平行，才會在吞吐量上帶來明顯增益。至於 Muse Spark Open 的生成速度，官方指出已明顯高於一般人類閱讀速度。

如何在 Mac 上部署本地代理工作流程？

以 mlx_lm.server 啟動本地模型伺服器，需要跨機時加上 mlx.launch 與 jaccl 後端，再讓代理工具指向本機端點即可。

部署的第一步是啟動模型伺服器。單機情境下，以 mlx_lm.server 指定模型與通訊埠即可；需要跨機推論時，則以 mlx.launch 搭配 hostfile 與 jaccl 後端啟動，並可加入實驗性的快速同步環境變數以降低 CPU 與 GPU 之間的協調開銷。

伺服器就緒後，代理工具只需指向本機端點。官方示範以 OpenCode 連接位於 127.0.0.1:8080 的服務，透過相容的 API 介面把本地模型設為預設供應商，如此便能保留既有工具的介面，同時把推論完全留在自有硬件。

這種安排對需要長上下文的代理式編程尤其合適，因為工具鏈不必改動，只需更換模型來源。官方亦提到，隨着 Mac 上的代理應用逐漸普及，把推論伺服器本地化已成為可直接採用的做法。

這套方案有哪些限制？

門檻在於硬件與工程成本：816B 級模型至少需要兩部高階 Mac Studio，跨機連線與後端參數需自行調校，且量化會犧牲部分精度，功耗與散熱亦須納入考量。

硬件規模是最現實的門檻。官方示範以四部 M5 Ultra 執行最大模型，兩部機器只是起點；記憶體較小的機型雖可應付 27B 與 128B 級模型，但無法完整承載 816B 級權重。

工程複雜度同樣不容忽視。張量平行需要每層都正確切分，跨機通訊依賴 Thunderbolt 網狀連線，後端參數與同步設定都需逐項驗證；官方亦以實驗性標記描述部分加速選項，意味着穩定性仍待社群累積經驗。

量化則牽涉取捨。把權重壓縮至 4 位元可讓原本無法容納的模型得以運行，但精度必然受影響，是否可接受取決於任務性質。至於電力與散熱，雖然官方強調單機峰值耗電僅相當於家電水平，多機同時滿載時仍需為工作空間的供電與溫度作準備。

出處連結有哪些？

本文資訊整理自 Apple 機器學習研究團隊於二零二六年十月十六日發布的 MLX 分散式推論技術文章，讀者可經下列連結查閱完整基準與指令說明。

官方文章：https://machinelearning.apple.com/research/mlx-distributed-inference MLX 開源專案：https://github.com/ml-explore/mlx

總結：這項更新適合哪些團隊？

需要資料留在本地、同時要執行前沿級大模型的團隊最具價值；僅偶爾使用小型模型，或無意投入多機調校心力的使用者，現階段改用雲端服務更合乎效益。

這次更新的意義，在於把分散式推論從資料中心的專利，下放到可負擔的桌面硬件。對已有數部高階 Mac、且必須維持資料主權的實驗室或工程團隊而言，以管線與張量平行換取超大模型的本地執行能力，是一條具體可行的路徑。

選擇時可依模型規模分層判斷。27B 與 128B 級模型在單機 M5 Ultra 上已有實用速度，投入門檻低；816B 級模型則需要多機配置與調校，適合有明確長期需求者。至於一般開發者，若只是偶爾呼叫模型，雲端服務在成本與維護上仍較簡單，本地推論的價值主要集中在隱私、可預期成本與離線可用三項。