AI の学習サーバーと推論サーバーの違い — スペックが分かれるポイント
GPU サーバーを調べていると、同じ「AI サーバー」なのに、ある資料は NVLink で 8 枚を束ねた数千万円のノードを語り、別の資料は数十万円のカード一枚で足りると言います。どちらも正しいのです。前者は学習用、後者は推論用の話だからです。この記事は学習と推論がなぜ別の機材を要求するのか、スペックが分かれるポイントを整理します。GPU サーバーの基本構造と GPU の名前の読み方に続く記事です。
ワークロードの性質が違います #
学習(training)はバッチ処理です。 大量のデータを繰り返し流し込みながらモデルの重みを更新する仕事で、数日から数週間、GPU を 100% で回し続けます。目標は総スループット、つまり「何日で終わるか」です。個別の応答のレイテンシという概念自体がありません。
推論(inference)はリクエスト処理です。 ユーザーのリクエストが届いたら答えを作って返す仕事で、トラフィックは寄せては引きます。目標はレイテンシ SLO の中での処理、つまり「最初のトークンが数秒以内に出るか、毎秒何リクエストを受けられるか」です。サーバーが遅い理由シリーズで扱ったレイテンシ診断の感覚がそのまま適用されるのはこちら側です。
バッチ処理とリクエスト処理の違いが、スペックの違いにつながります。
ボトルネックが違います — 通信対メモリ #
学習のボトルネックは GPU 間の通信です。 大きいモデルは GPU 一枚に収まらないので、数十〜数千枚がモデルとデータを分担して持ち、ステップごとに勾配を交換し合います。この交換が遅いと、GPU は通信を待って遊びます。だから学習ノードは、ノード内は NVLink、ノード間は InfiniBand/RoCE という高速接続がスペックの要になり、この接続がフラッグシップ(H100・B200 級)ノードが高い理由の大きな部分です。チェックポイントを読み書きするストレージ帯域も学習側で重要になります。
推論のボトルネックはたいていメモリです。 LLM がトークンを一つ作るたびにモデルの重み全体を VRAM から読む必要があるので、トークン生成速度は演算能力よりメモリ帯域に左右されることが多いのです。要件は「モデルが VRAM に収まり、帯域が目標速度を出せるか」に絞られ、GPU 間の通信はモデルが一枚に収まる限りまったく要りません。だから NVLink のない推論カード(L4、L40S)が成立します。
精度が違います — 量子化という推論の武器 #
学習は勾配計算の数値的な安定性のため、BF16 のような比較的高い精度が基本です(最新世代は FP8 学習も使います)。一方、推論は学習が終わった重みを読むだけなので、INT8・FP8・4 ビットへ下げる量子化が、品質の損失を許容できる範囲で実用になります。
これが機材選択に与える意味は大きいのです。量子化は必要な VRAM とメモリ帯域の要求を半分、4 分の 1 に減らすので、同じモデルでも推論は学習よりはるかに小さい GPU で動きます。 70B モデルの学習にはフラッグシップのノードが必要ですが、4 ビットに量子化した 70B の推論は中型 GPU 2〜3 枚で成立します。具体的な計算は次の記事で扱います。
スケールの方向が違います — アップかアウトか #
- 学習はスケールアップ + 密結合のスケールアウトです。通信のボトルネックのため、GPU 群は近く(NVLink ドメイン、同じ InfiniBand ファブリック)に束ねられている必要があり、ノードを増やすほどネットワーク設計が難しくなります。GB200 NVL72 のようにラック全体を一つのドメインとして売る製品が出てくる理由です。
- 推論は疎結合のスケールアウトです。リクエスト単位に分かれるので、モデルを載せたサーバーを複数台置いてロードバランサーで分ければ水平に拡張できます。トラフィックに合わせて台数を増減するオートスケーリングも、推論側でだけ成立する話です。
可用性の観点も分かれます。学習はノードが一つ落ちてもチェックポイントから再開すればいいバッチ処理ですが、推論はユーザーと向き合うサービスなので、一般のウェブサービスと同じ冗長化・ヘルスチェック・デプロイ戦略が必要です。
コスト構造が違います #
- 学習コストは一時的な支出に近いです。 プロジェクト期間に大量に使って終わるので、クラウドの予約・スポット容量や GPU クラウドのレンタルが向いています。スポットの中断はチェックポイントからの再開で吸収します。常時保有は、学習パイプラインが年中回る組織でだけ正当化されます。
- 推論コストは固定費です。 サービスが生きている限り出続け、トラフィックの少ない時間の遊休がそのまま無駄になります。だから推論側の実務は稼働率の管理が中心になります。バッチングで GPU を埋め、オートスケーリングで遊休を減らし、トラフィックが小さいならセルフホスティングの代わりに API の従量課金のほうが安い領域かを計算します。
兼用の罠 #
「学習用に買ったサーバーに推論も載せよう」は自然な発想ですが、罠が二つあります。第一に、要求のプロファイルが違うので無駄が出ます。推論には過剰な NVLink・InfiniBand にお金を払ったのに、肝心の推論性能はメモリ帯域の分しか出ません。第二に、干渉です。学習が GPU を占有している間、推論のレイテンシが SLO を超過します。兼用するなら MIG で GPU を分割するか(ハードウェア中級 #8)、時間帯で分けるか、最初からプールを分けるほうが運用はシンプルです。
まとめ #
- 学習はバッチ処理(総スループット)、推論はリクエスト処理(レイテンシ SLO)です。この性質の違いが、スペックの違いの根本にあります。
- 学習のボトルネックは GPU 間の通信なので NVLink・InfiniBand がスペックの要で、推論のボトルネックはたいてい VRAM 容量とメモリ帯域です。
- 推論は量子化で要求スペックを大きく下げられるので、同じモデルでも学習よりはるかに小さい GPU で動きます。
- 学習は密結合の拡張(ラック単位)、推論はロードバランサーの後ろの水平拡張とオートスケーリングです。
- 学習コストは一時的(スポット・レンタルが有利)、推論コストは固定(稼働率管理が肝)です。兼用は干渉と無駄を生みやすく、プールの分離が基本です。
次の記事でこの違いを数字につなぎます。LLM サービスをセルフホスティングするときに必要なサーバー規模を、VRAM の計算から見積もります。