より強力なGPUを探す前に、期待値を明確にする。

結果と時間枠を添えて問題を記述する

「GPUが動いていない」を、検証可能な観察に置き換えてください。最初の結果が遅れて届く、ステップに停止がある、または許容される出力の数が減る、といった形です。入力セット、アプリケーションのバージョン、設定、観察した期間を示します。初回起動には、すでに準備済みの実行とは異なるフェーズが含まれることがあるため、明示せずに混在させないでください。

処理の流れを、ファイルのオープン、CPUでの準備、転送、GPUでの計算、書き込み、検証に分けます。これらのフェーズは重なり合うことがあるため、図はトレースと照合すべき仮説となります。境界は同じタイムゾーンと十分な精度で記録してください。停止後に取得したハードウェアのグラフでは、その値が普段と違って見えても停止を説明できません。

パーセンテージとメモリを正しく読む

NVIDIA SMIでは、GPU使用率はサンプリング間隔のうち少なくとも1つのカーネルが実行されていた割合を示します。これはすべてのコンポーネントの性能評価ではありません。メモリ使用率は読み書きの活動を表し、占有されているメモリ量と混同してはいけません。またドキュメントには、環境によって一部のフィールドが利用できない場合があることも記されています。

したがって、メトリクスの正確な名前と単位を保持してください。メモリ量が多い場合は、待機中のデータが保持されていることを表すことがあります。低い活動は通常の準備フェーズ中に現れることもあります。逆に高い活動は、プログラムが有用な作業を行っていることを証明しません。ハードウェアと同時に、出力とアプリケーションの進捗も確認する必要があります。

相関のある、十分に短い測定記録を収集する

代表的なシーケンスを選び、収集をそのシーケンスに限定してください。時刻、GPU の識別子、アクティビティ、使用メモリ、アプリケーションの各フェーズを記録します。並行して、システムで利用可能なツールを使い、CPU プロセス、その待機状態、読み取りと書き込みを観察してください。全コアの平均は、飽和した単一スレッドを隠してしまう可能性があります。該当するプロセスも確認しましょう。

以下に示す読み取りコマンドは、すでにNVIDIA SMIを備えている許可されたNVIDIAターゲット向けに提案されたものです。このガイドでは実行されていません。CSV内の単位を保持し、中断されるまで1秒ごとに観測値を表示します。お使いのバージョンが対応するフィールドを確認し、シナリオの終了時に収集を停止してください。N/Aフィールドは不明のままです。ゼロに変換しないでください。

最小限のジャーナルは、作業の識別子、タイムゾーン付きの時刻、現在のフェーズ、識別可能な入力またはバッチ、進捗、および発生した可能性のあるエラーを関連付けます。シークレットや、診断に不要な業務コンテンツを含めてはなりません。テレメトリが欠けている場合は、まずその収集手段とアプリケーションの進捗を確認してください。空のグラフはプロセスが停止した証拠にはなりません。観察のない期間は、記憶から再構成するのではなく、そのまま印を付けてください。

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

手がかりと結論を区別する

アプリケーションが入力を待っている間に GPU アクティビティが低下する場合は、ファイルの経路を確認します。CPU の長い準備中に低下する場合は、そのフェーズと実際の並列性を確認します。デバイスが分散処理の他の参加者を待っている場合は、負荷の均衡と通信を確認します。複数の症状が同時に発生することがあります。それらの相関はまだ因果関係の証拠ではありません。

短い仮説と、それを切り分けるための変更を 1 つ書きます。たとえば、すでに準備済みの同じ入力を通常の準備と比較すれば、結果が同一であることを条件に、ある段階を切り分けられます。バッチサイズ、精度、プロセス数、ファイルの場所を同時に変更しないでください。改善の原因が特定しにくくなります。

架空の例：100秒のループを分析する

架空のチーム「 Revue des maquettes 」は、オーバーラップのないループを説明しています。CPU準備に60秒、GPU計算に20秒、そしてエクスポートに20秒です。合計は100秒で、GPU計算に割り当てられる時間の割合は20/100、つまり20%です。この教育用の計算は、サンプリングツールのパーセンテージを予測するものではなく、カタログ内のいずれのGPUの測定値にも対応しません。

計算や出力を変えずに、準備を30秒に短縮できると仮定しましょう。その場合、ループは30 + 20 + 20 = 70秒となり、30秒短縮され、GPUの割合は20/70、つまり約28.6%になります。逆に、GPU計算のみを仮に半分にすると、60 + 10 + 20 = 90秒になります。このシナリオは、最も長い待ち時間に対処することが、カードを変更するよりも大きな影響を与える可能性がある理由を説明しています。

プロファイラでフェーズを深掘りする

全体的な観察で遅い領域の場所が特定できてもその理由が説明できない場合は、短い時間枠でアプリケーションに適したプロファイラーを使用してください。PyTorch Profiler は CPU と CUDA のイベントを収集し、収集ウィンドウを整理できます。ドキュメントでは、シェイプやスタックの記録を有効にするとオーバーヘッドが生じると指摘されています。したがって詳細なトレースは診断の道具であり、その合計時間をそのままプログラムの通常の時間として提示すべきではありません。

フェーズ名は、技術的な操作と作業内容を結び付けられるよう、十分に説明的にしてください。ファイル群の準備、転送、アプリケーション段階、出力の公開などです。仮説に必要な詳細レベルから始めてください。変更後は、同程度の観測を行い、その後、大掛かりな計測なしで実行します。この2回目の確認により、通常の条件でも効果が存在することを検証できます。

問題を覆い隠す修正を避ける

並行性を高めると GPU を埋められる一方で、ディスク、ホストメモリ、出力に負荷がかかる可能性があります。バッチサイズを増やすとレイテンシと必要なメモリが変わることがあります。精度を下げると結果が変わる可能性があります。これらの判断は禁止されているわけではありませんが、表示されるパーセンテージが上がるから採用するのではなく、同じ業務目標に基づいて副作用とともに評価する必要があります。

単なるアクティビティの低下を診断するために、デバイスをリセットしたりハードウェア設定を変更したりしないでください。まずは読み取りから始め、明示的なエラーは権限を持つ担当者に確認してもらいます。また、プライベートなパス、機密パラメータ、入力データを含む生のトレースを公開することも避けてください。診断に役立つ抜粋を用意し、完全な証拠はチームの許可された範囲内で保管してください。

判断に役立つ証拠で診断を締めくくる

最終的な記録には、症状、採用した仮説、試した変更、その条件、および観察された結果を記載する必要があります。少なくとも、同じ入力セット、同じ品質、同じ終了定義でのビフォーアフターの比較を1つ保持してください。結果が結論に至らない場合は、何が排除されたか、そして次に必要な観察を書き留めてください。却下された仮説を文書化しておくことで、他の誰かが当てずっぽうでやり直すことを避けられます。

通常の低いアクティビティが常に修正を必要とするわけではありません。タスクが期限、品質、予算を満たしているなら、脆い最適化よりも複雑さを減らす方が望ましいことがあります。新しい構成を検討する場合は、実証された制約を受け入れ時の記録に伝えてください。孤立した測定値がカタログを格付けするものではなく、この例のいかなる値も約束された性能を構成するものではありません。