0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ariera(ariera)

第6回 EVO-X2（Ryzen AI Max+ 395 / 128GB）+ Qwen3.8-Flash-Nextが、AMDドライバー更新したらVulkan版llama.cppで動くようになった話

0
Last updated at Posted at 2026-09-06

第1回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Nextを動かした話」
第2回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Nextを高速化した話」
第3回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Nextの高速化の続き」
第4回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でllama.cppをアップデートしただけで、Qwen3.8-Flash-Nextがprefill/decodeともに速くなった話」
第5回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Nextとチャットした話」
の続き。

前回の予告からまた脱線しているが、前回までクラッシュして動かせていなかったVulkan版のllama.cpp + Qwen3.8-Flash-Nextが動くようになったので、先にその報告。

結論

前回までVulkan版のllama.cpp + Qwen3.8-Flash-Nextがamdvlk64.dllのエラーでクラッシュしていたが、AMDのドライバーを更新したら正常に動くようになった。前回までのクラッシュはamdvlk64.dllのバージョンが古かったのが原因かもしれない。

今回 b10798-mix-659e406 + Qwen3.8-Flash-Next UD-IQ3_XXS では、MTPなしの32K/64Kを複数回測った範囲ではVulkan版の方がROCm版よりPP/TGともに速かった。

ただし、ROCmのPPには同じ条件でも通常よりかなり速い値が出た例がある。今回の32Kでも最初の1回だけ310.33 tok/sだったのに、その後5回は248.99～250.33 tok/sとほぼ誤差範囲内に収まった。なので、単発値だけでVulkan/ROCmの優劣を決めるのは危なそう。

Vulkan版が動くようになった

Qwen3.8-Flash-Nextの別のモデルを試そうとしてvulkan版の別のllama.cppをソースからビルドしてみたのだけど、やっぱり推論途中でamdvlk64.dllのエラーでクラッシュした。そこで諦めようと思ったのだけど、一晩かけて90GB近いモデルをダウンロードしたのにもったいないな～なんて思いながら、何となくamdvlk64.dllのプロパティを見てみたら、ファイル作成日が2025/07/10と1年以上前になっている。

それってgpt-oss:20bと120bも出ていないころでは？そんな古いので大丈夫？と思って調べてみたら、2025年7月末にRyzen AI MAX+ 395でWindows Vulkan llama.cppの対応の拡張が入っている。その後も何度か更新されていて、現在の最新版は

Adrenalin 26.8.1を入れて再起動した後の情報はこうなった。

  • Radeon 8060S display driver: 32.0.31041.1004
  • Driver Date: 2026-08-17
  • 使用中の amdvlk64.dll のPE FileVersion: 9.2.10.395
  • amdvlk64.dll の更新日時: 2026-08-18

更新前に確認していた amdvlk64.dll はPE FileVersion 9.2.10.317、更新日時は 2025-07-10 だった。

なお、AMDのパッケージ名、WindowsのDisplay Driver Version、amdvlk64.dll 自体のFileVersionはそれぞれ別の番号なので、ここでは混同しないように分けて書いている。

この状態でVulkan版llama-serverを起動して、簡単なリクエストを送ってみたらちゃんと動いた！
第1回の苦労は何だったのか、という気もするけど、ROCm版も試したことで第5回ではgemma4:31bのPPがROCm版の方がだいぶ速いことも分かったし、まあよしとしよう。

長文要約テストで速度計測

Vulkan版が動くようになったら当然、ROCm版とどっちが速いの？ということが気になる。
なので、新モデルを動かすのはちょっと保留にして、パラメータとチャット特性の関係を探るのもちょっと保留にして、Vulkan版で速度を測ってみた。
題材は第4回と同じ長文要約タスクを使う。

まずMTPなし、ncmoe=0 で比較。32KはVulkan/ROCmとも5回、64KはVulkan 3回・ROCm 4回を測定した。128Kは時間の都合で複数回の再測定はせず参考値扱い。

Context Prompt tokens Vulkan PP ROCm PP Vulkan TG ROCm TG 備考
32K 29,557 301.14 249.79 22.51 20.73 今回5回の中央値
64K 61,789 225.89 191.90 16.55 14.72 Vulkan 3回 / ROCm 4回の中央値
128K 126,253 146.08 137.92* 12.04 9.93* 参考値。*は第4回ROCm

32KではVulkanの方がPPで約20.6%、TGで約8.6%速かった。64KでもVulkanの方がPPで約17.7%、TGで約12.4%速かった。128Kも1回だけの参考比較では同じ方向だった。

少なくとも今回使ったUnsloth配布版 b10798-mix-659e406 とUD-IQ3_XXSの組み合わせでは、32K/64Kの長文要約タスクはVulkan版の方がROCm版より速かった。第5回でGemma4 31Bを試したときはROCmのPPがかなり速かったので、「EVO-X2なら常にROCmの方が速い」というわけではなく、モデルや処理内容で変わるようだ。

ただしROCm版とVulkan版は同じbuild/commitの配布バイナリでも、ROCm版はClang 23.0.0、Vulkan版はMSVC 19.44でビルドされている。純粋にVulkan/ROCmだけが違う比較ではなく、実際に配布されているWindowsバイナリ同士の比較、と考えた方がよさそう。

PPは変動が大きい？

第4回でllama.cpp b10798-mix コンテキスト32K、64K、128Kの条件で計測したときに、64KだけPPが妙に速かった。
今日は同じllama.cppビルドでVulkanと比較するために、対照値としてROCmも測ったら、32KのPPだけ異常に速かった。
ドライバの更新でROCm側のPPも速くなったのかとも思ったが、第4回の結果と今日の結果を合わせて考えると、PPは振れ幅が大きいのではないかという疑いを持った。
なので、同じ条件で複数回測ってみた。

32Kの再測定

Backend Run数 PP中央値 PP最小～最大 TG中央値
ROCm 5 249.79 248.99～250.33 20.73
Vulkan 5 301.14 300.86～301.75 22.51

ROCmもVulkanも、連続して測った5回はかなり安定している。特にVulkanのPPは300.86～301.75 tok/sで、振れ幅は0.3%程度しかない。

ところが、このちょっと前にお試しで測った同じROCm 32KではPP 310.33 tok/sが出ている。後の5回の中央値249.79 tok/sより約24%速い。TGはそのとき20.90 tok/sで、その後の20.7 tok/s前後とほとんど変わっていない。

64Kでも似たことが起きている

第4回のROCm 64KはPP 245.62 tok/sだった。一方、今回のROCm 64Kは4回測定して190.70、192.14、191.79、192.01 tok/sで、中央値は191.90 tok/s、範囲は190.70～192.14 tok/sだった。TGも14.71～14.73 tok/s、中央値14.72 tok/sに収まっている。Vulkan 64Kも3回すべて225.86～225.91 tok/sで、中央値225.89 tok/sとほぼ誤差範囲内。

つまり「PPは毎回ランダムに大きく振れる」というより、連続して複数回繰り返すと安定している一方で、ときどき通常よりかなり速い状態になることがあるように見える。ログを見ても最終集計だけがおかしいわけではなく、prompt processing途中の速度もその試行では実際に速い。

原因はまだ分からない。GPU/メモリクロック、電力管理、Windowsのメモリ状態、約27GiBの per_layer_token_embd.weight が lazy read enabled になっていることとの関係など、いくつか候補はありそうだけど、今回の記事では深追いしない。

このため、今回のVulkan vs ROCm比較は単発の最高値ではなく、複数回測定した32K/64Kの傾向を重視する。64Kについても、ROCm 4回のPPが190.70～192.14 tok/sに収まったことで、今回の通常状態ではVulkanのPPがROCmより約17.7%速いという差はかなり安定して確認できた。

MTPありも参考比較

せっかくなので、MTPありでもVulkanの今回値と、第4回のROCm値を並べてみる。こちらは同じ日に複数回測った厳密比較ではなく、あくまで参考値。

Context Vulkan PP ROCm PP（第4回） Vulkan TG ROCm TG（第4回） Vulkan acceptance ROCm acceptance
32K 277.45 240.11* 31.34 29.42* 70.4% 71.9%*
64K 205.93 233.99* 26.29 22.13* 71.9% 68.3%*
128K 137.12 171.24* 19.98 16.34* 68.5% 約70%*

*は第4回のROCm値。32Kは第4回で2回測ったうち速かった方を載せた。

TGは32K/64K/128Kのすべてで今回のVulkanの方が速かった。一方PPは32KではVulkanが速いが、64K/128Kでは第4回ROCmの方がかなり速い。

ただ、上で見た通りROCmのPPには通常より大幅に速い値が出ることがある。特に第4回64Kの245.62 tok/sも今回の190台前半と比べてかなり高いので、このMTP表だけから「長contextのPPはROCmが速い」とまでは言いきれない。MTPを使うと傾向も少し変わる、くらいの参考比較として見る。

ncmoe=8の出力崩壊

第2回で、ncmoe=8にするとPPは速くなるけど、出力が崩壊する現象を確認した。これはROCm版特有の現象なのか、Vulkan版でも再現するのかを確認しようと思った。

最初はb10798-mixのROCm版とVulkan版でチェックしたのだけど、どちらも出力崩壊は起こらない。もしかしてドライバー更新で出力崩壊も直った？と思ったけど、第2回で使ったllama.cppはb10679だったので、b10679のROCm版とVulkan版でもチェックした。

その結果、出力崩壊するのはb10679のROCm版のみ。すべてllama-cliで3回ずつチェックしたが、再現性があった。

今回の短い再現テストは、第2回で3/3崩壊した条件に合わせて、約5,369 tokens、-c 8192、ncmoe=8、t=4、tb=4、b=2048、ub=1024、fa=1 で各3回実行した。

build backend PP中央値 TG中央値 出力崩壊
b10679 ROCm 503.37 22.06 3/3
b10679 Vulkan 146.38 18.29 0/3
b10798 ROCm 286.82 12.60 0/3
b10798 Vulkan 276.91 20.81 0/3

b10679 ROCmだけは今回も / の繰り返しになり、3回とも完全に再現した。一方、同じb10679でもVulkanでは3/3正常、b10798ではROCm/Vulkanとも3/3正常だった。

なので、「ドライバー更新で出力崩壊も直った」という話ではなかった。新しいドライバー上でもb10679 ROCmでは再現する。また、ncmoe=8 自体が常に壊れるわけでもなく、b10679 Vulkanでは正常。今回確認した範囲では、b10679のROCm版という組み合わせに依存しているように見える。

ただしb10679とb10798、ROCmとVulkanではbackend以外にもビルド環境が異なるので、原因を1つの変更に絞り込んだわけではない。今回は「以前の記事で再現していた現象が、現行b10798では再現しなくなっている」ことの確認までにする。

速度面では、出力崩壊していないパターンでは、PPもTGもncmoe=0に比べてncmoe=8 が速いわけではない。とても高速に見えるのは出力崩壊と関係があるのかもしれない。

まとめ

AMDのドライバーをAdrenalin 26.8.1 WHQL Recommendedへ更新したところ、これまで amdvlk64.dll でクラッシュしていたVulkan版llama.cpp + Qwen3.8-Flash-Nextが正常に動くようになった。今回の検証条件では、旧ドライバー側がクラッシュの原因だった可能性が高そう。

速度は、MTPなしの32K/64Kを複数回測った範囲ではVulkan版がROCm版よりPP/TGともに速かった。32KではPPが約20.6%、TGが約8.6%速く、64KでもPP約17.7%、TG約12.4%ほどVulkanが上回った。128Kの参考値も同じ方向だった。少なくとも今回のQwen3.8-Flash-Next UD-IQ3_XXSでは、WindowsのVulkan版は「動くだけ」ではなく十分有力な選択肢になった。

一方で、ROCmのPPには同条件でも通常より20%以上速い値が出た例があり、単発測定だけで細かな差を論じるのは危なそうだと分かった。TGはかなり安定していた。

MTPありの参考比較ではTGはVulkanが速かったが、64K/128KのPPは第4回ROCm値の方が速かった。ただし、そのROCm値自体が今回確認したPPの高速状態の影響を受けている可能性もあるので、ここは参考程度。

ついでに第2回の ncmoe=8 出力崩壊も再チェックしたところ、b10679 ROCmでは今回も3/3で再現したが、b10679 Vulkanとb10798のROCm/Vulkanでは再現しなかった。現行b10798では、少なくとも今回の条件で以前の出力崩壊は気にしなくてよさそう。

次は、途中で保留にした新モデルか、パラメータとチャット特性の検証に戻る予定。たぶん。

長文要約テストのコマンド例(第4回と同じ)

.\llama-cli.exe `
    -m "(モデルのパス)\Qwen3.8-Flash-Next-UD-IQ3_XXS-00001-of-00003.gguf" `
    -c (コンテキスト長) `
    -ngl 999 `
    -ncmoe 0 `
    -t 4 `
    -tb 4 `
    -b 2048 `
    -ub 1024 `
    -fa 1 `
    -ctk f16 `
    -ctv f16 `
    --temp 0.2 `
    --top-k 20 `
    --top-p 0.8 `
    --min-p 0.05 `
    --jinja `
    --single-turn `
    --reasoning off `
    -f 入力ファイルのパス `
    -n 1024 `
    -lv 4

検証環境

Hardware

  • Device: NucBox_EVO-X2
  • CPU / APU: AMD Ryzen AI MAX+ 395 with Radeon 8060S
  • CPU clock displayed by Windows: 3.00 GHz
  • Installed memory: 128 GB
  • Windows usable memory: 63.6 GB
  • UMA Frame Buffer: 64 GB
  • GPU: AMD Radeon 8060S Graphics

OS

  • OS: Windows 11 Pro
  • Version: 25H2
  • OS Build: 26200.9168
  • Installed: 2025-10-24
  • Windows Feature Experience Pack: 1000.26100.344.0

llama.cpp

llama.cpp(出力崩壊確認用)

EVO-X2にインストール済みのHIP SDK

  • HIP SDK: 7.2.60201-38d754472
  • HIP compiler: clang 21.0.0git
  • HIP target: gfx1151

使用したモデル

Target model

MTP draft model

追記：Qwen3.6-35B-A3BもVulkanで動くようになった(2026/9/10)

以前、Qwen3.6-35B-A3B UD-Q4_K_MをWindows + Vulkanで動かした際、
GPU offloadを増やすとSTATUS_STACK_BUFFER_OVERRUNでクラッシュする問題を
llama.cppのIssue #26945で報告していた。

その後、AMDドライバーをAdrenalin 26.8.1へ更新して再確認したところ、
挙動が大きく変わった。

llama.cpp / backend AMD driver 結果 PP TG
b10066 Vulkan 購入時driver GPU offload増加でクラッシュ - -
b10066 Vulkan 26.8.1 full offload可能。ただし出力崩壊・極端に低速 約31.8 約1.58
b10798-mix Vulkan 26.8.1 出力正常。ただし極端に低速 約25.7 約1.60
b10809 Vulkan（LaurentZuijdwijk fork） 26.8.1 出力正常・実用的な速度 約158.7 約26.1
b10798-mix ROCm 26.8.1 出力正常・実用的な速度 約160.2 約24.2

※ PP/TGは約129 tokenの短いpromptでの参考値。

AMDドライバー更新後は、元のb10066でも42/42 layersのfull GPU offloadが可能になり、
少なくとも「GPUに載せるとクラッシュする」という問題は解消した。

ただしb10066では出力が壊れ、速度も非常に遅かった。
b10798-mix Vulkanでは出力は正常になったものの、TGは約1.6 tok/sのままだった。

一方、第7回でビルドしたb10809 Vulkan（LaurentZuijdwijk fork）では
PP約158.7 tok/s、TG約26.1 tok/sまで改善し、
b10798-mix ROCmのPP約160.2 tok/s、TG約24.2 tok/sとほぼ同じ速度帯になった。

このため、元のクラッシュについてはAMDドライバー更新の影響が大きかったと考えられるが、
出力品質やVulkan性能の改善についてはllama.cpp側の更新も大きく効いている。

なお、b10809はupstreamそのものではなくLaurentZuijdwijk forkなので、
単純にbuild番号の差だけによる改善とは言えない。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?