← Learnings Hub

Chronicles of OPT-175B

What training a 175-billion parameter model on 1024 A100 GPUs actually looks like in practice. An interactive exploration of Meta AI’s 148-page logbook: numerical instabilities, 90+ hardware restarts, the accidental deletion of the entire cluster, and the path to automated self-healing.

175B
Model Parameters
1,024
80GB A100 GPUs
4.30e23
Total FLOPs
90+
Cluster Restarts
33 Days
Continuous Compute
300B
Tokens Processed

Interactive Incident & Training Timeline

Click or press Enter on any marker or log row to inspect exact logbook notes, token milestones, and architectural actions.

Major SEV Hardware Failure Loss Spike / NaN Hyperparameter / Architecture Automation Win
Phases:
Category:

Chronological Event Ledger

Validation Loss Dynamics & Trajectory

The comparison between the ill-fated Experiment 11.xx and the successful Experiment 12.xx revealed a crucial counter-intuitive lesson in deep learning at scale: optimizing for the lowest loss early in training does not guarantee long-term convergence.

Loss Trajectory vs Steps

Updates (0 to 75,000)
Exp 11.xx (Diverged / Underflow) Exp 12.xx (Megatron Init / Final) GPT-3 175B Reference

The Early Loss Trap

Notice how Exp 11.xx (red) plunged aggressively early on, reaching a loss of 5.1 by update 3,500 while Exp 12.xx (blue) was lagging behind at 5.4.

However, 11.xx achieved this through aggressive initialization and Normformer layers that quickly saturated gradients, leading to floating-point underflow and terminal stagnation. Exp 12.xx sacrificed early speed for structural stability, unlocking a steady, monotonic descent across 75,000 steps.

Key Metric: 175B dense training required ~2.5e12 FLOPs per parameter, roughly 125× higher than a comparable Mixture-of-Experts (MoE) model.

Six Hard-Earned Engineering Learnings

Lessons distilled from 148 pages of real-time firefighting across 87 days of distributed cluster execution.

Learning #1

The x3 GeLU FP16 Instability

In FP16 mixed-precision training, the cubic term in Gaussian Error Linear Units (GeLU(x) ≈ x · σ(1.702x)) amplifies activations exponentially during extreme forward passes. At 175B scale, this caused sudden gradient overflows. Hot-swapping to standard ReLU restored bounded linear gradients.

Takeaway: What works cleanly in FP32 on a 1.3B model can trigger catastrophic underflow or overflow in FP16 at 175B.
Learning #2

Frozen Positional Embeddings

The team originally used sinusoidal initialization for Learned Positional Embeddings (LPE). At 175B scale, the gradient magnitudes flowed disproportionately through the massive projection matrices, effectively reducing gradients on LPE to zero. The positional representations remained completely frozen.

Takeaway: Initialization schemes must be individually ablated at medium scale; sinusoidal init works for fixed encoders, not 175B decoders.
Learning #3

1.6TB Checkpoint I/O Hangs

Each checkpoint comprised 992 files (totaling 1.6 TB). When 1024 nodes attempted to download these shards simultaneously from cloud object storage during restarts, the cloud provider's API experienced nondeterministic network stalls, turning a 15-minute reboot into a 4-hour deadlock.

Takeaway: Distributed storage is the primary hidden bottleneck of LLM training. Checkpoint staging must be coalesced and rate-limited.
Learning #4

The Hardware Failure Rate (~2 Hosts / Day)

At 1024-GPU scale (128 hosts with 8 A100s each), hardware components fail continuously: single-bit uncorrectable ECC memory errors, PCIe bus drops, and InfiniBand link degradations. The cloud provider initially took hours to swap hosts and frequently re-assigned the same malfunctioning machines back to the pool.

Takeaway: Maintain a live hot-standby pool of at least 12–18 burn-in tested nodes. Never rely on on-demand provisioning.
Learning #5

The "Omicron SEV" Cluster Deletion

On December 21, 2021, while attempting to replenish the buffer pool, the cloud provider's operations team mistakenly deleted the entire active 1024-GPU production cluster. Because all nodes were wiped, the team had to rapidly rebuild the cluster from scratch, discovering that 16 of the newly provisioned machines failed basic burn-in tests.

Takeaway: Cloud infrastructure is not infallible. Build strict validation scripts that gate cluster membership before any workload runs.
Learning #6

Automation Defeats On-Call Burnout

In November, 40+ manual restarts consumed the engineering team's nights and weekends. By late December, the team deployed custom burn-in scripts, automated InfiniBand topology checks, and auto-restart harnesses. Over the Christmas–New Year break, the cluster self-healed through 8 separate hardware drops without human intervention.

Takeaway: Human on-call rotations cannot sustainably service 1024-GPU training. Automated health-check & auto-restart is required.

Cluster Failure & Cost Simulator

Estimate the real downtime, restart overhead, and lost cloud spend of training large models at scale based on real-world MTTR (Mean Time to Recover) and hardware failure rates.

Total Elapsed Duration:
35.4 days
Estimated Restarts:
71 restarts
Downtime Overhead:
6.2% (53h)
Total Cluster Cloud Cost:
$2.78M
Wasted Idle Spend:
$174.5k wasted

Primary Sources & Documentation