GLM-5在WaveSpeed上的推理速度：延遲與吞吐量

在起草一封入職郵件時，我想要快速回覆。GLM-5 感覺很聰明，但第一個 token 出現的時間長到讓我盯著游標發呆。這不是什麼大問題，只是一個不斷重複的小停頓。這通常是我檢查實際情況的訊號。

我是 Dora。我做了一組簡單的測試，看看能在不把工作流程變成科學實驗的前提下，從 GLM-5 推理速度中榨出多少效能。沒什麼花俏的，只要足以感受到實際工作中的差異，而不是在實驗室裡。

測試方法（硬體、設定、提示詞長度）

我嘗試了三種存取路徑：

• WaveSpeed：我一直在測試的輕量加速層，在客戶端/閘道側處理請求整形與快取。
• 直連 Z.ai API：透過供應商直接存取 GLM-5 的路由。
• OpenRouter：一個帶有額外功能、轉發至模型供應商的中介服務。

硬體與情境

• 本地客戶端：MacBook Pro（M2 Max，64 GB RAM）。網路使用穩定光纖（下載約 500 Mbps，到美國常見端點約 30 ms）。
• 伺服器端：無自訂伺服器，僅使用客戶端呼叫；WaveSpeed 除外，它在本地執行一個小型閘道來管理快取與批次整形。

除非特別說明，我保持以下設定不變

• 模型：GLM-5（chat/completions），temperature 0.2，top_p 0.9，max_tokens 512。
• 開啟串流，因為這是我實際的工作方式。
• 除網路錯誤外，關閉重試。

我使用的提示詞

• 短：60–80 個 token（包含 2–3 個限制條件的精簡指令）。
• 中：約 350 個 token（帶有品牌備注與範例的郵件草稿）。
• 長：約 1,500 個 token（包含產品背景、語調備注及應做／不應做清單的小型簡報）。

每個條件執行 25 次，並記錄：

• 首個 token 時間（TTFT）：從發出請求到收到第一個串流 token 的時間。
• 吞吐量（tokens/s）：token 開始輸出後的串流輸出速率。
• 「思考模式」的切換（供應商的推理追蹤）。

關鍵指標

首個 token 時間（TTFT）

在良好路由下，短提示詞的 TTFT 落在 250–400 ms 之間。中等提示詞將 TTFT 推高至 450–700 ms。長提示詞超過一秒，除非快取介入。這個跳躍並非線性：感覺排隊與驗證的額外開銷和提示詞長度同樣重要。

我的感受：400 ms 以下感覺流暢；超過一秒就會打斷思緒。在即時編輯文案時，第一個 token 比最終吞吐量更重要。

每秒 token 數（吞吐量）

一旦串流開始，非思考模式的運行速度約為 35–70 tok/s。這對文案來說足夠快，對程式碼差異比較則勉強夠用。吞吐量在較長輸出時下降，我猜測是伺服器端整形與安全性檢查的緣故，而非純粹的模型速度問題。

思考模式 vs 非思考模式

開啟「思考」後，TTFT 跳升 30–80%，某些情況下吞吐量減半。在棘手的提示詞上，輸出文字更為連貫，但對於日常草稿撰寫，我並不需要它。一開始這並沒有節省時間，但經過幾次執行後，我注意到它減少了複雜編輯上的心智負荷。簡單任務我就關閉它。

WaveSpeed 加速如何應用於 GLM-5

WaveSpeed 並未修改模型權重。它在我這端做了兩件簡單且有用的事：減少冗餘工作，並整形請求以讓供應商能更快回應。在 GLM-5 上，這體現為重複提示詞的 TTFT 改善，以及中等提示詞的小幅提升。

ParaAttention 與快取技術

• ParaAttention（我的筆記）：WaveSpeed 不是批次處理不相關的請求，而是在偵測到重複框架時，對單一長提示詞內適合平行處理的區塊進行注意力平行化。實際上，它重用了序言部分（系統提示 + 共用範例），只推送差異部分。我無法驗證內部機制，但效果看起來像是閘道層的部分 KV 快取重用。
• 快取：它對提示詞序言和短系統範本的嵌入進行了記憶化。當我在相同任務上進行小幅修改的迭代時，TTFT 下降了約 120–180 ms。在冷提示詞上，效益較小（約 40 ms），但仍然明顯。

我遇到的限制

• 第一次冷啟動仍受限於上游，沒有奇蹟。
• 如果我更改了超過約 20% 的提示詞，快取就不起作用。
• 思考模式基本上抵消了這些收益：推理追蹤的行為類似一個獨立的串流。

比較：WaveSpeed vs 直連 Z.ai API vs OpenRouter

這就是細微差異開始重要的地方。

• 直連 Z.ai API：穩定。TTFT 變異最小。當我需要在展示中有可預測的回應開始時，這是我的首選。在長提示詞上，TTFT 懲罰是真實存在的，但很穩定。
• OpenRouter：平均 TTFT 略高，變異稍大，但設置簡便且路由靈活。在同時使用多個模型時很好用。文檔完善：參見 OpenRouter 指南。

• WaveSpeed 層：在暖提示詞和中等輸入上 TTFT 最佳，可能來自快取和請求整形。在真正冷啟動的長提示詞上，與直連不相上下。

這些都沒有改變 GLM-5 的核心行為。它們改變的是我感受到模型「甦醒」的速度，以及迭代過程的流暢程度。

如果你正在做選擇：

• 需要穩定效能且希望減少不確定因素？透過供應商直連。參考：ZhipuAI API 文檔。
• 需要多模型路由或跨工具共用金鑰？OpenRouter 不錯，接受多幾毫秒的延遲。
• 整天在相似提示詞上迭代？輕量加速層帶來的心理平靜回報比原始速度更多。

生產工作負載的優化技巧

實際上有幫助的做法：

• 預熱序言：保持系統提示和共用範例穩定。快取它們，即使是在客戶端。我的 TTFT 節省：重複執行時約 100–200 ms。
• 修剪尾部：將 max_tokens 上限設為真正需要的數量。將 1,000 token 的上限削減至 400，為我的草稿節省了總時間的 10–20%。
• 優先使用結構化重試：如果必須重試，恢復串流而不是重新啟動。盲目重試會大幅增加 TTFT。
• 控制變異性：生產環境中 temperature ≤0.3。較低的熵值減少了伺服器處理次數，使吞吐量更穩定。
• 延遲思考模式：僅在歷史上容易出錯的提示詞上啟用它。我標記「困難提示詞」，並按路由切換該標誌。
• 在上游分塊長上下文：一次性摘要參考資料，儲存摘要並重複使用。第二次和第三次執行感覺明顯更輕鬆。
• 注意 tokenization：不同的 SDK tokenize 方式略有差異。鎖定客戶端並重新測量：光是這一點，我就看到了假性的效能退化。
• 測量 p95 而非僅 p50：峰值延遲造成的可見延遲才是用戶真正記得的。

原始基準數據（表格）

以下是我執行結果的快照（每行 25 次迭代）。所有數字都是近似值，但能代表我在鍵盤前的實際感受。

備注

• 「暖序言」表示系統提示 + 共用範例已被閘道快取。
• 吞吐量在第一個 token 之後測量。總時間 = TTFT + tokens_out / 吞吐量。
• 網路狀態穩定：當我在飯店 Wi-Fi 上測試時，所有數據都差了 10–20%。

最後一個觀察：削減 150 ms 的 TTFT 對我來說比增加 5 tok/s 更有意義，因為它減少了那個觸發上下文切換的小等待。這不是普遍規則，只是我的大腦處理串流的方式。