AIREITER想知道 GLM-5.3 能不能直接跑在桌機 GPU 上？答案是否定的。線上旗艦 checkpoint 所需記憶體屬於伺服器等級；即使換成 GLM-5.3-Flash，門檻雖然降低，仍是一個需要多張 GPU 的大型模型。能把量化 checkpoint 載入，不代表它足以作為反應流暢的程式設計 agent 服務。
先看結論：GLM-5.3 要多少硬體
完整 GLM-5.3 的官方文件明確列出 8-GPU FP8 拓撲；若要實現完整的 100 萬 token context，文件指定的是 8× B200。即使稀疏 MoE 路由每個 token 只會啟用部分參數，24 GB、64 GB、128 GB 或 192 GB 的單機記憶體規模，仍不適合作為完整模型的實際部署目標。
| 目標 | 公開依據 | 證據類型 | 實務建議 |
|---|---|---|---|
| GLM-5.3 原生 FP8 | 官方 vLLM recipe 指定 8× H200 或 H20 | 官方拓撲 | 適合伺服器等級或專業工作站部署。 |
| GLM-5.3 BF16 | 另有 BF16 checkpoint；vLLM recipe 說明採多節點 serving | 官方部署說明 | 僅適合評測或高階正式環境。 |
| GLM-5.3 NVFP4 | 官方 vLLM recipe 列出 Inferact/GLM-5.3-NVFP4，這是約 465 GB 的 Blackwell checkpoint | 官方 recipe 列出的社群 checkpoint | 限 Blackwell 的實驗或服務路線。 |
| GLM-5.3 量化版 | 一份社群 2-bit GGUF 報告使用約 281 GB 的檔案 | 社群封裝，非 Z.ai 官方容量資料 | 可做 offload 實驗，但不是一般桌機安裝方案。 |
| GLM-5.3-Flash | 已驗證的設定採用 2× RTX PRO 6000 Blackwell 96GB，搭配 175.6 GB、4-bpw checkpoint | 社群驗證 | 較務實的本機 GLM 選項，但依然需要多張 GPU。 |
線上的 Hugging Face model card 顯示模型總參數為 753,329,940,480，其中 751,226,191,872 個為 FP8 參數，safetensors 檔案總容量為 755,643,409,571 bytes。vLLM recipe 則將模型概略寫為約 743B 總參數、39B 活躍參數。兩者的四捨五入方式略有差異，但不會改變硬體需求的結論。
只算權重，記憶體就要多少？
以下為純算術估計，尚未計入 KV cache、activation、runtime buffer 與 allocator overhead。FP8 與 BF16 以線上旗艦模型約 753B 參數的規模推算；NVFP4 與 2-bit 則採特定實作的數字。
| 表示格式 | 原始權重記憶體約需 | 實務含義 |
|---|---|---|
| FP8 | ~753 GB | 對應原生 FP8、8-GPU 等級的部署規劃。 |
| BF16 | ~1.5 TB | 尚未加入 serving overhead，就已需要多節點等級的記憶體。 |
| NVFP4 | 官方列出的社群 checkpoint 約 ~465 GB | 官方 recipe 中的 Blackwell 專用路徑；並非預設 Z.ai checkpoint。 |
| 2-bit | 社群版本仍有數百 GB | 適合 offload 或大記憶體實驗，不是 24 GB 部署方案。 |
預發布時期的硬體建議，現在有何不同？
GLM-5.3 repository 現已上線，並提供原生 FP8 檔案。checkpoint metadata 應以線上 model card 為準，拓撲與啟動參數則看官方 vLLM recipe，至於實測部署體驗可參考社群報告；目前 recipe 標示的 context window 為 1,048,576 tokens。
別只看參數量，先按記憶體預算選方案
部署 GLM-5.3 時，第一道門檻是權重記憶體，第二道則是 context 所需記憶體。活躍參數較少能降低運算量，但無法免除儲存 routed experts 與 runtime buffers 的需求。
24–64 GB：不要規劃完整 GLM-5.3 本機部署
單張 RTX 4090、RTX 5090，或任何 24 GB 等級顯示卡，都放不下旗艦版原生 FP8 checkpoint。線上 Hugging Face repository 中的 safetensors 檔案約為 756 GB，即使是 64 GB 工作站卡，也遠低於權重所需容量。
透過 CPU offload，或許能載入量化實驗，但那比較適合除錯，不是互動式程式設計服務的預設選擇。Agent 必須能在可接受的速度下完成一連串工具呼叫。
128–192 GB：旗艦版仍不可行；Flash 僅有特定方案
128 GB 或 192 GB 的統一記憶體機器，仍不足以部署旗艦版原生 FP8。Flash 則有明確路徑：公開的已驗證設定，使用固定版本的 EXL3/TR3 4-bpw checkpoint，橫跨 2× RTX PRO 6000 Blackwell 96GB GPU 執行。
該設定使用 175.6 GB checkpoint 資料、約 220 GB 可用儲存空間、PCIe peer-to-peer 通訊，以及固定版本的 runtime。報告指出單次 request 上限為 262,144 tokens，但這是兩張獨立 GPU 的部署，並不等同於擁有 192 GB 一般系統 RAM。該 Flash 設定也回報 171.7 tokens per second 的 decode 速度，以及 0.059 seconds 的 median time to first token。
2–4 張大記憶體 GPU：看 Flash，不要看旗艦版
若你有兩張或四張大記憶體顯示卡，第一個值得研究的目標是 Flash。原因是精度、runtime、context length、batching 與影像輸入都會改變記憶體預算。這份雙 GPU 已驗證設定支援文字、結構化工具與語義影像輸入；但影片功能已停用，endpoint 沒有內建驗證機制，隨附的 vision template 也必須先進行可還原的修正，才能做多模態驗證。這些限制只適用於該固定 recipe，不代表所有 Flash build 或旗艦版都會如此。
8× H200 或 H20：官方定義的 FP8 旗艦拓撲
官方 vLLM recipe 將 8 張 H200 或 H20 列為原生 FP8 的標準拓撲。設定採用八路 tensor parallelism、FP8 KV cache、五 token 的 multi-token prediction、自動工具選擇，以及 GLM 專用的 reasoning 與 tool-call parser。
這是官方文件記載的拓撲，而不是特定 tokens-per-second 表現的保證。實際吞吐量取決於互連、context length、batch size、並行 sequence 數量與 serving build；vLLM 頁面提供的是設定方式，未提供量測過的正式環境吞吐量。
8× B200：需要 1M context 才選它
官方 recipe 將 8 張 B200 定位為完整 1,048,576-token context 設定的硬體。額外的 context 本質上是 VRAM 問題：KV cache 會隨活躍 sequence 與 context 增長，因此能以 32K 或 128K tokens 運作的部署，未必能在相同並行量下支援 100 萬 tokens。
建議先以較小的 --max-model-len 值開始，量測 KV-cache 用量後再逐步提高。超大的 context window 對長篇 repository 與文件很有價值，但不表示每一筆 request 都具成本效益或能維持低延遲。
官方 recipe 沒有定義的主機規格
vLLM recipe 提供 GPU 拓撲與啟動參數，但沒有公布通用的系統 RAM、供電、散熱、儲存空間餘裕或網路需求。這些數值會隨 checkpoint、runtime、context 目標與供應商平台而變動。
| 主機項目 | 現有資料能支持的結論 |
|---|---|
| 模型儲存空間 | 線上旗艦 repository 顯示 safetensors 檔案為 755.6 billion bytes；還須預留 cache 與暫存 shards 的額外空間。 |
| GPU 互連 | recipe 要求八路 tensor parallelism；應確認租用平台或伺服器的拓撲，而不是假設 PCIe-only 的效能。 |
| 系統 RAM | vLLM recipe 未公布通用的官方數字。不要將系統 RAM 數字誤當成所需 GPU 記憶體。 |
| 供電與散熱 | 官方未公布通用數字。採購硬體前，請依平台的八 GPU 電力與散熱規格評估。 |
| 軟體 | 官方 recipe 採用 vLLM 0.28.0 或更新版本，以及 Transformers 5.15.0 或更新版本；FP8 效能需要 DeepGEMM。 |
最小化的官方 serving 路徑
文件中的部署方式使用 vLLM 0.28.0 與 OpenAI-compatible endpoint，設計目標是多 GPU 節點。直接把指令複製到較小的機器上，並不會消除模型本身的記憶體需求。
安裝文件指定的 runtime
uv venv
source .venv/bin/activate
uv pip install "vllm==0.28.0" --torch-backend=auto
uv pip install "transformers>=5.15.0"vLLM recipe 也指出，若要取得 FP8 效能，必須使用 DeepGEMM。在租用付費節點前，先確認最新 recipe 與目標 GPU image 是否相容。
啟動原生 FP8 GLM-5.3
vllm serve zai-org/GLM-5.3 \
--kv-cache-dtype fp8 \
--tensor-parallel-size 8 \
--speculative-config.method mtp \
--speculative-config.num_speculative_tokens 5 \
--tool-call-parser glm47 \
--reasoning-parser glm45 \
--enable-auto-tool-choice \
--served-model-name glm-5.3各參數的作用如下：
--tensor-parallel-size 8將 checkpoint 分散到 8 張 GPU。--kv-cache-dtype fp8相較於較高精度的 cache，可降低 cache 壓力。- 五 token 的 MTP 設定會啟用文件所列的 speculative decoding。
--tool-call-parser glm47與--reasoning-parser glm45負責將模型輸出格式化，以供工具使用與 reasoning。--enable-auto-tool-choice讓伺服器能在 client 提供工具時自行選擇工具。
接上 agent 前，先驗證 endpoint
curl -X POST "http://localhost:8000/v1/chat/completions" \
-H "Content-Type: application/json" \
--data '{
"model": "glm-5.3",
"messages": [
{"role": "user", "content": "Write a Python function that reverses a linked list."}
],
"max_tokens": 256
}'收到成功回應，只能證明模型已完成載入，不能證明工具使用或長 context 行為正常。官方 model card 也列出 SGLang 作為另一條 OpenAI-compatible 路徑；本指南選用 vLLM，原因是它有專屬 recipe，明確記錄 GPU 拓撲與啟動參數。
容易被忽略的記憶體開銷：KV cache 與常駐 reasoning
GLM-5.3 model card 與vLLM recipe都將 thinking 視為永遠啟用。支援的 reasoning-effort 值為 low、high 與 max；若未提供受支援的較低設定，預設值是 max。
更長的 reasoning 會產生更多 output tokens；同時，程式設計 agent 在連續工具呼叫過程中，可能持續將龐大的 repository 前綴保留在 KV cache。即使模型權重不變，更多並行 sequence 仍會成倍提高 cache 需求。
可將這些設定視為部署控制項：
- Low：互動式程式設計、短 request 與對延遲敏感的工具，建議從這裡開始。
- High：適合需要較多規劃，但仍有互動式回應預算的任務。
- Max：保留給高難度、長期任務，且額外 reasoning tokens 確實合理的情境。
官方 recipe 建議完整 context 的 B200 設定採用 --max-num-seqs 32，並使用 FP8 cache。請將這個數字當成起點：若伺服器記憶體不足，就降低並行量；在實際 request 未達到該範圍且未發生 cache truncation 前，也不要宣稱支援 100 萬 tokens。
什麼時候 API 比買硬體更理性？
自架服務即使沒有開發者送出 request，仍須保留 GPU 容量。若流量間歇、並行度低，或團隊仍在驗證 GLM-5.3，API 可避免購買或持續租用八 GPU 節點；代價則是資料由託管服務處理，以及對供應商的依賴。
Z.ai 目前的價格頁面列出：GLM-5.3 每 1M input tokens 為 $1.40、每 1M cached input tokens 為 $0.26、每 1M output tokens 為 $4.40。GLM-5.3-Flash 的牌價則為 $0.15 / $0.03 / $0.50，頁面顯示有 50% 優惠至 2026 年 9 月 9 日；做預算前請再次確認線上帳務頁面。
| 工作負載 | GLM-5.3 牌價試算 | GLM-5.3-Flash 牌價試算 |
|---|---|---|
| 10M 新 input + 2M output | $14.00 + $8.80 = $22.80 | $1.50 + $1.00 = $2.50 |
| 2M 新 input + 8M cached input + 2M output | $2.80 + $2.08 + $8.80 = $13.68 | $0.30 + $0.24 + $1.00 = $1.54 |
這些只是 token 成本範例，不是自架服務的損益兩平計算。有效的本機比較還必須納入節點時租價格、持續 tokens per second、使用率、電力、儲存空間、工程時間，以及失敗或重試的 agent 執行成本。若想逐項了解費率，可參考 AIReiter 的 GLM-5.3-Flash API pricing guide。
選擇方向如下：
- 若你需要旗艦版、但需求不規律或屬中等規模，選擇託管的 GLM-5.3 API。
- 若較在意較低 token 成本、多模態輸入或較小的自架目標，選擇 GLM-5.3-Flash。
- 若隱私、控制權或持續使用率足以合理化八 GPU 部署，選擇自架旗艦版 GLM-5.3。
GLM-5.3 硬體需求 FAQ
GLM-5.3 能在單張 RTX 4090、RTX 5090 或 24 GB GPU 上執行嗎？
不行，至少完整模型不行。線上原生 FP8 repository 含有約 756 GB 的 safetensors 檔案，因此 24 GB 顯示卡頂多參與極端的 offload 或量化實驗，無法正常承載模型 serving。
128 GB 或 192 GB RAM 夠用嗎？
不足以部署旗艦版原生 FP8。已驗證的 Flash 設定使用兩張獨立 96 GB GPU、固定版本的 4-bpw checkpoint，並需要額外儲存空間；這不等同於一台 192 GB 筆電或統一記憶體工作站。
GLM-5.3 和 GLM-5.3-Flash 有什麼差別？
兩者是不同模型：旗艦 model card 顯示總參數約為 753B，而Z.ai 對 Flash 的說明為總參數 320B、活躍參數 18B，並定位為原生多模態模型。Flash 較小、成本較低，但它仍是伺服器等級模型，不是可視為 18B 桌機模型的產品。
該選哪一種精度？
若有文件指定的八 GPU 拓撲，使用原生 FP8。若可接受多節點記憶體需求，BF16 適合作為參考品質或特殊評測；NVFP4 僅應在支援的 Blackwell 硬體上考慮，並要記得recipe 列出的 NVFP4 checkpoint是社群重新量化版本，不是原始預設套件。
GLM-5.3 能連接程式設計 agent 嗎？
可以。官方 vLLM recipe 提供 OpenAI-compatible endpoint，以及 tool-call 與 reasoning parser，因此支援該介面的 client 在完成伺服器驗證後即可連線。不過，別因為 chat completion 成功就假定 agent 一定相容；應實際測試使用的 harness、tool schema 與長 session 行為。
接下來該怎麼做
如果你只有桌機或低於 192 GB 的主機，先測試託管 API。你可以租用文件列出的八 GPU 拓撲，針對代表性工作負載進行測試；或在高記憶體多 GPU 機器上評估 Flash。只有在實測使用率證明控制權與隱私需求足以支撐基礎設施成本後，再考慮自架。