高火力 PHY B200で、H100の4倍の費用対効果を得る方法

株式会社フィックスターズでパフォーマンスエンジニアリングラボ長を務めている吉藤です。フィックスターズでは、以前よりさくらインターネット様と高火力 PHYを使った共同研究開発とビジネス協業を推進しており、最近ではH200を使った検証やH100x8ノードの検証を実施しました。

今回、さくらインターネット様が新しく提供開始したB200プランについて、その実力を検証する機会を得ることができましたので、本記事ではその検証結果をご紹介します。

TL;DR:
背景
B200の性能特性：前世代の約2倍高性能なハードウェア
事前準備
まずは計測指標を定義する：「費用対効果」とは
事例1：（継続）事前学習
実践2：巨大推論
まとめ

TL;DR:

B200という新しいハードウェアを利用するため、そのハードウェアに合わせたバージョン選定と環境構築を実施しました。
B200の1ノードは、H100の2ノード構成に比べて、費用対効果が、LLM事前学習で4倍、巨大モデル推論で1.3倍良いという結果となりました。
この向上は、B200がH100に比べて「全体的に約2倍になったハードウェア性能向上」をうまく使うことによって得られたものです。
今回構築したB200向けAI処理用環境は、Fixstars AIBoosterのinfra機能で提供されています。高火力 PHY B200プランをご利用の方はAIBoosterの本機能を使用することでAI処理をすぐに始められます。

背景

H200の記事でも述べた通り、近年のAI、特に大規模言語モデル（LLM）の進化は凄まじく、モデルサイズは増大の一途をたどっています。一方、多くのAI開発現場では、GPUのメモリ上限のせいで性能が詰まってしまう「メモリ律速」が常態化しており、これが新たな技術的挑戦の足かせとなっています。

特に昨今はAI活用の方向性が、既存の巨大モデルを使う時代から、マルチエージェントシステムを使いこなす時代へと移行しつつあります。この流れにおいて確実視されているのが「小-中規模モデルを自社のニーズに合わせて作ってチューニングし、エージェントとして利用する」時代の到来です。

そのような時代になると、より高性能な計算（学習と推論）の需要が高まってくると予想されます。この需要を満たすために登場したのが、高火力 PHY B200プランです。

B200の性能特性：前世代の約2倍高性能なハードウェア

今回サービスの提供が開始されたB200プラン（正確にはSec.Fモデル）では、前世代のHopperアーキテクチャ(NVIDIA H100/H200)からの正統進化であるNVIDIA B200が利用できます。

ここで、H100, H200, B200のハードウェア性能を抜粋して比較してみると、以下のようになります。

	H100 SXM	H200 SXM	B200
TF32 TensorCore演算速度 [TFLOP/s]	495	495	1100
FP/BF16 TensorCore演算速度 [TFLOP/s]	989	989	2200
FP8 TensorCore演算速度 [TFLOP/s]	1979	1979	4500
メモリ帯域 [TB/s]	3.4	4.8	8.0
ノード内GPU間通信速度[GB/s]	900	900	1800
メモリ容量 [GB]	80	141	192
FP4 TensorCore演算速度 [TFLOP/s]	なし	なし	9000

なお、B200 SXM単体の性能は公式には公表されていませんが、HGXシステムの1GPUあたりの性能がほぼそのまま該当すると考えられるため、その値を記載しました。また、TensorCoreの性能については、学習用途を念頭に疎性なしの値を記載しています。

このように、

TensorCore演算速度は概ね2倍以上
メモリ帯域やGPU間通信速度も2倍
メモリ容量もH100比で2倍以上（※H200比だと1.4倍弱）

と概ねハードウェア性能は2倍になったと言えるでしょう。これは、B200のハードウェア実装が、概ねH100を2つ結合して1つにパッケージングしたような形になっていることに起因します。また注目すべきはFP4(INT4)演算器が搭載されたことで、これはHopper世代にはなかった新機能になります。

このように、B200とは、前世代から

約2倍の性能向上
4bit演算器の新機能追加

の2点が改良されたものととらえれば良いでしょう。

本記事では、高火力 PHY B200プランを用いた検証を進めてご紹介します。

ただし、今回用いた環境は、実際のサービス開始前の先行検証機でした。一部の利便性が未提供なこと以外は、同じ機体・品質・性能であるはずですが、わずかに本番環境とは異なる部分がある可能性もあります。今後、サービス提供機体を使う機会があれば、遜色ない結果であることを確認したいと思います。

事前準備

B200を実際に高火力 PHYで使うためには、B200用の環境構築が必要です。この環境構築をうまくできないと、処理速度の低下や動作不具合などを引き起こす可能性があります。

特に今回はハードウェアが更新され、しかもアーキテクチャがHopperからBlackwellに更新されたものになっている点に注意が必要です。
このような状況の時、特に処理速度の点を考慮したパフォーマンスエンジニアリングの観点からは「新しいものの方がより高速化を期待できる」という経験則があります。一方で、最近の複雑なAI処理においては各ソフトウェアのバージョンは複雑に絡み合っており、「なにか一つを不用意に変更すると、どこかでバージョン不一致が起きて動作しなくなる」ということがおきます。そのためB200の性能を最大限に引き出す各種ソフトウェアの組み合わせは真剣に見極める必要があります。

B200の性能を活かす環境構築：各種ソフトウェアのバージョン選定

AI処理のソフトウェアのバージョンと一言で言ってもいろいろあり、どこを考慮すべきか迷います。フィックスターズでは、自動的に依存関係を解決してくれないだろう部分を切り離し、大きく4段に分けてバージョンを選定しています。今回の結果は以下のようになりました。

AI処理フレームワーク(Megatron-LM)：core_v0.13.1
PyTorch：2.8.0
CUDA：12.9
GPUドライバ：R575.57.08

なお、今回選定したバージョンが、必ずしも全てのAI処理において適切とは限らないことに注意してください。次節より、今回の検証における各バージョン選定の理由と、実際に業務でパフォーマンスを最大化する環境構築のためのバージョン選定の指針について解説します。

バージョン選定の方針

まず、（AI処理に限らず）ソフトウェアのバージョン選定は、「どのような処理をしたいか」の定義から始める必要があります。例えば、

すでに実績のあるこの学習スクリプトをなるべくそのまま動作させて短時間で移行を済ませたい
新しい機能を使ってなるべく良い環境にしたい

などがあるでしょう。今回については、B200の性能を引き出すことが目的のため、後者に近い考え方でバージョン選定をしました。

やりたいことが決まれば、先にあげた4段のうち一番上の「AI処理フレームワーク」のバージョンから順に下方向に決めていくのが基本方針になります。なぜなら、上段の方がアプリケーション層に近く、最上位のバージョンがもっとも「やりたいこと」に強く影響するからです。残りの3段は、基本的に上が決まれば決められるようになります。

AI処理フレームワークのバージョン選定

まずはAI処理フレームワークのバージョンを決めます。

今回は後述するようにMegatron-LMを用いるため、そのバージョンをいくつにするかという点を考えます。なるべく最新版を使ったほうが最新機能による高性能で良い結果を得られそうな一方で、Megatron-LMのような最新鋭のAIフレームワークの進歩は激しく、何の準備もなしにバージョン更新をすると期待した動作ができなくなることがあります（インターフェースが変わることはもちろん、内部動作が変わってしまうなど）。そのため特別な事情がない限りは、バージョン更新には慎重になる必要があります。

そのような観点から、これまでH100およびH200では、Megatron-LMのバージョンをcore_v0.8.0に固定してきました。バージョン自体は今日ではかなり古くなってしまっていますが、このバージョンであれば確実に動作する学習スクリプトと手順が手元にあり、特にベンチマークや動作確認を取ることを考えれば、無理してバージョンを上げる必要がなかったからです。

しかし、先述の通り今回はB200の機能のフル活用が目的であることを考えると、多少のリスクを背負ってでも最新バージョンを使うことで性能改善を取り込める可能性が高いです。そのため、今回は思い切って検証時点で最新であったcore_v0.13.1を使うことにしました。結果的にこのバージョンで動作させることが叶ったため良かったです。繰り返しますが、最新バージョンを使う判断は慎重に行うべきで、一歩間違えれば時間切れで「なんの成果も！！得られませんでした！！」と叫ばなければならない状況にもなりうるのでご注意ください。

ひとまず最上段のバージョン選定は終わったので、次の2段目の選定に移ります。

PyTorchのバージョン選定

現在、ほとんどのAI処理フレームワークはPyTorchの上に構築されていると言っても過言ではありません。そして、各AI処理フレームワークは「特定のバージョンのPyTorch」を前提に繊細に積み上げられていることが多いです。

例えば今回用いるMegatron-LMは、各バージョンによって使うべきPyTorch NGC Containerのバージョンが異なります。そして、そのコンテナ内にインストールされているPyTorchのバージョンが固定されています。ということは、使いたいMegatron-LMのバージョンによって、PyTorchのバージョンが変化するわけです。このように、AI処理フレームワークのバージョンとPyTorchのバージョンは密結合しており、PyTorchのバージョン選定が2段目として次に重要になっているのです。

今回は先述の通りMegatron-LMのcore_v0.13.1にしました。この時のコンテナのバージョンはREADMEによると、nvcr.io/nvidia/pytorch:25.04-py3でした。そのバージョンのリリースノートによると、PyTorchのバージョンは2.7.0a0+79aa17489cとのことでした。

ただ、PyTorchを標準的な方法(pip install)でインストールしようとした場合、PyTorchの公式レポジトリにはそのような細かい指定ができるバージョンは用意されていません。配布されているバージョンではv2.7.0かその次のv2.7.1が一番近く、または先述のように「新しいものほどよい可能性がある」事を考えて、この時点で最新版であったv2.8.0も選択肢でした。

最終的に選んだバージョンはv2.8.0です。その理由は後述しますが、CUDAのバージョンを12.9にしたためで、v2.7系にはCUDA 12.9でビルドされたパッケージがなかったためです。

CUDAのバージョン選定

PyTorchでB200のようなGPUを利用するには、そのPyTorchがCUDAを利用するようにビルドされたものが必要となります。そしてそのCUDAにもバージョンが複数あるので、つまり、CUDAのバージョンはPyTorchがビルドされたバージョンに合わせなければなりません。

今回、PyTorchはpip installで公式レポジトリからインストールする予定のため、公式がビルドして提供しているCUDAバージョンから選んで使う必要があります。ただし、当然のことながら、PyTorchのレポジトリにあらゆるバージョンが用意されているわけではありません。PyTorch公式レポジトリでは提供範囲がかなり限られており、概ね3つのバージョンだけが用意されています。もしどうしてもそのバージョンから外れたものをどうしても使いたければ、PyTorchのような巨大なフレームワークを自力ビルドするという苦行を超える必要があり、よほど特殊な事情がなければ現実的ではありません。

今回のPyTorchは先述の通りv2.7.0かv2.7.1が最有力候補でしたので、用意されているCUDAのバージョンは11.8、12.6、12.8の3種類でした。そこで12.8というのが最初の選択肢となりました。

ただ一方で、先述のPyTorch NGC Containerを見てみたところ、そちらのCUDAバージョンは12.9でした。PyTorch公式レポジトリにはありませんが、NVIDIAが自力ビルドをして用意してくれたものだと推察されます。もしCUDA 12.9を使う場合は、公式レポジトリに用意があるPyTorchのバージョンはv2.8.0になります。

つまりPyTorch v2.7系＋CUDA 12.8か、v2.8系＋12.9のどちらかを選択する必要があります。今回については、最初に述べた通りB200という新しいハードウェアであることも考慮して「最新のものを使うと速くなる可能性が高まる」ことを期待し、CUDA 12.9を選択しました。

GPUドライバのバージョン選定

そして最後に、特定のバージョンのCUDAを利用するには、特定のバージョンのGPUドライバが必要になります。ただし、GPUドライバについては、ここまでの3段とは違い、いくつか特別に考慮するべき点があり、かなり慎重な選定が必要になります。

まず最初に注意すべきは、NVIDIAのGPUドライバは基本的に後方互換性がないことです。つまり、新しいバージョンのドライバ上では、古いバージョンのCUDAは動きません。一方で、その逆はできて、古いバージョンのドライバで新しいバージョンのCUDAはcuda-compat-XXというパッケージを入れることで動作します。

ということを考慮すると、以下の2つの要件が相反することになります。

フレームワーク→PyTorch→CUDAという上段からのバージョン指定に従うなら、できるだけ広い範囲のバージョンのソフトウェアたちとそれに対応するCUDAを使うべく、ドライバはなるべく古く広く使えるものが望ましい。
B200のような新しいGPUは古いドライバでは動作しないため、最低限B200が動作するバージョンのドライバでなければならない。特に最新GPUではドライバの更新によってバグや性能が改善されることも多々あるため、可能であれば新しいバージョンのドライバを使いたい。

また、GPUドライバの選択をさらに難しくしているのは、これまでに選定してきたCUDA以上のソフトウェアとは異なり、GPUドライバだけはコンテナに分離してコンテナごとに使い分けたりできない点です。つまり、常に1つのホストには1つのバージョンしか入れられず、各個人が使いたい上位のソフトウェアに合わせて好きに選ぶことはできません。そのため、先のような相反する要求の天秤が釣り合うバージョンを、ただ1つだけ決めて、その1バージョンを全員が使えるように選ぶ必要があるのです。

今回は、B200という新しいハードウェアであることを考慮し、他のバージョン選定と合わせて可能な限り新しいものを使って性能を引き出す要求を優先し、R575.57.08を導入することにしました。

なお、この時点でドライバの最新バージョンはR580.65.06でした。しかし、このバージョンはCUDA 13系しか使えず、できるだけ広い範囲のソフトウェアを使用したいという要件にそぐわないことになります。PyTorch公式レポジトリで提供されているCUDA 12.9でビルドしたPyTorchを使おうとすると、ドライバの最新バージョンであるR580は使えないということです。今後、PyTorchの公式レポジトリが更新され、CUDA 13系に対応したバージョンが提供されるようになれば、R580の導入も視野に入れられるでしょう。

ところで今回のように検証ではない、実運用においては、もうひとつ全く別の観点で気をつけるべきことがあります。それはバージョンのサポート期限です。公式ページに解説されている通り、GPUドライバには以下の3つの種類があるのです。

NFB（新機能版）：新しく革新的な機能追加がされるバージョンで、今回選択したR575はこれにあたります。最新機能が使えることもあり今回導入しましたが、反面、サポート期間は3ヶ月間しかなく、以降はバグ修正やセキュリティパッチなども提供されなくなるので、安定性が必要な実務上の環境構築には適していません。
PB（製品版）：実務に耐えることができると考えられるバージョンで、今回選択したバージョンの1つ前のR570がこれにあたります。サポート期限も1年あって、その間はバグ修正などが提供されます。実はB200の最低サポートバージョンというだけなら、このR570でも利用できるので、PyTorchを公式レポジトリから使う業務をする場合には、このPBであるR570を使うのが今日時点ではオススメではあります。
LTSB（長期間サポート版）：3年間という長期間サポートされるものなので、先述の「幅広いCUDAバージョンを使いたい」場合にはこのLTSBを使うのがもっとも効果的ではあります。現時点ではR535またはR580がこれに該当します。ただしR535はB200がサポートされておらず、またR580は先述の通りPyTorchが未対応のため、今回はどちらのLTSBも使うことができませんでした。PyTorchがCUDA 13以降を提供するようになれば、B200を使った実務ではR580のドライバを使うのが将来的には良い塩梅となるでしょう。

事前準備のまとめ

実際に検証に入る前に、ここまでの知識と作業のおさらいです。

B200は、前世代に比べて約2倍の性能向上があり、4bit演算器の新機能を追加している。
B200の性能を最大限引き出すためのバージョン選定とその導入を実施。

それでは、実際に検証の作業に入っていきましょう。

まずは計測指標を定義する：「費用対効果」とは

実際の検証作業に入る前に行っておくべき、重要なことがあります。それは、パフォーマンスエンジニアリングにおいて大切なことの1つである、定量的に改善効果を計測することです。まずは何をもって、性能を評価するのかを決めましょう。

今回は、費用対効果の観点でB200を評価することとしました。具体的な改善に入る前に、この「費用対効果」についてしっかり定義する必要があるので、先にここで解説します。

純粋な「はやさ」だけであれば、AIにおいては学習スループット[itr/s]や推論生成スループット[token/s]、あるいは演算スループット[FLOP/s]などで計測できます。しかし、AIの性能評価においては、単なるスループットだけでは、真の価値を測ることはできません。なぜなら、AIの処理は「ただ速く終われば良い」のではなく、「与えられた資源（時間、費用）で、どれだけ質の高い成果を生み出したか」が本質的な評価基準となるからです。

そこで本記事では「同じ資源量で、価値が何倍向上したか」を費用対効果の改善量としました。具体的には、

H100/200は2ノード、B200は1ノードとする：これは先述の通りB200がハードウェア的に性能が単純に2倍であることと、それに伴い費用が概ね2倍になるという推定により、資源量を同じにするには2ノードと1ノードの比較が妥当と判断しました
価値は以下の3指標の掛け算とする
- 大きさ：モデルの扱える情報量（LLMでは系列長）が2倍であれば、2倍の価値
- 精度の良さ：処理した時に得られた精度が2倍良い、あるいは同じ精度に達するために必要な計算回数が半分になった場合、2倍の価値
- 速さ：スループットが2倍であれば、2倍の価値

最後の3つの価値指標については、厳密に言えば、例えば「精度が2倍である価値」と「速さが2倍である価値」を等しく扱ってよいのか、議論の余地があります。実際には、目の前で「精度が悪くて困っている」場合には速さより精度、「遅くて困っている」場合には精度より速さのほうが価値が高くなるはずです。このように実際の価値は、ユーザーの課題やニーズによって変化することに注意が必要です。

ただし今回は検証そのものが目的のため、ベンチマーク的に一律のものとして扱いました。実際の業務でAI処理の費用対効果を比べる際は、業務内容と目的に合わせて算出指標を設計してください。

事例1：（継続）事前学習

最初の題材として、H100、H200の検証でも用いた「Megatron-LMを用いたLlama3 70Bの（継続）事前学習」を対象に、費用対効果を計測してみました。

事前学習における費用対効果の3指標

この事例において、価値の3指標は具体的にはそれぞれ以下のようになります。

大きさ＝学習時の系列長：系列長を長くしてモデルを学習することは、単に処理負荷が増えるだけでなく、より多くの文脈を一度に読み込めるため、より複雑な指示を理解し、質の高い応答を生成する能力に直結します。ここでは、多くの実タスクにおいて系列長が2倍になれば、後工程の作業削減などを含め、実質的な価値もそのまま2倍に相当すると考えます。
精度の良さ＝損失曲線において同じ損失値になるまでに要した反復回数：H200記事でも解説した通り、1回の反復でモデルが「もっと良くなる」のであれば、それは計算の効率が向上しており、より短時間で良いモデルを作るという価値となります。ここでは単に、同じ損失値になる反復回数が半分になったのであれば、それは2倍の価値として換算します。
速さ＝演算スループット[FLOP/s]：今回も以前と同じく実際の数値比較には演算スループットを用います。本来は学習スループット[itr/s]も比較したかったのですが、時間の制約もあり未計測であることと、以前までの結果で演算スループットと学習スループットはほぼ線形に正相関することが分かっているため、今回は演算スループットが2倍速くなれば、2倍の価値として考えます。

B200での事前学習の結果：826[TFLOP/s/GPU]

次に改善方法についてですが、まず大きさと精度を向上させるため、以下の設定としました。

系列長＝8K：以前までの結果では系列長を4Kにしてメモリ消費量を抑える必要がありました。しかし今回B200ではメモリ容量が増えたため、長くすることに成功しました。
最適化器＝AdamW：これはH200の記事の時に解説した通り、反復回数を直接的に改善するものです。潤沢なメモリ容量を背景に、今回はSGD-SaIからAdamWに改善することができました。

次に、速さに関する設定のうち、以下の2つは以前の計算から、メモリ容量に余裕さえあれば確実に速くなることがわかっていたため、決め打ちとしました。

活性値再計算＝なし：再計算をしないとメモリ消費量が増えますが、今回は容量に余裕があることから再計算を実施しないことで速度を向上させました。
演算器幅＝fp8：Megatron-LMの実装上の都合で16bitの方がメモリ消費量が抑えられますが、今回は余裕があるためfp8を採用することができました。

残るは、並列数とマイクロバッチサイズです。

マイクロバッチサイズ(MBS)：GPUが一度に学習処理するサンプル数。多いほうが計算効率が良いがメモリ消費量が増えるため良い塩梅の値を見つける必要があります。
データ並列数(DP)：バッチ（一度に学習するサンプル数）を何分割するか。例えばグローバルバッチサイズが512の時、DP=4にすると、512/4=128バッチずつを4並列で処理します。一番通信オーバーヘッドが少ないのでなるべくこれを多くしたいです。
テンソル並列数(TP)：モデルの重みテンソルを何分割するか。例えば2048行のテンソルをTP=8で行分割する場合、2048/8=256行ずつを8並列で処理します。通信負荷が高いのでなるべく少なくしたいですし高帯域なノード内に留めたいところです。
パイプライン並列数(PP)：モデルを層ごとに何分割するか。例えば80層あるモデルをPP=2で分割する場合、80/2=40層ずつを2並列で処理します。DPとPPの中間ほどのオーバーヘッドですが、多くしすぎるとパイプラインバブルによって性能低下の要因となります。
コンテキスト並列数(CP)：テンソル以外の分割数。以前までの記事には登場していませんでしたが、今回は準備の節で述べた通りB200の性能を最大限引き出すためにMegatron-LMのバージョンを上げた結果、この機能が使えるようになりました。

この5つが、どのように性能に影響するのか調べて適切な値を選び出すことが高速化に効いてきます。

今回は時間の制約があり、試すことができたのは8GPUをそれぞれのパラメーターに全振りしてみたパターン5種だけでした。その結果をお伝えすると、5パターンのうち4つはそもそもメモリ容量が足らず、OoM(Out of Memory)エラーとなって動かすことができませんでした。テンソル並列に全振りしたパターンのみ動作させることができました。

試行	DP	PP	CP	TP	MBS	性能 [TFLOP/s/GPU]
すべてデータ並列	8	1	1	1	1	OoM
すべてパイプライン並列	1	8	1	1	1	OoM
すべてコンテキスト並列	1	1	8	1	1	OoM
すべてテンソル並列	1	1	1	8	1	826
マイクロバッチサイズを増やしてみる	1	1	1	8	2	OoM

今回行った検証の範囲では、B200ですべてテンソル並列にしたところ動作し、826[TFLOP/s/GPU]という結果になりました。

H100/200との比較：事前学習での費用対効果は4倍

では結局、H100と比較すると、B200は費用対効果でどれぐらい良くなったのでしょうか？これを表にまとめると以下のようになります。

環境	大きさ＝系列長	精度の良さ＝損失値0.1になるに必要な反復回数	速さ＝合計演算スループット[TFLOP/s/GPU × GPU枚数]
H100	4096	27,000	332×16=5312
H200	4096	18,000	575×16=9200
B200	8192	※18,000	826x8=6608
H100からの改善効果	2倍長	1/1.5倍減	1.3倍速
H200からの改善効果	2倍長	同じ	0.7倍速

このように、2倍×1.5倍×1.3倍で、全体として「H100比では約4倍の費用対効果の改善」となりました。

なお、※のついているB200の反復回数については、今回は時間の都合上、実測することができておらず推定値になります。この推定の根拠は、以前のH200での検証ではB200と同じAdamWとfp8を用いた場合に18,000回で目標精度に到達しており、また今回B200での学習序盤の損失曲線がその時とおおむね一致していたことから、B200でも同等の反復回数で損失値0.1に到達するとしたものです。次の機会には、実際にこの反復回数で目標精度に到達するのか計測したいと思います。

また、最終列で演算スループットをGPU枚数の合計にしている点も注意してください。速さに演算スループットを用いると良い点は「1GPUあたりのハードウェア仕様上の性能上限値Rpeakからの効率で測ることができる」という、パフォーマンスエンジニアリングを「工学」として実施するのに重要であったためでした。しかし、あくまで1GPUあたりの値であることから、今回のようにノード数（GPU枚数）が異なるものを比較する場合には、システム全体での演算スループットの合計値で比較しなければなりません。なぜなら、費用対効果を考える目的は、同じ費用で同等〜それ以上の性能をもつシステムを導入することにあるからです。

B200はH100に比べて、性能も費用もおおよそ2倍である点を考慮した比較であることを思い出してください。ハードウェア的に2倍程度の性能が出るのであれば、H100が332[TFLOP/s/GPU]出ていたのに対して、費用も2倍になりますがB200に移植すれば664[TFLOP/s/GPU]が出ると期待されます。実際にそのように単純に性能を出すこと自体も難しいのですが、今回はそれよりもさらに速くなったことで「演算スループット単体でも1.3倍の費用対効果の改善」と言えているわけです。この1.3倍がどこに起因するものかについては、以下のように考えられます。

2倍よりわずかに増えたメモリ容量(80[GB]→192[GB])の中で、fp8の採用や活性値再計算の導入ができたこと
1ノードにおさめられたことで、ノード間の通信オーバーヘッドを削減できたこと
新しいバージョンのソフトウェアを用いたことで、実行時のテンソルFP4計算（いわゆる第2世代TransFormer Engine）を適用できたこと

ただしこれは推定であって、確定には詳細なプロファイリング等を必要とします。今回は時間の制約でその調査ができなかったので、次の機会には調べてみたいと思います。

また、H200比でいうと、長さ（系列長）は2倍にできていますが、速さ（演算スループット）では遅くなっている（7割減）結果となりました。そのため、H200と比べたときの費用対効果は2×0.7=1.4倍の改善にとどまっています。これは、最近のLLM（事前）学習においては「メモリ容量に余裕があればあるほどパフォーマンスエンジニアリングの機会に優れている」ことに起因しています。メモリ容量の観点では、H100比では先述の通り2倍強ありますが、H200比では1.4倍弱しかありません。今回はH100/200が2ノード対B200が1ノードの比較ですから、合計メモリ容量はH200の方が1.5倍弱ぐらい多いということになっています。つまり、この0.5倍多い分がH200では有利となって効果的なパフォーマンス改善が実施できていた一方、B200ではそれらを導入できなかったことが「H200より演算スループット単体では遅くなった」原因と考えられるでしょう。

また、これも今回は時間の都合上、並列数やマイクロバッチサイズなどの探索がとても簡易的なものになってしまいました。もっと良い組み合わせが存在して、性能改善する可能性もあります。このあたりの点についても、次の機会にはより深く探索を実施したいと思います。

実践2：巨大推論

さて、次の題材として、H100x8ノードの検証にも使用した「480Bモデルの1Mトークン推論」で、B200の費用対効果を計測してみます。

推論における費用対効果の3指標

推論においては、価値の3指標は具体的にはそれぞれ以下のようになります。

大きさ＝推論時の系列長：系列長がながければ、より多くの文脈を一度に読み込めるためより複雑な指示を理解し、質の高い応答を生成することができます。その改善効果については必ずしも比例するとは限らないかもしれませんが、ここでは、多くの実タスクにおいて系列長が2倍になれば、価値もそのまま2倍に相当すると考えます。
精度の良さ＝下流タスクに対するベンチマーク点数：推論の精度を計測する指標については、すでに多くのベンチマークが世の中には存在しており、その点数で比較することができます。
速さ＝生成速度[token/s]：1秒間に多くのトークン（文字）が生成できればそれだけ速く価値を生み出していると考えられます。例えば30[token/s]から60[token/s]と2倍の生成速度になるのであれば、それは2倍の価値と考えても差し支えないでしょう。

B200での巨大推論の結果：45[token/s]はH200の1.3倍の費用対効果

それでは実際に、H100の時に2ノードで動作した、vLLMを使ったQwen3-Coder-480B-A35B-Instruct-FP8をYarnで拡張して1000K=1Mトークン推論できるようにしたスクリプトを移植し、結果がどうなったかを見てみましょう。

GPU種別	ノード数	状態	生成速度 [token/s]
H100	2	既存の結果	32
B200	1	H100スクリプトをそのまま移植しただけ	33
B200	1	FlashInferを導入	45
H100	2	FlashInferをH100にも導入してみた	33

まず、H100x2ノードで動いていたスクリプトを、B200x1ノードに移植してそのまま動かしてみることには成功しました。これはメモリ容量が2倍になっていることから想定通りの結果です。つまり「大きさ」の観点では費用対効果が同じであることを意味しています。

また、移植しただけの時の生成速度については、H100の2ノードと同程度という結果になりました。これについては、推論はメモリ帯域に律速するという既知の常識と一致しています。1GPUあたりのメモリ帯域が2倍ですがGPU枚数が半分で合計のメモリ帯域が変化してないからです。

ただしこの推論を実行した時、実行ログに

FlashInfer failed to import for V1 engine on Blackwell (SM 10.0) GPUs; it is recommended to install FlashInfer for better performance.

という警告が出ていることに気づきました。そこでFlashInferを導入してB200で計測し直してみたところ、警告の通り性能が改善し、45[token/s]となりました。これは元のH100の結果やFlashInferを入れる前と比較して、概ね1.3倍速となります。つまり、FlashInferを入れるだけで、「速さ」の観点での費用対効果がB200では1.3倍改善したという結果になりました。

ここで、H100の2ノードの方にもFlashInferを導入してみるとそちらも速くなるのではと思い、念のためやってみました。結果、H100の2ノードでは生成速度が改善しませんでした。そのため、おそらく警告メッセージの通り「Blackwellアーキテクチャ」特有の改善がFlashInferによってもたらされたと考えて良いでしょう。FlashInferのBlackwell向け改善について少し追ってみると、これはPR#1039で導入されていて、実態はCUTLASSという行列演算ライブラリ内にある注意機構をBlackwell(SM10)向けのPTXやキャッシュサイズなどを考慮して実装したカーネルのサンプルを移植したものでした。vLLM側で速くなることが把握されていたため、専用のコードパスが存在しており警告が出されたようです。

なお、ここでも時間の制約上、検証しきれなかった点が2つあります。

FP4で量子化し、FP4のTensorCoreを使って推論させた時に生成速度がどれぐらい改善するのかを見る
精度評価用のベンチマークで、精度が維持されていることを確認する

特に、今回に限っては精度が劣化するような変更を加えていないため、精度評価を省略しても大きな問題になりませんでしたが、FP4を導入する場合にはその劣化具合をよく考えなければいけません。次にB200を使う機会には、この2つを実施したいと思います。

まとめ

B200を使ったAI処理に対して、費用対効果を改善する方向にパフォーマンスエンジニアリングを実施したところ、LLM事前学習で4倍、巨大モデル推論で1.3倍良いという結果が得られました。

そのためには、ソフトウェア（AIフレームワーク・PyTorch・CUDA・GPUドライバ）のバージョン選定を含めた環境構築が重要であることと、パフォーマンスエンジニアリングの際にはハードウェアの特性を活かした設定・チューニングが有用であることを示しました。

ただし将来課題として残っている点もまだたくさんあります。次の機会には、これらについて追加検証を実施し、よりこの結果を強固なものにして、また報告したいと思います。

また本検証で用いた環境の構築は、Fixstars AIBoosterに取り込まれて提供されています。今回用いた高火力 PHYのB200でAI処理を実施しようとしている方は、AIBoosterを使うことですぐにパフォーマンスが良いAI環境を手に入れることができますので、ぜひ使ってみてください。

(参考: さくらインターネットより) ホワイトペーパーのご紹介

さくらインターネットが提供している高火力シリーズ「PHY」「VRT」「DOK」を横断的に紹介する資料です。お客様の課題に合わせて最適なサービスを選んでいただけるよう、それぞれのサービスの特色の紹介や、比較表を掲載しています。