EVO-X2 x Qwen3.8-Flash-Next 番外編6 EVO-X2のP-MODEボタンの罠 同じexeでも速度が大きく変わる

ローカルLLMをいじるのに速度計測は欠かせない。特にllama.cppの改造などをして遊んでいると、修正して速くなったかを確認するのは必須。そして、速度を比較するには前提条件がそろっていることが必要（当たり前）。なのだけど、その前提が揺らぐ事件があった、という話。

結論

• EXO-X2で謎の速度低下があって、調べたらP-MODEが原因の可能性が高かった
• EVO-X2のP-MODEボタンでPerformance / Balanced / Quietを切り替えると、今回の64kテストではPP速度が最大 約16.5% 変わった
• Windowsのヘッドレス運用で「今どのP-MODEなのか」を自動取得するのが意外と面倒だったので、GPU計測とP-MODE確認をベンチマークに組み込んだ
• その後P-MODEはPerformanceのまま、GPUコアクロックもほぼ維持されているのに、VRAMクロックとPP速度だけが低いという別の事件が発生
• この低速状態は、ACケーブルを抜いて電源ボタンを約30秒長押しして、約10分放置しても改善しなかった
• 物理ディスプレイ接続＋ローカルログイン＋P-MODEボタン3回押下の後に回復。その後、ディスプレイを外したヘッドレス起動でも回復状態を維持できた。ただし何が効いたのかは未解明

検証環境

項目	内容
PC	GMKtec NucBox EVO-X2
APU	AMD Ryzen AI MAX+ 395 / Radeon 8060S
RAM	128GB UMA（UMA Frame Bufferは96GBに設定）
OS	Windows 11 Pro 26H2（Build: 26300.9550）
GPUバックエンド	llama.cpp Vulkan
最初のP-MODE検証	Qwen3.8-Flash-Next / Unsloth UD-IQ3_XXS PLE16、llama.cpp b11560
後半の復旧検証	Qwen3.8-Flash-Next / Agention ROCmFP4-FAST v2 PLE16＋対応MTP draft、llama.cpp b11588
運用	通常はRDPで接続。必要に応じて物理ディスプレイを接続

ソース、Windowsビルド、検証スクリプトなどはGitHubリポジトリで公開している。
今回の計測機能の開発は主にinvestigation/r5-adlx-gpu-monitor-20261015ブランチで行った。

※以下、Prompt Processing（入力の処理）をPP、Token Generation（出力トークン生成）をTGと書く。速度はいずれもtok/sで、大きいほど速い。

謎の速度低下発生

チャッピー様と相談しながら、チマチマとllama.cppのMTPの高速化をしていた時のこと。1項目の高速化の実装とビルドを終え、速度を測ってみたら、なぜか遅くなっている。

何か壊した！？
と思って、作業前にビルドしたexeを探して測り直したけど、そっちでもやっぱり遅い。

コンテキスト128k、MTP OFF、同じllama-cli.exeを使った結果は次のとおり。

計測日	PP速度	備考
2026/10/11	335.455 tok/s	前はもっと速かったはず、ということでログから探した値
2026/10/14	305.18 tok/s	謎の速度低下発生後に測った値

また、64kのMTP OFFでは、謎の速度低下発生後に約339 tok/sだった。この数字が後で妙に気になることになる。

ログを発掘してモデル、入力、起動オプション、環境変数、ドライバー、保存済みexeなどを見直したけど、速度差を説明できる変更は見つからない。しかも2つの計測の間に3日ぐらい空いていたので、ここから原因追究の沼にハマった。

疑ったもの	試したこと・分かったこと
Windows再起動	再起動後も128k PPは306.75 tok/s。335には戻らない
Visual Studio Native Tools shell	通常PowerShell 305.90、開発用shell 305.18 tok/s。主因ではなさそう
RDP接続・切断	RDP(Remode Desktop)接続しっぱなし、計測開始後に切断で大差なし
Windows Update	期間中に更新はあったが、速度低下との因果関係は不明
物理ディスプレイ	接続しただけでは当初の速度が戻らなかった
GPUの温度やクロック	当時ログを取っていなかったので、後から確認できない

遅くなっているときのログを調べてみると、入力32kあたりからPP速度の差が大きくなっていた。これは第8回で入れたVulkan QSA unionの適用位置と重なる。
QSAのkernelが悪いのか？　と疑ったのだけど、境目が一致しているだけで犯人確定ではない。長い処理ほど電力制御やクロック状態の差が現れた可能性もある。
GPUの動作状態を当時記録していなかったので詳細は分からない。計測していないものは、後から復元できない。

P-MODEボタンが原因だった可能性

原因を探して半日ぐらい溶かした後、ふと思い出した。2つの計測の間にEVO-X2を移動したり、ディスプレイやUSBメモリを抜き差ししたりしていた。
もしかして、P-MODEボタンを押した？

EVO-X2本体の物理ボタンで、Performance / Balanced / Quietを切り替えられる。けれど、普段はRDPなので本体の画面を見ていないし、そのときの設定を記録する仕組みもない。

仕方ないので物理ディスプレイをつないで、画面を見ながらボタンをポチポチ押してPerformanceに戻してから計測したら、高速時に近い値に戻った！

後で考えれば、押すときに注意して何回押したか数えていれば元々何のモードだったか分かったかもしれないのだけど、何も考えずにポチポチ押したので、最初に遅いと思ったときのモードが何だったかは分からない。

ついでなので、物理ディスプレイを接続した状態で、P-MODEボタンの各モードで、64k llama-bench（PP 61,777トークン、MTP OFF）**を測り、作り始めていたADLX monitorのGPUデータも記録してみた。

P-MODE	PP速度	Performance #1比	高負荷中GPUコアクロック	高負荷中GPU電力
Performance #1	357.264 tok/s	基準	2,878.9 MHz	114.0 W
Quiet	298.213 tok/s	-16.53%	2,151.4 MHz	53.5 W
Balanced	339.165 tok/s	-5.07%	2,621.7 MHz	84.8 W
Performance #2	356.978 tok/s	-0.08%	2,872.2 MHz	115.3 W

先ほどの64k低速記録の約339 tok/sと、Balancedの339.165 tok/sが妙に近い。

「謎の速度低下」の犯人は、ボタン誤操作でBalancedになっていたことかも？

でも、遅かった時のP-MODEの値が分からないので、近い数値になったことは状況証拠であって、過去のモードがBalancedだったと確実に言えるわけではない。

この時は、基本的にPerformanceモードしか使わないから、誤操作しないようにカバーを作って接着剤でくっつけておこうかと思ったのだけど、後でもう１つ事件が起こって、ここで早まらなくて良かったと思うことになる。

ADLX monitorを作る

P-MODE事件とは別に、以前から推論が異常終了したときの状況を調べるため、メモリ使用量だけでなくGPUクロックや温度も記録したいと思っていた。今回のような謎の速度低下にも必要そうなので、この機会に実装することにした。

まずAMD Software: Adrenalin EditionでGPU関連の値が見られることを確認し、AMDのADLX SDKを使ってWindows向けの小さな計測プログラムを作成した。

取得する情報	何を見るため？
GPU使用率	GPUが高負荷で動いているか
GPUコアクロック	計算側のクロックが落ちていないか
GPUメモリ（VRAM）クロック	メモリ側のクロックが変わっていないか
GPU温度	温度による制御を疑う材料になるか
GPU消費電力	P-MODEや電力状態と整合するか
GPUメモリ使用量	大きなモデルやKVキャッシュの負荷を確認するため
RDPセッション情報	リモート接続時かどうか

約2秒間隔で記録して、計測ごとにgpu-metrics.csvへ保存する。既存のMeasure-LlamaCli.ps1とMeasure-LlamaBench.ps1から自動起動し、計測対象のプロセスが終了したらモニターも止める仕組みにした。データ取得に失敗しても、推論やベンチマーク自体は止めない。

なお、一部の温度や電力指標（hotspotやtotal board powerなど）は、この環境ではADLXから取得できなかった。取れない値を適当に0として扱うと後でハマるので、未取得として残すようにした。

速度を測るためのモニターを作って、そのモニターのせいで速度が落ちたら意味がない。

そこで、64kのllama-benchでADLX計測のON/OFFを**ABBA順（ON→OFF→OFF→ON）**で比べてみた。

ADLX計測	PP平均
ON	357.252 tok/s
OFF	356.120 tok/s
差	+0.318%

ONの方がわずかに速いけど誤差変動範囲。このテストでは目立った計測負荷は見えなかったので、通常のベンチマークではADLX計測をONにすることにした。

P-MODEボタンの現在値も記録したい

GPUの消費電力などからモードを推測することはできけど、できればP-MODEの実際の設定値を直接読みたい。
LinuxだとP-MODEの変更も読み取りも比較的簡単にできるらしいのだけど、Windowsだとこれが意外と大変だった。

まずpowercfgを調べてみたが、P-MODEをPerformance・Balanced・Quietに切り替えても、Windowsの電源プランはずっと「高パフォーマンス」のまま。Windowsの電源プランとEVO-X2のP-MODEは別物だった。

いろいろ調べたところ、EVO-X2ではACPI/WMIという、Windowsと本体側の制御機構がやり取りする仕組みから、現在のP-MODEを読むことができた。

読み取れる値	P-MODE
0	Balanced
1	Performance
2	Quiet

具体的には、ACPI\PNP0C14\IP3POWERSWITCH_0に対応するWMIのmethod 2を呼び出して読む。ボタンが押された瞬間を通知する仕組み（IP3_WMIEvent）も見つかったけど、こちらは過去の状態を覚えているわけではない。今回欲しいのは、計測開始時に今どのモードかなのでmethod 2を使うことにした。

ただし、通常のユーザー権限のPowerShellから呼ぶとアクセス拒否。管理者権限が必要だった。

ベンチマーク全体を管理者権限で動かすのは避けたいので、P-MODEを読むだけの処理をタスクスケジューラ経由で管理者権限実行し、結果をファイルに保存して、ユーザー権限のPowerShellから読むようにした。(これはP-MODEを変更する処理ではない。)

計測環境を整えて最初のMTP関連最適化を測り直すと、同じビルドで、64kのPPが333.495→345.460 tok/s（+3.59%）、128kでは**300.93→321.13 tok/s（+6.71%）**で、ちゃんと速くなっていた。何か壊したから遅くなっていたわけではなかった。高速化の中身は次回の記事で。

謎の速度低下ふたたび

GPUもP-MODEも記録できるようになって、ようやく安心して速度測定ができる。そう思っていた約1週間後、もっと面倒な事件が起こった。

最初のきっかけは、速度計測中に謎のWindows再起動が起こったこと。
イベントログにはKernel-Power 41などが残っていたが、これは正常にシャットダウンされなかったことを示すもので、それだけで原因は分からない。直前にはWindows Updateも実行されていなかった。
速度計測のログで直前に記録できたGPU温度は約84℃、GPUコアクロックは2,869 MHz、電力は114 W、使用率は99%。計測中の温度ピークは約89℃だった。負荷は大きいが、ログから熱暴走やメモリ不足を原因と断定できる証拠は見つからなかった。
過負荷だったのか、ドライバーだったのか、ハードウェア側なのかは今も不明。

謎の再起動も困るけど、さらに困ったことに、それ以後の速度が妙に遅い。

今度はP-MODEもGPUの動作状態も記録できている。P-MODEの読取値は、開始時も終了時もPerformance。本体には触っていないので、前回のようなボタン誤操作でもない。
GPUコアクロックはほぼそのままなのに、VRAMクロックの平均だけが低く、PP速度も落ちている。

32kで同じ条件の検証を繰り返したところ、こうなった。

時刻	実施した操作・状態	PP tok/s	TG tok/s	PP中VRAMクロック平均
16:50頃	異常再起動前、RDP・ヘッドレス	398.65	36.60	約970 MHz
20:32頃	異常再起動後、RDP	376.88	35.95	約884 MHz
20:53頃	通常のWindows再起動後	380.02	35.93	約895 MHz
21:06頃	通常のシャットダウン→電源ON後	376.23	36.14	約876 MHz
21:48頃	AC抜き＋電源長押し＋物理画面接続、ローカル計測	393.12	36.47	約937 MHz
21:57頃	物理ディスプレイ接続中、RDP	397.31	36.52	約957 MHz
22:50頃	別のハングから手動再起動後、画面なし・RDP	376.15	36.32	約875 MHz
23:23頃	AC抜き＋約30秒長押し＋約10分放置後、画面なし	377.11	36.07	約877 MHz
23:34頃	物理画面接続＋ローカルログイン＋P-MODE 3回押下後	393.98	36.50	約942 MHz
23:45頃	物理画面を外して再起動、RDP	394.96	36.66	約944 MHz

この表の32k計測は、Vulkan b11588（同一exe）／約29,557入力トークン／出力512トークン／ROCmFP4-FAST v2モデル＋対応MTP draft／温度0でそろえている。生成結果とMTPの採択率（299/423、70.686%）も一致。ログに記録されているP-MODEはどれもPerformanceだった。

謎の再起動は17:46頃。
その後速度が低下して、Windowsを再起動しても、シャットダウン→電源ONしても戻らない。

「再起動の原因が過負荷で、その後何らかの電力制御・保護状態に入ったのでは？」と疑って、21:48頃、

• 電源ケーブルを抜いて、電源ボタンを30秒長押しして、10分放置
• 電源ケーブルと物理ディスプレイを接続して起動
• 画面を見ながらP-MODEボタンを押してPerformanceモードにする
• 物理ディスプレイを接続したまま、他のクライアントからRDPで接続して速度計測

で高速状態に戻ったけど、複数の操作をしたので、何が効いたかは分からない。

高速に戻ったので、調子に乗って色々計測していたら、今度はRDPが切れて応答しなくなって、物理ディスプレイをつないでも何も表示されなくなった。ファンは動いているので本体の処理は続いているのかもしれないけど、外から全く操作できないので電源ボタンを長押しして電源を落として、再度電源ボタンを押して起動したら、また遅くなってる！

1日に2回も異常終了するのは初めてで、それも心配なのだけど、色々ブン回しすぎて負荷をかけた自覚はある。
それよりも、再起動後に低速化するのが困る。

さっき復旧した操作の中で、効いてそうなものから順番に試してみることにした。

まずはWindowsをシャットダウンし、電源コードを抜いて電源ボタンを約30秒長押し。そのまま約10分放置してから、物理ディスプレイなしで起動して再計測したら、速度は遅いまま。VRAMクロックも低下したまま。
さっき効いたのはこれだと思ったのだけど、違った。

次は、物理ディスプレイを接続してみることにした。一度シャットダウンしてディスプレイを接続して、電源オン→画面を見ながらローカルログイン→P-MODEボタンを3回押したらPerformanceモードになった。3回ということは、元の状態もPerformanceモードだったはず。
物理ディスプレイを接続したまま、他のマシンからRDP経由で速度計測してみると、PPもVRAMクロックも高速状態に戻っていた！

確認のため、物理ディスプレイを外してシャットダウン→再起動し、RDPでもう一度計測したところ、PPは394.96 tok/s、VRAMクロック平均は944 MHz。高速状態を維持できていた！
つまり、物理ディスプレイが常時接続されていないと遅くなるわけではない。

では、何が効いたのか？

• 物理ディスプレイをつないで起動したこと？
• ローカルログインを行ったこと？
• P-MODEを3回切り替えたことで、EVO-X2内部の電力設定が再適用されたこと？
• それらの組み合わせ？

１個ずつ順番に試して切り分けるつもりだったのだけど、早く高速状態に戻したくて、結局複数の操作を一緒に行っていた。

また、VRAMクロック低下がPP低下の直接の原因かどうかも断定できない。電力制御の変化によって、VRAMクロックとPPの両方が下がった可能性もある。今回確認できたのは、P-MODEはPerformanceでGPUコアクロックもほぼ同じなのに、PP中のVRAMクロックと実測速度が一緒に変わったということだけ。

ということで、異常再起動したら何らかの保護機能が働いてVRAMクロックが低速化して、物理ディスプレイ接続か、ローカルログインか、P-MODEボタン押下か、どれかを契機にリセットされたのではないか？と推測するけど、ただの推測で、ちゃんと確認したわけではない。

次に異常再起動が起きたら何が効くのかは確かめてみたいけど、無理に過負荷状態を作りたくはないし、異常再起動はあまり起こって欲しくはない。(幸い、その後3日以上異常再起動は起こっていない)

ともあれ、P-MODEボタンがリセットに必要かもしれないので、接着剤で無効化しなくて良かった。

まとめ

P-MODEボタン絡みで、何だかんだで2日ぐらい溶かしている。

今回整備した計測環境で、速度とメモリ使用量などのリソースのほかに、次の記録も取れるようになった

• P-MODE実際の設定値を開始・終了時に記録する
• GPUコアクロックだけでなく、VRAMクロック・電力・温度も取る
• RDP／物理ディスプレイ接続の状態も記録しておく

注意点として、「Performanceと表示されている＝必ず同じ性能」ではない
特にWindowsの異常終了や異常再起動の後は要注意

Linuxだったらこんな変なハマり方はしなかったはず。そろそろ脱Windowsしようかとも思うけど、せっかく計測環境を整えたし、EVO-X2を写真や動画の整理にも使いたいので、しばらくはWindowsのままにする予定。

次回はP-MODE事件の前後に調査していた、MTPを入れるとPPが遅くなる件について書く予定だけど、また事件が起こったら脱線するかもしれない。

付録

詳細な検証環境

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: 128GB
• UMA Frame Buffer: 96GB
• Windows CPU側に見えるRAM: 約32GB
• GPU: AMD Radeon 8060S Graphics
• GPU arch: gfx1151

OS

• OS: Windows 11 Pro
• Version: 26H2
• OS Build: 26300.9550