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 等での取得を推奨(未実施なら次回実施)。