抽象化の引退

2026年8月5日 · 6分読了 抽象化の引退 Stuart Sul, Chris Ré TL;DR: CUDA DSLは引退に向かっていると考えています。 昨年、私たちはメガカーネルを書くことにしました。しかし、メガカーネルの実装は非常に苦痛を伴うことがあります。複雑なデータ構造、広範なスレッド/SM/GPU間の同期、深くネストされた制御フローなどを必要とします。それを頭の中で保持することはできなかったため、私たちは70年間コンピュータサイエンスが行ってきたこと、つまり抽象化レイヤーを構築しました。それを使っても、Llamasが驚異的な速さで実行されるようになるまで、数ヶ月間レースコンディションやデッドロックと格闘しなければなりませんでした。 今年、私たちはMoEメガカーネルを構築しましたが、抽象化を削除しました。エージェントを使用することで、複雑さを直接処理し、ゼロからターゲット最適化されたコードを構築することができました。中間的なC++抽象化レイヤーは必要ありませんでした。これは何を意味するのでしょうか？ オフローダーのオフロード 過去四半期に興味深いパターンに気づきました。抽象化なしで既に実行できたタスク（例: 最適化されたGEMMカーネルの記述）は、適切なプロンプトがあればほぼ自動化されています。今のところ、エージェントにどのPTX命令を使用するか、ワープスペシャライゼーションのデザインなどを指示する必要がありますが、それは非常に迅速に最先端の状態に到達します。残念ながら、抽象化を必要としたタスク（例: メガカーネルの記述）は自動化されていません。今日、メガカーネルをワンショットで作成することはできません。しかし、エージェントは、注意深く設計されたC++テンプレートではなく、不完全で乱雑な形式で、抽象化をプロンプトに入れることを可能にします。昨年は管理不可能だった複雑さが、曖昧な指示を受け取ってコードを生成できる「コンパイラ」が登場したため、管理可能になりました。メガカーネルに込められたアイデアは依然として同じくらい重要でしたが、それを表現することははるかに容易になりました。認知オフローダーとしての抽象化の仕事は引退し始めています。エージェントがその仕事を引き継いでいます。 次は何？ 帰納法により、CUDA DSLが引退リストの次に来るでしょう。私たちの愛するThunderKittensも含まれます。おそらく来年、あるいはもっと早く。これがどこまで進むかは分かりません。その下に、抽象化が純粋に契約であり、オフローダーではない、そしてそこで止まる床があるはずです。しかし、ここからは見えません。 これが挑発につながります。プロンプトがスタックのすべてのレイヤーを生成できるとしたら、コードベースの価値は何でしょうか？コードベースのピッチは精度です。それは曖昧さのない唯一の成果物であり、特定の機械が同じように二度実行するものです。しかし、精度にはコストがかかり、そのコストは脆さです。コードベースは、言語、フレームワーク、ハードウェアターゲット、そしてそのコードを書いたチームだけが本当に理解する一連の規約に縛られています。それはポータブルに見えますが、ほとんどそうではありません。 プロンプトは逆です。それは曖昧ですが、移動します。同じ意図を異なるワーカー、人間または機械に渡すと、そのワーカーがギャップを正しく埋めるのに十分賢ければ、ギャップを事前に標準化することなく正しい結果が得られます。それが興味深い部分です。エージェントが登場したことで、指定が不十分な指示を読み取って正しいことを行うインテリジェントな実行者と、愚かな実行者が判断を必要としないようにすべてのギャップを指定することとの間で競争が生まれています。DSLとフレームワークは、コードベースとして表現されたその仕様です。実行者が愚かでなくなれば、DSLはその基盤を失います。 コードベースは不完全な媒体です。私たちはそれを愛していますが、それは巨大で、バロック的で、バグに満ちています。それを書いたエンジニアが不注意だからではなく、機械にとって十分に正確で、人間にとって十分に読みやすく、将来にとって十分に柔軟であるという、トークンの文字列にとってほとんど不可能な制約のセットであるためです。そして、私たちは以前にも不透明な変換を受け入れてきました。実際に実行されるアセンブリを書く人はほとんどいません。コンパイラは、チームの誰も指摘できない方法で、並べ替え、インライン化、ベクトル化し、実行されるものを変更します。コンパイラが私たちよりも正しいことが多かったため、私たちはその取引を受け入れました。インテリジェンスは既に意図と機械の間にあります。問題は、それをより高く配置することが程度の違いなのか、種類の違いなのかということであり、私たちはそれが種類ではないと考えています。 適格性 確かに、私たちは抽象化の仕事について少し軽率でした。それを手放す前に考慮すべきことはもっとあります。第一に、抽象化は認知負荷を管理する方法であるだけでなく、アプリケーション、再利用、レビューが付着する共有サーフェスです。それがないと、検証上の課題のカンブリア爆発を引き起こします。10チームがThunderKittensで同じタイルセマンティクスをテストし、それが時間とともに蓄積されます。10チームがカスタムメガカーネルを生成すると、10個の断片化された問題セットができ、それらは階層化されません。第二に、共有されたオラクルはありません。メガカーネルの場合、テストが契約であり、作業です。誰がそれらを書き、何がそれらをチェックするのでしょうか？フレームワークを削除したとき、私たちはオラクルを保持しました。参照実装、数値許容度、プロファイルされたガントチャートがどのように見えるべきかという私たちの直感などです。それが、引退する抽象化が残したものです。オラクルがそれを超えて存続する限り、レイヤーを引退させることしかできません。オラクルが何であるか誰も知らないドメインでは、これらすべては適用されず、足場を維持します。最後に、私たちは単一の偏ったサンプルです。私たちは深く知っているドメインで抽象化を削除しました。抽象化は、まだそれを持っていない人々に知識を伝達するためにも存在し、私たちがギャップを埋めるエージェントが、ワープスペシャライゼーションについて初めて聞く人にもそれを埋めるかどうかは分かりません。おそらくエージェントはオンボーディングレイヤーを時代遅れにするでしょう。あるいは、人間はまだそれらを必要としており、私たちは訓練された人々のための快適な位置を説明しただけかもしれません。 年金 いずれにせよ、変革は避けられないように見え、愛するフレームワークを手放さなければならないかもしれません。では、何を保持するのでしょうか？意図、不変条件、テスト、そして現在ThunderKittensの抽象化の中にあり、それらをハードウェア上で正しく動作させている苦労して獲得したドメイン知識です。ライブラリは消えるかもしれません。しかし、その知識は、CUDAやHIPなどが手作業で調整される代わりに再生成されるという理由だけで蒸発するわけではありません。そして何が変わるのでしょうか？信頼はレベルアップします。差分ではなく、仕様とオラクルを精査します。実装は使い捨てになります。特定のコンパイルのキャッシュであり、真実の情報源ではありません。コードベースは消えません。単に「プロジェクト」と言うときの意味ではなくなります。抽象化は引退します。アイデアは残ります。私たちは依然としてThunderKittensを更新し、維持し、愛していきます。Vera Rubinカーネルがまもなく登場！