GPUサーバーラックは、アクセラレータで満たされた単なるキャビネットではありません。GPUトポロジー、ネットワークファブリック、ストレージ、管理、電力、冷却、スケジューリングが連携して機能するか、あるいは高コストなボトルネックを生み出すかを分けるデプロイメント境界です。
AI開発者やMLインフラストラクチャエンジニアにとって有用な問いは、「ラックには何基のGPUが収まるか」ではありません。重要なのは、このラックがワークロードに必要な通信、データパス、リカバリーの挙動を提供できるかです。このガイドでは、その問いをアーキテクチャチェックリストとクラウド受け入れ計画に落とし込みます。
GPUサーバーラックとは？
GPUサーバーラックとは、1台以上のGPUサーバーに加え、それらを運用するために必要なネットワーク、電力、冷却、管理コンポーネントを収容する物理ラック、またはプロバイダーが管理するラック規模の割り当てのことです。クラウド導入では、キャビネット自体を制御できない場合がありますが、それでも、ホストあたりのGPU数、ホスト内インターコネクト、ホスト間ファブリック、ストレージパス、メンテナンスドメイン、配置ポリシーといったトポロジーのどの部分が保証されるかを確認すべきです。
単一のGPUサーバーはノードです。GPUサーバーラックは、複数ノードを取り巻くシステムです。GPUクラスターは1つ以上のラックにまたがる場合があります。これらの区別は重要です。なぜなら、推論サービスは単一ホストのGPUメモリやPCIe/NVLinkパスによって制約されることがある一方、分散トレーニングや大規模推論はホスト間のネットワークおよびストレージパスによって制約される可能性があるためです。
NVIDIAのBasePODリファレンスアーキテクチャは、この違いを示しています。InfiniBandコンピュートネットワーク、Ethernetの管理・ストレージファブリック、帯域外管理ネットワークを分離しています。設計でこのリファレンスアーキテクチャをそのまま複製する必要はありませんが、容量を確定する前に同等のパスを明確にする必要があります。 NVIDIA DGX BasePODリファレンスアーキテクチャ
GPUサーバーラックのアーキテクチャ：マッピングすべき6つの要素
物理配置と論理パスを示すラック図から始めます。プロバイダーがすべてのコンポーネントを開示できない場合は、保証される内容を記録し、受け入れ期間中に残りをテストしてください。
| レイヤー | 文書化する内容 | 結果に影響する理由 |
|---|---|---|
| コンピュートノード | GPUモデル、ホストあたりのGPU数、CPU/RAM、ローカルNVMe、交換ドメイン | メモリ容量、ホスト側の前処理能力、ノード障害の影響範囲を定義します。 |
| ノード内トポロジー | PCIeレイアウト、NVLink/NVSwitchの可用性、GPUとNICのアフィニティ | 1台のホスト上のGPU間でデータを効率的に交換できるかを決定します。 |
| ノード間ファブリック | ネットワークタイプ、NIC数と速度、スイッチ階層、オーバーサブスクリプションポリシー、同一ラック配置 | ジョブが1台のサーバーを離れた後の集団通信の挙動を決定します。 |
| ストレージパス | ローカルキャッシュ、共有ファイルシステムまたはオブジェクトストア、チェックポイントの保存先、ネットワークパス | データ読み込みとチェックポイント作成がコンピュート時間を奪わないようにします。 |
| 管理と制御 | BMC/帯域外アクセス、インベントリ、スケジューラー、メトリクス、変更管理 | ホストまたはドライバーに障害が発生した際に、ラックを運用可能にします。 |
| 設備条件 | ラック電力割り当て、PDU冗長性、気流または液冷設計、保守アクセス | 機械的に収まるかどうかだけでなく、持続可能な密度と保守作業を制約します。 |
1. トポロジーをワークロードの入力として扱う
GPU数だけでは、容量を完全に説明できません。1台のホストについて、GPU同士およびNICへの接続方法を確認してください。ホスト間では、ジョブが1台のサーバー内、1つのラック内、またはラックをまたいで実行されるかを特定します。「8基のGPU」がどこでも同じマシンを意味すると仮定するのではなく、想定される配置ルールをワークロード仕様に記録してください。
NCCLは、CUDAが関連するGPU同士で互いのメモリにアクセスできると報告した場合、直接のピアツーピアパスを使用します。NVIDIAは、ピアツーピアの状態を確認する方法としてnvidia-smi topo -p2pを文書化しています。これをワークロードベンチマークの代替ではなく、検証入力として使用してください。 NCCL GPUトラブルシューティングガイダンス
2. コンピュート、データ、管理のトラフィックを分離する
GPUサーバーラックには、高速なトレーニングネットワーク以上のものが必要です。管理トラフィック、アーティファクトのプル、テレメトリー、共有ストレージ、ユーザーアクセスは、容量不足のパスを共有するとワークロードトラフィックに干渉する可能性があります。アーキテクチャで必要とされる場所では、論理的または物理的に経路を分離し、次の各項目をどのパスで運ぶかを定義してください。
- 集団通信およびGPUダイレクトトラフィック。
- イメージプル、モデル重み、データセット、チェックポイント。
- Kubernetes、SSH、BMC、ロギング、モニタリングのトラフィック。
- API、オブジェクトストレージ、またはダウンストリームサービスへのエグレス。
これはクラウド容量で特に重要です。帯域幅の数値が、ホスト間帯域幅、ラックのアップリンク、ストレージスループット、またはベストエフォートの総帯域幅のどれを示すのかを確認してください。これらは互換的に扱えません。
3. 電力と冷却を容量制約として設計する
GPUサーバーラックをラックユニットだけでサイジングしてはいけません。機械的に収まる構成でも、設備電力、PDU冗長性、気流方向、液冷要件、ケーブルの曲げ半径、保守用クリアランスによって制約される可能性があります。NVIDIAは、ラックレイアウトが現地の最大電力および冷却インフラストラクチャによって異なると指摘しています。実際の割り当てについては、サーバーベンダーとコロケーションプロバイダーの最新ドキュメントを使用してください。 NVIDIA DGX SuperPOD FAQ
導入前に、以下の質問に対する書面での回答を依頼してください。
- 持続的なラック電力の許容範囲はどの程度で、どのような冗長性の前提が含まれていますか？
- 冷却設計は空冷、ダイレクト・トゥ・チップ液冷、リアドア熱交換、またはそれらの組み合わせですか？
- 最初にスロットリングまたはメンテナンスイベントを引き起こすコンポーネントはどれですか：ホスト、PDU、ネットワークスイッチ、それとも施設側ループですか？
- 技術者は隣接する容量を中断せずに、ノード、ケーブル、またはリアドアのコンポーネントを保守できますか？
導入がクラウド専用の場合は、同じ質問をプロバイダーの用語に置き換えてください：専用ホスト配置、メンテナンスドメイン、ホスト交換ポリシー、およびプロビジョニング後に割り当てのトポロジーが変更される可能性があるかどうかです。
4. 有用な場合にのみスケジューラーにラック認識を持たせる
ラックラベルは、ワークロードがローカリティまたは障害ドメインを重視する場合に価値があります。分散トレーニングジョブでは、ラック間に拡張する前に単一ラックへの配置が望ましい場合があります。高可用性の推論サービスでは、意図的にレプリカをラックまたはホストに分散させることがあります。topology.rack、topology.host-class、topology.fabric、topology.failure-domainなど、小規模で監査可能なラベルセットから始め、そのラベルに従ってスケジューラーが配置を行うことを検証してください。
Kubernetesでは、クラスターのバージョンだけでなく、サポート対象のオペレーティングシステム、Kubernetes、ドライバー、ランタイム、導入オプションに対して、GPUソフトウェアスタック全体を検証してください。NVIDIAのGPU Operatorサポートマトリクスは、ベアメタル、GPUパススルーVM、vGPU導入を区別し、サポート対象環境の互換性詳細を公開しています。NVIDIA GPU Operatorのプラットフォームサポート
ワークロードに適したGPUサーバーラックの選び方
ワークロード概要を使用して、単一の高密度ホスト、1ラック、またはマルチラッククラスターのどれが必要かを判断します。
| ワークロードパターン | 通常優先する項目 | プロバイダーまたはプラットフォームチームへの質問 |
|---|---|---|
| 単一ノードのファインチューニングまたは推論 | GPUメモリ、ノード内トポロジー、ローカルストレージ、信頼できるホスト交換 | 1台のホストにはどのGPUとインターコネクトが接続されていますか？必要なGPUはすべてまとめて割り当てられますか？ |
| 分散トレーニング | 同一ラック配置、ネットワークファブリック、NICアフィニティ、チェックポイントスループット | ホスト間ネットワーキングについて何が保証されますか？ラック間配置はどのように公開または回避されますか？ |
| マルチノード推論 | テールレイテンシ、モデルシャード通信、ロールアウトの安全性、可観測性 | モデル並列ランクのトポロジー認識を維持しつつ、障害ドメインごとにレプリカを分散できますか？ |
| バッチまたはレンダリングワークロード | キューの挙動、ローカルキャッシュ、中断処理、イメージ／データのステージング | 配置保証はどのようなもので、中断されたジョブはどのように復旧しますか？ |
| 共有社内プラットフォーム | 分離、クォータ、スケジューラーポリシー、容量の可視性、変更管理 | GPUパーティション、テナント境界、ドライバー、アップグレードはどのように管理されますか？ |
新規導入では、ラックという選択肢をより簡単な代替案と比較してください。トポロジー、データローカリティ、またはカスタムのサービングスタックを制御する必要がない場合、マネージドモデルAPIの方が運用負荷を低減できる可能性があります。GPUサーバーラックをデフォルトの回答と見なすのではなく、意思決定の一部としてこのGPUクラウドとモデルAPIの比較を使用してください。
GPUサーバーラックの性能を評価する方法
ピーク時のアクセラレータ性能値だけでGPUサーバーラックを受け入れてはいけません。主要な性能経路を分離する簡潔な受け入れテストを作成してください。
ステップ1：インベントリとトポロジーのベースラインを取得する
割り当てられた各ホストについて、GPUの識別情報、ドライバーとCUDAのバージョン、GPU間トポロジー、GPUとNICのアフィニティ、CPU NUMAレイアウト、ローカルストレージ、ネットワークインターフェースを収集します。この記録を導入リビジョンとともに保管してください。イメージ、ファームウェア、ドライバー、またはホストの交換後に性能が変化した際の比較点になります。
nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n
一般的なチェックリストに従って、カーネル、BIOS、IOMMU、PCIeアクセス制御の設定を変更しないでください。NVIDIAはLinuxベアメタルシステムにおける構成依存のピアツーピア動作を文書化しています。実際に運用するサーバーおよびクラウドプラットフォームでサポートされる設定を使用してください。NCCLのトポロジーおよびピアツーピアのトラブルシューティング
ステップ2：重要な境界でテストする
次の3つのスコープで代表的なテストを実行します：
- 単一ノード：GPUの可視性と、ローカルのNVLink/NVSwitchまたはPCIe経路を検証します。
- 同一ラック：ホスト間配置とローカルファブリックを検証します。
- ラック間：容量の拡張またはフェイルオーバー時にスケジューラーが使用する経路を把握します。
NVIDIAのNCCLテストガイダンスでは、GPU可視性、ノード内インターコネクト、ノード間ファブリック、配置を検証するために、単一ノード、単一ラック、マルチラックでの実行を明示的に使用しています。結果を再現できるよう、テストコマンド、コンテナーイメージダイジェスト、ノードリスト、配置ラベルとともにレイテンシおよび帯域幅を記録してください。NCCL検証チュートリアル
ステップ3：実際のアプリケーション経路を測定する
次に、提供する予定のワークロードを実行します。トレーニングでは、ステップあたりの時間、データ待機時間、集団通信時間、チェックポイント時間、およびリカバリ動作を報告します。推論では、最初のトークンまでの時間、出力スループット、テールレイテンシ、キュー遅延、キャッシュ動作、およびエラー率または再起動率を報告します。配置を比較する際は、同じモデル、バッチ/同時実行プロファイル、コンテキスト長、キャッシュ状態を維持してください。
これにより、GPUの問題と、データ、ネットワーク、スケジューラ、または設定の問題を切り分けることができます。
ステップ4：計画された障害をテストする
運用中のGPUサーバーラックには、リカバリ経路が必要です。本番トラフィックを開始する前に、ワーカーがドレインされた場合、ノードが利用できなくなった場合、ジョブがプリエンプトされた場合、またはチェックポイントを別の場所で再開する必要がある場合に何が起こるかを検証してください。永続データが交換可能なコンピュートから分離されていること、また資格情報、イメージ、オブザーバビリティが交換先の経路でも引き続き機能することを確認します。
クラウドでGPUサーバーラックを導入する：実践的な手順
クラウド導入で変わるのは制御境界であり、エンジニアリング作業ではありません。ハードウェアと配置に関する前提を可視化する必要は依然としてあります。
- ワークロード契約を作成する。 モデルサイズ、GPU数、メモリ要件、レイテンシまたはスループットのSLO、ネットワーク感度、データソース、チェックポイントの場所、可用性目標、予算ガードレールを指定します。
- トポロジ境界を選択する。 ジョブを単一ホスト、単一ラック、または定義されたマルチラックファブリック内に維持する必要があるかを決定します。これは非公式な希望ではなく、プロバイダーへの要求事項として扱ってください。
- 割り当てシートを依頼する。 ホストクラス、GPU数、GPUインターコネクト、NIC、ネットワークファブリック、ストレージオプション、配置保証、メンテナンスポリシー、およびスケジューラに公開されるトポロジメタデータを要求します。
- ソフトウェア契約を固定する。 オペレーティングシステム、カーネル、NVIDIAドライバー、CUDA、コンテナランタイム、Kubernetesバージョン、GPU Operatorバージョン、フレームワークイメージ、アプリケーションイメージダイジェストを記録します。ロールアウト前に、サポート対象マトリクスに照らしてこの組み合わせを検証してください。
- 限定的な受け入れ期間を設ける。 継続的なトラフィックを移行する前に、インベントリ、トポロジ、同一ノード/同一ラック/ラック間通信、ストレージ、アプリケーション、リカバリのテストを実行します。
- 各レイヤーを計測する。 GPUヘルス、ファブリックエラー、ストレージ待機、スケジューラ待機、熱イベントまたはスロットリングイベント、アプリケーションSLOについて、それぞれ個別にアラートを設定します。単一の使用率メトリクスでは、ラックスケールのインシデントを説明できません。
- 退出とリカバリの選択肢を維持する。 特定の割り当てに依存しない形で、イメージ定義、インフラストラクチャ設定、永続データの保存場所、チェックポイント、ロールバック計画を維持します。
この手順のホストレベル部分については、GPUサーバー導入ガイドを参照してください。マルチノードのコントロールプレーンおよびファブリックの観点については、GPUクラスターアーキテクチャガイドを参照してください。
GPUサーバーラック受け入れチェックリスト
新しいGPUサーバーラック、専用クラウド割り当て、またはコロケーション構成を受け入れる前に、このチェックリストを使用してください。
- [ ] ワークロード契約で、単一ホスト、同一ラック、またはマルチラックというトポロジ境界が明記されている。
- [ ] 割り当てシートで、ホストあたりのGPU数、アクセラレータインターコネクト、NIC、ネットワークファブリック、ストレージパスが特定されている。
- [ ] 電源、冷却、PDU冗長性、気流または液冷要件、および保守作業スペースに担当者が設定されている。
- [ ] GPU、ドライバー、CUDA、カーネル、コンテナランタイム、オーケストレーションのバージョンが記録されている。
- [ ] スケジューラが、ワークロードで必要な配置ラベルまたは障害ドメインラベルを公開し、それらを尊重する。
- [ ] インベントリおよび
nvidia-smiのトポロジ出力が、すべてのホストクラスについて保存されている。 - [ ] 通信テストが、本番スケジューラで作成可能な単一ノード、同一ラック、ラック間の配置をカバーしている。
- [ ] アプリケーションテストで、代表的なデータソースとワークロードプロファイルを使用している。
- [ ] チェックポイント、ホストドレイン、交換、ロールバックの経路がテストされている。
- [ ] コストレポートで、生産的なGPU時間をアイドル、リトライ、データ、サポートのコストから分離し、同じ時間を二重計上していない。より広範なコストモデルについては、このGPUレンタルガイドから始めてください。
よくある質問
GPUサーバーラックはGPUクラスターと同じですか？
いいえ。GPUサーバーラックは、物理的またはプロバイダー管理のラックスケール導入境界を示します。GPUクラスターは、1つのラックの一部、ラック全体、または複数ラックにまたがることができる論理的なノードグループです。ネットワーク、ストレージ、障害ドメイン、スケジューリングが物理的境界をまたぐ場合、この違いは重要になります。
GPUサーバーラックには何台のGPUサーバーを収容できますか？
有用な普遍的な数値はありません。サーバーの奥行きとラックユニットは、最初の制約にすぎません。実際の答えは、サーバーの消費電力、冷却設計、PDU容量と冗長性、ケーブル配線、保守アクセス、および施設で承認された密度に依存します。使用する正確なホスト、ラック、データセンター設計に照らして確認してください。
すべてのGPUサーバーラックにInfiniBandは必要ですか？
いいえ。適切なファブリックは、ワークロードとトポロジに依存します。単一ホストのワークロードでは、ノード間の高性能ファブリックがまったく必要ない場合があります。分散ワークロードは、同一ラックおよびラック間の配置を含め、実際に使用するネットワーク経路でテストする必要があります。マーケティング仕様だけでファブリックを選定することは避けてください。
クラウドGPUラック容量を受け入れる前に何をテストすべきですか？
受け取った割り当てをテストします。ハードウェアインベントリ、トポロジ、GPUとNICのアフィニティ、ローカルおよび共有ストレージの動作、単一ノード通信、同一ラック内通信、本番環境で可能な場合はラック間通信、代表的なアプリケーションの動作、計画的な障害からの復旧を確認します。
GPUサーバーラックの運用を避けるべきなのはどのような場合ですか？
ワークロードがGPUサーバーラックによる制御を必要としない場合は、ラック規模の運用を避けてください。マネージドモデルAPIでモデル、レイテンシ、可用性、プライバシー、コストの要件を満たせる場合、ハードウェア、ファブリック、ドライバー、スケジューラー、容量管理の作業を不要にできます。GPUサーバーラックを導入する前に、この比較を慎重に行ってください。
ワークロードを中心にラックを構築する
GPUサーバーラックが成功するかどうかは、その物理設計とクラウド割り当てが、ワークロードの通信、データ、復旧の経路に適合しているかどうかにかかっています。トポロジを明確にし、相互に干渉しうるトラフィッククラスを分離し、単一ノード、同一ラック、ラック間の各スコープで性能を検証してください。また、実際のアプリケーションと障害経路をテストした後にのみ、容量を受け入れてください。
ラックレベルの制御が不要な場合は、運用負荷を引き受ける前にモデルAPIの選択肢を比較してください。必要な場合は、このガイドをGPUサーバーガイド、GPUクラスターアーキテクチャガイド、GPUクラウドコストチェックリストと併用し、容量を検証可能な導入環境へと変えてください。
