LLMにとって簡単なことなどない：「フラット・レイテンシ」問題
大規模言語モデル（LLM）はトークンごとに常に同じ計算量を消費するため、タスクの難易度に関係なくコストが一定になる「フラット・レイテンシ」問題がある。本記事では、軽量なドラフトモデルを使う投機的復号化と、Gemma 4に標準搭載されたMTPドラフターによる最大3倍の高速化について解説する。
人間は台所まで歩くときほとんど意識を使わないが、微分方程式を解くときには多くのエネルギーを消費する。人間のエネルギー消費はタスクの難しさに比例する。しかしLLMはそうではない。フランスの首都を尋ねても、量子コンピューティングの最近の進歩を説明させても、モデルが1トークン生成するコストはまったく同じだ。どんなトークンも、すべての層・アテンションヘッド・重みを経由する完全なフォワードパスを1回実行する。「Paris」を予測するのも「Qubit」を予測するのも、計算上は同一のイベントである。これは非効率ではなく、アーキテクチャそのものに組み込まれた性質であり、LLMとのすべてのやり取りに影響を与えている。
この一様な計算コストは、コード生成の場面で顕著になる。Pythonの関数を生成するとき、「for i in range(len(my_list」の後の閉じ括弧はほぼ確定的で、GitHubのコードを学習したモデルなら誰でも容易に予測できる。それでも、その後の括弧やコロン、改行、インデントといった単純な構文トークンにも、フロンティアモデルの全計算量が費やされる。そして本当に重要なロジックのトークンも、同じ価格で生成される。マルチエージェントシステムでは、すべてのエージェントが全トークンに対してフルモデルのコストを支払うことになり、問題はさらに複雑化する。著者はこれを「フラット・レイテンシ問題」と呼び、ハードウェアをスケールしても解決できないと指摘する。
解決策として紹介されるのが投機的復号化だ。小さくて安価なドラフトモデルが先にK個のトークンを高速に生成し、大型の検証モデルがそれらK個を1回の並列フォワードパスでまとめて検証する。ドラフトが検証モデルの出力と一致していれば、K個のトークンをほぼ1回分のコストで得られる。途中でずれた場合も、検証モデルの修正トークンを使い、残りのドラフトを捨てるだけだ。最終的な出力は常に大型モデル単体が生成するものと同一であり、品質は損なわれない。ただし、ドラフトモデルが十分に速く正確でなければならない。10トークン中7トークン正しければ大きな高速化が得られるが、受入率が約60%を下回ると、もう1つモデルを実行する複雑さに見合わなくなる。
投機的復号化はHuggingFaceで長年サポートされており、技術的にはgenerate()にassistant_model引数を渡すだけで済む。しかし問題はドラフトモデルと検証モデルのペアリングだった。両者は同じトークナイザーと出力分布を共有する必要があり、事実上、同じファミリーのモデルか、検証モデル自身の蒸留・量子化版しか選べない。間違った組み合わせでは受入率が急落し、2つのモデルを動かしても利益がない。Gemma 4はこの状況を変えた。内蔵のMTP（Multi-Token Prediction）ドラフターは外付けの別モデルではなく、アーキテクチャ内に直接訓練された予測ヘッドであり、メインモデルのKVキャッシュとアクティベーションを共有する。互換性を探す必要も、追加モデルを維持する必要もなく、出力品質を落とさずに最大3倍の推論高速化を実現する。
フラット・レイテンシはすべてのtransformerベースLLMに組み込まれた構造的問題であり、投機的復号化は今日における最も意味のある構造的答えだ。Gemma 4はそれをネイティブ機能として提供する最初の広く入手可能なモデルである。だが、これは一歩に過ぎない。タスクの実際の難しさに応じて計算量を動的に割り当てるモデルという、より深い課題はまだ解決されていない。