最近、RDNA向けのLLM推論エンジンに、hipfireへHFQ4-G256の実験的なMMQプリフィル・パスを貢献しました。
免責事項：私はPRを書いたので、これは一部貢献メモでもありますが、主にAMDの他のユーザーからの独立した検証を探しています。
このPRの前は、hipfireにおけるHFQ4のプリフィルが、より汎用的／より遅いパスを通っていました。私のStrix Halo環境では、プロンプト処理が明確なボトルネックで、より長いプリフィルではおよそ~310–340 tok/sでした。
新しいパスは、MMQスタイルのプリフィル実装をオプトインで追加します。この文脈において、MMQとは、プリフィルを最適化されていない一連の演算として扱うのではなく、実行のためにGPU向けに適したタイル化された行列―行列カーネルに作業を詰め込む、特殊化された量子化行列乗算パスのことです。実装では、プリフィルの活性をQ8_1のMMQレイアウトに事前量子化し、LDSステージングを伴って、128×128の出力／バッチタイルに対してi8 WMMAを使用します。
次のように有効化すると：
HIPFIRE_MMQ=1
Strix Halo / gfx1151で、より長いプリフィルのスループットが~1140–1260 tok/sほどになります。
変わった点：
- HFQ4-G256プリフィル用の、
HIPFIRE_MMQ=1によるオプトインパスを追加。 - 対象は当面RDNA3 / RDNA3.5：
gfx1100、gfx1101、gfx1102、gfx1103、gfx1150、gfx1151。 - プリフィルの活性をQ8_1のMMQレイアウトに事前量子化。
- LDSステージング付きで、128×128の出力／バッチタイルに対するi8 WMMAを使用。
- llama.cppのAMD MMQプロンプト処理パスと形が似ている。
- デフォルトでは有効化されない。
ベンチマーク：Strix Halo / gfx1151でのQwen3.5 9B HFQ4/MQ4
| KV mode | pp | MMQ off, tok/s | MMQ on, tok/s | Speedup |
|---|---|---|---|---|
| q8 | 256 | 363.1 | 1127.6 | 3.11x |
| q8 | 512 | 352.0 | 1179.8 | 3.35x |
| q8 | 1024 | 328.9 | 1222.7 | 3.72x |
| q8 | 2048 | 318.2 | 1168.5 | 3.67x |
| asym4 | 256 | 368.6 | 1108.8 | 3.01x |
| asym4 | 512 | 360.7 | 1173.3 | 3.25x |
| asym4 | 1024 | 333.9 | 1223.0 | 3.66x |
| asym4 | 2048 | 312.3 | 1151.7 | 3.69x |
| asym3 | 256 | 361.4 | 1124.5 | 3.11x |
| asym3 | 512 | 359.8 | 1187.3 | 3.30x |
| asym3 | 1024 | 329.9 | 1259.1 | 3.82x |
| asym3 | 2048 | 314.1 | 1216.5 | 3.87x |
| asym2 | 256 | 374.0 | 1116.2 | 2.98x |
| asym2 | 512 | 356.6 | 1173.2 | 3.29x |
| asym2 | 1024 | 340.1 | 1208.5 | 3.55x |
| asym2 | 2048 | 311.4 | 1142.9 | 3.67x |
つまり、より長いプリフィルでは、私のStrix Haloの結果が概ね~311–340 tok/sから~1143–1259 tok/sに移りました。
これまでの正しさの検証：
- バッチ化されたプリフィルを、トークンを1つずつ進める逐次のforward passと比較
- プリフィルの最終トップトークン一致
- 選択されたlogitのドリフトが許容範囲内
- プリフィル後の次のデコードステップもチェックし、KVキャッシュ書き込みの問題を検出
q8、asym4、asym3、asym2のKVモードでテスト
注意点：
- 主に私の1台のStrix Halo /
gfx1151環境で検証 - このパスは実験的
- デフォルトでは有効化されない
- 現時点では、これを最終版／正準（canonical）のMMQ実装だとはまだ呼びません
- より多くのコヒーレンス確認やロングコンテキストのテストがあると有用
メンテナも、マージされたパスをgfx1100でテストし、HIPFIRE_MMQ=1がそこで正常に動作し、ただし小さいながらもプラスの結果が得られたと報告しています：4B pp256で+19.8%。
私が特に今確認したいのは、この実装が他のAMD GPUやAPUでもうまく汎用化できるのか、それとも現在のチューニングが主にStrix Halo / gfx1151にとって有利なだけなのか、という点です。
基本的な正しさのチェックは通っていますが、KVキャッシュ挙動が完全に「弾丸級（bulletproof）」であるとまではまだ確信できていません。微妙なKVキャッシュの問題は、より長い実運用ワークロードでしか表れない可能性があるため、特にロングコンテキストやマルチターン実行での検証をぜひお願いしたいです。
私は以下のような人たちからの結果をとても知りたいです：
- 7900 XTX /
gfx1100 - 他のRDNA3カード
- Strix Halo /
gfx1151 - RDNA3.5 APU
- そしてその他
- プリフィルが短いチャットのデコードより重要になる、ロングコンテキストのエージェント的ワークロード
[link] [comments]
