LG U+ GPU Software Engineer完全合格ガイド：CUDA・vGPU・InfiniBandからK8s GPUスケジューリングまで

SM (Streaming Multiprocessor)
├── CUDA Cores (INT32 + FP32)
│   └── H100: SM当たり128個のFP32コア
├── Tensor Cores
│   └── H100: SM当たり第4世代Tensor Core (FP8対応)
├── RT Cores (Ray Tracing, データセンターでは未使用)
├── Warp Scheduler (4個)
│   └── 各スケジューラが独立してwarpをディスパッチ
├── Register File (256KB per SM in H100)
├── Shared Memory / L1 Cache (統合、最大228KB)
├── Load/Store Units
├── Special Function Units (SFU)
│   └── sin, cos, expなど超越関数の計算
└── Texture Units

Grid (全体の作業)
├── Block 0
│   ├── Warp 0  (Thread 0~31)   → 同じ命令を同時実行
│   ├── Warp 1  (Thread 32~63)  → 同じ命令を同時実行
│   └── Warp N  ...
├── Block 1
│   ├── Warp 0
│   └── ...
└── Block M

// 悪い例: Warp Divergence発生
__global__ void kernel(float* data, int n) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx % 2 == 0) {
        data[idx] = expensive_operation_A(data[idx]);
    } else {
        data[idx] = expensive_operation_B(data[idx]);
    }
    // Warp内の偶数/奇数スレッドが異なる分岐 → 逐次実行
}

// 良い例: 同一Warp内のスレッドが同じ分岐を取るよう設計
__global__ void kernel_optimized(float* data, int n) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    int warp_id = idx / 32;
    if (warp_id % 2 == 0) {
        data[idx] = expensive_operation_A(data[idx]);
    } else {
        data[idx] = expensive_operation_B(data[idx]);
    }
    // 同一Warpの全スレッドが同じ分岐
}

NVLinkトポロジ (DGX H100基準):
GPU 0 <── NVLink 4.0 (900GB/s) ──> GPU 1
  |                                    |
  NVSwitch (完全接続)               NVSwitch
  |                                    |
GPU 2 <── NVLink 4.0 (900GB/s) ──> GPU 3
  |                                    |
  ...           8-GPU 完全接続         ...
GPU 6 <── NVLink 4.0 (900GB/s) ──> GPU 7

総帯域幅: 8 GPU x 900GB/s = 7.2TB/s (双方向)

メモリ階層 (速い → 遅い):

1. Register (最速)
   ├── 容量: スレッド当たり最大255個 (32ビット)
   ├── 遅延: ~1 cycle
   ├── 帯域幅: 無限 (ALUに直接接続)
   └── 特徴: コンパイラが自動割り当て、超過時local memoryにspill

2. Shared Memory
   ├── 容量: SM当たり48KB ~ 228KB (設定可能)
   ├── 遅延: ~5 cycles (register比 ~5x遅い)
   ├── 帯域幅: ~19TB/s (H100基準)
   ├── 特徴: 同一Block内のスレッド間で共有
   └── 注意: Bank Conflict発生の可能性

3. L1 Cache
   ├── Shared Memoryと統合 (設定で比率調整)
   ├── H100: Shared Memory + L1 = 228KB per SM
   └── 自動キャッシュ、プログラマが直接制御しない

4. L2 Cache
   ├── 容量: H100 = 50MB (全SM共有)
   ├── 遅延: ~200 cycles
   └── A100: 40MB, Blackwell: 最大128MB

5. Global Memory (HBM)
   ├── 容量: 40GB ~ 192GB
   ├── 遅延: ~600 cycles (register比 ~600x遅い)
   ├── 帯域幅: 2.0 ~ 8.0 TB/s (世代別)
   └── すべてのスレッドからアクセス可能

Arithmetic Intensity (算術強度) = FLOPs / Bytes Accessed

H100基準:
- Peak Compute: 989 TFLOPS (FP16 Tensor)
- Peak Memory BW: 3.35 TB/s

均衡点 (Roofline分析):
  989 TFLOPS / 3.35 TB/s = 295 FLOPs/Byte

→ 算術強度が295より低ければMemory-Bound
→ 算術強度が295より高ければCompute-Bound

実際の例:
- ベクトル加算: 1 FLOP / 12 Bytes = 0.08 → 極度にMemory-Bound
- 行列乗算 (NxN): 2N FLOPs / 8 Bytes ≈ O(N) → Nが大きければCompute-Bound
- Transformer Attention: 通常Memory-Bound (特に推論時)

// 良い例: Coalesced Access (連続アクセス)
// Thread 0 → data[0], Thread 1 → data[1], ..., Thread 31 → data[31]
__global__ void coalesced(float* data) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    float val = data[idx];  // 128-byteトランザクション1つ
}

// 悪い例: Strided Access (非連続アクセス)
// Thread 0 → data[0], Thread 1 → data[32], ..., Thread 31 → data[31*32]
__global__ void strided(float* data, int stride) {
    int idx = (blockIdx.x * blockDim.x + threadIdx.x) * stride;
    float val = data[idx];  // 32個の個別トランザクション！
}

Shared Memoryバンク構造 (4バイト単位):
Bank 0: addr 0, 128, 256, ...
Bank 1: addr 4, 132, 260, ...
Bank 2: addr 8, 136, 264, ...
...
Bank 31: addr 124, 252, 380, ...

Bank Conflictの例:
Thread 0 → Bank 0 (addr 0)
Thread 1 → Bank 0 (addr 128)  ← 同じバンク！ 衝突
→ 2-way bank conflict: 2倍遅くなる

回避方法: パディング追加
__shared__ float tile[32][33];  // 33にパディング (32の代わりに)
// 列アクセス時にBank Conflictを回避

CUDA実行モデル:

Grid (1個)
├── Block (0,0)  ──  Block (1,0)  ──  Block (2,0)
├── Block (0,1)  ──  Block (1,1)  ──  Block (2,1)
└── Block (0,2)  ──  Block (1,2)  ──  Block (2,2)

各Block:
├── Thread (0,0) ... Thread (15,0)
├── Thread (0,1) ... Thread (15,1)
└── Thread (0,15) ... Thread (15,15)

制約:
- Block当たり最大1024スレッド
- Block次元: 最大 (1024, 1024, 64)
- Grid次元: 最大 (2^31-1, 65535, 65535)

#include <stdio.h>
#include <cuda_runtime.h>

// GPUカーネル関数
__global__ void vectorAdd(const float* A, const float* B, float* C, int n) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx < n) {
        C[idx] = A[idx] + B[idx];
    }
}

int main() {
    int n = 1 << 20;  // 1M要素
    size_t size = n * sizeof(float);

    // ホストメモリ割り当て
    float *h_A = (float*)malloc(size);
    float *h_B = (float*)malloc(size);
    float *h_C = (float*)malloc(size);

    // 初期化
    for (int i = 0; i < n; i++) {
        h_A[i] = 1.0f;
        h_B[i] = 2.0f;
    }

    // デバイスメモリ割り当て
    float *d_A, *d_B, *d_C;
    cudaMalloc(&d_A, size);
    cudaMalloc(&d_B, size);
    cudaMalloc(&d_C, size);

    // ホスト → デバイスコピー
    cudaMemcpy(d_A, h_A, size, cudaMemcpyHostToDevice);
    cudaMemcpy(d_B, h_B, size, cudaMemcpyHostToDevice);

    // カーネル実行
    int blockSize = 256;
    int gridSize = (n + blockSize - 1) / blockSize;
    vectorAdd<<<gridSize, blockSize>>>(d_A, d_B, d_C, n);

    // デバイス → ホストコピー
    cudaMemcpy(h_C, d_C, size, cudaMemcpyDeviceToHost);

    // 検証
    printf("C[0] = %f (expected 3.0)\n", h_C[0]);

    // メモリ解放
    cudaFree(d_A); cudaFree(d_B); cudaFree(d_C);
    free(h_A); free(h_B); free(h_C);
    return 0;
}

#define TILE_SIZE 32

__global__ void matMul(const float* A, const float* B, float* C, int N) {
    __shared__ float tileA[TILE_SIZE][TILE_SIZE];
    __shared__ float tileB[TILE_SIZE][TILE_SIZE];

    int row = blockIdx.y * TILE_SIZE + threadIdx.y;
    int col = blockIdx.x * TILE_SIZE + threadIdx.x;
    float sum = 0.0f;

    for (int t = 0; t < (N + TILE_SIZE - 1) / TILE_SIZE; t++) {
        // Global Memory → Shared Memoryロード
        if (row < N && t * TILE_SIZE + threadIdx.x < N)
            tileA[threadIdx.y][threadIdx.x] = A[row * N + t * TILE_SIZE + threadIdx.x];
        else
            tileA[threadIdx.y][threadIdx.x] = 0.0f;

        if (col < N && t * TILE_SIZE + threadIdx.y < N)
            tileB[threadIdx.y][threadIdx.x] = B[(t * TILE_SIZE + threadIdx.y) * N + col];
        else
            tileB[threadIdx.y][threadIdx.x] = 0.0f;

        __syncthreads();  // Block内の全スレッド同期

        for (int k = 0; k < TILE_SIZE; k++)
            sum += tileA[threadIdx.y][k] * tileB[k][threadIdx.x];

        __syncthreads();
    }

    if (row < N && col < N)
        C[row * N + col] = sum;
}

# 基本状態確認
nvidia-smi

# 1秒間隔モニタリング
nvidia-smi dmon -s pucvmet -d 1

# GPUプロセス詳細情報
nvidia-smi pmon -d 1

# クエリフォーマット（スクリプトで活用）
nvidia-smi --query-gpu=timestamp,gpu_bus_id,utilization.gpu,utilization.memory,memory.used,memory.total,temperature.gpu,power.draw --format=csv -l 1

# MIG状態確認
nvidia-smi mig -lgi
nvidia-smi mig -lci

# GPUトポロジ確認（NVLink接続状態）
nvidia-smi topo -m

# ECCエラー確認
nvidia-smi --query-gpu=ecc.errors.corrected.volatile.total,ecc.errors.uncorrected.volatile.total --format=csv

# アプリケーション全体のプロファイリング
nsys profile --stats=true -o report python train.py

# CUDA API呼び出し + GPUカーネル + メモリ転送追跡
nsys profile --trace=cuda,nvtx,osrt -o detailed_report python train.py

# 結果可視化 (GUI)
nsys-ui report.nsys-rep

# 特定カーネルの詳細分析
ncu --target-processes all --set full -o kernel_report python train.py

# 特定カーネルのみプロファイリング
ncu --kernel-name "volta_sgemm" --launch-count 10 -o sgemm_report ./my_app

# 主要メトリクス確認
ncu --metrics sm__throughput.avg.pct_of_peak_sustained_active,dram__throughput.avg.pct_of_peak_sustained_active ./my_app

# DCGM起動
sudo systemctl start nvidia-dcgm

# ヘルスチェック
dcgmi health -g 0 -c

# 診断実行 (Level 3: 最も詳細)
dcgmi diag -r 3 -g 0

# メトリクス収集 (Prometheus連携)
dcgm-exporter &
# http://localhost:9400/metrics からPrometheusが収集

GPU Utilization 低い (<50%)
├── CPUボトルネック？
│   ├── データロードが遅い → num_workers増加、prefetch
│   ├── 前処理が重い → DALI（GPU前処理）使用
│   └── Python GIL → マルチプロセシング
├── メモリ転送ボトルネック？
│   ├── PCIe帯域幅飽和 → GPU Direct活用
│   └── 不要なCPU-GPUコピー → 固定メモリ（pinned memory）使用
├── 小さなカーネル + 大きなオーバーヘッド？
│   ├── カーネルラウンチオーバーヘッド → CUDA Graph使用
│   └── 過剰な同期 → 非同期実行最適化
├── バッチサイズが小さい？
│   └── GPUを十分に埋められない → バッチ増加またはGradient Accumulation
└── 通信オーバーヘッド？ (分散学習)
    ├── AllReduce時間が長い → NCCLチューニング
    └── ネットワークボトルネック → InfiniBand確認

Type 1 (Bare-metal):           Type 2 (Hosted):
┌─────────────────┐            ┌─────────────────┐
│   VM1    VM2    │            │   VM1    VM2    │
│ ┌─────┐┌─────┐ │            │ ┌─────┐┌─────┐ │
│ │Guest││Guest│ │            │ │Guest││Guest│ │
│ │ OS  ││ OS  │ │            │ │ OS  ││ OS  │ │
│ └─────┘└─────┘ │            │ └─────┘└─────┘ │
│  Hypervisor     │            │  Hypervisor     │
│  (ESXi, KVM)   │            │  (VirtualBox)   │
│  Hardware       │            │  Host OS        │
└─────────────────┘            │  Hardware       │
                               └─────────────────┘

IOMMUなし (安全でない):
VM → (仮想アドレス) → 物理メモリ (直接アクセス → 他VMのメモリ侵犯可能)

IOMMUあり (安全):
VM → (仮想アドレス) → IOMMU変換 → (物理アドレス、隔離済み)
                     └── DMA要求も隔離！

# IOMMUグループ確認
find /sys/kernel/iommu_groups/ -type l

# カーネルブートパラメータ確認
cat /proc/cmdline | grep iommu
# intel_iommu=on または amd_iommu=on であること

# IOMMUグループ別デバイス確認
for g in /sys/kernel/iommu_groups/*/devices/*; do
    echo "IOMMU Group $(basename $(dirname $(dirname $g))):"
    lspci -nns $(basename $g)
done

PCI Passthroughアーキテクチャ:

Host (Linux + KVM)
├── GPU 0 → VFIOドライババインディング → VM1 (直接アクセス)
├── GPU 1 → VFIOドライババインディング → VM2 (直接アクセス)
├── GPU 2 → NVIDIAドライバ → Host使用
└── GPU 3 → NVIDIAドライバ → Host使用

# 1. IOMMU有効化 (GRUB)
# /etc/default/grub に追加:
# GRUB_CMDLINE_LINUX="intel_iommu=on iommu=pt"

# 2. GPUのPCI ID確認
lspci -nn | grep NVIDIA
# 41:00.0 3D controller [0302]: NVIDIA Corporation A100 [10de:20b2]

# 3. VFIOドライバにバインディング
echo "10de 20b2" > /sys/bus/pci/drivers/vfio-pci/new_id
echo "0000:41:00.0" > /sys/bus/pci/devices/0000:41:00.0/driver/unbind
echo "0000:41:00.0" > /sys/bus/pci/drivers/vfio-pci/bind

# 4. QEMU/KVMでVM起動時にデバイス追加
# -device vfio-pci,host=41:00.0

vGPUアーキテクチャ:

Physical GPU (A100-80GB)
├── vGPU Instance 1 (A100-4C, 4GB) → VM1
├── vGPU Instance 2 (A100-4C, 4GB) → VM2
├── vGPU Instance 3 (A100-8C, 8GB) → VM3
└── ... (残容量分だけ追加可能)

タイムスライシング:
t=0ms  [VM1実行] → t=16ms [VM2実行] → t=32ms [VM3実行] → ...

# vGPUスケジューラタイプ
Equal Share:
  - すべてのvGPUに同一時間を割り当て
  - 公平だが優先度設定不可

Fixed Share:
  - vGPUプロファイルサイズに比例して時間割り当て
  - 4GB vGPU: 8GB vGPU = 1:2 時間

Best Effort:
  - アイドルvGPUの時間をアクティブvGPUに再分配
  - 最も効率的だが性能予測が困難

MIGアーキテクチャ (A100-80GB):

全体GPU: 108 SM, 80GB HBM2e
├── MIG Instance 1 (7g.80gb): 98 SM, 80GB  ← ほぼ全体 (単独使用)
または
├── MIG Instance 1 (4g.40gb): 56 SM, 40GB
├── MIG Instance 2 (3g.40gb): 42 SM, 40GB
または
├── MIG Instance 1 (3g.40gb): 42 SM, 40GB
├── MIG Instance 2 (2g.20gb): 28 SM, 20GB
├── MIG Instance 3 (1g.10gb): 14 SM, 10GB
├── MIG Instance 4 (1g.10gb): 14 SM, 10GB
または (最大分割)
├── MIG Instance 1~7 (1g.10gb): 各14 SM, 各10GB (x7)

# MIG有効化
sudo nvidia-smi -i 0 -mig 1

# 使用可能なMIGプロファイル確認
nvidia-smi mig -lgip

# GPU Instance作成
sudo nvidia-smi mig -i 0 -cgi 9,14,14,14  # 3g.40gb + 1g.10gb x3

# Compute Instance作成
sudo nvidia-smi mig -i 0 -cci

# 現在のMIG状態確認
nvidia-smi mig -lgi
nvidia-smi mig -lci

# MIGインスタンス削除
sudo nvidia-smi mig -i 0 -dci
sudo nvidia-smi mig -i 0 -dgi

# MIG無効化
sudo nvidia-smi -i 0 -mig 0

# MIG設定ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: mig-parted-config
  namespace: gpu-operator
data:
  config.yaml: |
    version: v1
    mig-configs:
      all-1g.10gb:
        - device-filter: ["0x20B210DE"]
          devices: all
          mig-enabled: true
          mig-devices:
            "1g.10gb": 7
      mixed-config:
        - device-filter: ["0x20B210DE"]
          devices: all
          mig-enabled: true
          mig-devices:
            "3g.40gb": 1
            "1g.10gb": 4

SR-IOV構造:

Physical NIC (ConnectX-7)
├── PF (Physical Function): ホストドライバ管理
├── VF 0 (Virtual Function) → VM1 (直接割り当て、ネイティブ性能)
├── VF 1 → VM2
├── VF 2 → VM3
└── ... (最大128個VF)

長所:
- 仮想ブリッジなしでVMがNICに直接アクセス
- ネイティブに近いネットワーク性能
- CPUオーバーヘッド最小化

GPU Direct RDMAとの組み合わせ:
VM内GPU <-> VF(SR-IOV NIC) <-> InfiniBand <-> リモートGPU
   (PCIe直接)  (SR-IOVバイパス)  (RDMA)

# KubeVirt VMにGPU PCI Passthrough
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: gpu-vm
spec:
  running: true
  template:
    spec:
      domain:
        devices:
          hostDevices:
            - name: gpu
              deviceName: nvidia.com/A100
        resources:
          requests:
            memory: '32Gi'
            cpu: '8'
      volumes:
        - name: rootdisk
          containerDisk:
            image: quay.io/containerdisks/ubuntu:22.04

# KubeVirt VMにvGPU割り当て
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vgpu-vm
spec:
  template:
    spec:
      domain:
        devices:
          gpus:
            - name: vgpu
              deviceName: nvidia.com/NVIDIA_A100-4C
        resources:
          requests:
            memory: '16Gi'

InfiniBand速度の進化:
SDR  (2001):   10 Gbps
DDR  (2005):   20 Gbps
QDR  (2008):   40 Gbps
FDR  (2011):  56 Gbps
EDR  (2014): 100 Gbps
HDR  (2018): 200 Gbps
NDR  (2022): 400 Gbps
XDR  (2024): 800 Gbps
GDR  (2026): 1.6 Tbps (予定)

InfiniBandファブリック構造:

Leaf Switch (ToR)
├── HCA (Host Channel Adapter) ─ Server 1 [GPU 0~7]
├── HCA ─ Server 2 [GPU 0~7]
├── HCA ─ Server 3 [GPU 0~7]
└── HCA ─ Server 4 [GPU 0~7]

Spine Switch
├── Leaf Switch 1
├── Leaf Switch 2
├── Leaf Switch 3
└── Leaf Switch 4

管理要素:
- Subnet Manager (OpenSM): LID割り当て、ルーティングテーブル管理
- LID (Local ID): サブネット内アドレス (16ビット)
- GID (Global ID): グローバルアドレス (128ビット、IPv6類似)
- GUID (Globally Unique ID): ハードウェア固有識別子

TCP/IP転送 (従来):
App → Socket API → TCP/IP Stack (カーネル) → NIC Driver → NIC → ネットワーク
                   ↑ CPU介入 (コピー、チェックサム、セグメンテーション)

RDMA転送:
App → RDMA Verbs → NIC (直接) → ネットワーク
       ↑ Zero-copy, CPUバイパス

// ibverbsベースのRDMA Write例 (簡略化)
#include <infiniband/verbs.h>

// 1. デバイスを開く
struct ibv_context *ctx = ibv_open_device(dev);

// 2. Protection Domain作成
struct ibv_pd *pd = ibv_alloc_pd(ctx);

// 3. メモリ登録 (NICが直接アクセスできるように)
struct ibv_mr *mr = ibv_reg_mr(pd, buf, size,
    IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE);

// 4. Queue Pair作成
struct ibv_qp *qp = ibv_create_qp(pd, &qp_init_attr);

// 5. RDMA Write (リモートメモリに直接書き込み)
struct ibv_send_wr wr;
wr.opcode = IBV_WR_RDMA_WRITE;
wr.wr.rdma.remote_addr = remote_addr;
wr.wr.rdma.rkey = remote_key;
ibv_post_send(qp, &wr, &bad_wr);

通常の経路 (GPU Directなし):
GPU0 → PCIe → Host Memory → NIC → ネットワーク → NIC → Host Memory → PCIe → GPU1
       (コピー1)              (コピー2)         (コピー3)              (コピー4)

GPU Direct RDMA:
GPU0 → PCIe → NIC → ネットワーク → NIC → PCIe → GPU1
       (直接)                        (直接)
CPUバイパス、コピー回数2倍削減

通常のストレージアクセス:
NVMe → Host Memory (bounce buffer) → GPU Memory
       CPU介入、2回コピー

GPU Direct Storage:
NVMe → GPU Memory (直接)
       CPUバイパス、1回コピー

使用ケース: 大規模データセットのロード (チェックポイント復旧、データ前処理)

# NCCL環境変数設定 (分散学習)
export NCCL_IB_HCA=mlx5_0,mlx5_1  # InfiniBand HCA指定
export NCCL_IB_GID_INDEX=3         # RoCE v2 GIDインデックス
export NCCL_SOCKET_IFNAME=eth0     # 制御チャネルインターフェース
export NCCL_DEBUG=INFO             # デバッグログ

# NCCLトポロジファイル (GPU-NICマッピング最適化)
export NCCL_TOPO_FILE=/path/to/topo.xml

# NCCL AllReduceベンチマーク
/usr/local/nccl-tests/build/all_reduce_perf -b 8 -e 1G -f 2 -g 8

# 帯域幅テスト
# サーバ: ib_write_bw --size=65536
# クライアント: ib_write_bw --size=65536 <server_ip>

# レイテンシテスト
# サーバ: ib_write_lat
# クライアント: ib_write_lat <server_ip>

# 結果例 (NDR 400Gbps):
# Bandwidth: ~48 GB/s (理論 50 GB/s)
# Latency: ~0.6 us

# Mellanox NIC PFC設定
mlnx_qos -i eth0 --pfc 0,0,0,1,0,0,0,0
# Priority 3のみPFC有効化 (RoCEトラフィック)

# DSCP → Priorityマッピング
mlnx_qos -i eth0 --trust dscp

大規模InfiniBandファブリックでのECMP:

Server A ─── Leaf 1 ─┬─ Spine 1 ─┬─ Leaf 3 ─── Server C
                      ├─ Spine 2 ─┤
                      ├─ Spine 3 ─┤
                      └─ Spine 4 ─┘

→ 4つの等コスト経路をロードバランシング
→ ハッシュベース (ソース/宛先LID) 分散
→ Adaptive Routing (AR): 輻輳状態に応じた動的経路変更

GPU Operatorコンポーネント:

GPU Operator
├── NVIDIA Driver (DaemonSet)
│   └── カーネルモジュール自動ビルド/インストール
├── NVIDIA Container Toolkit
│   └── コンテナランタイムにGPUサポート追加
├── NVIDIA Device Plugin
│   └── K8sにGPUリソース登録
├── DCGM Exporter
│   └── GPUメトリクス → Prometheus
├── MIG Manager
│   └── MIGプロファイル自動適用
├── GPU Feature Discovery (GFD)
│   └── ノードにGPUラベル自動追加
└── NVIDIA Validator
    └── インストール状態検証

# HelmでGPU Operatorインストール
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator \
  --create-namespace \
  --set driver.enabled=true \
  --set mig.strategy=mixed \
  --set dcgmExporter.enabled=true

# PodにGPU割り当て
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
    - name: cuda-container
      image: nvcr.io/nvidia/cuda:12.3.0-runtime-ubuntu22.04
      resources:
        limits:
          nvidia.com/gpu: 2 # GPU 2枚要求
      command: ['nvidia-smi']

# GPU Time-Slicing ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        renameByDefault: false
        failRequestsGreaterThanOne: false
        resources:
          - name: nvidia.com/gpu
            replicas: 4  # 1 GPUを4つに分割 (タイムスライシング)

DGX H100 GPUトポロジ:
GPU0 ─ NVLink ─ GPU1 (同一NVSwitchドメイン)
GPU2 ─ NVLink ─ GPU3 (同一NVSwitchドメイン)
GPU4 ─ NVLink ─ GPU5 (同一NVSwitchドメイン)
GPU6 ─ NVLink ─ GPU7 (同一NVSwitchドメイン)

GPU0 ─ PCIe ─ GPU4 (異なるドメイン、PCIe接続)

→ 4-GPU学習時: GPU0,1,2,3 (NVLink接続) >> GPU0,2,4,6 (PCIe接続)

# Topology-aware schedulingのためのNodeSelector
apiVersion: v1
kind: Pod
metadata:
  name: distributed-training
spec:
  nodeSelector:
    nvidia.com/gpu.product: 'NVIDIA-H100-80GB-HBM3'
    nvidia.com/gpu.count: '8'
  containers:
    - name: trainer
      resources:
        limits:
          nvidia.com/gpu: 4

# Volcanoを使用したGang Scheduling
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: distributed-training
spec:
  minAvailable: 4 # 最少4つのPodを同時スケジューリング
  schedulerName: volcano
  tasks:
    - replicas: 4
      name: worker
      template:
        spec:
          containers:
            - name: trainer
              image: training-image:latest
              resources:
                limits:
                  nvidia.com/gpu: 8 # ノード当たり8 GPU

Bin-packing (リソース密集):
Node1: [GPU0 使用, GPU1 使用, GPU2 使用, GPU3 空]
Node2: [GPU0 空, GPU1 空, GPU2 空, GPU3 空]
→ 長所: アイドルノードの電源節約、リソース効率性
→ 短所: ホットスポット発生の可能性

Spread (分散):
Node1: [GPU0 使用, GPU1 空, GPU2 使用, GPU3 空]
Node2: [GPU0 使用, GPU1 空, GPU2 使用, GPU3 空]
→ 長所: 負荷分散、障害隔離
→ 短所: リソースの断片化

# GFDが追加するノードラベルの例
nvidia.com/gpu.product=NVIDIA-A100-SXM4-80GB
nvidia.com/gpu.count=8
nvidia.com/gpu.memory=81920
nvidia.com/cuda.driver.major=535
nvidia.com/mig.strategy=mixed
nvidia.com/gpu.family=ampere
nvidia.com/mig-1g.10gb.count=4
nvidia.com/mig-3g.40gb.count=1

# DCGM Exporter DaemonSet (GPU Operatorに含まれる)
# Prometheus ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: dcgm-exporter
spec:
  selector:
    matchLabels:
      app: nvidia-dcgm-exporter
  endpoints:
    - port: metrics
      interval: 15s

# GPU稼働率
DCGM_FI_DEV_GPU_UTIL             # SM稼働率 (%)
DCGM_FI_DEV_MEM_COPY_UTIL        # メモリ帯域幅稼働率 (%)

# メモリ
DCGM_FI_DEV_FB_USED              # 使用中のフレームバッファ (MB)
DCGM_FI_DEV_FB_FREE              # 空きフレームバッファ (MB)

# 温度/電力
DCGM_FI_DEV_GPU_TEMP             # GPU温度 (C)
DCGM_FI_DEV_POWER_USAGE          # 電力使用量 (W)

# エラー
DCGM_FI_DEV_XID_ERRORS           # XIDエラーコード
DCGM_FI_DEV_ECC_SBE_VOL_TOTAL    # Single-bit ECCエラー
DCGM_FI_DEV_ECC_DBE_VOL_TOTAL    # Double-bit ECCエラー

# PCIe
DCGM_FI_DEV_PCIE_TX_THROUGHPUT   # PCIe送信スループット
DCGM_FI_DEV_PCIE_RX_THROUGHPUT   # PCIe受信スループット

# Prometheus Alert Rules
groups:
  - name: gpu-alerts
    rules:
      - alert: GPUMemoryAlmostFull
        expr: DCGM_FI_DEV_FB_USED / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE) > 0.95
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: 'GPU memory usage above 95%'

      - alert: GPUThermalThrottling
        expr: DCGM_FI_DEV_GPU_TEMP > 85
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: 'GPU temperature exceeds 85C'

      - alert: GPUXIDError
        expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: 'GPU XID error detected'

# PyTorch Automatic Mixed Precision (AMP)
import torch
from torch.cuda.amp import autocast, GradScaler

model = MyModel().cuda()
optimizer = torch.optim.Adam(model.parameters(), lr=1e-3)
scaler = GradScaler()

for data, target in dataloader:
    optimizer.zero_grad()

    # FP16でForward Pass
    with autocast():
        output = model(data.cuda())
        loss = criterion(output, target.cuda())

    # Loss Scaling + Backward Pass
    scaler.scale(loss).backward()
    scaler.step(optimizer)
    scaler.update()

# DeepSpeed ZeRO Stage 3設定
# ds_config.json
{
    "zero_optimization": {
        "stage": 3,
        "offload_optimizer": {
            "device": "cpu",
            "pin_memory": true
        },
        "offload_param": {
            "device": "cpu",
            "pin_memory": true
        },
        "overlap_comm": true,
        "contiguous_gradients": true,
        "sub_group_size": 1e9,
        "reduce_bucket_size": "auto",
        "stage3_prefetch_bucket_size": "auto",
        "stage3_param_persistence_threshold": "auto",
        "stage3_max_live_parameters": 1e9,
        "stage3_max_reuse_distance": 1e9
    },
    "bf16": {
        "enabled": true
    },
    "train_batch_size": "auto",
    "train_micro_batch_size_per_gpu": "auto"
}

ZeROメモリ分割:

ZeRO Stage 0 (基本):
GPU0: [Model] + [Gradient] + [Optimizer State]
GPU1: [Model] + [Gradient] + [Optimizer State]
→ すべてのGPUに全体複製

ZeRO Stage 1 (Optimizer分割):
GPU0: [Model] + [Gradient] + [Optimizer 1/2]
GPU1: [Model] + [Gradient] + [Optimizer 2/2]
→ メモリ ~1.5x節約

ZeRO Stage 2 (+ Gradient分割):
GPU0: [Model] + [Gradient 1/2] + [Optimizer 1/2]
GPU1: [Model] + [Gradient 2/2] + [Optimizer 2/2]
→ メモリ ~2x節約

ZeRO Stage 3 (+ Model分割):
GPU0: [Model 1/2] + [Gradient 1/2] + [Optimizer 1/2]
GPU1: [Model 2/2] + [Gradient 2/2] + [Optimizer 2/2]
→ メモリ ~N倍節約 (N = GPU数)

Data Parallelism:
入力データをN等分してN個のGPUで同一モデルを学習
→ AllReduceでグラディエントを同期
→ 通信量: O(model_size)

Tensor Parallelism:
1つのレイヤー（行列）をN等分してN個のGPUに分配
→ Forward/Backward各レイヤーごとに通信が必要
→ GPU間高速通信（NVLink）必須

Pipeline Parallelism:
モデルのレイヤーをN等分してN個のGPUに順次配置
→ マイクロバッチをパイプラインで処理
→ バブル（アイドル時間）の最小化が核心

3D Parallelism (LLM学習):
Data Parallel x Tensor Parallel x Pipeline Parallel
例: 256 GPU = 32 DP x 4 TP x 2 PP

# TensorRTによるモデル最適化 (Python API)
import tensorrt as trt

logger = trt.Logger(trt.Logger.WARNING)
builder = trt.Builder(logger)
network = builder.create_network(
    1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)
)
parser = trt.OnnxParser(network, logger)

# ONNXモデルパース
with open("model.onnx", "rb") as f:
    parser.parse(f.read())

# ビルド設定
config = builder.create_builder_config()
config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 << 30)  # 1GB
config.set_flag(trt.BuilderFlag.FP16)  # FP16量子化有効化

# エンジンビルド
engine = builder.build_serialized_network(network, config)

Tritonアーキテクチャ:
Client → HTTP/gRPC → Triton Server
                      ├── Model Repository
                      │   ├── model_a/ (TensorRT)
                      │   ├── model_b/ (ONNX Runtime)
                      │   └── model_c/ (Python Backend)
                      ├── Scheduler
                      │   ├── Dynamic Batching
                      │   └── Sequence Batching
                      ├── Model Ensemble
                      │   └── 前処理 → モデル → 後処理パイプライン
                      └── Metrics (Prometheus)

# Tritonモデル設定 (config.pbtxt)
name: "my_model"
platform: "tensorrt_plan"
max_batch_size: 64

input [
  {
    name: "input"
    data_type: TYPE_FP16
    dims: [ 3, 224, 224 ]
  }
]

output [
  {
    name: "output"
    data_type: TYPE_FP16
    dims: [ 1000 ]
  }
]

dynamic_batching {
  preferred_batch_size: [ 16, 32, 64 ]
  max_queue_delay_microseconds: 100
}

instance_group [
  {
    count: 2
    kind: KIND_GPU
    gpus: [ 0 ]
  }
]

from vllm import LLM, SamplingParams

# vLLMサーバ起動
llm = LLM(
    model="meta-llama/Llama-3-70B",
    tensor_parallel_size=4,      # 4 GPU Tensor Parallel
    gpu_memory_utilization=0.9,  # GPUメモリ90%使用
    max_model_len=8192,
    dtype="bfloat16",
)

# 核心最適化技術:
# 1. PagedAttention: KV Cacheをページ単位で管理 (メモリ効率)
# 2. Continuous Batching: リクエストを動的にバッチに追加/削除
# 3. Prefix Caching: 共通プレフィックスのKV Cache再利用

[性能問題診断フローチャート]

1. nvidia-smi確認
   ├── GPU Util < 30%
   │   ├── CPU/IOボトルネックの可能性が高い
   │   │   ├── top/htop確認 → CPU 100%? → データロード最適化
   │   │   └── iostat確認 → ディスクI/O? → NVMe/GDS使用
   │   └── カーネルが小さすぎる → CUDA Graph、バッチ増加
   ├── GPU Util > 90%, 性能低い
   │   ├── Memory-Boundの可能性
   │   │   ├── Nsight Compute → Memory Throughput確認
   │   │   └── Memory Coalescingパターン点検
   │   └── Warp Divergenceの可能性
   │       └── Nsight Compute → Warp Stall Reasons
   └── GPU Util 不規則 (上下変動)
       ├── 同期ボトルネック → 非同期実行最適化
       └── 通信ボトルネック (分散) → NCCLプロファイリング

2. 分散学習ボトルネック
   ├── NCCL AllReduce時間確認
   │   ├── Nsight SystemsでNCCL領域確認
   │   └── 通信/演算比率分析
   ├── InfiniBand帯域幅確認
   │   └── ib_write_bwベンチマーク
   └── GPUトポロジ確認
       └── nvidia-smi topo -m

# GPUデバイス情報
lspci -vv -s $(lspci | grep NVIDIA | head -1 | awk '{print $1}')

# GPUドライババージョン
cat /proc/driver/nvidia/version

# CUDAバージョン
nvcc --version

# GPUメモリ使用量詳細
nvidia-smi --query-gpu=memory.used,memory.free,memory.total --format=csv

# GPUプロセス別メモリ
nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory --format=csv

# PCIe帯域幅確認
nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.width.current --format=csv

# GPUクロック情報
nvidia-smi --query-gpu=clocks.current.graphics,clocks.current.memory,clocks.max.graphics,clocks.max.memory --format=csv

# dmesgでGPU関連メッセージ
dmesg | grep -i -E "nvidia|nvrm|gpu|xid"

# InfiniBand状態確認
ibstat
ibstatus
ibv_devinfo

# RDMAデバイス確認
rdma link show
rdma resource show

# NIC状態
ethtool -i mlx5_core0
mlxlink -d /dev/mst/mt4125_pciconf0 -m

# カーネルモジュール状態
lsmod | grep nvidia
lsmod | grep mlx
lsmod | grep vfio

# NUMAトポロジ (GPU-CPUアフィニティ)
numactl --hardware
lstopo --of ascii
nvidia-smi topo -m

# XIDエラーモニタリング
dmesg -w | grep "NVRM: Xid"

# 出力例:
# NVRM: Xid (PCI:0000:41:00): 79, pid=0, GPU has fallen off the bus
# NVRM: Xid (PCI:0000:41:00): 48, pid=12345, DBE (double bit error)

# GPUハング時のリセット試行
nvidia-smi --gpu-reset -i 0

# ドライバ再ロード (すべてのGPUプロセス終了が必要)
# 1. GPU使用プロセスの確認
fuser -v /dev/nvidia*

# 2. プロセス終了
kill -9 <pid>

# 3. ドライバアンロード/ロード
sudo rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia
sudo modprobe nvidia

# 完全に解決しない場合
sudo systemctl restart nvidia-persistenced

# PyTorchでOOM発生時のデバッグ

# メモリ使用量確認
import torch
print(f"Allocated: {torch.cuda.memory_allocated()/1e9:.2f} GB")
print(f"Reserved:  {torch.cuda.memory_reserved()/1e9:.2f} GB")
print(f"Max Allocated: {torch.cuda.max_memory_allocated()/1e9:.2f} GB")

# メモリスナップショット (詳細分析)
torch.cuda.memory._record_memory_history(max_entries=100000)
# ... 学習コード実行 ...
snapshot = torch.cuda.memory._snapshot()
torch.cuda.memory._dump_snapshot("memory_snapshot.pickle")
# https://pytorch.org/memory_viz で可視化

# ECCエラー確認
nvidia-smi --query-gpu=ecc.errors.corrected.volatile.total,ecc.errors.uncorrected.volatile.total,ecc.errors.corrected.aggregate.total,ecc.errors.uncorrected.aggregate.total --format=csv

# Retired Pages確認
nvidia-smi --query-retired-pages=gpu_uuid,retired_pages.address,retired_pages.cause --format=csv

# RMA判断基準:
# - Uncorrected (Double-bit) ECCエラーが繰り返し発生
# - Retired Pagesが閾値超過 (通常60+ pages)
# - XID 48が複数回発生
# - GPUがbusから分離 (XID 79)

# 温度モニタリング
nvidia-smi --query-gpu=temperature.gpu,temperature.memory --format=csv -l 1

# 電力制限確認/設定
nvidia-smi --query-gpu=power.limit,power.default_limit,power.max_limit --format=csv
sudo nvidia-smi -pl 300  # 電力制限を300Wに設定

# クロック速度確認 (Throttling時に低下)
nvidia-smi --query-gpu=clocks.current.graphics,clocks.max.graphics --format=csv

# Throttling原因確認
nvidia-smi --query-gpu=clocks_throttle_reasons.active --format=csv

プロジェクト構成:
cuda-matmul-benchmark/
├── src/
│   ├── naive_matmul.cu          # Naive実装
│   ├── tiled_matmul.cu          # Shared Memoryタイリング
│   ├── wmma_matmul.cu           # Tensor Core (WMMA API)
│   └── cublas_matmul.cu         # cuBLASラッパー
├── benchmark/
│   ├── run_benchmarks.sh
│   └── plot_results.py          # 結果可視化
├── profiles/
│   ├── nsight_systems/
│   └── nsight_compute/
└── README.md

プロジェクト構成:
mig-k8s-multitenant/
├── infra/
│   ├── gpu-operator-values.yaml
│   ├── mig-config.yaml
│   └── monitoring/
│       ├── dcgm-dashboard.json    # Grafanaダッシュボード
│       └── alert-rules.yaml       # Prometheusアラート
├── workloads/
│   ├── inference-deployment.yaml  # MIG 1g.10gb推論
│   ├── training-job.yaml          # MIG 3g.40gb学習
│   └── notebook-statefulset.yaml  # MIG 2g.20gb Jupyter
├── scheduler/
│   ├── gang-scheduling.yaml       # Volcano設定
│   └── priority-classes.yaml
└── docs/
    ├── architecture.md
    └── benchmark-results.md

プロジェクト構成:
distributed-training-profiler/
├── benchmarks/
│   ├── nccl_allreduce.sh          # NCCLベンチマーク
│   ├── ib_bandwidth.sh            # InfiniBand帯域幅
│   └── multi_node_training.py     # 実際の学習スクリプト
├── profiling/
│   ├── nsight_distributed.sh      # 分散環境プロファイリング
│   └── nccl_debug_analysis.py     # NCCLログ分析
├── optimization/
│   ├── nccl_env_tuning.sh         # NCCL環境変数最適化
│   └── topology_optimization.py   # GPU-NICトポロジ最適化
└── results/
    ├── scaling_efficiency.png     # スケーリング効率グラフ
    └── communication_breakdown.png # 通信時間分析