なぜAIの次の偉大なエンジニアリング課題は「学習」ではなく「推論」なのか

過去10年間、人工知能のスポットライトは学習によって独占されてきた。ブレークスルーは主に、大規模なコンピュートクラスター、兆単位のパラメータを持つモデル、そしてシステムに「思考」を教え込むために費やされた数十億ドルからもたらされた。我々はAI開発を、主に知性という高層ビルを建設するプロジェクトとして扱ってきた。しかし、この高層ビルが建てられた今、真の課題は、その中で同時に生活し、活動する必要がある何百万人もの人々をいかにして円滑に受け入れるかを考えることだ。これはAI研究者とエンジニアリングの焦点を、学習（知性を創造する行為）から推論（それを利用する行為）へと移行させる。学習が大規模な一度きりの資本支出（CapEx）であるのに対し、推論は無期限に続く継続的な運用支出（OpEx）である。企業が24時間体制で何百万人ものユーザーにサービスを提供するエージェントを展開するにつれ、彼らは厳しい現実を発見している。推論は単なる「逆方向の学習」ではない。それは根本的に異なり、おそらくより困難なエンジニアリング課題なのだ。

なぜ推論コストがこれまで以上に重要なのか

このエンジニアリング課題を理解するには、まずその根底にある経済的要請を理解しなければならない。学習フェーズでは、非効率性は許容される。学習実行に3週間ではなく4週間かかることは、煩わしいことではある。しかし、推論において非効率性はビジネスにとって壊滅的になりうる。例えば、最先端モデルの学習には1億ドルのコストがかかるかもしれない。しかし、そのモデルを展開して1日1000万件のクエリに答える場合、最適化されなければ数ヶ月でそのコストを超えてしまう可能性がある。これが、推論への投資が学習への投資を上回ると予測される市場の変化が起きている理由だ。

エンジニアにとって、これはゴールポストを動かすことになる。我々はもはやスループット（この大規模なデータセットをどれだけ速く処理できるか？）のために最適化しているのではない。レイテンシ（単一のトークンをどれだけ速く返せるか？）と並行処理（1つのGPUで何人のユーザーにサービスを提供できるか？）のために最適化しているのだ。学習フェーズを支配した「力任せ」のアプローチ、つまり単に計算リソースを追加する方法は、ここでは通用しない。ボトルネックがメモリ帯域幅である場合、レイテンシの問題にさらに多くのH100を投入することはできない。

メモリウォール：真のボトルネック

大規模言語モデル（LLM）推論についてあまり知られていない真実は、それが計算能力によって制限されることはほとんどなく、メモリによって制約されるということだ。学習では、データを大規模なバッチで処理し、GPUの計算ユニットを完全に活用する。推論では、特にチャットボットやエージェントのようなリアルタイムアプリケーションにおいて、リクエストは逐次的に到着する。生成される各トークンは、モデルがその数十億のパラメータを高帯域幅メモリ（HBM）から計算コアにロードすることを必要とする。これが「メモリウォール」だ。それは、フェラーリのエンジン（GPUコア）が渋滞（限られたメモリ帯域幅）に巻き込まれているようなものだ。

この課題は、エンジニアリングチームにシステムアーキテクチャをシリコンレベルまで再考させる原動力となっている。これが、GroqのもののようなLinear Processing Units (LPUs)や、専用のNeural Processing Units (NPUs)の台頭を目にしている理由だ。これらのチップは、大容量のオンチップSRAMを使用してHBMのボトルネックを回避し、メモリアクセスを単純なフェッチ操作ではなく連続的なデータフローとして扱うように設計されている。ソフトウェアエンジニアにとって、これは「デフォルトでCUDA」の時代の終わりを意味する。我々は今、データがワイヤを通じてどのように移動するかを正確に理解する、ハードウェアを意識したコードを書かなければならない。

AI効率化の新たなフロンティア

ハードウェアを常に変更できるわけではないため、今後のエンジニアリングのフロンティアはソフトウェア最適化にある。ここで、現在最も革新的なブレークスルーのいくつかが起きている。我々は、コンピュータがニューラルネットワークをどのように実装し実行するかを再定義する技術のルネサンスを目撃している。

• 連続バッチ処理: 従来のバッチ処理は、バスが満員になるのを待ってから出発するため、遅延が生じる。連続バッチ処理（vLLMのようなフレームワークによって開拓された）は地下鉄システムのように機能し、新しいリクエストが各イテレーションでGPU処理の列車に参加または退出することを可能にする。これはレイテンシを犠牲にすることなくスループットを最大化し、深いOSレベルの専門知識を必要とする複雑なスケジューリング問題を解決する。

• 投機的デコード: この技術は、小さく、高速で、安価なモデルを使用して応答を下書きし、一方で、より大きく、低速で、能力の高いモデルがそれを並行して検証する。これは、テキストを生成するよりも検証する方がはるかに計算コストが低いという事実に依存している。
• KVキャッシュ管理: 長い会話では、「履歴」（Key-Valueキャッシュ）が急速に増大し、大量のGPUメモリを消費する。エンジニアは現在、オペレーティングシステムの仮想メモリページングに着想を得た技術である「PagedAttention」を実装している。この技術はメモリを断片に分割し、非連続的に管理する。

エージェントの複雑さ

標準的な推論が難しいなら、エージェントAIはそれを指数関数的に難しくする。標準的なチャットボットはステートレスだ。ユーザーが質問し、AIが答え、プロセスが終了する。しかし、AIエージェントにはループがある。計画を立て、ツールを実行し、結果を観察し、反復する。エンジニアリングの観点からは、これは悪夢だ。このアーキテクチャの変化は、いくつかの根本的な課題を引き起こす：

1. 状態管理: 推論エンジンは、エージェントの思考プロセスの「状態」を、しばしば数分にわたる複数のステップにわたって維持しなければならない。
2. 無限ループ: 予測可能なフォワードパスとは異なり、エージェントは推論ループに陥る可能性がある。確率的なコードに対する堅牢な「ウォッチドッグ」や「サーキットブレーカー」をエンジニアリングすることは、全く新しい分野だ。
3. 可変計算量: あるユーザークエリは単一の推論呼び出しをトリガーするかもしれないが、別のクエリは50回の呼び出しをトリガーする可能性がある。各リクエストがこのような極端なばらつきを持つ場合に、負荷を管理し、インフラを自動スケーリングすることは、全く新しい種類のオーケストレーションロジックを要求する。

我々は本質的に「モデルを提供する」ことから「認知的アーキテクチャをオーケストレートする」ことへと移行している。

AIを日常のデバイスにもたらす

最後に、エネルギーとネットワークレイテンシの限界は、必然的に推論をエッジに追いやるだろう。すべてのスマート電球、自動運転車、工場ロボットがそのリクエストをデータセンター経由でルーティングすることを期待することはできない。ここでのエンジニアリング課題は圧縮だ。インターネット全体から学習したモデルを、爪よりも小さなチップに、バッテリーで動作するように収めるにはどうすればよいか？

量子化（精度を16ビットから4ビット、さらには1ビットに削減）やモデル蒸留（小さな生徒モデルに大きな教師モデルを模倣するように教える）のような技術は、標準的な実践になりつつある。しかし、真の課題は、これらのモデルをAndroid、iOS、組み込みLinux、カスタムセンサーなど、それぞれ独自のハードウェア制約を持つ何十億ものデバイスの断片化されたエコシステムに展開することだ。それは、ニューラルネットワークの複雑さが掛け合わされた、モバイル開発の「断片化の悪夢」だ。

結論

我々は生成AIの「Day 2」の時代に入っている。Day 1は、AIが詩を書けることを実証することだった。Day 2は、その能力をより信頼性が高く、手頃で、どこにでも存在するようにするエンジニアリングについてだ。次の10年を定義するエンジニアは、必ずしも新しいモデルアーキテクチャを発明する人々ではない。彼らは、電力網を溶かしたり、会社を破産させたりすることなく、毎秒10億トークンを提供する方法を見つけられるシステムエンジニア、カーネルハッカー、インフラストラクチャアーキテクトだ。AI推論はもはや単なるランタイムの詳細ではない。それは製品そのものだ。そしてそれを最適化することは、次の偉大なエンジニアリング課題である。