技術 約11分で読めます

Radeon 8060S (gfx1151) のVulkanがAMDドライバ更新後に壊れた

AMD Vulkan GPU llama.cpp LLM

先月、AMDドライバを26.2.2に更新したらVulkan GPU推論が正常に動くようになった。abliterated版のQwen 3.5が54 t/s出て、VRAMの共有メモリ優先問題も解消し、やっとEVO-X2のGPUがまともに使えるようになったと思っていた。

AMD Software 26.3.1に更新したら、また壊れた。Vulkan経由でモデルをロードすると「成功」と報告されるのに、実際にはVRAMにデータが載らずシステムRAM経由のCPU処理に落ちている。ドライバ26.2.2で34〜54 t/s出ていた同じモデル・同じ設定で 4〜9 t/s まで劣化した。さらに調査を進めると、Vulkanのロード失敗を繰り返すとデバイスメモリがリークし、再起動するまで回復しないことが判明した。再起動直後なら50+ t/sが出るので、ドライバのメモリ管理にバグがあることはほぼ確実だ。

環境

項目値
PCGMKtec EVO-X2 (NucBox_EVO-X2)
CPUAMD Ryzen AI Max+ 395 (Zen 5 / 16C 32T)
GPUAMD Radeon 8060S (gfx1151, RDNA 3.5)
メモリ64GB UMA（システム16GB / VRAM 48GB）
OSWindows 11 Pro 10.0.26200
AMD ドライバ32.0.23033.1002（ビルド日: 2026-03-09）
AMD Software26.3.1（インストール日: 2026-03-22）
LM Studio0.4.8
llama-serverb8183 (66d65ec29)

Ryzen AI Max+ 395 はCPUとGPUが同じダイに載ったAPUで、メモリはUMA（Unified Memory Architecture）構成になっている。64GBの物理メモリをシステムとVRAMで共有し、BIOS設定でVRAM割り当てを48GBに設定している。UMA構成の詳細やVRAM配分の最適化は以前の記事で解説した。その記事で報告した「VRAMではなく共有メモリに優先配置される」問題はドライバ26.2.2で修正されたが、今回26.3.1で再発している。通常のディスクリートGPUと違い、CPUとGPUが同じメモリバスを共有するため、Vulkanドライバのメモリ管理がおかしくなると影響が大きい。

症状

1. GPUが使われない（CPUフォールバック）

Vulkanバックエンドでモデルをロードすると成功扱いになるが、実際にはGPU演算されずシステムRAM経由のCPU処理になる。

テスト速度26.2.2での実測値
b8183 Vulkan Q4_K_XL (20.7GB)9.5 t/s35 t/s
b8183 Vulkan Q6_K + --no-direct-io4.4 t/s41 t/s
b8183 CPU IQ2_XXS (9.8GB)13.4 t/s14.4 t/s

前回の検証ではドライバ26.2.2でQ4_K_Mが35 t/s、Q6_Kが41 t/s、abliterated Q6_Kに至っては54 t/sまで出ていた。それがVulkan経由で純粋なCPU推論より遅い状態になっている。モデルデータがVRAMではなくシステムRAMに配置され、GPUカーネルがシステムRAMからデータを読みに行く（あるいはそもそもGPUカーネルが走っていない）状態だろう。メインメモリの使用量も異常に大きく、VRAMにデータが載っていないことを裏付けている。

2. ErrorOutOfDeviceMemory

Vulkanが 54,305 MiB free と報告しているにもかかわらず、26.8GBの Q6_K モデルを確保できない。

vk::Queue::submit: ErrorOutOfDeviceMemory

VK_ERROR_OUT_OF_DEVICE_MEMORY はVulkan APIが返すエラーコードで、デバイス（GPU）側のメモリ割り当てに失敗したことを意味する。空き容量が十分あるのにこのエラーが出るのは、ドライバがメモリプールの管理を誤っているか、UMA環境でのメモリタイプのマッピングがおかしいかのどちらかだ。

3. ゴミ出力（mmap=true時）

Q4_K_XL を mmap=true でロードすると、モデル出力が完全に壊れる。

说完ak觉得 ,一ば った跟不会 . sieme 只言却 ...

中国語・日本語・英語が混ざった意味不明な文字列が出力される。これはモデルの重みデータが正しくVRAMに転送されていない（あるいは転送中に化けている）典型的な症状だ。mmap経由でホストメモリにマッピングされたデータをVulkanバッファにコピーする際に、ドライバ側でアドレス計算かDMA転送を誤っている可能性がある。

mmap=false にすると出力は正常になるが、速度は大幅に劣化する。前回の検証で --no-mmap 指定時にシステムメモリ使用量が28GBから8.8GBに改善し、速度もわずかに向上した実績があるので、mmap周りのドライバ実装が26.3.1で退行したとみるのが自然だ。

4. 最新ビルド(b8560)ではさらに悪化

llama.cpp の最新ビルド b8560 に更新すると、状況がさらに悪化した。

ggml_vulkan: Device memory allocation of size 907872256 failed.
ggml_vulkan: vk::Device::allocateMemory: ErrorOutOfDeviceMemory

0.9GB（約907MB）のアロケーションすら失敗する。b8183では20GBクラスのモデルが（遅いながらも）ロードできていたのに、b8560ではギガバイト単位の割り当てすらできない。llama.cpp側のVulkanメモリ割り当て戦略の変更もあり得るが、ドライバ側の問題と複合している。

5. デバイスメモリリーク

上記の症状を繰り返し検証しているうちに、もうひとつ厄介な問題が見えてきた。Vulkanのロード失敗を繰り返すと、デバイスメモリがリークして回復しなくなる。

再起動直後に同じテストを実行すると、記事時点の性能（50+ t/s）が再現できる。しかしロード失敗や ErrorOutOfDeviceMemory が数回発生すると、以降はどのモデルも正常にVRAMを確保できなくなる。LM Studioやllama-serverのプロセスを終了してもVRAM使用量が元に戻らない。

つまり、上記の速度劣化やメモリ確保エラーは「常に起きる」のではなく「一度失敗するとセッション中ずっと引きずる」タイプの問題だった。ドライバがVulkanリソースの解放に失敗し、確保したデバイスメモリを返却していない。UMA環境ではVRAMとシステムRAMが物理メモリを共有しているため、VRAMリークはシステム全体のメモリ圧迫にも直結する。

この発見で、検証結果の解釈も変わる。前述の速度テストで 9.5 t/s や 4.4 t/s という数値が出ているが、これはメモリリークが蓄積した状態での計測だった可能性がある。再起動直後のクリーンな状態なら、もう少しマシな数値が出るかもしれない。ただし、それでも不安定であることに変わりはない。

発生経緯

graph TD
    A["3/1: ドライバ 26.2.2<br/>Q6_K Vulkan 34-48 t/s<br/>正常動作"] --> B["3/9: 現ドライバのビルド日"]
    B --> C["3/13: AMD チップセットドライバ更新"]
    C --> D["3/16: Q6_K ロード試行<br/>ErrorOutOfDeviceMemory"]
    D --> E["3/22: AMD Software 26.3.1<br/>インストール"]
    E --> F["3/23: Q4_K_XL mmap=false<br/>19.5 t/s 動作するが遅い"]
    F --> G["3/27: LM Studio 0.4.8 更新"]
    G --> H["3/28: Q4_K_XL mmap=true<br/>22.6 t/s だがゴミ出力"]
    H --> I["3/28: Q5_K_XL / Q6_K<br/>ErrorOutOfDeviceMemory"]
    I --> J["3/28: メモリリーク発見<br/>再起動で50+ t/s復帰"]

    style A fill:#4CAF50,color:#fff
    style D fill:#FF9800,color:#fff
    style H fill:#f44336,color:#fff
    style I fill:#f44336,color:#fff
    style J fill:#2196F3,color:#fff

注目すべきポイントがいくつかある。

3/16の時点で既にQ6_Kが ErrorOutOfDeviceMemory で失敗していた。3/13のチップセットドライバ更新が引き金かもしれない。AMD Software 26.3.1 のインストールは3/22なので、問題の発端はそれ以前だ。

3/23に Q4_K_XL が 19.5 t/s で動作したが、3月初旬の同モデルの速度は 35 t/s だった。一見「動いている」ように見えて、実はこの時点で既にパフォーマンスが半減していた。VRAMへの配置が部分的にしか機能していなかったのだろう。メモリリークの件を踏まえると、この時点で既にリークが蓄積していたのだろう。

3/28にメモリリークの存在を確認した。再起動直後なら50+ t/sが出ることから、ドライバのメモリ管理自体は初期状態では正常に動作する。ロード失敗やエラーを契機にリークが始まり、セッション中に蓄積していく。

問題の切り分け

この問題がドライバ起因なのか llama.cpp 起因なのかを切り分ける材料を整理する。

ドライバ起因を示す証拠

llama.cpp 起因の可能性

  • b8560 で状況が悪化した（Vulkanメモリ割り当て戦略の変更）
  • ただし b8183 でも既に劣化していたので、根本原因ではない

UMA固有の問題

  • UMA環境ではVulkanのメモリタイプ（DEVICE_LOCAL、HOST_VISIBLE など）の扱いがディスクリートGPUと異なる
  • ドライバがUMA環境で DEVICE_LOCAL メモリを正しくアドバタイズしていない、あるいはアロケーション時に誤ったメモリタイプを選択している可能性がある
  • EVO-X2の初期セットアップ時から一貫してUMA環境でのドライバ不具合に悩まされている。VRAM配分の検証記事で発見した「VRAMではなく共有メモリに優先配置される」問題はドライバ26.2.2で修正されたことを確認済みだが、26.3.1で同じ症状が再発している
  • メモリリークがUMA環境で特に深刻なのは、リークしたVRAMがシステムRAM側の可用性にも影響するため。ディスクリートGPUならGPUメモリがリークしてもシステムRAMは無事だが、UMAでは共有プール全体を食いつぶす

暫定対処

現時点で試せる対処法は限られている。

対処法効果・注意点
再起動メモリリークをリセットする最も確実な方法。再起動直後なら50+ t/sが出る。ただしロード失敗でリークが再発するため、大きすぎるモデルのロード試行は避ける
mmap=false 指定ゴミ出力は防げるが速度は大幅に劣化する
小さい量子化モデル（Q4_K_XL以下）ErrorOutOfDeviceMemoryを回避できるが品質は下がる。リーク防止の観点でも確実にロードできるサイズに収めておきたい
CPU推論IQ2_XXSで13.4 t/s。リークが蓄積した状態のVulkanより速い
ドライバのロールバック（26.2.2）35〜54 t/sの実績あり。復旧する見込みが高い。AMD Softwareでクリーンインストールが必要

根本的にはAMDのドライバ修正待ちだ。gfx1151 (RDNA 3.5) は新しいアーキテクチャで、Vulkanドライバの成熟にはまだ時間がかかる。2月末のOllama全滅も3月初旬のVulkanクラッシュも結局AMDドライバの更新で解決した実績があるので、次のドライバリリースに期待するしかない。ただし今回は「新しいドライバで壊れた」パターンなので、ロールバックが最も確実な暫定策になる。llama.cpp の Issue や AMD Community Forum で同様の報告がないか確認し、再現情報を提供するのが進展への近道だ。GPU推論が使えない間、Tailscale経由のAPI化もCPU推論にフォールバックするため、外部からの推論リクエストも大幅に遅くなる点に注意。

ドライバ26.2.2で全部直ったと喜んでいたら、26.3.1でまた壊れた。しかも今回はメモリリークというおまけ付きで、検証を繰り返すほど状態が悪化していくという嫌がらせのような挙動だった。再起動すれば一時的に復活するのが救いだが、安定運用とは程遠い。時系列を振り返ると、EVO-X2の初期セットアップでVulkan周りの不安定さに気づき、VRAM配分の検証で共有メモリ優先問題を特定し、Ollama全滅事件を経てドライバ更新で一括解決。ここまでが2月末〜3月初旬の話で、それから1ヶ月も経たずに振り出しに戻った。もう3回目のドライバ起因トラブルだ。UMA + 新アーキテクチャという組み合わせはドライバの地雷を踏みやすい。しばらくはCPU推論で凌ぎつつ、次のドライバアップデートに期待するしかない。

関連記事