Anthropic Head of Pretraining on Scaling Laws, Compute, and the Future of AI

Nick Joseph, Head of Pretraining at Anthropic, shares insights on how AI models are trained at scale, the infrastructure challenges involved, and how the pre-training team has evolved over time.

Background and Journey to Anthropic

Career Path

• Started at Vicarious, originally an AGI lab that shifted to robotics products
• Worked on training computer vision models for robotics - first job in ML
• Learned ML infrastructure fundamentals at Vicarious
• Joined OpenAI on one of the safety teams, worked on code models
• Saw GPT-3 fine-tuned to write code and realized AI could self-improve
• Left OpenAI with the safety team leads to join Anthropic at founding

Early Interest in AI Safety

• Internship at GiveWell (nonprofit evaluating charities) introduced AI safety concepts
• Initially skeptical - AI safety discussions were mostly theoretical at the time
• Models weren’t good enough to pose real dangers yet
• Decided to work on AI: either safety would matter, or he’d build useful AI tools

What is Pre-training?

The Core Concept

• Scale is a key ingredient to making AI models better
• Need an objective with massive amounts of data
• The internet is the biggest single source of data humanity has created
• No manual labels needed - predict the next word from existing text

How It Works

• Take text and predict the next word
• “The cat” -> predict what comes next
• Every word becomes a new training example
• Dense signal from massive data

Scaling Laws

• As you add more compute, data, and parameters, models get predictably better
• Lower loss = better prediction of next word
• Original scaling laws paper showed 11 orders of magnitude of consistent trends
• This creates a positive feedback loop: train model -> make useful product -> get money -> buy more compute -> train better model

Early Days at Anthropic

Starting Small

• Team of about 10-12 people initially
• Much less funding than competitors like OpenAI
• GPT-3 cost about $5 million to train - significant but achievable
• Used cloud provider for compute

Efficiency as Competitive Advantage

• “We have way less funding than everyone else, we have to be really efficient”
• Most people weren’t very efficient with compute at the time
• Focused on getting the most out of available hardware

Infrastructure Challenges

• Had to understand literal physical layout of chips
• Ran clustering algorithms to identify which rooms chips were in
• Network latency between different physical locations caused issues
• Constantly pushing limits of hardware

Distributed Training Approaches

Key Techniques

• Data Parallelism: Split data across multiple chips
• Pipelining: Chain operations across chips
• Op-sharding: Distribute operations across hardware

Building Custom Infrastructure

• No great open-source packages existed at the time
• Wrote their own all-reduce implementation
• Needed to modify everything as they scaled beyond what Facebook had done
• Couldn’t rely on external packages they’d constantly need to modify

Why Build In-House?

• Going to bigger scale than existing solutions supported
• Need full control to optimize at every level
• Can make architecture changes that simplify efficiency problems

Scaling Laws and Conviction

The Physicist’s Perspective

• Original scaling laws paper showed remarkably consistent trends
• Debate about whether trends would continue seemed “nonsensical”
• 11 orders of magnitude of data, arguing about one more point seemed unlikely to fail
• “What are these people doing? They’re all missing the big picture”

Different Lab Cultures

• FAIR (Facebook AI Research) had PhD-style independent research culture
• People fighting for their own compute, pursuing individual ideas
• Training large language models requires collaboration on infrastructure
• Not publishable work - “I got 5% more efficiency” isn’t a paper
• Anthropic’s culture focused on collaborative scaling

Team Evolution Over Time

Early Days

• First 3-6 months: tried to read every PR in the codebase
• Knew all the pieces, could make cross-cutting changes easily
• Could spot efficiency improvements by changing architecture

Growing Specialization

• As team grew, people became deep experts on individual components
• Some focus on exactly how attention should work
• Others dial in parallelism strategy
• Benefits: can go really deep on specific problems

The Trade-off

• Specialists may miss cross-component optimizations
• Manager’s role: ensure bigger picture makes sense
• Need people who understand the whole system
• Avoid single points of failure

Balancing Generalists and Specialists

• People have genuine preferences for generalist vs specialist roles
• Early hires tend to be generalist-shaped (startup mentality)
• Risk: everyone doing everything, no one deeply understanding anything
• Too many specialists: manager has to connect everything
• Goal: balance of both types

What Hasn’t Changed

The Core Metric

• Still pushing down the same loss function from day one
• “Loss go down” remains the one OKR that matters
• Could plot progress on same metric from first model to today
• Answer is always “as low as possible”

The Feedback Loop

• Train model -> deploy -> get revenue -> buy more compute -> repeat
• This cycle has run continuously for ~5 years
• Scaling laws give conviction that progress will continue

Key Takeaways

1. Scale matters: More compute, data, and parameters predictably improve models
2. Efficiency is competitive advantage: Especially when resource-constrained
3. Build what you need to control: Custom infrastructure enables optimization
4. Balance team composition: Mix of generalists and specialists
5. Stay focused on core metric: Loss reduction drives everything