2026年3月22日の r/LocalLLaMA 投稿は、AMD Mi50 32GB で llama.cpp を動かすときに ROCm 7 nightly と Vulkan のどちらを選ぶべきかを、かなり具体的な構成で比較した記録だ。投稿者は Ubuntu Server 24.04、Proxmox 上の EPYC 7532、ROCm 7.13.0a20260321、Vulkan 1.4.341.1、llama.cpp build 8467 という条件を提示し、Qwen 3.5 9B、27B、122B、Nemotron Cascade 2 を試したとしている。こうした条件開示があるため、LocalLLaMA では実用的な参考資料として受け止められている。

投稿の主張

結論は単純な「どちらが常に速いか」ではない。投稿者によれば、短い context の dense model では Vulkan が安定して速い一方、context が 16k を超えるようなケースや MoE、GPU/CPU をまたぐ推論では ROCm の方が有利になるという。これは local inference の現場感覚に近い。多くの利用者は backend を一つの速度指標で比較しがちだが、実際には prompt processing、token generation、context depth、model architecture によって結果はかなり変わる。

短い dense workload では Vulkan が優位という観察が繰り返されている。
長い context や MoE 系では ROCm が全体の体感性能で勝ちやすいと投稿者は述べている。
一方で TheRock nightly ベースの ROCm 7 には安定性リスクがあるとも明記されている。

コメント欄が加えるニュアンス

このスレッドはコメント込みで価値がある。あるユーザーは Mi60 で Nemotron Cascade 2 Q4_1 を使い、65K context で約 726 tokens/s の prompt processing を共有し、長文脈での ROCm 優位を補強した。別のユーザーは、ROCm は Vulkan よりビルドも運用も難しく、実際の安定性でも不利だったと報告している。また、RDNA 4 など GPU 世代が変われば結果も変わるはずだという指摘もある。つまり、この投稿は単独の数値表というより、AMD 環境での意思決定材料として読むべきだ。

どう読むべきか

もちろん、これは単一環境・nightly ソフトウェア・hobbyist セットアップでの測定にすぎない。投稿者自身も、ROCm llama-server が prompt cache を VRAM に誤って確保して OOM を起こす問題や、以前の nightly で memory leak のような挙動を見たことを認めている。それでも、Vulkan は簡単で安定、ROCm は長い context や一部の MoE workload で報われる可能性がある、という整理は非常に実務的だ。AMD で local LLM を組む読者なら追っておく価値がある。

出典

#vulkan

LocalLLaMAでMi50向け llama.cpp の ROCm 7 と Vulkan 比較ベンチマークが共有される