世界を動かす技術を、日本語で。

ママ、泡がないよ: Llama-1Bのための低遅延メガカーネルの設計

概要

  • LLM推論の 低レイテンシ 化が重要な用途(チャットボット等)で求められる状況
  • 従来手法 は小さなカーネル分割によりGPU帯域の半分しか活用できない問題
  • Megakernel による全モデルforwardパスの統合で帯域活用率を大幅向上
  • カーネル統合のための 命令管理・共有メモリ管理・同期機構 の工夫
  • 実装・詳細は オープンソース で公開中

低レイテンシLLM推論の課題と背景

  • チャットボットや human-in-the-loop ワークフローなど、即時応答が重要なアプリケーション
  • 単一シーケンス生成(例:Llama-3.2-1B)では メモリ帯域 がボトルネック
  • vLLMやSGLangなどの 既存エンジン はH100上で最大でもGPU帯域の50%しか利用できない現実
  • 原因はモデルforwardパスを 100個前後の小カーネル に分割して実行する設計
  • 各カーネル起動・終了時に 無駄な待機時間 が発生し、重みロードも停止
  • CUDA GraphsやPDL等のNVIDIA機能でも 待機の根本解決には至らず

Megakernelによる高速化アプローチ

  • forwardパス全体を 単一カーネル(Megakernel) で実行しカーネル境界を排除
  • H100上で 帯域利用率78%、既存システム比1.5倍以上の性能達成
  • Megakernel実装の3つの課題
    • 多命令融合 (約100種の演算を統合)
    • 共有メモリの効率利用 (メモリバブルの最小化)
    • 同期機構の自前実装 (データ依存性の管理)

多命令融合(Issue 1/3)

  • 従来のカーネル融合は2~3演算が限界、Megakernelでは約100演算の統合が必要
  • GPU上で動作する インタプリタ 方式を採用
  • 各SMが命令シーケンスを受け取り、共通のCUDAテンプレートで実行
  • 主要命令例
    • RMS norm + QKV + RoPE融合命令
    • Attention計算命令
    • MLP関連命令
    • 最終logits計算命令

共有メモリ管理(Issue 2/3)

  • Megakernelでは 命令間の処理遷移を高速化 し、常時重みロード状態を維持
  • H100の共有メモリ213kBを 16KiB単位でページ分割
  • 命令ごとにページの 明示的な取得・解放 を管理し、空き次第次命令がロード開始
  • これにより メモリバブルの発生を最小化

同期機構(Issue 3/3)

  • Megakernelではカーネル間の自動同期がないため、 命令間の依存性管理が必要
  • GPUグローバルメモリ上に カウンタ配列 を用意
  • 命令完了時にカウンタをインクリメント、依存命令は該当カウンタが所定値に到達するまで待機
  • 例:Llama-1Bの大規模MLPでは中間状態を4チャンクに分割し、 チャンク単位で逐次処理・同期

Megakernelの実装と効果

  • H100上でのMegakernelは 業界最速級のforwardパス を実現
  • 単一シーケンス生成 でも高い帯域効率・低レイテンシを達成
  • 低バッチ・小モデルサイズ環境でも GPUの無駄時間を大幅削減
  • 全コードをオープンソースで公開、詳細実装や応用も可能

今後の展望と応用

  • Megakernelの手法は他の 小規模モデルや低バッチ用途 にも適用可能
  • 共有メモリ管理・同期の自前実装 ノウハウは他GPU最適化にも有用
  • 低レイテンシAIサービス 全般での活用可能性

参考 :詳細・コードは公式リポジトリを参照

Hackerたちの意見

これはCerebrasの夢で、GPUで少しでも実現されているのを見ると本当に嬉しいです。これらの技術にはまだまだ性能が眠っているのがすごいですよね。少数の勇敢な人たちが、こういった最先端技術を押し進めるためにどれだけのことができるかを考えると、驚くべきことです(カーネルだけじゃなくて、他の分野でもね!)。私の経験では、大きな音やマーケティングで賑やかな世界に対する恐怖を乗り越えて、問題にコミットし、学びながら時間をかけて進めていくと、ほとんどのアプリケーションで素晴らしい結果が得られることが多いです。もしそうならなかったとしても、まだ大きな進展が見込める適用可能な他の分野があることが多いです。大手企業はスケールの利点を持っていますが、周りを見回して感覚を保てば、まだまだできることがたくさんありますよ。<3 :)

メタな話ですが、この論文は素晴らしく書かれていて、すごく読みやすいです — 著者たちの素晴らしい仕事ですね。

深さを損なわないカジュアルなスタイルを見事に表現してますね。もっと「brr」って言葉を使った出版物が増えてほしいな。

これは明らかにブログ記事か何かで、論文じゃないね。論文としての構成がなくて、期待される要素がたくさん欠けてる。でも、それが逆に素晴らしいんだよね:)

ここでのスピードアップは、小さなモデルに最も役立つようですね。大きなモデルでは、カーネル間のスワッピングにかかる時間が全体の時間の中で小さな割合になるからでしょうか?実際に多くの人が使っている14-70BパラメータのLLMに対する理論的な結果が見てみたいですね。それに、大きなバッチサイズでのスループットへの影響についても、彼らが最後に触れている通り、興味深いです。全体的にとても面白い結果ですね!

これ、7B-70BパラメータのMoEモデルにもいいスピードアップをもたらすかもしれませんね。ただし、アクティブなパラメータがO(10x)少ない場合ですが。例えば、https://huggingface.co/Qwen/Qwen3-30B-A3Bのように、エキスパートルーターがモノリシックなメガカーネル内で効果的にスケジュールできると仮定して。

フォワードパスの時間を、例えば1.5msから1msに減らしてるんだ。大きなモデルだと、15msから14.2msくらいに減らせるかもね。

数字を示した後、CUDAグラフもこれを多く行っていると述べていますが、彼らには起動時間が高いとも言っています。比較の数字を含めてくれたらもっと面白かったのに。数字がないと、彼らがCUDAグラフのベンチマークを省略したのは努力不足なのか、それとも実際にベンチマークを行ったけど、自分たちのアプローチが彼らが描いているほどの性能向上ではなかったことを認めたくなかったのか、疑問が残ります。

うん、私もこの比較を見たかったです。でも彼らのアプローチは大好きでした。

図1に示されているように、私たちのメガカーネルはvLLMやSGLangのベースライン(CUDAグラフとtorchコンパイルを使用)を上回っています。グラフとストリームのオーバーヘッドの削減がこんなに少ないとは驚きです。もっと大きな利得を観察している気がしますが、もしかしたらCPUのオーバーヘッドと起動遅延を混同しているかもしれません。彼らはグラフのアップロードを事前に行ったのか、グラフ内でパラメータを変更する必要があったのかを言及すべきですね。

sglangとvllmの数値はCUDAグラフが有効になっている状態のものだよ。そう言った意味では、1Bモデルは極端な例だから1.5倍のスピードアップがあるんだ。普通のモデルやバッチサイズだと、せいぜい数パーセントの改善になると思う。

他のLLMエンジンやGPUでもこれが可能なのかな?例えば、LlamaやApple Silicon、Radeonとか?

うん、これらはCUDA特有のものじゃないよ(ただし、相対的なレイテンシは違うかもしれないけど)。

CUDAについて本当に残念に思うのは、Nvidiaがこれを簡単に実現するための同期プリミティブを提供できるのに、しないことだね。彼らのコアでのスケジューリングは本当に頭が悪いままだし、今の世代で追加された非同期ワープ特化の行列乗算命令をサポートするために裏でたくさんの作業が行われているのは知ってるんだけど。直接アクセスする方法がなくて、毎世代で公開されるちょっとした特別な部分を使わなきゃいけないのが残念だよ :(

Llama 1Bのような小さなモデルのために、本当に低レイテンシの推論を実現することは、デバイス上でのAIを普及させるために重要なんだ。もし、これらのモデルが一般的なハードウェアや組み込みシステムで十分に速く動くようになれば、クラウドベースのAPIを超えた新しい可能性が広がるんだ。

bfloat16を使いながら、どうしてそんなにスピードアップにこだわるの?