GLM-5.3-Flash 的 VRAM 需求：運行 320B MoE 需要多少記憶體

GLM-5.3-Flash 無法在任何消費級 GPU 上運行。最小可用版本 2bit-lite 需要約 102 GB 的權重和 112 GB 的記憶體。128 GB 的 Mac 是入門門檻；單張 H200 可容納 2bit-lite，且剩餘約 39 GB 空間；其他所有人應使用託管 API：z-ai/glm-5.3-flash。

這就是一口氣講完的完整答案，而且在這裡值得直白地說：沒有任何消費級硬體配置可以運行這個模型。Z.ai 的 320B 參數視覺語言混合專家模型，於 2026 年 8 月 26 日發布，在任何量化等級下都需要伺服器級記憶體。「18B 啟用」這個數字描述的是每個 token 的運算量，而非常駐記憶體——全部 320B 的權重都會保持載入。實際可行的本機目標是大型統一記憶體 Mac、多 GPU 伺服器，以及單張 141 GB 的 H200。如果你不擁有其中任何一種，下面的數字不是購物清單；而是改用 API 呼叫該模型的原因。

在列出數據之前，先說明一個框架重點：本文中的記憶體數字是社群調查結果，並非廠商指引。Z.ai 發布模型權重和 API 規格，但並未發布本機推論（local-inference）所需的記憶體需求。各量化等級的表格來自 Hugging Face 上的 orcarouter/GLM-5.3-Flash-MLX 模型卡，這是由社群團體維護的開放權重 MLX 量化版本；部署數字則來自實際載入過該模型的實務工作者。若某項數字是由廠商提供——例如定價，以及該架構在 KV-cache 效率上的宣稱——我們會明確標示。

簡短回答：什麼適合你現有的

從你實際擁有的東西開始，因為量化階梯只有針對目標機器才有意義：

• 消費級 GPU（RTX 4090、RTX 5090 及更低階的型號）——不行。沒有任何一張消費級顯示卡擁有足夠的 VRAM：最小的建置光是權重就約需 102 GB，大約相當於五張 RTX 5090。系統 RAM 無法改變這一點，因為權重必須常駐於裝置上。

• 128 GB Mac（M4 或 M5 Max）——2bit-lite 建置（約 102 GB 權重 / 112 GB 最小 RAM），且必須在提高固定記憶體限制之後才行。詳見下文。這是唯一能容納此模型的消費級機器。

• 192 GB 和 256 GB Mac Studio — 3-bit（約 184 / 200 GB）和 2-bit（約 145 / 160 GB）變得可達成；4-bit 需要約 224 GB，只有 256 GB 級別接近。

• 單一 H200（141 GB VRAM）— 2bit-lite 可容納，KV 快取約剩 39 GB，這意味著僅限短上下文。

• 多 GPU 伺服器 — 包括 4-bit、6-bit 以及約 328 GB 的 FP8 參考建置在內的一切。

• 其他所有人 — 託管 API，z-ai/glm-5.3-flash。這不是安慰獎；這才是該模型實際使用上快速且便宜的地方，且已涵蓋於本頁底部。

兩個數字，而非一個：權重 vs 總記憶體

模型卡上的每次量化都有兩欄——權重大小與最低記憶體——而兩者之間的差距正是大多數文章略過不提的部分。權重欄指的是模型檔案：每個參數以該精度常駐於記憶體中。最低記憶體欄則代表機器在執行時期必須容納的內容：權重加上 KV 快取、激活值，以及隨上下文長度成長的緩衝區。

「18B 活躍參數」這個數字正是容易誤導人的地方。GLM-5.3-Flash 是一個總參數量 320B／活躍參數量 18B 的 MoE 模型：每個 token 只有大約 18B 的參數會參與運算。這是節省運算量，而不是節省記憶體。無論哪些專家被觸發，全部 320B 的權重都依然駐留在記憶體中，因為路由器必須在看到 token 之後，才知道自己需要哪些專家。MoE 換來的是速度，而不是佔用的記憶體空間——關於這點，模型自己的規格卡就以身作則說明了：它同時列出 320B 的總參數量與 18B 的活躍參數量。

所以當某個建置寫著「~204 GB 權重 / 224 GB 最小記憶體」時，額外的 ~20 GB 是運行時開銷——KV 快取、活化值、上下文緩衝區。把上下文長度拉高，這個差異就會變大。要衡量一台機器是否符合需求，看的是「最小記憶體」那一欄，而不是「權重」那一欄。

該模型本身——架構、授權，以及 Z.ai 自身的定位——記錄在供應商的官方模型卡上，如上所示。本機記憶體並未涵蓋於該處；這正是此頁面存在的原因。以下數字來自開放權重的社群 MLX 移植版本。

量化階梯

從業者目前實際載入的是 {{1}}orcarouter/GLM-5.3-Flash-MLX{{/1}} 卡片上的表格。它列出了 {{2}}五個量化版本加上 FP8 參考版本{{/2}}，並標明各自的權重大小與最低 RAM 需求：

• FP8 參考 — 約 328 GB 權重。這是開放權重發布時的未量化參考基準。

• 6-bit — 約 296 GB 權重 / 320 GB 最低記憶體。接近無損；品質最佳的建置。

• 4-bit — ~204 GB / 224 GB。建議的日常預設值。

• 3-bit — ~184 GB / 200 GB。激進但可用。

• 2-bit — 約 145 GB / 160 GB。盡力而為。

• 2bit-lite — ~102 GB / 112 GB。最小的版本；唯一能裝進 128 GB Mac 或單張 H200 的版本。

品質會隨著位元數下降而劣化，而模型卡對此做了量化。相對於 FP8 基準，困惑度（perplexity）在 6-bit 時退化 +0.24%、4-bit 時 +2.96%、3-bit 時 +9.96%、2-bit 時 +56.9%、2bit-lite 時 +141%（困惑度數據取自同一模型卡）。模型卡自身的場域指引：6-bit 用於接近無損、4-bit 作為日常預設、3-bit 與 2-bit 用於記憶體受限時、2bit-lite 僅在其他選項都無法容納時使用——而且在 2bit-lite 下，長程式碼生成並不可靠。這最後一項警告對 320B 推理模型至關重要：正是 2bit-lite 讓你能以 128 GB 的 Mac 運行，而品質代價恰好落在程式設計工作最痛的地方。

那個階梯中的兩個數字值得更仔細的觀察，因為它們決定了整個硬體問題。

為什麼會有 2bit-lite

2bit-lite 並不是額外的品質等級——它是為了一個理由而存在的尺寸等級：常規的 2-bit 放不下。約 102 GB 的權重使其成為唯一能塞進 128 GB Mac 約 112 GB 可用記憶體的版本，也是唯一能裝進單張 H200 的 141 GB 並為 KV cache 留出空間的版本。模型卡上也說得很明白：常規 2-bit 裝不進 128 GB Mac；2bit-lite 可以，只是調高了 wired 記憶體上限。在 H200 上，它「還剩約 39 GB 給 KV cache」（模型卡的說法）。這 39 GB 是模型載入後一切運作的完整工作預算——這就帶到了上下文的話題。

KV 快取在長上下文中的成本

GLM-5.3-Flash 擁有 1M token 的上下文視窗，而長上下文正是本機記憶體方案的致命傷。該模型的混合式稀疏加線性注意力機制——採用索引池（index-pool）機制的 NoPE-MLA——確實高效：Z.ai 報告指出，與其自家 GLM-5.3 相比，可將注意力運算量降低 3.01 倍，KV 快取大小縮減 4.44 倍（廠商公布的數據）。但「比 GLM-5.3 小 4.44 倍」在逼近完整 1M 上下文時，仍會留下以數十 GiB 計的快取。

我們所有的最佳公開數字來自一個社群部署，該部署在四個 DGX Spark 節點上執行模型：每個 rank 有 16 GiB 的 KV cache——四個節點總共約 64 GiB——用來容納完整的 1M token 上下文，並把它設計成可支援幾個並行的全上下文請求。這在未計入任何權重之前，就已經超過大多數單機的整個記憶體預算。在單一 H200 上，這道算術正是本頁的重點：2bit-lite 在權重之外留下約 39 GB 給所有東西——短暫聊天綽綽有餘，但當上下文朝向 100K token 攀升時，幾分鐘內就會耗盡。

實用規則：min-RAM 欄位假設的是合理的上下文長度。如果你的工作負載需要處理長文件、agent 迴圈，或儲存庫規模的程式碼，請在基礎上額外預留 KV-cache 記憶體——而若需求接近 100 萬個 token，就別再自行計算了，直接使用 API。這些容量估算觀察來自社群發現；目前沒有任何廠商針對 KV 預算提供官方指引。

macOS 的固定記憶體上限：為何配備 128 GB 的 Mac 仍無法載入

實務工作者最常回報的失敗不是「記憶體不足」，而是一台 128 GB 的 Mac 搭配約 102 GB 的模型卻拒絕載入。原因在於 macOS 的「固定記憶體」（wired memory）限制。在 Apple Silicon 上，GPU 無法定址全部的统一記憶體：Metal 暴露的「建議最大工作集」（recommended max working set）約為實體 RAM 的三分之二，超過此上限的配置即使機器仍有可用記憶體也會失敗。

因此，一台 128 GB Mac 的預設 Metal 預算位於 80–90 GB 範圍內——低於 2bit-lite 版本所需（最低 112 GB RAM，常駐模型約 102 GB）。載入失敗是因為 Metal 預算，而不是 RAM 容量。我們找到的每份實務報告中的修復方法都相同：使用 sudo sysctl iogpu.wired_limit_mb=… 提高固定記憶體上限（wired limit），設定一個高於模型總佔用空間（以 MB 計）的值，並預期它會在重新開機後重設。有些社群指南也會透過 Python 的 mlx.metal.set_wired_limit() 設定固定記憶體上限，如此一來模型權重會被固定，macOS 就不再壓縮閒置的 Metal 頁面。

還有一個複雜之處：執行環境的行為不盡相同。MLX 會強制執行 Metal 預算，一旦超出便會直接失敗；而基於 llama.cpp 的執行環境（GGUF 路徑）通常不會強制執行此限制，而是讓 macOS 改用交換（swap）機制。這就是為什麼同一個模型在某個執行環境中會拒絕載入，在另一個執行環境中卻能「載入」——也是為什麼被交換的模型會慢到幾乎無法使用。這些是社群對 macOS 行為的發現，並非 Apple 的官方指引。

託管替代方案：z-ai/glm-5.3-flash

對於上述數字排除的所有人——也就是大多數人——Z.ai 本身以 z-ai/glm-5.3-flash 提供模型，而這正是名稱中「Flash」真正展現之處。Z.ai 的牌價為每百萬輸入 token 0.15 美元、每百萬快取輸入 token 0.03 美元、每百萬輸出 token 0.50 美元；上市促銷活動持續至 2026 年 9 月 9 日，價格為 0.075 / 0.015 / 0.25 美元（供應商回報的定價，截至撰寫時為準）。快取輸入的價格僅為全新輸入的五分之一，這是最大的成本槓桿：任何具有可重複使用前綴的工作負載——系統提示詞、工具定義、長時間共用的文件——都應該用到快取讀取定價。

記憶體的計算應納入決策考量。自行部署 320B 模型，無論其閒置或滿載，都需為其分配 112–320 GB 的記憶體。託管端點則可將所有這些需求移出你的機器；而且在上市促銷價格下，該模型每 token 的成本低於許多僅有其十分之一大小的模型——這正是 18B 啟用參數 MoE 的意義所在。

這也是設置路由點的自然位置。透過 OrcaRouter，z-ai/glm-5.3-flash 是單一 API 背後 200+ 模型之一，價格按供應商列表價格，零加價——因此上市促銷和任何未來降價，都在宣布當天立即生效。自動故障轉移意味著，一個才推出三天、服務路徑不穩定的模型，不會成為你生產環境的賭注：如果供應商出錯或飽和，請求會轉到健康的供應商，而不是失敗。安全地嘗試未經驗證的模型，正是路由器的用途。

常見問題

我可以在RTX 5090上運行GLM-5.3-Flash嗎？

不。最小的構建僅權重就約有 102 GB，而 RTX 5090 只有 32 GB 的 VRAM。沒有任何消費級 GPU 能接近這個需求；該模型需要統一記憶體的 Mac、單張 H200，或多 GPU 伺服器。

18B 活躍參數是否意味著 GLM-5.3-Flash 可以在消費級硬體上運行？

不。18B 活躍參數是指每個 token 的計算量。全部 320B 參數仍須常駐於記憶體中，因為路由器在實際看到 token 之前，無法得知該 token 需要哪些專家。MoE 節省的是計算量，而非記憶體。

嘗試 GLM-5.3-Flash 最便宜的方法是什麼？

託管 API，z-ai/glm-5.3-flash。以發布促銷價計算，每百萬輸入 tokens 費用為 $0.075，而快取輸入 tokens 費用為 $0.015。自行託管最小建置版本意味著需要為其分配約 112 GB 的 RAM，這只有在您已經擁有該硬體的情況下才合理。

誠實的總結：GLM-5.3-Flash 在每一種建置中都是伺服器等級的模型。128 GB 的 Mac 只能使用唯一符合的建置——2bit-lite，具有調高的記憶體限制、較短的上下文，以及在長程式碼上有明確記載的品質損失。單張 H200 則可執行相同建置，並擁有約 39 GB 的 KV 餘裕。伺服器硬體才有真正的完整光譜，從預設的 4-bit 一路到近乎無損的 6-bit。而對其他所有人——也就是大多數讀者——託管的 z-ai/glm-5.3-flash 端點才是正確答案，上述數字是原因，而不是採購清單。若想在 MacBook Pro 上逐步安裝，我們的 MacBook 安裝指南涵蓋了完整的端到端流程；至於量化建置在品質上的比較以及何時該選擇哪一種，MLX 建置指南有詳細說明；發布報導則包含了推出背景與基準測試宣稱。