GLM-5 vs DeepSeek V3 vs GPT-5：開發者的速度與成本比較

嘿，我是 Dora。讓我開始思考這個問題的契機其實很小：一個原本應該五分鐘內完成的摘要任務，卻拖了十五分鐘，因為第一個回應在開頭就卡住了。這不完全是模型的問題——token 串流、伺服器負載，諸如此類——但這件事提醒了我，「準確性」並不是唯一能把一天搞亂的因素。

於是我開始認真面對那個一直困擾我的問題：在真實世界中，GLM-5、DeepSeek 和 GPT-5 用起來實際感覺如何？不是看圖表，而是看回應時間、不會讓你嚇一跳的費用，以及在任務有三四個環環相扣的部分時的可靠性。這篇文章是我試著冷靜地把這些寫下來的嘗試，並附上一個說明：你的技術堆疊、所在地區，以及你對邊緣案例的容忍度，都會讓結論有所不同。

我會保持務實：GLM-5 vs DeepSeek vs GPT-5，超越炒作與慣見的基準測試截圖。

基準分數之外，還有什麼值得比較

基準測試是一個健全性檢查，而不是終點。我真正關注的測試並不光鮮：

最重要的延遲：首個 token 出現的時間（TTFT）以及穩定的輸出速度。一個「思考更久」的模型不是問題；一個甚至還沒開始就閒置的模型，往往才是。
符合工作形態的成本：每百萬 token 的報價只是起點，但情境視窗的浪費、重試，以及工具呼叫，都可能讓實際支出翻倍。
失敗模式：當提示稍有偏差、工具逾時，或輸入比預期長時，模型的表現。
可控性：能真正改變輸出變化的溫度參數、能保持住的系統提示、不會在 schema 邊緣搖晃的函數呼叫。
高負載下的性能衰退：一分鐘內的第三次執行，或是批次工作中的第一百個任務。

在 GLM-5、DeepSeek 和 GPT-5 之間，我尋找的是沉穩的稱職感：不會以錯誤方式讓我驚訝的模型。我也記錄了每個模型的弱點所在，因為圍繞已知弱點設計，遠比圍繞行銷承諾設計來得容易。

推論速度（TTFT + 輸出速度）

我關注兩個時刻：第一個 token 出現的時候，以及後續內容的生成速度。

TTFT：這告訴我模型是否立即開始作業，還是讓我乾等。在互動式工具（起草文件、支援對話）中，快速的 TTFT 感覺像是一種體貼。
輸出速度：一旦開始，它能否在長篇輸出時保持穩定的節奏而不出現卡頓？

我在實際使用中的觀察（2026 年 2 月，美國/歐盟混合端點）：

GLM-5：在短提示上 TTFT 一貫快速。在長情境（超過約 30–40k token）下，開始時稍慢，但串流穩定。起草文件和程式碼編輯時有種「不製造麻煩」的好感。如果你想要原始數據和並排延遲比較，我發現這篇 GLM-5 推論速度基準測試分析很有參考價值。
DeepSeek（尤其是 R1/V3 變體）：TTFT 出乎意料地快，即使在輕度批次負載下也是如此。在非常長的生成中偶爾會有微小的串流停頓，但恢復流暢。
GPT-5：在某些端點上的啟動比預期慢，但之後以非常穩定的串流補回來。當工具呼叫進入流程時，交接的開銷很低，這有助於多步驟流程。

我不斷提醒自己的注意事項：地區和閘道的影響，不亞於模型本身的原始性能。如果你透過聚合器路由，請開啟串流，並在探索性執行時適當降低 max_tokens。這能消除等待空白，而不影響輸出品質。

每百萬 token 的成本

公告價格只是起點，而不是你最終付的帳單。有三個變數對我的實際成本影響比預期大得多：

情境浪費：每次呼叫都傳送相同的系統前言和工具 schema，累積起來相當可觀。快取或精簡 schema 很快就能回本。
重試策略：在繁忙時段，針對速率限制的一次激進重試，可能悄悄讓支出翻倍。
輸出長度管控：設定合理的 max_tokens 上限（並讓模型在函數呼叫時停止），比任何折扣碼都有效。

截至本月：

DeepSeek 一直在推進積極的定價策略，尤其是推論變體。它對批次工作流程很友好，前提是你留意偶爾的風格變異。
GLM-5 定位在務實的中間地帶。不是最便宜的，但可預測，而當財務部門需要預算預測時，可預測性本身就有價值。
GPT-5 的定價在公開層面仍在變動中。在實務上，我以 GPT-4.1/4o 的價格區間作為下限來建立預算模型，並為 GPT-5 的推論層預留空間。如果你今天需要一個確定的上限，這是需要壓力測試的那個。

如果你要做蘋果對蘋果的比較，請衡量「每個有效輸出的實際成本」，而不是 token 數量。一個貴 1.2 倍但能將修改次數減半的模型，在我看來是贏家。

推理與程式碼品質

我沒有跑排行榜。我跑的是我實際在做的工作：結構化寫作、小型程式碼工具，以及多工具代理流程。兩個角度最為重要。

單一任務準確性

在專注任務上（例如「將這段 JSON 轉換為帶型別的介面」、「摘要這些會議記錄並列出行動項目」），GPT-5 感覺最為完整。它需要較少的引導才能遵循嚴格的格式，函數呼叫也更可靠地保持在 schema 範圍內。

DeepSeek 在能夠逐步展開的推理任務上表現不錯。我注意到它有輕微的過度闡述傾向，這對草稿來說沒問題，但對嚴格輸出來說不太理想，除非我限制 max_tokens 並明確要求簡潔。 GLM-5 落在一個平穩的中間點：較少的華麗修辭、穩定的遵循度，以及在差異不大時扎實的程式碼編輯。在使用模糊提示的冷啟動場景中，它有時比我希望的更為保守，但更嚴格的系統提示解決了這個問題。

多步驟代理可靠性

當工具加入進來——搜尋、爬蟲、資料庫讀取——問題就從「答案好不好？」轉變為「迴圈能不能撐住？」

GPT-5：擅長規劃短鏈，並在工具逾時時恢復。它會要求補充缺少的欄位，而不是自己猜測。這是件小事，卻能大大保持理智。
DeepSeek：簡潔、高效的呼叫鏈。偶爾在兩個工具功能重疊時，會自信地走錯方向。在系統提示中加入明確的工具選擇規則有所幫助。
GLM-5：在 schema 定義明確時非常穩定。如果工具返回了非預期的資料結構，它會偏向謹慎並要求釐清。比起無聲的幻覺，我更偏好這種做法。

一開始這並沒有節省我的時間——事實上，設置護欄又花了一個下午——但在幾次執行後，我注意到它減少了腦力消耗。更少神秘的失敗，更少「它為什麼這樣做？」的時刻。

按工作類型推薦最佳模型

這不是加冕典禮，而是一個配對練習。以下是每個模型在我這週最適合的場景。

即時應用程式 → ？

如果螢幕另一端有人在等待，我會偏向快速的 TTFT 和可預測的風格。

輕量對話、起草文件、支援側邊欄：GLM-5 或 DeepSeek。兩者都感覺靈活。DeepSeek 到第一個 token 略快；GLM-5 在跨會話中往往能保持一致的語調。
工具密集型助理：GPT-5。規劃能力和 schema 的穩定性能減少邊緣案例的卡頓。如果預算有限，先用 DeepSeek 製作原型，再在最關鍵的端點上換成 GPT-5。

批次處理 → ？

對於大型離線任務（數百到數千個項目）：

DeepSeek 在成本效益上勝出，前提是你能容忍小幅的風格漂移。請加入嚴格的輸出 schema 和差異檢查。
GLM-5 是穩定的預設選擇，適合在意較少異常值、並願意多付一點錢換取一致性的場景。
GPT-5 是殺雞用牛刀，除非任務確實需要更深入的推理或每個項目需要多跳檢索。當它確實需要時，重跑率的下降足以證明成本合理。

多模態管道 → ？

對於圖片加文字或音訊加文字的流程，銜接部分比說明書更重要。

GPT-5：在我的測試中，模態和工具之間的交接最為流暢。如果你的管道需要在提取、推理和生成之間跳轉，這種流暢感是值得的。
DeepSeek：快速且稱職。對於 OCR 加摘要或圖說加標籤，它保持了較低的延遲。
GLM-5：在結構化的圖片轉文字任務上可靠。如果一致性比創意更重要（想想發票解析或產品資料整理），我會優先選它。

一個設計注意事項：將中間結果串流到你的日誌中。這是在發佈前捕捉模態不匹配問題最簡單的方法。

WaveSpeed 在三者間的定價比較

我嘗試將 WaveSpeed 作為定價的健全性層——不是萬靈丹，只是一種更平靜地思考支出的方式。

讓我印象深刻的不是神奇的折扣，而是其中的機制：

固定路由：將 GPT-5 固定在需要其規劃能力的端點，將直接摘要任務發送給 DeepSeek，用 GLM-5 處理結構化編輯。一張帳單，更少驚喜。
情境快取：系統提示和工具 schema 不會在每次呼叫時重新傳送。在我的測試中，這平均減少了三分之一的輸入 token。這不光鮮，但卻是那種會積累起來的精簡。
邊緣護欄：如果模型偏離了 schema，WaveSpeed 會提早捕捉並用同一個供應商重試。工作中途不會有供應商輪盤賭。

在價格方面，比較很簡單：