DGX Spark GPUクロック実測｜2000MHzで報告電力40%減

先に結論

今回のQwen3.8-27B MTPでは、2000MHzが性能とGPU報告電力のバランスを取る候補でした。定格条件の平均に対して、decodeは0.75%、prefillは1.51%低下する一方、nvidia-smiが報告したGPU電力の平均は40.61%低下しました。

2000MHz: 性能低下を小さく保つ通常運用候補
1900MHz: prefillの低下を許容してGPU報告電力をさらに抑える候補
1800MHz: 省電力優先。実際のSLOで追加反復してから採用

ただし、これは1台のDGX Sparkと特定のQwen3.8-27B構成を、1セッションで測ったpilot結果です。2台のQwen3.8-Flash-Nextでは9回中3回がHTTP 500となり、production用の値は決めていません。

検証区分: KFBがDGX Spark実機で行った測定です。公開前監査日は2026年8月30日（Asia/Tokyo）。
電力値: 壁コンセントで測ったシステム総電力ではなく、0.5秒間隔のnvidia-smi telemetryが報告したGPU電力です。CPU、memory、storage、network、電源変換損失は含みません。
統計上の制約: 条件順を無作為化していない単一セッションのpilotです。数%の差を統計的に確定した性能差とは扱いません。

測定した構成と手順

測定対象は次の2構成です。

Qwen3.8-27B MTP: DGX Spark 1台
Qwen3.8-Flash-Next-NVFP4: DGX Spark 2台、Tensor Parallel 2

1台構成では、定格、2200、2100、2000、1900、1800MHzの6条件を比較しました。decodeは4並列のbatch（各request 256 token）を条件ごとに3回、合計12 request分測定。prefillは約14.4K tokenを2回、streamingのTTFTは1回測りました。TTFTは単発値のため結論や結果表には使っていません。定格条件は試験の最初と最後に取り、その平均を基準にしています。

2台構成では、2並列のbatch（各request 256 token）を3回、約14.4K tokenのprefillを2回測定しました。条件を変えるたびにserviceを停止し、headとworkerの両方へ同じ要求範囲を設定してからmodelを起動し直しています。

温度は実行順とheat soakの影響を分離できなかったため、今回の表から発熱低下を断定しません。クロック条件も無作為化していないため、定格の前後測定だけでは時間経過の影響を完全には除けません。

今回の公開用測定記録には、OS、driver、CUDA、SGLang image digest、model revision・quantization、sampling parameter、seed、固定prompt本文、個別run値、telemetryのquery項目と採取sample数が含まれていません。このため、結果は実機pilotとして扱い、厳密な再現packageとは位置付けません。次回はこれらを固定してraw値とともに保存します。

Qwen3.8-27B MTPの結果

`-lgc`指定上限	実測平均クロック	decode tok/s	定格比	prefill tok/s	定格比	GPU報告電力	定格比
定格平均	2442MHz	78.11	—	1736	—	41.48W	—
2200MHz	2174MHz	77.60	-0.65%	1753	+0.97%	29.24W	-29.50%
2100MHz	2079MHz	79.67	+2.00%*	1733	-0.19%	26.83W	-35.31%
2000MHz	1980MHz	77.53	-0.75%	1710	-1.51%	24.63W	-40.61%
1900MHz	1890MHz	77.42	-0.88%	1687	-2.84%	22.62W	-45.47%
1800MHz	1794MHz	78.10	-0.02%	1654	-4.75%	20.87W	-49.70%

* 2100MHzの+2.00%は、クロックを下げたことで速くなったとは解釈していません。decode 3回だけの試行ばらつきです。

表の平均値は表示桁へ丸めているため、掲載値だけから定格比を再計算すると、原稿集計の割合と0.01〜0.03ポイントずれる箇所があります。

decode throughputは1800MHzまでほぼ横ばいでした。このworkloadでは、GPU演算クロックよりmemory帯域や別の処理がボトルネックになっている可能性があります。一方、prefillは要求上限を下げるにつれて緩やかに低下しました。原因を確定するには、hardware counter、別のprompt長、batch、modelで追加測定が必要です。

2000MHzでは、定格平均41.48Wに対して24.63Wでした。差は16.85Wですが、これはGPU報告値の差です。DGX Spark全体の電気代や壁電力が同じ割合で減るとは限りません。

2000MHzを候補にした理由

今回の範囲では、2000MHzから1900MHzへ下げるとGPU報告電力はさらに約2.01W低下しましたが、prefillの低下幅は1.51%から2.84%へ広がりました。1800MHzではGPU報告電力が定格比49.70%低下した一方、prefillは4.75%低下しています。

そのため、性能低下を小さく保ちつつGPU報告電力を抑える出発点として2000MHzを選びました。常に2000MHzが最適という意味ではありません。長いprefillが多いservice、低遅延SLO、異なるquantizationやspeculative decodingでは、1900〜2200MHzを同じ条件で再測定する必要があります。

2台のQwen3.8-Flash-Nextは上限未確定

Qwen3.8-Flash-Next-NVFP4を2台・TP=2で測った成功runだけを並べると、次の結果になりました。

`-lgc`指定上限	head / worker実測平均	decode tok/s	2200MHz成功run比	2台のGPU報告電力平均の合計	2200MHz成功run比
2200MHz	2175 / 2176MHz	68.51	—	49.17W	—
2100MHz	2080 / 2086MHz	64.04	-6.53%	44.26W	-9.99%
2000MHz	1980 / 1977MHz	63.04	-7.99%	41.83W	-14.93%
1900MHz	1888 / 1886MHz	64.73	-5.53%	37.07W	-24.61%
1800MHz	1792 / 1787MHz	64.47	-5.91%	36.47W	-25.83%

各行は条件単位で完走した1セッションの集計値で、同じ条件を複数セッション反復した平均ではありません。提供された記録だけでは各条件の試行数Nを完全には復元できないため、成功run間の分散も評価できません。

この表だけで1800MHzを選ぶことはできません。2並列の正式workloadは9回中6回完走し、3回はHTTP 500でした。2000MHzは最初のrunが失敗し、同じ条件の再試験は成功。定格の再確認は2回とも失敗しています。失敗率はクロックに対して単調ではなく、HTTP 500の原因をGPUクロックへ帰属できません。

さらに、model稼働中に定格から2200MHzへ変更した試行では両rankが終了しました。この1件だけで因果を確定できませんが、稼働中の変更を避ける十分な運用上の理由になります。Qwen3.8-Flash-Nextのproduction用設定は保留し、再試験する場合は2200MHzから反復数を増やします。

安全側に倒した設定手順

NVIDIAのnvidia-smi資料では、--lock-gpu-clocksは最小・最大の要求クロック範囲を指定し、root権限が必要と説明されています。専用の「上限だけを設定する」optionではないため、本文の「要求上限」は今回使った300,MAXの最大側を指します。

単一nodeのQwen3.8-27Bを2000MHzで起動する例です。先にnvidia-smi -Lで対象GPUのindexを確認し、実機に合わせて-iを変更します。

set -euo pipefail

PROFILE=qwen27
CLOCK_MAX=2000

# 1. 対象GPU indexとserviceの停止状態を確認
nvidia-smi -L
~/bin/dgx-model stop
~/bin/dgx-model status

# 2. 300MHz〜指定値の要求範囲を設定
sudo nvidia-smi -i 0 -lgc "300,${CLOCK_MAX}"

# 3. 設定commandが成功した場合だけ起動
~/bin/dgx-model start "${PROFILE}"

2台構成では、両nodeへ同じ要求範囲を設定してから起動します。Qwen3.8-Flash-Nextのproduction値は未確定なので、次は保守的な2200MHzから再試験する例です。WORKER_SSHは自分のSSH接続先へ置き換えます。

set -euo pipefail

PROFILE=qwen-flash
CLOCK_MAX=2200
WORKER_SSH='user@worker-host'

~/bin/dgx-model stop
~/bin/dgx-model status
sudo nvidia-smi -i 0 -lgc "300,${CLOCK_MAX}"
ssh -t "${WORKER_SSH}" "sudo nvidia-smi -i 0 -lgc 300,${CLOCK_MAX}"
~/bin/dgx-model start "${PROFILE}"

解除時もserviceを先に停止します。単一nodeでは次の2行です。

set -euo pipefail

~/bin/dgx-model stop
sudo nvidia-smi -i 0 -rgc

2台構成は両nodeで解除します。

set -euo pipefail

WORKER_SSH='user@worker-host'

~/bin/dgx-model stop
sudo nvidia-smi -i 0 -rgc
ssh -t "${WORKER_SSH}" 'sudo nvidia-smi -i 0 -rgc'

今回、300MHzは両実機で受理された数値下限です。idle時のcurrent clockはhardware制御によって208MHzまで下がったため、300MHzへ常時固定されたという意味ではありません。nvidia-smi -plによるpower limitは今回のGB10環境ではN/Aでした。

この結果を再現するときの記録項目

別環境で比較するときは、少なくとも次を固定・保存します。

model ID、quantization、revision、container imageまたはruntime commit
DGX Sparkの台数、driver、CUDA、SGLang、parallelism、speculative decoding設定
prompt token数、生成token数、concurrency、warm-up、反復数
クロック変更前後のservice停止、全nodeへの設定成功、起動確認
decode、prefill、TTFT、error数、実測clock、GPU報告電力の採取区間
壁電力を比較する場合は同じpower meter、idle差し引き方法、測定時間

NVIDIAのTensorRT性能測定資料も、floating clockやthrottlingが短時間測定のばらつきにつながり得る一方、どの固定値が最適かはworkload次第と説明しています。今回の2000MHzも、別modelへそのまま一般化せず、再現対象ごとに確認する値です。

まとめ

Qwen3.8-27B MTPを1台のDGX Sparkで測った今回のpilotでは、2000MHzでdecode -0.75%、prefill -1.51%に対し、GPU報告電力は-40.61%でした。1900MHzでは-45.47%、1800MHzでは-49.70%まで下がりましたが、prefillの低下と測定のばらつきを考えると、2000MHzから始めるのが現実的です。

一方、2台のQwen3.8-Flash-NextはHTTP 500が9回中3回発生し、成功runの表だけではproduction設定を選べません。失敗原因を分離し、2200MHzから反復する必要があります。

運用手順は stop → 全nodeへ同じ要求範囲を設定 → start に固定します。稼働中の変更を避け、解除時もservice停止後に-rgcを実行するのが今回の実機検証から得た最も重要な注意点です。

参考資料

NVIDIA System Management Interface：--lock-gpu-clocks / --reset-gpu-clocks（2026年8月30日確認）
NVIDIA TensorRT：Hardware and Software Environment for Performance Measurements（2026年8月30日確認）
Qwen：Qwen3.8-27B公式model card（2026年8月30日確認）
Qwen：Qwen3.8-Flash-Next公式model card（2026年8月30日確認）
MiaAI-Lab：Qwen3.8-27B SGLang DGX Spark recipe（2026年8月30日確認）
MiaAI-Lab：Qwen3.8-Flash-Next Dual DGX Sparks recipe（2026年8月30日確認）