クラウドT4 GPUの温度依存性能低下：サーマルスロットリング実測データに基づく推論安定化の設計指針

はじめに：クラウドGPUの「スペック」は嘘をつかないが、条件もまた真実である

クラウドGPUのスペックシートを読むとき、多くの技術者は「FP16: 65 TFLOPS」のような数値を見て、それが稼働中の実効性能であると思い込みがちだ。しかし、Google Compute EngineのGPUページにT4のFP16性能が記載されている一方で、動作条件や温度に関する詳細な注釈は明示されていない場合が多い。この数値は、理想的な冷却条件下で得られる最大値であり、長時間の連続推論を前提とした安定性能を保証するものではない。

T4は受動冷却設計のGPUであり、ファンによる強制冷却を持たない。この設計上、チップ温度の上昇は回避可能なノイズではなく、物理的に不可避な現象となる。重要なのは、この温度上昇が単に「熱い」という問題にとどまらず、クロック周波数の自動低下を通じて推論速度（tok/s）に影響を及ぼす点である。

本記事では、Google Cloud上のT4でLLMモデルを実際に実行し、温度変化に伴うデコード速度の低下を定量的に測定したデータに基づいて分析する。サーマルスロットリングが本番環境のレイテンシに与える影響を「設計上の変数」として扱い、回避策の設計判断基準を提示する。対象読者は、LLM推論のレイテンシとコストを厳密に制御する技術責任者・SREであり、スペックシートの裏にある物理的制約を前提とした設計判断を行うことを目的とする。

現象の解明：温度上昇とクロック周波数の因果関係を実測する

Google Cloud上のT4でGemma 4 E2Bのデコード処理を実行し、温度変化に伴う速度の変化を測定した。その結果、チップ温度が45°Cから77°Cに上昇する過程で、デコード速度が115.3 tok/sから106.8 tok/sへ7.4%低下した。この低下は測定誤差やランダムノイズの範囲を超えており、本番環境のレイテンシSLOに影響し得る規模である。

この低下の根本原因は、半導体回路の物理的特性にある。温度が上昇するとMOSFETのリーク電流が増加し、同じクロック周波数でも消費電力が大きくなる。T4は70Wの電力制限（Power Limit）で動作するため、消費電力がこの上限に近づくとGPUは自動的にクロック周波数を低下させることで電力を抑制する。実測では、温度上昇に伴いクロック周波数が1,457MHzから1,267MHzへ低下しており、これが推論速度の7.4%低下に直接結びついている。

この現象はT4に固有の特殊事例ではなく、NVIDIA TensorRTの公式ドキュメントでも指摘されている。低電力GPUにおいて冷却が不充分な場合、安定化クロック周波数自体が低下し、結果として性能が悪化する物理的制約が存在する。つまり、スペックシート上の数値は「冷却が十分であること」を暗黙の前提としており、この前提が崩れると性能は保証されない。

flowchart LR
    A["温度上昇"] --> B["リーク電流増加"]
    B --> C["消費電力増大"]
    C --> D["電力制限に到達"]
    D --> E["クロック周波数低下"]
    E --> F["推論速度低下"]

この因果チェーンを理解しておくと、単に「温度が高い」ことへの対応（例：冷却強化）だけでなく、「電力制限に到達する前にクロックを制御する」という設計介入点が存在することが分かる。次のセクションでは、この介入点の一つであるクロック固定の効果と限界を考察する。

設計判断I：クロック固定は性能安定化の万能薬か？

温度による速度ドリフトを抑制する最も直接的な手法は、GPUクロックを固定することである。実測では、GPUクロックを1,200MHzに固定した結果、温度変化に伴う速度ドリフトが7%から0.7%に縮小した。これは、クロックが一定であれば温度上昇による電力変化が速度に反映されにくくなることを意味し、予測可能なレイテンシを実現する有効な手段となり得る。

しかし、この手法には明確なトレードオフがある。固定したクロック値（1,200MHz）はT4の最高クロック（1,457MHz）より低い値であり、その状態では平均性能が最高速時より低下する。スループットを最大化したいバッチ処理や、レイテンシの変動よりも総処理時間が重要なワークロードでは、固定クロックによる性能喪失がコスト増に直結する可能性がある。

したがって、設計者は「予測可能性（安定性）」と「最大パフォーマンス」のどちらを優先するかを判断する必要がある。リアルタイム推論でP99レイテンシを厳密に制御する場合は固定クロックが有利であり、オフラインバッチ処理でスループットを最大化したい場合は動的クロック（デフォルト）が適切である。以下に両方式の特徴をまとめる。

方式	速度変動	向いている場面	注意点
動的クロック（デフォルト）	温度依存の変動あり（実測で最大7.4%）	バッチ処理・スループット重視	レイテンシSLOが厳しい場合不適
固定クロック（例：1,200MHz）	変動が0.7%程度に抑制	リアルタイム推論・P99制御	平均性能が最高速時より低下する

ここで判断基準を整理すると、レイテンシの「上限」がビジネス要件として定義されている場合は固定クロックが合理的であり、レイテンシの「平均」のみが問題である場合は動的クロックで十分である。ただし、固定クロックの値はワークロードの特性に応じて調整可能であり、必ずしも最低値に設定する必要はない。最高クロックに近い値で固定すれば性能劣化を抑えつつ、ある程度の安定性も得られる中間解が存在する。例えば1,300MHz程度で固定すれば、最高速時の性能劣化は数%程度に収まりつつ、ドリフトも大幅に抑制できる可能性がある。最終的な値は、nvidia-smi dmonで温度とクロックの相関を観測しながら、SLO要件に対して余裕を持たせた値に設定するのが実務的なアプローチである。

設計判断II：A/Bテストにおけるサーマルバイアスの除去

モデルの性能比較やプロンプト最適化の検証において、バックツーバック（同一ハードウェア上で順次実行）でA/Bテストを行うことは標準的な手法である。しかし、T4のような受動冷却GPUでは、この「順次実行」が系統的なバイアスを導入する可能性がある。

実測では、冷却待機なしで2つのサーバーを連続実行した場合、2番目に実行されたサーバーのデコード速度が1番目より1.9〜2.5%低速となった。この差はランダムノイズではなく、GPUの熱容量が起因する遅延効果である。最初のワークロードがGPUチップと基板に熱を蓄積し、2番目のワークロード開始時点でチップ温度がまだ高い状態から始まるため、電力制限に達するまでのクロック余剰が少なくなる。結果として、2番目の実行が「最初から低速」でスタートするのだ。

この1.9〜2.5%の差は、モデル間の性能差が数%程度の場合、比較結果を覆すほどの規模である。例えば、AモデルがBモデルより2%高速であるという結論を導いたとしても、それが実態ではなくサーマルバイアスに起因する偽陽性である可能性を排除できない。特に、モデル間の性能差が3%以内である場合、バイアス除去なしのバックツーバックテストでは統計的に有意な差を判定することが極めて困難になる。

バイアスの除去戦略

このサーマルバイアスを除去するには、以下3つのアプローチが考えられる。

冷却待機時間の挿入：各ワークロードの間に十分な待機時間を設け、チップ温度がベースラインまで回復させる。待機時間は環境依存だが、T4の受動冷却構造を考えると、温度が低下するまでには数分単位を要する場合がある。テストの総実行時間が長くなる代償は避けられないが、単一インスタンスで完結できる点でコスト面では最も軽量な手法である。

並列実行による熱影響の均質化：比較対象を同時に実行し、両者が同じ熱環境に曝されるようにする。ただし、T4は単一GPUインスタンスに1枚搭載される構成が一般的であり、並列実行には複数インスタンスの同時起動が必要になる。コストは増えるが、バイアス除去の信頼性が高い。

クロック固定による排除：前節で述べた通り、クロックを固定すれば温度ドリフト自体が収まるため、サーマルバイアスの影響を実質的に消滅させることができる。ただし、固定クロックでは「最高速時の性能差」が測れないため、比較の目的が「安定性能の差」に限定される点に注意が必要である。

判断基準は、比較したい性能指標が「ピーク性能」か「安定性能」かで分かれる。ピーク性能の差を知りたい場合は冷却待機が必須であり、安定性能の差で十分ならクロック固定が最も効率的である。いずれにせよ、バイアスの存在を無視したまま統計的有意性を判断すると、本来は差がないモデル間に差を見出してしまう（偽陽性）リスクがある。

運用監視：nvidia-smi dmonを用いた多変量モニタリングの実践

本番環境で性能ドリフトが発生した際に「温度が高かったから」と断定するのは早急である。温度上昇は結果であり、原因の特定にはクロック周波数・消費電力・利用率の時間的相関が必要になる。NVIDIAのTensorRTドキュメントでも、推論負荷中にこれらのメトリクスを並行して記録・監視することが推奨されている（TensorRTのハードウェア環境に関する解説）。

なぜ単一指標では不十分か

温度が閾値を超えても、クロックがまだ高い値を維持している状態と、すでに低下している状態では、推論速度への影響が全く異なる。前者は電力制限にまだ到達していない（リーク電流の増加が電力制限の余剰を吸収している段階）ため、性能影響は限定的である。後者は電力制限に到達し、GPUドライバが能動的にクロックを下げている状態であり、性能影響が顕在化している。温度の絶対値だけでは、この2つの状態を区別できない。

同様に、GPU利用率が100%でもクロックが低下していなければ性能は維持されるが、利用率が80%でクロックが低下している場合、実効的なスループットは大きく落ちる。利用率とクロックの両方を同時に把握することで、「負荷が原因か、熱が原因か」を切り分けることができる。

nvidia-smi dmonの実践

nvidia-smi dmonコマンドは、GPUのクロック（SM Clock）、メモリクロック、消費電力、温度、GPU利用率、メモリ利用率などのメトリクスを出力する。オーバーヘッドが比較的lowであるため、本番環境のデバッグ時にリアルタイムで実行できる場合がある。

nvidia-smi dmon -s pcutm -d 1

ここで重要なのは、出力を時系列データとして記録し、後で相関分析することである。特にT4のような受動冷却デバイスでは、温度が閾値を超えた瞬間にクロックが段階的に低下するため、「温度の傾き」ではなく「クロックのステップ変化のタイミング」を電力消費と突き合わせることが、スロットリングの発生条件を特定する鍵となる。

本番環境では、dmonの出力をファイルにリダイレクトし、PrometheusやInfluxDBなどの時系列DBに収集するパイプラインを構築するのが実用的である。アラート設定の際は、温度の絶対値ではなく「クロックがベースラインから何%低下したか」をトリガーにすると、誤検知を減らすことができる。例えば、ベースラインクロック（1,457MHz）に対して5%以上低下（約1,384MHz以下）した場合にアラートを発火させる設定は、温度閾値ベースのアラートよりも性能影響との相関が明確であり、オンコールの対応判断を迅速にする。

sequenceDiagram
    participant App as 推論アプリケーション
    participant GPU as T4 GPU
    participant Driver as GPUドライバ
    App->>GPU: 推論リクエスト増加
    GPU->>GPU: 温度上昇
    GPU->>Driver: 消費電力が制限に接近
    Driver->>GPU: クロック低下
    GPU->>App: 推論速度低下

アーキテクチャレベルの回避策：スケジューリングと冷却設計

クラウド環境では物理的な冷却設計（ファン追加、筐体改造）が利用できないため、回避策はソフトウェア層に求めることになる。ここではスケジューリングとリソース配置の2つの観点から、実務的に有効なパターンを整理する。

タスク分割とアイドル時間の設計

T4の受動冷却構造では、チップの熱が基板を通じて外部へ逃げる速度が限られている。長時間の連続推論（例：バッチジョブで数十分間GPUを100%稼働）では、熱が飽和状態に近づき、電力制限に到達するまでのクロック余剰が消失する可能性がある。これを防ぐには、推論タスクを分割し、間に短いアイドル時間（数秒〜数十秒）を挟むスケジューリングが有効である。

具体的には、バッチサイズを小さくして1回のGPU占有時間を短縮し、バッチ間で数秒のインターバルを設ける。このインターバル中にチップ温度がわずかに低下し、次のバッチ開始時にクロック余剰が回復する可能性がある。バッチサイズとインターバルの最適値はワークロード依存だが、nvidia-smi dmonで温度の回復カーブを観測しながら調整するのが確実である。例えば、バッチサイズを32から16に減らし、バッチ間に5秒のインターバルを設けることで、ピーク温度を数°C下げる効果が見込める場合がある。

ホスト上の熱干渉（Nearby Noise）の考慮

クラウドVMのホスト上には、自分のインスタンス以外のワークロードも存在する。同じ物理マザーボード上の他のGPUやCPUが放熱すると、T4の基板温度が上昇し、電力制限に到達するまでの余剰が減少する。これは「Nearby Noise」と呼ばれる現象であり、同一インスタンス内で再現性のあるベンチマーク結果が得られない原因になることがある。

対策として、レイテンシSLOが厳しいインスタンスは、他の高負荷ワークロードと同一ホストに配置されないようにする（専用ノードの確保、またはスケジューラーでのアフィニティ設定）。クラウドプロバイダーがノードレベルの制御を提供している場合は、それを活用できる。提供されていない場合は、時間帯をずらして高負荷ジョブを実行する運用上の工夫が必要になる。

ワームアップ期間の設計

リアルタイム推論のAPIにおいて、インスタンスの起動直後（またはアイドルから復帰した直後）は、GPUがまだベースライン温度にないため、最初の数リクエストで性能が不安定になる。この初期変動を除外するため、プロトコルレベルでワームアップ期間を設ける設計が有効である。

例えば、インスタンスのヘルスチェックが成功してから一定時間はトラフィックを投入せず、その間にGPUが熱的に安定化するのを待つ。この待機時間は環境依存だが、dmonでクロックが安定するまでの時間を計測すれば、ワークロード固有の値を導出できる。ワームアップ期間を設けない場合、P99レイテンシが初期リクエストによって引き上げられ、SLO違反の原因になり得る。

コストと性能のバランス：T4選定時の真のコスト計算

T4は低電力・低コストでLLM推論に用いられるが、その「低コスト」は安定した高性能を前提としていない。Google Cloud GPUの仕様ページに記載されているFP16 65 TFLOPSは、動作条件や温度に関する注釈が付されていない理論値である（Google Cloud GPUドキュメント）。実際の稼働環境では、サーマルスロットリングにより実効性能がスペック値を下回る場合があり、この差を無視したコスト試算は構造的に不正確になる可能性がある。

具体的には、実測で確認された7.4%のデコード速度低下が発生した場合、同等のスループットを維持するにはインスタンス数を約8%増やす必要がある（1/0.926 ≈ 1.08）。例えば、10インスタンスで運用していた場合、実質的に11インスタンス相当のコストがかかる計算となる。あるいは、スループットを維持せずレイテンシ許容度を広げる選択を取ることも可能だが、その場合はユーザー体験やSLOに直接影響する。

ここで重要なのは、この数値が「最悪ケース」ではなく「熱安定化後の定常状態」である点だ。Gemma 4 E2Bのデコード負荷を継続的にかけた条件下で観測された値であり、バッチ処理やスパイク負荷ではさらに異なる値になる可能性がある。導入検討段階では、スペックシート上の理論値ではなく、実際の負荷パターンにおける熱安定化後の性能を見積もりに組み込むことが、正確なROI試算に不可欠である。

実践的なアプローチとしては、評価環境で30分〜1時間程度の連続推論負荷をかけた後に計測したtok/sを「実効性能」としてコストモデルに反映することだ。これにより、運用開始直後の「スペック通り」の幻想が剥がれ、実際のインフラコストとレイテンシ特性に基づいた意思決定が可能になる。特にT4のような受動冷却GPUでは、この差が顕著に現れるため、コスト比較の前提条件を「定常状態」に揃えておくことが公平な比較の最低条件となる。

実装パターン：動的クロック制御のコード例と注意点

Python環境では、pynvmlライブラリを用いてGPUの電力制限やクロック周波数をプログラム的に制御できる。以下は、GPUクロックを1,200MHzにロックする最小例である。

import pynvml

pynvml.nvmlInit()
handle = pynvml.nvmlDeviceGetHandleByIndex(0)

# 現在の電力制限を確認（mW単位）
current_limit = pynvml.nvmlDeviceGetPowerManagementLimit(handle)
print(f"Current power limit: {current_limit / 1000:.0f}W")

# GPUクロックを1200MHzにロック（min=maxで固定）
pynvml.nvmlDeviceSetGpuLockedClocks(handle, 1200, 1200)

# 設定の確認
min_c, max_c = pynvml.nvmlDeviceGetGpuLockedClocks(handle)
print(f"Locked clocks: {min_c}-{max_c} MHz")

# 不要になったら解除
# pynvml.nvmlDeviceResetGpuLockedClocks(handle)
# pynvml.nvmlShutdown()

このスクリプトは、推論アプリケーションの起動前に実行することで、プロセス全体が固定クロックで動作する状態を確保する。逆に、アプリケーション起動後に設定を変更すると、実行中の推論バッチの間にクロックが切り替わり、レイテンシのスパイクが発生し得るため、起動前の一括設定が基本になる。

クラウドVMでの制約

ただし、クラウドVM（特に共有ホスト型）では、低レベルなハードウェア制御が制限されている場合がある。nvmlDeviceSetGpuLockedClocksが権限エラーを返す、あるいは設定してもホスト側のポリシーで上書きされるケースが報告されている。事前にプロバイダーのGPU制御ポリシーを確認し、利用可能な制御範囲を把握しておくことが必要だ。制御できない環境では、前節で述べたスケジューリング層での熱管理に頼ることになる。

ロールバック計画の重要性

固定クロックの適用は、GPUの過熱やシステム不安定を招く設定ミスにつながり得る。例えば、冷却能力が不足する環境で高クロックを無理に固定すると、サーマルシャットダウンが発生するリスクがある。そのため、設定スクリプトには必ずロールバック手順（nvmlDeviceResetGpuLockedClocksの呼び出し）を同梱し、設定適用後に一定時間（5分程度）nvidia-smi dmonで温度とクロックの挙動を確認する手順を運用手順書に明文化しておくべきである。設定変更は変更管理プロセスに組み込み、無断変更が起きないようアクセス制御を施すことも推奨される。

まとめ：物理制約を前提とした堅牢なAIインフラ設計へ

クラウドGPUの性能は、温度や電力といった物理的制約に常に左右される。T4におけるデコード速度の7.4%低下は、設計上の「ノイズ」ではなく、考慮すべき「変数」である。スペックシートが示す理論値と、熱的に安定化した実効性能の間に構造的な差が存在することを前提に置かない限り、レイテンシSLOの設計もコスト試算も根拠を失う可能性がある。

推論システムの安定性を高めるには、単一の対策ではなく多層的なアプローチが有効である。第一層として、nvidia-smi dmonによるクロック・電力・温度の並行監視で状態を可視化する。第二層として、レイテンシ要件が厳しいサービスにはクロック固定による予測可能性の確保を適用する。第三層として、スケジューリング層で熱蓄積を防ぐ待機時間の設計や、複数インスタンス間の負荷分散による熱影響の均質化を行う。これらの層を組み合わせることで、物理的制約を「回避」するのではなく「管理」する設計が実現する。

技術意思決定者に求められるのは、ハードウェアの物理的限界——リーク電流の温度依存性、電力制限とクロック周波数のトレードオフ、熱容量による時間遅延——を正確に理解した上で、ビジネス要件（レイテンシ vs コスト vs スループット）に最適なバランス点を見出すことだ。GPUのスペック表は理想条件での値を示している。本番環境の熱環境を「設計変数」として扱い、実測データに基づいて判断する姿勢が、堅牢なAIインフラの基礎となる。

参考

本記事は海外の技術トレンド「Don't Assume Your Cloud T4 Runs at Spec: Gemma 4 Decode Falls 7% as the Card Warms」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。