AMD向けHipfire、LocalLLaMAが食いついたのは「RDNAがやっと主役」

LocalLLaMAでHipfireが伸びた理由はかなり分かりやすい。AMDユーザーはもう「そのうち対応します」より、「今どれだけ速いのか」を見たい。READMEはそこを正面から押している。Rust + HIPの推論エンジン、単一バイナリ、hot pathにPythonなし、OpenAI互換APIを11435番で提供、そしてRDNA1からRDNA4までのコンシューマ向けGPU、プロ向けGPU、APUを対象にする。ROCm周辺では消費者向けRDNAが後回しにされがちだっただけに、この書き出しだけでスレッドは十分に引き込まれた。

性能主張もかなり具体的だ。READMEとベンチマーク文書では、7900 XTX上の autoregressive decode が Qwen 3.5 0.8Bで391 tok/s、4Bで180 tok/s、9Bで132 tok/s、27Bで47 tok/s とされている。さらに比較条件をそろえたうえで Ollama/llama.cpp より decode が1.7倍から2.1倍速いと主張する。もっと刺激的なのは DFlash speculative decode で、コード系プロンプトでは Qwen 3.5 9B が372 tok/s超、27B が218 tok/s超まで伸びる。一方で prose では逆に遅くなることがあり、そのため DFlash をデフォルトoffにしている。この但し書きが、逆に宣伝臭さを弱めていた。

設計の説明も単なる看板では終わっていない。HipfireはQwen 3.5系に合わせたMQ4量子化を前面に出し、4bit化の前にFWHT回転で外れ値を散らす仕組みまで説明している。つまり「AMD向けに最適化しました」で終わらず、どのモデル系列にどの量子化を当てるのかまで設計思想を示している。そこへReddit側の実測が重なった。上位コメントでは、7900 XTXで9Bのコードプロンプトが約306 tok/s対106 tok/sだったという報告があり、別のユーザーはStrix Haloでの簡易テストも共有した。公式ベンチと現場の数字がすぐ接続されたのが、このスレッドの強さだ。

もちろん、まだ安心して祝える段階ではない。投稿者自身がHipfireはAMD公式ではないと明言しており、一部GPUでは未完成な部分もあるとコメントされている。量子化品質の検証もこれからだ。それでもスレッドの空気ははっきりしていた。LocalLLaMAは長いあいだ、AMDでのローカル推論を妥協と回避策の連続として扱ってきた。Hipfireがこのまま数字の誠実さを保ち、対応範囲を広げられるなら、初めて「仕方なく使う代替」ではなく、積極的にベンチしてみたいAMD向け推論エンジンになりそうだ。