模型選型別只看規格表：GLM-5與Gemini 3.8 Flash實測

從402行日誌檢索、883行程式模組定位到月費估算，看兩款中價位模型在規格表之外的真實表現，以及這份數據不能回答的問題。

2026年10月，我把智譜的GLM-5和Google的Gemini 3.8 Flash放進同一套19題題庫跑了一遍。兩者價位接近，都是各自產品線裡拿來做批量任務的中檔模型，日常被互相替代。最顯眼的差異是上下文：200K對1.0M，相差五倍。

結果是19比17。但真正的發現不是這個分數——七個維度裡六個完全打平，全部差距來自兩處行為性失誤：一次沒答完，一次格式不符。決定勝負的不是能力，而是行為穩定性。而這兩處，都跟上下文容量無關。

兩款的規格差異

價位接近，但定位差很多：Gemini 3.8 Flash的上下文是對方的五倍，還支援圖片、音訊與影片輸入，並提供批量檔位；GLM-5只吃文字。單看規格表，這題似乎沒什麼好選的。

成績：前17題白測了

每一題都有可自動判定的驗收條件，判定只看模型最後交出的正文，中間輪次的試錯不計分。

兩處失分，都不是「讀不懂」

第一道：402行的日誌裡找金鑰

材料是402行、約1.4萬token的日誌，金鑰埋在第287行，要求把值原樣回答出來。

GLM-5在第4輪正常結束，正文就是那8個字元。Gemini 3.8 Flash用滿6輪上限，結束原因仍是tool_calls——它還在呼叫工具時就被切斷，最終正文是空的。

這處失分是「沒答完」，不是「讀不懂」。

第二道：883行的模組裡找末尾常數

材料是883行的Python模組，約3,500token，常數定義在最後一行，要求只回答數字。

它找到了，答案正確，甚至更快。但判定要求正文只有「17」這兩個字元，它寫成了一整句，20個字元。多寫的18個字元讓它從通過變成失敗。

按失敗原因，這一題該歸在「指令遵循」，不是「長上下文」。它的問題是沒壓縮輸出格式，不是讀不了長檔案。

一個容易讀錯的數字

指令遵循那道嚴格JSON的題目，兩個模型都通過，但輸出token差了3.35倍——85對285。

我第一反應是「Gemini比較囉嗦」。把兩邊正文調出來一看，都是20個字元的乾淨JSON，一模一樣長。

多出來的200個token在思考裡。API回傳的「輸出token」包含思考token，85裡有65是思考，285裡有265是思考。可見正文兩邊都是20。

所以「輸出token多」不能直接讀成「答案囉嗦」。跨模型比成本時，必須把思考拆開來看。

成本：便宜23%不是定價問題

官方牌價（2026年10月22日核對）：

一款輸入貴、一款輸出貴。實際跑完19題的帳單：

看起來Gemini便宜23.1%。但廠商公布的三檔工作負載估算，差距都只在10%以內——客服機器人約$176對$173、文件處理約$13對$12、編碼助手約$3.28對$3.00。

為什麼實測差這麼多？不是單價，是用量。 GLM-5這次消耗的輸入token是對方的兩倍（55,258對27,713），因為它真的把材料讀進去了。如果把用量拉平，兩個模型都用27,713輸入、13,034輸出：

• GLM-5：$0.0694
• Gemini 3.8 Flash：$0.0697

差0.4%，幾乎完全相同。

所以「便宜23%」的真實含義是：GLM-5為了把題做對，多花了將近一倍的輸入。任務讓模型讀得越多，這個差距越明顯；讀得少，兩者成本幾乎一樣。

另外兩個變數：快取讀取價差2.7倍（本次全部是獨立請求，一次都沒命中），以及Gemini有批量檔位而GLM-5沒有。

還有一個成本驅動因素藏在輪數裡。程式碼修復那三道題，GLM-5的輪數是4、4、4，Gemini 3.8 Flash是5、6、4。每一輪都要把前面的對話重新傳一次，所以輪數是乘在成本上，不是加在成本上——平均多0.4輪，在長任務上會被成倍放大。

這次測試不能說明什麼

它不能用來評價上下文容量。 兩道題的材料分別只有約1.4萬和3,500token，而兩款模型的標稱上限是200K和1.0M，差了一個數量級以上。要驗證「標稱五倍上下文優勢」成不成立，必須構造接近上限的輸入，這次沒做。

樣本也小。 長上下文只有2題，一次執行，沒有重複實驗。兩題的失利也可能是題型特例。

選型建議

給個人開發者：按你的情況查

給團隊與技術決策者：按順序做

兩款速查

一句話

這次實測最實際的結論是：如果你要把模型輸出直接餵給程式，先測格式約束，再談能力。 19道題裡，有一道是答案對了但分沒拿到。這種事在demo時看不出來，上線之後才知道。