llama.cpp qwen4exp MTP (Qwen3.8-Flash-Next) — Strix Halo (ROCm) 検証まとめ
最終更新: 2026-09-05 write by Claude そねっとさん
1. 目的
Windows / ROCm(Strix Halo, gfx1151)環境で、llama.cppのqwen4exp MTP(Multi-Token Prediction)機能を使い、Qwen3.8-Flash-Nextのコーディングエージェント用途での推論速度を改善できるか検証する。焦点は「速度が上がっても正答率・品質が落ちないか」。
2. 環境
| 項目 | 内容 |
|---|---|
| ハードウェア | GMKtec NucBox EVO-X2 、AMD RYZEN AI MAX+ 395 w/ Radeon 8060S(Strix Halo、RDNA3.5 iGPU、gfx1151)、統合メモリ128GB |
| OS | Windows |
| ビルド用SDK | ROCm 7.1(公式、C:\Program Files\AMD\ROCm\7.1) |
| 実行時DLL | TheRock 7.13.0(Lemonade同梱、...\lemonade\bin\therock\gfx1151-7.13.0\binをPATH最優先) |
| ビルド元 |
danielhanchen/llama.cpp の qwen4exp/mtp ブランチ(= PR #28243、最新コミット 2857e51) |
| モデル | Qwen3.8-Flash-Next(Unsloth製 UD-Q4_K_XL)+ MTPサイドカー(mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf) |
3. 関連PR / issueマップ(ggml-org/llama.cpp)
| # | 作者 | 内容 | 状態 |
|---|---|---|---|
| #27742 | — | qwen4exp アーキテクチャ本体 | (前提、マージ済み想定) |
| #27836 | rmonsurate | NextN/MTP draft head 本体 | Draft・未マージ |
| #28097 | TheArchitectit | draft-head-only GGUFロード対応 + speculative.cppのdraft-loadパス取り違えバグ修正 |
Draft・未マージ |
| #28123 | ServeurpersoCom | recurrent state rollback対応(checkpoint方式より効率的な投機的デコード) | Draft・未マージ、今回のビルドには未適用 |
| #28243 | danielhanchen | 共有MTPモジュール(embed_tokens共有)+ CUDAグラフキャッシュキー修正など。今回これをビルドして使用 | Draft・10コミット・最新2857e51・2026-09-02以降動き無し |
参考にした外部プロジェクト: evanwtf/local-llm(個人ベンチマークプロジェクト)— 「MTP採用率はプロンプトの性質次第」「同一バイナリ・同一重みで比較する」等の方法論を参考にした。
4. ビルド設定
- CMakePresetsの
rocm隠しプリセット:GGML_HIP=ON,GPU_TARGETS/AMDGPU_TARGETS=gfx1151 - コンパイラ: ROCm 7.1 SDK同梱の
clang/clang++ - 検証したが見送ったオプション:
-
GGML_HIP_ROCWMMA_FATTN: rocwmmaヘッダがROCm 7.1 SDKに同梱されておらず、有効化するとCHECK_INCLUDE_FILE_CXXでFATAL_ERRORになる見込み。C:\ROCm\7.14(公式AMD版、コンパイラ一式込み)にrocwmmaが同梱されているのを発見したが、過去にこの7.14でのビルドが失敗した経緯があり保留。 -
GGML_HIP_GRAPHS: ggml側定義で"experimental, slow"と明記、過去の不安定性報告(hipGraphDestroyクラッシュ)もあり見送り。
-
Visual Studio 2026 CmakePresets.json
(Base設定)
{
"name": "base",
"hidden": true,
"toolset": {
"value": "version=14.44.35207",
"strategy": "external"
},
"environment": { "LLAMA_VER": "qwen4exp-mtp-2857e51" },
"cacheVariables": {
"CMAKE_INSTALL_PREFIX": "D:/llm/llama-cpp-builds/llama-$env{LLAMA_VER}-bin-win-$env{MY_BACKEND}-x64",
"GGML_LTO": "ON"
}
},
(Clang-win設定）
{
"name": "clang-win",
"hidden": true,
"cacheVariables": {
"CMAKE_C_COMPILER": "C:/Program Files/AMD/ROCm/7.1/bin/clang.exe",
"CMAKE_CXX_COMPILER": "C:/Program Files/AMD/ROCm/7.1/bin/clang++.exe",
"CMAKE_PREFIX_PATH": "C:/Program Files/AMD/ROCm/7.1",
"CMAKE_C_FLAGS": "-mavx512f -mavx512bw -mavx512dq -mavx512vl -mavx512vbmi -mavx512vnni",
"CMAKE_CXX_FLAGS": "-mavx512f -mavx512bw -mavx512dq -mavx512vl -mavx512vbmi -mavx512vnni -Wno-nested-anon-types -Wno-gnu-anonymous-struct -D__HIP_DISABLE_CPP_MATH_OVERLOADS__ -D__HIP_DISABLE_GPU_MATH__ -D__CLANG_CUDA_MATH_FORWARD_DECLARES_H -D_CRT_USE_BUILTIN_ISIF=0 -DCACHE_LINE_SIZE=64 "
}
},
(ROCm バックエンド設定）
{
"name": "rocm",
"hidden": true,
"environment": { "MY_BACKEND": "rocm7.1-clang" },
"cacheVariables": {
// ここはバックエンド特有のスイッチのみ！
"GGML_HIP": "ON",
"GPU_TARGETS": "gfx1151",
"AMDGPU_TARGETS": "gfx1151"
}
},
(ビルドターゲット設定）
{
"name": "x64-windows-rocm-release",
"inherits": [ "base", "clang-win", "rocm", "release" ]
}
5. 遭遇した問題と解決
-
ロード失敗(
invalid vector subscript):--ctx-size 262144でMTP有効時、ドラフトモデル読み込み直前にROCm0の空き容量が「0 MiB」と報告されロード失敗。--ctx-size 196608に落として解決。WindowsのHIPが動的な専用GPUメモリの空き容量を正確に報告できていない可能性が高いが、根本原因は未解明。「表示された空き容量は当てにせず、実際に起動して確認する」以外に確実な回避策はなし。 -
CPU実行時の電力競合:
--spec-draft-ngl 0(ドラフトをCPU実行)でロード自体は成功したが、HWiNFOで確認したところAPU STAPM電力上限(120W前後)に張り付き、GPU実効クロックが低下(最小1,422MHz程度)。ドラフトをフルGPUオフロードすることで解消(GPU実効クロックの最大値・現在値ともに改善)。 -
OCL_SET_SVM_SIZE環境変数: 「RDNA3.5のユニファイドメモリ空間限界突破」という触れ込みでLemonadeから拝借していたが、設定値(262144)が--ctx-sizeのコピーにしか見えず、外して比較した結果ロード・挙動とも変化なし。実質無意味な設定だったことを確認・削除。
6. 最終 llama.cpp 起動パラメータ(MTP on)
$env:HIP_VISIBLE_DEVICES="0"
# ROCm 7.13 (TheRock) のDLL群が置かれているパスを環境変数の最優先に追加する
$TheRockPath = "C:\Users\(username)\.cache\lemonade\bin\therock\gfx1151-7.13.0\bin"
$env:PATH = "$TheRockPath;" + $env:PATH
cd D:\llm\llama-cpp-builds\llama-qwen4exp-mtp-2857e51-bin-win-rocm7.1-clang-x64\bin
# 時刻を付与して出力する
# 本来の ctx サイズは --ctx-size 262144 `
.\llama-server.exe `
-m "D:\llm\models\Qwen3.8-Flash-Next\Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf" `
-md "D:\llm\models\Qwen3.8-Flash-Next\mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf" `
--spec-type draft-mtp `
--spec-draft-n-max 3 `
-dev ROCm0 `
--host 0.0.0.0 `
--port 27681 `
--ctx-size 196608 `
--timeout 3600 `
--cache-ram 10240 `
--cache-reuse 256 `
--parallel 1 `
--cache-idle-slots `
--kv-unified `
--fit off `
--n-gpu-layers 999 `
--threads 20 `
--poll-batch 1 `
--poll 50 `
--cache-type-k q8_0 `
--cache-type-v q8_0 `
--prio 2 `
--ubatch-size 2048 `
--batch-size 8192 `
--flash-attn on `
--load-mode dio `
--adaptive-target 0.1 `
--temp 0.6 `
--top-k 20 `
--top-p 0.95 `
--min-p 0.0 `
--presence-penalty 1.5 `
--repeat-penalty 1.0 `
-lv 4 `
--slot-save-path "D:\llm\models\slot-save" `
--no-webui `
--reasoning-budget 4096 `
--reasoning-format deepseek 2>&1 | ForEach-Object { "[$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')] $_" }
(ドラフトはフルGPUオフロード、--spec-draft-ngl指定なし)
-
n-maxは5→3に削減(位置4・5の採用率が低く、CPU負荷/電力の見返りが薄いため)。 -
#28123(recurrent state rollback)は未適用のため、投機的デコード時は非効率なcheckpoint方式で動作(n_rs_seq=3、RSバッファがMTP無効時の約4倍)。それでも実測でtg向上を確認。
7. ベンチマーク結果(llmbench、独自swe-bench的タスク76問×5試行、--with-l6 --with-l7)
| 指標 | MTP off(同一ビルド) | MTP on | 参考: 別ビルド(master相当, MTPなし) |
|---|---|---|---|
| Resolved率 | (実行中断、要再取得) | 94.7% (72/76) | 94.7% (72/76) |
| pass@1平均 | (同上) | 94.5% | 93.2% |
| ≥1成功 | (同上) | 98.7% | 98.7% |
| 品質平均 | (同上) | 82.9 | 82.8 |
| Combined平均 | (同上) | 86.3 | 85.2 |
| tok/s(タスク別目安) | 13〜15(進行中の実測もこの水準) | 20〜29 | 14〜15 |
MTP off側は76問完走前に中断(task 43-44/76付近まで進行)。ここまで確認できた個別タスク(t001, t021など)ではon/off/参考ビルドの3条件でquality・combinedが完全一致。
失敗タスク(🔴不可)の再現性:
- t046・t103・t105: 3ビルドすべてで一貫して失敗(t105は5/5とも常に失敗)→ MTP無関係の、モデル自体の限界と判断。
- t095/t102: ビルド間で成否が入れ替わる(いずれもボーダーライン40〜60%台)→ temp=0.6のサンプリングブレの範囲と判断。
8. 暫定結論
- 正答率系の指標は、比較した範囲でMTP有無・ビルド間でほぼ一致。ROCm固有の既知の数値ズレ(
test-recurrent-state-rollbackのlogits mismatch)が実タスクの成否に悪影響を与えている様子は見られない。 - 速度はMTP onで明確に向上(tok/s目安で on 20〜29 vs off/参考ビルド 14〜15)。
- 個人利用(宅内コーディングエージェント用LLM)としては、MTP onを採用し、別AIモデルによるコードレビューを安全網とする運用であれば実用上問題ない、との判断に至った(ユーザー自身の暫定結論)。
9. 未解決・要ウォッチ事項(TODO)
- MTP off側の76問完走と最終比較— 中断分の再開が必要。
-
PR #28243の動向 — 2026-09-05時点でDraftのまま変化なし。ggerganovのレビュー指摘が未反映(
model_sharedを既存のctx_otherロジックに置き換えるべき/CUDAグラフキー修正は別PRへ切り出すべき)。正式マージ時は今のブランチと形が変わる可能性あり。 -
#28123(recurrent state rollback)の適用検証 — 未マージ・未適用。適用すればcheckpoint方式より投機的デコードが効率化する可能性があるが未検証。 -
ggml-cuda.cuの今後の動き — HIPビルドでも同一ソースを共用するため、CUDA/ROCmに関わらず本流の更新頻度が高く、リベース時にコンフリクトの種になりやすい。継続ウォッチ対象。 -
GGML_HIP_ROCWMMA_FATTNの有効化 —C:\ROCm\7.14(公式AMD版、rocwmma同梱)を使えば解決する可能性があるが、過去のビルド失敗経験ありで保留中。 - Windows上のHIPメモリ空き容量報告の不整合 — 根本原因未解明。実測ベースでの確認以外に回避策なし。
-
本流masterのリバースマージ ドライラン — 未実施。
git merge upstream/masterでのコンフリクト状況を今後確認する。 -
diffの保存 —
https://github.com/ggml-org/llama.cpp/pull/28243.diff等での取得を推奨(未実施なら次回実施)。