Cost, Billing, and Ops2026年10月12日Flatkey Team

NVIDIA H200 対 H100: メモリ容量、スループット、コスト

AIチーム向けの実用的なH100対H200購入ガイド。メモリ容量、LLMスループット、学習への適性、クラウドGPU価格、完了ワークロードあたりのコストを比較します。

H100 と H200 を比較しているなら、短く言えばこうです。ワークロードがメモリ律速、長文コンテキスト、または 80GB の H100 に収まりにくい場合は、H200 のほうが適しています。容量がより安い、すでに入手可能である、あるいは追加の HBM3e があっても実行時間が短くならないほど計算律速である場合は、H100 が依然として実用的な基準です。

ただし、注意点はコストです。H200 はメモリが多いからといって自動的に安くなるわけではありません。141GB の大きなメモリプール、4.8TB/s のメモリ帯域幅、またはより大きなバッチサイズによって、少ない GPU、少ないレプリカ、量子化上の妥協の減少、失敗実行の減少でジョブを終えられるときに、H200 が優位になります。

H100 と H200: 迅速な判断

H200 を選ぶのは次のような場合です:

モデル、コンテキスト長、KV キャッシュ、またはバッチ目標が 80GB の H100 の上限に近い。
生の Tensor Core のピーク性能よりも、メモリ帯域幅とバッチサイズが重要な LLM 推論を提供している。
70B クラスの推論、長いプロンプトを伴う RAG、高並列サービスのために、Tensor Parallel の分割数を減らしたい。
H200 のレンタルプレミアムが、GPU 台数の削減、受け入れ可能なスループットの向上、または運用の簡素化による節約額より小さい。

H100 を選ぶのは次のような場合です:

ワークロードが、アクティベーション、KV キャッシュ、オプティマイザ状態、またはサービングのオーバーヘッドに余裕を持って 80GB にきれいに収まる。
入手可能な容量、成熟したイメージ、既知のクラスタ挙動、またはより低い時間単価を重視して最適化している。
ボトルネックが GPU メモリではなく、CPU 前処理、ストレージ、ネットワーク、キューイング、ソフトウェアのオーバーヘッド、またはモデル品質にある。
H200 よりもはるかに良い実効価格で H100 SXM または NVL を調達できる。

多くの AI チームにとって、最初の判断基準はベンチマークの順位表ではありません。次の問いです。H200 は、H100 より通常は広く利用できるという利点を上回るほど、GPU 台数、精度の妥協、または待ち時間を減らせるでしょうか。

注目すべき NVIDIA H200 と H100 の仕様

NVIDIA は H200 を、より大きくより高速なメモリに焦点を当てた Hopper 世代のアップグレードとして位置付けています。H200 の製品ページには 141GB の HBM3e メモリと 4.8TB/s のメモリ帯域幅が記載されています。NVIDIA の H100 ページには、H100 SXM が 80GB の HBM3 メモリと 3.35TB/s のメモリ帯域幅、H100 NVL が 94GB と 3.9TB/s であることが記載されています。

仕様	NVIDIA H200 SXM / HGX	NVIDIA H100 SXM	NVIDIA H100 NVL
GPU 世代	Hopper	Hopper	Hopper
GPU メモリ	141GB HBM3e	80GB HBM3	94GB HBM3
メモリ帯域幅	4.8TB/s	3.35TB/s	3.9TB/s
最適なワークロード	メモリ負荷の高い LLM 推論、大きなバッチ、長いコンテキスト、HPC のメモリ圧迫	成熟した学習・推論の基準構成	空冷 / PCIe 向けの LLM サービング
実務上の購入判断	追加メモリで GPU 台数や再試行が減るか?	より安価で入手可能な基準構成で十分か?	NVL のメモリ / 相互接続がサーバー設計に合うか?

これらのメモリ差が、nvidia h200 vs h100 比較の核心です。H200 は H100 SXM より約 76% 多く、H100 NVL より約 43% 多いメモリを備えています。帯域幅は H100 SXM より約 43% 高く、H100 NVL より約 23% 高くなっています。

これは、すべてのジョブが 23〜76% 速くなるという意味ではありません。メモリサブシステムが、H200 により大きなワーキングセットを GPU 上に保持し、計算コアに供給する余地を与えるということです。性能向上は、モデルサイズ、コンテキスト長、精度、サービングフレームワーク、バッチ戦略、相互接続、そして実際にワークロードがメモリ律速かどうかに依存します。

H200 と H100 のメモリ: 141GB が LLM サービングをどう変えるか

h200 vs h100 memory という表現は、たいてい次のような厄介なトレードオフを避けようとしている場面で登場します:

出力品質を損なう過度な量子化、
チームが運用したくないほど多い Tensor Parallel 分割、
サービング容量を無駄にする小さなバッチ、
製品に必要なものより短いコンテキストウィンドウ、
あるいは、実際のプロンプトがベンチマークのプロンプトより大きい場合のジョブ失敗です。

H100 の 80GB 構成は、多くの推論やファインチューニングのジョブに対して依然として強力です。しかし、モデル重み、KV キャッシュ、フレームワークのオーバーヘッド、Speculative Decoding のバッファ、アダプタ、埋め込み、同時リクエストを加えると、80GB はすぐに埋まってしまいます。

H200 の 141GB メモリは、インフラチームにより多くの選択肢を与えます。複数の H100 でしか収まらないモデルが、より少ない H200 で収まるかもしれません。H100 ではコンテキストを短く保たなければならないサービング階層が、H200 ではより長いリクエストを処理できるかもしれません。H100 では小さなマイクロバッチに溢れていた学習やファインチューニングのジョブが、H200 ではより効率的なバッチ設定を使えるかもしれません。

そのため、h100 vs h200 の判断は、GPU の時間単価だけでなく、完了した作業を基準にモデル化すべきです。

NVIDIA H200 と H100 の性能比較

nvidia h200 vs h100 performance comparison では、3 つの場合に分けて考えます。

1. メモリ律速の LLM 推論

これが H200 にとって最も分かりやすいケースです。NVIDIA は、H200 のより大きな HBM3e メモリと 4.8TB/s の帯域幅が生成 AI と LLM ワークロードを加速するために設計されており、指定されたバッチおよびシーケンス設定の下で H100 より高い Llama 2 および GPT 系の推論スループット例をページ上で示していると述べています。

まず H200 を使うべきなのは次の用途です:

70B クラスのモデル提供、
長文コンテキストの RAG、
高バッチのデコードワークロード、
大きな KV キャッシュ圧力があるサービング経路、
失敗や性能低下したリクエストが高くつく製品ワークロード。

ただし、NVIDIA の例の倍率をそのまま自社の予測に転用してはいけません。改善幅は、プロンプト長、出力長、バッチサイズ、量子化、エンジン設定、そして H100 の基準構成がすでに最適化されていたかどうかに依存します。

2. トレーニングとファインチューニング

H100 は、広く導入されており、サポートが充実していて、成熟したマネージドクラウドおよび専用クラスタ構成で利用できるため、トレーニングクラスタの強力なデフォルトとして引き続き有力です。H200 は、メモリ圧迫によってマイクロバッチサイズ、シーケンス長、アクティベーションチェックポイントの選択、またはオプティマイザ戦略が制限される場合に役立つことがあります。

フルトレーニングでは、判断基準は単一 GPU というよりクラスタの構成になることが多いです。

ノードごとの GPU 数、
NVLink/NVSwitch トポロジ、
ノード間ネットワーク、
ストレージのスループット、
チェックポイント保存時間、
フレームワークの成熟度、
および予約可用性。

あるトレーニング実行がすでに H100 上で問題なくスケールし、メモリ圧迫にも直面していないなら、H200 の上乗せコストは正当化されないかもしれません。H200 によって追加の並列化を回避でき、再計算を避けられ、失敗実行を減らせるなら、経済性は逆転し得ます。

3. 計算性能ボトルネックまたはパイプラインボトルネックのジョブ

中には、追加メモリをあまり気にしないジョブもあります。前処理、データ読み込み、CPU 変換、オブジェクトストレージ、ネットワーク転送、あるいはアプリケーションのオーケストレーションがボトルネックなら、H200 も H100 と同様にアイドル状態になり得ます。

H200 に料金を払う前に、次をプロファイルしてください。

GPU 利用率、
割り当て済みおよび予約済みメモリ、
HBM 帯域幅の利用率、
1 秒あたりのトークン数、
1 分あたりの受理リクエスト数、
キュー待ち時間、
失敗/再試行率、
および受理された出力 1 件あたりのコスト。

メモリのグラフが横ばいで、パイプラインが別の場所で待機しているなら、通常は H100 の方が安全な選択です。

コスト: 完了したワークロードごとに H200 と H100 を比較する

GPU のレンタル価格は急速に変動し、マーケットプレイスの在庫状況も地域と時期によって変わります。以下は、2026 年 10 月 12 日時点で確認したソースページのスナップショットとして扱い、永続的な価格保証とは考えないでください。

RunPod の価格ページでは、H200 は Community Cloud で $3.59/時、Secure Cloud で $4.59/時と記載されていました。同じページには、H100 PCIe が community で $1.99/時、secure で $2.89/時、H100 SXM が community で $2.69/時、secure で $3.49/時、さらに H100 NVL が community で $2.59/時、secure で $3.19/時と記載されていました。

Lambda の価格ページでは、1x H100 SXM が $4.29/GPU/時、1x H100 PCIe が $3.29/GPU/時と記載され、より大きなノード数では GPU あたりの H100 SXM クラスタ例の価格が低くなっていました。この記事で使用したページスナップショットでは、Lambda の公開表に対応する H200 のオンデマンド行は表示されていませんでした。

AWS の P5 ファミリーページは、導入コンテキストとして有用です。そこでは、P5、P5e、P5en を大規模 ML トレーニング、推論、HPC 向けの NVIDIA H100 および H200 インスタンスファミリーとして提示しており、P5e では 1 p5e.48xlarge インスタンスあたり 8 基の H200 GPU と 1,128GB の HBM3e を提供しています。予算検討では、モデルにどの数値を使う場合でも、正確な AWS リージョン、購入オプション、サポートプランを必ず確認してください。

実務向けのワークシートは次のとおりです。

完了したワークロードのコスト =
  時間あたりの GPU 価格
  x GPU 数
  x 実時間
  + ストレージ
  + ネットワーク egress
  + アイドル/キュー待ち時間
  + 失敗実行と再試行のコスト
  + シャーディング、量子化、デバッグのためのエンジニアリング時間

H200 は時間単価が高くても、GPU 数を削減し、シャーディングの複雑さを減らし、受理スループットを向上させ、メモリ起因の失敗を防げるなら勝つことがあります。H100 は、ジョブがきれいに収まり、H200 のプレミアムが完了ワークロードの計算結果を変えない場合に、より安価になります。

より完全なコスト用ワークシートについては、関連する Flatkey のGPU レンタル価格ガイドを参照してください。

ワークロード別の推奨

ワークロード	より良いデフォルト	理由
長いプロンプトを伴う 70B LLM 推論	H200	より大きなメモリと帯域幅により、より大きな KV キャッシュ、より大きなバッチ、またはより少ないシャードを支えられます。
中程度のコンテキストを伴う 7B-34B 推論	H100	多くのジョブは余裕をもって収まり、H100 の容量の方が通常は調達しやすいです。
高並行チャットサービング	両方をテストする	H200 はレプリカあたりの 1 秒当たりトークン数を改善する可能性があり、H100 は価格と可用性で優位になるかもしれません。
フルモデルトレーニング	まず H100、メモリ制約があるなら H200	H100 クラスタは成熟しています。H200 はメモリがバッチ/シーケンス戦略を制限する場合に役立ちます。
ファインチューニング / LoRA	ほとんどのジョブでは H100	H200 が役立つのは、シーケンス長、バッチ、またはベースモデルサイズがメモリ制限に達する場合だけです。
メモリ負荷の高い HPC	H200	141GB と 4.8TB/s が、H200 に料金を払う主な理由です。
開発とデバッグ	H100 またはより安価な GPU	ワークロードの形が分かる前に H200 を使うのは、通常は無駄です。

H100 対 H200 のシンプルなテスト計画

予約済みクラスタにコミットする前に、同じ実ワークロードを両方の GPU タイプで実行してください。合成ベンチマークは方向性をつかむのに有用ですが、購入判断は本番相当のプロンプト、バッチ設定、失敗ルールを使って行うべきです。

目標成果を定義する。 1秒あたりのトークン数、1日あたりに完了したジョブ数、承認された回答1件あたりのコスト、学習ステップあたりのコスト、または目標品質に到達するまでの壁時計時間を使う。
本番サイズの入力を使う。 実際のプロンプト長、検索コンテキスト、出力長、バッチのばらつき、同時実行数を含める。
モデル品質を一定に保つ。 収めるためだけに、一方のGPUに低品質な量子化を使わせてはいけない。
GPU数と稼働率を測定する。 単一のH200が、いくつかの提供階層では複数のH100を上回ることがある。一方、安価なH100が、小規模モデルでは十分に使われていないH200を上回ることもある。
再試行とメモリ失敗を追跡する。 メモリ不足の再試行、より小さなバッチ、緊急のシャーディングは、実際のコストである。
アイドル時間を含める。 数時間キューで待つ安価なH100は、すぐ使えるH200に負けることがある。
時間帯をまたいで繰り返す。 マーケットプレイスの価格と供給能力は、平日のピーク時とオフ時間で変動することがある。

Flatkeyのより広いコスト指針は、GPUとモデルAPIで同じである。つまり、表示上の単価だけでなく、承認された結果を生み出す経路を比較することだ。同じ考え方は、AIモデル価格比較、AI API価格比較、およびAIモデル価格をプロバイダー切り替え前に比較する方法にも当てはまる。

モデルAPIがどちらのGPUよりも優れている場合

H200 vs H100 の判断は、GPUを直接管理する必要があることを前提としている。だが、それが常に正しいとは限らない。

次のような場合は、GPUを借りる代わりにホスト型モデルAPIまたはルーターを使うべきだ。

トラフィックがバースト的である、
モデル選択が頻繁に変わる、
1つの固定されたオープンウェイトモデルではなく複数のプロバイダーが必要、
絶対的なGPU稼働率より運用工数のほうが重要、
または、リクエストごとの使用ログ、予算管理、フェイルオーバーが必要。

Flatkeyはその判断のもう一方に向けて作られている。1つのキー、1つの残高、1つの請求書、公式モデルエンドポイント、リクエスト単位の使用ログ、そして複数のモデルプロバイダーにまたがるルーティングを提供する。最先端モデルやホスト型オープンモデルの出力だけが必要なチームにとって、モデルAPIはGPUの遊休コストと運用オーバーヘッドを避けられる。一方、独自重みを持つモデルを継続的な負荷で提供するチームにとっては、直接のH100またはH200容量が依然として適切なインフラ層かもしれない。

最終推奨

H100 vs H200 では、メモリがボトルネックで、より大きなGPUがワークロードの形を変える場合はH200を購入またはレンタルする。H200が最適なケースは、長文コンテキストのLLM推論、70B級の提供、メモリ集約型HPC、そして141GBのHBM3eによってGPU数を減らせる、または提供アーキテクチャをより単純にできるあらゆる経路である。

ワークロードに収まり、可用性が重要で、価格差が実際にあるならH100を使う。H100は、成熟した学習スタック、開発、中程度のコンテキストの推論、そしてすでに稼働率プロファイルを把握しているチームにとって、依然としてより安全な既定値である。

判断基準は「どちらのGPUが速いか」ではない。メモリ適合、スループット、待ち行列時間、再試行、そしてエンジニアリングの複雑さを踏まえた、承認された結果1件あたりのコストである。