第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