How To Train An LLM with Anthropic's Head of Pretraining

The Core Thesis: Scaling Laws and the Compute Feedback Loop

The central thesis of pre-training has been consistent: scaling compute, data, and model parameters predictably yields more capable models. This principle is quantified by “scaling laws,” which show that as you increase compute, the model’s loss (a measure of its error in predicting the next word) decreases in a predictable power-law fashion.

This predictability created a powerful positive feedback loop that has driven progress over the last five years:

1. Train a large model using available compute.
2. Use the model to create a useful product that generates revenue.
3. Use the revenue to buy more compute.
4. Train an even better, larger model.

This cycle relies on a simple, scalable objective. Next-word prediction on the vast, unlabeled dataset of the internet proved to be the most effective. Unlike other objectives like masked language modeling (used by models like BERT), autoregressive next-word prediction has a significant advantage: it naturally enables generative product use cases through simple sampling, fitting perfectly into the feedback loop.

The Engineering Reality of Training at the Frontier

While the concept of scaling is simple, the implementation is an immense engineering challenge. The hardest problems in AI are often infrastructure problems, not ML problems.

Early Infrastructure and Efficiency

In the early days of Anthropic, the team felt they were among a small group of ~30 people in the world working at the frontier of large-scale training. To compete with less funding, they focused intensely on efficiency.

• Custom Frameworks: Off-the-shelf open-source packages like PyTorch’s distributed libraries were insufficient for the scale they were targeting. The team had to build their own distributed frameworks from the ground up, implementing techniques like data parallelism, pipelining, and tensor sharding (upsharding) themselves. This gave them the control needed to modify and optimize every component.
• Hardware-Level Understanding: Using a cloud provider doesn’t abstract away the physical hardware. The team had to understand the literal layout of GPUs in the data center, at one point running clustering algorithms on network latency data to reverse-engineer which chips were in which rooms to debug performance bottlenecks.
• A Scientific Approach to Optimization: The process for improving efficiency was methodical:
  1. Model the System: On paper, calculate the theoretical maximum efficiency (MFU/flops utilization) by modeling the six or so key constraints, such as HBM bandwidth, CPU offloading, and network interconnects.
  2. Implement: Write the code to execute the parallelization strategy.
  3. Profile and Debug: Use profilers to measure the performance of every single operation. The goal is to match the actual performance to the theoretical model, identifying and fixing any discrepancies. This often required hacking existing single-GPU profilers to trace and combine data from thousands of GPUs simultaneously.

The Challenge of Cursed Bugs and Unreliable Hardware

A surprising and frustrating challenge at scale is that the hardware itself can be the source of bugs. The conventional programmer’s wisdom, “it’s your code, not the computer,” breaks down.

My manager looked at it and was like, “uh yeah, probably the computer’s wrong.” And I was like, that seems unlikely. And sure enough, the computer was wrong. Turned out that like the GPU was broken.

Teams must debug the entire stack, from the high-level Python code down to the physical hardware. A single faulty GPU, a misconfigured power supply, or a subtle networking issue can corrupt a training run. These “cursed bugs” can take months to solve, potentially derailing an entire model generation. This necessitates a rare engineering skill set: the ability to deep-dive any problem at any level of the stack, from ML learning dynamics down to the movement of bytes across a network.

Strategy, Data, and Team Composition

Generalists vs. Specialists

As the team grew, its composition evolved. Early on, the team consisted mostly of “generalist-shaped” people who could work on any part of the codebase. Over time, a need for deep specialists emerged—experts in areas like numerical precision or parallelism strategies. The ideal team structure is a balance: specialists to drive deep optimizations and generalists who understand the full picture to connect disparate efforts and prevent single points of failure. The most critical need has consistently been for engineers, not just researchers, who can solve these hard, systems-level problems.

Pre-training vs. Post-training (RLHF)

The focus in LLM development has partially shifted from pure pre-training to include extensive post-training, primarily through Reinforcement Learning from Human Feedback (RLHF). This introduces a new resource allocation problem: how much compute should be dedicated to pre-training versus RL?

• Iteration Speed: Post-training has a massive advantage in iteration speed. An experiment can be run in hours or days, compared to the multi-month “one shot on goal” of a pre-training run.
• Division of Labor: A useful mental model is that pre-training teaches the model to be intelligent, while post-training tweaks its personality and behavior. For complex interventions, like aligning the model’s personality, post-training is more suitable because it requires a model that is already highly capable.
• Collaboration: The pre-training and inference teams must work in lockstep. The pre-training team’s architectural decisions (e.g., model size, complexity) directly define the problem the inference team must solve. Models are therefore co-designed to be both intelligent and efficient to serve.

The Future of Data

The narrative that “we are running out of data” is complex. While the amount of high-quality data on the internet is finite and growing slower than compute, the exact size of the “useful internet” is unknown.

A more pressing concern is the rise of synthetic, AI-generated data.

• Distillation: Using a large model to generate data to train a smaller, cheaper model is a proven technique.
• Self-Improvement: Using a model’s own output to train a better version of itself is theoretically challenging. You risk merely reinforcing the model’s existing distribution, including its flaws (e.g., if a model thinks 5+5=11, it will generate data reinforcing that error).
• Data Pollution: As more of the internet becomes LLM-generated, there’s a risk of models training on their own noisy, homogenized outputs, leading to a potential degradation or “mode collapse.” The exact impact of this is an open and critical area of research.

• Tags:
• AI Safety
• Pre-Training
• Distributed Systems
• Feature
• Anthropic
• Scaling Laws
• Claude
• GPU
• LLM Infrastructure