什麼是GLM-5？架構、速度與API存取

我是 Dora。最近幾週，當我試著完成正常的草稿、規格文件和一些小型資料處理工作時，GLM-5 不斷出現在討論串和基準測試中。第三次看到它與「推理」和「代理」並列提及時，我停下來多看了一眼。不是因為我需要一個新模型，而是因為我目前使用的工具組合在較長的任務上有時會拖慢節奏。如果換個模型能稍微減輕負擔，我想親身感受看看。

於是我在 2026 年 2 月初的幾個晚上，用 GLM-5 處理我桌上實際發生的工作：雜亂的提示詞、寫到一半的大綱，以及從來不會固定不變的腳本。以下是我冷靜觀察後的心得，沒有誇張的溢美之詞。

GLM-5 的背景脈絡——智譜的第五代模型

智譜 AI 已經推出 GLM 系列模型一段時間了。如果你用過 GLM-3 或 GLM-4，應該對其風格不陌生：扎實的多語言推理能力、良好的程式碼直覺，以及務實的特質——不需要反覆調整提示詞就能完成工作。

GLM-5 是他們的下一步。我只針對我能觀察到的內容，以及智譜在公開資料中所分享的資訊進行說明。如果你想參考官方說法，官方文件是很好的參考來源：智譜 AI（GLM）文件以及智譜官方網站。

745B 總參數 / 44B 激活參數（MoE 架構）

最核心的技術細節是架構。GLM-5 採用混合專家（MoE）設計：擁有大量「專家」（據稱總參數約 745B），但每個 token 只激活其中一部分，平均約 44B。在實際使用中，這帶來了兩點我每天都能感受到的差異：

首 token 延遲感覺更接近 30–70B 的密集模型，而非 700B 的龐然大物。我的提示詞不像某些超大模型那樣在一開始就卡頓。
長篇生成的穩定性比我預期的更好。MoE 有時會出現漂移，但 GLM-5 在多步驟大綱和程式碼重構中大多保持在軌，這一點我並不視為理所當然。

我更在意的不是數字本身，而是它能帶來什麼：激活算力足以承載細微的語義差異，但路由機制讓成本和速度維持在可接受的範圍內。根據 Hugging Face 的 MoE 說明文章，稀疏激活讓模型能夠「擴展至數十億甚至數兆個參數」，同時維持合理的推理成本。在幾個較長的推理鏈（約 3–5 段的多跳分析）中，與較小的密集模型相比，我注意到「遺忘式」跳躍的情況明顯減少。

主要升級：推理、程式碼、代理行為、創意寫作

與早期 GLM 版本相比，我注意到以下變化：

推理：即使不主動要求，類思維鏈的結構也更頻繁地出現。我並不總是需要完整的推理過程，但內部邏輯確實更加穩健。當我要求它審視自己的計畫時，它會做出調整，而不是顯得防禦性或陷入迴圈。
程式碼：它在增量式編輯方面比全面重寫更得心應手。當我要求以差異（diff）風格修改腳本時，它會保留上下文，而不是重新輸出所有內容。這節省了幾分鐘——雖然不多，但確實有感。
代理行為：工具調用風格的任務（描述步驟、識別缺失輸入、提出重試建議）輸出更加清晰。我不會讓它在無人監管的情況下存取關鍵系統，但作為規劃夥伴，它的表現是稱職的。
創意寫作：語氣控制有所改善。如果我設定了語調（「平淡、緩慢、親切」），它能在幾頁篇幅內維持一致。當要求中混雜了過多的限制條件時，它仍會有些磕絆，但漂移程度較輕。

這一切都稱不上神奇，但確實減少了我的提示詞通常需要耗費的腦力開銷。在週二下午注意力稀缺的時候，這一點尤其重要。

推理速度概覽——預期表現

我透過共享推理層（而非智譜自己的控制台）測試 GLM-5，因此底層硬體可能有所不同。儘管如此，在三次測試（2026 年 2 月 6–9 日）中，仍出現了一致的規律：

首 token 延遲：短提示詞通常在一秒以內；包含多部分指令的較重型、工具類請求為 1–2 秒。這個範圍內，我不會因為等待而打斷思路。
持續吞吐量：長篇回覆呈現穩定的串流輸出，感覺約在 30–60 tokens/秒的範圍。在高負載下，它不像某些 MoE 模型那樣在段落中途停滯。
長上下文穩定性：在約 8–16k token 時，輸出保持連貫。這幾次測試中我沒有挑戰最大上下文窗口，因為我的實際任務很少需要如此之長。有關上下文窗口大小的更多說明，請參見常見問題。

延遲 vs. 吞吐量 vs. 成本的取捨

MoE 設計意味著你以密集模型的簡單性換取一個路由層，而這個路由層（理想情況下）在相同品質水準下，能在速度和成本上實現正向回報。在實際使用中：

如果你注重流暢的來回對話（產品規格、電郵草稿、程式碼重構），GLM-5 的響應速度足以維持工作流。
如果你進行批次大型作業，吞吐量表現穩定。我仍建議將非常長的文件分塊處理，以避免重試。
成本取決於服務提供商。44B 的激活參數意味著定價落在「大型但非頂級」的區間。如果你目前的技術棧是用小型密集模型處理快速任務、用單一昂貴模型應對困難任務，GLM-5 或許能以更少的切換覆蓋更多的中間地帶。

一個來自實戰的備注：我沒有觀察到「推理型」和「創意型」提示詞之間存在明顯的速度差異。有些模型在決定「大聲思考」時會明顯變慢，而 GLM-5 無論哪種方式都保持著穩定的節奏。

如何透過 WaveSpeed API 存取 GLM-5

我透過 WaveSpeed 使用 GLM-5，它以相容 OpenAI 的介面整合了多個服務提供商。這裡不寫程式碼，只用白話文描述我的操作步驟。

模型 ID、端點、身份驗證設定

模型 ID：我在 WaveSpeed 模型目錄中選擇了標記為「glm-5」的模型。有些提供商會附加大小或路由標籤，我直接使用預設值。
端點風格：介面使用了熟悉的 chat.completions 模式。如果你曾整合過任何 OpenAI 相容的服務，通常只需更改基礎 URL 和模型字串即可完成切換。
身份驗證：在標準 Authorization 請求標頭中使用單一 API 金鑰即可。我為每個專案設定了獨立的金鑰，以保持日誌整潔。速率限制會顯示在回應標頭中，在調整並發數時非常方便。

兩個來自設定過程的實用提示：

temperature 和 top_p 的行為可以預期，但對於複雜提示詞，稍微降低 temperature（0.5–0.7）能讓輸出更加穩定。這樣做能減少漫無邊際的輸出，同時不會抹平語調。
最大輸出 token 數：預設上限較為保守。如果你的回答經常被截斷，請盡早調高這個數值，可以省去重新運行的麻煩。

GLM-5 的市場定位（對比 GPT-5、Claude 4.5、DeepSeek）

比較很快就會變得嘈雜，所以我只談實際感受，不做排行榜式的比拼。

對比 GPT 系列：GPT 系列在生態系統重力、外掛、範例和社群資源方面仍然佔優。在專注寫作和逐步推理方面，GLM-5 毫不遜色。與我最近使用的某些 GPT 版本相比，它在長篇大綱中出現的格式異常更少，在處理增量式程式碼編輯時也不那麼容易過度修改。
對比 Claude 系列：Claude 模型通常謹慎克制，擅長節制和摘要。GLM-5 在事實性改寫方面展現出同等的克制，並且稍微更願意主動提出後續步驟，無需催促。如果你喜歡 Claude 在語調和安全框架方面的表現，在處理敏感內容時可能仍會偏向它。
對比 DeepSeek：我用過的 DeepSeek 模型感覺輕盈且具成本效益，非常適合大量任務。GLM-5 每次調用的感覺更「厚重」，但在多跳分析上更加穩健。如果你需要大量小型查詢，DeepSeek 在性價比上可能略勝一籌；但對於較少、較深入的調用，GLM-5 對我來說更合適。

這些沒有對錯之分，只是不同的預設特性。如果你已深度嵌入某個生態系統，轉換的理由就比較薄弱。如果你習慣按任務混用模型，GLM-5 是「思考型工作」這個位置的有力候選者。

常見問題——可用性、定價、上下文窗口

可用性：GLM-5 可透過智譜平台及部分聚合服務商取得。如果你在中國大陸以外，延遲和存取情況可能因服務提供商而異。我在 2026 年 2 月 6–9 日那週使用的是 WaveSpeed。
定價：因服務商而異，聚合商有各自的收費標準，且廠商會隨時間調整定價。我避免引用容易過時的數字，建議在正式上線前直接查看你所用服務商的定價頁面。
上下文窗口：在我的測試中沒有觸及上限。約 8–16k token 的工作範圍保持穩定。如果你的工作流程依賴非常長的上下文（完整 PDF、逐字稿），請在文件中確認硬性限制並留意截斷問題。
安全與內容審核：我觀察到標準的安全護欄。在我澄清用途之前，它拒絕了幾個模糊的請求。如果你的業務領域有嚴格的合規要求，建議先進行小規模的政策審計。
適合誰：如果你需要更少的模型切換，並希望在規劃、分析和以修改為主的寫作任務上獲得更穩定的輸出，GLM-5 很合適。如果你追求極低成本、極高速度的微型任務，較小的密集模型或 DeepSeek 類的選項可能更適合你。

最後，一點來自我的工作臺的小感想：我欣賞的並非原始的強大性能，而是不需要時刻盯著它。這不是什麼驚天大標題，但卻是那種在一週工作中悄悄積累起來的、切實的進步。