 | 過去9か月間、手元のセットアップで32GBのMI50を2枚使っています。私の用途の大半は単にllama.cppに頼っているだけで、今は実に快適に動いています！ （当時の状況と比べると大きな飛躍です） たまに、遊び半分でComfyUIにも手を出し、新しいImageGen/AudioGenモデルを試したりしていました。ですが、私のMI50では、動画生成という特定の用途が現実的に全く不可能でした。 問題以前Wan 2.2を触ったときのことを覚えています。シンプルな動画生成をすると、すぐにOOMになるか、あきらめて自分でプロセスを殺すまでに7〜9時間もかかるかでした。最新のLTXモデルでもうまくいきませんでした。 少し調べてみると、MI50s（gfx906）ではPyTorch上でメモリ効率の良い注意（attention）のサポートがゼロであることが分かりました。理由は、それに必要な行列積（matrix-multiplication）のコアを持っていないからです。すべての融合（fused）attention実装は、明確にgfx906を除外しています：
融合attentionがない場合、PyTorchはMath SDPAへフォールバックします。この場合、全N x Nのattentionスコア行列をそのまま生成（materialize）します。2.5秒の480p動画（17Kトークン）なら、attention層1つ分のスコア行列だけで26 GB。5秒の720p動画（75Kトークン）だと500 GB超です。32GBでは完全に無理です。 DIYのアプローチ当然ながら、上記の調査結果を見てから、公式のFAサポートがないのにllama.cppが私のGPUでどう処理しているのか気になりました。すると、未対応GPU向けのフォールバックとして、汎用的なタイル（tiling）機構が用意されていることが分かりました。 それをヒントに、PyTorchでも同様のものを自作できないか検討することにしました。とはいえ、このコーディング領域は私にとって完全に新しい分野でしたが、AIの助けを借りながらなんとか道筋をつけられました。 核心となるアイデアはシンプルです。N x Nのスコア行列を一度に計算するのではなく、メモリに収まるサイズのチャンクに分割（タイル化）します。
理論上は簡単ですが、確実に動かすところまで持っていくのに約28回の試行が必要でした。考え出さないといけなかったこと： うまくいったこと：
うまくいかなかった、または不要だったこと：
到達点カーネルは動作し、単一のMI50 32GBで以下が可能になりました： 動画生成（ComfyUI経由）：
画像生成（Z-Image Turbo 6B via ComfyUI）：
PyTorch LLM推論 — Qwen 2.5 0.5B（GQA、FP16）：
すべてのベンチマークは、単一のMI50 32GBで、128 GBのDDR4 RAMを搭載し、150Wの電力制限下で実施しました。 DRAMに関する重要な注意：これらのVideoGenワークフローはCPUへのオフロードに依存しており、さまざまな解像度や動画長で快適に実験するには少なくとも64 GBのDRAMが必要です。（参考として、Wan 2.2 5BとLTX 2.3に使ったワークフローは私のGitリポジトリで共有しています） それと、気づきましたか？！ 実はさらに速い！カーネルのいちばん良い点は、Math SDPAがまだ動作できるシーケンス長においても、実際にMath SDPAを上回る性能を出していることです。分離したattentionベンチマーク（B=1、H=16、D=64、MI50上でFP16）：
スピードアップは、おそらくL2キャッシュの利用が改善され、小さなチャンクが巨大なNxN行列を行き来してキャッシュを荒らす（thrashingする）のではなく、キャッシュ内で“熱い状態”のまま維持されるためでしょう。これはタイル状の注意（tiled attention）の基本的な性質です（Flash AttentionがNVIDIAでも高速なのと同じ理由なので）、多少正確な数値が違っても他のGPUでも同じ方向性になるはずです。私にとっては、これによりカーネルが“何でもPyTorch”の完璧なドロップイン置換になりました！ 他にも役立ちそうな領域上のベンチマークは私が個人的に実際に試したものですが、カーネルのパッチはSDPAの呼び出しをグローバルに適用します。つまりComfyUIや推論だけに限りません。理論上、次のような用途にも役立つはずです：
gfx906から、より広いリリースへ当初これは、私のMI50向けの単純なプライベートDIYでした。公開する予定はありませんでした。でも、そのアルゴリズムが純粋にPyTorchのmatmulであることに気づきました。フューズド注意（fused attention）を持たないすべてのAMD GPUには、まったく同じ問題があります：
現在、注意を多用するワークロードでMath SDPAに“固定”されているGPUの設置台数ベースは非常に大きいです。 そこで、GPUの自動検出付きの汎用的で、pipでインストールできるライブラリとしてパッケージ化しました。対応GPUでは、importするだけで完了です： 検出システムは起動時に、効率的なSDPAバックエンドがあるかを調べます。GPUにFlash Attentionまたはmem_efficientがあれば、そのまま何もしません。なければ自動で有効化されます。 リポジトリ: https://github.com/Lowkey-Loki-SN/noflash-attention 制限事項と貢献歓迎以下の点については、先に正直にお伝えしたいです：
もし上記のどれかのGPUを持っていて、このカーネルの恩恵がありそうなら、ぜひ試してみて、結果を教えてください！これはサイドプロジェクトなので、これ以上の改良に向けた継続的なコミットを保証はできませんが、不具合報告や互換性に関するフィードバックは歓迎します。コミュニティにやってもらいましょう！ ボーナス事実: ROCm 7.2 + PyTorch（ソースから）はgfx906で動くその過程で、ROCm 7.2をgfx906で動かせるかどうかもテストしたかったのですが（公式にはサポートされていません）、答えははい、ソースからビルドすればです。私はROCm 7.2をコンパイルし、その上でそれに対してPyTorchをビルドしました。gfx906はまだ動きます！コンパイラ側のハードウェアサポート（LLVM/AMDGPU）は削除されていません。単に公式のビルドターゲットに入っていないだけです。私は1週間ほど使っていますが、現時点では安定しています。 最後は、MI50 1枚でこのカーネルを使って、LTX-2.3 22Bで生成した1080pの5秒の音声-映像クリップで締めます。 [link] [comments] |
対応していないAMD GPU向けに、単純なPyTorchのフラッシュ・アテンション代替を作った
Reddit r/LocalLLaMA / 2026/3/28
💬 オピニオンDeveloper Stack & InfrastructureTools & Practical Usage
要点
- 著者は、AMD MI50（gfx906）GPU上で動画生成モデルを動かすのが難しいと述べている。理由は、PyTorchに当該アーキテクチャ向けのメモリ効率の良い／フラッシュ・アテンションのサポートがなく、そのためメモリ使用量が急増したり、実行が極端に遅くなったりするため。
- 彼らは、一般的な“fused（融合）”アテンションの手法（Composable Kernel、AOTriton、Flash Attention ROCm、Triton）について、新しいGPU命令セット（gfx908+）を必要とするか、あるいは明確にgfx906を除外していると説明している。
- fused attentionがない場合、PyTorchは“math SDPA”にフォールバックし、N×Nのアテンション行列全体を生成（materialize）してしまう。その結果、32GBのVRAMでは、より長い／高解像度の動画プロンプトが実行困難になる。
- llama.cppの“対応していないGPU向けのタイル分割（tiling）フォールバック”から着想を得て、著者は「単純なPyTorchのフラッシュ・アテンション代替」を構築した。具体的には、フル行列ではなくクエリ／キーのチャンクを順に処理することで、メモリに収まるタイル単位でアテンションを計算する。
