Nanbeige4.3-33B 與 Gemma 4 31B：廠商表格中 33 個百分點的差距究竟代表什麼

在 Nanbeige4.3-33B 自家的基準測試表中，Gemma 4 31B 在 Terminal-Bench 4.0 上得分為 0.0。這一列正是你該先看的起點，因為它告訴你該如何解讀這份比較中的其他每一個數字。Gemma 4 31B 是 Google DeepMind 的 307 億參數開放權重版本，自 2026 年 4 月 2 日起可依 Apache 2.0 下載，而 Google 自家資料宣稱它在 τ²-bench 工具使用上達 86.4、在 LiveCodeBench v6 上達 80.0。這樣的模型不會在所有終端機任務上全盤失敗。當基準測試無法區分「做不到」與「從未拿到可運作的工具迴圈」時，你得到的就是零。

相較之下，Nanbeige4.3-33B 才問世兩天。其儲存庫建立於 2026 年 10 月 24 日 02:49 UTC，其模型卡是 Nanbeige 唯一發布的公告，而該模型卡上的 20 列表格，是現今所有關於它的流傳數字之唯一來源。Gemma 4 31B 在該表中作為三個比較欄之一出現。尚無獨立實驗室讓這兩個模型彼此對測，兩個廠商也都沒有在這張表之外互相進行基準測試。因此，這場對決的誠實版本並不是一張記分板，而是一場爭論：哪些列經得起檢視，哪些列其實是在測量測試框架。

每個模型實際上是什麼

這兩個版本相隔六個半月，而設計假設也反映了這一點。

• 參數 — Nanbeige4.3-33B 是 33.1B 稠密模型（BF16 格式下為 33,118,977,024 個參數），每個 token 都會啟用全部參數。Gemma 4 31B 是 30.7B 稠密模型。兩者皆非混合專家架構，因此雙方的吞吐量都隨完整權重數量而擴展。

• 上下文 — Nanbeige4.3-33B 原生支援 524,288 個 token。Gemma 4 31B 則為 262,144。兩者在同參數量級中都異常龐大；Nanbeige 更是其兩倍。

• 模態 — Nanbeige4.3-33B 為文字輸入、文字輸出，支援英文與中文。Gemma 4 31B 除了文字之外也能接受影像，並以 140 多種語言進行預訓練，同時原生支援函式呼叫與可設定的思考模式。

• 授權條款 — 兩者皆為 Apache 2.0。這是少見的比較，授權問題在你開始之前就已經有定論。

• 磁碟上的權重 — Nanbeige4.3-33B 在 BF16 下約為 66GB，在 4-bit 下約為 20GB。Gemma 4 31B 也落在同一區間。兩者都不是筆電級模型；它們都是單一工作站或單一節點等級的模型。

唯一不算接近的是分發。Gemma 4 31B 有託管 API、一個 Artificial Analysis 目前列為零成本的端點，以及獨立報導。Nanbeige4.3-33B 有權重、模型卡，而且——用模型卡自己的話說——沒有推理供應商部署它。這種不對稱不是品質評判，但它改變了「試用它」的成本。

供應商欄位與 Google 自家的卡片並不一致

Nanbeige 表格中的兩行可以與 Google 公布的數字核對，而其中只有一行吻合。

• AIME 2026 — Nanbeige 將 Gemma 4 31B 記為 89.2。Google 回報 89.2。完全一致。

• GPQA Diamond — Nanbeige 給 Gemma 4 31B 的成績是 91.3，而這是 Gemma 唯一勝過 Nanbeige 自家 89.5 的一列。Google 為該模型公布的数字是 84.3。這是有七分的落差，而兩份模型卡都未說明其背後的配置。

第二行值得注意，因為它是廠商表格中唯一讓對手勝出的地方。如果這個數字來自以最大思考投入重新執行的結果，那就是一項合理的結果，而 Gemma 在研究所程度的科學問題上確實領先。如果它來自設定不同的評估，那麼這張表比較的就是兩個不同的 Gemma。無論如何，本週每一篇二手報導都不斷重複的「Gemma 贏得 GPQA」說法，都建立在一個 Google 並未公布的數字上。

Gemma 欄位的其餘部分較難稽核，因為 Google 報告的是不同的基準測試。Nanbeige 的表格將 Gemma 在 Tau3-Bench 上列為 18.6；Google 的模型卡則將其列為在 τ²-bench 上的 86.4。這些是同一基準測試家族的不同版本，因此並不矛盾——但它們也不是同一種比較，而兩者之間 68 分的差距，正好合理估計了測試框架與版本選擇能讓單一模型的分數變動多少。

正確解讀零值

Gemma 欄中有三列接近零：Terminal-Bench 4.0 為 0.0、DeepSWE 為 2.7、SWE-Atlas-QnA 為 3.3。這些正是會在社群媒體上瘋傳的列，也是整張表中最不具資訊價值的數字。

在代理式基準測試上拿到接近零分，至少有三種可能原因：模型無法完成任務、模型無法操作測試框架提供的工具，或是測試框架是針對不同的對話範本與工具呼叫格式調校的。Nanbeige 的模型卡明確指出，其自身結果在 Terminal-Bench 2.1 使用 Terminus 2，在 Terminal-Bench 4.0、DeepSWE 和 SWE-Atlas-QnA 使用 mini-swe-agent v2.4.6。它並未說明 Gemma 4 31B 是獲得同樣的評測腳手架、並搭配它自己的工具呼叫格式，還是被放進 Nanbeige 那套以 XML 為導向的腳手架中。這兩種情況會產生截然不同的數字，而其中只有一種真正與模型有關。

這不是否定 Nanbeige 結果的理由。Nanbeige4.3-33B 是圍繞代理式編碼打造的——其模型卡建議使用 XML 工具呼叫格式、在多輪工具使用時設定 preserve_thinking=true，並在代理式任務中將溫度設為 1.0——因此它在專為其打造的測試框架中表現良好並不令人意外。這反倒是將 Gemma 欄位視為下限而非最終評斷的理由。

不對稱{{1}}基準{{/1}}不{{2}}定價{{/2}}：{{3}}圖像{{/3}}

Gemma 4 31B 可接收圖像。Nanbeige4.3-33B 則不行。這一句話比表格中的任何一列更能決定實際部署。

如果你的 agent 會讀取螢幕截圖、發票、圖表、掃描表單或 UI 狀態，那麼無論基準測試分數多高，Nanbeige4.3-33B 都不是候選方案。你需要在它前面再接一個獨立的擷取模型，而這個模型有自己的延遲、成本與失效模式；如此一來，整條管線的品質就會取決於擷取模型的品質，而不是 33B 的品質。Gemma 原生就能完成這一步，而 Google 公布的 MMMU-Pro 76.9 與 MATH-Vision 85.6 顯示它做這件事是有實力的，而不是行禮如儀。

相對地，如果工作是純文字性質——程式碼、日誌、長篇文件、多輪工具軌跡——圖像能力就是你在每次前向傳遞中都得付出成本的累贅。這正是 Nanbeige 所針對的情境，而這類情境佔代理式工作很大一部分。

512K 對上 256K，以及視窗的用途是什麼

Nanbeige 的 524,288 token 視窗是 Gemma 262,144 token 視窗的兩倍，而這兩個數字都大到只有在特定類型的工作中，差異才會有影響。

256K 視窗大約可容納中型儲存庫份量的原始碼，或數百頁文字。512K 視窗則可容納兩倍。對於單一長文件加上長回答，兩者都足夠；對於會在數百回合中累積工具輸出的代理，較大的視窗能讓你在摘要或淘汰之前獲得更多回合。Nanbeige 的規格卡建議推理與聊天最多使用 262,144 個新 token，這意味著實用推理預算更接近 256K，而非完整的 512K。Gemma 的輸出上限通常設定為 131,072。

兩家廠商都沒有在這裡公布長上下文召回基準測試，所以無法誠實地說誰的 512K 或 256K 能更有效地被運用。上下文大小是容量上的宣稱，而非品質上的宣稱，而兩張卡都僅止於此。

打給每一個要多少費用

在這兩者之中，Gemma 4 31B 是目前唯一能以服務形式呼叫的模型。在 OrcaRouter 上，每百萬輸入 token 為 $0.13、每百萬輸出 token 為 $0.38，快取輸入為 $0.02——這是對供應商牌價的直接轉嫁，未添加任何加成，這也是為什麼供應商價格一經公布變動，當天就會反映在我們的目錄中。Artificial Analysis 目前將 Google 自家的端點列為輸入 $0.00、輸出 $0.00，這幾乎可以肯定反映的是促銷或免費方案，而非長期價格；請將其視為試用管道，而不是預算項目。

Nanbeige4.3-33B 沒有可報的每 token 價格。權重依 Apache 2.0 免費提供，而模型卡指出沒有任何推論供應商部署此模型。要執行它，意味著依模型卡自身的 vLLM 與 SGLang 配方，以張量平行度 4 使用四張 GPU，且無論是否有請求進來都保持常開。那麼，一個 token 的邊際成本就是你的電費與你的使用率，而不是費率表。任何拿「$0.13 輸入」與「免費」相比的人，都是在拿帳單跟資本支出相比。

這也是即使新模型是自架部署，仍要在流程中保留路由器的實際理由。多數團隊真正面臨的決策不是「取代 Gemma」，而是「把 5% 的流量導向新方案，看看會發生什麼事」。讓現有系統可透過單一金鑰，並具備自動容錯移轉保持可達；一旦實驗端點失效，這就只是路由變更，而非遷移。

當 Gemma 4 31B 單純就是正確答案時

四個條件就能在沒有基準表的情況下解決這件事。

• 工作負載包含圖像、PDF 或螢幕截圖。Gemma，毋庸置疑。

• 你需要的不只是英文和中文。Gemma 是在 140 多種語言上預訓練的；Nanbeige 只列出兩種。

• 你不會想自行擁有 GPU。Gemma 目前已有託管端點；Nanbeige 則有權重和部署配方。

• 品質方面，你需要一份獨立的第二意見。Gemma 在 Artificial Analysis 智慧指數中拿下 15 分，這個分數不算高，但至少是獨立評測。Nanbeige 在那裡完全沒有列入評測，所以關於它的每一個數字，都是廠商自己在批改自己的作業。

反過來看，Nanbeige 的情況同樣清楚：純文字的代理式工作、冗長的工具追蹤記錄、擁有 GPU 的團隊，以及願意執行其建議的 XML 工具格式。在這類工作型態上，Nanbeige 自己的表格宣稱在 Terminal-Bench 2.1 上{{1}}領先 33.7 分{{/1}}——{{2}}80.9 對 47.2{{/2}}——並在 DeepSWE 上領先 62.8 分。這些差距大到即使扣除測試框架優勢，當中也可能含有真實訊號。但它們還沒大到讓你在未親自跑過的情況下，就把生產路徑押上去。

一場下午的烘焙比賽勝過這張桌子

如果你真的要在兩者之間做選擇，這個測試成本很低，而且不需要相信任一廠商。從你自己的代理日誌中取出二十個真實任務。以各自建議的工具呼叫格式與思考設定來執行每個模型——Nanbeige 用 XML，Gemma 用原生函式呼叫——並評估任務完成度，而不是基準測試相似度。記錄每個已完成任務所消耗的 token，因為稠密 33B 和稠密 30.7B 即使在每 token 價格相同時，冗長程度也會不同。

你在一個下午就能弄清楚的是：Nanbeige 的 agentic 優勢，是否能挺過它自身 harness 優勢的考驗。在有人發表那份結果之前，站得住腳的總結比新聞標題所呈現的更為狹窄：Gemma 4 31B 是更易於部署的模型，也是唯一擁有獨立評分的模型；Nanbeige4.3-33B 則是更有野心的那一個，具備原生 512K 視窗，以及一組自我報告的 agentic 數字——引人注目、未經審核，而且才問世兩天。