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)

第7回 EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Next ROCmFP4を動かした話。長文処理も快適にできるかも？

0
Last updated at Posted at 2026-09-09

第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とチャットした話」
第6回「EVO-X2（Ryzen AI Max+ 395 / 128GB）+ Qwen3.8-Flash-Nextが、AMDドライバー更新したらVulkan版llama.cppで動くようになった話」
の続き。

第5回でQwen3.8-Flash-Nextを使って日本語長文要約＆読解支援を試してみて、意外と使えそうな感じだった。
けど高速モデルのGemma 4 26B A4Bと比較してしまったので、もうちょっと速くならないかと欲が出た。
そんなときにXで、Strix Halo（Ryzen AI MAX+ 395 / Radeon 8060S）向けに長文prefillを高速化した
agentionai/Qwen3.8-Flash-Next-ROCmFP4-FAST-imatrix-GGUF
を見つけた。モデルカードには87GiB級のモデルをGPU側に置いたまま、32kで245.5 tok/s、128kでも137.7 tok/sのprefillが出ると書いてある。
これを、EVO-X2 + Windowsで動かせるか試してみた。

以降、Prompt Processing（入力を読み込む処理）をPP、Token Generation（出力生成）をTGと表記する。どちらも単位はtok/sで、高いほど速い。

結論

専用forkのllama.cppをWindowsでビルドしたら、EVO-X2、Windows 11、UMA Frame Buffer 64GBの状態で
agentionai/Qwen3.8-Flash-Next-ROCmFP4-FAST-imatrix-GGUF
の Qwen3.8-Flash-Next-ROCmFP4-FAST-v2-ple16.gguf を全層GPU offloadで動かせた。

今まで使っていた Unsloth/Qwen3.8-Flash-Next-GGUF の UD-IQ3_XXS と同じllama.cpp・Vulkan・同じ長文入力で比較すると、AgentionAI版は全体としてPPが速かったが、unslothの別llama.cppビルドでの最速値と比較すると、すごく速いわけでもない。

TGは今回の計測ではAgentionAIとUnslothで大差ないように見えたが、長コンテキストでもそこそこのTGが維持できているのは今までの計測ではなかったところ。

第5回と同じ日本語論文の要約・読解支援も試したところ、今回の簡単な比較ではAgentionAI版の出力の方が読みやすかった。

今回の主な検証環境

今回の実験内容と速度比較に関係するものだけ先に書く。詳細は記事末尾に。

項目 内容
PC GMKtec NucBox EVO-X2
APU AMD Ryzen AI MAX+ 395 / Radeon 8060S
RAM 128GB UMA
OS Windows 11 Pro 25H2
AMD GPU driver Adrenalin 26.8.1 WHQL Recommended
通常のUMA Frame Buffer 64GB
比較用UMA Frame Buffer 96GB
llama.cpp b10809 / commit 5e085d123
backend Vulkan
build LaurentZuijdwijk fork / vulkan/qwen4exp-rocmfpx
AgentionAI model 87.05 GiB / 4.23 BPW / 176.94B
Unsloth model 76.32 GiB / 3.71 BPW / 176.94B

今回比較した2つのGGUFはファイルサイズも量子化方式も同じではない。
そのため、速度・出力品質とも「同サイズ量子化同士の厳密な品質比較」ではなく、今まで自分が実際に使っていたUnsloth UD-IQ3_XXSとの実用上の比較として見ている。

llama.cppの専用forkをビルドする

AgentionAI版のモデルカードを見ると、Qwen3.8-Flash-Next自体の対応はupstreamの
ggml-org/llama.cpp PR #27742
にあるが、今回のROCmFPx量子化形式とper-head PLE layoutを使うには、さらに
LaurentZuijdwijk/llama.cpp
の vulkan/qwen4exp-rocmfpx branchが必要と書かれている。

今までプレビルドのllama.cppしか使ったことがなく、ビルドはちょっとハードルが高かったので、まず手元にあったプレビルドWindows版llama.cppの b10679-rocm、b10679-vulkan、b10798-mix-659e406-rocm、b10798-mix-659e406-vulkan

でこのモデルを使ってllama-serverを起動してみたが、

load_model: failed to load model, 'C:\llama\models\agentionai\Qwen3.8-Flash-Next-ROCmFP4-FAST-v2-ple16.gguf'

と言われてすべて失敗した。

当時の最新プレビルドでも同じだった。
当時のbuild番号を控え忘れたので、記事執筆時（2026/9/9 20:00）時点の最新版 b10874-vulkan でも改めて試したが、やはり同じところで失敗した。

仕方がないので自分でビルドしてみる。

ビルド手順の短いまとめ

初めてなので色々ハマったけど、それは後でまとめて書くことにして、成功手順のみ先に書く。

前提として、Build Tools for Visual Studio 2026は既にインストール済みだった。
さらに「個別のコンポーネント」で、
・LLVM (clang-cl) ツールセットの MSBuild サポート
・Windows 用 C++ Clang コンパイラ（22.1.3）
を追加してある。(このVisual Studio付属Clang 22.1.3は今回のforkの実ビルドには使わなかった)
導入済みのBuild Tools for Visual Studio 2026は 公式サイトから、インストーラvs_BuildTools.exeをダウンロードして最小構成でインストールしたもの。

gitも以前に既に導入済み。確かこのコマンドでインストールしている

winget install --id Git.Git -e --source winget

今回ダウンロードしてインストールしたものはこれ。

  • LLVM / Clang 20.1.8　ダウンロードファイル名: LLVM-20.1.8-win64.exe
  • LunarG Vulkan SDK 1.4.357.0 ダウンロードファイル名: vulkansdk-windows-X64-1.4.357.0.exe
  • 7-Zip ダウンロードファイル名: 7z2602-x64.exe
  • jinja (python導入済みなので pip install Jinja2 でインストール)

環境設定ができたらビルドスタート。以下の作業はスタートメニューから「Visual Studio 2026」内のの「x64 Native Tools Command Prompt for VS」を開いて行った。
まずforkをcloneしてbranchを切り替える。

cd C:\llama-build
git clone https://github.com/LaurentZuijdwijk/llama.cpp.git agention-vulkan
cd agention-vulkan
git switch vulkan/qwen4exp-rocmfpx

ROCm付属ClangとVisual Studio付属Clangではなく、新しくインストールしたLLVM 20.1.8のClangが呼び出されるように、ビルド用コマンドプロンプトでLLVM 20.1.8ATHの先頭に置く。ついでにと7-ZipにもPATHを通す。

set "PATH=C:\LLVM\20.1.8\bin;%PATH%"
set "PATH=C:\Program Files\7-Zip;%PATH%"

そのうえでconfigure。

cmake -S . -B build -G "Ninja Multi-Config" ^
  -D CMAKE_TOOLCHAIN_FILE=cmake/x64-windows-llvm.cmake ^
  -DGGML_VULKAN=ON ^
  -DGGML_NATIVE=OFF ^
  -DGGML_BACKEND_DL=ON ^
  -DGGML_CPU_ALL_VARIANTS=ON ^
  -DGGML_OPENMP=ON ^
  -DGGML_OPENMP_FETCH=ON ^
  -DLLAMA_BUILD_BORINGSSL=ON ^
  -DLLAMA_BUILD_EXAMPLES=OFF ^
  -DLLAMA_BUILD_TESTS=OFF ^
  -DLLAMA_BUILD_TOOLS=ON ^
  -DLLAMA_BUILD_SERVER=ON ^
  -DGGML_RPC=ON

最後に、

cmake --build build --config Release --target llama-server llama-cli llama-bench

でビルドした。できたexeはこの中。

C:\llama-build\agention-vulkan\build\bin\Release

できたexeの動作確認。

llama-cli.exe --version
llama-server.exe --version
llama-cli.exe --list-devices

ここまでで、とりあえず今回のモデルを試す準備は完了。

まずはVRAM64GBで動かしてみた

相変わらずネットワーク環境がショボくて、90GB近いモデルをダウンロードするのに数時間かかった。
実はビルド完了後、第6回に書いたAMDドライバー更新の前にllama-serverで今回のモデルを起動したところ、第1回のVulkan版と同じところでクラッシュした。
チャッピー様に相談したら、「このモデルは諦めて、ビルド成功までの経緯と第1回と同じところでクラッシュしたというところまでで記事にしたらどうですか。それだけでも結構情報量があります」と見放されたのだけど、せっかく時間をかけて大きいモデルをダウンロードしたので諦めきれなくて30分ぐらい調べていたら第6回の内容が発覚した。
というわけで、ネットワークの遅さもたまには役に立つ？？

話を戻して、モデルカードではこのモデルは

Sized for the 96 GiB VRAM carve-out of a Strix Halo

と説明されている。

うちのEVO-X2は普段BIOS設定でVRAM割り当てを64GBにしている。しかも配布ページのコマンド例はLinuxっぽい。
AMDドライバーを更新したけど「Windows + 64GB設定で、87GiBのモデルがそもそも動くのか？」というところから心配だったので、最初はcontextを8192にしてllama-serverを起動した。

そしたら普通に起動して、簡単な推論もできた。ログでは、

Vulkan0 : AMD Radeon(TM) 8060S Graphics (114326 MiB, 108610 MiB free)
Vulkan0 model buffer size = 88645.69 MiB
offloaded 49/49 layers to GPU

となっている。
BIOSでは64GBを割り当てているのに、Vulkanからは約114GBのtotal memoryが見えていて、87GiBのモデルも全層GPU側に載っている。UMAの不思議なところ。

MTP draft modelも試したところ、こちらもロードできた。
AgentionAIのMTP modelは、
agentionai/Qwen3.8-Flash-Next-MTP-ROCmFP4-FAST-GGUF
の Qwen3.8-Flash-Next-MTP-ROCmFP4-FAST.gguf を使用した。

64GB UMAで長文速度を測る

第4回と同じ日本語長文入力を使って、context 32k / 64k / 96k / 128k / 256kを測った。

固定した主な条件は、

  • -ngl 999
  • -ncmoe 0
  • -t 4
  • -b 2048
  • -ub 1024
  • -fa 1
  • generation 1024 tokens
  • temperature 0.2
  • top_p 0.8
  • thinking off

比較対象のUnsloth UD-IQ3_XXSも、過去の数字をそのまま使うのではなく、今回ビルドした同じ b10809 Vulkan版で再測定した。

MTPなし

context 実入力 tokens 出力 tokens (AgentionAI / Unsloth) AgentionAI PP Unsloth PP AgentionAI TG Unsloth TG
32k 29,557 518 / 483 296.73 272.58 23.51 23.80
64k 61,789 584 / 537 191.12 126.07 21.19 22.31
96k 94,021 584 / 489 149.90 118.94 20.40 21.37
128k 126,253 587 / 466 128.20 101.30 19.61 20.36
256k 255,181 586 / 423 90.85 22.45 16.65 17.58

PPは全体的にAgentionAIの方が速い傾向がある。

ただ、256kのUnsloth 22.45 tok/sは過去にROCmで測った値（97.66 tok/s）と大きく異なるため、モデル固有の性能差として単純に「4倍速い」というわけではなさそう。今回のVulkan + build + メモリ配置の組み合わせで極端に低下している可能性がある。

TGはUnslothの方が少し速い。

-n 1024 を上限にしているが、どちらのモデルもEOGまで生成して終了しているため、実際の出力token数は行ごとに異なる。

普段よく使う「長い文書を最初に読み込ませる」処理ではAgentionAIの方が待ち時間を短くできる気がする。

MTPあり

AgentionAI版には専用MTP draft modelがあるので、同じ条件でMTPありも測った。

context PP MTPなし PP MTPあり TG MTPなし TG MTPあり draft acceptance
32k 296.73 270.02 23.51 26.55 71.5%
64k 191.12 182.25 21.19 26.02 74.6%
96k 149.90 139.81 20.40 23.28 70.3%
128k 128.20 119.54 19.61 23.43 75.3%
256k 90.85 78.45 16.65 19.03 72.5%

今回もMTPを入れるとTGは上がるが、PPは少し下がった。
このぐらいの差だと、どっちを重視するか悩ましい。

Unslothの過去データと比べてみる

過去記事にもUnsloth UD-IQ3_XXSの測定結果があるが、今回とは条件が違う。

  • 第6回: b10798-mix-659e406-vulkan / Vulkan / 新AMD driver
  • 今回: b10809 専用fork / Vulkan / 新AMD driver

第6回では、今回と同じ入力ファイルを使ってMTPなし・ncmoe=0のVulkan版を測っている。32k/64kは複数回測定の中央値、128kは1回だけの参考値だが、今回の測定結果と並べてみた。

context 第6回 Unsloth b10798 Vulkan PP 今回 Unsloth b10809 Vulkan PP AgentionAI PP 第6回 Unsloth TG 今回 Unsloth TG AgentionAI TG
32k 301.14 272.58 296.73 22.51 23.80 23.51
64k 225.89 126.07 191.12 16.55 22.31 21.19
128k 146.08 101.30 128.20 12.04 20.36 19.61

最初の表だとPPはAgentionAIモデルの方がUnslothモデルより速く見えるが、それは今回のllama.cppビルドとの組み合わせの問題で、llama.cppのビルドが違う過去データを含めた最速値を取れば、ここまでの結果ではUnslothの方が速い。
PPはUnsloth前回 > AgentionAI > Unsloth今回 となっている。

第6回で書いた「たまにPPだけ妙に速い」現象は今回も発生しているので、PPの差を単純に比較するのは要注意だけど、全contextで傾向としては同じ。

そして、TGだと評価は逆転して、Unsloth今回 > AgentionAI >> Unsloth前回となる。特に長contextでの差が目立つ。

ちなみに、第4回には Unslothモデル、同データでの b10798-mix-659e406-rocm / ROCm / 旧AMD driverでの測定データがあるが、第6回のVulkanの方がPP、TGとも速かったので、今回の比較には使っていない。

作者の公開値とも比べてみる

AgentionAIのモデルカードには、同じStrix Haloでの長context速度が公開されている。

MTPなしの作者値は、

depth 作者 PP 作者 TG
32k 245.5 24.67
64k 188.0 23.09
128k 137.7 19.70

今回64GB UMAで測った値は、

context 今回 PP 今回 TG
32k 296.73 23.51
64k 191.12 21.19
128k 128.20 19.61

32kでは今回計測したPPが高め、128kでは低めに出ているが、だいたい近い値が出ているので、私の環境設定がとんでもなく間違っているということはなさそう。

ただし、作者のテストと今回の計測では

  • OS
  • 測定方法
  • 実際の入力token数
  • KV cache

などが違うので、厳密な比較ではない。
今回の計測はllama-benchのdepthではなく日本語の文書を入れていて、実入力の長さは

  • 32k test: 約29.6k tokens
  • 64k test: 61,789 tokens
  • 128k test: 126,253 tokens
  • 256k test: 255,181 tokens
    なので、コンテキストぎりぎりまでデータを入力しているわけではない。

それでも「短contextでは速く、contextが深くなるとPPが落ちていくが128kでも100 tok/s超」という全体傾向は近い。

作者が推奨しているQ8 KV cacheも試してみる

作者の起動例では、

-ctk q8_0 -ctv q8_0 -fa on

が使われている。

モデルカードによると、Q8 KVにするとfull 262144 contextでKV cacheが約6GiBから約3.2GiBに減り、作者環境ではthroughput costは確認されなかったとのこと。

第2回でUnsloth版 + b10679 ROCmを使って128kの llama-bench を測ったときは、Q8_0にしても速度はほぼ変わらなかったので、速度面ではあまり期待はせず、メモリ使用量はどのぐらい減るかを確認するだけのつもりだった。

けど、AgentionAI版で64k実入力を使って試すと、最初のQ8測定で 234.54 tok/s と妙に高い値が出た。

第6回でも、同じ条件を連続測定するとPPは安定しているのに、別のタイミングでは20%以上速い値が突然出ることがあったので、この1回だけでは判断せず、FP16とQ8を追加で3回ずつ測定した。

KV PP run 1 PP run 2 PP run 3 平均
FP16 199.0 197.0 196.8 約197.6
Q8_0 218.9 220.4 226.1 約221.8

Q8_0のPPは追加3回平均でFP16より約12%速かった。64kでのUnslothの最速値に近い値が出ている。

TGはほぼ変わらなかった。

  • FP16平均: 約21.8 tok/s
  • Q8_0平均: 約21.8 tok/s

KV cacheサイズは64kではかなり小さくなった。

KV main KV indexer KV
FP16 1536 MiB 576 MiB
Q8_0 816 MiB 306 MiB

他のコンテキスト長でも測ってみたかったけど、時間がないので今回はやめておく。

VRAMを96GBに変えて再測定

64GBでも全層GPUに載っていたので、「96GBに変えても、あまり変わらないかも？」と思いつつ、BIOSのVRAM設定を96GBに変えて再測定した。

まず興味深かったのが、llama.cppから見えるVulkan memory。

BIOS UMA設定 Vulkan total Vulkan free CPU側total RAM
64GB 114326 MiB 約108610 MiB 約65174 MiB
96GB 114507 MiB 約108782 MiB 約32406 MiB

64GB → 96GBに変えてもVulkan totalは約181MiBしか増えていない。
一方、WindowsからCPU側に見えるRAMは約64GB → 約32GBへ半減する。

つまり少なくともこのWindows + Vulkan環境では、

BIOSのUMA Frame Buffer Size = Vulkanが使えるメモリ総量
という単純な関係には見えない。

AgentionAIは96GBでかなり速くなった

MTPなしのPP比較。

context 64GB PP 96GB PP 差
32k 296.73 334.73 +12.8%
64k 191.12 218.64 +14.4%
96k 149.90 166.92 +11.4%
128k 128.20 138.59 +8.1%
256k 90.85 97.95 +7.8%

MTPあり PP

context 64GB PP 96GB PP 差
32k 270.02 314.68 +16.5%
64k 182.25 208.24 +14.3%
96k 139.81 151.17 +8.1%
128k 119.54 131.86 +10.3%
256k 78.45 87.99 +12.2%

PPは全contextで96GB設定の方が速かった。32kではUnslothの第6回の最速値より速くなっている。64k,128kではまだ第6回の方が少し速いが、Q8 KV cacheを入れるとさらに速くなるかもしれない(試してはいない)。

MTPなし TG

context 64GB TG 96GB TG 差
32k 23.51 24.72 +5.1%
64k 21.19 22.96 +8.4%
96k 20.40 21.96 +7.6%
128k 19.61 20.93 +6.7%
256k 16.65 18.26 +9.7%

最初に測ったVRAM64GB MTPなしの測定では、TGは微差だが Unsloth > AgentionAI だった。VRAM96GBのAgentionAIのTGは、全contextでVRAM64GB時のUnslothのTGを越えている。
後述するようにVRAM96GBで今回のllama.cppビルドでのUnslothモデルはPPが極端に遅くなりTGも遅くなっていたので、ここまでのMTPなしの最速値はVRAM96GBのAgentionAIとなる。

MTPあり TG

context 64GB TG 96GB TG 差
32k 26.55 29.43 +10.8%
64k 26.02 27.07 +4.0%
96k 23.28 26.37 +13.3%
128k 23.43 24.39 +4.1%
256k 19.03 19.26 +1.2%

TGも全体として96GB設定の方が速かった。ただしPPほど一貫した差ではなかった。
今までのQwen3.8-Flash-Nextの全計測値のなかで、実際に長文を入力した後のTGではこれがほぼ最速値。(第4回のshared版MTPモデルを使った32kの測定値は今回より速いが、他のcontextでは測っていなくて、他の測定値の傾向から多分高contextでは遅くなると考えられる)

96GB MTPありの256kでは、起動時の見積もりでdevice memory使用量が約105684MiB、freeが約108284MiBで、残りは約2.6GiB。かなりギリギリではある。

Unslothには96GBが逆効果だった

同じ96GB設定でUnsloth UD-IQ3_XXSも試すと、

context PP TG
32k 14.86 22.89
64k 12.86 21.37

と、PPの値が何かの見間違いではないかというぐらいに低下した。VRAM64GBの測定時からUnslothのモデルは第6回のb10798-mix-659e406 vulkanビルドと比較して、今回のllama.cppビルドとの相性が悪そうな気はしていたが、VRAM96GBでの相性は最悪のようだ。

Unslothのロードログを見ると、

per_layer_token_embd.weight size = 27465 MiB, lazy read enabled
CPU_Mapped model buffer size = 27465.95 MiB

という巨大なCPU_Mapped / lazy read領域がある。

96GB UMA設定ではCPU側の物理RAMが約32GBしか残らないため、この約27GiB領域とOS・その他のメモリ使用がぶつかる。

96k試験では最初から約12 tok/sで進み、途中からFree RAMがほぼ0になって激しいページングが発生したので、それ以降のUnsloth 96GB試験は中止した。

ここで分かったのは、

UMA Frame Bufferは大きければ大きいほど良いわけではない

ということ。

AgentionAI版は巨大なPLEを含めてGPU側にresidentするレイアウトなので96GBが有利だった。
一方、CPU_Mapped領域を持つUnsloth版では、96GBにするとhost RAM不足が先に問題になる。

同じQwen3.8-Flash-Nextでも、モデルのメモリ配置によって最適なUMA設定はかなり違うようだ。

日本語長文の要約＆読解支援性能をチェック

まだAgentionAI版モデルの最速値を追えていない気がして、VRAM96GB、Q8 KV cacheでコンテキスト128k、256kの計測もしたかったのだが、一度本来の目的に立ち返って、日本語長文の要約＆読解支援を試すことにした。

第5回 と同じ日本語論文を使い、

  1. 第5回のQ1と同じプロンプトで文書全体を約1000字で要約依頼
  2. 「今要約した内容を高校生にも分かるように簡単に説明してください」

の2ターンだけ会話した。

今回のチャット比較は、今回のllama.cppではUnsloth側のMTP modelをロードできなかったため、両モデルともMTPなしで揃えている。

出力内容

初回要約 AgentionAI
image.png

初回要約 Unsloth
image.png

2ターン目出力 AgentionAI
image.png

2ターン目出力 Unsloth
image.png

今回の2ターンだけを見た範囲では、AgentionAI版の方が変な引っ掛かりが少なかった。

Unsloth版の1ターン目では、

課題は6点挙げられる。

と書いた後、実際には①～⑤の5項目しか列挙していなかった。 これは第5回で同じモデルを試したときにも同じことが起きていた。

2ターン目では、

書き込まれない評価：「買ってすぐ壊れた」と書かれていなくても「最悪だ」とわかるような、あえて書かれない評価をどう拾うか

という説明があり、何を言われているのかよく分からない。
AgentionAI版では、同じ部分を

明示的に書かれていない評価の読み取り(例：「買ってすぐ壊れた」→明らかに不満)

と説明していて、こちらはちゃんと意味が伝わる。

また、Unsloth版は2ターン目で「評価の分類軸の細分化・再考」に相当する項目を落としていたが、AgentionAI版は「肯定・否定以外の分類軸の検討」として残していた。

ただし今回比較したのは各モデル1会話、2ターンだけ。
またAgentionAIは87.05GiB、Unsloth UD-IQ3_XXSは76.32GiBでモデルファイルサイズも量子化タイプも違う。

そのため「AgentionAIの方が一般的に高品質」と結論するものではなく、今回の日本語長文要約タスクではAgentionAI版の方が安定して見えた、という程度の結果としておく。

まとめ

今回は、Strix Halo向けに公開されているAgentionAI版 Qwen3.8-Flash-Next-ROCmFP4-FAST を、EVO-X2 + Windowsで動かしてみた。

主な結果は、

  • 専用forkをWindowsでビルドすれば、UMA Frame Buffer 64GBでも87GiB級モデルを全層GPU offloadで動かせた
  • コンテキスト64kでしか試していないが、KVキャッシュをFP16からQ8にすると速くなった
  • AgentionAI版はVRAM64GB設定よりも96GB設定の方が全体的に速くなった
  • 今回ビルドしたllama.cpp同士で比較すると、AgentionAI版はUnsloth版よりPPが速い、TGは大差ない
  • ただし、別ビルドのllama.cppでのUnsloth版最速値と比較すると、条件によってどちらが速いかが違う
  • 最初はPPが速いのがAgentionAI版の特徴かと思ったが、高contextのTGも速い
  • 日本語論文の要約・読解支援では、今回の2ターンではAgentionAI版の方がUnsloth版より読みやすかった

そして、今後日常的にどの設定でどのモデルを使うかは、かなり悩ましいことになっている。
たぶん、PP、TGとも最速に近く、日本語品質も良いのは、VRAM96GB設定にして、AgentionAI版をKVキャッシュQ8量子化で使うパターン。
なのだけど、普段VRAM64GB設定にしているのは、Evo-X2をローカルLLM以外の画像処理や動画処理にも使っているからで、VRAM96GB常用化して困らないかは試してみないと分からない。

今まで色々試してきたけど、可変項目を色々いじると組み合わせが爆発するので、最速かもしれない組み合わせを全context長で試せていない。
第4回のllama.cpp(b10798-mix) x Unsloth版モデル x MTPモデルshared Q8_0 とか、
今回のllama.cpp(専用ビルド) x AgentionAI版モデル x MTP x KVキャッシュQ8 +　VRAM96GB とか。
でも、最新のllama.cppに更新したらまた色々変わるかもだし、キリがないので、最速値を追うのはやめようと思う。

次は、Evo-X2のBIOS画面でVRAM設定は2 / 4 / 8 / 16 / 32 / 64 / 96GBを選べるので、2GBにしたらモデルはGPU側に乗るのか、VulkanとROCmで挙動が違うのかなどを試してみたい。
temperatureなどのパラメータのチャットへの影響とか、OpenWebUIとOpenCodeで使ったときの挙動も調べてみたいのだけど、第5回で実タスクの評価は結構大変だということに気づいてしまった。速度計測なら結果は数字で出るからチャッピー様に表にしてもらって、見たまんまの考察を書くだけなのだけど、実タスクだと最初に評価基準を作らないといけないし、出力結果も丸ごと貼れないからどうやって見せるかを考えないといけない。
などと考えていると、また予想外の方向に脱線する可能性もある。

付録

llama.cppビルドの試行錯誤記録

今回のforkはWindowsでもビルドできたが、ROCm導入済み環境だったこともあり、何か所かハマった。

最終的に成功した組み合わせは以下。

  • LaurentZuijdwijk/llama.cpp
  • branch: vulkan/qwen4exp-rocmfpx
  • build: b10809
  • commit: 5e085d123
  • compiler: Clang 20.1.8
  • backend: Vulkan
  • Vulkan SDK: LunarG Vulkan SDK 1.4.357.0
  • build system: CMake + Ninja Multi-Config

ビルド後は、

llama-cli.exe --version

version: 0.3.0-dev (build 10809, commit 5e085d123)
built with Clang 20.1.8 for Windows x86_64

まで確認できた。

1. 最初はglslcがなくて止まった

Vulkan shaderのコンパイルに必要なglslcが見つからず停止した。

LunarG Vulkan SDK 1.4.357.0を入れて、

glslc --version

が通る状態にしたら解消した。

2. ROCm付属のClangを拾ってしまった

ROCmを入れているので、最初は

C:\Program Files\AMD\ROCm\7.2\bin\clang.exe

がPATH上で優先されており、

undefined symbol: mainCRTStartup

でconfigureに失敗した。

3. Visual Studio付属Clang 22でも通らなかった

Visual Studio 18 Build Tools付属のClang 22.1.3を使うと、

LLVM OpenMP 20.1.8 requires Clang 20.x

でconfigureが止まった。

さらにOpenMPの問題を避けても、CPU SSE4.2 backendで_mm_prefetch()周辺の型エラーが出た。

ビルド用のコマンドプロンプトだけ、

set "PATH=C:\LLVM\20.1.8\bin;%PATH%"

として、別途入れたLLVM 20.1.8を先に使うようにした。

システム全体のPATHは変更していない。

4. CMake optionの組み合わせにも注意

最初は、

GGML_NATIVE=ON
GGML_BACKEND_DL=ON

を同時に指定して、

GGML_NATIVE is not compatible with GGML_BACKEND_DL

と言われた。

最終的には、

GGML_NATIVE=OFF
GGML_BACKEND_DL=ON
GGML_CPU_ALL_VARIANTS=ON
GGML_OPENMP=ON
GGML_OPENMP_FETCH=ON

にした。

5. 7-Zipは入っているだけでは足りなかった

GGML_OPENMP_FETCH=ONではLLVM OpenMPの展開に7-Zipを使う。

7-Zip自体はインストール済みだったがPATHに入っておらず、

GGML_OPENMP_FETCH requires 7-Zip to extract the LLVM installer

で止まった。

set "PATH=C:\Program Files\7-Zip;%PATH%"

として解消した。

最終的に通ったconfigure / build

cmake -S . -B build -G "Ninja Multi-Config" ^
  -D CMAKE_TOOLCHAIN_FILE=cmake/x64-windows-llvm.cmake ^
  -DGGML_VULKAN=ON ^
  -DGGML_NATIVE=OFF ^
  -DGGML_BACKEND_DL=ON ^
  -DGGML_CPU_ALL_VARIANTS=ON ^
  -DGGML_OPENMP=ON ^
  -DGGML_OPENMP_FETCH=ON ^
  -DLLAMA_BUILD_BORINGSSL=ON ^
  -DLLAMA_BUILD_EXAMPLES=OFF ^
  -DLLAMA_BUILD_TESTS=OFF ^
  -DLLAMA_BUILD_TOOLS=ON ^
  -DLLAMA_BUILD_SERVER=ON ^
  -DGGML_RPC=ON

cmake --build build --config Release --target llama-server llama-cli llama-bench

途中にはanonymous structs are a GNU extensionやdeprecated APIなど多数のwarningが出たが、GGML_CPU_ALL_VARIANTS=ONで複数のCPU backendをまとめてビルドしているため同じwarningが繰り返し表示されていた。

また、

UI: LLAMA_UI_GZIP requested but gzip not found, embedding uncompressed

も出たが、UIを非圧縮で埋め込むだけなのでbuild自体には影響しなかった。

今回重要だったのは、Vulkan SDKを入れる、ROCm版Clangを避ける、Clang 20.1.8に合わせる、CMake optionを正しく組み合わせる、7-ZipをPATHに入れるの5点だった。

長文要約テストのコマンド例

モデル以外は第4回の条件をベースにした。

.\llama-cli.exe `
    -m "(モデルのパス)\Qwen3.8-Flash-Next-ROCmFP4-FAST-v2-ple16.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

Q8 KVを使う場合は、

-ctk q8_0 -ctv q8_0

に変更した。

MTPではAgentionAIのdraft modelを指定して、

-md Qwen3.8-Flash-Next-MTP-ROCmFP4-FAST.gguf
--spec-type draft-mtp
--spec-draft-n-max 2
--spec-draft-p-min 0

を追加した。

テストデータの作り方

乾孝司・奥村学「テキストを対象とした評価情報の分析に関する研究動向」（『自然言語処理』Vol.13, No.3, 2006年、pp.201–241）

この論文の、言語処理学会論文誌LaTeXコーパス
https://www.anlp.jp/resource/journal_latex/
に収録されているLaTeXソースから、
(速度チェック用)第3章の一部を9,406字と14,874字で切り出し、9,406字のブロックと14,874字のブロックを繰り返して、必要な長さの日本語文書を作成した。
(日本語性能チェック用)本文のみを切り出して、LaTexの記号と図表を除去した35,515字のテキストファイルを作成した。

詳細な検証環境

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（64GB UMA時）: 約63.6 GB
  • UMA Frame Buffer: 64 GB / 96 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

AMD GPU driver

  • AMD Software: Adrenalin Edition 26.8.1 WHQL Recommended
  • driver更新の経緯は第6回を参照

llama.cpp

  • 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

使用したモデル

Target model

MTP draft model

Comparison model

  • 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
  • per_layer_token_embd.weight: 約27465 MiB / lazy read
  • CPU_Mapped model buffer: 約27465.95 MiB

比較時の注意

過去記事の測定値は以下のように条件が異なる。

記事 llama.cpp backend AMD driver
第4回 b10798-mix-659e406 ROCm 旧driver
第6回 b10798-mix-659e406 Vulkan 新driver
今回 b10809 専用fork Vulkan 新driver

そのため、過去値は参考値として扱い、今回のAgentionAI / Unsloth直接比較は同じb10809 Vulkanで測定した値を使用した。

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?