TL;DR
- IBM が 2026年8月25日に Granite（グラナイト） 4.2 を公開した。3B / 8B / 30B の3サイズ、Apache 2.0。本記事は 30B を DGX Spark（NVIDIA GB10）でベンチマーク測定した。
- 先行して同じホスト・同じ測定手法で回した2本がある。
- 速度: 単発では他と横並び。並列を上げると一気に立ち上がり、c=16〜24 で頭打ちになる。
- 日本語知識（JamC-QA）: 34.6% で最下位。ただしこの数字は選択肢の位置バイアスに 汚染されており、額面通りには読めない。バイアスの機構は5通りの切り分けを試みても特定できなかった。
- コーディング（Aider Polyglot）: 非思考・temperature=0では11.1%で最下位。ただし、これはIBMが必須とするtemperature=1.0の外での測定だった。正式条件（フル思考・temperature=1.0・max_tokens=32768）で5題を追試したところ、try2で1題が合格し、4題は不合格。1題平均58分を要するため全225題の再測定は行っておらず、11.1%は正式条件での性能値ではない。
数字だけ見れば「速いが賢くない」だが、この記事で伝えたいのはむしろ、低い数字が出たとき、それをモデルの実力と断定するまでにどれだけの検証が要るかである。今回は5回検証して、なお断定できなかった。
1. Granite 4.2 の構造
Granite は IBM が自社で事前学習から手がけているオープンウェイトのモデル系列で、一貫して Apache 2.0 で出しており、その条件の下で商用利用できる。企業が自前の環境に置いて使うことを最初から想定した作りになっている。ソブリンAI の文脈で Gemma4 や Muse Glimmer と並べて検討されることになるだろう。
| 項目 | 値 |
|---|---|
| 種別 | decoder-only dense transformer |
| Attention | GQA、32 attention heads / 8 KV heads |
| 位置符号化 | RoPE（θ = 10,000,000） |
| FFN | SwiGLU |
| 正規化 | RMSNorm |
| コンテキスト | 128K ネイティブ（512K まで拡張可） |
| 学習量 | 15T トークン |
| ライセンス | Apache 2.0 |
dense であること — 速度の天井が決まる
dense とは、1トークン生成するたびに 30B のパラメータを全部読み出すという意味である。対して MoE（Mixture of Experts）はパラメータの一部だけを使う。比較群の Qwen3.6-35B-A3B は総パラメータ35Bだが、1トークンあたり動くのは 3B（A3B の "A" は active）。読み出す量が10分の1以下なので、同クラスのサイズでも桁違いに速い。
大規模 dense モデルの低バッチ decode では、主にメモリ帯域が律速になる。dense モデルは1トークン進めるたびに全重みを読み出すため、1本のストリームの速度は「帯域 ÷ 重みサイズ」を超えられない。DGX Spark の帯域 273GB/s を Q4_K_M の重み 18.03GB で割ると
273 ÷ 18.03 ≒ 15.14 tok/s
これが c=1・投機なしにおける、単純な帯域モデルによる理論上限である。§3 で dense 4本が団子になるのも、この天井を全員が共有しているからだ。
並列時はこの限りではない。1回の重み読み出しを c 本のストリームで共有できるため、集計スループットは最大 15.14 × c まで伸びうる（実際にどこまで伸び、どこで止まるかは §4 で見る）。MoE が速いのも、投機デコードが c=1 で上限を超えるのも、「1回の読み出しあたり1トークン」という前提を崩す仕組みだからで、同じ物差しの上にある。
この検算は割り算1回で済むわりに、異常検知の効果は大きい。実際、本測定の途中で c=1 と称して 62.53 tok/s という値が出たことがあり、上限の4倍という時点で即座に異常と分かった（原因は測定対象の取り違えだった）。想定外の数値を見たら、まずこの割り算に当ててみてほしい。
GQA の 32:8 — KVキャッシュが4分の1になる
GQA（Grouped Query Attention）は、32個の query head で8組の KV を共有する。KV キャッシュの必要量が単純計算で4分の1になる。同時に何本のリクエストを捌けるかは、KV キャッシュがメモリに収まるかで決まるので、これは並列処理に効く設計である。§4 で Granite の曲線が低並列域から一気に立ち上がるのは、ここが効いている可能性がある。
RoPE θ = 10,000,000 — 長文脈向けの設定
RoPE はトークンの位置情報を回転として埋め込む方式で、θ はその周期を決める。一般的な値は 10,000。Granite 4.2 は 1000倍 を使っている。低周波成分の回転が緩やかになり、長い文脈でも位置表現を維持しやすくなるため、128K ネイティブという仕様と辻褄が合う。
SwiGLU と RMSNorm — 標準装備
どちらも現代の LLM のほぼ標準で、Qwen も Gemma も採用している。特徴というより「奇をてらっていない」という情報として読める。なお Granite 4.0 世代には Mamba-2 ハイブリッドの h 系列が存在したが、4.1 以降の 30B 系列は dense に統一されており、4.2-30B は granite-4.1-30b-base からの後訓練である。
reasoning は3モードある
Granite 4.2 の目玉が、ネイティブ reasoning の 3モードである。
- フル思考（デフォルト）
-
非思考（
enable_thinking=False） -
低エフォート（
low_effort=True）— 簡単な質問への思考トークン量を少なく抑える
IBM は 4.2-30B を「フラグシップ推論モデル」と位置づけており、公表ベンチマークは思考有効での数字とみられる。本記事の測定は比較群と条件を揃えるため非思考で行った。 速度比較としてはそれが正しいが、品質軸ではこの選択が結果に効いている可能性がある。§6・§7 で思考モードでの追試にも触れる。
量子化版について
公式の FP8 / NVFP4 / MXFP4 / GGUF は、本プロジェクトの測定期間中に公開された。
着手時点では未公開だったため、測定はコミュニティ配布（bartowski、imatrix あり）で行っている。公開後、公式 GGUF Q4_K_M（17.72GB）と c=1 で突き合わせたところ
10.75 対 10.62 tok/s（+1.2%）で、系統差は測定誤差の範囲だった。品質面でも公式 GGUF で位置バイアスが同様に再現することを確認している（§6）。
2. 測定条件
| 項目 | 値 |
|---|---|
| ホスト | DGX Spark（NVIDIA GB10、128GB unified memory、帯域 273GB/s） |
| モデル | ibm-granite/granite-4.2-30b |
| 量子化 | GGUF Q4_K_M（bartowski/granite-4.2-30b-GGUF、18.03GB、imatrix あり） |
| エンジン | llama.cpp（着手時点の master 最新、commit 539f245） |
| reasoning | 非思考（§6・§7 の追試を除く） |
| temperature | 速度: 0.80（llama-server 既定）／品質: 0.0（後述の限界あり） |
| キャッシュ | 完全排除（--no-cache-prompt --cache-ram 0 --no-cache-idle-slots） |
-np |
各測定点の同時実行数に一致（充填率 100%） |
| クライアント |
vllm bench serve、ShareGPT 200 問 |
測定条件の限界を先に書いておく。 IBM は公式ドキュメントで temperature=1.0 を全タスクで必須と明記している。本記事の品質測定（JamC-QA、Aider）は temperature=0 で実施しており、これは公式仕様外の条件である。Aider についてはハーネスが未知モデルに temperature=0 を自動送信する仕様で、意図的な選択ではなかった。発覚後に temperature=1.0 での部分再測定を行い（§6・§7）、結果への影響を確認している。
なぜキャッシュを切るのか
llama-server は既定でプロンプトのプレフィックスや遊休スロットの KV を再利用する。ベンチマークに使う ShareGPT は似た形の会話が並ぶため、キャッシュが効くと TTFT が実際より短く出る。問題は歪み方がモデルごとに違うことだ。
| モデル | キャッシュ無効化での TTFT 変化 |
|---|---|
| Gemma4-31B | 8893ms → 587.6ms（15分の1） |
| Qwen3.8-27B | 2953.7ms → 485.6ms（6分の1） |
| Muse Glimmer 30B / MoE 勢 | ほぼ変化なし |
キャッシュを効かせたまま比べると、モデルではなくキャッシュとの相性を測ることになる。本記事の比較値はすべて取り直し後の値である。
3. 単発生成（c=1）— 全部横並び
| モデル | c=1 output tok/s |
|---|---|
| Muse Glimmer 30B | 11.90 |
| Granite 4.2-30B | 10.62 |
| Qwen3.8-27B | 10.51 |
| Gemma4-31B | 9.94 |
4本が 9.94 から 11.90 の間に収まる。 差は最大でも2割弱で、事実上の団子である。
§1 で見たとおり dense の速度は帯域で決まる。全員が同じ 273GB/s を似たサイズの重みで割っているのだから、差がつかないのは当然でもある。Granite の 10.62 は理論上限の 70%。c=1 の棒グラフだけ見て「どれも同じ」と結論すると、大事なものを見落とす。
4. 並列を上げると差が開く
| c | output tok/s | TTFT mean (ms) |
|---|---|---|
| 1 | 10.62 | 352.7 |
| 8 | 55.57 | 775.7 |
| 16 | 72.81 | 1119.5 |
| 24 | 84.88 | — |
| 32 | 73.57 / 76.19（再測定） | 2109.9 |
c=1 から c=8 で5.2倍、c=16 で6.9倍。c=16 以降は伸びが鈍化し、c=24 付近までに飽和域へ入る。 c=16〜32 の4点は 72.81〜84.88 の帯に収まり、c=32 の再測定差は 3.5%。ただし c=16 → c=24 は +16.6% で再測定差より明らかに大きく、「c=16 で完全に止まる」とまでは言えない。TTFT は c=16 から c=32 でほぼ倍増しており、スループットの伸びに対して待ち時間の悪化が先行する。c=24 が c=32 より高い山型については、200問を投げ切る終盤の「尾」の形が集計値に影響した可能性を考えているが、これは仮説であり、定常負荷での測定では未検証である。
なぜ飽和するのか
低並列域では、1回の重み読み出し（18GB）を全ストリームで共有できるため、c を増やせばほぼその分だけ集計値が伸びる（§1 の理屈の続き）。しかしストリーム間で共有できないコストもある。各ストリームは毎ステップ自分の KV キャッシュを読み出し、アテンション計算も本数分だけ増える。c が大きくなるほどこの「1本ごとのコスト」が積み上がり、どこかで重み読み出しではなくこちらが1ステップの時間を支配し始める。そうなると1本増やしても1ステップがその分遅くなるだけで、集計は増えない。これが飽和であり、TTFT だけが延び続けるのは増えた分が待ち行列に回るからだ。
Granite だけが早く飽和する理由は未検証だが、比較群との注意機構の違い——Muse は SWA（KV の参照窓が固定）、Qwen3.8 は線形アテンション主体（KV コストが小さい）、Granite はフルアテンション + GQA——とは整合的ではある。KV 由来のコストが相対的に重いモデルほど早く飽和するという仮説は、前記事の宿題（速度序列は注意機構の分類だけでは説明できない）への接続点になる。ただし本測定では機構を直接検証しておらず、比較群の c=16 が充填率未補正である点（§8）も差し引いて読んでほしい。
比較群と並べる
| モデル | c=1 | c=8 | c=16 | c=32 |
|---|---|---|---|---|
| Granite 4.2-30B | 10.62 | 55.57 | 72.81 | 73.57 |
| Muse Glimmer 30B（非投機） | 11.90 | 27.01 | 34.07 | 87.68 |
| Qwen3.8-27B | 10.51 | 14.46 | 17.20 | 46.21 |
低並列域では表面上 Granite が大きく上回る（c=8 で 55.57 対 27.01・14.46）。ただし §8 のとおり、比較群の c=8 / c=16 は -np 32 固定サーバでの値でスロット充填率が異なり（25%・50%）、Qwen3.8 では -np を一致させた追試で 10.88 → 37.50 に跳ねた実績がある。この倍率をモデル固有の性能差とは解釈できない。 条件を揃えた低並列比較は今後の課題とする。
一方、c=32は全モデルとも充填率100%であり、低並列域よりは比較条件が揃っている。ただしMuseはキャッシュ有効時の値を流用しているため、厳密な同条件比較ではない。 Muse 87.68 > Granite 76.19 / 73.57 > Qwen3.8 46.21。c=16→32 の伸びは Granite が実質ゼロ、Qwen3.8 +169%、Muse +157% で、飽和が早いのは Granite だけである（比較群の c=16 が未補正値のため伸び率は過大に出うる点は割り引いてほしい）。
何が言えるか
並列度を1点だけ測って優劣を語るのは危うい。 同じ測定でも、見る点によって順位が入れ替わる。そして条件（充填率）が1つずれるだけで倍率は2〜3倍動く。
運用上は扱いやすい性質でもある。 飽和域は c=16〜24 にあり、それ以上並列度を増やしても集計スループットは伸びず TTFT だけが悪化する。同時接続がその範囲に収まる社内利用なら見通しが立てやすい。ただし最適並列数はプロンプト長・出力長・TTFT 要件でも変わるため、16〜24 を目安に自環境で確認してほしい。
5. 量子化ラダー — どこまで上げられるか
DGX Spark(GB10) の 128GB unified memory に対して Q4_K_M（18GB）は余裕が大きい。どこまで量子化を上げられて、速度がどう落ちるかを bartowski 系列で測った（30問、c=1 / c=16 の2点）。
| 量子化 | サイズ | c=1 tok/s | 理論上限比 | c=16 tok/s |
|---|---|---|---|---|
| Q4_K_M | 18.03GB | 10.62 | 70.1% | (72.81) ※ |
| Q5_K_M | 21.03GB | 9.16 | 70.6% | 24.31 |
| Q6_K | 24.51GB | 7.91 | 71.0% | 21.81 |
| Q8_0 | 31.11GB | 7.01 | 79.9% | 18.06 |
| BF16 | 58.56GB | 4.02 | 86% | 15.33 |
※ Q4_K_Mのc=16のみ200問で測定した参考値。Q5_K_M以降の30問測定とは直接比較できない。c=16における量子化間の比較は、Q5_K_M〜BF16の範囲で読む必要がある。
面白いのは理論上限への到達率である。K量子化3水準（Q4/Q5/Q6）が 70〜71% で横一線なのに対し、Q8_0 は 79.9%、BF16 は 86% と、ビット幅が上がるほど単調に上限へ近づく。dequant 処理の複雑さが K量子化では同程度で、Q8_0（単純な per-block scale）・BF16（dequant なし）ほど計算オーバーヘッドが減って帯域律速に近づく、という説明が数値の並びと整合するが、機構の直接検証はしていない（仮説）。
実用上の結論は単純で、BF16 でも 128GB に収まり c=16 まで完走する（OOM なし）。ただし c=1 で 4.02 tok/s と Q4_K_M の4割弱なので、品質検証の基準点として使うもので、常用する速度ではない。なお、c=16のQ4_K_Mのみ200問、その他は30問で測定しているため、Q4_K_Mと他の量子化のc=16値は直接比較できない。
6. JamC-QA — 34.6% という数字を5回疑った
日本語知識を測るため JamC-QA（2,309問、4択、3-shot）を非思考で回した。
結果は 34.6%。
| モデル | JamC-QA accuracy |
|---|---|
| Gemma4-31B-IT | 61.28% |
| Gemma4-26B-A4B（MoE） | 58.08% |
| Qwen3.6-35B-A3B（MoE） | 55.26% |
| Qwen3.8-27B | 53.44% |
| Muse Glimmer 30B | 52.62% |
| Granite 4.2-30B | 34.6% |
次点から 18.0pt 下。4択の偶然は 25% なので、これは「知識が弱い」より「設問形式に乗れていない」ときに出る水準である。そのまま記事にする前に調べた。
懸念：選択肢の位置バイアス
| 記号 | Granite 選択率 | Qwen3.8 選択率 | 正解位置 | Granite 正答率 | Qwen3.8 正答率 | |
|---|---|---|---|---|---|---|
| 0 | 33.3% | 22.7% | 0 | 44.3% | 49.1% | |
| 1 | 12.3% | 24.6% | 1 | 19.9% | 52.1% | |
| 2 | 35.8% | 27.4% | 2 | 46.3% | 58.5% | |
| 3 | 18.5% | 25.3% | 3 | 27.9% | 54.0% |
Granite は選択肢を選ぶ位置に強い偏りがあり、選択率の谷と正答率の谷が一致している。同一データセット・同一ハーネスの Qwen3.8 は両方ともほぼ平らだ。選択肢の並び順をシャッフルすると accuracy はほぼ不変（30.0%→32.0%）なのに個別の正誤が20%入れ替わった。答えが内容ではなく位置に引きずられている直接証拠である。
そして5回の切り分けが、すべて空振りした
原因の仮説を立てては検証した。結果は以下の通り。
| # | 仮説 | 検証 | 結果 |
|---|---|---|---|
| 1 | 記号を出力させるのが悪い | 選択肢本文で回答させる（200問） | 26.0% に低下、先頭偏重はむしろ強まる |
| 2 | temperature=0 のせい | temperature=1.0（200問） | 28.0%、分布ほぼ同一 |
| 3 | imatrix 量子化のせい | 公式 GGUF で再測（50問） | 同じ先頭バイアスが再現 |
| 4 | 思考を切ったせい | フル思考 10問（temp=1.0） | 30.0%、非思考と同水準 |
| 5 | 思考量の不足 | 低エフォート 100問 | +3.0pt（誤差範囲）、コスト13.6倍 |
位置バイアスは、記号除去・サンプリング温度・量子化系統・思考モードのすべてに対して頑健だった。 再現性のある実在の現象だが、機構は特定できていない。当初の「記号1を避ける癖」という単純な説明も、後続検証で崩れた。
それでも言えること
34.6%は位置バイアスに汚染されており、モデルの日本語知識をそのまま表す値とはいえない。しかし、バイアスの影響が比較的小さい「選ばれやすい位置」（0・2）の問題でも、正答率は44〜46%で、比較群最下位の52.6%を下回った。34.6%を額面通りには読めない一方、日本語知識が比較群に対して劣位であるという方向性は変わらないと考えられる。
フル思考のコストも記録しておく。1問あたり平均 3.5分、非思考の 300〜600 倍。知識想起のタスクは思考トークンを増やしても動かなかった。2,309問への外挿は134時間となり現実的でない。
手法への教訓
選択肢の記号を選ばせる評価は、モデルの出力の癖に素通しで汚染されうる。JamC-QA に限らず MMLU 系の多肢選択ベンチマーク全般に同じ穴がある。今回は偏りが極端だったから気づけたが、数ポイントの汚染なら見逃していただろう。想定から大きく外れた測定値は、モデルの実力と断定する前に、まず測り方を疑う価値がある。
7. Aider Polyglot — 最下位。ただし評価条件に3つの留保あり
コーディング能力を Aider Polyglot（225題）で測った。pass_rate_1 = 1.8%、pass_rate_2 = 11.1%。
| モデル | pass_rate_1 | pass_rate_2 |
|---|---|---|
| Coder-480B | — | 57.3% |
| Qwen3.6-35B-A3B | 24.0% | 49.8% |
| Qwen3.8-27B | 15.6% | 47.6% |
| GLM-5.2 | — | 43.4% |
| Gemma4-31B-IT | 9.3% | 43.1% |
| MiniMax-M3 | — | 40.0% |
| DeepSeek-V4-Flash | — | 39.7% |
| Granite 4.2-30B | 1.8% | 11.1% |
比較群7モデル中、明確に最下位（次点比 −28.6pt）。出力形式は健全で（well_formed 98.7%、構文エラー0）、失敗の大半はアルゴリズムの中身の誤りだった。ただし、この数字には3つの但し書きが要る。
その1：公式仕様外の条件で測っていた。 IBM は temperature=1.0 を全タスクで必須と明記しているが、Aider は未知モデルに temperature=0 を自動送信する。225問すべてがこの条件で測られていたことが、測定後の点検で判明した。
その2：公式の想定ハーネスに Aider が入っていない。 IBM が agentic 用途で案内するのは OpenCode / Pi / OpenHands で、Aider は含まれない。実際 <tool_call> タグの漏出が2.2% で観測された。tool-calling を RL で特化学習したモデルが、プレーンテキストの差分編集規約と噛み合っていない可能性を示す一次証拠である。
その3：思考モードでは max_tokens の罠が待っていた。 フル思考 + temperature=1.0 で5題を追試したところ、max_tokens=8192 では3題が思考だけで max_tokens を使い切り、答えに到達しなかった。32768 に上げると枯渇は全て解消し、1題が try2 で合格（全診断を通じて初の合格例）。JamC-QA では 8192 で十分だったのに、コーディングでは思考＋コード全文が収まらない。max_tokens の教訓、シリーズ3例目である（Qwen3.8 記事・Muse 記事参照）。
ただし上限を広げても 4/5 題は不合格のままで、温度と max_tokens だけで 11.1% が説明できるわけではない。正式条件（フル思考 + temp=1.0 + 32768）は1問平均58分、全225題では8並列でも27時間規模になる。得られる情報量がこの投資に見合うとは考えにくく、正式条件での全題測定は行わないと判断した。本記事で言えるのは、非思考・temperature=0 という公式仕様外の動作点で、Granite のコーディングは比較群最下位だった。
8. 測定上の注意点
比較群の c=8 / c=16 は充填率が揃っていない。 先行プロジェクトは -np 32 固定で、c=8 は充填率25%、c=16 は50%。Granite 側は全点充填率100%。Qwen3.8 では -np 一致で 10.88 → 37.50 （+244.6%）に跳ねた実測があり、§4 の中間2点の差には設定差が混ざる。
Muse Glimmer の高並列側はキャッシュ有効時の値。 無効化の影響が c=1 で 1.4% と
軽微だったことを根拠に流用している。
Gemma4-31B は高並列データが存在しない。 先行プロジェクトでチャットテンプレート起因の異常値により c=4 で測定中止となったため。
c=16 / c=32 で 2〜3.5% の低確率失敗。 エラーログの残らない接続レベルの消失で、
4仮説（キャッシュ機構・タイムアウト・reasoning・HTTPスレッドプール）を反証したが真因未特定。成功分の分布に偏りはなく、他モデルの測定でも既知。
エンジンのビルドは各プロジェクトの着手時点の最新を使用（当ラボ方針）。比較群とはビルドが異なるが、同一イメージでの再測定実績から差は数%以内と見ている。
測定環境
DGX Spark（NVIDIA GB10、128GB unified memory、帯域 273GB/s）。測定中は同一ホスト上の他サーバをすべて停止し、/props によるモデル身元確認を全測定点で実施している。