如何在 MacBook Pro 上執行 GLM-5.3-Flash：2bit-Lite MLX 操作手冊

執行 GLM-5.3-Flash 於 MacBook Pro 上，所指的是一部 128 GB M4/M5 Max MacBook Pro，運行 2bit-lite 版本的 我們的 MLX 轉換，並調高 macOS 的 wired-memory 限制。如果您的 MacBook Pro 記憶體少於 128 GB——36 GB 的 M4 Pro、48 GB 的 M4 Max——這本操作手冊不適合您；請跳到最後一節，改為使用代管的 z-ai/glm-5.3-flash API。GLM-5.3-Flash（權重位於 zai-org/GLM-5.3-Flash）是 Z.ai 的 3200 億參數混合專家（Mixture-of-Experts）模型，每個 token 有 180 億個激活參數——於 2026 年 8 月 26 日發布，是首個原生多模態 GLM-5——即便是我們 MLX 移植的最小建置，也需要約 102 GB 的權重和約 112 GB 的記憶體。這就是整個市場的現實，我們不會粉飾。

這是第一方文件，不是發布稿：以下權重是 OrcaRouter 自己的構建（orcarouter/GLM-5.3-Flash-MLX，MIT），使用我們無需校準的 OrcaSAQ 量化方法製作。我們於 8 月 26 日發布，隔天公開修正方向，因為原本的量化範圍對大多數人來說並未讓 MacBook Pro 的使用變實用——一般 2-bit 版本仍需要約 160 GB，沒有任何筆電具備如此容量。8 月 27 日我們將最小的變體重建為2bit-lite，專門用於容納 128 GB 的 MacBook Pro，而這篇文章如實說明了你能得到什麼、代價又是什麼。每個標有現場記錄的數字，都是在我們的單一 H200 驗證運行中測量的；這裡沒有任何廠商基準測試。凡是我們沿用社群做法的地方——如 wired-memory 指令、mlx-vlm 版本控制——我們都會如此標示。

哪個版本適用於哪款 Mac（下載任何內容前請先閱讀）

儲存庫中的五個建置各對應一個最低 RAM 數值。在 MacBook Pro 上，「哪個建置」只有一個答案——高於2bit-lite的都是 Mac Studio 的討論：

• 6-bit——約296GB權重／約320GB記憶體／近乎無損。僅適用於配備512GB的Mac Studio。

• 4-bit — 約 204 GB / 約 224 GB / 我們建議的預設值。Mac Studio 256 GB。這就是 repo 根目錄所鏡像的內容。

• 3位元 — ~184 GB / ~200 GB。Mac Studio 256 GB。

• 2位元——約145 GB / 約160 GB。Mac Studio 192 GB。這是我們首日發布的最小版本，而這正是我們的失誤。

• 2bit-lite — 約 102 GB / 約 112 GB。唯一能裝進 128 GB 機器的版本——128 GB M4/M5 Max MacBook Pro、128 GB Mac Studio 或 Mac mini。任何 128 GB Apple Silicon 筆電（M3 Max 或更新機型）情況相同，只是速度較慢。

那個階梯中隱藏的陷阱：README 的預設下載指令會拉取 4-bit 版本（約 204 GB），這對 256 GB 的機器是正確的預設值，但在筆電上毫無用處。如果你在 MacBook Pro 上依照預設指令操作，最終會得到一個無法分配記憶體的模型。2bit-lite 路徑需要明確指定--include，如下所述。

在以上計算甚至還未適用之前，你也會撞上一個硬性上限。macOS 不允許單一程序佔用 128 GB Mac 的全部統一記憶體；預設可供 GPU 使用的上限約為 91–96 GB（這是社群逆向工程得出的結果，並在多篇大型模型 MLX 配置的文章中得到佐證）。這低於權重本身約 102 GB 的容量，所以即使 2bit-lite 也無法載入，除非你提高固定記憶體限制。這個步驟是必須的，這將在第 4 節中介紹。

安裝 mlx-vlm — 且僅安裝 mlx-vlm

GLM-5.3-Flash是一個視覺語言模型，因此它運行於mlx-vlm，而非mlx-lm。這是最常見的卡關原因，所以先說清楚：mlx-lm僅供純文字模型使用；若透過它執行多模態模型，會產生令人困惑的載入錯誤。請安裝 0.6.17 或以上版本的 VLM 套件：

pip install -U "mlx-vlm>=0.6.17"

版本鎖定並非裝飾。glm5_next—— 即 GLM-5.3-Flash 背後的混合稀疏加線性注意力架構 —— 直到模型發布當天（2026 年 8 月 26 日）才整合進 mlx-vlm，任何更舊的版本都無法識別該配置。架構之所以重要還有第二個原因：這是一個全新的拓撲結構，第一波移植存在實際的正確性錯誤，而流暢的輸出不會顯露這些問題。社群對早期 glm5_next MLX 路徑的執行期稽核發現並修復了其中四個問題——每個 FFN 區塊上未套用的 SwiGLU 截斷、流形約束的超連接張量被轉換為錯誤的 dtype（這會悄悄破壞注意力混合矩陣）、注意力正規化中的兩個 epsilon 不匹配，以及路由器 logits 使用 bf16 而參考實作使用 float32。修復之後，數值與參考實作吻合至約 1e-7。對你而言的重點是：保持 mlx-vlm 為最新版本，並對任何新架構移植的第一個版本抱持懷疑。

下載權重：排除旗標，以及你實際需要的包含項

儲存庫根目錄對應 4-bit 建置，而所有五個變體都以子資料夾的形式提供。預設指令會下載根目錄，並使用 --exclude，因此五個變體資料夾（合計約 800 GB）都不會一併下載：

hf download orcarouter/GLM-5.3-Flash-MLX --local-dir ./GLM-5.3-Flash-MLX --exclude "2bit-lite/*" "2-bit/*" "3-bit/*" "4-bit/*" "6-bit/*"

在 MacBook Pro 上，那個指令不適用於你——它會給你 4-bit 根目錄。對於 128 GB 的筆電，只擷取 2bit-lite 子資料夾：

使用 hf 下載 orcarouter/GLM-5.3-Flash-MLX，包含 "2bit-lite/*"，並將本機目錄設為 ./GLM-5.3-Flash-MLX

那就是約 102 GB 的下載，而且是自包含的——2bit-lite/ 資料夾自帶 config.json，所以你直接把生成器指向它即可。如果 hf 不在你的 PATH 中，請安裝它：pip install -U huggingface_hub。開始之前，請確認你有約 110 GB 的可用磁碟空間，而且你的 Mac 儲存空間不是只剩下最後 100 GB——MLX 會將權重以 memory-map 方式載入，所以 SSD 幾乎滿載時，這類設定容易在下載途中掛掉。

提高固定記憶體限制——每個人都會忘記的步驟

這是 128 GB MacBook Pro 上成敗的關鍵步驟，而且 README 卡片預設你已知道，沒有把指令明確寫出來。128 GB Mac 的 Metal 工作集上限預設約為 91–96 GB，低於 2bit-lite 權重約 102 GB 的需求——因此若未執行此步驟，模型將無法配置記憶體，載入也就會失敗。社群標準的解決方法是透過 sysctl 提高 GPU 鎖定記憶體的上限（以 MB 為單位）：

以 sudo 權限執行 sysctl，將 iogpu.wired_limit_mb 設定為 114688

這設定了約 112 GB 的上限，留下約 14 GB 作為作業系統保留空間。在 128 GB 機器上，社群實際使用的數值範圍約從 114688（112 GB）到 122880（120 GB）；不要調到最大值——macOS 需要預留餘裕，否則在記憶體壓力下會出現 window-server 卡頓與系統延遲。設定後，載入模型並觀察「活動監視器」：如果記憶體壓力轉黃，就把數值調低。

以下兩點實務建議皆來自社群經驗，而非我們的實地筆記。首先，sysctl 會在重新開機時重設，且僅對您設定它的終端機工作階段生效，因此請規劃重新執行（或透過 LaunchAgent 將其腳本化）——重新開機後忘了執行，正是經典的「昨天還能用」故障。其次，MLX 也提供了一個處理程序內的調整選項，mlx.core.metal.set_wired_limit(bytes)，適用於 macOS 15.0 及更新版本；它必須保持在 sysctl 上限之下，而且如果您是在 Notebook 中撰寫腳本，這會是較具可攜性的選項。無論您使用哪一種，效果都相同：沒有它，這裡的一切都無法執行。

執行它：文字、影像，以及 Python API

權重就位、限制提高後，生成只需一條指令。文字：

python -m mlx_vlm.generate --model ./GLM-5.3-Flash-MLX/2bit-lite --prompt "用一句話解釋量子糾纏。" --max-tokens 256

圖像輸入的運作方式相同，使用--image旗標 — 這正是多模態模型在筆電上證明其價值之處，因為在 OrcaSAQ 佈局中，視覺塔保持較高的精度：

python -m mlx_vlm.generate --model ./GLM-5.3-Flash-MLX/2bit-lite --image photo.jpg --prompt "描述這張圖片。" --max-tokens 256

對於腳本，Python API 的形態與 mlx-vlm 使用者所知相同：

from mlx_vlm import load, generate from mlx_vlm.prompt_utils import apply_chat_template model, processor = load("./GLM-5.3-Flash-MLX/2bit-lite") prompt = apply_chat_template(processor, model.config, "描述這張圖片。", num_images=1) print(generate(model, processor, prompt, ["photo.jpg"], max_tokens=256, verbose=True))

保持--max-tokens保守。在我們的 H200 現場筆記執行中，2bit-lite 大約維持 10 tok/s，因此 1,024 個 token 的回答已經是兩分鐘的等待——而長輸出正是 KV 預算和品質崩潰影響最明顯的地方（見下文）。在筆電上，除非有量測數據，否則你應該預期它感覺更慢，而不是更快。

您實際獲得的品質（測量階梯）

這裡是劇本中誠實的部分，我們不會粉飾它。OrcaSAQ 能優雅地退化到 3-bit，之後成本就會迅速攀升。相對於 FP8 參考（困惑度 2.7797）：

• 6位元 — 困惑度 2.7864（+0.24%），top-1 token 一致率 97.76%。近乎無損，如廣告所述。

• 4-bit — 困惑度 2.8620（+2.96%），Top-1 96.13%。這是建議的預設值。

• 3-bit — 困惑度 3.0566（+9.96%），top-1 92.06%。激進但可用。

• 2-bit — 困惑度 4.3622（+56.9%），top-1 86.56%。這是實實在在的代價。

• 2bit-lite — 困惑度 6.7018（+141%），top-1 77.19%。最小的版本，也是唯一一個 MacBook Pro 能容納的版本。

這些是來自我們自有轉換管線的實測數據。2bit-lite 的困惑度退化達 141%，top-1 token 一致性低於 78%——你正在運行一個明顯降級的模型，而以下這些失敗模式正是這種降級在實際使用中的樣貌。它是個出色的示範，也是個合理的短篇助理；但它無法取代全精度模型。

關於速度，我們同樣對您誠實以告。已發布的實測紀錄為 H200：約 10 tok/s，多輪對話穩定，日常問答與短篇文本皆可流暢處理。我們尚無 2bit-lite 在 MacBook Pro 上的實測數據，也不打算憑空捏造——Apple Silicon 在此的吞吐量取決於記憶體頻寬、散熱情況，以及 MLX 核心對混合注意力機制的支援涵蓋範圍，而這些我們都尚未針對此筆電上的此版本進行實測。我們能提供給您最接近的已發布 Apple Silicon 數據點，是另一個獨立測得的約 450 tok/s：在 512 GB Mac 上、使用不同 MLX 執行環境的 4-bit GLM-5.3-Flash 版本——這是不同的版本、不同的精度，而且還是桌上型機器，因此請勿將其視為您的數據。請以慢速為預期做規劃；若實際並非如此，就當作意外的驚喜吧。

KV cache 與長上下文：注意餘裕空間

GLM-5.3-Flash宣稱擁有 100 萬 token 的上下文視窗。在這種硬體上，這個數字無關緊要；任何佯裝它重要的教學，反而是在誤導你。實戰筆記只有一句話：給執行環境足夠的 KV 預算，以應付你的目標長度。在單張 H200 上，2bit-lite 在載入權重後約留下 39 GB 的 KV 快取空間。在 128 GB MacBook Pro 上，計算就更嚴苛了：約 112 GB 的上限扣除約 102 GB 的權重後，在 macOS 本身的運作集之前，僅剩約 26 GB——而這個模型的混合線性注意力層，使其 KV 佔用量相對於同尺寸的密集模型來得小，但仍會隨上下文長度線性成長。

來自更廣泛社群的服務端指導印證了這點：一個在 8K 上下文下能正常載入的配置，在 128K 時可能會記憶體不足。在筆電上，保持上下文簡短——幾千個 token 的問答或單張圖片——不要試圖餵給它一本書。當工作負載真正需要長上下文時，你就進入了本文的最後一節。

在 2bit-lite 下，長程式碼生成並不可靠（請讀兩遍）

這是教學指南中不可或缺的一節——若指南隱藏其失敗模式，缺了此節便一文不值——因此它自有標題。H200 的實地筆記非常明確：日常問答與短文輸出表現良好，但在這種精度下，長程式碼生成並不可靠。我們在驗證執行中重現了三種失敗模式：

• 重複迴圈 — 模型開始重複相同的行或區塊，而非持續推進，通常在數百個 token 後出現。

• 缺少膠水程式碼 — 匯入、接線與錯誤處理被默默丟棄。生成的函式單獨看起來正確，但無法執行，因為周圍的支撐結構根本不存在。

• 反覆改寫——不是做最小幅度的編輯，而是改寫檔案的大段內容，且連續回合的輸出彼此不一致。

這些問題在 2bit-lite 上可以重現，而它們正是 77% top-1 一致性所預測的內容。那些保留筆電版本的實務工作者真正在做的是：

• 將其用於解釋、摘要、問答和影像理解——這是它真正擅長的短篇任務。

• 如果你必須要求程式碼，請要求一次一個小函式，並附上明確的簽名，在繼續之前逐一驗證。不要將整個檔案交給它，然後要求某個功能。

• 對於任何較長的工作——完整的模組、重構、長時間的代理程式工作階段——請路由到完整精度的 API。這不是變通做法；這是正確的架構，而這是最後一節。

完全不該這樣做時：請改為呼叫 z-ai/glm-5.3-flash

誠實的決策規則是：在 128 GB M4/M5 Max MacBook Pro 上執行 2bit-lite，只有當你確實想要一個 320B 多模態模型在你能攜帶的筆電上 — 離線問答、私人文件、影像理解，資料完全不離開機器。其他一切都選擇 API：

• 任何 128 GB 以下的 MacBook Pro — 沒有適合您的版本。請勿嘗試載入；請使用 API。

• 長程式碼生成或長上下文推理 — 2bit-lite 正是在這方面必然失敗。請使用 API。

• 品質敏感型工作 — 77.19% 的 top-1 一致率與 +141% 的困惑度是實質的下降，而非四捨五入的誤差。請使用 API。

• 保證的吞吐量或可預測的延遲 — 目前尚無已測量的筆電數據，現場記錄為 10 tok/s。請使用 API。

託管模型是z-ai/glm-5.3-flash，在 OrcaRouter 上以全精度提供服務，採用 Z.ai 目前定價——截至撰寫本文時，每百萬個輸入 token 為 $0.07，每百萬個輸出 token 為 $0.25（上市期間定價；Z.ai 公布的定價表為 $0.15 / $0.50）。這是供應商回報的價格，以 0% 加價直接轉傳，因此 Z.ai 若降價，我們這邊當天就會反映。您只需要一個 API 金鑰，就能使用我們所路由的其他 200+ 個模型；自動故障轉移（automatic failover）意味著，用這個新模型做實驗，不會讓您的正式環境路徑押注在單一供應商上。在下載 102 GB 並等待第一次冷啟動生成（cold generation）結束所需的時間內，API 早已回答了整整一週的問題量——而且是以全精度回答。

當原因是本地（隱私、離線工作、無速率限制、可靠電池供電運行的示範）時，採用本地推論是值得的。以成本或品質來算，不值得為了任何其他理由採用它，而且在記憶體低於 128 GB 的機器上，一點都不值得。

常見問題

配備 64 GB 或 96 GB 記憶體的 Mac 能否在本機執行 GLM-5.3-Flash？不行。最小的建置版本 2bit-lite 在扣除 macOS 系統開銷後，至少需要約 112 GB，而且即使是 128 GB 的機器也必須提高鎖定記憶體上限才能載入。如果你的 Mac 記憶體低於 128 GB，本機路徑並不存在；請改為透過 API 使用 z-ai/glm-5.3-flash。

我安裝了 mlx-vlm，但模型無法載入 — 問題出在哪裡？ 兩個常見原因，依序為：版本低於 0.6.17（早於 glm5_next 支援，無法辨識該架構）；以及未提高 wired-memory 限制，因為在 128 GB Mac 上，預設約 91–96 GB 的 Metal 上限無法配置約 102 GB 的建置。同時修正兩者（升級套件、執行 sysctl）即可正常載入。

本地的 2bit-lite 建置是否與 z-ai/glm-5.3-flash API 是相同的模型？底層同樣是 GLM-5.3-Flash 權重，但品質並不相同。2bit-lite 是 2-bit 量化，與 FP8 參考版本相比，top-1 token 一致率為 77.19%，且長程式碼生成不可靠。API 提供的是完整精度。兩者僅在短篇幅、對品質容忍度較高的工作上可互換使用。

30秒版本

一台機器、一次建置、一個必設的 sysctl。如果你有一台 128 GB 的 M4/M5 Max MacBook Pro：安裝 mlx-vlm>=0.6.17，只下載 2bit-lite/（約 102 GB），然後用以下指令提高 wired-memory 上限：sudo sysctl iogpu.wired_limit_mb=114688，然後執行 mlx_vlm.generate — 適用於問答、短文和圖片。請接受：在此精度下，長程式碼生成並不可靠；目前還沒有實測的筆電吞吐量；而且 128 GB 的 Mac 是下限，不是標準。如果上述任何一項讓你無法接受——或者你的 Mac 低於 128 GB——同一個模型的全精度版本只需一次 API 呼叫即可取得，服務位於 z-ai/glm-5.3-flash。

不是用 128 GB 的 Mac？z-ai/glm-5.3-flash 在 OrcaRouter 上以全精度提供相同模型——只需一個 API 金鑰，供應商定價以 0% 加成直接轉嫁，且無需下載 102 GB。