Nanbeige4.2-3B vLLMサポート登場：BOSS直聘のループ型3Bエージェントモデルがフォーク専用時代を脱却

Nanbeige4.2-3B — BOSS直聘のNanbeige Labが2026年7月下旬にリリースしたコンパクトなエージェント型モデル — が、まもなく標準のvLLMインストール上で初めてサービス提供可能になろうとしています。2026年9月9日に開かれたプルリクエストは、transformersバックエンドを通じてvLLMのモデルレジストリにこのアーキテクチャを追加するものです。これがマージされれば、`vllm serve Nanbeige/Nanbeige4.2-3B` はベンダーフォークの儀式ではなく標準コマンドになります。これはセルフホスティングを行う人にとって実際の変化です。モデルが出荷されてからの6週間、そのモデルカードに記載されているすべてのサービングエンジン — vLLM、SGLang、llama.cpp、Ollama — は、未修正のインストールではなく、Nanbeige管理のフォークを指し示していました。

モデル自体がニュースなのではありません。7月最終週以降、ダウンロード可能になっていました。ニュースとは、フォーク専用の時代が終わりつつあり、それが今週終わるということです。SGLangは9月5日にNanbeige4.2のネイティブ実装をメインブランチにマージし、vLLMのプルリクエストは4日後にオープンされました。両者とも、あらゆるエンジンがこれまで特別扱いしてきたアーキテクチャに対する、アップストリームかつ標準インストールでのサポートです。以下では、すべてがラベル付けされています。プルリクエストが実際に行うこと、検証済みか未解決か、ベンダーのベンチマーク主張、そしてそれらを文脈に位置づける独立した数値が示されています。

今週、正確には何が変わったのか

vLLMのプルリクエストはvllm-project/vllm #56071、"[Model] Add support for Nanbeige4.2 (transformers backend)"で、9月9日にNanbeigeのエンジニアによってオープンされ、本稿執筆時点ではまだオープンのままです。これは意図的に小さく、2つのファイルのみです。1つ目はvLLMのモデルレジストリに、Hugging Faceのアーキテクチャ名NanbeigeForCausalLMをTransformersForCausalLMにマッピングする行を追加します。TransformersForCausalLMは、transformersバックエンドを通じてモデルを実行するvLLMの汎用フォールバックです。2つ目はNanbeigeModelArchConfigConvertorを追加します。その唯一の役割は、vLLMに何層分を割り当てるべきかを伝えることです。configのnum_hidden_layersにnum_loopsを掛けた値を返します。なぜなら、Nanbeigeのループ型トランスフォーマーがレイヤースタックを繰り返すため、vLLMはそれに応じてKVキャッシュとアテンションインスタンスのサイズを設定する必要があるからです。

この件を追跡している人にとって、レビュースレッドの2つの詳細が重要です。まず、レジストリのマッピングによって、モデルが自動的にtransformersバックエンドで実行されるようになります。vLLMのメンテナーは、マッピングが存在すれば、明示的な --model-impl transformers フラグは冗長になると指摘しました。また、マージ前に残る作業は、ドキュメントの追記とCIテストのレジストリマッピングです。次に、レビュアーは、最近マージされたvLLMの変更（PR #54941）によって、レイヤー数から推測するのではなくアテンションモジュールを直接検出するため、レイヤー数コンバーターが不要になる可能性があると指摘しました。簡単に言えば、修正はリリース前に複雑になるのではなく、よりシンプルになる可能性があります。

vLLMのパスがより重要であるのは、それが何でないかという理由による。これはNanbeige4.2をvLLMにネイティブに組み込もうとする最初の試みではない。同じエンジニアが7月下旬にデイゼロのネイティブ実装として開いたPR #49433は、メンテナが、特注のモデル実装はアーキテクチャに見合う以上の作業であり、代わりにtransformersバックエンドを指し示した後、transformersバックエンドのPRが登場したのと同じ9月9日にクローズされた。読者にとっての要点は、アップストリームのvLLMサポートは、手作業で調整されたネイティブ実装ではなく、互換性ルートによってもたらされるということだ。そして、その違いには、以下で説明する実際のパフォーマンス上の影響がある。

この特別な処理をすべて必要としたモデル

Nanbeige4.2-3Bがすべてのランタイムの前提を覆した理由を理解するには、このモデルが何であるかを知っておくと役立つ。これは約40億パラメータのモデルで、非埋め込みパラメータは30億、Apache-2.0ライセンスで英語と中国語で公開されており、コードエージェント、オフィス自動化、ツール使用、ターミナル操作といったエージェント型ワークロードに真っ向から照準を合わせている。技術レポート（arXiv 2607.22083、2026年7月24日付）には、28兆トークンによるスクラッチからの事前学習と、それに続く、実世界の環境との相互作用を中心に構築されたSFT＋3段階RLのレシピが記載されている。コンテキストウィンドウは262,144トークンに及ぶ。これらはすべて検証可能である。

普通でないのはアーキテクチャです。Nanbeige4.2-3Bは「Looped Transformer」を採用しています。同じ22層のTransformerレイヤースタックを2回実行するため、3Bパラメータのモデルでありながら、従来の3Bモデルと比べてトークンあたりの計算量が約2倍になり、重みは追加されません。これにより、少ないパラメータ数でありながら、その規模を超えるベンチマーク性能を実現しているのです。モデルは実質的に自身の表現をもう一度処理し、設定ではその再利用を22の隠れ層に対するnum_loops: 2として表現します（実効44段のアテンション段階）。代償として、すべての推論エンジンは、2回使用されるレイヤースタックの扱い方を指示される必要があります。KVキャッシュとCUDAグラフのためのアテンションのインデックス付け、キャッシュのサイズ設定、重みのストリーミング方法などです。1回のフォワードパスを前提とした標準エンジンは、これをどう扱えばよいか見当もつきません。そのため、カスタムモデリングコードはリポジトリ内に同梱され、Hugging Face Transformersでtrust_remote_code=Trueが必要となっています。

そのカスタムコードこそ、このモデルの最も粗削りな部分でもある。独立したレポート（arXiv 2608.13987、8月中旬）は、リリースされたチェックポイントがHugging Face Transformersでそのまま読み込めない原因となる5つのバグを記録している。その中には、暗黙にゼロ化された回転位置埋め込みバッファや、削除されたキャッシュAPIへの呼び出しが含まれる。また、コミュニティの投稿では、モデルを実行するにはuse_cache=Falseのような回避策が必要だと説明されていた。これらは修正可能であり、パッチ適用済みのチェックポイントとハーネスが現在流通している。しかし、重要なのはこのパターンである。これは巧妙なアーキテクチャでありながら、初日から展開時の摩擦という異例のコストを払い続けてきたのだ。

数字、ベンダー、および独立

技術レポートに直接記載された見出しとなるベンチマーク主張は、Nanbeige4.2-3Bが、より大規模なオープンモデルであるQwen3.5-9BやGemma4-12Bを、エージェント評価全体で上回るというものです。最有力の数字はSWE-Bench Verifiedで63.6、Qwen3.5-9Bの53.1、Gemma4-12Bの44.2に対するものです。レポートはまた、GPQA-Diamond 87.4、HMMT-Feb-2026 82.8、Terminal-Bench 2.0 44.1、SWE-Bench Pro 46.9も挙げています。これらのいずれも、ベンダーが選択したハーネス上で独立に再現されたものではなく、モデルカードがArtificial Analysisの小規模モデルリーダーボードの最上位に位置すると要約しているのと同じ、研究室自身によるモデル説明として読むべきものです。

これまでで独立した検証に最も近いものは、まったく別の面からもたらされる。8月下旬に公開された、iPhone 17 Proで実行されたArtificial Analysis × Liquid AIのオンデバイスベンチマークでは、Nanbeige4.2-3Bの4ビット版が、16Kコンテキストで、動作する33の8GB未満モデルの中で最高平均スコアに並んだ（63で、LFM2.5-2.6Bと同点、複数の9Bクラスモデルを上回る）。64Kコンテキストでは65を記録し、Ling 3.0 Tinyの66に次ぐ2位となった。そのテストごとのプロフィールは印象的だった。MATH-500で分野最高（96%）、関数呼び出し（BFCLで76%）で強い一方、AA-Omniscienceでは非幻覚率33%と弱く、そして実用上決定的なことに、遅い。毎秒およそ14トークンを生成し、1,024トークンのプロンプトに答えるのに21.4秒と4.0GBを要した。60秒の回答時間制限の下では、平均スコアは63から18に落ち込んだ。言い換えれば、9Bモデルを上回る品質は本物であり、それを生み出すループ型アーキテクチャのコストもまた本物だ。

アップストリームサポートで実際に得られるもの

この2つの上流イベントを合わせると、セルフホスターにとっての実践的な状況は明快です。SGLangを実行している場合、Nanbeige4.2-3Bは、統合されたmainブランチのサポートにより、標準インストールのまますでに利用できます。フォークは不要で、モデルのツール呼び出しパーサーと推論パーサーは、SGLangがすでに同梱しているqwen3検出器と同じものに接続されています。vLLMを実行している場合、標準サポートはマージ1つ先にあります。レジストリ行がモデルをtransformersバックエンドにルーティングし、アーキテクチャコンバーターがキャッシュを正しくサイズ調整し、qwen3の推論パーサーとツール呼び出しパーサーが再利用されます。これがOpenAI互換のツール呼び出しサーフェスの仕組みです。

率直に言えば、vLLMのルートは互換性のための経路であり、チューニングされたものではありません。NanbeigeForCausalLM を TransformersForCausalLM 経由で実行するということは、vLLM が独自カーネルと CUDA-graph 処理を備えたネイティブ実装ではなく、モデル自身の Hugging Face コードをサービング層の中で実行することを意味します。この違いこそ、SGLang がネイティブに構築することを選んだ点です。ループによってトークンあたりのコストがすでに2倍になっている3Bモデルにとって、transformersバックエンドのルートが最速のサービング経路である可能性は低く、また、基盤となるカスタムコードには5つのバグの履歴があるため、その経路はそこに残るどんな癖も引き継ぐことになります。エージェント型ワークロードでは、ツール呼び出しの正確性や長文コンテキストの挙動が、生の1秒あたりトークン数よりも重要であることが通常なので、これは許容できるトレードオフかもしれません。レイテンシーに敏感なチャットの場合は、本番経路として依存する前にベンチマークを取る価値があります。そして、2つのエンジンは依然としてフォークのみです。llama.cpp と Ollama は引き続き Nanbeige のブランチを参照しており、LM Studio に同梱された llama.cpp サーバーはまだこのアーキテクチャをサポートしていません。

次に見るもの

3つのことがそれぞれ状況を変えるでしょう。まず、vLLMのPRがマージされ、リリースに含まれる必要があります。スレッドとvLLMのリリースノートを注視してください。レビュアーは、マージ可能になる前にドキュメントエントリとCIチェックポイントのマッピングが残っているとすでに指摘しています。第二に、レイヤー数コンバーターがレビューを通過するかどうかに注目してください。メンテナーはPR #54941によってそれが冗長になった可能性があると考えているためです。これは、この回避策の多くがループアーキテクチャを囲む足場であることを示しています。第三に、ホスト型プロバイダーの問題に注目してください。現在、Hugging Faceのカードには、このモデルを提供する推論プロバイダーは表示されておらず、当社もホストしていないため、現時点ではこれはセルフホストの話です。プロバイダーがそれをリストアップすれば、ルーティング側は日常的なものになります。大きなモデルカタログにわたる単一のAPIで、プロバイダーのリスト価格をマークアップなしで透過的に渡すことは、自己ホストのNanbeige4.2-3Bを、それが打ち負かすと主張するホスト型モデルとA/Bテストするための低摩擦な方法です。それまでは、注目すべきマイルストーンはちょうど起こったものです。すべての主要なランタイムが肩をすくめ、フォークすることで迎えたローンチから6週間後、そのうちの2つが現在、変更されていないインストールからNanbeige4.2-3Bを提供しています。