第7回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Next ROCmFP4を動かした話」で、EVO-X2のBIOS設定でVRAM割り当てを64GBと96GBに変えてみた。その結果、64GB設定でも90GB近いモデルが単純にCPUオフロードされるわけではない。けど、VRAM割り当て64GBと96GBでは推論速度が結構変わり、Windowsから見たメモリの状態も変わっていた。
VRAM割り当てを他の値にしたらどうなるのか、llama.cppのバックエンドがVulkanかROCmかで違うのか、など色々気になったので調べてみた。
以降、Prompt Processing（入力を読み込む処理）をPP、Token Generation（出力生成）をTGと表記する。どちらも単位はtok/sで、高いほど速い。
結論
EVO-X2のBIOS設定の「UMA Frame Buffer Size」は、少なくともWindows上では「GPUがここまでしかメモリを使えない」という単純な上限ではなかった。
VRAM 2GB設定でも、90GB近いサイズのモデルがllama.cppのログ上では全層GPUに載って、速度も極端に遅くなるということはなかった。
だからといってどのVRAM割り当てでも同じというわけではなく、基本的にはVRAM割り当てが大きいほど速度も速くなる傾向だった。
ただし、VRAMを増やせば常に速くなるわけでもなかった。VRAM 96GB設定で極度に遅くなったりクラッシュしたりするモデルとlamma.cppビルドの組み合わせもあった。
というわけで、EVO-X2では「VRAMは多ければ多いほどよい」というより、動かすモデル・コンテキスト長・バックエンドが必要とするGPU メモリと、CPU側に残したいメモリのバランスで決める設定と考えた方がよさそう。
検証環境
今回の主な環境は以下。
- PC: GMKtec NucBox EVO-X2
- APU: AMD Ryzen AI MAX+ 395 / Radeon 8060S
- Memory: 128GB unified memory
- OS: Windows 11 Pro 25H2
- AMD GPU driver: Adrenalin Edition 26.8.1 WHQL Recommended
llama.cppは３種類
- 実験開始時のupstream最新版b10919(
d3146f2b5) Vulkan - 同 ROCm
-
b10809(
5e085d123) Vulkan（AMD Strix Halo専用フォーク）（第7回でビルドしたもの）
モデルは比較用に２種類、おまけでQwen3.5を１種類
- Qwen3.8-Flash-Next Unsloth UD-IQ3_XXS: 76.32GiB
- Qwen3.8-Flash-Next AgentionAI ROCmFP4: 87.05GiB
- Qwen3.5-2B Unsloth UD-Q4_K_XL
※今回の検証ではすべてMTPはオフにした。そのため、各モデル x llama.cppでの最速値を測っているわけではない。
※なお、ROCmFP4 はAgentionAI版モデルの形式名で、今回このモデルを実行したAMD Strix Halo専用フォークのbackend自体は Vulkan。表中の「AgentionAI ROCmFP4 / 専用fork」もVulkan backendでの結果になる。
VRAM 2 / 32 / 64 / 96GBでメモリ配置はどう変わるか
普段は試したときの順番のまま思考に沿って記事化することが多いけど、今回はそれをやると混乱しそうなので、本題から先に書いてみる。
EVO-X2のBIOS設定でVRAMサイズを2GB、32GB、64GB、96GBに変更して、いつもの日本語長文要約タスクを使って、context 32k(入力29,557 tokens)と64k(入力61,789 tokens)のデータをllama-cliで実行してみた。
VRAM 2GB設定だと70～90GB級のモデルはまともに動かないかと思ったけど意外と普通に動いて、第7回から相性が悪いと思っていたUnslothモデル × 専用フォークのVRAM 96GB設定ではWindowsごとクラッシュするという事故が起きた。
ここで、以降のメモリ表に出てくる用語だけ簡単に整理しておく。
用語メモ
- WDDM（Windows Display Driver Model）: WindowsがGPUやGPUメモリを管理する仕組み。ここではWindowsのperformance counterから取得したGPUメモリ使用量を見る。
- UMA（Unified Memory Architecture）: CPUとGPUが同じ物理メモリを共有する構成。EVO-X2ではCPUとRadeon 8060Sが128GBの統合メモリを共有する。
- Dedicated: WDDM上でGPUのDedicated memoryとして計上される領域。EVO-X2では、「物理VRAMチップ」と同じ意味ではない。
- Shared: WDDM上でGPUがsystem memory側から使う領域として計上されるメモリ。EVO-X2ではDedicatedとSharedのどちらも物理的には同じ統合メモリ上にある。
- GPU Total Committed: llama.cppプロセスがGPU用途としてcommitしているメモリの合計。おおむねDedicated + Sharedの全体量を見るために使う。
※Dedicated / Sharedは「物理的に別のメモリ」ではなく、同じUMAをWindows/WDDMがどう分類・管理しているかを見るための値として扱う。
ということで、まずはllama.cppのログと、実行中に自作powershellスクリプトで取ったWindowsのリソースログから、メモリの状態をまとめてみる。
AgentionAI ROCmFP4版：同じ約93GBがDedicatedからSharedへ移る
まず一番分かりやすかったAgentionAI ROCmFP4 + 専用フォーク、context 64kの安定区間(後半40%)の中央値。
| BIOS VRAM設定 | llama GPU Dedicated | llama GPU Shared | GPU Total Committed | PP |
|---|---|---|---|---|
| 2GB | 1.42 GiB | 90.11 GiB | 91.53 GiB | 172.93 |
| 32GB | 31.30 GiB | 61.73 GiB | 93.02 GiB | 180.43 |
| 64GB | 63.20 GiB | 29.47 GiB | 92.67 GiB | 195.47 |
| 96GB | 92.36 GiB | 0.70 GiB | 93.06 GiB | 224.12 |
GPU Total Committedはどの設定でも約92～93GiBでほぼ同じなのに、その内訳だけが大きく変わっている。
2GB設定では90GiB以上がShared、32GB設定では約62GiBがShared、64GB設定でも約30GiBがSharedに残り、96GB設定でようやくほぼ全量がDedicated側に入った。
つまり、少なくともこの環境では「BIOSでVRAM 2GBを選んだらGPUは2GBしか使えない」という動作にはなっていない。BIOS設定はWDDM上でDedicatedとして扱える領域の大きさに強く効き、不足分はShared側に回っているように見える。
実際、VRAM 2GB設定で87.05GiBのAgentionAI ROCmFP4版をcontext 64kで起動したとき、llama.cppのログには次のように出ていた。
load_tensors: offloading output layer to GPU
load_tensors: offloading 47 repeating layers to GPU
load_tensors: offloaded 49/49 layers to GPU
load_tensors: Vulkan0 model buffer size = 88645.69 MiB
load_tensors: Vulkan_Host model buffer size = 497.31 MiB
offloaded 49/49 layers to GPU と記録され、Vulkan側のmodel bufferも約88.6GiB確保されている。ここでいう「GPU offload」はGPU backend側で処理するために配置されたという意味で、BIOSで設定した2GBのDedicated領域だけに約89GBのモデルが物理的に収まった、という意味ではない。上のWDDMカウンタでは、このrunの大部分がShared側として計上されていた。
Unsloth + upstream Vulkan：64GBでほぼDedicatedに収まる
同じcontext 64kでも、76.32GiBのUnsloth UD-IQ3_XXSをupstream Vulkanで動かした場合、GPU processのcommitは約54GiBだった。
| BIOS VRAM設定 | llama GPU Dedicated | llama GPU Shared | GPU Total Committed | PP |
|---|---|---|---|---|
| 2GB | 1.39 GiB | 52.05 GiB | 53.45 GiB | 147.72 |
| 32GB | 31.24 GiB | 22.74 GiB | 53.97 GiB | 160.91 |
| 64GB | 53.27 GiB | 0.71 GiB | 53.97 GiB | 227.97 |
| 96GB | 53.27 GiB | 0.71 GiB | 53.97 GiB | 231.15 |
こちらは64GB設定の時点でほぼ全部Dedicated側に収まり、96GBへ増やしてもメモリ配置はほとんど変わらなかった。
この「必要量をDedicated側へ収められるかどうか」が、後述する速度変化とも対応した。左がAgentionAI ROCmFP4版、右がUnslothのDedicated / Shared比とPPのグラフ。
速度も比較してみる
次に各条件のPP/TGを比較してみる。表中は PP / TG の順。
context 32k
| モデル / llama.cpp | 2GB | 32GB | 64GB | 96GB |
|---|---|---|---|---|
| Unsloth / upstream Vulkan | 280.31 / 20.52 | 297.44 / 21.10 | 310.19 / 22.90 | 320.41 / 22.59 |
| Unsloth / upstream ROCm | 243.16 / 13.07 | 243.93 / 13.00 | 324.90 / 21.08 | 322.21 / 20.77 |
| AgentionAI ROCmFP4 / 専用fork | 288.60 / 22.46 | 287.79 / 21.76 | 251.00 / 22.34 | 333.76 / 25.21 |
| Unsloth / 専用fork | 176.75 / 20.40 | 244.75 / 22.48 | 283.10 / 24.39 | 269.22 / 23.31 |
context 64k
| モデル / llama.cpp | 2GB | 32GB | 64GB | 96GB |
|---|---|---|---|---|
| Unsloth / upstream Vulkan | 147.72 / 15.05 | 160.91 / 15.30 | 227.97 / 16.69 | 231.15 / 16.39 |
| Unsloth / upstream ROCm | 202.12 / 9.81 | 200.86 / 9.88 | 276.58 / 14.73 | 267.66 / 14.74 |
| AgentionAI ROCmFP4 / 専用fork | 172.93 / 20.66 | 180.43 / 20.38 | 195.47 / 21.13 | 224.12 / 23.41 |
| Unsloth / 専用fork | 170.62 / 20.80 | 181.90 / 20.93 | 125.38 / 22.41 | Windows crash |
32kはrunごとの揺れが少し大きいので、VRAM設定の傾向を見るには64kの方が分かりやすい。
Unsloth + upstreamでは、2GB→32GBは小幅な変化なのに、32GB→64GBでPPが大きく伸びた。
- Vulkan 64k: 160.91 → 227.97 tok/s（約42%増）
- ROCm 64k: 200.86 → 276.58 tok/s（約38%増）
前節のリソースログを見ると、Unsloth版は約54GiBのGPU commitなので、64GB設定でShared側からほぼDedicated側へ移り切る。この境界とPPの段差が重なっている。
一方、約93GiBを使うAgentionAI ROCmFP4版は64GBでも約30GiBがShared側に残る。64k PPは172.93 → 180.43 → 195.47 → 224.12 tok/sと、2GBから96GBまで段階的に伸びた。こちらは96GB設定でほぼ全量がDedicatedに入ることと対応しているように見える。
ただし、Dedicated / Sharedだけですべてを説明できるわけではない。特にUnsloth + 専用forkは64GBでPP 125.38 tok/sまで落ち、96GBではクラッシュした。これは後で別に考える。
AgentionAIのモデルもllama.cppのAMD Strix Halo専用フォークもPPの速さを売りにしているようで、サイト上ではTGは少しデータが載っている程度なのだけど、今回の専用forkは高コンテキストでもTGが比較的安定していた。
たとえば64kでは、Unsloth + upstream Vulkanが15～17 tok/s、ROCmが10～15 tok/sなのに対し、専用forkはAgentionAIモデルで約20.4～23.4 tok/s、Unslothモデルでも約20.8～22.4 tok/sを維持している。Unslothモデルでも同じ傾向が出ているので、量子化形式だけではなくfork側のqwen4exp向け実装の影響が大きそうに見える。
ちょっと脱線して、VRAM 4GBマシンと比較
EVO-X2で長時間推論を走らせている間、暇だったので、GTX 1650 Max-Q（物理VRAM 4GB）搭載の古いゲーミングノートPCでモデルを動かせないかと思って、Gemma 4 E4Bを入れて遊んでいた。
当初は「とりあえず起動するか」を見る程度の予定だったのだけど、3.91GiBのモデルが43/43 layers GPU offloadで動き、日本語要約も思ったよりちゃんとできたので、その話は別記事にする予定。
こちらで興味深かったのが、WindowsのWDDMカウンタ上ではEVO-X2の低VRAM設定と似た「Dedicated + Shared」という見え方になるのに、性能への影響はかなり違ったこと。
ただし、EVO-X2側とはGPU、モデル、llama.cpp buildのすべてが違うため、ここではPP/TGの絶対値を直接比較するのではなく、Dedicatedが埋まってShared側へ出たときにWDDM上でどう見えるかという点だけを比べる。
今までのEVO-X2のテストはコンテキスト長に合わせた長さの日本語入力を入れて要約してもらうというタスクで測ったデータだが、次のGTX 1650側の表は、32k、64k、96k、128kのすべてで全く同じ短いプロンプトを入力し、コンテキスト長の「設定値だけ」を変えたテストになっている。
promptは数十tokensしかないため、contextを実際に埋めたことによるattention処理量の増加とは切り離して、context確保に伴うメモリ配置とTGの変化を見やすい。
| context設定 | VRAM使用 | Shared / Non-local | GPU committed | TG |
|---|---|---|---|---|
| 32k | 3311 MiB | 0.145 GiB | 3.378 GiB | 30.93 tok/s |
| 64k | 3855 MiB | 0.176 GiB | 3.940 GiB | 30.91 tok/s |
| 96k | 3889 MiB | 0.705 GiB | 4.504 GiB | 27.63 tok/s |
| 128k | 3907 MiB | 1.250 GiB | 5.067 GiB | 26.50 tok/s |
32kから64kまでは、Dedicated VRAMの使用量は3.3GiBから3.9GiB近くまで増えるものの、Shared / Non-localは0.145→0.176GiBと小さく、TGも30.93→30.91 tok/sでほぼ完全に横ばいだった。
ところが96kではDedicated VRAMがほぼ4GBの上限に達し、Shared / Non-localが0.705GiBまで急増する。同じ短いpromptしか入力していないにもかかわらず、TGも30.91→27.63 tok/sへ低下した。128kではShared / Non-localがさらに1.250GiBまで増え、TGは26.50 tok/sになった。
つまり、このテストでは「入力文が長くなったから遅くなった」という要因はほぼない。コンテキスト設定を大きくしてDedicated VRAMだけでは収まらなくなり、Shared / Non-local側の利用が増えた境界と、TGが落ち始める境界が64k→96k付近でほぼ重なっている。
Windowsのリソースログだけを見ると、これはEVO-X2をVRAM 2GBや32GBに設定した場合と少し似ている。どちらもDedicatedだけでは足りず、Sharedを使ってGPU workloadを動かしているように見える。
けど、GTX 1650では、4GBのDedicated VRAMはGPU側の物理メモリで、Shared / Non-localはCPU側のsystem RAMになる。
EVO-X2の方ははUMA（ユニファイドメモリ）なので、WDDM上でDedicated / Sharedと分類されていても、物理的にはCPUとGPUが同じLPDDRメモリを共有している。
EVO-X2ではBIOSをVRAM 2GBに設定して、Qwen3.8-Flash-Nextの約90GiBのGPU memory commitの大部分がSharedとして計上されても推論そのものは普通に動いていた。後述する小さいQwen3.5-2Bでは、1M context時に約10.5GiBがSharedになっている2GB設定と、ほぼDedicatedに収まる64GB設定でPPがほとんど変わらなかった。
そのため、WDDM上で同じ「Shared memory」と表示されても、UMAのEVO-X2と、VRAMとsystem RAMが物理的に分離しているGTX 1650では、性能上の意味はかなり違うように見える。
なので今回の「EVO-X2はVRAM 2GB設定でも90GB以上をGPUから使えた」という結果から、「物理VRAM 2～4GBの一般的なGPUでも同じように巨大モデルが動く」ということはできない。
VRAM 96GBでWindowsごとクラッシュした件をちょっと考察
ここは例によってチャッピー様の受け売り。
96GB設定では8パターン中7パターンは正常完走したが、最後の Unsloth UD-IQ3_XXS + AMD Strix Halo専用fork + context 64k だけWindowsごと再起動した。
この組み合わせは以前から挙動が怪しかった。
| テスト | 結果 |
|---|---|
| 過去の96GB / 64k | 完走したがPP 12.86 tok/s、TG 21.37 tok/s。約80分かかった |
| 過去の96GB / 96k | 75,776 tokens、累積PP 12.32 tok/s付近でWindows crash |
| 今回の96GB / 32k | PP 269.22 / TG 23.31で正常完走 |
| 今回の96GB / 64k | 最初の2,048 tokensが15.32 tok/s。その後進捗ログが止まり、Windows crash |
今回の64k runでは、llama.cpp 専用forkのログ上で約50.2GiBをVulkan側、さらに約27.5GiBのCPU_Mapped tensorをlazy mappingしていた。96GB UMA設定ではCPU側から見える物理メモリが約32GiBしかないので、このmapped領域は無視できない大きさになる。
ただし、CPU_Mapped 27.5GiBは27.5GiBすべてが常時物理RAMにresidentしている、という意味ではない。実際、64GB設定で正常に動いている同じforkではworking setはかなり小さい。今回問題だったのは、96GB設定の実行中に実際のFree RAM低下と大量のpage-in、GPU memory usageの大きな変動が同時に起きていた点。
Windows側のリソースデータでも異常な動きが見えた。
| 指標 | crash run中の値 |
|---|---|
| llama GPU total committed | 中央値 54.42 GiB / 最大 54.52 GiB |
| llama GPU Dedicated | 0.05 ～ 53.81 GiBを大きく往復 |
| llama GPU Shared | 約0.71 GiB |
| Free system RAM | 最小 0 GiB、何度もほぼ0まで低下 |
| Pages Input | 最大 983,424 /s |
| Page Reads | 最大 14,733 /s |
| Disk Read | 最大 3,952.63 MiB/s |
GPU total committed自体は約54.5GiBでほぼ一定なのに、Windowsから見たDedicated residencyがほぼ0～54GiBの範囲を大きく往復していた。同時にFree RAMが何度も0近くまで落ち、大量のpage-inとdisk readが発生している。
少なくとも「普通のcommit limit OOM」には見えず、WDDM/UMA上でGPU allocationのresidencyを激しく入れ替えているような状態だった。
クラッシュ時はPCを放置していてディスプレイが自動OFFになっており、マウスを動かして画面を復帰させようとしたところ、しばらく反応がなく、その後Windowsの再起動画面になった。
minidumpをWinDbgで確認するとBugCheckは0x19C WIN32K_POWER_WATCHDOG_TIMEOUTで、Failure Bucketは以下だった。
0x19C_DRVSETMONITORPOWERSTATE_HANG_dxgmms2!VidMmTransitionToState
faulting threadのstackも、DxgkPowerOnOffMonitorからdisplay stackのcore sync / schedulerを経由してdxgmms2!VidMmTransitionToStateで待っている形だった。
つまり最終的にWindowsを落としたwatchdogは「モニターをpower onしようとしたが、GPU Video Memory Managerの状態遷移が時間内に完了しなかった」というものだった。
resource logではその直前まで激しいRAM枯渇、page-in、GPU residencyの往復が起きていたので関連はかなり疑わしいが、minidumpのstackにAMDのamdkmdag.sysが直接出ているわけではない。Windowsのdxgmms2側のedge caseなのか、AMD display miniportとの相互作用なのか、単に極端なresidency pressureがpower transitionを完了できなくしたのかまでは分からない。
「96GB設定にするとWindowsが落ちる」ということではなく、他の96GBテストは完走している。現時点では 96GB UMA + Unsloth UD-IQ3_XXS + この専用fork + 長context の組み合わせで落ちる確率が高い、としか言えない。
前回よりPPが速くなっている？？
第6回で計測したllama.cppはUnsloth buildのb10798-mix-659e406で、今回のupstreamはb10919なのだけど、特にROCmのPPがかなり速くなっているように見えた。
64GB設定で、第6回の値と今回のb10919を比べるとこうなっている。
| backend / context | b10798（第6回） | b10919（今回） | 差 |
|---|---|---|---|
| Vulkan 32k | 301.14 | 310.19 | +3.0% |
| Vulkan 64k | 225.89 | 227.97 | +0.9% |
| ROCm 32k | 249.79 | 324.90 | +30.1% |
| ROCm 64k | 191.90 | 276.58 | +44.1% |
Vulkanはほぼ同等なのに、ROCm PPはかなり違う。
最近PPに関しては、ときどき妙に速い値が出ることがあり、第6回でもROCm 32kで310.33 tok/sという上振れが1回あった。そこで今回の64GB条件は2回測定した。
| backend / context | b10919 run 1 | b10919 run 2 |
|---|---|---|
| Vulkan 32k | 303.72 | 310.19 |
| Vulkan 64k | 225.70 | 227.97 |
| ROCm 32k | 321.85 | 324.90 |
| ROCm 64k | 276.22 | 276.58 |
今回のROCmは32k/64kとも2回ほぼ同じ値になったので、少なくとも「たまたま1回だけ出た異常な上振れ」ではなさそう。
ただし、b10798→b10919の間にはQwen3.8-Flash-Next（qwen4exp）、Vulkan、ROCm、MoEまわりの変更がかなり入っているので、今回の結果だけから特定のcommitが+30～44%を生んだとは言えない。
この期間に今回の環境と直接的に関係する変更として、Qwen3.8-Flash-Next + Vulkan + AMD Strix Haloで--lazy-mode autoを使うとPPが約半分になるregressionが報告されている（llama.cpp issue #28160）。その後、iGPUではlazy tensor loadingをdefaultで無効化する修正（#28326）が入った。
これはVulkan側のメモリ配置・PPに効き得る変更だが、今回大きく伸びたのはROCmなので、これだけでは説明できない。ROCm側にもMoE/MMQ系を含む複数の最適化が入っており、build間の差分が大きすぎる。
PPはたまに異常に速い値が出るという現象は今回もあった。
たとえば64GBの専用forkでは、AgentionAI 32kが285.01→251.00、Unsloth 64kが186.08→125.38 tok/sと、同じ条件でもかなり振れた。後者はWindowsリソースログでresident memoryの大きな移動が見えているので、単なる偶然ではなく「たまに速い値が出る条件」があるのかもしれないが、今回は深追いしないことにする。
今回のupstream ROCm高速化は再測定でも再現したので結果として採用するが、PPの単発値、特にUMAでメモリ配置が境界に近い条件は、今後も複数回測った方がよさそう。
小さいモデルだとどうなる？
Qwen3.8-Flash-NextはEVO-X2で動かすにはかなり大きいモデルで、VRAM 96GB設定でも余裕がある状態とは言えず、BIOSでは96GB以上に割り当てを増やすことができなかった。
そこで、小さいモデルでGPU memoryに余裕がある場合にもUMA設定で速度が変わるのかを見るため、Qwen3.5-2B UD-Q4_K_XLを使って長コンテキストを試した。
まずnative contextの262,144で、235,846 tokensを入力した結果。
| BIOS VRAM設定 | GPU Dedicated | GPU Shared | GPU Total Committed | PP | TG |
|---|---|---|---|---|---|
| 2GB | 1.34 GiB | 3.52 GiB | 4.85 GiB | 943.68 | 41.06 |
| 32GB | 4.01 GiB | 0.91 GiB | 4.92 GiB | 951.41 | 43.43 |
| 64GB | 4.01 GiB | 0.91 GiB | 4.92 GiB | 956.71 | 42.79 |
| 96GB | 4.01 GiB | 0.91 GiB | 4.92 GiB | 958.07 | 58.38 |
PPは2GBの943.68から96GBの958.07まで、少しずつ速くなってはいるが、差は約1.5%しかなかった。
2GB設定ではGPU commitの大半がShared側に出ているのに、それでもPPはほとんど変わっていない。Qwen3.8で見えた「Dedicatedに収まる境界でPPが大きく変わる」という挙動は、少なくともこの小さいモデルでは出なかった。
TGは96GBだけ58.38 tok/sと高いが、生成token数が75程度しかなく測定時間が短いので、今回のUMA比較ではPPを主に見る。
さらに、公式native context 262kを超えてYaRNで1M（1,048,576）まで拡張し、943,645 tokensを入力した。
| BIOS VRAM設定 | GPU Dedicated | GPU Shared | GPU Total Committed | PP | TG |
|---|---|---|---|---|---|
| 2GB | 1.36 GiB | 10.50 GiB | 11.87 GiB | 292.67 | 22.25 |
| 64GB | 11.50 GiB | 0.41 GiB | 11.90 GiB | 294.93 | 22.32 |
| 96GB | 11.50 GiB | 0.41 GiB | 11.90 GiB | 299.72 | 22.05 |
1Mはnative 262kとは別条件なので絶対速度を比較する意味はないが、同じ1M条件でUMA設定だけを見ると、こちらも2GB～96GB少しずつ速くなってはいるが、差は小さい。
差は小さいと言っても全く同じとか、途中で逆転するわけではないところが、また不思議。
2GB設定では10GiB以上がShared側なのにPP 292.67 tok/s、64GBではほぼDedicatedに入って294.93 tok/s。今回のEVO-X2では、Shared memoryを使うこと自体が大きなペナルティなのではなく、モデルサイズ、アクセスパターン、backend、CPU側RAMの余裕などの組み合わせで影響が変わるように見える。
この流れで2M contextも試してみた。2M context自体と13GiBのKV cache確保には成功したが、実promptが約1.05M tokensを越えたあたりからVulkanのpinned memory allocation warningが繰り返し出て極端に低速化したので手動で止めた。
まとめ
EVO-X2のBIOSでVRAMを2GBにしても、「2GBのGPU」になるわけではない。
Windows / WDDM上では、BIOSのUMA Frame Buffer Sizeを超えたGPU memory commitがShared側へ回り、90GB級のモデルもそのまま動いた。128GB UMAという物理メモリ全体は変わらず、BIOS設定によってDedicated / Sharedの境界が動く、ということらしい。
Unsloth + upstreamのように約54GiBで済む構成は64GB設定でほぼDedicatedに収まり、そこでPPが大きく伸びた。約93GiBを使うAgentionAI ROCmFP4は96GBまで増やすほどSharedが減り、64k PPも伸びた。
しかし96GBへ増やすとCPU側から見えるRAMは約32GiBまで減る。Unsloth + 専用forkのように27.5GiBのCPU_Mapped tensorを持つ構成では、むしろこのCPU側の余裕のなさがWindowsごとクラッシュという事故につながった可能性がある。
ハーネスやチャットサーバーなどをEVO-X2内で共存させようと思ったら、その分のRAMも必要になる。
つまり、少なくともWindows版EVO-X2では、UMA Frame Buffer Sizeは「とにかく最大にしておけばよい設定」ではなさそう。
ということで、今のところは普段使いは元のまま64GBを継続することにした。
次回は一度Qwen3.8-Flash-Nextから離れて、Qwen3.5-2Bか他の軽量モデルを使って、メモリをコンテキスト長に全振りしたらどうなるかを試してみたい。
のだけど、専用forkでTGが速いのが気になるし、Strix Halo x Qwen3.8-Flash-NextでPPが4桁出るという噂も耳にしたし、最近llama.cppの中身をいじりたくなっている。これは安易に手を出してはいけない領域な気もするのだけど…
付録
EVO-X2のVRAM割り当て変更
EVO-X2を起動するときに、ESCキーを連打するとBIOS画面に入る。
「GFX Configuration」を選択して、「UMA Frame buffer Size」を変更し、「Save and Exit」する。
※VRAM設定は他に4G、8G、16Gも選択できるが今回は計測対象から外した。
テストデータの作り方
乾孝司・奥村学「テキストを対象とした評価情報の分析に関する研究動向」（『自然言語処理』Vol.13, No.3, 2006年、pp.201–241）
この論文の、言語処理学会論文誌LaTeXコーパス
に収録されているLaTeXソースから、第3章の一部を9,406字と14,874字で切り出した。
その後、9,406字のブロックと14,874字のブロックを繰り返して、必要な長さの日本語文書を作成し、最後に以下の指示を追加した。
以上が入力文書です。
複数回繰り返されている部分は無視して、入力文書のユニークな部分について要約してください。次の項目を含め、800字程度の日本語でまとめてください。
- 文書が扱う問題
- 主な手法の分類
- 評価表現辞書の構築方法
- 共起情報・PMI・文脈情報の役割
- 文書分類との関係
- 注意点または限界
文書に書かれていない内容は推測しないでください。
数式・専門用語は、意味を変えずに必要に応じて残してください。
主な実行条件
Qwen3.8-Flash-Nextの比較では、VRAM設定以外の主要条件をそろえた。
-ngl 999
-n 1024
-ncmoe 0
-t 4
-b 2048
-ub 1024
-fa 1
--temp 0.2
--top-p 0.8
--jinja
--single-turn
--reasoning off
contextは32k / 64k。MTPは全条件で無効。
Qwen3.5-2Bではupstream b10919 Vulkanに固定し、KV cacheはK/Vともq8_0、-b 2048 -ub 1024 -fa 1、temperature 0で測定した。1Mではnative 262,144を基準にYaRN scale 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
- UMA Frame Buffer test settings: 2 / 32 / 64 / 96 GB
- WindowsからCPU memoryとして見える量（llama.cpp起動時表示）
- 2GB設定: 約125.6 GiB
- 32GB設定: 約95.6 GiB
- 64GB設定: 約63.6 GiB
- 96GB設定: 約31.6 GiB
- GPU: AMD Radeon 8060S Graphics
- Storage: 1.82 TB total / 732 GB used / 約1.09 TB free
OS
- OS: Windows 11 Pro
- Version: 25H2
- OS Build: 26200.9168
- Installed: 2025-10-24
- Windows Feature Experience Pack: 1000.26100.344.0
AMD GPU driver
- AMD Software: Adrenalin Edition 26.8.1 WHQL Recommended
llama.cpp (upstream)
- b10919: Windows x64 Vulkan プリビルド
- b10919: Windows x64 ROCm 10.0 プリビルド
Windows版プリビルドについて
今回使用したllama-b10919-bin-win-vulkan-x64.zipは、筆者の環境ではダウンロード時にWindows DefenderからTrojan:Script/Wacatac.H!mlとして検出された。
ダウンロードしたZIPのSHA-256は318500010bbd20b781e9523a78ae496fa64b4f5bf3d892cb2b124a5193076303で、GitHubが公開しているb10919のattestationに記載されたWindows x64 Vulkan版のSHA-256と一致。
過去のllama.cpp Windows版でも同系統の検出報告がある。これをもって今回の検出が誤検知であると保証するものではない。利用する場合は各自で判断してください。
ROCm版の実行環境
upstreamのROCm版を実行するため、検証機にはHIP SDKを導入している。
- HIP SDK: 7.2.60201-38d754472
- HIP compiler: clang 21.0.0git
- HIP target: gfx1151
llama.cpp (AMD Strix Halo専用フォーク)
- fork:
https://github.com/LaurentZuijdwijk/llama.cpp - branch:
vulkan/qwen4exp-rocmfpx - build:
b10809 - commit:
5e085d123 - compiler: Clang 20.1.8
- backend: Vulkan
- upstream Qwen3.8 support:
https://github.com/ggml-org/llama.cpp/pull/27742
使用したモデル
AgentionAI ROCmFP4
- Repository:
agentionai/Qwen3.8-Flash-Next-ROCmFP4-FAST-imatrix-GGUF - URL: https://huggingface.co/agentionai/Qwen3.8-Flash-Next-ROCmFP4-FAST-imatrix-GGUF
- File name:
Qwen3.8-Flash-Next-ROCmFP4-FAST-v2-ple16.gguf - File size reported by llama.cpp: 87.05 GiB
- BPW: 4.23
- Model params: 176.94B
Unsloth UD-IQ3_XXS
- Repository:
unsloth/Qwen3.8-Flash-Next-GGUF - URL: https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF
- Quantization:
UD-IQ3_XXS - File size reported by llama.cpp: 76.32 GiB
- BPW: 3.71
- Model params: 176.94B
Qwen3.5-2B
- Repository:
unsloth/Qwen3.5-2B-GGUF - URL: https://huggingface.co/unsloth/Qwen3.5-2B-GGUF
- Quantization:
UD-Q4_K_XL - File size reported by llama.cpp: 1.24 GiB
- Model params: 1.88B
- native context: 262,144