「遅いプリフィル」という既知の痛点を、行列演算の再設計で正面突破

AMD GPU向けのLLM推論エンジン「hipfire」に、HFQ4-G256量子化モデルのプリフィル（prompt processing）を大幅に高速化するMMQパスが実装された。Sourceによれば、このPRを投稿したのは開発者本人であり、「自己PR半分、独立検証を求めるポスト半分」という正直な立場から情報が公開されている。

これまでhipfireにおけるHFQ4のプリフィルは、汎用的かつ最適化が不十分なパスを経由していた。Strix Halo環境では長いプリフィルで約310〜340 tok/sという数字が上限に張り付いており、トークン生成（decode）フェーズと比較してプリフィルが明確なボトルネックになっていた。長文コンテキストを扱うユースケース——RAGや長文要約、コード補完など——では、このプリフィル速度の遅さがエンドツーエンドのレイテンシを支配する。

新しいMMQパスは`HIPFIRE_MMQ=1`という環境変数で有効化するオプトイン方式を採用している。デフォルトでは無効であり、安定性や互換性への影響を最小限に抑えながら実験的な機能を試せる設計になっている点は評価できる。

技術的な中身：i8 WMMAと128×128タイル、LDSステージング

実装の核心は「プリフィルをデコードの延長として扱うのをやめ、GPU本来の得意技である行列-行列演算に落とし込む」という発想の転換だ。具体的には以下の要素で構成される。

まず、プリフィル時の活性化（activations）をQ8_1 MMQレイアウトに事前量子化する。これにより、重み側のHFQ4量子化と合わせて、整数演算ユニットを効率的に活用できる形式に揃える。次に、128×128の出力／バッチタイルを単位として、i8 WMMA（Wave Matrix Multiply Accumulate）命令を使った行列積を実行する。WMMAはAMDのRDNA3以降で利用可能なテンソル演算加速命令であり、FP16やBF16だけでなくi8精度での積和演算に対応している。さらにLDS（Local Data Share、AMDのGPUにおけるシェアードメモリ相当）を用いたステージングにより、グローバルメモリへのアクセス回数を削減し、演算ユニットの稼働率を高める。

この手法はllama.cppがAMD向けに実装したMMQプロンプト処理パスと「形が似ている」と開発者自身が述べており、既存のエコシステムでの実績ある設計思想を参考にしていることが伺える。対応ターゲットはRDNA3およびRDNA3.5のgfx1100、gfx1101、gfx1102、gfx1103、gfx1150、gfx1151に限定されており、旧世代や他アーキテクチャへの対応は現時点では含まれない。

ベンチマーク：Qwen3.5 9Bで全KVモードが3倍超え、最大3.87倍

Qwen3.5 9B（HFQ4/MQ4）をStrix Halo / gfx1151上で動作させた場合の実測値は、MMQオフ時とオン時で以下のような差が出ている。

KVキャッシュモードがq8でプリフィル長256トークンの場合、MMQオフが363.1 tok/s、MMQオンが1127.6 tok/sで3.11倍。同じq8でプリフィル長1024では328.9→1222.7 tok/sで3.72倍。asym3モードのプリフィル長1024では329.9→1259.1 tok/sで3.82倍、プリフィル長2048では314.1→1216.5 tok/sで3.87倍と、最大スピードアップを記録した。

注目すべきはプリフィル長が長くなるほどスピードアップ比が大きくなる傾向だ。256トークン前後では3.0〜3.1倍程度だが、1024〜2048トークンでは3.5〜3.87倍に達する。これはタイルベースの行列演算が、バッチサイズ（ここではプリフィル長に相当）が大きくなるほどGPUの並列性を効果的に活用できるという、行列積演算の基本的な特性を反映している。短いプリフィルでは初期化オーバーヘッドの比率が高くなるため、スピードアップ幅がやや小さくなるのは想定の範囲内だ。

KVキャッシュの量子化モード（q8、asym4、asym3、asym2）間での差はそれほど大きくなく、いずれのモードでも同様の高速化が得られている。これはMMQパスがKV量子化とは独立した層で機能していることを示唆している可能性がある。

結論：AMDエコシステムの「自力更生」が着実に進んでいる

NVIDIAのcuBLASやFlashAttentionが長年にわたって積み上げてきた最適化の厚みと比較すれば、AMDのROCm周辺エコシステムはまだ発展途上だ。しかしhipfireのような専用推論エンジンが、llama.cppの知見を参照しながら独自の最適化を積み重ねている現状は、コミュニティ主導の「自力更生」として見れば着実な前進と言える。

3倍超のプリフィル高速化は、Strix HaloのようなAPU構成でLLMをローカル実行するユーザーにとって実用上の意義が大きい。プリフィルが遅いと長文コンテキストの活用が事実上制限されるが、1000〜1200 tok/sのレンジに乗れば、日常的な利用シナリオでのストレスはかなり軽減される。

ただし、投稿者自身が「独立した検証を求めている」と明記している点は重要だ。単一の開発者・単一のシステム構成での数値であり、他のStrix Halo環境や異なるモデルでの再現性はまだ確認されていない。また、デフォルト無効のオプトイン実装であることから、品質・安定性の面での追加検証が必要と推測される。AMDユーザーコミュニティによる追試が、このパスの本採用への道を開くかどうかを左右するだろう。