明日のAI 用語集
JA

← ノートに戻る

まとめ · 第IV章

七つの道筋はどう組み合わさるか

ここまで私たちは、道筋を一つずつ調べてきました。けれども明日のAIは、それらをいっしょに使うはずです。問いは単純ですが、答えはそう単純ではありません。節約は足し合わさるのでしょうか、それとも互いの足を引っぱるのでしょうか。

有望 更新日

I

考え方をかんたんに

レオナルドの工房を思い浮かべてください。疲れ果てずにより多くの絵を仕上げるには、まず弟子に仕事を任せ(まず小さなモデル)、必要な専門家だけを呼び(専門家)、すべてを手で描かずに型を使い(プログラム)、顔料を少なめにすり(ビットを減らす)、道具を替え(機械)、親方に見直してもらい(検証)、手本を頭ではなく帳面にしまっておく(別のメモリ)ことができます。

どの工夫も費用の別の部分に取り組んでいます。だから積み重ねられると期待できるのです。でも、互いに触れ合ってもいます。結果を誰も確かめなければ型は役に立たず、弟子が多ければ工房の場所を取ります。図で21組のペアを一巡りします。

図L — 誰が誰を助けるか

  1. 1 専門家
  2. 2 まず小さなモデル
  3. 3 プログラム
  4. 4 ビットを減らす
  5. 5 機械
  6. 6 検証
  7. 7 別のメモリ
  • + 足し合わさる (10)
  • − 邪魔し合う (2)
  • ± 両方 (2)
  • · 無関係 (7)
  1. 専門家 × ビットを減らす:gpt-ossは専門家を4ビットで保存し、GPU1枚に収まります。
  2. ビットを減らす × 機械:NorthPoleは重みをチップ上に置いたまま、言語モデルを4ビットで動かします。
  3. 専門家 × 機械:専門家が多ければ置くべき重みも多く、内蔵メモリのチップにはその余裕がほとんどありません。
  4. ビットを減らす × 検証:長い推論では丸め誤差が積み重なります。

説明用の図です。考え方を示すもので、測定値ではありません。

七つの道筋からは21組のペアができます。各マスは、二つの道筋が助け合うか(+)、邪魔し合うか(−)、両方か(±)、関係がないか(·)を示します。これは筆者の読みで、ノートで引用した研究にもとづいています。二つの道筋を同時に試した研究は少なく、混ぜたときにそれぞれがどれだけ効いたかを測った研究はほとんどありません。
II

一つの質問の道のり

七つの道筋をすべて使うシステムの中を、一つの質問について行ってみましょう。1. 振り分け役が質問を見ます。プログラムがすでに答えられるなら(計算や単位の換算など)、それを呼びます。ほとんどただです。

2. そうでなければ、小さなモデルが答えます。少数だけが動く専門家でできていて、重みは4ビット、その重みを計算のすぐそばに置くチップで動きます。3. 事実が必要なら、重みに頼るのではなくメモリで調べます。

4. 答えは検証を通ります。コードならテスト、そうでなければ、いくつもの単語を一度に確かめる大きめのモデルです。5. 検証に失敗したときだけ、質問は大きなモデルへ上がります。どの段階でも、満額を払うのは必要なときだけです。

III

足し合わさるもの

四つの組み合わせは、実際のシステムですでに働いています。共通点は、二つの道筋が別々の要因に効くことです。だから一方が他方の利得を食いつぶしません。

確立

専門家+ビットを減らす:gpt-ossとKimi K2 Thinking

専門家は計算するモデルの割合を減らし、4ビットは重み一つひとつの大きさを減らします。この二つは積み重なります。gpt-ossは1,170億のパラメータのうち51億だけを動かし、専門家を4ビットで保存しているので、80GBのGPU1枚に収まります。Kimi K2 Thinkingは1兆パラメータの規模で同じことを行い、生成は約2倍速くなりました。

出典: OpenAI, gpt-oss-120b & gpt-oss-20b Model Card (2025), Moonshot AI, Kimi K2 Thinking (2025)

有望

ビットを減らす+新しい機械:NorthPole

重みをその場に置くチップは、メモリが少なめです。4ビットの重みは16ビットの4分の1の場所しか取りません。こうしてIBMは、30億パラメータのモデルを16枚のNorthPoleカードで、1単語あたり1ミリ秒未満で動かしました。圧縮がなければ、モデルはチップに収まらなかったでしょう。

出典: IBM Research, NorthPole LLM inference (2024)

確立

プログラム+検証:AlphaEvolveとShinkaEvolve

プログラムは確かめるのが簡単です。動かして測ればよいのです。だからこそ、モデルに何千もの案を出させて、最良のものだけを残せます。AlphaEvolveはそこから、より短い行列の掛け算と、Googleの計算資源0.7%の回収を引き出しました。ShinkaEvolveは150回の試行で記録を破っています。

出典: Google DeepMind, AlphaEvolve (2025), Lange et al., ShinkaEvolve (ICLR 2026)

確立

まず小さなモデル+検証:投機的デコーディング

いちばん完成度の高いカスケードは、検証でもあります。小さなモデルがいくつかの単語を提案し、大きなモデルが一度でまとめて確かめます。最終的な文章は大きなモデルが書いたものとまったく同じですが、2〜3倍速く、EAGLE-3では最大6.5倍速く出てきます。

出典: Leviathan, Kalman & Matias, Speculative Decoding (ICML 2023), Li et al., EAGLE-3 (2025)

IV

邪魔し合うもの

研究には三つの摩擦がくり返し現れます。二つの道筋が同じ資源を引っぱり合うときに起こります。メモリ、精度、そして審判をどこまで信頼できるかです。

有望

多数の専門家と、少ないメモリ

専門家混合モデルは少数しか動かしませんが、全員を手元に置いておく必要があります。内蔵メモリの速いチップには、その余裕がほとんどありません。Taalasが刻み込むのは80億パラメータのモデルで、1兆パラメータのモデルではありません。統合スケーリング則はこの対立をやわらげますが、解決はしません。最適な専門家の数は、使えるメモリによって決まります。

出典: Ludziejewski et al., Joint MoE Scaling Laws (ICML 2025), heise online, Taalas announces HC1 chip (2026)

確立

ビットを減らすことと、長い推論

書かれる単語はそれぞれ前の単語にもとづくので、小さな丸め誤差が広がっていくことがあります。長く推論するモデルほど、その影響を受けやすいのです。Moonshot AIは、Kimi K2 Thinkingでは学習中に4ビットを身につけさせる必要があったと説明しています。そして、いちばん圧縮したいはずのよく学習したモデルほど、もろいのです。

出典: Moonshot AI, Kimi K2 Thinking (2025), Ouyang et al., Low-Bit Quantization Favors Undertrained LLMs (ACL 2025)

確立

振り分けと信頼

カスケードの価値は審判しだいです。振り分け役はわざとだまされて、すべてを高いモデルに送らされることがあります。同じ条件で比べると、多くの振り分け役はいちばん単純なやり方をかろうじて上回るだけです。段を重ねるほど信頼できる審判が多く必要になり、審判は一人ひとりが攻撃の新しい入り口になります。

出典: Shafran et al., Rerouting LLM Routers (2025), Li et al., LLMRouterBench (Findings of ACL 2026)

V

利得は掛け算になるのか

紙の上では魅力的です。道筋ひとつごとに費用が半分になるなら、七つで2⁷=128分の1になります。これが私たちの仮説H6の考え方で、確からしさは35%と見ています。

けれども、アムダールの法則という単純な規則が熱を冷まします。仕事の一部を速くしても、効くのはその部分だけです。あくまで説明用の例です。大きなモデルが総費用の半分を占め、それを10分の1の費用にしても、総費用は90%ではなく45%しか下がりません。100から50+5=55になるだけです。

つまり、道筋が費用の別々の部分をねらうとき(専門家とビット)は利得が掛け算になり、同じ部分をねらうときは重なり合います。大きなモデルを避けるカスケードは、その大きなモデルが専門家のおかげですでに安くなっていれば、節約の効果が小さくなります。私たちの読みでは、組み合わせれば一つの道筋よりはるかに大きな効果がありますが、一つずつの利得を掛け合わせた値にははっきり届きません。まだ誰もきちんと測っていません。

VI

このまとめが言っていないこと

この表は読みであって、測定ではありません。根拠の研究はほとんどが一度に一つの道筋しか試していません。gpt-ossやKimi K2のように複数を組み合わせたシステムも、混ぜた中でそれぞれの道筋がどれだけ効いたかは公表していません。

また、とても現実的な費用を二つ考えに入れていません。複雑さ(道筋を一つ足すたびに、壊れうる部品が一つ増えます)と、要求のまとめ処理です。サーバーは、似た質問を大量に同時に扱うと効率がよくなります。振り分けや深さの調整をするたびに、そのまとまりが少しずつ崩れます。

VII

どうやって確かめるか

単純な実験で決着がつくはずです。公開モデルを一つ選び、道筋を一つずつ、いくつかの順序で加えていき、そのたびに同じベンチマークで正解1件あたりの費用を測るのです。

利得が掛け算になるなら順序は関係なく、最後に加えたものも最初と同じだけ効きます。重なり合うなら、加えるたびに効果は前より小さくなります。この曲線は、どんな表よりもよく、どの道筋から始めるべきかを教えてくれるでしょう。

ページの先頭へ