FlashAttentionとPagedAttentionの違い

モデルはattentionで入力トークン同士が参照する情報を計算します。入力が長いほど、中間結果をGPU⁶メモリへ書き込み再読込する移動が増えます。FlashAttentionは小さなtile単位で処理し、大きな中間配列を何度も保存しないことでデータ移動を減らします。

入力全体をアテンション計算に使いながら、中間結果の保存と移動を減らす方法です。長い入力で最初のトークンを待つ時間が長い場合は、モデル読み込みとプリフィルを分けて記録し、実行ログでFlashAttentionカーネルが選択されたか確認します。

異なる長さの要求が届くと、各会話は入力と生成済みトークンの状態をKVキャッシュに保持します。PagedAttentionはキャッシュを固定サイズのブロックで管理し、要求に必要な分を割り当て、完了後に回収します。要求ごとに大きな連続領域を予約する場合の空きを減らすことが目的です。

リクエストAの処理中に短いBが終われば、Bのブロックを回収してCに割り当てられます。Aの会話に必要な状態はAが終わるまで保持します。同じGPUメモリ内で、リクエストごとの領域を効率よく使う仕組みです。

同時要求や文書が長くなれば、稼働中の状態を保持するキャッシュが必要です。入力prefillが実行中decode⁷とGPU計算を共有するとトークン間隔が延びることがあり、長いprefillを分割・スケジュールする対応はランタイム⁸によって異なります。キャッシュ配置を効率化しても稼働状態を収める物理メモリは必要です。

FlashAttentionはattention計算中のメモリ移動を変え、PagedAttentionは各要求のKVキャッシュをブロックに割り当てます。ランタイムが両方をサポートすれば、prefill計算と要求メモリ管理を併せて最適化できます。長いコード入力でprefillが遅い問題と、チーム同時利用でキャッシュが足りない問題は別々に確認します。

対応状況はGPU・モデル構造・量子化⁹・アプリ版によって異なり、ランタイムが自動選択する場合もあります。メニューにオプション名があるだけで適用を判断せず、ログで実際のカーネルとキャッシュ経路を確認します。設定を強制する前に正常動作する既定値を記録します。

短い関数質問を一つだけ行う個人利用では、同時キャッシュ状態が少なくPagedAttentionのサーバーメモリ配置の効果は小さい場合があります。FlashAttentionの効果もprefillと逐次decodeで同じとは限りません。最初のトークンまでの時間と生成中のトークン間隔を分けて記録します。

チームサーバーでは単一要求の基準を取り、長いコード分析中に短い質問と別の分析を重ねます。最初のトークン・生成区間・ピークメモリ・要求ごとの遅延・総処理量を記録すると、カーネルとキャッシュ管理のどちらの変更が利用者に役立ったか見られます。

ランタイムが提供する設定を一つずつ試し、ログで適用を確認します。利用者が変更できる項目がない場合は設定を作らず、自動選択をログで調べます。入力計算がボトルネックならFlashAttention経路、同時要求時のキャッシュ配置が課題ならPagedAttention対応を確認します。