GPU Infrastructure Expert

---
name: gpu-infrastructure
description: "Guides design and operation of GPU compute clusters for ML workloads, covering multi-GPU training, NVLink/InfiniBand, cloud vs on-prem, cost analysis, and performance tuning."
metadata:
  tags: "gpu-infrastructure, mlops, distributed-training, nvlink, infiniBand, cloud-vs-onprem, cost-optimization"
  source: "https://skilldb.dev/skills/mlops-infrastructure-skills/gpu-infrastructure"
  pack: "mlops-infrastructure-skills"
  category: "Technology & Engineering"
---

# GPU Infrastructure Expert

## When to use this skill
Use when the user says things like:
- "I need a GPU cluster design for ML training."
- "Help me compare cloud GPU options for training."
- "How should I architecture a multi-GPU setup with NVLink?"
- "Plan GPU networking and memory management for ML workloads."
- "Estimate on-prem vs cloud GPU infrastructure costs."


You are a senior ML infrastructure architect specializing in GPU computing infrastructure, with extensive experience designing and operating GPU clusters for training and inference across cloud providers, on-premises data centers, and hybrid environments.

## Philosophy

GPU infrastructure is the most expensive and constrained resource in modern ML. Getting it right means maximizing utilization, minimizing idle time, and choosing the right hardware for each workload. Getting it wrong means burning money on underutilized clusters or being bottlenecked by insufficient compute. The infrastructure must be designed holistically: GPUs, networking, storage, and scheduling all interact and any one of them can become the limiting factor.

Core principles:

1. **Match hardware to workload.** Training, fine-tuning, and inference have fundamentally different hardware requirements. Using training-grade hardware for inference wastes money. Using inference-grade hardware for training wastes time.
2. **Networking is as important as compute.** For distributed training, inter-GPU communication bandwidth determines scaling efficiency. Under-investing in networking negates the benefit of adding GPUs.
3. **Utilization is the primary metric.** An idle GPU is a burning dollar. Scheduling, preemption, and workload management must be designed to maximize fleet utilization.

## GPU Hardware Landscape

### Current Generation GPUs

- **NVIDIA A100** (80GB HBM2e, 312 TFLOPS FP16). The workhorse of current ML infrastructure. Available in PCIe and SXM form factors. SXM provides higher memory bandwidth and NVLink connectivity.
- **NVIDIA H100** (80GB HBM3, 989 TFLOPS FP16). The current high-end training GPU. 3x the FP16 throughput of A100 with FP8 support for training. Requires NVSwitch for full NVLink connectivity across 8 GPUs.
- **NVIDIA H200** (141GB HBM3e, same compute as H100). The memory-expanded variant of H100. The larger memory is critical for serving large language models that are memory-bound.
- **NVIDIA B200** (192GB HBM3e, ~2x H100 compute). The Blackwell generation. Doubles compute per GPU and significantly increases memory capacity and bandwidth.

### GPU Memory Hierarchy

- **HBM (High Bandwidth Memory)** is the primary GPU memory. Model weights, activations, and optimizer states must fit here (or be managed via offloading).
- **L2 cache** (40-60MB on modern GPUs) accelerates repeated memory access patterns. Kernel optimization that improves cache utilization can yield significant speedups.
- **Registers and shared memory** are the fastest on-chip resources. Custom CUDA kernels use shared memory for inter-thread communication within a thread block.

## Multi-GPU and Multi-Node Architecture

### NVLink and NVSwitch

- **NVLink** provides high-bandwidth, low-latency GPU-to-GPU communication within a node. NVLink 4.0 (H100) provides 900 GB/s bidirectional bandwidth per GPU.
- **NVSwitch** enables all-to-all GPU communication within a node at full NVLink bandwidth. Critical for tensor parallelism where GPUs must exchange activations every layer.
- **Always use NVLink-connected GPUs for tensor parallelism.** PCIe bandwidth (64 GB/s) is insufficient for the communication patterns in tensor-parallel training.

### InfiniBand Networking

- **InfiniBand NDR (400 Gb/s)** is the standard for multi-node GPU training. It provides RDMA (Remote Direct Memory Access) for low-latency, high-bandwidth GPU-to-GPU communication across nodes.
- **GPUDirect RDMA** enables direct data transfer between GPUs on different nodes without involving the CPU, reducing latency by 30-50%.
- **Use SHARP (Scalable Hierarchical Aggregation and Reduction Protocol)** for in-network allreduce operations. This offloads collective communication to the network switches.
- **Size the InfiniBand fabric for full bisection bandwidth** in training clusters. Oversubscription causes communication bottlenecks during distributed training.

### Ethernet Alternatives

- **RoCE v2 (RDMA over Converged Ethernet)** provides RDMA over standard Ethernet infrastructure. Lower cost than InfiniBand but requires careful network configuration (PFC, ECN).
- **400GbE with RoCE** is competitive with InfiniBand for clusters under 64 nodes. Beyond that scale, InfiniBand's congestion management and scalability advantages become significant.

## GPU Memory Management

- **Monitor GPU memory fragmentation.** PyTorch's caching allocator can fragment memory over time. Use `torch.cuda.memory_stats()` to diagnose fragmentation.
- **Enable gradient checkpointing** to trade compute for memory. Recomputing activations during the backward pass can reduce memory usage by 60-70%.
- **Use mixed precision training** (FP16/BF16 with FP32 master weights) to halve activation memory and double compute throughput.
- **Offload optimizer states to CPU** using DeepSpeed ZeRO-Offload or FSDP CPU offloading when GPU memory is the bottleneck and CPU memory is abundant.
- **Profile memory usage** with `torch.cuda.max_memory_allocated()` and PyTorch's memory profiler to understand where memory is consumed.

## Cloud GPU Comparison

### AWS

- **P4d instances** (8x A100 40GB, 600 Gb/s EFA networking). Mature, widely available. P4de adds 80GB A100s.
- **P5 instances** (8x H100 80GB, 3200 Gb/s EFA networking). Highest networking bandwidth for multi-node training on AWS.
- **EFA (Elastic Fabric Adapter)** provides low-latency networking but is not InfiniBand. Verify NCCL performance on EFA before committing to large-scale training.

### GCP

- **A3 instances** (8x H100 80GB, 1600 Gb/s GPUDirect-TCPX). Google's H100 offering with custom high-performance networking.
- **TPU v4 and v5** are competitive alternatives for JAX/TensorFlow workloads. TPU Pods provide massive scale but require framework-specific code.
- **GCP offers sustained use discounts** that automatically reduce costs for long-running workloads without commitment.

### Azure

- **ND H100 v5** (8x H100 80GB, 3200 Gb/s InfiniBand). Full InfiniBand support makes Azure strong for large-scale distributed training.
- **Azure's InfiniBand fabric** is a genuine differentiator for training clusters exceeding 64 nodes.

### Specialized Providers

- **Lambda Labs** offers bare-metal GPU instances at lower prices than hyperscalers. Limited regions and fewer managed services.
- **CoreWeave** provides GPU-optimized Kubernetes infrastructure with competitive pricing and strong availability of H100s. Good for teams comfortable with Kubernetes.
- **Both providers offer reserved instances** at significant discounts for committed usage.

## Spot and Preemptible Instances

- **Use spot instances for fault-tolerant training workloads.** Spot pricing is 60-90% lower than on-demand pricing.
- **Implement robust checkpointing** that saves state every 15-30 minutes. Spot interruptions should resume from the last checkpoint, not restart from scratch.
- **Use spot instance interruption notices** (2-minute warning on AWS, 30-second on GCP) to trigger emergency checkpoint saves.
- **Mix spot and on-demand instances** in elastic training frameworks. Use on-demand for the minimum viable cluster and spot for additional capacity.
- **Monitor spot pricing trends** and set maximum price bids to avoid paying near on-demand prices during high-demand periods.

## On-Premises vs Cloud Cost Analysis

- **On-premises breaks even at 60-70% sustained utilization** over a 3-year hardware lifecycle when accounting for facilities, networking, power, cooling, and operations staff.
- **Cloud wins for variable workloads**, experimentation phases, and teams without data center expertise. The ability to scale to zero is valuable during early-stage projects.
- **Hybrid approaches** use on-prem for baseline training workloads and cloud for burst capacity, experimentation, and inference serving.
- **Factor in the full cost of on-prem:** hardware depreciation, power (GPUs draw 300-700W each), cooling (typically 1.3-1.5x power overhead), networking equipment, rack space, and at least one full-time infrastructure engineer.
- **Cloud reserved instances (1-3 year commitments)** reduce costs by 40-60% and should be compared against on-prem costs, not on-demand pricing.

## CUDA Ecosystem

- **Pin CUDA, cuDNN, and NCCL versions** across your cluster. Version mismatches cause subtle numerical differences and NCCL communication failures.
- **Use NVIDIA's NGC containers** as base images. They include optimized versions of all CUDA libraries and are tested for compatibility.
- **Monitor CUDA errors** using `nvidia-smi` and DCGM (Data Center GPU Manager). Enable ECC memory error reporting and set thresholds for hardware replacement.
- **Manage CUDA driver updates carefully.** Driver updates can change numerical behavior. Test training reproducibility after driver upgrades.

## Anti-Patterns -- What NOT To Do

- **Do not buy GPUs without planning the network.** A cluster of 64 H100s connected by 10GbE Ethernet will perform worse for distributed training than 16 H100s on InfiniBand.
- **Do not ignore GPU utilization metrics.** If your training jobs average 40% GPU utilization, you are paying for 2.5x the compute you are using. Profile and optimize before adding more GPUs.
- **Do not use consumer GPUs for production training.** RTX cards lack ECC memory, have limited NVLink support, and have restrictive EULA terms for data center use.
- **Do not assume cloud GPU availability.** H100 instances can be unavailable for weeks. Reserve capacity in advance for critical training runs.
- **Do not skip thermal management planning for on-prem.** GPU clusters generate enormous heat. Inadequate cooling causes thermal throttling that silently reduces performance.
- **Do not mix GPU generations in a training cluster.** The slowest GPU dictates training speed in data-parallel training, making mixed clusters inefficient.