ワークロードがGPUとCPUのどちらに適しているかを決定します。
大規模並列計算（ディープラーニングのトレーニング/推論、行列演算、シミュレーション）→ GPU。逐次処理、分岐の多い制御ロジック、OSタスク、軽いI/O → CPU。
理由: GPUは、並列SIMTワークのスループットに最適化された数千のコアを備えています。CPUは、レイテンシに敏感な逐次ロジックで優位に立ちます。ほとんどのAIシステムでは両方を組み合わせて使用します。
最終確認：2026年6月
NCA-AIIO 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
ワークロードがGPUとCPUのどちらに適しているかを決定します。
大規模並列計算（ディープラーニングのトレーニング/推論、行列演算、シミュレーション）→ GPU。逐次処理、分岐の多い制御ロジック、OSタスク、軽いI/O → CPU。
理由: GPUは、並列SIMTワークのスループットに最適化された数千のコアを備えています。CPUは、レイテンシに敏感な逐次ロジックで優位に立ちます。ほとんどのAIシステムでは両方を組み合わせて使用します。
NVIDIAのビルディングブロックを選択します。完全なアプライアンスか、OEMシステム向けボードか。
ターンキー統合AIサーバー（GPU + CPU + NVLink + ネットワーキング + ソフトウェア）→ DGX。OEMやクラウドプロバイダーがサーバーを構築するためのGPUベースボード → HGX。
理由: DGXはNVIDIA'sのすぐに使えるリファレンスシステムです。HGXは、ハイパースケーラーが自社で統合するマルチGPUボードです。
1つのサーバー内のGPUが、バスが提供する以上の高速なGPU-to-GPU帯域幅を必要とします。
高帯域幅のノード内GPUインターコネクトにはNVLink（および全対全接続にはNVSwitch）を使用します。NVLinkが利用できない場合はPCIeがフォールバックとなります。
理由: NVLinkはPCIeよりもはるかに高いGPU-to-GPU帯域幅と低いレイテンシを提供します。これは、ノード内でのモデル並列および大規模バッチトレーニングにとって極めて重要です。
ノード内の8つのGPUすべてが、同時にフルNVLink帯域幅で相互に通信する必要があります。
NVSwitch — すべてのGPUを他のすべてのGPUにフルNVLink速度で接続するノンブロッキングスイッチファブリック。
理由: ポイントツーポイントNVLinkだけでは全対全帯域幅は提供されません。NVSwitchは、フルメッシュGPU通信のためのクロスバーを提供します。
スケールアップ（サーバー内）とスケールアウト（サーバー間）のインターコネクトを区別します。
ノード内のスケールアップGPUインターコネクト → NVLink/NVSwitch。クラスター内のノード間スケールアウト → InfiniBand（またはRoCE Ethernet）。
理由: NVLinkはノード内接続です。InfiniBandはノードをクラスターに接続し、マルチノード分散トレーニングを可能にします。
集合演算のレイテンシが最も重要となる大規模分散トレーニング向けのクラスターファブリックを選択します。
最低レイテンシ、インネットワークコンピュート（SHARP）、RDMAネイティブ → InfiniBand。なじみがあり、低コスト、広範なエコシステム → Spectrum-X Ethernet上のRoCE。
理由: SHARPを搭載したInfiniBandはall-reduceをスイッチにオフロードし、集合演算のレイテンシを削減します。Spectrum-XはNVIDIA'sのAIファブリック向けEthernetソリューションです。
ネットワーク、ストレージ、セキュリティ処理をCPUからオフロードし、AI計算のためにコアを解放します。
NVIDIA BlueField DPU — ホストCPU/GPUからインフラストラクチャサービスをオフロードおよび分離するプログラマブルなデータ処理ユニット。
理由: DPUは、東西のネットワーキング、NVMe-oFストレージ、ゼロトラストセキュリティを高速化し、効果的なGPU/CPU利用率とテナント分離を向上させます。
DPUによる完全なオフロードなしでGPUノード用の高速RDMA NICが必要です。
NVIDIA ConnectX SmartNIC — RDMAおよびGPUDirectをサポートする高スループットInfiniBand/Ethernetアダプター。
理由: ConnectXはラインレートRDMAを提供します。BlueFieldは、完全なインフラストラクチャオフロードのために、その上にプログラマブルなArmサブシステムを追加します。
CPU/ホストメモリを介さずにデータをGPUメモリに直接移動させることで、レイテンシを削減します。
GPUDirect RDMA — NICがGPUメモリを直接読み書きします。GPUDirect StorageはNVMeストレージに対しても同様の機能を提供します。
理由: CPUバウンスバッファをバイパスすることで、データパス上のコピーとレイテンシが排除され、マルチノードトレーニングのスループットにとって不可欠です。
大規模モデルトレーニング向けに、現行世代のデータセンターGPUアーキテクチャを選択します。
Hopper（H100/H200）はTransformer Engine + FP8を搭載した確立された世代です。Blackwell（B200/GB200）は、より高いスループットとFP4を備えた最新世代で、最大のモデル向けです。
理由: 両方ともTransformerワークロードをターゲットとしています。Blackwellはスケールと低精度（FP4）推論をさらに推進します。予算とモデルサイズに合わせて選択してください。
ディープラーニングの行列計算を高速化するハードウェアを特定します。
Tensor Cores — 混合精度（FP16/BF16/FP8/FP4）で融合行列積和演算を実行する特殊なユニットです。
理由: これらは、標準のCUDAコアよりもGEMM/畳み込みで桁違いに高いスループットを提供し、DLのパフォーマンスを向上させます。
大規模モデルが収まらない。計算ではなくメモリ帯域幅がボトルネックです。
より大容量で高速なHBM（例: HBM3eを搭載したH200/B200）を備えたGPUを選択します。1つのGPU'sのメモリが不十分な場合は、マルチGPUモデル並列処理を使用します。
理由: 大規模モデルのトレーニング/推論は、多くの場合メモリ容量と帯域幅によって制約されます。HBMはGPUが必要とする高帯域幅を提供します。
エンタープライズトレーニング向けに、ターンキーで検証済みのマルチラックAIスーパーコンピュータを構築します。
NVIDIA DGX SuperPOD — DGXノード、InfiniBandファブリック、ストレージ、およびBase Commandソフトウェアのリファレンスアーキテクチャ。
理由: SuperPODは事前に検証されたフルスタック設計です。これにより、大規模なファブリック、ストレージ、オーケストレーションの配線における推測作業が不要になります。
ハードウェアを所有せずにDGXクラスのトレーニング容量を取得します。
NVIDIA DGX Cloud — 主要なクラウドプロバイダーでホストされ、サービスとしてアクセスできるマネージドAIトレーニングインフラストラクチャ。
理由: OpEx vs. CapEx: DGX Cloudはバースト的または短期的なトレーニングに適しています。オンプレミスのDGX/SuperPODは、持続的な高利用率とデータグラビティの制約に適しています。
AIワークロード向けに、オンプレミスGPUクラスターとクラウドGPUのどちらかを選択します。
持続的な高利用率、データ主権、予測可能な支出 → オンプレミスDGX/SuperPOD。変動的/バースト的な需要、迅速な開始、データセンターのフットプリント不要 → クラウドまたはDGX Cloud。
理由: 所有するGPUは、高い定常利用率でのみ減価償却が良好です。アイドル状態の所有ハードウェアは純粋なコストです。
新しいGPUクラスターが、既存のデータセンターのラック電力および冷却予算を超過しています。
最新のGPUには高密度電力（1ラックあたり数十kW）と液冷を計画し、設置前にPDU、バスウェイ、熱容量を評価してください。
理由: 最新のGPUノード（およびGB200ラック）は、従来のサーバーよりもはるかに多くの電力と熱を消費します。空冷や標準的なPDUでは対応できないことがよくあります。
データパイプラインがGPUに十分な速度でデータを供給できないため、トレーニングが停止します。
GPUDirect Storageを備えた高スループットの並列/NVMeストレージを使用し、GPUを飽和状態に保つために持続的な読み取り帯域幅を確保します。
理由: プロビジョニング不足のストレージI/Oは、高価なGPUをデータを待つアイドル状態のままにします。ストレージ層はGPUの総読み取り要求と一致させる必要があります。
モデルが大きすぎて、許容できる時間内に単一ノードでトレーニングできません。
データ/テンソル/パイプライン並列処理を使用して、InfiniBand経由で複数のノードにスケールアウトします。NCCLがGPUの集合通信を処理します。
理由: マルチノードスケーリングには、低レイテンシのファブリックと最適化された集合通信ライブラリ（NCCL）が必要です。低速なファブリックはスケーリング効率を著しく低下させます。
単一のA100/H100では小さな推論ジョブには過剰です。ハードウェア分離されたスライスが必要です。
Multi-Instance GPU（MIG） — 1つのGPUを最大7つの分離されたインスタンスに分割し、それぞれに専用の計算リソースとメモリを割り当てます。
理由: MIGは、ソフトなタイムスライシングとは異なり、マルチテナント推論に対して真のハードウェア分離と予測可能なQoSを提供します。
AI、機械学習、ディープラーニングを区別します。
AIは広範な目標です。MLはデータから学習するサブセットであり、DLは多層ニューラルネットワークを使用するMLのサブセットです。
理由: これらは入れ子関係にあります: DL ⊂ ML ⊂ AI。ニューラルネットワークは大規模に並列処理されるため、DLが現代のGPU需要を牽引しています。
トレーニングと推論の計算プロファイルを区別します。
トレーニング = 計算量が多くメモリを消費し、長時間実行されるバッチ処理で、多くのGPUを使用。推論 = レイテンシに敏感で軽量、多くの場合単一/部分的なGPUを使用し、本番環境で継続的に実行。
理由: これらは異なるハードウェアとスケーリング要件を持っています。クラスターのサイズ決定には、これら2つのワークロードを区別する必要があります。
学習パラダイムを選択します。ラベル付きデータ、ラベルなしデータ、または報酬主導の試行錯誤。
ラベル付き → 教師あり学習。ラベルなしのクラスタリング/構造 → 教師なし学習。agentが報酬から学習 → 強化学習。
理由: 所有するデータ（および目標）がパラダイムを決定します。RLHFは、LLMを調整するために人間のフィードバックによって導かれる強化学習です。
ニューラルネットワークがGPUにうまくマッピングされる理由を説明します。
これらは重み付き行列乗算と非線形活性化の層であり、GPUが効率的に実行する高密度並列線形代数です。
理由: 順伝播/逆伝播はGEMM負荷が高く、Tensor Coresがこれを正確に高速化するため、DLはGPU上で実行されます。
現代のLLMと生成AIの背後にあるアーキテクチャを特定します。
Transformer — データとパラメータとともにスケーリングするアテンションベースのアーキテクチャ。foundation modelsとLLMはこれに基づいて構築されています。
理由: Transformerは高度に並列化可能であり、これが大規模GPUクラスターとTransformer Engineハードウェアの需要を牽引する理由です。
精度を著しく損なうことなく、トレーニングを高速化し、メモリ使用量を削減します。
混合精度を使用します — 計算にはFP16/BF16（Hopper/BlackwellではFP8）、累積にはFP32を使用します。Tensor Coresが低精度演算を高速化します。
理由: 低精度化によりメモリは半分になり、スループットは向上します。ロススケーリング / BF16は数値安定性を維持します。
ソフトウェアをNVIDIA GPU上で実行可能にする基盤を挙げてください。
CUDA — NVIDIA'sの並列計算プラットフォームとプログラミングモデル。CUDA-Xはライブラリ層（cuDNN、cuBLAS、NCCL、RAPIDSなど）です。
理由: PyTorch/TensorFlowのようなフレームワークは内部でCUDA-Xライブラリを呼び出します。CUDAはAIソフトウェアをNVIDIA GPUに結びつける堀です。
フレームワーク内でディープラーニングプリミティブ（畳み込み、アテンション）を高速化します。
cuDNNはGPU最適化されたDLプリミティブを提供し、cuBLASは高密度線形代数を処理します。両方ともPyTorch/TensorFlowの下にあります。
理由: これらのライブラリがあるため、CUDAカーネルを自分で記述することなく、フレームワークがGPU速度を得ることができます。
NVIDIA最適化され、GPU対応のコンテナ、モデル、Helmチャートを取得します。
NGC（NVIDIA GPU Cloud）カタログ — 最適化されたコンテナ（フレームワーク、NIM、Triton）、事前学習済みモデル、SDKのキュレーションされたレジストリ。
理由: NGCコンテナはNVIDIA GPU向けに調整およびテスト済みで提供されるため、依存関係やドライバー互換性の推測作業が不要になります。
複数のフレームワークからの多くのモデルを、1つの標準化されたGPU効率的なエンドポイントの背後で提供します。
NVIDIA Triton Inference Server — 動的バッチ処理、同時モデル実行、GPU共有を備えたマルチフレームワークモデル提供。
理由: Tritonは、モデルごとに1つのプロセスを使用するのではなく、バッチ処理とモデルの同時実行によって推論のためのGPU利用率を最大化します。
基盤モデルを、本番環境に対応した最適化された推論マイクロサービスとして迅速にデプロイします。
NVIDIA NIM — 最適化されたエンジンと標準APIを備え、一般的なモデル向けに事前構築されたコンテナ化された推論マイクロサービス。
理由: NIMは、モデル + 最適化されたランタイム（TensorRT-LLM/Triton） + APIを1つのデプロイ可能なユニットにパッケージ化し、製品化までの時間を短縮します。
トレーニング済みモデルの推論レイテンシを削減し、スループットを向上させます。
モデルをTensorRT（LLMの場合はTensorRT-LLM）でコンパイルします — レイヤー融合、精度キャリブレーション（INT8/FP8）、およびカーネル自動チューニング。
理由: TensorRTはターゲットGPU向けに最適化された推論エンジンを生成し、生のフレームワークと比較してスループットを大幅に向上させることがよくあります。
pandas/scikit-learnスタイルのデータ準備と従来のMLをGPUで高速化します。
NVIDIA RAPIDS — cuDF (DataFrames)、cuML (ML)、cuGraph (graphs) は、データサイエンスワークフローをGPU上で実行します。
理由: RAPIDSは表形式のETLと従来のMLをGPU上で実行し、パイプラインにおけるCPUのボトルネックを回避します。
DGX/SuperPODクラスター全体のAIワークロード、ジョブ、およびユーザーを管理します。
NVIDIA Base Command — DGXインフラストラクチャ向けのジョブスケジューリング、クラスター管理、およびワークロードオーケストレーション。
理由: Base CommandはDGXシステムの運用制御プレーンです。マルチユーザーのジョブ投入とリソース追跡を処理します。
エンタープライズSLAを備えた、サポートされ、セキュアで、本番環境対応のAIソフトウェアが必要です。
NVIDIA AI Enterprise — セキュリティパッチとエンタープライズサポートを備えた、サポート対象のソフトウェアスイート（フレームワーク、NIM、Triton、RAPIDS、GPU Operator）。
理由: これは、検証済みのスタックをサポートとライフサイクル保証とともにバンドルしており、規制対象/本番環境で必要とされます。
基盤モデルと、チームがそれをどのように適応させるかを定義します。
広範なデータで事前学習された大規模モデルで、ゼロからトレーニングするのではなく、プロンプティング、RAG、またはファインチューニングによって多くのタスクに適応可能です。
理由: 適応（プロンプト/RAG/ファインチューニング）は事前学習よりもはるかに安価です。ほとんどの企業はfoundation modelsを構築するのではなく、利用します。
LLMベースのアプリケーションにプライベート/現在の知識を追加します。
頻繁に変化する事実 → RAG（推論時にvector storeから取得）。新しい振る舞い/スタイル/domain skillを教える → fine-tuning。
理由: RAGはデータを外部に保ち、再トレーニングなしで更新可能です。fine-tuningは振る舞いを重みに焼き付け、更新に費用がかかります。
高価なGPUが効率的に使用されているかを判断します。
GPU使用率、メモリ使用量、SM/Tensor-Coreアクティビティを追跡します。低い使用率は、データパイプライン、バッチサイズ、またはスケジューリングのボトルネックを示します。
理由: ウォールクロック上のGPUが「ビジー」であっても、実際の計算効率が低い場合があります。利用率ゲージだけでなく、Tensor-Core/SMの占有率も確認してください。
クラスター全体のGPUの健全性、利用率、温度、電力、およびエラーを監視します。
NVIDIA DCGM (Data Center GPU Manager) — テレメトリ、ヘルスチェック、および診断。Prometheus/Grafanaにメトリックをエクスポートします。
理由: DCGMは標準的なGPUテレメトリソースです。DCGM Exporterは、クラスター全体のダッシュボードとアラートのためにPrometheusにデータを供給します。
Kubernetesクラスター上で、ノードごとの手動設定なしにGPUドライバー、コンテナツールキット、および監視をプロビジョニングします。
NVIDIA GPU Operator — Kubernetes上でのドライバー、コンテナランタイム、デバイスプラグイン、DCGM、およびMIGの設定を自動化します。
理由: これはGPUソフトウェアの完全なライフサイクルを宣言的に管理し、脆弱なノードごとのドライバーインストールを不要にします。
GPUワークロード用のオーケストレーターを選択します。
マイクロサービス/推論、クラウドネイティブ、混合ワークロード → Kubernetes。バッチHPCスタイルのトレーニングジョブ、gang scheduling、従来のクラスター → Slurm。
理由: Kubernetesは長時間実行サービスと弾力性に優れています。SlurmはMPIスタイルのスケジューリングを備えたキューイングされたバッチジョブに優れています。
Kubernetes PodはGPUを要求し、GPUにスケジューリングされる必要があります。
NVIDIAデバイスプラグインはGPUをスケジューリング可能なリソースとしてアドバタイズします。Podは`nvidia.com/gpu`を要求し、スケジューラーがそれらを配置します。
理由: デバイスプラグインがなければ、KubernetesはGPUを認識または割り当てることができません。これがGPUをファーストクラスのリソースにするものです。
多くの小さなジョブ/ユーザーがGPUを共有して利用率を向上させる必要があります。
ハードウェア分離 → MIG。1つのGPUのソフト共有 → タイムスライシングまたはMPS。公平性のためにネームスペースクォータと組み合わせます。
理由: MIGはQoS保証を提供します。タイムスライシング/MPSは分離なしでGPUをオーバーサブスクライブします。分離要件に応じて選択してください。
共有クラスターで、高優先度トレーニングが低優先度実験をプリエンプトする必要があります。
スケジューラーで優先度/プリエンプションとキュー（Slurmパーティションまたはクォータ付きKubernetes PriorityClasses）を使用します。マルチGPUジョブはgang-scheduleします。
理由: gang schedulingは部分割り当てのデッドロックを防ぎます。優先度クラスは、競合するGPU上のビジネス順序を強制します。
ノード間でGPUドライバー、CUDA、およびコンテナツールキットのバージョンを一貫させ、互換性を持たせます。
GPU Operator（Kubernetes）またはNGCコンテナを介して標準化します。ドライバーをフレームワークが必要とするCUDAバージョンに合わせ、メンテナンス期間中に更新をロールアウトします。
理由: ドライバー/CUDA/フレームワークの不一致は、クラスター障害の主要な原因です。コンテナに固定されたCUDAは、サポートされる範囲内でアプリをホストドライバーから分離します。
予測されるトレーニングおよび推論の需要に合わせてGPUクラスターのサイズを決定します。
トレーニング（ピーク、バッチ）と推論（持続的、レイテンシ制約）を分離します。電力/冷却/ファブリックのヘッドルームを計画し、高い定常利用率を目標とします。
理由: 過剰なサイジングはアイドルGPUにCapExを浪費し、過少なサイジングは提供を妨げます。単一のピークではなく、ワークロードの組み合わせに合わせて計画してください。
GPUは持続的な高負荷下でスロットリングを起こしたり、故障したりします。
DCGMを介して温度と電力を監視します。適切な冷却（高密度ラックには液冷）を確保し、適切な電力制限を設定し、熱しきい値でアラートを送信します。
理由: 熱スロットリングは黙ってスループットを低下させます。プロアクティブなテレメトリと冷却設計は、パフォーマンスとハードウェア寿命の両方を保護します。
共有ハードウェアから複数のVMまたはVDIユーザーにGPUアクセラレーションを提供します。
NVIDIA vGPUソフトウェアは、スケジューリングと分離機能を備え、物理GPUを複数のVMに分割します。MIGは、ハードパーティショニングのためにvGPUプロファイルをバックアップできます。
理由: vGPUは、ベアメタルパススルーでは共有できない仮想化/マルチテナントGPUアクセス（VDI、クラウド）を可能にします。
ノードがXidエラーまたは失敗したジョブを返します。これ以上実行が破損する前に、不良GPUを隔離する必要があります。
DCGM診断とアクティブなヘルスチェックを実行します。ノードをコードン/ドレインし、GPUを交換またはリセットしてから、プールに戻します。
理由: XidエラーとECC障害は故障しているGPUを示します。自動ヘルスゲーティングは、不良GPUがスケジューリングプールを汚染するのを防ぎます。