技術 約11分で読めます

Qwen 3.5がRadeon 8060Sで全滅した原因はAMDドライバだった

AI LLM ローカルLLM AMD llama.cpp Ollama LM Studio 実験

EVO-X2（Strix Halo / Radeon 8060S）でQwen 3.5が動かない人、AMDドライバを更新しろ。 プリインストールのAMD Softwareには自動更新がない。AMDの公式サイトから最新版を入れてAdrenalin 26.2.2以降にすれば、Vulkan GPU推論が正常に動く。以下はその結論に至るまでの検証記録。

前回の記事で、Qwen 3.5がRadeon 8060S（ROCm / gfx1151）で全滅した。ROCmはゴミトークン、Vulkanはクラッシュ、LM Studioもクラッシュ。Mac（Metal）では正常に動いたので、モデルの問題ではなくバックエンド側の問題——と結論づけた。

今回はCPU推論とllama-server（本家llama.cpp）で原因を切り分けていったら、最終的にAMDドライバの更新だけで全部解決した。

環境

項目スペック
PCGMKtec EVO-X2
CPUAMD Ryzen AI Max+ 395（Zen 5 / 16C 32T）
GPURadeon 8060S
メモリ64GB（統合メモリ）
OSWindows 11
llama.cppb8183（2026-03-01）
LM Studio0.4.6

メモリ配分はBIOSで設定。統合メモリなので物理的には同じDRAMだが、OS上ではシステムメモリとVRAMとして区別される。検証中にBIOS変更を行い、48GB/16GBと32GB/32GBの両方で試した。

llama-serverのセットアップ

OllamaもLM Studioも内部はllama.cppだが、独自のラッパーやフォークが入っている。本家llama.cppのHTTPサーバーであるllama-serverを直接使えば、バックエンドの挙動を切り分けられる。

llama.cppのGitHub Releasesからビルド済みバイナリを取得。今回使ったのはb8183（2026-03-01リリース）。

バイナリ用途
llama-b8183-bin-win-cpu-x64.zipCPU推論
llama-b8183-bin-win-hip-radeon-x64.zipROCm（HIP）GPU推論
llama-b8183-bin-win-vulkan-x64.zipVulkan GPU推論

モデルはunsloth/Qwen3.5-35B-A3B-GGUFから Qwen3.5-35B-A3B-UD-IQ2_XXS.gguf（9.76GB / 2.25 BPW）を使用。システムメモリ16GBに収める必要があったため最軽量の量子化を選んだ。

CPU推論: 問題なく動く

C:\llama\llama-server.exe -m "Qwen3.5-35B-A3B-UD-IQ2_XXS.gguf" --port 8080 --ctx-size 512 --reasoning-budget 0

起動ログでバックエンドが ggml-cpu-zen4.dll であることを確認。--ctx-size 512 はKVキャッシュを最小にしてメモリ消費を抑えるため。--reasoning-budget 0 でthinkingを無効化。

http://localhost:8080 のWebUIから「こんちわ」を送信した結果:

こんにちは！何かお手伝できることはありますか？

普通に動いた。 11トークン / 0.8秒 / 14.38 t/s。ゴミトークンは一切出ない。

指標値
eval14.38 t/s
CPU使用率約50%（16C中16スレッド使用）
GPU使用率0%
メモリシステムメモリ14GB使用

MoEでactive 3Bしか使わないため、実際の演算量は3Bモデル相当。Zen 5のAVX-512（VBMI / VNNI / BF16）がフルに効いていて、CPU推論とMoEの相性が良い。

Qwen 3.5のアーキテクチャが想像以上に特殊だった

起動ログのメタデータから、Qwen 3.5の内部構造が見えた。前回の記事では「GQAとRoPEがROCmで処理できていない」と推測していたが、実際はもっと複雑だった。

パラメータ値
アーキテクチャqwen35moe（Attention + SSMハイブリッド）
エキスパート数256（アクティブ8）
full_attention_interval4（4層に1回だけフルAttention）
SSMd_conv=4, d_state=128, d_inner=4096
RoPEtype=40（mrope）、sections=[11, 11, 10, 0]
KVバッファ10MB（Attention用、10層分）
RSバッファ251MB（SSM recurrent state用、40層分）

40層中10層だけがAttentionで、残り30層はSSM（Mamba系）。KVキャッシュよりrecurrent stateの方が25倍大きい。さらにRoPEは通常のものではなくmrope（multi-dimensional RoPE）で、256エキスパートのMoEも組み合わさっている。Qwen 2.5は同じ環境のGPUで問題なく動くので、この特殊なアーキテクチャがGPUバックエンドとの相性問題を引き起こしていた。

HIPビルド: APUのGPUを認識しない

HIPビルド（ROCm）でGPU推論を試した。Ollamaが出すゴミトークンが、Ollamaのフォーク固有の問題なのか、llama.cppのROCmカーネル自体の問題なのかを切り分けたい。

load_backend: loaded CPU backend from C:\llama-hip\ggml-cpu-zen4.dll
llama_params_fit_impl: no devices with dedicated memory found

HIP/ROCmバックエンドがロードされない。 no devices with dedicated memory found — Ryzen AI Max+ 395は統合メモリAPUなので、「dedicated memory（専用メモリ）を持つデバイス」として認識されない。本家llama.cppのHIPビルドはAPUの統合メモリを想定していない。

結果はCPUフォールバック。13.73 t/sでCPU版とほぼ同じ速度。GPU推論の検証にはならなかった。

Ollamaはgfx1151を認識してROCmでGPUに載せられる（起動ログに library=ROCm compute=gfx1151 と出る）ので、APU対応はOllamaの独自実装。

Vulkanビルド: GPU認識するが推論で即死

同じEVO-X2でllama.cppのVulkanビルドがGPU推論に成功した報告を見つけたので、Vulkanビルドも試した。

ggml_vulkan: 0 = AMD Radeon(TM) 8060S Graphics (AMD proprietary driver) | uma: 1
load_tensors:      Vulkan0 model buffer size =  8959.58 MiB

Vulkanは uma: 1（unified memory architecture）としてRadeon 8060Sを正しく認識。モデルの大部分がVulkan0（GPU）に載った。

しかし「こんちわ」を送った結果、プロンプト処理は成功するがトークン生成で即死。

slot update_slots: prompt processing done, n_tokens = 14
（プロセスが終了、タイミングログなし）

prompt eval（入力のエンコード）は通るが、eval（自己回帰的なトークン生成）に入った瞬間にプロセスごと落ちる。エラーログなし。

LM Studio 0.4.6: 同じ壁

LM Studioを0.4.6にアップデートして、Q4_K_M（19.71GB）でも試した。

全41レイヤーをGPUにオフロードするとロード時にexit code overflow（18446744072635810000）で即死。20レイヤーのデフォルト設定だとロードとプロンプト処理は通るが、やはりトークン生成で死ぬ。llama-server Vulkanと全く同じパターン。

BIOSでメモリ配分を変更（32GB/32GB）

以前の記事で、Strix HaloのVulkanドライバはVRAMではなく共有メモリ（システムメモリ側）を優先的に使用する問題を確認していた。VRAM 48GB/システム16GBの設定だと、Vulkanがシステムメモリ側に配置してしまい16GBで溢れる。

BIOSでVRAM 32GB/システムメモリ32GBに変更して再テスト。

load_tensors: offloaded 41/41 layers to GPU
load_tensors:      Vulkan0 model buffer size = 19905.15 MiB

全41レイヤーのGPUオフロードが通った。メモリの問題は解消。だがトークン生成は同じく即死。メモリではなくVulkanの演算カーネルの問題だと確定。

AMDドライバが古かった

ここでXの投稿を発見。同じRadeon 8060S（128GBモデル）でLM Studio + Qwen 3.5がVulkanで47 t/s出ている報告。設定を合わせても動かない。

ドライバを確認したところ、EVO-X2にプリインストールされていたAMD Softwareには自動更新機能がなかった。 AMDの公式サイトから最新のAMD Software（自動更新あり）をインストールし、ドライバをAdrenalin 26.2.2（2026-02-17リリース）に更新。

こんにちは！元気ですか？今日はどんな一日でしたか？

動いた。 ドライバ更新だけでVulkan GPU推論が正常に動作。

指標値
eval34.99 t/s
VRAM使用22.1GB
システムメモリ9.2GB（OS分のみ）
共有メモリ0.6GB

CPU推論の14 t/sから35 t/sへ、2.5倍の高速化。

さらに重要なのはメモリ管理も修正されたこと。旧ドライバではVulkanが共有メモリ（システムメモリ側）を優先的に使用し、VRAMがガラ空きなのにシステムメモリが溢れる問題があった。新ドライバではモデルが正しくVRAMに配置され、システムメモリはOS分の9.2GBだけ。共有メモリも0.6GBとほぼ使われていない。

以前の記事で「VRAMを減らした方がうまくいく」と書いたが、それは旧ドライバの共有メモリ優先バグを回避していただけだった可能性がある。

Q6_Kに上げてみる

BIOSをVRAM 48GB/システム16GBに戻し、Q6_K（lmstudio-community/Qwen3.5-35B-A3B-GGUF）で再テスト。

指標Q4_K_MQ6_K
eval34.99 t/s41.22 t/s
VRAM使用22.1GB22.2GB

Q6_Kの方がQ4_K_Mより速い。Q6_Kはデコード処理が単純で、Vulkanのコンピュートシェーダーとの相性が良いのかもしれない。48GBのVRAMに対して22GB程度なのでまだ余裕がある。

Q8_0も試したが、共有メモリ経由のVRAM転送時にオーバーフローしてロードできなかった。Q6_Kがこの環境（64GB / VRAM 48GB）の実用上限。

llama-serverでは48GB/16GB構成だとQ6_Kのロード時にシステムメモリが溢れるため、BIOS設定を32GB/32GBに変更して再テスト。35.15 t/sで動作した。ロード完了後はシステムメモリに20GB以上の空きがあるため、KVキャッシュをシステムメモリ側に配置すればコンテキスト長を大きく取れる。

abliterated版も動く

前回の記事で全滅したabliterated版（mradermacher/Huihui-Qwen3.5-35B-A3B-abliterated-GGUF、Q4_K_M）をllama-server Vulkanで試した。

C:\llama-vulkan\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
こんにちは！元気にお過ごしですか？
何かお手伝いできることがありましたら、いつでもお気軽にお声がけください。

47.57 t/s。 前回全滅だったabliterated + Radeon 8060Sが、ドライバ更新だけで完全に動作。全41レイヤーがVulkan0に載り、graph splits = 2 のクリーンな構成。

Q6_K（mradermacher/Huihui-Qwen3.5-35B-A3B-abliterated-GGUF）も --no-mmap 付きで試した。VRAM 27.9GB、システムメモリ9GB、共有0.5GBで全部VRAMに収まり、53.83 t/s。公式版Q6_Kの41 t/s（LM Studio）を大きく上回った。

統合メモリAPUでは —no-mmap が必須

ドライバ更新でVulkanの演算カーネルは修正されたが、mmapが有効（デフォルト）だとシステムメモリが逼迫する問題が残る。VRAM 48GB/システム16GBの設定で、モデル（Q4_K_M / 20GB）がVRAMに載っているにもかかわらず、システムメモリがほぼ100%使われる。

原因はmmapによる二重マッピング。GGUFファイルがシステムメモリにメモリマップされ（約20GB）、さらにVulkanがVRAMにコピーする。統合メモリで物理的には同じDRAMだが、OSのアドレス空間としては二重に確保される。

--no-mmap を指定するとシステムメモリ側のマッピングがなくなり、モデルはVRAMバッファに直接ロードされる。

C:\llama-vulkan\llama-server.exe -m "モデル.gguf" --port 8080 --ctx-size 4096 --reasoning-budget 0 --n-gpu-layers 99 --no-mmap
指標mmap有効（デフォルト）—no-mmap
システムメモリ28GB（逼迫）8.8GB
VRAM21GB21GB
共有メモリ5.6GB0.4GB
eval速度47.57 t/s49.18 t/s

--no-mmap でシステムメモリが8.8GB（OS分のみ）に激減。速度も47→49 t/sとわずかに向上。共有メモリも0.4GBまで下がった。

VRAM 48GB/システム16GBのBIOS設定でも、--no-mmap を使えば16GB中8.8GBで7GB以上の余裕が生まれる。統合メモリAPUでllama-serverを使う場合は --no-mmap を必ず指定すべき。

—no-mmapでもロード時の転送バッファは残る

--no-mmap は推論中のダブルマッピングを防ぐが、モデルのロード時にはシステムメモリを転送バッファとして経由する。VRAM 48GB/システム16GBの構成でQ8_0（35GB）やQ6_K（28GB）をllama-serverで読み込むと、転送バッファがシステムメモリ16GBを超えて ErrorOutOfDeviceMemory で落ちる。

VRAM 32GB/システム32GBに戻せばシステムメモリに余裕ができてQ6_Kのロードが通るが、Q8_0はVRAM 32GBに収まらないためどの配分でもllama-serverでは載らない。

LM Studioは同じVulkanバックエンドでもQ6_Kを48GB/16GB構成でロードできるため、転送時のバッファ管理がllama-serverより効率的と考えられる。大きなモデルを載せたい場合はLM Studioの方が有利。

前回の記事の結論を修正

前回の記事では以下のように結論づけた:

  • Qwen 3.5はRadeon 8060S（ROCm / gfx1151）で動かない
  • abliterationは無罪（Macで検証済み）
  • llama.cppのROCmバックエンドがgfx1151上でQwen 3.5のアーキテクチャに対応しきれていない

3つ目は不正確だった。正確には:

  • Radeon 8060SのAMDドライバが古く、Vulkanのコンピュートシェーダーがqwen35moeのトークン生成に対応していなかった
  • ドライバ26.2.2（2026-02-17）で修正済み
  • 旧ドライバではメモリ管理もおかしく、VRAMではなく共有メモリに優先配置していた

OllamaのROCmでゴミトークンが出る問題もドライバ起因の可能性があるが、ROCmについてはドライバ更新後に再検証していないため未確認。

GMKtec EVO-X2を買った人へ

EVO-X2にプリインストールされているAMD Softwareには自動更新機能がない。そのため手動でドライバを更新しない限り、出荷時の古いドライバのまま使い続けることになる。

AMDの公式サイトから最新のAMD Softwareをダウンロードしてインストールすると、自動更新機能付きのバージョンに切り替わる。RDNA 4（gfx1151）は新しいアーキテクチャでドライバの成熟が進んでいる最中なので、常に最新ドライバにしておくことを強く推奨する。

ローカルLLMで特定のモデルが動かない、Vulkanでクラッシュする、メモリ管理がおかしい——と思ったら、まずドライバを確認。

検証まとめ

バックエンド旧ドライバドライバ26.2.2
Vulkan（LM Studio / Q4_K_M）evalクラッシュ正常（35 t/s）
Vulkan（LM Studio / Q6_K）evalクラッシュ正常（41 t/s）
Vulkan（llama-server / Q6_K）evalクラッシュ正常（35 t/s）
Vulkan（llama-server / abliterated Q4_K_M）evalクラッシュ正常（49 t/s）
Vulkan（llama-server / abliterated Q6_K）evalクラッシュ正常（54 t/s）
ROCm（Ollama）ゴミトークン未検証
CPU（llama-server）正常（14 t/s）正常（14 t/s）

くどいようだけどドライバは更新しろ。

関連記事