AMDローカルLLMホスティングにおけるROCm vs Vulkan：2026年版ガイド

エンジンごとに最適なAMDバックエンドを選択する

目次

ROCm と Vulkan はどちらも AMD GPU をローカル LLM ホスティングで高速化しますが、互換性はありません。適切な選択は、エンジン、GPU、およびワークロードに依存します。

ローカル LLM ホスティングにおいて、この2つのバックエンドは異なるレイヤーに位置しています。ROCm は PyTorch、vLLM、SGLang 下の AMD コンピューティングプラットフォームであり、Vulkan は llama.cpp 系のエンジンが幅広いハードウェアで量子化モデルを実行するために使用する、ポータブルな GPU API です。

ROCm and Vulkan backends for AMD local LLM hosting

このガイドでは、llama.cpp、Ollama、LM Studio、vLLM、SGLang、TGI、LocalAI について、エンジンの比較、ビルドコマンド、デバイスチェック、およびパフォーマンス問題に偽装した失敗モードを取り扱います。ホスティングの概要が初めての方は、この記事で掘り下げるツールファミリーのマッピングが行われた LLM ホスティング概要 から始めることをお勧めします。

ROCm と Vulkan: 短い回答

状況 おすすめの出発点 理由
Linux での llama.cpp と GGUF Vulkan 導入範囲が小さく、GPU カバー範囲が広く、ロールバックが容易
対応 RDNA 3 または RDNA 4 GPU での llama.cpp 両方のベンチマーク実行 カーネルパフォーマンスはモデル形状、量子化、コンテキスト、ビルドによって変化
掲載されている AMD GPU での Ollama まず ROCm、Vulkan も検証 Ollama は両方をサポート하지만、生の llama.cpp よりバックエンド選択が明示的でない
デスクトップ AMD GPU での LM Studio まず Vulkan ランタイム切り替えにより比較が容易になり、システム全体のスーパースタックを回避
vLLM または SGLang ROCm、ただし GPU ファミリーのカーネルカバー範囲を検証 これらは PyTorch/HIP スタックであり、Vulkan は代替バックエンドではなく、最新アーキテクチャは最適化カーネルがまだない可能性
対応 Instinct ハードウェアでの TGI ROCm 公開されている AMD コンテナパスは MI210、MI250、MI300 ファミリーを対象
古いまたは未掲載の Radeon GPU Vulkan Vulkan ドライバーは通常、ROCm ライブラリよりも多くのグラフィックハードウェアをカバー
AMD Instinct サーバー ROCm マルチ GPU コンピュート、RCCL、フレームワークカーネル、運用ツールがここにある
Windows ローカル GGUF サービング Vulkan llama.cpp 系ランタイムにとって一般に最も制約が少ないルート
Ryzen AI Max または他の大容量メモリ APU まず Vulkan、必要に応じて ROCm どちらも動作する可能性があるが、共有メモリとカーネルサポートにはワークロード固有のテストが必要

この表は出発方針であり、ベンチマーク結果ではありません。GPU を検出するが一部の演算を CPU に残すバックエンドは、健康に見えながら悪いパフォーマンスを示す可能性があるため、すべての最終決定にはログの検査とエンドツーエンドのプロンプトテストが必要です。

ROCm と Vulkan が実際何か

ROCm はコンピューティングプラットフォーム

ROCm には、AMD コンピュートワークロードを実行するために必要な HIP ランタイム、コンパイラ、数学ライブラリ、集合通信、プロファイラー、フレームワークパッケージが含まれます。これは PyTorch ビルドおよび vLLM や SGLang などのエンジンの下にある AMD 側の基盤であり、HIP バックエンドを通じて llama.cpp を高速化することもできます。

その広大さは ROCm の利点であり、そのコストでもあります。ホストドライバー、GPU ターゲット、ユーザー空間ライブラリ、フレームワークホイール、カーネルバージョン、コンテナイメージは互換性の あるセットを形成しなければなりません。それらがそうである場合、ROCm は1つのローカル実行可能ファイルを通じたトークン生成よりもはるかに多くのことを提供します。

2026年8月26日にリリースされた ROCm 10.0.0 は TheRock (ROCm 7.14 以降の AMD のビルドおよびリリースシステム) に構築され、PyTorch 2.13、vLLM 0.27、SGLang 0.5.15 を検証し、gfx1200 (RX 9060/9060 XT/9050) および gfx1201 (RX 9070/9070 XT/9070 GRE、Radeon AI PRO R9700 シリーズ) に対する RDNA 4 サポートを公式に追加しました。正確な GPU と OS の組み合わせ権威は、同じマーケティングファミリーを使用するだけのフォーラム投稿ではなく、引き続き ROCm 互換性マトリックス です。

Vulkan はポータブルな GPU インターフェース

Vulkan は、GPU ドライバーによって実装されるグラフィックおよびコンピューティング API です。ローカル LLM ホスティングにおいて、それは通常、推論エンジンが compute シャーダーを配布またはコンパイルし、Linux での Mesa RADV や Windows でのベンダードライバーのような Vulkan 実装を通じて実行することを意味します。

Vulkan は、ROCm に匹敵するドロップイン PyTorch プラットフォームを提供しません。その実用的な強みは狭く、有用です：llama.cpp スタイルのエンジンは、ベンダー固有の機械学習スタックをインストールすることなく、AMD、Intel、Nvidia、および他の Vulkan 対応ハードウェアで同じバックエンド設計を使用できます。

この区別が決定の大部分を説明します。アプリケーションが HIP または PyTorch パスしか提供しない場合、Vulkan はそれを救うことはできません；アプリケーションがすでに llama.cpp と GGUF に基づいている場合、ROCm スタック全体をインストールすることは、あなたが持っていなかった問題を解決するかもしれません。

2026年のエンジンサポートマトリックス

エンジン ROCm または HIP Vulkan 一般的なモデル形式 実用的な注記
llama.cpp / llama-server はい はい GGUF 制御された A/B バックエンドテストのための最良のプラットフォーム
Ollama はい はい 管理された GGUF 派生モデル 便利だが、バックエンド選択とパッケージングが抽象化されている
LM Studio はい はい GGUF およびプロダクト管理形式 選択可能なランタイムによりデスクトップテストが容易
vLLM はい いいえ Safetensors および対応量子化 AMD の対応 ROCm イメージまたはホイールセットを使用；まず GPU ファミリーのカーネルカバー範囲を検証
SGLang はい いいえ Safetensors および対応量子化 ROCm はデプロイアーキテクチャの一部
TGI はい いいえ Safetensors および対応量子化 公開されている AMD 検証は Instinct に焦点
LocalAI はい はい バックエンド依存、通常 GGUF 異なる ROCm と Vulkan コンテナイメージを使用

ROCm は Safetensors を意味せず、Vulkan は公式に GGUF を意味しません。有用な関連性はエンジンから来ます：llama.cpp は HIP または Vulkan ビルドのいずれか同じ GGUF を読み取れ、PyTorch ネイティブサーバーは ROCm を使用し、一般的に Hugging Face モデルリポジトリを消費します。

これはモデルインベントリをアーキテクチャ制約にします。注意深く選択された GGUF 量子化のライブラリは自然に llama-server、Ollama、LM Studio、または LocalAI を指します；テンソル並列性、継続的バッチング、フレームワークネイティブ重みを中心に構築されたデプロイは、ROCm と vLLM または SGLang を指します。AMD バックエンド以外のより広いエンジン風景（一打十工具間の API 成熟度、ツールコール、本番準備状態）については、Ollama、vLLM、LM Studio、LocalAI および他のローカル LLM ホスティングツールの比較 を参照してください。

llama.cpp: ROCm と Vulkan の最もクリーンな比較

llama.cpp は、モデルファイルや HTTP クライアントを変更せずに両方のバックエンドを公開します。トークナイザ、サンプリング設定、チャットテンプレート、量子化、サーバー挙動を固定したままにできるため、ROCm と Vulkan を比較する最も公平な場所です。

現在の llama.cpp ビルドドキュメント は、ROCm に GGML_HIP、Vulkan に GGML_VULKAN を使用します。GGML_ROCM または削除された Makefile フラグを推奨する古い記事は、プロジェクトの現在の CMake オプションを確認せずに信頼すべきではありません。

Ubuntu で Vulkan バックエンドのビルド

Vulkan ヘッダー、シェーダーコンパイラー、SPIR-V ヘッダーをインストールし、その後、ドライバーが意図した GPU を列挙できることを確認します：

sudo apt-get update
sudo apt-get install -y libvulkan-dev glslc spirv-headers vulkan-tools

vulkaninfo --summary

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -S . -B build-vulkan \
  -DGGML_VULKAN=ON \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan --config Release -j

iGPU とディスクリート GPU の混合システムでは、列挙順序に注意が必要です。GGML_VK_VISIBLE_DEVICES は llama.cpp を特定の Vulkan デバイスに制限でき、起動ログは単に Vulkan デバイスの存在を報告するのではなく、選択されたカードの名前を報告する必要があります。

ROCm または HIP バックエンドのビルド

まず、ROCm が GPU を識別し、期待される gfx ターゲットを報告することを確認します。ターゲットを省略すると現在のシステムの GPU 向けにビルドできますが、デプロイハードウェアがわかっている場合、それを固定するとコンパイル作業が減ります。

rocminfo | grep -E 'Name:.*gfx' | head
hipconfig --full

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

HIPCXX="$(hipconfig -l)/clang" \
HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build-rocm \
  -DGGML_HIP=ON \
  -DGPU_TARGETS=gfx1201 \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-rocm --config Release -j

gfx1201 は実際のカードに対して報告されたターゲットに置き換えてください — その値は RDNA 4 の RX 9070/9070 XT/9070 GRE および Radeon AI PRO R9700 ファミリーに対応し、gfx1200 は RX 9060 シリーズ、gfx1100/gfx1101/gfx1102 は RDNA 3 の RX 7900/7800/7700/7600 ラインをカバーします。非サポート GPU の起動が助けられたからといって、HSA_OVERRIDE_GFX_VERSION を本番サービスにコピーしないでください；オーバーライドはコードを読み込ませるかもしれませんが、そのハードウェアを検証されたプラットフォームに変えるわけではありません。

2つのデフォルトではなく、同じワークロードのベンチマーク

1つの GGUF ファイル、同じフラッシュアテンション設定、同じレイヤーオフロード、および繰り返し実行を使用します。プロンプト処理 (pp) とトークン生成 (tg) はシステムを異なる形で試します、長コンテキストサーバーはまた、短い合成ベンチマークが逃す KV キャッシュ割り当てとメモリ圧力も追加します。

MODEL=/srv/models/model.gguf

./build-vulkan/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

./build-rocm/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

コミュニティの結果は、ユニバーサルな勝者が誤解を招くことを示しています、そして RDNA 4 の gfx1201 ターゲットは最新の明確な例です。1つの同機 RX 9070 XT サブミッションでは、Vulkan が 7B Q4_0 生成テストで ROCm の 128 token/s に対して約 143 token/s に達しましたが、後のサブミッションではビルドの変更につれてギャップが小さくなことを示しました；Vulkan と ROCm のディスカッションにはまた、プロンプト処理結果とテスト条件における大きな違いも含まれています。別個の、より詳細な OpenBenchmarking.org での RX 9070 XT と llama.cpp b6401 での実行では、Vulkan が数々の 8B クラスモデル（Qwen3-8B-Q8_0、Llama-3.1-Tulu-3-8B-Q8_0）でデコードで先行しましたが、長いプロンプト長でのプロンプト処理では HIP に劣後 — 2つのバックエンドは測定するフェーズによってリードを交代します。

ギャップはまた、特定のモデル形状で逆方向に、そしてかなり大きく走れます。オープンな llama.cpp issue は、モデルの隠れ層サイズが 4096 に達すると、トークン生成で gfx1201 上の Vulkan が HIP より 4.7–6.7 倍遅くなることを文書化しています（効果的なデコード帯域幅が 640 GB/s カードで概ね 70–100 GB/s に崩壊）、一方、隠れ層サイズ 2560 の小さな 4B モデルはどちらのバックエンドでもそのような退行を示しません。ここでのすべての数値を、1つのビルド、1つのドライバー、1つのモデル形状のスナップショットとして扱いましょう — 量子化タイプ、モデルアーキテクチャ、フラッシュアテンション、バッチサイズ、ドライバーバージョン、熱状態、または llama.cpp コミットに一般化されるルールとしてではなく。

AMD での Ollama: 便利だが、バックエンドを検証

Ollama は公式に掲載されている AMD GPU を ROCm を通じてサポートし、現在 Windows と Linux で Vulkan 経由の追加 AMD カバー範囲を文書化しています。現在の ハードウェアサポートページ は、Vulkan がバックエンドがインストールされている場合デフォルトで有効化され、デバイス選択のために GGML_VK_VISIBLE_DEVICES をサポートし、OLLAMA_VULKAN=0 で Vulkan を無効化できると述べています。

これは、Vulkan の助言が実験的ビルドに依存していた期間から有意な改善です。また、いくつかの古いチュートリアルを古くします：文書化されていないスイッチを設定し、サービスが Vulkan を選択したと仮定することは、サーバーログを読むことより弱い証拠です。

sudo systemctl edit ollama

診断のために、インタラクティブシェルでのみ変数をエクスポートするのではなく、ドロップインを追加します：

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="GGML_VK_VISIBLE_DEVICES=0"

その後、読み込み直し、再起動し、プロセス配置と検出メッセージの両方を検査します：

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -b --no-pager | tail -n 200

ollama run qwen3:8b "Return exactly: backend test passed"
ollama ps

名前付き GPU、選択されたライブラリ、モデル割り当て、GPU 割合を探します。検出タイムアウトに続き正常な HTTP 応答を示すログは、Ollama が静かに CPU にフォールバックしたことを意味するかもしれません。このサービスを中心とする日常のコマンドセットについては、Ollama CLI チートシート がより速い参照です。

Ollama は、モデル取得と安定したローカル API がバックエンド制御より重要である場合に優れています。再現可能な ROCm-vs-Vulkan テストが目標の場合、生の llama-server がより良い計器です。ビルドディレクトリがバックエンドを明示するためです。

vLLM と SGLang は ROCm を決定する — ただしまず GPU ファミリーのカーネルカバー範囲を確認

vLLM と SGLang は Vulkan アプリケーションではありません。それらの AMD パスは ROCm、PyTorch、最適化された HIP カーネルの上にありますので、これらのエンジンのいずれかを選択することは、すでにコンピューティングプラットフォームを選択したことになります。

AMD の現在の ROCm での vLLM ガイド は、プリビルトコンテナを推奨し、ROCm、PyTorch、Python、vLLM の対応イメージを公開しています。その結合は有用です：大きな依存解決演習をバージョン管理されたデプロイユニットに置き換えます。

執筆時点、AMD は vLLM 0.27 に対してこの ROCm 10 イメージを文書化しています：

docker pull \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0

docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  --ipc=host \
  --network=host \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  -v /srv/models:/app/models \
  -e HF_HOME=/app/models \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0 \
  bash

AMD の文書で正確な GPU ファミリーに対して選択されたイメージを使用してください；RDNA と CDNA イメージは常に互換性があったわけではありません。本番サーバーでは、完全なタグまたはダイジェストを固定し、vLLM を責める前にホストドライバーを検証してください。

ブランド新しい GPU 世代が最も鋭いエッジケースです、そして RDNA 4 は理論的なリスクではなく、実際の文書化された例です。2026年初頭の RX 9070 XT (gfx1201) での独立したテストは、ROCm 7.2 上の vLLM が FP8 モデル重みの FP32 量子化解除に静かにフォールバックしていることを発見しました — gfx1201 がまだ vLLM のプラットフォーム検出で認識されていなかったため — これは GPU の行列アクセラレータを完全にバイパスし、同じカード上で比較可能なモデルの GGUF 量子化を実行する Vulkan 上の llama-server の 62 token/s に対してわずか 48 token/s を生成しました。教訓は一般化します：ROCm/PyTorch スタックは新しいアーキテクチャで正常にロードでき、エラーメッセージなしで最適化されていないフォールバックパスを実行し続ける可能性があります。常に、実際にどのカーネルパスが実行されたかを確認してください（rocprof、ベンダープロファイリングノート、または GPU の既知良好スループットベースライン経由）で、最後のリリースサイクルまたは2つ以内に出货されたハードウェア上の単一の「正常に開始した」結果を信頼する前に。

カーネルカバー範囲が確認された後、ROCm のより大きな運用面を受け入れる理由は、スループットアーキテクチャです — 単一ユーザーテストで数 token/s 多いことではありません。継続的バッチング、フレームワークネイティブ量子化、テンソル並列性、スケジューラ挙動、および周囲の PyTorch ツールが、vLLM への移行 の実際の理由です、そしてその移行が本当に正当化されるかどうかを考ている場合、私たちの Ollama から vLLM への移行ガイド がワークロードシグナルを列挙しています。

TGI: より狭いターゲットでの ROCm サポート

Hugging Face は Text Generation Inference に対する AMD イメージを文書化していますが、その公開検証は Instinct MI210、MI250、MI300 ハードウェアを中心に据えられています。TGI AMD ガイド は 3.3.5-rocm イメージを使用し、サポートされない ROCm 機能を列挙していますので、すべての Radeon カードへの約束として一般化すべきではありません。私たちの TGI インストールガイド は、その ROCm イメージ設定をより詳細にカバーしています。

比較のための Vulkan TGI パスはありません。TGI が固定要件である場合、サポートされた ROCm ハードウェアを選択し、文書化されたコンテナを再現してください；エンジンが交渉可能である場合、現在の vLLM と SGLang のサポートは、新しい AMD デプロイを開始する前に評価に値します。

LM Studio: 再ビルドではなくランタイムを切り替え

LM Studio は複数の推論ランタイムをパッケージし、lms コマンドを通じてランタイム管理を公開します。その ランタイムドキュメント は、ランタイムの列挙、ダウンロード、選択、更新、削除をサポートしています。これは、別々のソースツリーを維持することなく、ROCm-vs-Vulkan 実験を可能にします。

lms runtime ls
lms runtime get
lms runtime select

同じコンテキスト長、GPU オフロード、フラッシュアテンション設定、およびプロンプトで同じ GGUF を実行します。1つの短いチャット応答からバックエンドを判断するのではなく、初回トークンまでの時間、生成レート、ロード時間、ピークメモリを比較します。

ランタイムパッケージングは、バックエンド固有の障害を排除しません。例えば、2026年の R9700 での LM Studio issue は、ROCm ロードの終わりに近づきながら大きなモデルがハングしている一方、Vulkan ランタイムがそれをロードしたと報告し、別個の Vulkan メモリ余白 issue は、VRAM ほぼ満杯時の逆の結果を説明しています。これらは個々の報告ですが、一緒に、適切な運用点を示します：フォールバックランタイムを保持し、メモリ余白を残してください。

LocalAI: バックエンドだけでなくイメージも選択

LocalAI は別々の ROCm または hipblas と Vulkan コンテナバリアントを提供します。その GPU アクセラレーションガイド は、AMD コンピュート用の gpu-hipblas イメージとポータブルパス用の gpu-vulkan イメージを文書化していますので、CUDA ガイドからコピーされたコンテナタグは、魔法で正しいバックエンドを検出しません。LocalAI クイックスタート は一般的なセットアップをカバーし、バックエンド固有のコンテナ選択がこのセクションが追加するものです。

ROCm コンテナは /dev/kfd と /dev/dri が必要ですが、Vulkan は通常、/dev/dri 下の適切なレンダリングデバイスが必要です。実際のサービスにはリリースタグを固定してください；latest と master は診断に有用ですが、ロールバックとパフォーマンス比較を不必要に曖昧にします。

# ROCm または HIP イメージ
docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  -p 8080:8080 \
  quay.io/go-skynet/local-ai:v4.8.0-gpu-hipblas

# Vulkan イメージ
docker run --rm -it \
  --device /dev/dri \
  -p 8080:8080 \
  localai/localai:v4.8.0-gpu-vulkan

タグの例は、出版時に利用可能なドキュメントを反映しています；プルを自動化する前に現在のレジストリ名を確認してください。より重要なのは、コンテナ名だけでアクセラレーションを推測しないことです — LocalAI のデバッグログを検査し、リクエスト中に GPU 使用率を観察してください。

ROCm 10 パッケージングで何が変わったか

ROCm 10 は、単なるマイナーパッケージ更新ではありません。AMD の TheRock 移行ガイド は、ROCm Core SDK パッケージが現在 amdrocm- プレフィックスを使用し、バージョン管理インストールルートの /opt/rocm/core-10.0、およびいくつかのレガシーパッケージが統合されたことを述べています。

これは、正しく設定されたリポジトリでも、古い ROCm 記事のコマンドが「パッケージが見つかりません」と返りうることの理由です。例えば、HIPCC は現在 amdrocm-llvm から来ており、BLAS コンポーネントは amdrocm-blas に結合され、完全なシステムインストールは全アーキテクチャまたは GPU ファミリー固有の Core SDK メタパッケージを使用でき — RDNA 4 カードは gfx120X-all ファミリータグ（パッケージサフィックス -gfx1200-gfx1201）を使用し、存在しない gfx1201 のみのパッケージ名を探しに行く前に知る価値があります。

amdrocm メタパッケージは /opt/rocm 下の代替手段と互換性シンボリックリンクを設定します。最小またはカスタムインストールは同じパスを提供しない可能性があるため、/opt/rocm/bin/hipcc をハードコードするビルドスクリプトは、hipconfig を使用するか ROCM_PATH を明示的に設定すべきです。

2つの診断変更が見落とされやすいです。ROCm SMI は AMD SMI に取って代わられ、ROCm Bandwidth Test は終身を迎えました；rocm-smi や rocm-bandwidth-test を呼び出すスクリプトは、無差別なレガシーパッケージを再インストールするのではなく、amd-smi と AMD の代替ツールに移行する必要があります。

コンテナは依然としてホストに依存

ROCm コンテナはカーネルドライバーの代替ではなく、ユーザー空間ライブラリを保持します。ホストは /dev/kfd と /dev/dri を公開し、そのドライバーはコンテナスタックと互換性があり、サービスユーザーはそれらのデバイスを開く権限が必要です。

Vulkan コンテナは、ホスト Vulkan ドライバーとレンダリングノード周囲に同様の境界があります。パッケージングは軽いが、誤った ICD、レンダリンググループ所属の欠如、または偶然選択された iGPU は、動作するコンテナイメージを CPU 依存または不安定なサービスに変え続け得ます。

ディスクリート GPU、APU、および古い Radeon カード

RDNA 3 と RDNA 4 ディスクリート GPU

現在の Radeon RX 7000、RX 9000、および Radeon AI Pro モデルは、llama.cpp の両バックエンドのテストにとって最も強力なケースを持っています。ROCm サポートは現在多くの gfx110x および gfx120x ターゲットに対して明示的であり、現在の Mesa RADV または Windows ベンダードライバーを介した Vulkan は、絶望的なフォールバックではなく、主要なルートとして成熟しています。その決定のハードウェア側 — ベンダー間の VRAM、帯域幅、電力、価格 — については、2026年の AI ワークロード向けの GPU 比較 を参照してください。

7B ベンチマークを 27B dense モデルまたは mixture-of-experts モデルへのルールに変換しないでください。行列形状、活性パラメータ、量子化カーネル、プロンプト長、およびメモリ圧力は順序を変える可能性があり、バックエンドパフォーマンスは llama.cpp リビジョン間で大幅に移動してきました — 上記の gfx1201 隠れ層サイズ退行は、まさにそのようなシフトの具体的なケースです。

Ryzen APU と共有メモリ

大容量メモリの Ryzen AI Max システムは、通常のカラメル消費者カードが提供するものよりはるかに大きな共有メモリプールに GPU がアクセスできるため、特に興味深いことです。ROCm 10 は現在の Ryzen AI ファミリーを列挙し、Vulkan 対応 llama.cpp ランタイムはまた、PyTorch 環境を構築することなく iGPU を使用できます。

容量は帯域幅ではありません。割り当てられた共有メモリ 64 GB または 96 GB にモデルがフィットすることは、32 GB ディスクリートカードのようにデコードされることを意味せず、積極的なコンテキスト割り当ては、アプリケーションが十分な GPU メモリを報告していても OS を飢えさせる可能性があります。ディスクリート NVIDIA および AMD カードに適用される同じ VRAM バジェット規律がここにも適用されます — バックエンド非依存の基礎的なバジェット計算については、16 GB GPU での KV キャッシュ を参照してください。

iGPU と dGPU 混合のマシンは明示的なデバイス選択が必要です。最近の llama.cpp 報告は、R9700 の横に未使用の iGPU が可視のままでは、過剰なシステムメモリ割り当てを説明しています；それは未確認の issue ですが、サービスが使用することを意図したデバイスのみを公開する良い理由です。

古いおよびサポートされない Radeon ハードウェア

Vulkan は通常、古い Radeon にとって最初のルートです。グラフィックドライバーの範囲が ROCm のサポートされたコンピューティングターゲットセットより広いからです。ROCm ベースのプロジェクトもまた、新しい rocBLAS リリースが一部の古いターゲットのカーネルを削除したことを注記していますので、近くの gfx 値を強制しても、もはや出货されないコードを復元することはできません。

オーバーライドは、明確な失敗期待を持つ実験室実験には許容されます。監視されない API のための悪い基盤です、次の ROCm またはアプリケーション更新が、許容された不一致を起動失敗または誤った結果に置き換え得るためです。

AMD LLM バックエンドのための Linux vs Windows

Linux は本番推論のための自然な ROCm ホストです。最も広いエンジンサポート、確立されたコンテナデバイスマッピング、現在の Mesa Vulkan ドライバー、および vLLM と SGLang デプロイが期待する運用ツールを提供します。

Windows は掲載されたハードウェアに対して真の ROCm サポートを持っていますが、アプリケーションエコシステムは依然として狭いです。llama.cpp、Ollama、または LM Studio を通じたデスクトップ GGUF 推論にとって、Vulkan は通常より静かな出発点です；アプリケーションがサポートされた Windows パスを提供し、具体的な機能またはベンチマークがそれを正当化する場合 ROCm を使用してください。

WSL2 は、ネイティブ Linux の同義語ではなく、第三のプラットフォームとして扱うべきです。AMD の文書化された Windows ドライバー、WSL 分布、ROCm リリース、およびフレームワークパッケージを1つのサポートされた組み合わせとして一致させます。

トラフィック提供前の検証チェックリスト

アプリケーションの下から始めます。ドライバーが正しいデバイスを列挙できない場合、モデルフラグの変更は単に症状の並べ替えです。

lspci -nnk | grep -A3 -E 'VGA|Display'
ls -l /dev/kfd /dev/dri/renderD* 2>/dev/null
id

# ROCm パス
rocminfo | grep -E 'Marketing Name:|Name:.*gfx' | head -n 20
amd-smi list

# Vulkan パス
vulkaninfo --summary

その後、エンジンを検証します。起動出力は ROCm または Vulkan を名前をつけ、意図した GPU を名前をつけ、モデルレイヤーまたはテンソルがそれに配置されたことを報告する必要があります；最後に、リクエストが実行されている間に GPU メモリと使用率が上昇する必要があります。

# 別ターミナルでリクエストを送信しながら AMD GPU を観察
watch -n1 amd-smi monitor

# llama-server の基本的な OpenAI 互換 API チェック
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local-model",
    "messages": [{"role": "user", "content": "Return exactly: ready"}],
    "max_tokens": 8,
    "temperature": 0
  }'

すべてのベンチマークで、ドライバー、ランタイム、エンジンコミットまたはイメージダイジェスト、モデルファイルチェックサム、コンテキスト、バッチ設定、およびコマンドラインを記録します。そのメタデータなしに、秒間トークン数は次のアップグレードで生き残れない伝聞です — そして vLLM-on-gfx1201 のフォールバックおよび上記の Vulkan 隠れ層サイズ退行の両方が示すように、見た目通りの数字が静かに最適化されていないコードパスを隠す可能性があります。

バックエンドパフォーマンスのように見える失敗モード

静かな CPU フォールバック

サーバーは正常に起動し、正しく応答しますが、生成は意図せず遅く、GPU 使用率は平坦のままです。スレッドやサンプリングパラメータを調整する前に、検出ログ、デバイス権限、モデルオフロード、およびコンテナデバイスをチェックしてください。

静かな精度フォールバック (新しいハードウェア、新しいカーネル)

サーバーは起動し、GPU 使用率は合理的に見え、エラーはありません — ただし、GPU の計算能力またはアーキテクチャ文字列がまだ認識されていなかったため、フレームワークが静かに最適化されていない数値パスに落ちました。これはまさに gfx1201 での vLLM の FP8 カーネルで起こったことです；最後のリリースサイクルまたは2つ以内にリリースされた GPU 世代上の単一のスループット数を信頼する前に、正確な GPU 文字列に対してフレームワーク自身のプラットフォーム検出コードまたは issue トラッカーをチェックする修正です。

誤った GPU が選択される

Ryzen デスクトップは、iGPU を Vulkan デバイス 0 として、ディスクリート Radeon をデバイス 1 として公開することがあります。可視デバイスを制限し、ログで完全なデバイス名を確認してください；ドライバーまたは BIOS 変更後に番号付けが安定していると仮定しないでください。

ROCm ターゲット不一致

rocminfo が1つの gfx ターゲットを報告する一方で、アプリケーションイメージが別のセットのカーネルを含む。対応するイメージを使用するか、正確なターゲットに対して再ビルドしてください；HSA_OVERRIDE_GFX_VERSION は明示的にサポートされない実験のために予約してください。

ドライバーとユーザー空間の不整合

コンテナには現在の ROCm ライブラリがありますが、ホストドライバーは古いリリースストリームに属します。検出中のタイムアウト、カーネル起動エラー、または CPU へのフォールバックは、バージョン境界を説明するクリーンなメッセージよりも可能性が高いです。

Vulkan ICD の混乱

複数の Vulkan 実装がインストールされており、ローダーが予期しない ICD を選択します。vulkaninfo を検査し、誤った重複を削除するか、意図した ICD とデバイスを明示的に選択してください。問題の上に別 SDK を積むのではなく。

VRAM 見積もりは運用余白を残さない

モデルはフィットするように見えますが、ウォームアップ、フラッシュアテンションセットアップ、または最初の長いプロンプト中に失敗します。大きなモデルで数 GB の余白を残し、バックエンドが量子化を実行できないと結論付ける前に、コンテキストまたはバッチサイズを減らします。

実用的なバックエンド選択手順

ステップ 1: サービング挙動を選択

目標が1つか2つのローカルユーザー、GGUF ファイル、および単純な OpenAI 互換エンドポイントであれば、llama-server、Ollama、または LM Studio から始めます。目標が継続的バッチング、高並行性、フレームワークネイティブモデル、またはテンソル並列性であれば、vLLM または SGLang から始め、ROCm を設計の一部として受け入れます。

ステップ 2: 公式ハードウェアサポートを確認

現在の ROCm マトリックスで、正確な GPU ターゲット、OS バージョン、カーネル、ドライバーを一致させます。Vulkan については、vulkaninfo を通して意図した GPU を確認し、libvulkan.so の存在が有用なコンピューティングサポートを証明すると仮定するのではなく、現在のドライバーを使用します。GPU が最新のアーキテクチャ世代からのものである場合、公式サポートと最適化カーネルサポートは常に一緒にリリースされるわけではないため、その正確な gfx ターゲットに対して特定のフレームワークのプラットフォーム検出コードまたはオープン issue も確認してください。

ステップ 3: 最も単純な動作ベースラインを確立

GGUF について、Vulkan は通常そのベースラインです、システムコンポーネントを少なく変更するためです。PyTorch エンジンについては、無関係な最新バージョンから torch、Triton、AITER、vLLM を組み立てるのではなく、AMD の固定 ROCm コンテナを使用してください。

ステップ 4: 本番形状のプロンプトのベンチマーク

プロンプト処理、初回トークンまでの時間、デコードレート、ピークメモリ、および並行リクエスト挙動を測定します。実際のサービスが使用するコンテキストとツールコールパターンを含め；128 トークンのマイクロベンチマークは 100,000 トークンのエージェントセッションを予測しません。

ステップ 5: フォールバックをデプロイ可能な状態に保つ

2つの llama.cpp ビルドディレクトリは、ドライバー退行による1日の損失と比較して少ないコストです。最後に既知良好のコンテナダイジェストまたはランタイムをインストールし、候補が同じテストセットを通過する後にのみ前方へロールします。

同じ手順を決定フローとして：

flowchart LR A["サービングエンジンを選択"] --> B{"PyTorch/HIP エンジン？"} B -- はい --> C["ROCm: 固定コンテナ
+ カーネルカバー範囲チェック"] B -- いいえ --> D{"AMD GPU 上の GGUF？"} D -- はい --> E["Vulkan ベースライン"] E --> F{"ベンチマーク: ROCm が
測定可能な余分で勝利？"} F -- はい --> G["ROCm に切り替え"] F -- いいえ --> H["Vulkan を維持、
ROCm ビルドをフォールバックとして維持"]

最終裁定: AMD LLM ホスティングのための ROCm か Vulkan か

Vulkan は、ポータビリティ、セットアップ速度、Windows サポート、または古い Radeon カバー範囲が重要である場合の、ローカル GGUF 推論の最良のデフォルトです。それが本質的に遅いと説明するのはもはや合理的ではありません；最近の Radeon と llama.cpp の組み合わせの一部ではそれがより速いバックエンドであり、他のものでは、低い運用摩擦が勝つほどに十分近いです。

ROCm は、エンジンが PyTorch の周りに構築されている場合、AMD Instinct とマルチ GPU コンピュートが中心である場合、またはテストされた HIP ビルドが実際のモデルワークロードに勝利する場合の正しい選択です。2026年にそのエコシステムははるかに強力ですが、新しいパッケージングと厳格な互換性レイヤーは依然として固定バージョンと規律ある検証を報酬し — 特に最新の RDNA 世代では、最適化カーネルパスが実際に実行されたことを検証することは必須です。

サポートされた Radeon ワークステーションについて、私の推奨は意図的に非ロマンチックです：まず Vulkan をインストールし、エンジンまたはベンチマークが複雑さを得たときに ROCm を追加し、マシンが定期的に異なるモデル形状を提供する場合は両方の llama.cpp ビルドを保持してください。最良の AMD バックエンドはカードの恒久的な性質ではなく、カード、エンジン、モデル、ドライバー、およびワークロード全体の性質です。

参照

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。