# Persistent Kernel ## 定義 persistent kernel(持続カーネル、persistent thread)は、タスクごとに小さなカーネルを個別に起動する従来の「1タスク1カーネル」方式を逆転させる設計パターンである。単一の長時間実行カーネルを1回だけ起動し、そのスレッドがグローバルまたは共有メモリ上の共有producer-consumerキューから継続的に作業(タスク)を取得し続ける。典型的には `atomicAdd` によるグローバルカウンタでタスクインデックスを取得するループとして実装され(`while (true) { idx = atomicAdd(&g_index, 1); if (idx >= totalTasks) break; processTask(tasks[idx]); }`)、カーネル起動オーバーヘッドを1回分に集約する。GPU上に多数の小さい・不均一なタスク(グラフ探索、per-tokenのLLM推論処理等)がある場合に、SMを遊休させず動的負荷分散を行える(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 10 Intra-Kernel Pipelining, Warp Specialization, and Cooperative Thread Block Clusters]])。 **megakernel(メガカーネル)** はpersistent kernelをさらに発展させたLLM推論由来のアプローチで、複数レイヤー、場合によっては複数GPUをまたぐ演算列全体を1つの巨大なカーネルへ融合する。層ごとのカーネル起動オーバーヘッドを完全に排除し、従来の層単位カーネル起動に対し1.2〜6.7倍のレイテンシ削減が報告されている(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 10 Intra-Kernel Pipelining, Warp Specialization, and Cooperative Thread Block Clusters]])。 persistent kernelはwarp specializationやcooperative groupsの`grid.sync()`と組み合わせて使われることが多い: 各SMに1ブロックを常駐させ、複数フェーズを`grid.sync()`で調停しながらキューをループする、といった設計である。一方でタスクキューの明示的なatomic管理によるコンテンション、単一巨大ループのデバッグ困難性、GPUを独占してしまう(他ワークロードと共存させるにはstreamやthread block clusterでの資源分割が必要になる)というデメリットも持つ(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 10 Intra-Kernel Pipelining, Warp Specialization, and Cooperative Thread Block Clusters]])。 ## 横断的知見 - **persistent kernelは「カーネル起動オーバーヘッド削減」という単純な動機から出発しつつ、章内の技法(warp specialization、cooperative groups、thread block cluster)を統合する結節点として機能している**。本章は、persistent kernelが単独でも2〜3倍のスループット改善をもたらす一方、warp specializationと組み合わせることで深いパイプラインと長寿命リソースの効率利用が可能になり、`grid.sync()`と組み合わせることでマルチフェーズの縮約処理をホスト往復なしに実行でき、さらにthread block clusterと組み合わせることで他ワークロードとGPUを共存させられる、という多層的な合成パターンとして提示している(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 10 Intra-Kernel Pipelining, Warp Specialization, and Cooperative Thread Block Clusters]])。 - **LLM推論という文脈が、persistent kernel/megakernelの実用上の主戦場として繰り返し言及される**。per-token演算のような不均一・小粒度タスクの多発、レイテンシ最小化(バッチサイズ1のデコード等)への強い要求という推論ワークロード特有の性質が、カーネル起動オーバーヘッドの排除という技法の価値を特に高めている(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 10 Intra-Kernel Pipelining, Warp Specialization, and Cooperative Thread Block Clusters]])。 ## 未解決の問い - 本文は「PyTorchは現時点(執筆時点)でマルチステージのワークロード全体を自動的に1つのカーネルへ融合しない」と述べているが、`torch.compile`や専用コンパイラが将来的にmegakernel相当の自動融合をどこまでサポートしうるか、その技術的障壁(スケジューリングの複雑性)は何か。 - megakernelの1.2〜6.7倍というレイテンシ削減幅の広さは、どのようなワークロード特性(層数、バッチサイズ、GPU種別)に依存しているか。本章の図10-8(Llama-1Bのデコードスループット比較)以外の定量データはあるか。 - persistent kernelがGPUを独占する制約と、thread block clusterによる部分SM予約という緩和策の間で、実運用上どこまで細かい粒度のリソース分割が現実的か(例: 推論サービングでのマルチテナント共存)。 ## 関連 - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 10 Intra-Kernel Pipelining, Warp Specialization, and Cooperative Thread Block Clusters]] - [[CUDA]] - [[Warp Specialization]] - [[Thread Block Cluster]] - [[wiki/entities/AI Systems Performance Engineering|AI Systems Performance Engineering]] ## 出典 - Chris Fregly, *AI Systems Performance Engineering*, O'Reilly Media, 2025, Chapter 10「Intra-Kernel Pipelining, Warp Specialization, and Cooperative Thread Block Clusters」.