Surface Pro 11 は5分フルロードでも61.6%まで落ちなかった

Surface Pro 11th Edition に301.0秒のフルロードをかけても、% Processor Performance は最初の5件平均60.2%、最後の5件平均61.6%に収まった。

ファンレスの Snapdragon X Elite X1E80100 なので、5分ほど全コアを使い切れば途中からクロックが落ちるだろうと思っていたが、実際に測ってみると最後のほうがわずかに高い。最大は69.5%、最小は55.5%で、48件のサンプル全体を眺めても時間が進むほど沈む線にはならず、むしろ「落ちるはず」という先入観のほうが外れてしまった（温度を直接読めていないので、熱に余裕があったと書くには材料が足りない）。

もうひとつ目についたのは、落ちなかったことより、全区間が60%前後にいる点だった。公称は3.40GHzだが、Processor Frequency の実値は990MHzから2397MHz、平均1512.9MHzに収まっている。全コア同時負荷では、熱で落ちる前に、定常の運転点がこのあたりへ置かれているように見える（短い単一スレッドのブーストとは別の話）。

計測日は2026年7月26日で、電源は AC 接続、電源プランは既定の「バランス」のままにした（普段の状態から大きく寄せていない）。Windows 11 Pro 10.0.26200 の ARM64 環境で、Python 3.12.10 も ARM64 ネイティブで動かしている。

負荷と監視をどう走らせたか

負荷は Python の ProcessPoolExecutor で作った。12プロセスを立て、各プロセスで整数演算のループを回すだけの単純なもの。GPU やディスクは狙わず、CPU だけを雑に熱くする（この雑さは弱点でもあるけれど、普段の小さな変換処理には近い）。

from concurrent.futures import ProcessPoolExecutor
import time

def burn(until):
    x = 0
    while time.perf_counter() < until:
        x = (x * 1664525 + 1013904223) & 0xffffffff
    return x

until = time.perf_counter() + 300
with ProcessPoolExecutor(max_workers=12) as pool:
    list(pool.map(burn, [until] * 12))

監視は別の PowerShell プロセスで並走させた。5秒おきに \Processor Information(_Total)\% Processor Performance、\Processor Information(_Total)\Processor Frequency、\Processor(_Total)\% Processor Time を読む形にしている。

while ((Get-Date) -lt $end) {
    $perf = (Get-Counter '\Processor Information(_Total)\% Processor Performance').CounterSamples.CookedValue
    $freq = (Get-Counter '\Processor Information(_Total)\Processor Frequency').CounterSamples.CookedValue
    $busy = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue
    [pscustomobject]@{
        t = Get-Date -Format 'HH:mm:ss'
        perf = [math]::Round($perf, 1)
        freq = [math]::Round($freq, 0)
        busy = [math]::Round($busy, 1)
    }
    Start-Sleep -Seconds 5
}

この構成には弱点があり、監視側の PowerShell も CPU を使うし、Get-Counter を3回呼ぶので、まったく無負荷な観測者にはならない（観測している側も少し場を荒らす）。厳密なベンチマークとしては雑だが、普段の自動化を走らせながら状態を見る、という私の使い方にはかなり近い。

実際の負荷時間は301.0秒だった。目標の300秒から1.0秒長い。ProcessPoolExecutor の終了待ちや監視側のタイミングが混ざるので、この程度のずれは出る。

途中で拾えたカウンター

全48件を載せると表が長くなりすぎるので、最初の5件、中間の5件、最後の5件をそのまま置く。単位は % Processor Performance と % Processor Time が%、Processor Frequency がMHz。

位置	時刻	% Processor Performance	Processor Frequency	% Processor Time
最初	20:38:11	55.5%	1030MHz	33.5%
最初	20:38:18	58.9%	1230MHz	58.4%
最初	20:38:25	63.4%	2066MHz	100.0%
最初	20:38:31	60.2%	1230MHz	44.9%
最初	20:38:37	62.9%	2270MHz	73.7%
中間	20:40:22	60.6%	990MHz	44.0%
中間	20:40:28	61.7%	1270MHz	64.8%
中間	20:40:34	61.9%	1590MHz	78.8%
中間	20:40:41	61.4%	1030MHz	63.9%
中間	20:40:47	59.4%	1806MHz	58.3%
最後	20:42:38	61.6%	1455MHz	77.0%
最後	20:42:44	69.5%	2142MHz	100.0%
最後	20:42:50	61.2%	1660MHz	100.0%
最後	20:42:56	58.9%	1393MHz	66.6%
最後	20:43:03	56.8%	1260MHz	41.9%

% Processor Time は最大100.0%で、100.0%のサンプルが4件ある。90%以上も9件あった。全サンプル平均は71.3%なので、表だけ見ると張り付きっぱなしには見えないが、負荷プロセス自体は12本を走らせ続けている。Windows のカウンターを別プロセスから読むと、サンプリングの窓や監視処理のタイミングでこういう見え方になるのだと思う。

なぜ busy が常に100%近くに並ばないのだろうか、という点で少しハマり、最初は busy が常に100%近くに並ぶはずだと思い込んでいた。実測では33.5%から100.0%まで振れている。負荷が抜けていたというより、監視の取り方が粗い。CPU を燃やす処理と観測処理を同じ Windows 上で動かしているので、きれいな線を期待しすぎたのが勘違いだった。

クロックは落ちたのか

見たかったのは、時間経過で % Processor Performance が下がるかどうかだ。最初の5件平均は60.2%、最後の5件平均は61.6%。差は1.4ポイントで、低下ではない。全体平均も61.7%だった。

最大69.5%は最後のほう、20:42:44 に出ている。もし熱で苦しくなって終盤に強く絞るなら、最後の5件にこの値は出にくい。もちろん、5秒間隔の48件だけなので、短い谷を取り逃がした可能性は残る。それでも、少なくともこの観測では、5分の連続負荷で右肩下がりに落ちる挙動は見えなかった。

一方で、3.40GHz の公称値に対して、Processor Frequency は最高でも2397MHzだった。最低は990MHz。平均1512.9MHzという数字だけを見ると、かなり低く感じる。だが、% Processor Performance が60%前後で安定していることと合わせると、これはサーマルスロットリングというより、12コア同時に回したときの持続クロックがもともと控えめに決まっている、という読みになる。

短時間の単一スレッドなら別の絵になるはず。今回の話は、12プロセスを同時に走らせたときに限る、という但し書きつきの記録。

測れなかったもの

失敗した点もある。CPU 温度を取りたかったが、手元の PowerShell からは取れなかった。

Get-StorageReliabilityCounter で SSD の温度は見に行ける。けれど、Surface Pro 11th Edition の CPU 温度センサーには同じ方法で届かなかった。Windows の標準カウンターだけで済ませるつもりだったので、ここで詰まった。

そのため、「熱的に余裕があった」と書くには材料が足りず、クロックの観点では5分間で落ちる様子は見えなかった、というところまでにする。筐体内部の温度が上がっていたのか、余裕を残していたのか、あるいは別の制御で先に抑えていたのかは、このログだけでは分からずに残った。

もうひとつの限界は時間だ。今回は300秒を狙い、実測では301.0秒だった。10分、20分に延ばせば違う結果になるかもしれない。ファンレス機で本当に見たいのは、短いバーストより、長めの定常負荷だ。今回はその入口を5分だけ試したにすぎず、次はもう少し長く試してみるつもりだ。

使い方の見方は少し変わった

個人的には、ファンレスだから長く走らせる処理はすぐ苦しくなる、という先入観があった。今回の5分では、その見方は外れる。Surface Pro 11th Edition は静かなまま、少なくとも % Processor Performance の範囲では60%前後を保っている。

この先は未確認。

楽観しすぎるのも違う。3.40GHz という数字を見て、12コア全部がその近くで回ると期待すると間違える。私の環境では、全コア負荷時の実測周波数は990MHzから2397MHzの間に散っていた。最大性能を出し続ける機械というより、ファンレスの範囲で持続できるところに最初から置いている機械、という印象に近い。

この結果を見て、自分の運用では短いバッチ処理を避ける理由は減った。Python で数分の変換や集計を走らせる程度なら、途中で急にしぼむ心配は小さそうだ。一方で、動画エンコードのように20分以上続く処理は、まだ別に測る必要がある。

2026-07-26 の結論としては、ファンレスだから性能が持続しない、という単純な見方は少なくとも5分では否定された。とはいえ、温度未計測で、時間も短い。次はCPU温度に触れる方法を探し、10分以上で同じ表を取り直したい。