H200 GPU：アーキテクチャ、性能、クラウド導入ガイド

H200 GPU：アーキテクチャ、性能、クラウド導入ガイド

NVIDIA H200 GPUは、Hopper世代のデータセンター向けアクセラレータであり、その導入における決定的な特長はメモリです。GPUあたり141 GBのHBM3eと4.8 TB/sのメモリ帯域幅を備えています。これにより、長文コンテキスト推論、大規模バッチ、メモリバウンドのHPCジョブの計画方法は変わりますが、キャパシティプランニングやクラウド検証が不要になるわけではありません。

本ガイドでは、H200 GPUとは何か、H200 SXMとH200 NVLの違い、どのような場合にワークロードに適合するか、より大規模なフリートにコミットする前にクラウド導入を検証する方法を説明します。変動しやすいプロバイダーの価格スナップショットは意図的に扱いません。以下のチェックリストは、利用可能な正確なリージョン、マシンタイプ、トポロジー、契約内容とともに使用してください。

要点

ワークロードがGPUメモリ容量または帯域幅によって制約されており、アクセラレータだけでなく周辺システムも検証できる場合は、H200 GPUを選択してください。単一GPUのモデルサーバーでは、モデルウェイト、ランタイムワークスペース、KVキャッシュが余裕を持って収まることを証明する必要があります。マルチGPUのトレーニングまたはサービングでは、GPU間ファブリックと、該当する場合はノード間ネットワークを検証する必要があります。

H200 GPUは万能なアップグレードではありません。リクエストが短い、バッチサイズが小さい、またはワークロードがCPU、ストレージ、ネットワークに律速される場合、その追加メモリは重要な結果を変えない可能性があります。まずワークロード概要を作成し、次に代表的なトレースでテストしてください。

H200 GPUの仕様：導入計画を変える要素

NVIDIAは、H200を141 GBのHBM3eメモリと4.8 TB/sのメモリ帯域幅を備えたHopperアーキテクチャのGPUとして掲載しています。H200 SXMとH200 NVLが提供されており、主要なメモリ仕様は同じですが、フォームファクター、電力枠、スケーリングの選択肢が異なります。NVIDIAが公表しているTensor Coreのピーク性能値は製品構成の比較には有用ですが、アプリケーションスループットを保証するものではありません。これらの数値には、明記されたテスト条件およびスパース性の前提が含まれます。SKUを選択する前に、現在のH200製品仕様を確認してください。

これらはベンダー公表値であり、NVIDIAは製品ページ上で暫定値としています。これらを構成のベースラインとして扱い、実行する環境で正確なクラウドSKUとそのトポロジーを検証してください。

HBM3eがLLM推論で重要な理由

LLMサービングでは、GPUメモリはモデルウェイト以外にも消費されます。最初の概算に役立つ容量計算式は次のとおりです。

必要なGPUメモリ = ウェイト + ランタイムワークスペース + p95のコンテキストおよび同時実行数におけるKVキャッシュ + 運用上の余裕

KVキャッシュが制約要因となる場合、H200 GPUは魅力的な選択肢になり得ます。プロンプトの長期化、同時シーケンス数の増加、バッチの拡大はいずれもKVキャッシュを増加させる可能性があります。追加のHBMがあってもメモリ不足のリスクがなくなるわけではありません。キャッシュポリシー、アロケータの挙動、量子化、モデル並列化、トラフィック形状も引き続き重要です。長文コンテキストの導入では、ローカルメモリの増加だけが答えだと考えるのではなく、この判断をKVキャッシュのオフロードおよび階層化計画と組み合わせてください。

H200 SXMまたはH200 NVL：カードだけでなくトポロジーを選ぶ

フォームファクターは導入に関する選択です。

• H200 SXMは、4基または8基のGPUを搭載するHGX H200およびNVIDIA-Certifiedシステム設計に適しています。1つのワークロードに密結合のマルチGPUシステムが必要で、アプリケーションがGPU間で頻繁にデータを交換する場合、通常はこれが適切な出発点です。
• H200 NVLは、デュアルスロットの空冷PCIe設計です。NVIDIAは2または4ウェイのNVLinkブリッジ構成を掲載しており、パートナーおよび認定システムには最大8基のGPUを搭載できます。すべての8 GPUサーバーが同じ直接GPU間パスを提供すると推測してはいけません。実際のトポロジーを確認し、ランタイムが使用する集団通信をベンチマークしてください。
• 独立したレプリカには、必ずしも最も密結合なファブリックが必要とは限りません。各レプリカが独自のリクエストを処理する場合は、ワークロードが使用しないトポロジーに費用をかける前に、キャパシティ、可用性、ホストリソース、明確なスケジューリング境界を優先してください。

NVIDIAはH200のMIG容量を文書化していますが、GPU共有モードを相互に代替可能なものとして扱わないでください。Kubernetesでは、MIGはハードウェア分離されたGPUインスタンスを作成します。一方、タイムスライシングは処理を交互に実行する方式であり、レプリカ間のメモリ分離や障害分離は提供しません。GPU Operatorの共有ガイドでは、このトレードオフと監視上の制約を説明しています。

購入判断のより詳細な比較については、H200 vs. H100を参照してください。この比較は意思決定に役立ちます。本ページは、H200が候補となった後の導入プレイブックです。

H200 GPUが適している場合

以下の制約のいずれかが本番環境で実際に存在する場合、H200 GPUをテストする価値は一般にあります。

1. メモリバウンドのLLM推論。 コンピュートを完全に使い切る前に、p95コンテキスト長または同時実行数によって実用的なメモリ予算が枯渇する。
2. 帯域幅に敏感なAIまたはHPC。 プロファイリングにより、Tensor Core演算を単純に飽和させるよりも、ジョブがメモリ移動の待機に相当な時間を費やしていることが示される。
3. より大きなメモリ常駐ワーキングセット。 別のGPUをすぐに追加せずに、モデル、検索コンテキスト、バッチ、キャッシュ、または科学データ構造のための容量をさらに必要としている。
4. 密結合のマルチGPU処理。 H200 SXM/HGXスタイルのシステムを使用でき、アプリケーションがそのファブリックの恩恵を受けるという証拠がある。
5. 制御されたパーティショニング要件。 掲載されているMIG構成を使用する明確な理由があり、それらに適合するスケジューラとチャージバックモデルがある。

モデルのパラメータ数だけでH200 GPUを選定しないでください。パラメータ数からは、精度、ランタイムワークスペース、KVキャッシュポリシー、最大コンテキスト、バッチ形状、可用性マージンについてほとんど分かりません。また、クラウドワークロードでボトルネックとなり得るホストCPU、RAM、ストレージ、ネットワークについても分かりません。

クラウドGPUを借りる前にH200のキャパシティプランを作成する

インスタンスを作成する前、またはクラスターノードプールをリクエストする前に、この1ページの概要を使用してください。

この概要の価値は、不適合を早期に可視化できる点にあります。たとえば、短いプロンプトを使った合成テストで優れた結果が出ても、p95のコンテキストとキャッシュの負荷により、単一GPU構成が失敗することがあります。逆に、ランタイムが効率的に利用できないファブリックにまたがって分割されている場合、マルチGPU構成は期待を下回る可能性があります。

クラウド導入：段階的なH200 GPUランブック

1. 正確なクラウド構成を確認する

プロバイダーまたはプラットフォームチームに、アクセラレータの正確なフォームファクター、GPU数、CPU/RAM割り当て、ローカルおよび永続ストレージ、ネットワーク特性、GPUトポロジーを確認してください。回答は導入チケットに記録します。マルチGPUの性能を見込むには、「H200」だけでは十分な情報ではありません。

キャパシティを予約する前に、短期間のパイロットで以下の詳細を検証してください。

• H200 SXM または H200 NVL
• GPU 数と nvidia-smi topo -m の出力
• インスタンスが専有、パーティション分割、またはタイムスライスのいずれであるか
• ドライバー、CUDA、コンテナランタイム、フレームワークのバージョン
• 利用可能なホスト RAM、CPU コア、ストレージスループット、ネットワーク経路
• イメージプル、モデルダウンロード、チェックポイント、再起動の所要時間

2. サポート対象のソフトウェア構成を導入する

Kubernetes へのデプロイでは、NVIDIA の GPU Operator を使用して、NVIDIA ドライバー、コンテナツールキット、デバイスプラグイン、GPU Feature Discovery、DCGM ベースのモニタリング、および関連コンポーネントを管理できます。公式インストールガイドでは、Operator がドライバーを管理する場合のノード OS の一貫性に加え、コンテナランタイムおよび名前空間セキュリティの前提条件についても説明されています。古いチャートバージョンをコピーするのではなく、最新の GPU Operator インストールガイダンスに従ってください。

初回インストールは次のパターンに従います。バージョンは、クラスターおよびドライバーポリシーに対して検証済みのものに置き換えてください。

helm install --wait gpu-operator \
  -n gpu-operator --create-namespace \
  oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
  --version=<validated-operator-version>

インストール後、最初のワークロードを送信する前に、Operator Pod と ClusterPolicy の状態を検証してください。Operator ガイドでは、ノードが割り当て可能な nvidia.com/gpu リソースを報告していることを確認する方法も示されています。

3. スケジューリングを明示する

共有モード向けに意図的に設計している場合を除き、まずは専有のフル GPU リクエストから始めてください。

resources:
  limits:
    nvidia.com/gpu: 1

検証済みの H200 ノードをターゲットにするには、プラットフォーム管理のノードプールラベルまたはクラウドセレクターを使用してください。サンプルクラスターの製品ラベルをハードコードしてはいけません。Kubernetes では、デバイスプラグインと拡張リソースを通じた GPU スケジューリング（上記のリソース制限パターンを含む）が文書化されています。現在の契約については、Kubernetes の GPU スケジューリングドキュメントを参照してください。

MIG を有効にする場合は、まず対象ノードをドレインまたはコルドンしてください。NVIDIA は、MIG モードまたはジオメトリを変更する際にはユーザーワークロードを GPU から退避させる必要があり、一部のクラウド環境では再起動が必要になる場合があると述べています。パーティション変更をオンライン操作として扱う前に、GPU Operator の MIG 手順を確認してください。

4. 単純なワークロードを確認してから、実際のワークロードを検証する

次の 3 つのゲートを順番に実行します。

1. プラットフォームゲート: ドライバーと CUDA がロードされる。スケジューラーが想定どおりの GPU 数を認識する。コンテナが CUDA コンテキストを作成できる。
2. ファブリックゲート: トポロジーが想定された設計と一致する。マルチ GPU ランタイムが初期化され、代表的な集団通信テストを完了する。
3. アプリケーションゲート: 代表的なプロンプト、バッチサイズ、コンテキスト長、チェックポイントパターン、またはシミュレーション入力のリプレイが、必要なレイテンシー、スループット、エラー目標に到達する。

3 番目のゲートが意思決定のゲートです。汎用ベンチマークでは GPU が動作することは確認できますが、トラフィック分布、モデルサーバー、キャッシュポリシーが機能するかどうかまでは判断できません。

スケーリング前にパフォーマンスを検証する

予想されるボトルネックを中心に受け入れテストを構築し、その前提を覆し得る結果を確認してください。

NVIDIA DCGM は、パッシブな健全性監視とアクティブな診断を分離しています。その診断ワークフローでは、デプロイメント、メモリ、PCIe、NVLink、コンピュート、電力、温度、通信経路をテストできますが、リソースを消費し、本番作業と競合する可能性があります。侵襲的な診断を実行する前に、ノードをドレインするか、メンテナンスウィンドウを設定してください。適切なテストレベルを選択するには、DCGM の最新の診断ガイダンスを使用してください。

LLM サービスでは、アプリケーションとインフラストラクチャの両方のシグナルを追跡してください。

• p50/p95 の初回トークン生成時間とトークン間レイテンシ
• 1 秒あたりの受理された出力トークン数と 1 秒あたりの完了リクエスト数
• キュー深度、キャンセル、再試行、エラー率
• 割り当て済み GPU メモリと予約済み GPU メモリ、GPU 使用率、電力、温度
• キャッシュヒット／オフロードの挙動とキャッシュ関連の障害
• ホスト CPU の飽和、RAM 負荷、モデル／チェックポイント I/O、ネットワークレイテンシ

ある指標が改善して別の指標が悪化する場合は、まだスケールしないでください。トークンレートが上がっても p95 レイテンシや再試行が増加している場合、顧客向けサービスにとっては回帰となる可能性があります。

時間単位の GPU 利用時間ではなく、完了した作業に基づいてコストを最適化する

クラウドの H200 GPU 料金は、リージョン、予約期間、ホスト構成、供給状況によって異なるため、静的な価格表はすぐに古くなります。代わりに、アイドル時間と失敗した作業を可視化できるワークロード単位を使用してください。

fully loaded hourly cost = accelerator + attached CPU/RAM + storage + network + licenses + operating overhead

cost per completed request = fully loaded hourly cost / completed requests per hour

cost per million accepted output tokens = fully loaded hourly cost / accepted output tokens per hour × 1,000,000

最大スループットのデモではなく、ローンチ時に想定するトラフィックミックスでこれを計算してください。フェイルオーバー、モデル読み込み、チェックポイント、メンテナンスのために確保するキャパシティも含めます。より詳細なモデルについては、セルフホスト LLM の 100 万トークンあたりのコストを参照してください。

もう 1 つの境界に関する問いもあります。ランタイムを運用する必要があるのか、それともモデル出力への信頼できるアクセスが必要なのか、という点です。カスタムカーネル、特定のランタイム、専用のデータローカリティ、または制御されたハードウェア実験が必要であれば、クラウド H200 GPU のパイロットを正当化できる場合があります。主にモデル API が必要な場合は、インフラストラクチャにコミットする前に、運用負荷を API パスと比較してください。GPU サーバー導入ガイドとKubernetes GPU クラスターガイドは、この境界を明確にするのに役立ちます。

H200 GPU 導入チェックリスト

H200 の導入を準備完了と判断する前に、以下をすべて確認してください。

• [ ] 正確な H200 のフォームファクター、GPU 数、トポロジーを記録済み
• [ ] p95 コンテキストと想定同時実行数でメモリ予算をテスト済み
• [ ] ドライバー、CUDA、フレームワーク、コンテナイメージの互換性を検証済み
• [ ] Kubernetes を使用する場合、GPU Operator／デバイスプラグインの健全性を確認済み
• [ ] スケジューラーが想定どおりの nvidia.com/gpu キャパシティを公開している
• [ ] 本番トポロジーでマルチ GPU コレクティブテストに合格している
• [ ] 代表的な負荷テストが TTFT、レイテンシ、スループット、エラーの目標を満たしている
• [ ] DCGM の健全性確認と適切なメンテナンス時間帯の診断がランブックに含まれている
• [ ] ストレージ、ネットワーク、モデル読み込み、チェックポイント、再起動の経路を計測済み
• [ ] アイドル時および復旧用のキャパシティを含め、完了した有用な単位あたりでコストを計算している

よくある質問

H200 GPU のメモリ容量はどれくらいですか？

NVIDIA は、H200 SXM と H200 NVL の両方について、141 GB の HBM3e メモリと 4.8 TB/s のメモリ帯域幅を公表しています。カードのフォームファクターとインターコネクトは異なるため、正確な SKU とシステム構成をプロバイダーに確認してください。NVIDIA の H200 仕様は、このガイドにおける数値の情報源です。

LLM 推論では H200 GPU は H100 より優れていますか？

特にメモリ容量またはメモリ帯域幅がワークロードの制約となる場合は、優れている可能性があります。実際の答えは、モデル精度、コンテキスト長、KV キャッシュの挙動、同時実行数、サービングランタイム、システムトポロジーに依存します。代表的なトレースでワークロードを比較し、ベンダーベンチマークをサービス SLO の代替と見なさないでください。ハードウェア選定のフレームワークについては、H200 と H100 の比較を参照してください。

H200 SXM と H200 NVL のどちらを選ぶべきですか？

トポロジーを起点に選択してください。H200 SXM は、密結合された HGX スタイルのマルチ GPU 構成に適しています。H200 NVL は、2 ウェイまたは 4 ウェイの NVLink ブリッジ構成に対応する、PCIe 接続・空冷のオプションです。メモリ容量だけで選ぶのではなく、トポロジー、ホスト、ワークロードの通信パターンを検証してください。

H200 GPU は MIG をサポートしていますか？

NVIDIA は、H200 SXM と H200 NVL について、インスタンスごとに記載されるメモリ容量は異なるものの、最大 7 つの MIG インスタンスを記載しています。ハードウェアで裏付けられたメモリ分離と障害分離が必要な場合は MIG を使用してください。これらの分離特性が必要な場合に、タイムスライシングで代用してはいけません。

必要な H200 GPU の数は？

代表的なメモリ、レイテンシ、スループット、復旧テストに合格する最小構成から始めてください。メモリ予算、レプリカ数、または検証済みの並列化計画で必要となる場合にのみ GPU を追加します。ファブリックを考慮しないワークロードで GPU 数を増やしても、顧客向けの結果を改善せずにコストと運用上の管理対象を増やす可能性があります。

検証済みの H200 GPU パイロットから始める

適切な H200 GPU 導入とは、計測されたシステムです。アクセラレータメモリ、トポロジー、スケジューラー、ランタイム、データパス、可観測性、ワークロードの経済性がすべて整合している必要があります。計測機能を備えたパイロットから開始し、現実的なトラフィックをリプレイし、障害モードを文書化して、次のキャパシティ拡張を裏付ける証拠が得られた後にのみスケールしてください。

情報源

• NVIDIA H200 GPU仕様
• NVIDIA GPU Operatorインストールガイド
• Kubernetes GPUスケジューリングのドキュメント
• NVIDIA DCGM診断ドキュメント