Nanbeige4.3-33B 與 Granite 4.2 30B：宣稱與合規之比較

Nanbeige4.3-33B 與 Granite 4.2 30B 之間的抉擇，會在採購會議上做出，而不是在排行榜上。兩者都是約 300 億參數的稠密模型，皆採用 Apache 2.0，本週都能下載，也都宣稱具備 512K 個 token 的上限。但其中一款由 IBM 銷售，附有簽署過的產出物與支援合約；另一款則是來自中國實驗室、兩天前才出現的儲存庫，且該實驗室尚未發布推出公告。IBM 的 Granite 4.2 30B 於 2026 年 8 月 25 日推出；Nanbeige4.3-33B 則於 2026 年 10 月 24 日現身 Hugging Face。它們其實並不是同一筆採購案中的真正競爭對手，而這正是為什麼值得審慎比較。

以下內容不是在選出一個勝出者，而是一套篩選邏輯：真正能把這些模型區分開來的那四個問題，每個答案所憑藉的證據，以及證據比表面看來更薄弱的地方。

兩款產品披著相同的參數量

Granite 4.2 30B 是 IBM Granite 4.2 系列中的頂規型號，該系列包含 3B、8B 與 30B，全數為稠密模型。它建構於 Granite-4.1-30B-Base 之上，以約 15 兆個 token 進行預訓練，其中包含約 1 兆個合成程式碼 token，隨後再針對 8B 與 30B 規模加入代理式強化學習階段。它提供三種推理模式（思考、非思考、低投入），以 OpenAI 格式原生支援工具呼叫，並提供 FP8 與 4 位元版本。IBM 列出對 vLLM 與 SGLang 的原生支援，包括 granite_thinking_parser。

Nanbeige4.3-33B 是 Nanbeige LLM Lab 推出的單一稠密權重檢查點（dense checkpoint）；該實驗室是看準（Kanzhun）旗下的 AI 團隊，而看準正是 BOSS直聘的母公司。其模型卡對部署條件的說明異常具體：33.1B 參數、524,288 個 token 的上下文、支援英文與中文、預設開啟思考模式、建議採用 XML 而非 JSON 的工具呼叫格式，以及一個針對多輪工具使用所設計的 preserve_thinking 旗標。它被明確定位為較小型同系列模型 Nanbeige4.3-3B 的教師模型，而後者尚未發布。

意圖上的差異很重要。Granite 是一條具備企業支援途徑的產品線。Nanbeige4.3-33B 則是為了孕育一個家族而釋出的研究產物。前者是為了被購買而打造；後者則是為了被蒸餾而打造。

兩個實驗室實際上都執行過的那一列

Nanbeige 的模型卡將自身與 Qwen3.8-27B、Muse-Glimmer-30B 和 Gemma 4 31B 相比。IBM 的 Granite 資料完全沒有提到 Nanbeige。因此，這兩份模型卡恰好只有一個基準測試，連名義上都有可能進行直接對比：Terminal-Bench 2.1。

• Terminal-Bench 2.1 — Nanbeige4.3-33B 80.9（Nanbeige 的模型卡）對上 Granite 4.2 30B 29.24（IBM 的模型卡）。Nanbeige 領先 51.7 分。

這是整份比較中，兩張廠商表格之間所宣稱的最大差異，但在它具有任何意義之前，需要先提出三個注意事項。第一，這兩個數字都是廠商自行報告的。第二，Nanbeige 的說明卡指出其 Terminal-Bench 2.1 執行使用了 Terminus 2；IBM 的說明卡則未說明其使用的外圍框架。第三，終端機基準測試衡量的是模型加上代理迴圈，而 51 點的差距可能來自迴圈，也可能同樣輕易地來自權重。一個搭配良好調校測試框架的模型，和一個搭配現成框架的模型，在同一個名義基準上就會相差數十點。

下一個最接近的共同評測列是 GPQA Diamond：Nanbeige 回報 89.5，IBM 回報 66.41。這是知識基準上的一項真實差距，而且差距夠大，足以不受評測框架差異影響；但它衡量的東西也不同於代理式編碼——是研究所程度的科學問題，而非長時程工具使用。這表示在此證據下，Nanbeige 是兩者中較強的推理者。這並不表示它是較強的代理。

其餘項目皆無從比較。Nanbeige 報告 SWE-Bench Pro 為 60.3；IBM 報告 SWE-Bench Verified 為 57.00——兩者版本不同，難度也不同。Nanbeige 報告 AIME 2026 為 95.2；IBM 報告 AIME25 為 89.17——兩者年份不同。Nanbeige 報告 JobBench 與 DeepPlanning；IBM 報告 τ³-bench 62.00、BFCL v4 61.39、MMLU-Pro 77.60、LiveCodeBench v6 75.77 以及 RULER 128K 81.38。上述這些項目在 Nanbeige 都沒有對應的結果。

兩項 512K 的主張，而它們並非同一項主張

兩款模型都標榜 512K 的上限。它們達到這個上限的方式不同，而這差異也體現在各家廠商願意公開的內容上。

• 原生視窗 — Nanbeige4.3-33B：524,288 個 token，原生支援。Granite 4.2 30B：131,072 個 token，原生支援。

• 擴充上限 — Granite 4.2 30B 提供長上下文擴充至 512K。Nanbeige 並不需要；512K 就是訓練視窗。

• 長上下文證據 — IBM 公布 RULER 於 128K：81.38。Nanbeige 公布 AA-LCR 為 84.0，這是一項長上下文推理基準，但並非在指定深度下的召回基準。

輸出 — Nanbeige 的模型卡建議推理與對話最多可使用 262,144 個新 token，代理式與工具使用工作則為 65,536 個。IBM 建議的 max_new_tokens 在思考模式下為 8,192，在非思考模式下為 2,048。

最後那句話才是實務上的重點。512K 輸入視窗搭配 8K 輸出建議，是為了大量閱讀、簡短回答而打造的模型。512K 視窗搭配 262K 生成預算，則是為了產出長篇成品而打造的模型。如果你的工作是「吸收整個儲存庫、寫出遷移方案」，那麼即使名義上下文長度相同，它們也不是等效的產品。

工具呼叫、思考模式與整合稅

Granite 的工具呼叫採用 OpenAI 格式且為原生支援，在 IBM 自家評估中，BFCL v4 達到 61.39。這表示它能直接接入標準的函式呼叫客戶端，無須自訂解析器。IBM 也為 vLLM 發布了思考解析器，因此推理軌跡能與答案清楚分離。

Nanbeige4.3-33B 採取相反做法：它建議設定 tool_call_format="xml" 以獲得最佳效能，隨附 ChatML 風格模板，並要求你在 vLLM 或 SGLang 中使用 Qwen3 reasoning parser 與 Qwen3-Coder tool parser。這不是缺陷——許多強大的代理模型都使用 XML 工具呼叫——但這是整合工作。如果你的技術堆疊使用 OpenAI 工具 JSON，Nanbeige 需要一個轉譯層，或使用其 JSON 模式；模型卡表示該模式受支援但非首選。

這是基準測試表從未呈現的成本代價。一個在你必須重建的評測框架上高出 20 分的模型，到了星期二並不會真的高出 20 分。Granite 在這裡的優勢不在於能力；而在於其串接方式有文件記載、符合標準，並由擁有錯誤追蹤系統的供應商所支援。

合規專線

IBM 交付 Granite 時，附上密碼學簽章、ISO 認證與透明度揭露。對受監管的買方而言，這不是行銷話術——而是模型能否走完核准流程的關鍵差異。IBM 同時也是交易對手：有合約、有支援管道，還有一家在採購週期時程內依然存在的公司。

Nanbeige4.3-33B 採用 Apache 2.0 授權，在法律上屬於寬鬆型授權，可作商業使用。它沒有企業支援合約、沒有簽署產物的計畫，除了模型卡之外也沒有公布資料來源聲明。該實驗室隸屬於 Kanzhun，一家中國上市公司，而該模型支援中英雙語。這些都不構成不合格的理由。但這些全都是安全審查會追問的事項，而今天誠實的答案是：在 Nanbeige 這一邊，證據較為薄弱。

對於不在受監管流程內的團隊，本節與你無關，可以略過。對於身處受監管流程內的團隊，這一點可能在讀取基準測試結果之前就已決定問題的答案。

一個 token 的成本，以及一張 GPU 的成本

Granite 4.2 30B 可透過受管 API 使用，每百萬輸入 token 收費 $0.16、每百萬輸出 token 收費 $0.65，並提供 75% 快取折扣，輸出速度約每秒 47.5 個 token，首個 token 時間為 0.82 秒。Artificial Analysis 估計其每項 Intelligence Index 任務的成本約為 $0.07。權重也可下載，BF16 格式約 60GB，8 位元格式約 30GB——可單一 GPU 部署。

Nanbeige4.3-33B 沒有公布的每 token 價格，因為沒有任何人託管它。模型卡明白指出，沒有任何推論服務供應商部署此模型。自行託管代表在 BF16 下約需 66GB，或在 4 位元下約需 20GB，而廠商自家的做法是使用張量平行大小 4。這代表無論是否有流量進來，都得讓四張 GPU 保持開啟。

把兩個數字誠實地並列來看，這是在拿一張從零起算的按量計費帳單，與一筆從四張 GPU 起算的資本支出相比。在低用量下，Granite 便宜了一個數量級。在持續高用量下，自架的 33B 確實可能勝出——但前提是使用率高到足以攤提硬體成本，而且前提是你把工程時間的價值算作零。大多數團隊最後發現，它並不是零。

這兩個模型都不在我們的路由器上，而這一點值得直說。

OrcaRouter 目前並未提供 Nanbeige4.3-33B 或 Granite 4.2 30B。我們不會假裝並非如此，因為若讀者衝著這兩款模型之一而註冊，卻發現目錄中根本沒有它，就會白白浪費一天。

路由層仍然做的，是讓其餘決策維持低成本。如果你已經透過我們的端點運行某個現有模型，那麼在同一把金鑰後方加入自架的 Nanbeige，並把一部分流量導給它，只是設定變更，而不是第二次整合。我們的零加成模式——按供應商定價原樣傳遞——也意味著當 IBM 或其他託管商調整 Granite 價格時，你看到的數字會隨之變動，而不是落後於轉售商的利潤之後。這並不會讓其中任一模型變得可用；它只是讓圍繞這些模型的實驗執行起來更便宜。

一份入圍名單，而不是一位贏家

• 如果你需要合約、簽名與支援管道：Granite 4.2 30B，基準測試差距就不再重要了。

• 如果你需要這個尺寸級別中號稱最強的代理式編碼效能：Nanbeige4.3-33B，但要注意的是，它在 Terminal-Bench 2.1 上的 80.9 分從未在其自家模型卡之外被重現。

• 若你需要原生 512K 輸入並搭配長輸出：Nanbeige4.3-33B。Granite 透過擴展達到 512K，並建議輸出為 8K。

• 若你需要中文：兩者都有列出。Granite 的模型卡在 12 種語言中列出了中文；Nanbeige 則列出英文與中文。語言不是這裡的決勝因素。

• 如果你今天需要在沒有 GPU 的情況下開始：透過 IBM 的 API 使用 Granite 4.2 30B。Nanbeige 完全沒有託管選項。

令人不安的總結是：這些模型在同級別中已經足夠接近，因此決定將取決於它們周遭的限制條件——採購、部署、語言、模態——而不是那 51 分的一列。那一列很可能確實是真的。它同時也是本文中最難以驗證的一項說法，而且它應該是你選擇模型的最後一個理由，而不是第一個。