7440億參數模型跑進 Windows 工作站：本地 MoE 的代價與取捨

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-12

XDA Developers 記者 Joe Rice-Jones 表示，已在一部 Windows 11 工作站的 WSL2 環境，載入 Z.ai 公開權重的 GLM-5.3。這是擁有 7,440 億參數的 mixture-of-experts（MoE）模型，原始完整模型約 1.5TB；透過 Unsloth 的 2-bit 動態量化及 llama.cpp，測試機可把它壓縮至約 238.6GB 的檔案並完成推論。這對希望把 coding agent、內部文件問答或自動化流程留在本地的開發者有啟示：超大型模型不再必然只可經雲端 API 使用，但所需硬件仍遠離一般家用電腦。

最重要的限制也很直接。XDA 的配置是 HP Z8 Fury G6i 工作站、Xeon 696X、兩張各有 96GB VRAM 的 NVIDIA RTX PRO 6000 Blackwell Max-Q，以及 128GB 系統記憶體，合計約 320GB 可用記憶體；文章估計整機約 65,000 美元。即使擁有 192GB VRAM，模型仍有一部分必須放進系統記憶體。因此，這不是「買一張高階消費級顯示卡便可複製」的案例，而是展示工作站級顯示記憶體、量化技術與 MoE 架構如何共同把門檻下調。

MoE 令模型能載入，卻沒有令所有成本消失

GLM-5.3 的關鍵在於 MoE 架構。XDA 指出，模型雖有 7,440 億個參數，但每次生成一個 token 時只會啟用約 400 億參數的 experts，可理解為每次查詢只會調用大型資料庫中的部分分區。這減少運算時實際啟用的權重，卻不代表其他權重可以不儲存；要在本地運行，整個模型仍要放在 GPU VRAM、系統記憶體或兩者之間的組合中。

這個分別對規劃私有 AI workflow 很實際。MoE 有助降低每 token 的活躍運算量，令超大模型有機會進入單一工作站；但當非活躍 experts 被卸載至系統記憶體，資料搬運便會受 RAM 頻寬及 GPU 與主機之間傳輸影響。換言之，能否「成功載入」與日常 agent 工作是否流暢，是兩條不同的評估線。部署前若只看參數量或 VRAM 總數，很容易高估實際體驗。

量化是另一項核心取捨。XDA 列出的 Unsloth 版本中，1-bit UD-IQ1_S 約 216.7GB，2-bit UD-IQ2_M 約 238.6GB，均可放進這套約 320GB 的記憶體池；3-bit UD-Q3_K_XL 則達 343GB，無法容納。測試者選用 2-bit 版本。Unsloth 自行測試稱，IQ2_M 與完整模型的 top-1 一致率為 78.53%，並以動態方式保留部分重要層較高精度。不過，這是供應商的指標，不能直接等同 coding、工具調用或企業知識庫任務的可靠程度。

WSL2 可行，但記憶體配置與分配策略決定成敗

測試在 WSL2 進行，Windows 顯示卡驅動把兩張 GPU 傳遞給 Linux 環境，WSL 端只需 CUDA toolkit。真正的陷阱是 WSL 預設只可取得約一半系統記憶體：128GB RAM 下若維持約 64GB 上限，模型會在載入途中耗盡記憶體。測試者把 .wslconfig 的上限調至 116GB 才能繼續。對已有 Windows 開發環境、但不想雙系統開機的團隊，這說明 WSL2 可以是部署路徑，但其資源上限必須被視為正式容量規劃的一部分。

llama.cpp 的參數安排同樣不能照預設處理。首次嘗試雖然花了約六分鐘讀入 239GB 模型檔，最終仍因第二張 GPU 分配約 110GiB 而出現 CUDA 記憶體不足。原因是 --n-cpu-moe 20 把最初 20 層的 experts 放到系統記憶體後，llama.cpp 仍按層數平均分給兩張卡；第一張卡接收了較輕的層，第二張卡卻保留較多完整 experts，而且該卡還要驅動螢幕，預先被 Windows 佔用約 2.2GB。

後來測試者以 --tensor-split 64,36 手動調整分配，並把 --n-cpu-moe 提至 22，才成功載入；GPU 0 峰值使用 93.9GB，GPU 1 則為 80.1GB。這個案例反映，多 GPU 本地推論不能只把兩張卡的 VRAM 相加。模型各層的記憶體佔用、顯示輸出所佔資源、CPU offload 數量，以及 runtime 的預設切分方式，都會影響結果。對小型團隊而言，先做記憶體地圖和載入測試，通常比先追求較高位元量化版本更有價值。

生成速度尚算可用，長 prompt 和推理時間才是實務瓶頸

在 llama.cpp build e937b17a2、64K context、q4_1 KV cache 與上述分配下，XDA 的測試錄得生成速度 11.3 tokens/s，約 2,000-token prompt 的處理速度為 82.7 tokens/s；在 8,184-token prompt 下，首個 token 等候 96.9 秒，32,984-token prompt 更要 393.9 秒。測試者亦稱模型在 8K 及 32K 的隱藏程式碼回憶測試中找到目標，工具調用測試通過。這些都是單一媒體、單一硬件配置的結果，適合用作容量與工作流參考，不能視為模型能力的普遍排名。

數字顯示其較適合「人提出任務、模型慢慢完成」的本地工作，而非每一步都要即時互動的 agent。約 11 tokens/s 的生成速度足以閱讀和檢查一般回覆，測試者也指長達 12,000-token 的輸出仍維持約 12 tokens/s；但把大段 codebase、log 或文件塞進 prompt 後，前置處理就會令使用者等待數分鐘。若 agent 頻繁重新讀取同一批內容，這段等待可能比生成答案本身更影響吞吐量。這是 RAM offload 換取容量所帶來的直接代價。

深度推理模式更放大了問題。XDA 指出，GLM-5.3 可選 low、high 或 max effort，但不能關閉思考；在 high effort、12,000-token 上限下，要求模型製作單一 HTML Snake 遊戲時，它思考約 1,000 秒、產生 44,832 個字元的推理內容後已用盡 token，沒有交付遊戲程式。另一個附完整測試的 thread-safe rate limiter 任務則在八分鐘內完成。這不表示模型必然不適合編程，反而提醒使用者要把任務切細、設定合理輸出與推理預算，否則本地運行的低 token 速率會把「思考」變成很長的等候。

私有部署的意義在控制權，不在取代所有雲端 API

對需要控制原始程式碼、內部 log 或敏感文件流向的使用者，這類配置的吸引力在於模型可在自家環境處理資料，不必把每個 prompt 送到外部 API；也可按自己的工具、context 策略和運行時間安排工作。不過，這是從部署方式作出的合理分析，實際私隱程度仍取決於模型權重來源、下載與更新流程、工具調用權限、日誌保留及網絡配置。本地模型不會自動消除資料治理責任。

成本比較亦不能只看 API 用量。工作站級 GPU、足夠 RAM、耗電、散熱、儲存空間、維護時間及模型更新，都是固定或營運成本；反過來說，長期、高頻而且資料不能外流的批次工作，才較可能攤薄這些投入。XDA 的實驗證明技術路徑已經存在，但沒有證明它比雲端方案便宜或更快。準備採用者應先以自己的 prompt 長度、每日任務量、可接受等待時間和資料規範作試算。

接下來值得觀察的是量化模型在真實 coding agent 任務上的穩定度，以及 llama.cpp 等 runtime 能否更自動地處理異質記憶體與多 GPU 分配。若長 context 的載入延遲繼續下降，超大 MoE 模型才會更接近可長時間自行處理 codebase 的私有助手；在此之前，它較像一項昂貴但已可行的工作站級選項，適合有明確私隱或離線需求、並能接受調校成本的用戶。