Nanbeige4.3-33B 対 Granite 4.2 30B：主張 対 コンプライアンス

Nanbeige4.3-33B と Granite 4.2 30B のどちらを選ぶかは、リーダーボード上ではなく調達会議で決まる。どちらも Apache 2.0 のもとで提供される約300億パラメータの dense モデルで、今週ダウンロードでき、どちらも 512K トークンの上限をうたっている。しかし一方は IBM が署名済み成果物とサポート契約付きで販売しており、他方は中国の研究所による、公開から2日しか経っていないリポジトリで、ローンチ告知も出していない。IBM の Granite 4.2 30B は2026年8月25日に登場し、Nanbeige4.3-33B は2026年10月24日に Hugging Face に現れた。両者は同じ調達の競合相手というわけではない。だからこそ、この比較は慎重に行う価値がある。

以下は勝者ではない。ショートリストの論理だ。これらのモデルを実際に分ける4つの問い、それぞれの答えが依拠する証拠、そして証拠が見かけより弱い箇所を示す。

同じパラメータ数を身にまとう2つの製品

Granite 4.2 30Bは、IBMのGranite 4.2シリーズ（3B、8B、30B、すべて稠密モデル）の最上位モデルです。Granite-4.1-30B-Baseを基盤とし、約15兆トークン（うち約1兆トークンは合成コードトークン）で事前学習された後、8Bと30Bサイズにはエージェント型強化学習の段階が適用されています。3つの推論モード（thinking、non-thinking、low-effort）を備え、OpenAI形式のネイティブツール呼び出しに対応し、FP8および4ビットのビルドも提供されます。IBMは、granite_thinking_parserを含むvLLMとSGLangのネイティブサポートを挙げています。

Nanbeige4.3-33Bは、BOSS Zhipinを運営するKanzhun傘下のAIチームであるNanbeige LLM Labによる単一のdenseチェックポイントです。そのモデルカードはデプロイについて異例なほど具体的で、33.1Bパラメータ、524,288トークンのコンテキスト、英語と中国語、デフォルトでオンのthinking、JSONより推奨されるXMLツール呼び出し形式、マルチターンのツール使用を目的としたpreserve_thinkingフラグを挙げています。まだ出荷されていない小型の兄弟モデルNanbeige4.3-3Bのteacherモデルとして明示的に位置づけられています。

意図の違いは重要だ。Graniteはエンタープライズサポートへの道筋を備えた製品ラインだ。Nanbeige4.3-33Bは、ファミリーを生み出すために公開された研究用の成果物だ。一方は買われるために作られ、もう一方はそこから蒸留されるために作られている。

両方の研究室が実際に実行した唯一の行

Nanbeigeのカードは、自社をQwen3.8-27B、Muse-Glimmer-30B、Gemma 4 31Bと比較している。IBMのGraniteの資料にはNanbeigeについて一切言及がない。つまり、両方のカードが共有するベンチマークは、直接の対比が名目上でも可能なものがちょうど1つだけある。Terminal-Bench 2.1である。

• Terminal-Bench 2.1 — Nanbeige4.3-33B 80.9（Nanbeigeのカード）対 Granite 4.2 30B 29.24（IBMのカード）。Nanbeige有利の51.7ポイント差。

これはこの比較全体の中で、2つのベンダー表の間で主張されている最大の差であり、意味を持つ前に3つの注意点が必要だ。第一に、どちらの数値もベンダーによる報告である。第二に、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 の対応するものはありません。

同一のクレームではない2つの512Kクレーム

両モデルとも512Kという上限をうたっている。しかしそこへ至る道筋は異なり、その違いは各ベンダーが進んで公表した内容に表れている。

• ネイティブウィンドウ — Nanbeige4.3-33B: 524,288トークン（ネイティブ）。Granite 4.2 30B: 131,072トークン（ネイティブ）。

• 拡張された上限 — {{1}}Granite 4.2 30B{{/1}} は長コンテキストを 512K まで拡張できます。Nanbeige にはそれは不要です。512K が学習済みのウィンドウです。

• 長文コンテキストの根拠 — IBMは128KでRULERを公開：81.38。NanbeigeはAA-LCRを84.0で公開しており、これは長文コンテキスト推論ベンチマークだが、指定された深度でのリコールベンチマークではない。

• 出力 — Nanbeige のカードでは、推論とチャットには最大 262,144 の新規トークン、エージェントおよびツール使用の作業には 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側の証拠がより薄いということです。

規制されたプロセスの外にあるチームにとって、このセクションは無関係なので飛ばしてかまいません。そのプロセスの中にあるチームにとっては、ベンチマークを読む前に問いの決着を左右する可能性があります。

トークンにかかるコストと、GPUにかかるコスト

Granite 4.2 30B はマネージド API として利用可能で、入力トークン100万あたり0.16ドル、出力トークン100万あたり0.65ドル、キャッシュ割引75%、おおよそ毎秒47.5出力トークン、最初のトークンまでの時間は0.82秒です。Artificial Analysis は、そのコストを Intelligence Index タスクあたり約0.07ドルと推定しています。重みもダウンロード可能で、BF16 で約60GB、8-bit で30GB — 単一GPUでのデプロイです。

Nanbeige4.3-33Bには公開されたトークン単価がありません。ホストしている人がいないからです。モデルカードには、このモデルをデプロイしている推論プロバイダーはないとはっきり書かれています。セルフホストする場合、BF16で約66GB、4ビットならおよそ20GBが必要で、ベンダー自身のレシピではテンソル並列サイズ4を使用しています。つまり、トラフィックが来ても来なくても、4台のGPUを常時確保しておくことになります。

2つの数字を正直に並べてみると、比較はゼロから始まる従量課金の請求額と、4台のGPUから始まる設備投資の間で行うことになる。低い利用量では、Graniteの方が桁違いに安い。継続的な高利用量なら、セルフホストの33Bが勝ち得る——ただし、ハードウェアを償却できるほど利用率が高く、かつエンジニアリング時間をゼロと見積もる場合に限る。ほとんどのチームは、それがゼロではないと気づく。

どちらのモデルも私たちのルーターには載っておらず、そのことは率直に言う価値があります。

OrcaRouterは現時点でNanbeige4.3-33BもGranite 4.2 30Bも提供していません。そうでないふりをするつもりはありません。どちらかのモデルを期待して登録した読者が、カタログにそれが存在しないと気づくまでに一日を無駄にしてしまうからです。

ルーティング層が依然として果たしているのは、意思決定の残りの部分を安く保つことです。既存のモデルを当社のエンドポイント経由ですでに運用しているなら、同じキーの背後にセルフホスト型の Nanbeige を追加し、トラフィックの一部をそこへ流すのは、二つ目の統合ではなく設定変更です。プロバイダーの定価をそのまま通す当社の0%マークアップモデルにより、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なしで始める必要があるなら：{{1}}IBMのAPI経由のGranite 4.2 30B。{{/1}} {{2}}Nanbeigeにはホスト型のオプションがまったくありません。{{/2}}

居心地の悪い要約になるが、これらのモデルは同クラス内で十分に近く、判断は51ポイントのその行ではなく、調達、導入、言語、モダリティといった周囲の制約によって下されることになる。その行は実際に正しい可能性が十分にある。だが、それはこの記事で最も検証しにくい主張でもあり、モデルを選ぶ理由としては最初ではなく最後にすべきものだ。