Granite Switch 4.1 30B：IBMが12個のアダプターを2つに削減

5か月前、IBMはHugging Faceに30B Granite Switchのプレビューを公開しました。内部には12個のアダプターがあり、ベースモデルに対して11.68%のパラメータ上乗せがありました。2026年10月14日、完成版モデルが登場しました——Granite Switch 4.1 30B——そしてアダプターはちょうど2つ、上乗せは3.89%です。目玉の数字は3分の2減り、それがこのリリースのすべてです。

「登場した」とは何を意味するのかを正確に言うと、多くの報道がずさんになるのはまさにこの点だ。重みは2026年10月14日にHubに公開され、IBM自身のローンチ記事であるGranite Switch 4.1：単一のエンドポイントからのチャット、意思決定、音声は10月15日に公開された。これは本稿を執筆している2日前にあたる。これは発表されたリリースであり、誰かがミラーで見つけたひっそりとしたドロップではなく、5月のプレビューの再掲載でもない——アーティファクトは異なり、アダプター数も異なり、音声パスはプレビューにはまったく存在しなかった。以下では、リポジトリから読み取れることと、IBMだけが述べたことを区別する。

チェックポイントには実際に何が入っているのか

Granite Switch 4.1 30Bは新しいアーキテクチャではなく、コンポジションです。これはGranite 4.1 30B — 密なデコーダ専用トランスフォーマー、131,072トークンのウィンドウ、100,352トークンの語彙 — を凍結し、2つのアクティブ化されたLoRAアダプタと音声エンコーダを追加します。ビルドマニフェストは重みの隣にリポジトリへチェックインされているため、以下のあらゆる構造的記述は報告されたものではなく読めるものになっています。

• guardian-core — aLoRA、ランク16、アルファ64、アテンション射影のみ（k_proj、o_proj、q_proj、v_proj）に適用され、Guardian Libraryから取り出され、有害性、ジェイルブレイク、冒涜的表現、暴力、性的コンテンツ、社会的バイアス、非倫理的行動を対象としています。制御トークン <|guardian-core|>、id 100352。

• decision — aLoRA、rank 64、alpha 128、MLP を含む7つすべての射影に取り付けられ、チャットよりも狭いことを実行するよう訓練されています。つまり、状態とラベル付きの選択肢を伴う質問が与えられると、1回のフォワードパスでそれらのラベルに対する較正された確率分布を返します。制御トークン <|decision|>、id 100353。

• 音声 — granite-speech-5.0-470m-turboctc。47億パラメータの非自己回帰型Conformer CTCエンコーダで、英語専用であり、2つ目のサービスとしてではなく音声入力パスとして組み込まれている。

重みの算術は、このリリースで最も明快な数字です。ベース: 28,865,728,512 パラメータ。合成後: 29,989,814,272。差は 1,124,085,760 パラメータ、つまり +3.89% です。制御トークンは自分で書くものではありません — チャットテンプレートが、あなたがadapter_name 引数を渡すときにそれらを挿入します。これは、能力の切り替えが2番目のデプロイではなくリクエストパラメータであることを意味します。

プレビュー版には12個のアダプターが搭載されていました。製品版には2個です。

これは理解する価値のある決定だ。なぜなら、一見すると後退のように見えるからだ。プレビューのチェックポイント——依然としてHub上にあり、依然としてApache-2.0で、2026年5月5日付——は、3つのGraniteライブラリから12個のアダプターを搭載している：引用、クエリ書き換え、クエリ明確化、ハルシネーション検出、回答可能性、事実性検出、ポリシーガードレール、事実性修正、guardian-core、不確実性、要件チェック、コンテキスト帰属。これは本当に有用なバンドルであり、同時に熟考を要するバンドルでもある。なぜなら、12個のアダプターは12通りの呼び出しレシピと12通りの異なる出力コントラクトを意味するからだ。

Granite Switch 4.1 30B はそのうち2つを保持し、音声エンコーダーを追加します。IBMが行ったトレードオフは、カバレッジと引き換えにした分かりやすさです。完成したモデルは、確率を伴って意思決定の質問に答えたり、音声を文字起こししたりもできるチャットモデルであり、これらは呼び出し元が一度に頭の中に保持できる3つのものです。残りの10個のアダプターがなくなったわけではありません — それらは依然として公開されており、依然として組み合わせ可能で、そして、そのコンポーザーはgranite-switchリポジトリ内で、12個すべてを含む、望む任意のサブセットでチェックポイントを構築してくれます。変わったのは、デフォルトで有効になって届くものだけです。

それは実際のコストであり、うやむやにするよりもきちんと名指しする価値がある。プレビューのハルシネーション検出アダプターとコンテキスト帰属アダプターが1.0チェックポイントに到達するのを待っていたのなら、これはそれではない。これはより狭いモデルで、オーバーヘッドはより低く、そのギャップを埋めるのはコンポジション・ツール群だ。

意思決定アダプターは、チャットモデルではないほうの半分です。

言語モデルから確率分布を読み取ること自体は目新しいものではない。固定された選択肢ラベルのセットに対して1回のフォワードパスでそれを行い、ルーティングできるほど十分にキャリブレーションされた数値を得る、という点こそが説明を要する部分だ。文書化されたレシピは、固定の意思決定エンジン用システムプロンプト、State:凍結されたベースで評価されるターン、次に### DECISION質問と単一トークンでラベル付けされた選択肢を提示するターンです。まさにそれらのラベルトークンIDのlogprobsを要求し、指数化します。カード自体の例では、A: 0.982、B: 0.0035、C: 0.014 のような値が返されます。そして興味深いのは、それらが分類器からではなく、通常の補完エンドポイントから得られたという点です。

発表が省略しているエンジニアリング上の厄介な点が一つある。logprob-token-id の仕組みは 1 リクエストあたり 128 個の ID が上限なので、128 を超える選択肢を持つ意思決定の問いは完全に失敗する。文書化されている修正策は、ラベル ID を 128 個ずつのチャンクに分割し、同一のプロンプトでチャンクごとに 1 リクエストを発行して連結するというものだ。これは上限なしの呼び出しと数学的に同一である。返される logprob は語彙全体にわたり、したがって各ラベルの値は、どのチャンクがそれを要求したかに依存しないからだ。128 個の選択肢ごとに追加リクエストが 1 つ。これは、リポジトリの内部にしか存在しない類の詳細である。

アダプターに紐づく唯一の公開数値は、Decision Index のエディション v0.3、1,068 行の公開ファストサブセットです: 総合 50.1、知識 32.4、言語 58.6、検索 49.8、ツール 76.5、芸術 26.4。見出しの数字ではなく、その形を読んでください — ツールの 76.5 が芸術の 26.4 の隣に並んでいるのは非常に不均一なプロファイルであり、このアダプターをどこに向けるのが安全かを、総合値よりもよく示しています。IBM はまた、アダプターをローカルでサービングした場合とホスト型 vLLM エンドポイント経由でサービングした場合が約 0.6 ポイント以内で一致したと報告しています。これは、IBM がその両方を実行したにもかかわらず、サービング経路に関する有用な健全性チェックになります。

音声テキスト化、そしてIBMが自社のカードに書き込んだ但し書き

音声パスは文字起こしを組み込みエンコーダーに通し、音声コンテンツパートの代わりにチャットコンテキストへ差し込む。そのため、音声付きのリクエストはinput_audioパートを伴う通常のチャット補完のように見える。2つ目の音声サーバーも、2つ目のレイテンシ予算も不要だ。

これらの制限はすべて、懐疑論者ではなくIBM自身のドキュメントに由来している。英語のみ、小文字で句読点なしの出力、デコード時のステアリングなし、そして——これはあなたの足を止めさせるべきものだが——音声エンコーダーと言語モデルは共同で訓練されていない。両者を結びつける訓練済みの射影は存在しない。したがって、誤転写はモデルまたは意思決定アダプターが反応する内容を変えうるが、パイプライン内の何もそれを指摘しない。転写エラーが結果を左右する何かを展開しているなら、その一文こそがあなたの脅威モデルのすべてである。

確認済み、ベンダー報告、未検証

• リポジトリで確認済み — ベースモデルの識別情報、両アダプターのランクと対象モジュール、制御トークンID、合成パラメータ数と+3.89%の差分、131,072トークンのウィンドウ、Apache-2.0ライセンス、および固定されたサポート範囲（Transformers 5.16–5.17、vLLM 0.26–0.28、PyTorch 2.11+）。

• ベンダー報告であり、再現されていない — Decision Indexの数値、Granite Speech 5.0 TurboCTCがOpenASRリーダーボード上で最速のASRモデルであるという主張、合成モデルがベースとほぼ同じVRAMを消費するという主張、Guardianアダプターが安全性関連タスクで名前の挙がった複数のクローズド意思決定モデルを上回るという断言、そしてローンチ投稿の余談で、カスタム3B Granite Switchビルドが報告されている毎秒10回に対して毎秒60〜100回の意思決定でDoomをプレイしたという話。IBMは「今後数週間で」さらなるデータが来ると述べており、これは今日の証拠が薄いことの認めである。

• 誰も確認していない——その他すべては。第三者による評価も、リーダーボードへの登録も、独立したレイテンシやスループットの測定も、ホストされたIBMエンドポイントもない。リポジトリにはいくつかの「いいね」が付いているだけで、執筆時点では実質的にダウンロード数はゼロ。公開から2日で、ほとんど読まれていない。

スタック内での位置づけ

Granite Switch 4.1 30B はセルフホストの話です。モデルカードには Hugging Face Transformers と vLLM が記載され、狭いバージョン範囲が指定されており、チェックポイントは変換なしで両方で動作します。マネージドエンドポイントはないため、実用的な最初のステップは GPU 1 台とコンテナです。

残りについては正直に言うと、現在OrcaRouterのカタログにGraniteモデルはない。だからこのチェックポイントが欲しければ、入手経路はIBMのリリースと自前のハードウェアだ。このプラットフォームが提供するのは、それを取り巻く意思決定、つまり1つのキーの背後に200以上のモデル、自動フェイルオーバー付き、プロバイダーの定価を0%のマークアップでそのまま提供——これがまさにこの状況で最も重要になる。独立した評価のない2日前のチェックポイントは候補であり、現行の採用モデルではない。候補に対して安上がりにできるのは、すでに本番稼働しているモデルの隣に置き、それを中心に本番経路を配線し直すのではなく、自社のトラフィックで比較することだ。

未解決の問題

Granite Switch の狙いは、特定の種類の作業——応答し、判断し、文字起こしを行うアプリケーション——では、構成が規模に勝るというものだ。そこでは3つのモデルが、3つのデプロイ、3つのレイテンシ、3つの請求を意味する。1つの KV キャッシュをアダプター間で共有し、そのために3.89%を支払うのは、まさに異例のエンジニアリングであり、このリリースの中で1年後もなお重要であり続ける部分だ。

確定していないのは、合成された回答が良いかどうかだ。decision adapter の公開プロファイルは不均一で、音声経路は英語のみで共同訓練もされておらず、モデルはできてから二日しか経っていないうえ、それを裏づける独立した実行もない。ビルドマニフェストを読み、自分のサブセットを構成し、誰かの 50.1 を信じる前に、自分のラベルセットに対して decision adapter をベンチマークせよ。