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

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

Nvidia H200 GPUは、メモリ容量、メモリ帯域幅、マルチGPUトポロジが結果に大きく影響するAIおよびHPCワークロード向けに設計されたHopper世代のアクセラレータです。NVIDIAは、H200あたり141 GBのHBM3eメモリと4.8 TB/sのメモリ帯域幅を公表しています。これらは重要な出発点ですが、それだけではH200の導入がレイテンシ目標を満たすか、モデルとKVキャッシュを収容できるか、あるいはクラウドノード全体で効率的にスケールできるかは分かりません。NVIDIAのH200仕様はハードウェアのリファレンスであり、本ガイドではそれを導入プロセスへと落とし込みます。

AI開発者およびMLインフラチームにとって、実務上の判断は通常次のとおりです。モデル、ピーク時のアクティブコンテキスト、ランタイムオーバーヘッドを、1基のGPUに十分な余裕を持って収容できるか。できない場合、ネットワークをまたぐ前に、ワークロードを高帯域幅のH200ノード内に留められるか。この答えによって、ピークTFLOPSという見出しではなく、フォームファクタ、並列化計画、受け入れテストを決めるべきです。

これはアーキテクチャと導入のガイドであり、価格表ではありません。見積もりやクラウドの時間単価を比較する場合は、まずH200 GPU価格ガイドをご覧ください。H200とH100の比較が目的であれば、H200とH100の比較をご覧ください。

要点：Nvidia H200 GPUが適している場合

以下の条件のすべて、または大半に当てはまる場合は、Nvidia H200 GPUを選択してください。

• ワークロードが、演算スループットだけでなく、モデルメモリ、KVキャッシュの増加、またはメモリ帯域幅によって制約されている。
• モデルを直ちにノード間で分割することなく、長コンテキストの推論や同時リクエストのためにより多くの余裕が必要である。
• 「H200」を完全な導入仕様として扱うのではなく、SXMまたはPCIe/NVLのフォームファクタ、ノードあたりのGPU数、利用可能なインターコネクトといった実際のクラウドトポロジを検証できる。
• 本番で想定するのと同じリクエスト形状で、最初のトークンまでの時間、出力トークンのスループット、テールレイテンシ、GPUメモリ、キューイングを測定する準備ができている。
• GPU容量を直接運用する正当性となる、サービングソフトウェア、モデルの重み、バッチ処理、またはデータローカリティに対する十分な制御が必要である。

H200は、すべての生成AIアプリケーションに自動的に最適な選択肢となるわけではありません。より小型のアクセラレータでモデルとアクティブコンテキストを問題なく収容できる場合、あるいはGPU運用を維持せずに多数のホスト型モデルを切り替える必要がある製品の場合は、マネージドモデルAPIのほうがよりシンプルな運用ベースラインになることがあります。重要なのは、生のハードウェア指標ではなく、自社のトラフィック形状における完了ワークロードのコストと信頼性を比較することです。

Nvidia H200 GPUアーキテクチャ：導入の選択を変える仕様

H200はNVIDIAのHopperアーキテクチャを採用しています。HopperにはTransformer Engineと第4世代NVLinkが含まれ、NVIDIAはこれらの機能を混合精度のTransformerワークロードおよびマルチGPU通信向けに位置付けています。Hopperアーキテクチャの概要では、ワークロードが単一アクセラレータを超えて拡張する際に、サーバートポロジが重要になる理由も説明されています。

出典：NVIDIA H200仕様。NVIDIAは、一部の公開性能値がスパース性を使用していると注記しています。これらの数値は本番スループットの保証ではなく、能力のリファレンスとして使用してください。

メモリ容量はマーケティング上の数値ではなく、導入変数である

LLMサービングでは、HBMを完全なワーキングセットに基づいて計画します。

必要なGPUメモリ ≈ モデルの重み
                    + ピークアクティブKVキャッシュ
                    + ランタイムワークスペース
                    + フラグメンテーションと安全マージン

モデルのチェックポイントは最初の項目にすぎません。正常にロードできる構成でも、提供しようとするアクティブなコンテキストウィンドウと同時シーケンスに対する余裕が不足している場合があります。そのため、モデルが技術的にはH100クラスの構成に収まる場合でも、H200の141 GB HBM3eは有用になり得ます。デプロイメントにおいて、バッチサイズ、コンテキスト長、同時実行性をレイテンシとの兼ね合いで調整するための余地が増えるためです。

キャパシティを予約する前に、次のワークロード入力を記録してください。

1. モデル、重み形式、および量子化または精度モード。
2. 実際のリクエストにおける最大入力トークン数と最大生成トークン数。
3. 想定される同時アクティブシーケンス数—リクエスト/秒だけではありません。
4. 最初のトークンまでの時間およびテールレイテンシを含むレイテンシSLO。
5. アプリケーションが単一のフルGPU、分離されたスライス、またはマルチGPUモデルレプリカのいずれを必要とするか。

最初のサイジング評価は、意図的に難しいプロンプトで実行してください。短いプロンプトのテストで正常に見えても、本番のコンテキスト長で発生するKVキャッシュの負荷を見落とす可能性があります。

帯域幅とトポロジは別個に確認する

自己回帰デコードおよびメモリ負荷の高いワークロードでは、メモリ帯域幅がコンピュートと同等以上に重要になる場合があります。モデルをシャーディングすると、GPU間帯域幅も重要になります。8基のH200 GPUに単一の共有1,128 GBメモリプールがあると想定しないでください。分散サービングソフトウェアは、実際に利用可能なリンクを介してテンソルを配置し、アクティベーションを交換する必要があります。

NVIDIAによると、第4世代NVLinkはDGXおよびHGXシステムでGPUあたり900 GB/sの双方向帯域幅を提供し、NVSwitchは8 GPUドメインをサポートします。そのため、1ノードのトポロジはマルチノードクラスタとは別に評価する価値があります。NVIDIAのHopperアーキテクチャのリファレンスはインターコネクト機能の情報源であり、実際に利用できるトポロジについてはクラウドプロバイダーのインスタンスドキュメントを参照してください。

H200 SXMとH200 NVL：インスタンスを選ぶ前にデプロイメント形態を選ぶ

「H200」は単一のサーバー設計を示すものではありません。一般的な2つのデプロイメント形態には、それぞれ異なる運用上の意味があります。

両フォームファクタは、NVIDIAの仕様表で141 GB HBM3eおよび4.8 TB/sのメモリ帯域幅を示しています。マルチGPUワークロードにおける差別化要因は、多くの場合、そのメモリを取り巻くサーバーとリンクのトポロジです。プロバイダーのトポロジ図と、インスタンス内でのトポロジ確認を必須の調達資料として扱ってください。

ワークロードからトポロジへの意思決定マトリクス

このマトリクスを使用して、最初のデプロイメント実験を決定してください。これはベンチマークの代替ではなく、出発点となる仮説です。

分散推論について、vLLMのドキュメントでは同じ基本的な進め方が示されています。モデルが収まる場合は1基のGPUを使用し、1ノード内に収まる場合はテンソル並列化を使用し、ノードをまたぐ必要がある場合はパイプライン並列化を追加します。正確なフラグとサポートされる戦略はvLLMのバージョンおよびモデルアーキテクチャによって異なるため、インストール済みのリリースで検証してください。vLLM distributed inference documentationを参照してください。

Nvidia H200 GPUワークロード向けクラウド導入プレイブック

最も安全なロールアウトは段階的なものです。各段階で、別の変動要因を追加する前に1つの問いに答えます。

1. ワークロード契約を作成する

プロビジョニング前にテストトラフィックを定義します。モデルバージョン、精度、入力および出力トークンの分布、同時実行数、サービスレベル目標、地理的配置、データ要件、コストベースラインを含めてください。小規模な固定回帰セットと、現実的なリプレイセットを維持します。

これにより、よくある誤りを防げます。すなわち、合成スループットテストでハードウェアを比較した後、選択した構成が、アプリケーションにとって重要な長いプロンプトまたはテールレイテンシ条件で失敗することが判明するという問題です。

2. モデルサーバーをデプロイする前にノードを検証する

インスタンスの起動後は、製品名に依存するのではなく、物理的な構成を特定します。

nvidia-smi topo -m
nvidia-smi topo -p2p n

NVIDIAは、トポロジーおよびNVLinkの挙動を診断する際にこれらの確認を推奨しています。NCCL performance and tuning guidanceでも、測定したGPU間帯域幅が想定されるハードウェアパスと一致するかを確認するために、nvbandwidthまたはnvloomを使用するよう案内されています。

トポロジーの出力を導入ランブックに記録してください。これにより、後から発生した性能低下を監査可能にできます。アプリケーションの変更と、PCIe、NVLink、またはネットワーク配置の違いを区別できます。

3. サポート対象のGPUソフトウェアスタックをインストールする

Kubernetesでは、ワークロードがGPUを要求できるようになる前に、クラスターにNVIDIAドライバー、コンテナランタイムの経路、ベンダーのデバイスプラグインが必要です。デバイスプラグインのインストール後、KubernetesはGPUをカスタムのスケジュール可能リソースとして公開します。Kubernetes’ GPU scheduling guideでは、混在するアクセラレータ群に対するリソースモデルと、ラベルまたはアフィニティの使用について説明しています。

NVIDIAのGPU Operatorは、GPUワーカーノード上で、ドライバー、NVIDIA Container Toolkit、デバイスプラグイン、DCGM Exporter、MIG Managerを統合されたスタックとして管理できます。最新のGPU Operator installation documentationを使用し、モデルサーバーを導入する前に、そのバリデーターおよびオペレーターのPodが正常であることを確認してください。

最小限のリソース要求は、概念的にはシンプルです。

resources:
  limits:
    nvidia.com/gpu: 4

Kubernetesでは、GPUは通常limitsで指定します。GPUリクエストも指定する場合、それは制限値と等しくなければなりません。レイテンシに敏感なH200サービスが意図しないアクセラレータプールにスケジュールされないよう、ノードラベル、アフィニティ、テイント、ワークロードクラストラベルを追加してください。

4. 1変数のサービングテストから始める

ワークロードを収容できる最小のトポロジーで、モデルレプリカを1つ起動します。単一ノード・マルチGPUのvLLMデプロイメントでは、テンソル並列サイズをレプリカに割り当てられたGPU数と一致させる必要があります。例：

vllm serve <model-identifier> \
  --tensor-parallel-size 4

これは意図的にトポロジーの例であり、そのままコピーして実行できる本番コマンドではありません。独自のデプロイメントマニフェストで、コンテナイメージ、ドライバー/CUDAの互換性、モデルリビジョン、トークナイザー、サービングエンジンのバージョンを固定してください。その後は、テンソル並列サイズ、最大アクティブシーケンス数、キャッシュ割り当てポリシー、レプリカ数のように、1度に1つの変数だけを変更します。

5. プリフィルとデコードを個別にテストする

トークンスループットは、ユーザーが体験するレイテンシ経路を隠す可能性があります。少なくとも以下を測定してください。

• 短い入力プロンプトと長い入力プロンプトにおける最初のトークンまでの時間。
• 最初のトークン後の出力トークンスループット。
• P50、P95、P99のエンドツーエンドレイテンシ。
• 使用済みGPUメモリ、キャッシュ負荷、メモリ不足イベント。
• キュー時間、リクエストのキャンセル、再試行、エラー率。

Nvidia H200 GPUは、より大容量かつ高速なメモリによってスケジューリングの余地を増やすため、制約のあるデプロイメントを改善できる可能性があります。しかし、その余地が実際にユーザー向けの有用な容量となるかどうかは、測定されたリクエスト構成によってのみ判断できます。

6. 可能な場合はノードを追加する前にレプリカを追加する

1台のH200ノードにモデルが収まり、レイテンシ目標を満たす場合、2台目のノードを導入するよりもレプリカを追加する方が運用上簡単になる可能性があります。ノードをまたぐ場合は、まずネットワークとコレクティブ通信の経路をテストしてください。マルチノード推論では、環境とモデルアーティファクトをノード間で一貫させます。コンテナ、ドライバー、モデルリビジョン、トークナイザーの不一致は、ハードウェアの問題のように見えることがあります。

トポロジーのベースラインを収集する前に、NCCLアルゴリズムの設定を強制しないでください。NVIDIAのNCCLドキュメントによれば、デフォルトの選択はトポロジーを認識しています。手動設定は測定された挙動への対応であり、測定の代替ではありません。

7. トラフィックに影響が及ぶ前にキャパシティを計測する

DCGM Exporterは、GPUテレメトリーをKubernetes監視スタックに公開できます。NVIDIAはこれをGPU Operatorで管理されるスタックの一部として文書化しており、DCGM Exporter documentationでPrometheus環境向けのインストールガイダンスを提供しています。

インフラストラクチャの健全性とサービス成果を結び付けるダッシュボードを構築します。

8. 障害時とメンテナンス時の挙動を計画する

H200の導入が本番対応といえるのは、復旧の手順がある場合に限られます。レプリカの再起動、ノードドレイン、モデルの再ロード、コールドキャッシュからの起動、アップストリームネットワークの中断をテストしてください。キャパシティが一時的に利用できない場合に何を行うかを定義します。キューイング、負荷の遮断、より小さいモデルへのルーティング、またはマネージドAPIへのフォールバックです。最適な選択肢は、製品に求められる正確性とレイテンシの要件によって異なります。

パフォーマンス：カタログではなくワークロードをベンチマークする

NVIDIAは、特定の比較においてLLM推論性能がより高いという主張を含め、H200の機能およびベンチマーク資料を公開しています。これらの結果はアクセラレータが実現できることを理解するのに役立ちますが、特定のモデル、コンテキスト長、量子化、サービングスタック、またはクラウドトポロジーでの性能を保証するものではありません。H200 datasheetは、テスト条件および脚注と併せて読む必要があります。

実用的なH200比較を行うには、次の変数を一定に保ちます。

1. モデルのリビジョン、トークナイザー、精度、量子化。
2. プロンプトおよび出力トークンの分布。
3. 同時実行性と受付制御ポリシー。
4. テンソル／パイプライン並列のレイアウトと実際のハードウェアトポロジー。
5. サービングエンジンとCUDA/NCCLのバージョン。
6. ウォームアップおよびキャッシュ状態を含むSLA測定方法。
7. クラウド料金の単位、およびストレージ、エグレス、CPU、運用などのGPU以外のコスト。

このテスト計画は、汎用的な「1秒あたりのトークン数」の比較よりも価値があります。なぜなら、Nvidia H200 GPUが顧客向けSLOまたは完了リクエストあたりのコストを変えるかどうかを判断できるためです。

H200導入チェックリスト

新しいH200ワークロードの公開判定基準として、このチェックリストを使用してください。

• [ ] モデル、精度、最大コンテキスト長、出力長、目標同時実行数を記録する。
• [ ] 重み、KVキャッシュ、ランタイムワークスペース、安全マージンのメモリ予算を計算する。
• [ ] 割り当てられたH200がSXMかNVLかを確認し、nvidia-smi topo -mを記録する。
• [ ] ドライバー、CUDA、コンテナ、フレームワーク、サービングエンジンの互換性を検証する。
• [ ] オーケストレーターで、配置制約とともに想定するGPU数をリクエストする。
• [ ] モデルをロードする前に、CUDA／オペレーターのヘルステストを実行する。
• [ ] マルチGPUの結果を採用する前に、トポロジーおよび集団通信帯域幅の検証を実行する。
• [ ] 短コンテキストと長コンテキストのトラフィックを分けて測定する。
• [ ] TTFT、出力トークンのスループット、P95/P99レイテンシ、キュー時間、エラー、GPUメモリを追跡する。
• [ ] 再起動、ノードドレイン、キャパシティ削減のシナリオをテストする。
• [ ] 同一のワークロードおよびSLOで、マネージドモデルAPIのベースラインと結果を比較する。
• [ ] 導入の決定とともに、トポロジー、ベンチマーク構成、コスト前提を保存する。

モデルAPIの方が適したクラウド導入となる場合

Nvidia H200 GPUを直接運用すると、モデルの重み、サービング構成、データ配置、キャパシティを制御できます。一方で、キャパシティ計画、トポロジー検証、可観測性、復旧に関する作業も増えます。これらの制御が意味のある製品上の優位性を生まない場合は、比較を公平に保ってください。同じ品質、レイテンシ、可用性、完了済みワークロードの指標で、マネージドモデルAPIを評価します。

Flatkeyは、個別のプロバイダー統合を維持せずに公式モデルAPIをテストまたは経路設定する必要があるチームにとって、そのようなベースラインの1つになり得ます。同社の製品概要では、モデルとツールをまたいで利用できる1つのAPIキーと残高について説明されています。適切な選択は、不要な運用負荷を最小限に抑えつつ、ワークロード要件を満たすものです。専用GPUキャパシティよりもルーティングされたAPIがワークロードに適している場合は、Flatkeyのモデルカタログを見るか、APIキーを取得するをご利用ください。

よくある質問

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

NVIDIAは、H200 GPU 1基あたり141 GBのHBM3eメモリと4.8 TB/sのメモリ帯域幅を示しています。これはアクセラレータ1基あたりの値であるため、モデルとアクティブキャッシュが単一GPUの実用的な余裕を超える場合は、分散サービング計画が依然として必要です。

H200は主に推論用GPUですか、それともトレーニング用GPUですか？

H200は、AIとHPCの両方のワークロード向けに位置付けられています。導入計画では、ラベルではなくワークロードを区別してください。長コンテキストLLMサービング、ファインチューニング、分散トレーニング、科学計算では、メモリ、通信、スケジューリングへの負荷がそれぞれ異なります。実際に運用するフレームワークとトポロジーでベンチマークを実施してください。

H200 SXMとH200 NVLの違いは何ですか？

これらは異なるH200のフォームファクタおよびサーバー統合パスです。NVIDIAは、HGXスタイルの4または8 GPU構成でNVLink接続を備えたSXMシステムを示している一方、H200 NVLは、ブリッジのオプションが文書化されたデュアルスロットPCIeフォームファクタです。同等のマルチGPU動作を想定する前に、クラウドプロバイダーの実際のトポロジーを確認してください。

KubernetesでH200ワークロードを実行できますか？

はい。クラスターに互換性のあるNVIDIAドライバー、コンテナランタイムのパス、デバイスプラグインがあることが前提です。KubernetesはGPUを拡張リソースとしてスケジューリングし、NVIDIA GPU OperatorはGPUソフトウェアスタックとテレメトリコンポーネントを管理できます。本番トラフィックを送る前に、ノードラベル、GPUリソースリクエスト、Operatorの健全性、アプリケーションレベルのSLOを検証してください。

H100ではなくH200を選ぶべきですか？

ボトルネックに基づいて選択してください。H200のより大きなHBM3e容量と、文書化されているより高いメモリ帯域幅は、メモリ制約のあるサービングで有用になる場合があります。ただし、より小規模なワークロードには、H100のほうが運用面または商用面でより適している可能性があります。同一のフォームファクタを比較し、両方の構成で同じワークロードを実行してください。判断の枠組みについては、当社のH200 vs. H100ガイドをご覧ください。

導入判断の再現性を確保する

メモリとトポロジーが真の制約である場合、H200のアーキテクチャは魅力的です。ワークロード契約、メモリ計画、ハードウェアトポロジー、ソフトウェアバージョン、負荷テスト結果をまとめて保存し、Nvidia H200 GPUの判断を再現可能にしてください。その記録があれば、次のエンジニアは導入が機能する理由を説明でき、機能しなくなった場合には何が変わったのかを特定できます。

次の計画ステップとして、コンピュート、ネットワーク、ストレージ、コントロールプレーンの設計についてはGPUクラスターアーキテクチャガイドを読み、テンソル並列およびパイプライン並列の設定についてはvLLMマルチGPU推論ガイドを参照してください。