LocalLLaMAでHipfireが一気に伸びたのは、単なるGitHub共有ではなかった。AMDユーザーは長い間、ローカルLLMの世界で後回しにされてきた。多くのツールはCUDAを中心に設計され、RDNA対応は後付けか不完全なことが多い。Hipfireはそこを正面から狙っている。READMEでは、RustとHIPで書かれたAMD RDNA向け推論エンジン、単一バイナリ、Ollama風UX、そしてhot pathにPythonなしという構成を前面に出している。

しかも対象は狭くない。HipfireはRDNA1からRDNA4まで、民生GPU、Pro向け、APUまで含めて面倒を見る方針だ。要するに「AMDでも動く」ではなく、「AMDを主役にして作る」という話だ。READMEの数字もかなり強い。7900 XTXでの既定設定では、Qwen 3.5 0.8Bが391 tok/s、4Bが180 tok/s、9Bが132 tok/s、27Bが47 tok/s。さらにDFlash speculative decodeでは、条件付きながら27Bで218 tok/s、9Bで372 tok/sのピーク値を出している。

スレッドが熱を持ったのはこの性能面だった。元投稿は独自quantや外部ベンチサイトに触れていたが、説得力を増したのはコメント欄の実測だ。RX 7900 XTXで9Bコードプロンプトを試したユーザーが、baseline 106 tok/sに対して約306 tok/s、しかも出力のcoherenceも保てたと報告した。LocalLLaMAはこういう具体例に強く反応する。理論上のピーク値より、どのカードで何を流してどれだけ出たかの方が重い。

もちろん無条件の礼賛ではない。GGUF対応が欲しい、独自quantが増えると生態系がまた割れる、世代ごとの対応はどこまでか、multi-GPUはどうなるのか。そうした疑問がすぐ出た。だが、それはむしろ健全だ。速さだけでは定着しないことを、このコミュニティはよく知っている。フォーマット、互換性、導入の手間まで含めて初めて“使える”になるからだ。

それでもHipfireが刺さった理由ははっきりしている。AMDユーザー向けに後付けで帳尻を合わせたのではなく、AMDユーザーから始めたように見えることだ。LocalLLaMAがこの投稿を持ち上げたのは、単なる速度自慢ではなく、その姿勢にようやく実体がついたからだ。

#rdna

AMD向け推論エンジンHipfire、LocalLLaMAが沸いた理由