【RX 9070 XT】VulkanとROCm、どっちが速い？OllamaとLM Studioで実測比較【ローカルLLM】

前回の記事では、RX 9070 XTでローカルLLMが「普通に戦える」ことを確認した。

その際バックエンドの話は「とりあえずVulkanでOK」で済ませたが、今回はその宿題を回収する。VulkanとROCm、結局どっちが速いのか。 同じマシン・同じモデル・同じ日に、条件を揃えて実測した。

先に断っておくと、結果は「どちらかが常に勝つ」という単純なものにはならなかった。だが、だからこそ面白い。自分の使い方ならどちらを選ぶべきかが、この記事を読めば判断できるはずだ。

【結論】用途とモデルで勝者が入れ替わる
【前提】計測環境と条件
【本題1】トークン生成速度：基本はVulkan優勢
【本題2】プロンプト処理速度：長文を読ませるならROCm
【検証】Flash Attentionの影響：生成には効かないが、読み込みには絶大
【手順】バックエンドの切り替え方法
1. Ollama：環境変数で切り替える
2. LM Studio：ランタイムを選ぶだけ（CLIでも可）
【検証】ツールが違うと結果は変わるのか：LM Studioでも測ってみた
【つまずきポイント】ベンチマークの落とし穴4連発
【まとめ】「一度測って決めて、たまに測り直す」
参考文献

【結論】用途とモデルで勝者が入れ替わる

いきなり結論の表から。

観点	勝者	例外
トークン生成速度（チャットの体感）	Vulkan（+23〜45%）	gpt-oss:20bだけはROCmが+15%
プロンプト処理速度（長文読み込み）	ROCm（+16〜76%）	gpt-oss:20bだけはVulkanが2.2倍
VRAM超過時（CPUに溢れる大型モデル）	生成はVulkan、読み込みはROCm	どちらも一長一短

つまり、チャットや文章生成が中心ならVulkan、RAGや長文要約など「読ませる」用途が多いならROCmという使い分けが基本線になる。ただしgpt-oss:20bのように傾向が真逆になるモデルもあるため、常用モデルが決まっているなら自分で測るのが最終回答だ（測り方も本記事で解説する）。

なおこの傾向はOllamaでもLM Studioでも同じだった（後半で検証する）。どちらも中身は同じllama.cppなので、バックエンド選びの結論はツールをまたいで使い回せる。

【前提】計測環境と条件

環境は前回と同じ。

項目	スペック/バージョン
GPU	Radeon RX 9070 XT 16GB
CPU	Ryzen 9 7900X
RAM	DDR5 64GB
OS	Windows 11 25H2
AMD Software	26.1.1
Ollama	0.30.10
LM Studio	llama.cpp ランタイム 2.23.1（Vulkan / ROCm とも）

計測条件は次のとおり。すべて同じ日・同じマシン・モデル単独ロードで、バックエンドだけを切り替えて測っている。

生成速度（tg）: 同一プロンプトで300トークン生成 × 3回の平均。temperature 0
プロンプト処理速度（pp）: 約2,000トークンの長文を読み込ませ、処理速度を3回計測。プロンプト先頭を毎回変えてキャッシュを無効化
Flash Attention有効。ロードのたびに空きVRAM（15.3GiB）を確認
どのバックエンドで動いているかは、サーバーログのinference compute行（library=ROCm / library=Vulkan）で毎回確認

ばらつきはどの計測も±1%程度で、再現性は良好だった。なお絶対値は日やマシンの状態で1〜2割変動することを先に断っておく（実際、前回記事のgemma4は約91 tok/s、今回は約69 tok/sと差が出ている）。本記事の主眼はあくまで「同一条件でのバックエンド間の比較」だ。

【本題1】トークン生成速度：基本はVulkan優勢

まず、チャットの体感を支配する生成速度から。

モデル	種別	ROCm	Vulkan	差
gemma4（7.5B級）	dense	69.3 tok/s	100.2 tok/s	Vulkan +45%
gpt-oss:20b	MoE	74.4 tok/s	64.8 tok/s	ROCm +15%
qwen3:14b	dense	49.1 tok/s	60.6 tok/s	Vulkan +23%
gemma4:26b（VRAM超過）	MoE	28.0 tok/s	36.6 tok/s	Vulkan +31%

4モデル中3つでVulkanの勝ち、それも1〜4割という無視できない差だ。gemma4 7.5Bに至ってはVulkanで100 tok/s超えを記録した。「Vulkan＝互換性重視の遅い方」というかつての常識は、少なくともRDNA4では完全に過去のものである。

興味深いのはVRAMから溢れているgemma4:26bでもVulkanが勝つこと、そしてgpt-oss:20bだけが逆転してROCm勝ちなことだ。MoEだから、という単純な話でもない（同じMoEの26bはVulkan勝ち）。カーネル実装とモデル構造の相性としか言いようがなく、これが「最後は自分のモデルで測れ」という結論の根拠になっている。

【本題2】プロンプト処理速度：長文を読ませるならROCm

次に、RAGや長文要約で効いてくるプロンプト処理速度。約2,000トークン（この記事の半分くらいの分量）を読み込ませた。

モデル	種別	ROCm	Vulkan	差
gemma4（7.5B級）	dense	2,797 tok/s	2,371 tok/s	ROCm +18%
gpt-oss:20b	MoE	1,316 tok/s	2,881 tok/s	Vulkan +119%
qwen3:14b	dense	1,546 tok/s	1,331 tok/s	ROCm +16%
gemma4:26b（VRAM超過）	MoE	730 tok/s	414 tok/s	ROCm +76%

今度はROCmが4モデル中3つで勝ち。生成速度とちょうど鏡写しの結果になった。とくにVRAM超過時（gemma4:26b）は差が76%まで開く。数千〜数万トークンの文書を読ませる使い方なら、この差は待ち時間として体感できるレベルだ。

そしてここでもgpt-oss:20bだけが真逆で、Vulkanが2.2倍という大差をつけた。gpt-ossを常用しているなら「生成もROCm、読み込みもVulkan」と、他のモデルと正反対の選択になる。面白いものである。

なお、Vulkanには「初回だけプロンプト処理が遅い」という癖がある。今回の計測でも、長文の1回目だけ他の回の3分の1程度の速度しか出なかった（2回目以降は安定）。シェーダーコンパイルによるウォームアップと思われる。Vulkanで測るときは1回目の数値を捨てること。

【検証】Flash Attentionの影響：生成には効かないが、読み込みには絶大

Ollamaは近年のバージョンでFlash Attention（FA）を自動有効化するが、環境変数OLLAMA_FLASH_ATTENTION=0で切ることもできる。オン/オフでどれだけ変わるかも測った（gemma4 7.5B）。

条件	生成速度	プロンプト処理速度
ROCm + FAオン	69.3 tok/s	2,797 tok/s
ROCm + FAオフ	65.3 tok/s	604 tok/s
Vulkan + FAオン	100.2 tok/s	2,371 tok/s
Vulkan + FAオフ	102.0 tok/s	530 tok/s

生成速度はFAの有無でほぼ変わらない（±5%）。ところがプロンプト処理はFAオンで4.5〜4.6倍という劇的な差がつく。バックエンドを問わずだ。もし長文の読み込みが妙に遅いと感じたら、バックエンドを疑う前にFAが有効かを確認したほうがいい。ログにflash attention is enabledと出ていれば有効である。

【手順】バックエンドの切り替え方法

Ollama：環境変数で切り替える

Ollamaは起動時にバックエンドを自動選択する（筆者環境ではROCm）。強制的に切り替えるには、タスクトレイのOllamaを終了したうえで、環境変数OLLAMA_LLM_LIBRARYを設定してターミナルから起動する。

# Vulkanで起動する場合
$env:OLLAMA_LLM_LIBRARY = "vulkan"
ollama run gemma4:latest --verbose

# ROCmを強制する場合は "rocm_v7_1"（Ollamaのlib\ollamaフォルダ名に対応）

これはそのターミナル内でのみ有効な一時設定だ。恒久化したいならsetxで設定してOllamaを再起動する。どちらで動いたかは%LOCALAPPDATA%\Ollama\server.logのinference compute行で確認できる。

LM Studio：ランタイムを選ぶだけ（CLIでも可）

LM StudioはGUIの設定（Runtime）でVulkan/ROCmを切り替えられるほか、実はCLI（lmsコマンド）でも操作できる。

# ROCmランタイムの導入（約210MB）
lms runtime get llama.cpp-win-x86_64-amd-rocm-avx2

# 切り替え
lms runtime select llama.cpp-win-x86_64-amd-rocm-avx2@2.23.1

切り替え後にモデルをロードし直せば反映される。

【検証】ツールが違うと結果は変わるのか：LM Studioでも測ってみた

OllamaもLM Studioも中身は同じllama.cppだ。では、ツールを変えても同じ結果になるのか。LM Studio側でも条件を揃えて（gemma4系7.5B・FAオン・dGPU固定・コンテキスト4096）両バックエンドを測った。

計測	ROCm	Vulkan	勝者
Ollama：生成速度	69.3 tok/s	100.2 tok/s	Vulkan
LM Studio：生成速度	76.3 tok/s	107.4 tok/s	Vulkan
Ollama：プロンプト処理	2,797 tok/s	2,371 tok/s	ROCm
LM Studio：プロンプト処理	3,812 tok/s	2,886 tok/s	ROCm

結果、勝敗の傾向は完全に一致した。 生成はVulkan、長文読み込みはROCm。このモデルに関しては、どちらのツールを使っていても選ぶべきバックエンドは同じ、ということだ。

絶対値はLM Studioのほうが1割ほど高く出ているが、これは同梱するllama.cppの世代差やバッチ設定の違いによるものだろう（プロンプト処理は計測方法も異なるため、ツール間の絶対値比較は参考程度に）。

ただし、これは「条件を揃えれば」の話である。 素の設定のままだと、話は大きく変わる。LM Studioのデフォルト（コンテキスト8192・並列4・Flash Attentionオフ）でROCmを測ると、生成66.8 tok/s・プロンプト処理はわずか247 tok/sまで落ちた。条件を揃えた場合（3,812 tok/s）と比べて15倍差である。ツールの差に見えるものの正体は、大半がデフォルト設定の差だ。LM Studioで長文を扱うなら、モデルロード設定でFlash Attentionをオンにしておくことを強くおすすめする。

【つまずきポイント】ベンチマークの落とし穴4連発

今回の計測では、数値がおかしくなる罠に立て続けにハマった。同じことを試す人のために共有しておく。

罠1：前のモデルがVRAMに残っている。 Ollamaは使い終わったモデルを既定で5分間VRAMに残す。この状態で別のモデルを測ると大幅に遅くなる（前回記事ではqwen3:14bが51→18 tok/sまで落ちた）。ollama stop モデル名でアンロードし、ollama psで空を確認してから測ること。

罠2：孤児プロセスがVRAMを占拠している。 Ollamaを再起動したつもりでも、ランナープロセス（llama-server.exe）が残ってVRAMを数GB掴んだままのことがある。実際、今回4.3GB掴んだ孤児のせいで初回の計測が全滅した。タスクマネージャーの「専用GPUメモリ」列か、次のコマンドで空きを確認してから計測を始めるとよい。

Get-Process -Name "ollama","llama-server" -ErrorAction SilentlyContinue | Stop-Process -Force

罠3：LM StudioのVulkanが内蔵GPUを掴む。 これが今回最大のハマりポイントだった。Ryzen内蔵GPU（Radeon Graphics）があるマシンでは、LM StudioのVulkanランタイムがdGPUではなく内蔵GPU側でモデルを実行してしまうことがある。症状は「エラーは出ないのに異常に遅い」（筆者環境では5.3 tok/s。本来は107）。タスクマネージャーのGPU使用率を見ると、RX 9070 XTが暇をしていて内蔵GPUのComputeが張り付いている。対処はLM Studioの設定（ハードウェア）で内蔵GPUを無効化すること。ROCmランタイムは内蔵GPUを対象外として扱うため、この問題が起きない。ちなみにllama.cppの環境変数GGML_VK_VISIBLE_DEVICESはLM Studioには効かなかった（LM Studio側がデバイスリストを明示的に渡しているため）。スクリプトから制御したい人は、lmsのSDK（@lmstudio/sdk）でロード時にgpu: { disabledGpus: [1] }を指定すれば回避できる。

罠4：Vulkanの初回プロンプト処理は遅い。 前述のとおり、シェーダーコンパイルのため初回だけ数値が低く出る。ベンチマークでは1回目を捨てて2回目以降を採用すること。