技術 約15分で読めます

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が出るので、ドライバのメモリ管理にバグがあることはほぼ確実だ。最終的にBIOSのVRAM配分を48GB/16GBから32GB/32GBに変更することで、Q6_Kが53.7 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
日付イベントVulkan性能
3/1記事執筆。ドライバ 26.2.234-48 t/s 正常動作
3/9現ドライバのビルド日-
3/13AMD チップセットドライバ更新-
3/16Q6_K ロード試行ErrorOutOfDeviceMemory
3/22AMD Software 26.3.1 インストール-
3/23Q4_K_XL ロード (mmap=false)19.5 t/s（正常だが半減）
3/27LM Studio 0.4.8 更新-
3/28Q4_K_XL (mmap=true)22.6 t/s だがゴミ出力
3/28Q5_K_XL / Q6_KErrorOutOfDeviceMemory
3/28メモリリーク発見再起動で50+ t/s復帰

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

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では共有プール全体を食いつぶす

関連 Issue

gfx1151 の Vulkan 問題は自分だけではなく、複数のプロジェクトで報告されている。

Issue内容ステータス
lmstudio-ai/lmstudio-bug-tracker#1048Vulkan v1.52.0 が gfx1151 で VRAM を使わない。3倍遅いfixed-in-next-update
ggml-org/llama.cpp#16832Vulkan UMA メモリ検出バグ（32GB しか認識しない）Closed (PR #17110)
ggml-org/llama.cpp#20354Vulkan に GATED_DELTA_NET シェーダーが無い（gfx1151）Open
ggml-org/llama.cpp#18741Strix Halo Vulkan ロード失敗。--no-direct-io で回避Closed
GPUOpen-Drivers/AMDVLK#413AMDVLK 2GB 割り当て上限Open
LostRuins/koboldcpp#1980koboldcpp でも 8060S の VRAM が認識されない-

llama.cpp だけでなく koboldcpp や LM Studio でも同様の問題が出ており、アプリケーション側ではなくドライバ側の問題であることを裏付けている。AMDVLK#413 の 2GB 割り当て上限は今回の ErrorOutOfDeviceMemory と直接関連する可能性がある。

試したこと

対策結果
--no-mmapロードは通るが GPU 未使用（9.5 t/s）
--no-direct-ioQ6_K ロード可能になるが GPU 未使用（4.4 t/s）
llama.cpp b8560（最新）悪化。0.9GB すら確保失敗
LM Studio mmap OFFmmap=false になるが ErrorOutOfDeviceMemory
PC 再起動メモリリーク解消、50+ t/s 復帰

再起動後のテスト結果

メモリリーク問題の発見を受けて、PC再起動後にクリーンな状態で記事と同じコマンドを実行した。

llama-server.exe -m "Huihui-Qwen3.5-35B-A3B-abliterated.Q4_K_M.gguf" --port 8080 --ctx-size 4096 --reasoning-budget 0 --n-gpu-layers 99 --no-mmap
項目結果
ロード成功（Vulkan0 = 19,905 MiB）
生成速度54.9 - 57.7 t/s
記事時点49.18 t/s
出力品質正常（日本語も問題なし）

再起動直後は記事以上の速度が出た。ただし Vulkan_Host に 272 MiB が配置されており、完全にVRAMに乗っているわけではない（共有メモリ経由）。ドライバ26.2.2では Vulkan_Host への退避は発生していなかったので、26.3.1 でメモリ配置のロジックが変わっていることは確かだ。

メモリリークの再現

再起動前後の比較。

状態結果
再起動前Device memory allocation of size 1025582592 failed → 1GB 割り当て失敗
再起動後Vulkan0 model buffer size = 19905.15 MiB → 19.9GB 割り当て成功、54.9 t/s

Vulkan ロード失敗（ErrorOutOfDeviceMemory）を繰り返すと、ドライバがデバイスメモリを解放しない。最終的に 0.9GB すら確保できなくなる。PC再起動でのみ回復する。つまり検証中に「失敗→リトライ」を繰り返すと状態がどんどん悪化する。大きいモデルのロード試行は慎重にやる必要がある。

根本原因

調査の結果、複数の問題が重なっていることがわかった。

  1. AMDドライバ 26.3.1 の Vulkan メモリ管理リグレッション: ドライバ（ビルド 2026-03-09）が Radeon 8060S UMA の Vulkan デバイスメモリ管理をリグレッションさせた。ドライバは Vulkan free memory を 54GB と報告するが、実際には共有メモリに配置されるケースがあり、大きいモデル（Q5_K_XL 24.6GB 以上）は ErrorOutOfDeviceMemory で失敗する
  2. Vulkan デバイスメモリリーク: ロード失敗時にドライバがメモリを解放しない。繰り返し試行するとデバイスメモリが枯渇し、最終的に小さい割り当てすら失敗する。PC再起動でのみ回復
  3. 共有メモリへのフォールバック: モデルデータの一部（Vulkan_Host バッファ）が VRAM ではなく共有メモリに配置される。ドライバ26.2.2では発生しなかった。現状で速度は出ているが、「共有メモリを使わない」状態とは異なる

解決: BIOS VRAM配分を 32GB/32GB に変更

BIOS を 48GB VRAM / 16GB システム → 32GB VRAM / 32GB システム に変更したところ、ErrorOutOfDeviceMemory が解消した。

モデル48/1632/32
Q4_K_M abliterated (19.7GB)54.9 t/s（再起動直後のみ）当然動く
Q6_K (26.8GB)ErrorOutOfDeviceMemory53.7 t/s

Vulkan free memory の報告値。

構成free memoryQ6_K
48/1654,305 MiB載らない
32/3246,522 MiB載る（53.7 t/s）

VRAMの報告値は減っているのに、ロード可能なモデルサイズは増えている。

なぜVRAMを減らした方が大きいモデルが載るのか

AMD ドライバ 26.3.1 はモデルロード時にシステム RAM を転送バッファとして使う。48/16 ではシステム側が 16GB しかなく、OS + Parsec + Tailscale 等で約7GB 消費した残り約9GB では転送バッファが不足し ErrorOutOfDeviceMemory となる。

32/32 にすることでシステム側に約25GB の空きが確保され、転送バッファに十分な余裕ができる。Vulkan の報告上は VRAM が減っているが、実効的にロード可能なモデルサイズは増える。

graph LR
    subgraph "48/16 構成"
        A1["VRAM 48GB"] --> B1["Q6_K 26.8GB<br/>ロード試行"]
        C1["システム 16GB<br/>空き ~9GB"] --> D1["転送バッファ不足"]
        D1 --> E1["ErrorOutOfDeviceMemory"]
    end

    subgraph "32/32 構成"
        A2["VRAM 32GB"] --> B2["Q6_K 26.8GB<br/>ロード成功"]
        C2["システム 32GB<br/>空き ~25GB"] --> D2["転送バッファ十分"]
        D2 --> B2
    end

    style E1 fill:#f44336,color:#fff
    style B2 fill:#4CAF50,color:#fff

前回のVRAM配分検証では「VRAMを多く確保するほど良い」という結論だったが、ドライバ 26.3.1 ではシステムRAM側の余裕も必要になった。UMA環境ではVRAMとシステムRAMの配分がドライバの挙動に直結するため、ドライバ更新のたびに最適解が変わり得る。

注意点がいくつかある。

  • Vulkan_Host に 397 MiB が配置されており、完全に VRAM のみで動作しているわけではない
  • ドライバ 26.2.2では 48/16 で Q6_K が動作していたため、これはドライバ 26.3.1 固有の回避策
  • Vulkan ロード失敗を繰り返すとメモリリークが発生するため、失敗したら即再起動

運用方法

  1. BIOSを 32GB VRAM / 32GB システムに設定
  2. b8183 + --no-mmap で llama-server 直接実行
  3. Vulkan ロード失敗したら即座に PC 再起動（メモリリークで状態が悪化する）
  4. LM Studio は Vulkan バックエンドの問題が別途存在、llama-server 直接実行を推奨

BIOS設定を変えただけで解決するとは思っていなかった。VRAMを48GBから32GBに減らしたら逆にQ6_Kが載るようになるというのは直感に反する。前回のVRAM配分検証では「VRAMは多いほど良い」だったのが、ドライバが変わったらシステムRAM側の余裕も要るようになった。EVO-X2の初期セットアップからVRAM配分検証、Ollama全滅事件、ドライバ更新で一括解決、そして今回のリグレッションとBIOS回避策。もう4回目のトラブルシュートだ。UMA + RDNA 3.5 はまだ枯れていない。

関連記事