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

GPUクラスターアーキテクチャ: Compute、Network、Storage、Control Plane

computeノード、ネットワークファブリック、ストレージ、KubernetesまたはSlurmのControl Plane、可観測性、受け入れテストを含む、実践的なGPUクラスターアーキテクチャガイドです。

GPUクラスターアーキテクチャは、GPU台数だけでなくシステム全体の形です。本番クラスターは、高価なアクセラレータを有用な学習ジョブや信頼性の高い推論へ変える前に、コンピュートノード、高速ネットワーク、ストレージ、スケジューラ、アクセス制御、テレメトリ、復旧経路を調整できなければなりません。

実務上の問いは単純です。チームはデータを移動し、ジョブをスケジュールし、障害を復旧し、コストを十分な速さで測定して、GPUを稼働させ続けられるでしょうか。できないなら、より優れたカードを備えたクラスターでも、小規模なマネージドGPUサービスやモデルAPIより経済性が悪くなる可能性があります。

このガイドは、AIプラットフォームチーム向けにgpu cluster architectureの実用モデルを示します。コンピュート層に何を含めるべきか、ネットワークが何を証明しなければならないか、ストレージとチェックポイントがどう組み合わさるか、KubernetesやSlurmがどのようにコントロールプレーンになるか、そしてマルチノード容量を借りるまたは購入する前に何をテストすべきかを解説します。

Flatkeyの実践的なルールは、まずワークロードの境界から始めることです。製品がモデル出力だけを必要とするなら、最初にGPU cloud vs model APIの経路をベンチマークしてください。カスタム重み、配置制御、長時間学習、またはプライベートな推論インフラが必要なら、ワークロードのコンピュート、ネットワーク、ストレージ、コントロールプレーン要件に合わせてGPUクラスターを設計します。

GPUクラスターアーキテクチャの要点

有用なGPUクラスターには4つのプレーンがあります。

Plane	What it owns	Common failure when skipped
Compute	GPU servers, CPU/RAM ratio, local NVMe, GPU topology, drivers, CUDA, containers, MIG or full-GPU allocation	The team buys the right GPU model but the wrong node shape, memory layout, or driver stack.
Network	Intra-node NVLink/NVSwitch, cross-node InfiniBand, RoCE, EFA, Ethernet, placement, DNS, ingress, service mesh boundaries	Multi-node jobs scale poorly because "fast network" was never validated with real all-reduce or serving traffic.
Storage	Dataset staging, model weights, checkpoint writes, shared filesystem, object storage, local scratch, snapshots, backup, cleanup	GPUs sit idle while data loads, checkpoints block training, or restart recovery takes too long.
Control plane	Kubernetes, Slurm, Kueue, Volcano, Ray, user access, quotas, observability, billing tags, security policy, incident response	Jobs run, but no one can explain queue time, allocation fairness, failures, or unit cost.

multi-node gpu cluster architectureが成功するのは、これらのプレーンを一緒に設計したときです。ファブリックのないコンピュートは孤立した容量です。ストレージのないファブリックはボトルネックを移動するだけです。クォータ、テレメトリ、runbookのないKubernetesは、起動機構にすぎません。

GPUクラスターアーキテクチャ図

ベンダーを比較する前やラック設計を承認する前に、この図をレビューの基準として使ってください。

                  users / CI / product traffic / API clients
                                  |
                                  v
        +------------------------------------------------------+
        | control plane                                        |
        | Kubernetes or Slurm scheduler, queues, quotas,       |
        | secrets, registry access, policy, telemetry, billing |
        +------------------------------------------------------+
              |                    |                    |
              v                    v                    v
   +-------------------+   +-------------------+   +-------------------+
   | gpu compute node  |   | gpu compute node  |   | gpu compute node  |
   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |
   | local NVMe, NICs  |   | local NVMe, NICs  |   | local NVMe, NICs  |
   +-------------------+   +-------------------+   +-------------------+
              \                  |                  /
               \                 |                 /
                v                v                v
        +------------------------------------------------------+
        | high-speed fabric                                   |
        | NVLink/NVSwitch inside node; InfiniBand, RoCE, EFA, |
        | or Ethernet across nodes; placement and routing     |
        +------------------------------------------------------+
                                  |
                                  v
        +------------------------------------------------------+
        | storage and data path                               |
        | object store, shared filesystem, local scratch,      |
        | model cache, checkpoints, snapshots, backups        |
        +------------------------------------------------------+

kubernetes gpu cluster architecture diagramの場合は、Kubernetes固有のオブジェクトをコントロールプレーンの周りに追加します。

cluster admins -> node images -> GPU Operator / device plugin -> GPU nodes
app teams      -> namespace -> quota -> job queue -> Pod / Job / RayJob
finance        -> labels -> usage export -> cost per job / team / model
security       -> secrets -> image policy -> network policy -> audit logs

この図は意図的に簡素です。目的は、すべてのサービスを描くことではありません。目的は、クラスターが本番の依存対象になる前に、欠けている責務を見つけることです。

ラックではなくワークロードから始める

Kubernetes、Slurm、クラウド予約、あるいはベアメタルベンダーを選ぶ前に、1ページのワークロード概要を作成してください。

項目	定義すべき内容
ワークロード種別	事前学習、ファインチューニング、バッチ推論、オンライン推論、埋め込み、検索、画像/動画生成、シミュレーション、または研究用ノートブック。
フレームワーク	PyTorch、JAX、TensorFlow、vLLM、SGLang、TensorRT-LLM、Ray、Slurm、Kubernetes Jobs、またはカスタムサービス。
GPUターゲット	H100、H200、B200、A100、L40S、RTX PRO、AMD MIシリーズ、または許容可能な範囲。
ノード形状	ノードあたりのGPU数、GPUメモリ、CPUコア数、システムRAM、ローカルNVMe、NIC数、および電力上限。
スケール形状	単一ノード、マルチノード同期学習、シャーディング推論、バッチキュー、または混在プラットフォーム。
ネットワーク感度	必要な all-reduce 性能、レイテンシ許容度、配置グループ要件、トラフィック分離、および外向き通信経路。
ストレージ感度	データセットサイズ、モデル重みサイズ、チェックポイント頻度、復元先ターゲット、ファイルシステム要件、およびオブジェクトストアのリージョン。
運用境界	ドライバ、イメージ、スケジューラポリシー、テレメトリ、サポート、パッチ適用、ユーザーアクセス、およびインシデント対応の責任者。
ビジネス指標	完了した学習実行あたりのコスト、承認された推論出力あたりのコスト、GPU時間の利用率、または予約済みGPU月。

この表を埋められないなら、まだ長期のキャパシティ契約に署名してはいけません。まずは小さな区画を借りてベンチマークを実行し、そのログを調達ブリーフに変えましょう。GPU cluster rental guide は、アーキテクチャの形が明確になった後の購入側チェックリストを提供します。

コンピュートプレーン：GPUノードは互換ではない

Compute plane は、ジョブが実際に何を使えるかを定義します。完全な compute 仕様には、"8x H100" や "B200 cluster" だけでは足りません。

以下を要求してください:

GPUモデル、メモリ容量、該当する場合はPCIeかSXMか。
ノードあたりのGPU数とノード内トポロジー。
CPUモデル、CPU数、システムRAM、およびNUMA配置。
ローカルNVMe容量と想定スループット。
NIC数、NIC速度、およびGPU-directパスがサポートされるかどうか。
ドライバ、CUDA、コンテナランタイム、およびOSイメージのライフサイクル。
MIG、vGPU、time-slicing、またはフルGPU割り当てポリシー。
ノードの均一性と交換ポリシー。

ノード内トポロジーが重要なのは、1台のサーバーに8基のGPUがあることと、単一GPUノードが8台あることは同等ではないからです。ノード設計は、メモリ圧力、CPUボトルネック、ローカルステージング速度、そしてノード間通信のコストを左右します。

NVIDIAのKubernetes GPU Operatorのドキュメントはここで役立ちます。ドライバ、NVIDIA Container Toolkit、device plugin、DCGMテレメトリ、および関連コンポーネントを、個別のノード設定ではなくクラスターのスタックとして管理できることを示しているからです。Kubernetes device plugin のドキュメントは、ベンダーデバイスをスケジュール可能なリソースとして公開するために使われる一般的な拡張ポイントを説明しています。

ネットワークプレーン：ベンチマークでファブリックを検証する

マルチノード学習と高スループット配信はネットワークに依存します。クラスター仕様には、帯域幅の数字だけでなく、ファブリックと受け入れテストを明記すべきです。

以下を要求してください:

ノード内のNVLinkまたはNVSwitchの詳細。
ノード間のInfiniBand、RoCE、EFA、またはEthernet設計。
ノードごとのNIC数と速度。
配置保証と障害ドメイン。
オーバーサブスクリプション比率。
該当する場合のGPUDirect RDMAサポート。
コンテナとホストのネットワーキングモデル。
ファブリックエラー、再送、輻輳、ノード障害の可観測性。

契約開始前に受け入れテストを実施してください:

network acceptance test:
  run NCCL all_reduce across every rented node
  record bandwidth, latency, node IDs, GPU model, driver, CUDA, NCCL version
  repeat after installing the production container image
  save logs and compare them with the provider's quoted topology

NVIDIA NCCL と NCCL tests は、分散GPUワークロードにおける集団通信の挙動を検証する標準的な参照です。重要なのは、単一のベンチマーク数値を追いかけることではありません。重要なのは、本番学習が失敗する前に、ノードの不一致、不適切な配置、ファブリック輻輳、あるいはドライバ/コンテナのずれを検出することです。

推論では、ネットワークテストに実際のトラフィック経路を含めるべきです。つまり、リクエストの入口、モデルシャード間通信、該当する場合のKVキャッシュ挙動、ストレージ取得、そして出口通信です。単独では強く見える学習用ファブリックでも、サービングスタックが多すぎるネットワーク境界をまたぐと、ユーザー遅延が悪化することがあります。

ストレージプレーン：データ、重み、チェックポイントをクリティカルパスから外す

ストレージは、多くのGPUクラスターアーキテクチャ計画が高くつく場所です。GPUの見積もりは見えますが、データパスは最初の本番実行まで隠れていることが多いです。

ストレージは次の4つのフローに沿って設計します:

フロー	アーキテクチャ上の問い
データセットのステージング	オブジェクトストレージ、リモートファイルシステム、またはデータウェアハウスからノードへデータセットを移すのにどれくらいかかるか?
モデル重み	ベース重み、ファインチューニング済み重み、トークナイザファイル、エンジンアーティファクトはどこにキャッシュされるか?
チェックポイント	チェックポイントはどのくらいの頻度で書き込まれ、どれくらいの大きさで、ノード障害後の復元にはどれくらい時間がかかるか?
出力とログ	生成されたアーティファクト、メトリクス、トレース、監査ログはどこに保存され、どの保持ポリシーが適用されるか?

学習では、チェックポイントのスループットと復元時間はバックアップの詳細ではなく、アーキテクチャ上の論点です。推論では、モデル重みの読み込み、ローカルキャッシュのウォームアップ、永続ボリュームの挙動が、デプロイ時間とフェイルオーバー時間に影響します。

NVIDIAのGPUDirect Storageのドキュメントは、アーキテクチャでローカルまたはリモートのストレージとGPUメモリの間に直接データパスが必要な場合に役立つ情報源です。すべてのクラスターがGPUDirect Storageを必要とするわけではありませんが、大規模なデータセットやチェックポイントを移動するチームは、ストレージスタックが通常のものか、最適化されているか、あるいは許容するボトルネックなのかを明確に判断すべきです。

コントロールプレーン：Kubernetes、Slurm、またはその両方

コントロールプレーンはハードウェアをプラットフォームへと変えます。誰が何を実行できるか、ジョブをいつ開始するか、障害をどのように再試行するか、チームが利用状況をどう把握するかを決定します。

Kubernetes GPUクラスターアーキテクチャ

Kubernetesは、サービスのデプロイ、マルチテナントの名前空間、コンテナネイティブなワークフロー、API主導の自動化、ポリシー、クラウドネイティブな可観測性との統合が必要なGPUプラットフォームに適しています。本番環境のkubernetes gpu cluster architectureには通常、次が含まれます:

ノードイメージとブートストラップ自動化。
GPU Operator、またはベンダー固有のドライバー/デバイスプラグイン管理。
GPU公開のためのデバイスプラグインまたはDynamic Resource Allocation。
名前空間、RBAC、シークレット、イメージのプルポリシー、ネットワークポリシー。
Jobs、Deployments、RayJob、学習オペレーター、または推論サービス。
バッチの公平性が重要な場合のKueueまたは他のキューイング層。
チーム、プロジェクト、環境、または顧客ごとのクォータ。
DCGM、Prometheus、ログ、トレース、請求ラベル。
イメージ、特権付きワークロード、ホストマウント、GPU共有に対するアドミッションコントロール。

Kubernetesのデバイスプラグインは、GPUを拡張リソースとして公開します。Kubernetes Dynamic Resource Allocationは、デバイスやその他の特殊リソースに対して、より豊富なクレームベースのリソースモデルを追加します。Kueueは、バッチおよびAI/MLスケジューリング向けに、workloads、queues、cohorts、resource flavors といったジョブキューイングの概念を追加します。これらを組み合わせることで、GPUプールをSSHでアクセスできる機械の集合ではなく、統制されたプラットフォームにできます。

Slurm GPUクラスターアーキテクチャ

Slurmは、キュー、パーティション、アカウンティング、予約、バッチジョブを中心に構築されているため、多くのHPCスタイルや研究環境に適しています。SlurmのGRESドキュメントはGPUリソースと、ジョブがそれをどのように要求するかを扱っています。

Slurmは次のような場合にしばしば有力な選択肢になります:

ユーザーがバッチ学習ジョブを送信する。
キューポリシーが中心である。
チームにすでにHPC運用の経験がある。
ワークロードがサービス指向ではない。
MPI、NCCLのテスト、バッチアカウンティングが馴染みのある運用単位である。

組織によっては両方を運用します。研究や大規模学習キューにはSlurmを、推論サービスやプラットフォームAPIにはKubernetesを使うのです。これは可能ですが、アイデンティティ、データアクセス、可観測性、コスト配分を両システムにまたがって設計している場合に限ります。

可観測性とコスト管理は最初の設計に含める

クラスターが稼働してからテレメトリを追加してはいけません。エンジニアリングと財務にとって重要な問いは予測できます:

どのジョブがどのGPUを使用したか?
どの名前空間、チーム、顧客、モデル、または実験が支出の原因だったか?
割り当てられたGPU時間だけでなく、有効な利用率はどれくらいだったか?
キューでの待機時間はどれくらいだったか?
どの失敗が最も多くのGPU-hoursを消費したか?
どのストレージまたはネットワークのボトルネックがGPUをアイドルにしたか?
完了した実行または受け入れられた出力1件あたりのコストはいくらだったか?

最低限のテレメトリには次を含めるべきです:

GPU利用率、メモリ利用率、電力、温度、ECCイベント。
ジョブごとの実行時間、キュー時間、再試行回数、終了理由、所有者。
ネットワークファブリックの健全性とベンチマーク履歴。
ストレージのスループット、レイテンシ、チェックポイント時間、復元時間。
スケジューラの割り当てイベントとクォータ拒否。
事業部門にひもづく請求ラベルまたは使用量エクスポート。

ここではFlatkeyのモデル/APIベースラインが重要です。マネージドなモデルAPIが、より明確な単価とより少ない運用負担で同じ受け入れ可能な出力を生成するなら、クラスターはアイドル時間、再試行、ストレージ、労務を加味したうえでそのベースラインを上回らなければなりません。

セキュリティ、分離、アクセス設計

GPUクラスターは、最初はエンジニアリングプロジェクトとして始まり、共有インフラへと発展することがよくあります。アクセス設計をアーキテクチャの一部として扱ってください。

次を定義します:

認証とIDのソース。
名前空間、プロジェクト、またはアカウントの分離。
SSHポリシー（ある場合）。
コンテナイメージレジストリ、署名、スキャン。
シークレット管理。
ネットワークの送信（egress）ポリシー。
ジョブ後のデータ削除とクリーンアップ。
監査ログの保持期間。
ブレークグラスアクセス。
ベンダーサポートアクセスとリモートハンズのワークフロー。

マルチテナントクラスターでは、GPU共有を許可するかどうかを決めてください。フルGPU割り当てのほうがシンプルです。MIG、vGPU、またはタイムスライシングは利用率を改善できますが、分離、テレメトリ、スケジューリング、パフォーマンスの期待値も変わります。

クラスターサイジング：アーキテクチャを数値に落とし込む

サイジングは有効な単位を基準にすべきです:

required_gpu_capacity =
  target_work_completed_per_month
  / useful_work_per_gpu_month_after_failures_idle_and_retries

次に、それを厳しく検証します:

サイジングの質問	重要な理由
割り当てられているだけでなく、実際に役立つ利用率はどれくらいか？	アイドル状態の予約や失敗した実行は、製品の成果に寄与しません。
許容できる最長のキュー待ち時間はどれくらいか？	安価なクラスターでも、ローンチや学習の時間枠を逃すことがあります。
実行中に1台のノードが故障したらどうなるか？	再起動時間は実効スループットを変えます。
モデルを別のGPUクラスに移行できるか？	ハードウェアの契約は、モデルのアーキテクチャより長く続くことがあります。
拡張のリードタイムはどれくらいか？	GPU需要は調達よりも速く変化することがあります。
終了時の経路は何か？	再販、契約終了、データクリーンアップ、移行コストも判断に含めるべきです。

コストモデルとしては、この記事を GPUクラスターTCOワークシートに接続してください:

effective_cluster_unit_cost =
  (compute + network + storage + support + operations + idle + retries)
  / accepted workload units

分母は製品に合わせるべきです: 完了した学習実行、受け入れられた推論トークン、生成されたメディアジョブ、検索インデックス更新、または顧客からのリクエスト。

アーキテクチャレビューのチェックリスト

マルチノードGPUクラスターアーキテクチャ図やベンダー見積もりを承認する前に、このチェックリストを使用してください。

領域	合格条件
ワークロード概要	チームがモデル、フレームワーク、スケール形状、データ経路、利用率目標、およびビジネス上の分母を定義している。
Compute	ノード形状にGPUトポロジ、CPU/RAM、ローカルNVMe、NIC、ドライバー/CUDAのライフサイクル、および交換ポリシーが含まれている。
Network	ファブリックの種類、配置、オーバーサブスクリプション、障害ドメイン、およびNCCLまたはサービングのベンチマークが文書化されている。
Storage	データセットのステージング、重みキャッシュ、チェックポイントの書き込み/復元、オブジェクトストレージ、スナップショット、クリーンアップがテストされている。
Scheduler	Kubernetes、Slurm、または混在アーキテクチャに、キュー、クォータ、再試行、ユーザーアクセスの明確な責任分担がある。
Observability	ジョブ、GPU、ファブリック、ストレージ、コストがチームおよびワークロードごとに可視化されている。
Security	ID、シークレット、イメージポリシー、ネットワークポリシー、監査ログ、データクリーンアップが定義されている。
Acceptance test	ベンダーまたは社内チームが本番コンテナを実行し、ネットワークをベンチマークし、チェックポイントを書き込み/復元し、ログをエクスポートできる。
Unit economics	クラスターは、同じ分母を使ってクラウドレンタル、コロケーション、オンプレミス、モデル/APIベースラインと比較される。

開いたままにしておくべき公式リファレンス

アーキテクチャレビューでは、公式ドキュメントをソース確認として使用してください:

ソース	用途
Kubernetes device plugins	GPUのような特殊なハードウェアをKubernetesのスケジューリングにどう公開するか。
Kubernetes Dynamic Resource Allocation	特殊リソース向けのクレームベースの割り当てモデル。
NVIDIA GPU Operator	Kubernetes向けのドライバー、コンテナランタイム、デバイスプラグイン、MIG、GPUテレメトリ管理。
NVIDIA NCCL documentation と NCCL tests	分散通信と実践的なall-reduce検証。
NVIDIA GPUDirect Storage	大規模データとチェックポイントフローにおけるストレージからGPUへのデータ経路に関する考慮事項。
Kueue concepts	バッチおよびAI/MLワークロード向けのKubernetesネイティブなキューイング概念。
Slurm GRES	SlurmにおけるGPUリソース、アカウンティング、ジョブ要求。

これらはアーキテクチャの参考資料として扱い、実際に運用するそのクラスターでの受け入れテストの代わりにはしないでください。

GPUクラスターが誤ったアーキテクチャである場合

GPU時間単価が魅力的に見えるという理由だけでクラスターを構築したり予約したりしないでください。次のような場合、直接的なGPUクラスターは誤ったアーキテクチャかもしれません:

製品が必要としているのはモデル出力だけである。
モデルの組み合わせが毎週変わる。
チームがドライバー、スケジューラー、ストレージ、ネットワーキング、インシデントを運用できない。
ワークロードがバースト的で利用率が低い。
計算よりもデータ移動が支配的である。
ベンチマークの証拠がない段階で、調達が3年契約を求めている。
財務部門がクラスター費用を受け入れられた出力に紐づけられない。

そのような場合は、まずクラウドGPUレンタル価格、サーバーレスGPU、またはモデルAPIを比較してください。適切なアーキテクチャとは、最大のアクセラレータ在庫を持つものではなく、信頼できる受け入れ済み出力を最も低い総運用コストで提供するものです。ベンダーレベルの市場調査としては、見積もりを依頼する前に GPUクラウド比較を使用してください。

最終的なまとめ

強力なGPUクラスターアーキテクチャとは、システム設計です。つまり、ワークロードに適したコンピュートノード、ベンチマークで実証されたネットワークファブリック、GPUを飢えさせないストレージ、そして使用量のスケジューリング、保護、可観測化、チャージバックを行えるコントロールプレーンです。

小規模な実験では、まずレンタルまたはマネージドAPIから始めてください。本格的なマルチノード学習やプライベート推論では、プロバイダー、ラック、または予約を決める前に、上記の図とチェックリストを確認してください。高くつく失敗は、Slurmの代わりにKubernetesを選ばなかったことでも、H200の代わりにH100を選ばなかったことでもありません。高くつく失敗は、アーキテクチャがその容量を有用な作業に変えられることを証明する前に、GPU容量を購入してしまうことです。