LLM アーキテクチャの複雑化の進行

モダンな大規模言語モデル（LLM）は、Llama のような初期モデルで見られたシンプルで繰り返し使用される Transformer モジュールから、極めて複雑な合成アーキテクチャへと進化しています。この変化は、能力向上の必要性と極端な推論効率の要求という緊張関係によって推進されており、レコメンデーションシステム（recsys）の歴史的な軌跡を映し出しています。

シンプルなスタックから合成アーキテクチャへのシフト

初期の LLM は、同一モジュールがきれいに積み重ねられた滑らかなスタックが特徴でした。しかし、現在の最先端モデルは、性能と効率を最適化するために多様なアーキテクチャバリエーションを取り入れています。

現代の LLM アーキテクチャに統合されている主な複雑性は次のとおりです：

• Attention のバリエーション: もはや単一の注意機構に依存せず、クエリグルーピング、圧縮注意、スパース注意、線形注意、スライディングウィンドウ注意を利用します。
• ルーティング機構: Mixture-of-Experts（MoE）はフィードフォワード層への選択的ルーティングを導入し、現在は注意ブロックや残差ストリームにもルーティングが適用されています。
• マルチモーダル統合: 以前は別個のコンポーネントとして「取り付けられた」ビジョンやオーディオエンコーダが、現在はモデルアーキテクチャに直接混合されています。
• 推論スケーリング: 複数 GPU にまたがって実行されるようになると、通信操作（comms ops）がモデル構造内に追加の境界と複雑性をもたらします。

「Recsys」パラレル：性能が必須になる

LLM の進化はレコメンデーションシステムの経験を映し出しています。約10 年間、recsys アーキテクチャはシンプルな二塔スパースニューラルネットでしたが、性能最適化が「荷重を支える」ものとなったために複雑化が進みました。つまり、特定の最適化がなければモデルは遅すぎるかリソース消費が大きすぎて実用的でなくなるということです。

LLM 研究の文脈では、性能がオプションの最適化から必須要件へとギャップが縮まっています。これにより研究イテレーションのループに課題が生じます。たとえば研究者が新しい注意バリエーションをテストしたい場合、融合された最適化ベースラインに比べて桁違いに遅くなることは許容できません。新しいアーキテクチャ変更が探索に値するか判断するためには、その変更の部分的に最適化されたバージョンが事前に存在していなければなりません。

合成性のための設計とカーネルの役割

実験的アーキテクチャごとに手作業でカーネルを融合するボトルネックを回避するため、業界は事前に合成性を考慮した設計へとシフトしています。PyTorch や JAX の定義から自動的に融合カーネルを生成する AI エージェントに依存するだけでは不十分です。エージェントは生成されたコードが正しいことを検証できる固定かつ利用可能なベースラインを必要とします。

PyTorch の FlexAttention

PyTorch の FlexAttention は合成的アプローチの主要な例として挙げられています。Triton テンプレートを用いて幅広いクラスの注意操作向けカーネルを生成できるようにします。注意操作を合成可能かつ検証可能にすることで、FlexAttention は研究者が性能への影響を最小限に抑えつつ新しいアーキテクチャバリエーションを探索できるようにし、手作業で時間のかかるカーネル融合の必要性を回避します。

アーキテクチャ進化に対するコミュニティの視点

アーキテクチャのシフトが進む一方で、ある観測者はこれが「苦い教訓」ライフサイクルに従っていると指摘しています。あるコミュニティメンバーは次のように述べています：

それは特徴エンジニアリングの苦い教訓ライフサイクルです。技術や手法が新しいときは、単にあるユースケースに適用するだけで大きな成果が得られます… 時が経つにつれて、その「苦い教訓」的な成果はロジスティック曲線の浅い部分に達し、企業は各小さなインクリメンタルな改善のためにますます多くのエンジニアリング投資をしなければならなくなります。

さらに、一部の批評家は、LLM の異なるファミリー（例：Llama 3 と Nemotron 3 Ultra）を比較して複雑性を強調することは、すべての単一モデルファミリーに共通する普遍的な傾向というよりは、設計選択の違いによる自然な結果であると主張しています。