Nathan Lambert spent three years as post-training lead at Ai2, where he built the OLMo models, and he writes Interconnects, one of the most-read technical newsletters in AI. He left Ai2 in June and is now working on a new project. He’s also the author of the RLHF book. We talked a lot about open models, their capabilities, and why they are better than he expected. We get into what that means over the next two to five years, why he thinks recursive self-improvement is overblown, what the market for training environments actually looks like now, and why he expects Anthropic’s famously open internal culture to break after its IPO.

Key Topics

• Open vs closed models and who actually captures the value

• Anthropic and OpenAI as opposite cultures, and the talent concentration problem

• Boom vs bubble, and why token spend hasn’t produced 10x better products

• Continual learning, RSI skepticism, and what Nathan wants to work on next

• What the open ecosystem needs economically to survive

Timeline

00:00 Intro
00:27 Open vs closed models, and who actually captures the value
05:12 China, harnesses, and where the real training leverage sits
08:40 Sovereign compute and the national security case for building models
11:18 Uncensored open weights and the bioweapon question
14:29 Anthropic vs OpenAI, ideology and politics
19:35 The Mythos ban and the Fable 5 delays
24:30 The AGI narrative, the talent drain, and antitrust
28:12 Why researchers join Anthropic, and the open Slack culture
34:04 Nathan’s next 12 months: character training and big RL runs
37:55 Continual learning, RSI, and why Nathan is skeptical
43:19 Boom or bubble, tokens vs GPUs
45:12 Why all that token spend never produced 10x products
48:38 Job displacement and the small-business future
52:49 Robotics, world models, and why multimodal lags
57:44 What the open ecosystem should actually do
1:03:17 Why NVIDIA isn’t building a frontier model
1:07:34 The RLHF book, and whether RLHF still matters
1:11:06 GRPO vs PPO and on-policy distillation

Music

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

Daphne Koller wrote the book that many of us learned probabilistic graphical models from, founded Coursera, and now runs insitro, which is trying to make drug discovery a machine-learning problem.

We start with the bitter lesson. She agrees with most of it and then says where it stops working: biology doesn’t have enough data, structure is how people understand anything, and making a drug is a question about an intervention that hasn’t happened yet, not a pattern in data you already have.

Most of the episode is about why drug discovery is hard. Ninety percent of drugs that reach the clinic fail, and mostly not because the molecule was bad. The molecule usually does what it was designed to do. It just turns out the thing it was designed to do had nothing to do with the disease. Only 22% of diseases have any approved drug at all, and she calls that an upper bound on what we understand, not a lower bound.

She also gets into what agents are and aren’t good for in a wet lab, why cells don’t grow faster no matter how many GPUs you point at them, what it would take to have real foundation models for biology, and why almost all of biology is still out of distribution.

Plus GLP-1s and what human data keeps teaching us, whether AI can make the kind of leap that turned a bacterial immune system into CRISPR, and what she’d build if she were starting Coursera today.

Key Topics

• The impact of scaling and data in machine learning

• The importance of structure and causality in AI

• Challenges in drug discovery and biological understanding

• The role of foundation models in biology

• Ethical considerations in AI and biomedical research

Chapters

00:00 Introduction to Machine Learning and Drug Discovery

02:00 The Bitter Lesson and Its Implications

06:48 Challenges in Drug Design and Discovery

11:48 Ethical Considerations in Human Research

17:20 The Drug Discovery Pipeline Explained

29:30 Integrating AI in Experimental Design

35:38 The Role of Human Judgment in Drug Design

37:14 Future of Drug Design: Efficiency vs. Automation

39:37 Challenges in AI and Data Availability for Biology

41:08 Foundation Models: Potential and Limitations

43:39 Causality in Biological Data: Importance and Challenges

45:18 Creativity vs. Understanding in Drug Design

48:17 Balancing Investments in Data, Algorithms, and Experiments

50:07 The Value of Simulations in Drug Discovery

52:03 Mathematical Frameworks in Biology: Utility and Limitations

54:14 The Future of Drug Discovery: Optimism and Innovations

56:28 The Impact of Coursera on Education

01:00:33 The Role of Universities in Lifelong Learning

01:04:06 Connecting Dots: The Fun of Variety in Work

01:05:46 Optimism for the Future of Drug Discovery

Music

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

In this episode, Joseph Suarez from PufferAI explains why he thinks RL never had an algorithm problem, but it had a code problem. Every part of the standard RL stack was running about a thousand times slower than it should have been, and once that got fixed, problems that used to take months started getting solved in seconds on one GPU. We talk about what makes a simulator good for RL, why most of their sims run on CPU, what he wants to do with scientific simulation, and why he open sources all of it instead of writing papers.

Key topics

• Types of RL and their applications

• Challenges in scaling reinforcement learning

• The role of simulators and hardware in RL

• RL in gaming: from chess to complex games like NetHack and RuneScape

• Future directions: scientific simulation and biological modeling

Chapters

00:00 - Introduction to RL and Puff AI

01:50 - Different settings for RL: Games, Robots, Finance

04:10 - RL in LM and other domains

07:00 - Challenges and solutions in RL scaling

09:55 - Building fast, efficient simulators

15:10 - RL for scientific research and simulation

19:57 - RL in complex games: NetHack, RuneScape, Dwarf Fortress

29:55 - Future of RL: Scientific discovery and beyond

Resources

Puff AI - Official Site - https://puffer.ai

NetHack - https://www.nethack.org/

RuneScape - https://www.runescape.com/

Dwarf Fortress - http://www.bay12games.com/dwarves/

OpenAI Gym - https://github.com/openai/gym

Music

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

Florian Brand builds evals at Prime Intellect. The premise of the conversation is that writing a benchmark is the easy part now. Keeping the model from cheating it is the job, and it takes longer than the benchmark itself.

We get into why he thinks you can’t evaluate a model apart from the CLI it runs in, what happens to statistics when a single run costs five figures, and whether the feeling that a model just works can ever become a number.

He also has a few stories about agents finding their way around the scoring that are worth hearing cold.

Timeline

• 00:13 Intro

• 01:00 What evals are for

• 04:05 Agentic benchmarks

• 07:10 Kimi K2 and model diversity

• 08:23 Long-horizon coding tasks

• 10:29 Building a benchmark

• 12:15 MirrorCode

• 14:27 Rubrics and LLM judges

• 16:30 The cost of expert labelers

• 17:49 Long runs and variance

• 19:44 Evaluating the harness

• 24:29 Chinese labs building CLIs

• 30:00 More reward hacking

• 37:45 Tau-bench and economic tasks

• 39:43 Benchmaxxing and GLM 5.2

• 45:15 Statistics and cost

• 47:56 Frontier convergence

• 52:04 Misuse in open and closed models

• 55:35 Self-improvement

Music

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

About

The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

Most labs build language models by scraping the web and filtering afterward. Pierre-Carl Langlais runs it the other way around. At Pleias, the French-German lab he co-founded, the models are built from data he can actually account for, which in practice means open and public-domain sources plus a lot of synthetic data the lab generates itself. It sounds like a self-imposed handicap. It mostly isn’t. One of their models is a 600 million parameter system that runs live inside the Paris subway’s monitoring pipeline.

We cover the SYNTH pretraining dataset and why he thinks “ethical data” has to mean more than copyright-free. He explains why barely 2% of their Common Corpus appears in typical web crawls, and why that gap is really a preservation problem. From there, he gets blunt about benchmark maxing and whether GLM really earns its Opus-class reputation. He also argues that the quiet move by closed labs to hide reasoning traces is mostly about claiming ownership of model outputs. He’s skeptical of sovereign AI, and not shy about how Mistral drifted from frontier research toward French corporate consulting. We finish on NVIDIA’s persona datasets and the odd idea of training on the conditions that produced a text rather than the text itself.

Timeline

• (00:02) Welcome and introductions

• (00:49) Why synthetic data matters, and the SYNTH set

• (04:15) Three reasons to control your training data

• (07:18) What “ethical data” actually means

• (11:08) How Common Corpus got built, from Wikipedia to PDFs

• (16:35) Agentic harnesses and synthetic data

• (20:03) Evaluating data when you train on reasoning traces

• (25:27) General versus specialized pretraining

• (27:08) Benchmark maxing and the GLM question

• (31:51) Getting diversity in, and the NVIDIA personas

• (35:02) Hidden reasoning traces and the fight over model IP

• (38:17) Mid-training and the “It’s All Training” thesis

• (41:47) Can small models actually compete

• (45:01) Cybersecurity and Europe’s strategic gap

• (47:08) Do you need a big model to orchestrate the small ones

• (52:08) Sovereign AI and the limits of national champions

• (56:42) Scaling laws when you control the data

• (01:00:41) The NVIDIA persona datasets

• (01:04:52) What you actually do with synthetic personas

• (01:08:22) Closing thoughts

Music

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

About

The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

Dhruv Batra spent years leading Embodied AI at Meta, training virtual robots to navigate photorealistic 3D scans of real buildings with pure reinforcement learning. Then he left to co-found Yutori and build agents for a very different environment: the web browser.

In this episode, Dhruv explains why he sees these as the same problem. Web agents, in his framing, are robots that act in a browser (pixels in, actions out), and the web turns out to be just as messy an environment as the physical world.

Along the way, we cover his definition of intelligence as “navigation in idea space,” why robotics is lagging LLMs, the sim-to-real gap and why you can’t fake friction coefficients, the teleoperation counterexample to the “it’s a sensor problem” argument, and his provocative claim that under the current paradigm, we solved machine learning and didn’t even realize it. He also makes the case for why the scaling hypothesis isn’t falsifiable, why JEPA-style arguments deserve to be grappled with, how Yutori trains its Navigator models with RL on live websites, and what happens to the ad-supported web when agents, not eyeballs, do the browsing.

Timeline

00:01 — Intro
00:54 — What embodied AI actually means
06:47 — Intelligence as navigation in idea space
13:26 — Habitat: training robots with pure RL, no maps
20:04 — Why robotics is behind LLMs
28:24 — Sim-to-real: what you can and can’t fake
33:34 — “We solved ML and nobody noticed”
37:12 — Leaving Meta, founding Yutori
43:21 — Web agents: screenshots in, actions out
48:15 — Why the web won’t rebuild itself for agents
53:32 — Training Navigator: RL on live websites
1:01:04 — Who pays for the web when agents browse?
1:09:17 — What Yutori means, closing thoughts

Music

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

About

The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

Ion Stoica has done what almost no academic ever does — repeatedly turned university research into billion-dollar companies. He co-founded Databricks (now valued at over $100 billion), Anyscale, Arena AI and Conviva, while his Berkeley lab produced the open source projects the entire AI industry runs on: Ray, vLLM, and SGLang.

In this episode, we ask him how it’s actually done. His answer is surprisingly unromantic: solve a problem people already care about, build an artifact good enough that they adopt it, and pay attention to the moment users start asking “who maintains this after the students graduate?” - that’s when a project becomes a company. He’s also insistent that the credit belongs to his students.

From there, the conversation goes deep into what he’s watching now: why the AI stack has become an order of magnitude more complex than the Hadoop/Spark era, why maximizing GPU utilization is “the name of the game” for any enterprise, and why coding agents will struggle with distributed systems long after they’ve mastered web apps. He shares a memorable reward-hacking story — a load balancer that maximized throughput by dropping requests — explains why the gap between open and closed models sits at about six months, and closes with his case for regulating AI by outcomes, not capabilities.

Timeline

• 00:00 — Introduction: welcoming Ion Stoica

• 01:21 — The playbook: how research projects become companies

• 05:22 — Will vLLM and SGLang stay open source?

• 07:47 — The real bottleneck in the AI stack: complexity, not just hardware

• 14:31 — Should algorithms follow infrastructure, or the other way around?

• 16:13 — Can AI coding tools write distributed systems and GPU kernels?

• 21:09 — Verifiers, harnesses, and the limits of outsourcing understanding

• 25:41 — Reward hacking: the load balancer that dropped requests

• 25:58 — How should enterprises consume GPUs? Utilization as the name of the game

• 30:23 — GPU scarcity: will the compute crunch ever end?

• 35:27 — Hyper-optimization and the risk of locking in today’s architectures

• 37:17 — Open vs. closed models: why every company wants to own the stack

• 40:35 — The six-month gap, and the rising cost of training frontier models

• 43:58 — Kimi, Qwen, and who’s incentivized to keep open models alive

• 45:39 — Regulation: outcomes, not capabilities

• 47:41 — Self-regulation, concentration of power, and auditing open models

• 48:32 — Wrap-up

Music

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

About

The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

Jean-Francois Puget is a Director and Distinguished Engineer at NVIDIA, where he leads the Kaggle Grandmasters team, and he’s ranked third on Kaggle’s all-time list. We caught him on the day NVIDIA announced Nemotron Ultra and its new agent skills repo. We talk about what skills actually are, why they beat MCP tools on context cost, and how NVIDIA built an evaluation pipeline to separate skills that help from skills that don’t.

From there we talk about the thing JFP cares about most: evaluation. He explains why most LLM benchmarks reward overfitting, how his team discovered O3 could pick the right files to fix SWE-bench issues without reading them, and why the only benchmarks he trusts are the ones where you commit before you see the score, which is exactly how Kaggle works. He predicts a “bloodbath” for the wave of competitors letting coding agents chase leaderboard scores with no notion of validation.

We also get into what coding agents are actually good for (”a mix of a genius and a dumb person”), the multi-agent system at NVIDIA that built a working PyTorch clone that runs 10x slower than the real thing, his unfiltered take on frontier lab PR and the Mythos release, whether AI is a bubble, and the story of how his team won ARC-AGI with a 4-billion-parameter model at 20 cents a task, including jumping from third to first in the final hours of a seven-month competition.

Timeline

• 00:00 — Intro

• 01:05 — NVIDIA’s announcements: Nemotron Ultra and the agent skills repo

• 07:21 — Skills vs MCP tools, and progressive disclosure

• 10:24 — Agents that write their own skills: a new form of learning

• 13:33 — When overfitting is fine (and when it isn’t)

• 15:47 — Why most LLM benchmarks reward overfitting

• 17:06 — The SWE-bench contamination story: O3 picks files without reading them

• 19:45 — How LLMs changed Kaggle, and the coming “bloodbath”

• 25:40 — What makes a good data scientist: evaluation and one-bit experiments

• 28:56 — Running Codex at scale: the top token consumers at NVIDIA

• 29:37 — Did coding agents kill AutoML?

• 30:16 — Genius and dumb at once: the limits of coding agents

• 35:21 — Humans in the loop, sandboxing, and the teenage hacker who never wrote code

• 37:42 — Mythos, frontier lab PR, and open source

• 40:08 — Why NVIDIA builds open models, and where it’s already frontier

• 43:48 — World models, robots, and the coffee test

• 49:20 — Why agents still can’t play Dota

• 50:24 — Is AI a bubble?

• 53:14 — Winning ARC-AGI with a 4B model at 20 cents a task

• 57:39 — Kaggle is a legal drugMusic:

  Music: “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

A new paper called DSpark came out recently (From the DeepSeek team,), and I wanted to understand what it adds beyond regular speculative decoding. The basic trick is to draft several tokens cheaply, then verify them with the big model in one pass. DSpark builds on that with two ideas: better long drafts, and a smarter way to decide how many drafted tokens to verify in production.

1. A full forward pass for every single token

An autoregressive language model produces text one token at a time. To generate token t+1 it needs a forward pass conditioned on everything up to token t.

To see whether that’s a problem, let’s follow one decoding step through the GPU and watch where the time goes. To generate one new token, the model has to produce its logits, the pre-softmax scores over the vocabulary. Getting them means every weight matrix in the model has to travel from the GPU’s main memory into the arithmetic units. That main memory is called HBM (High Bandwidth Memory), and it holds the model’s weights along with the KV cache, the stored attention state. For a 70B model in 16-bit, one token’s worth of logits costs about 140 GB of weight reads.

The arithmetic done with all that data is tiny by comparison: each weight participates in roughly one multiply-add per token. An H100 does on the order of a thousand trillion multiply-adds per second but reads only about 3 TB/s out of HBM. So the decoding step is memory-bound: its wall-clock time is set by how long the weight reads take, not by the math. The opposite regime, where the arithmetic itself is what you wait on, is called compute-bound. Decoding is nowhere near it, and that gap is the whole opportunity. In the memory-bound regime the arithmetic units are mostly idle: the multipliers finish their work instantly and then sit there while the next slab of weights streams in.

The loophole is that the weight reads are paid per forward pass, not per token. Push eight token positions through the same pass and the weights are read from HBM once, then multiplied against eight vectors instead of one. The memory traffic barely changes. You do eight times the arithmetic, but arithmetic was the idle resource anyway, so a pass over eight positions takes barely longer than a pass over one.

You already know this effect as the prefill/decode gap. Prefill is when the model ingests your prompt. All the prompt tokens are known up front, so they go through the model together, thousands of positions per pass, and the weight-read cost is split across all of them. Decoding generates one new token per pass and pays the full cost every single time.

Decoding can’t batch like prefill because the input at position t+1 is the token sampled at position t; it doesn’t exist until the previous pass finishes. But suppose someone handed you a guess for the next eight tokens. Now you do have all eight inputs, tentatively, and the big model can process them prefill-style in one pass. And the same pass gives the model its own next-token distribution at each of the eight positions. Those distributions are all it needs to go through the guess position by position and find where it stops being right. Verification is prefill-shaped. Generation is decode-shaped.

Who writes the guess? A smaller, cheaper model. That’s speculative decoding: everything in this post converts slow generation into fast verification plus a cheap guess.

2. Draft cheap, verify in parallel

Speculative decoding runs as a loop: draft a few tokens, verify them, keep the good prefix, repeat. The version everyone uses is due to Leviathan et al. and Chen et al. A lightweight draft model proposes a block of γ candidate tokens. The target model runs one forward pass over the whole block and gets its own next-token distribution at every position. Then it walks the block left to right and decides, position by position, whether it agrees with the draft.

Say the last confirmed token is D. Call it the anchor: the confirmed token this round’s draft hangs off. The draft proposes E F G H. The target might accept E and F and reject G. A rejection isn’t wasted work: the target already computed a distribution at G’s position, so it samples a replacement G* from a corrected version of it. G* is called the correction token. Everything after the first rejection (H) is thrown away, because it was conditioned on a token that never happened.

If every draft token is accepted, the round earns one extra token for free: the pass also computed the target’s distribution at the position after the last draft token, so the target samples from it and appends the bonus token.

The acceptance rule, and why the output is exact

The big claim of speculative decoding is that it’s lossless: the output tokens are distributed exactly as if the target model had generated them alone, temperature and all. This is a real guarantee, not an approximation, and it comes from a rejection-sampling rule. At position k, with draft distribution pᵈ and target distribution pᵗ, the drafted token xₖ is accepted with probability

In other words: when the target assigns the drafted token at least as much probability as the draft did, pᵗ(xₖ) ≥ pᵈ(xₖ), keep it always. When the draft over-sampled it, giving it more probability than the target does, keep it only in proportion pᵗ/pᵈ. On rejection, the replacement is sampled from the residual distribution norm(max(0, pᵗ − pᵈ)): max keeps the tokens where the target wanted more mass than the draft gave them, and norm rescales what’s left to sum to 1.

A nice consequence is that the per-position acceptance probability equals

which says the drafter’s entire job is to stay distributionally close to the target. DSpark reuses this exact quantity later as a free training label. (Why the rule is exact, and why this distance is total variation rather than KL: Appendix A1 and A2.)

3. The latency equation

How much time does it take to produce one token? Speculative decoding pays per round, one draft plus one verification, and gets a variable number of tokens back, so its cost is time-per-round divided by tokens-per-round. Let τ be the average number of tokens you get per round (accepted draft tokens plus the bonus/correction token), T_draft the time to write the draft, and T_verify the time for the target’s verification pass. Then the latency per generated token is

That leaves three ways to go faster. You can draft faster, shrinking T_draft. You can draft better, raising τ by getting the drafter to agree with the target more often and for longer. Or you can verify smarter, and stop spending T_verify on draft tokens that were never going to survive. Most of the literature picks one of the three.

DSpark is unusual in going after two terms at once: τ with an architecture change (Parts 5 and 6), and T_verify with a scheduler (Parts 7 to 9). The second attack only makes sense once you stop thinking about a single user and start thinking about a serving system with hundreds of concurrent requests. But first, the standard menu of drafter designs.

4. Two ways to build a drafter

Autoregressive drafters (EAGLE, DeepSeek’s MTP (multi-token prediction)) are small language models that generate the draft one token at a time, each conditioned on the last. They produce coherent drafts, but the drafting cost scales linearly with the block size, T_draft ∝ γ. To keep the draft cheap they have to stay shallow (EAGLE-style drafters are often a single transformer layer) and keep γ small, which caps both the block length and how much the drafter can know.

Parallel drafters (Medusa, and more recently DFlash) fill in all γ positions in a single forward pass. Feed in the anchor token plus a row of mask tokens, read out logits everywhere at once, diffusion-style. Now T_draft is nearly independent of γ, so you can afford a much deeper drafter (DFlash uses 5 layers where EAGLE uses 1) and much longer blocks (γ = 16 costs about what γ = 4 costs).

DFlash, the parallel drafter DSpark builds on, is worth describing in some detail because DSpark reuses its entire skeleton. The drafter is a small transformer, 5 layers in the paper. Its input for one drafting round is the embedding of the anchor token (the last token the target actually confirmed) followed by mask-token embeddings, placeholders for the positions to be filled in. All positions attend to each other bidirectionally, and one forward pass produces logits for every position in the block. The drafter doesn’t even own an embedding table or an output head. It borrows the target model’s, frozen.

Its central trick is how it sees the conversation, called KV injection. While the target processes the context, hidden states from a few of its layers are saved, projected down into the drafter’s width, and prepended to the keys and values of every drafter layer, so each draft position attends to the target’s own internal representation of everything said so far. All of it is computed once, at prefill, and reused every round. The drafter isn’t understanding the conversation with 5 layers of its own; it’s reading the big model’s notes, which is a big part of why it can imitate a model thousands of times larger. (Mechanics and a diagram: Appendix A3.)

So a parallel drafter is both faster to run and free to be deeper. That sounds like it should win outright, but it doesn’t…

5. Where parallel drafters break: the multi-modal collision

A parallel drafter predicts every position independently, in one shot. Position 3 can’t see what position 2 actually sampled, only the shared context. So when the context admits several equally good continuations, each position hedges across all of them.

Take the context “Sure, “. The target model is happy with either of course or no problem. A parallel drafter, sampling each position from its marginal, can happily emit of problem or no course: fragments of two valid answers stitched into an invalid one. This is the multi-modal collision problem, known since the non-autoregressive machine translation days (Gu et al., 2018). Each token is individually plausible, the combination is garbage, and the target rejects it.

The damage shows up as suffix decay: acceptance falls off rapidly with position in the block. The paper measures this with a nice metric, position-wise conditional acceptance: at position k, only count cases where positions 1…k−1 were all accepted, then ask how often k is accepted too. This strips out the compounding survival penalty and shows the drafter’s raw predictive quality at each depth.

Here are the curves (Qwen3-4B target, chat domain):

Why DFlash still gets the longer accepted length

The curves make Eagle3 look like the better drafter everywhere past position three. And yet, on accepted length, DFlash beats it on nearly every benchmark in the paper. The mismatch is explained by how verification scores a block.

Verification accepts a prefix and discards everything after the first rejection, so the expected haul per round compounds multiplicatively. Write the expected accepted count in terms of the conditional acceptance rates c₁, c₂, …:

Every term contains c₁, so raising c₁ by 10% grows the entire sum by 10%, while raising c₆ only moves the last couple of terms. A rejection at position 1 erases the whole block; a rejection at position 6 erases one or two tokens. Whatever a drafter is good at, being good at position 1 is worth several times more than being good anywhere else.

And position 1 is where the deep parallel drafter has its edge. No draft tokens exist yet at the first position, so both drafter types condition on the same thing, the verified context, and dependency modeling buys nothing there. What decides position 1 is raw capacity, and the latency budgets are lopsided: the autoregressive drafter runs once per position and must stay shallow (Eagle3 is one layer), while the parallel drafter runs once per block and affords five layers plus KV injection.

6. DSpark idea #1: bolt a bigram onto the parallel drafter

The obvious fix for suffix decay is to make the drafter autoregressive again, but then you’re back to T_draft ∝ γ. DSpark adds autoregression only where it costs almost nothing. The expensive part, the 5-layer KV-injected DFlash backbone, runs fully parallel as before: one pass, producing hidden states h₁…hᵧ and base logits U₁…Uᵧ for every position. After that, a small sequential head passes over the block left to right and adds a correction to each position’s logits, and the correction depends on the tokens already sampled before it:

In this formula, Uₖ is what the parallel backbone already gave us: the base logits for position k, one score per candidate token v over the vocabulary (V ≈ 10⁵ tokens), so Uₖ(v) is token v’s score. Bₖ(x₀, x<k, v) is the sequential head’s correction to that score, and it’s the only term allowed to look at the block’s history: the anchor x₀ and the draft tokens x<k already sampled at earlier positions.

The default B is a small Markov head. It throws away everything except the immediately preceding token: the correction becomes B(xₖ−₁, ·) ∈ ℝV, a full vector of logit corrections, one per candidate next token, selected by which token came just before. Written out as a table that’s a V×V matrix, a row per possible previous token and a column per possible next token. In other words, a learned bigram model, stored factorized at rank 256: per position the sequential loop costs one table lookup plus one small matrix-vector product, invisible next to the target’s verification pass. And it is learned with the rest of the drafter rather than counted from a corpus (dimensions and training: Appendix A4).

Back to the collision. The backbone, in parallel, gives position 1 as {of, no} and position 2 as {course, problem}. The sequential loop samples position 1 first and gets of. When it moves to position 2, the bigram bias for “of” boosts course and suppresses problem, so the drafter no longer stitches “of problem” together.

Does one token of memory suffice? The authors also try an RNN head, a small gated recurrence that carries the whole within-block prefix instead of just the last token. It helps only marginally, and only at long blocks. I think that near-null result is the most useful thing in the paper: suffix decay in parallel drafters is mostly a problem of adjacent-token incoherence, not of missing long-range information.

Through KV injection (Part 4), every draft position already sees the target’s representation of the whole conversation. The missing piece is what the neighboring positions sampled, and that doesn’t exist until after the forward pass is over. Only something that runs at sampling time can close that gap, and a bigram is the smallest such thing.

Across Qwen3-4B/8B/14B, DSpark’s macro-average accepted length comes out 27–31% above Eagle3 and 16–18% above DFlash, and a 2-layer DSpark already beats the 5-layer DFlash, so the gain comes from the dependency modeling and not from extra parameters. On the conditional-acceptance curves, DSpark opens where DFlash opens and stays flat where Eagle3 stays flat.

7. The serving problem: draft tokens compete for batch space

Everything so far was a single-user story: one request, one GPU, minimize that one user’s latency. In production the target model is shared. One copy serves hundreds of users at once, and each of its forward passes processes a batch. The batching is done by the serving engine, the software layer that owns the GPU and runs the model; vLLM and SGLang are the open-source examples, and DeepSeek runs its own. Each pass, the engine collects the pending tokens of many requests and pushes them through together: the amortize-the-weight-reads trick from Part 1, applied across users instead of across positions.

But the batch is a shared, finite resource. A small batch keeps the pass memory-bound, so extra tokens ride along at no cost (Part 1). Keep adding tokens though, and at some batch size the arithmetic units stop being the idle party; past that point, every additional token makes the pass measurably slower for everyone in it. This gives every engine a characteristic curve, SPS(B): steps per second as a function of how many tokens the batch holds. It stays flat while the pass is memory-bound and falls once the batch pushes it into compute-bound territory, the two regimes from Part 1.

Every draft token a request submits for verification takes up one token-slot in the batch, and a rejected token wastes its slot. On the flat part of the curve that waste is harmless, so even a 20% long shot is worth checking. On the steep part, the same token contributes 0.2 expected tokens while slowing down the several hundred others sharing the pass, and it isn’t worth the slot.

The right amount of verification also depends on the content. Drafters do well on structured text and badly on open-ended text: on Qwen3-4B the paper measures roughly 5.6 accepted tokens per round on math, 5.1 on code, 3.5 on chat. A single fixed length is therefore wrong in both directions at once, wasting slots on chat requests whose late tokens were never going to be reached and cutting short code requests that could have gone longer.

Before this paper, the DeepSeek’s production system drafted a single token per round, the MTP-1 setup, even though they had already built multi-token drafters (MTP-3, MTP-5). With a static 3-token draft, every request adds 3 tokens to every batch whether the load or the content justifies it, and at production concurrency many of those tokens are late-position chat tokens headed for rejection. The batches grow, every pass slows, and the slowdown across all users outweighs the extra accepted tokens: total throughput drops. Production stayed at the largest setting that never backfired, one token per round, at a price: at γ = 1 a round yields at most two tokens, the draft plus the bonus, so the ceiling is roughly a 2x speedup and everything Part 4 built for long parallel blocks goes unused.

The way out of that dilemma is to stop picking one length for everyone and instead decide per request, per step: given the load right now, how many of this request’s drafted tokens deserve a batch slot? The drafter has already produced its full γ-token block, so that cost is sunk; the only choice is which of those tokens get slots, and whatever is cut is dropped unseen. Deciding needs a per-token estimate of the chance a slot pays off, plus a rule turning those estimates and the SPS curve into lengths.

8. DSpark idea #2: choose verification lengths by expected throughput

The scheduler is the part of the engine (Part 7) that decides, before each forward pass of the target model, what goes into that pass: which requests participate, and (the new degree of freedom here) how many draft tokens each request contributes. It answers Part 7’s question once per step, for the whole batch at once.

For one verification step, there are R active requests, each with a freshly drafted γ-token block, and the scheduler has to pick a verification length ℓᵣ ∈ {0, …, γ} for every request r: verify the first ℓᵣ draft tokens and drop the rest. A choice of lengths is judged by the expected token throughput of the whole system for this step:

SPS(B) is the Part 7 cost curve; the engine measures it once at startup by timing passes at a range of batch sizes and keeps the results as a lookup table. τ is the expected number of output tokens the pass will produce for the whole batch, i.e. Part 3’s per-request τ summed across all R requests. The two +1s are both the anchor: even at ℓᵣ = 0 a request still sends one token through the pass and gets one token back, the bonus or correction from Part 2. Each admitted draft token at position j then adds aᵣ,ⱼ to τ: the probability that it survives verification and actually ends up in the output. Expected tokens per step times steps per second gives expected tokens per second. The one missing part is those survival probabilities (a_r,j)

The confidence head

What does it mean for a slot to pay off? A draft token survives verification if the left-to-right check actually reaches it (every earlier token in the block was accepted) and accepts it too. “Reaches it” is the price of batched verification: the whole block is checked in one pass, but acceptance is prefix-only, so a rejection at position 3 means positions 4 and onward are discarded without ever being checked, however good their tokens were.

To do that, they use a confidence head, which outputs one scalar per position, cₖ, the conditional piece of survival: the probability that position k is accepted given that the check reached it. This is the same conditional acceptance rate the Part 5 curves measured, now predicted per token instead of averaged over a benchmark. The head itself is small. It reads the backbone hidden state plus the Markov embedding of the previous token and runs them through a single linear projection and a sigmoid. Its training label is free: the exact acceptance probability from Part 2 is computable at every training step and used directly as a soft label (Appendix A4).

Because the cₖ are conditionals, the chain rule turns them into full survival probabilities for free:

These aₖ, computed per request, are exactly the aᵣ,ⱼ the objective consumes, with one requirement: the arithmetic only works if the scores are calibrated, meaning a token scored 0.8 really is accepted about 80% of the time. Raw heads are overconfident; per-position temperature scaling shrinks the predicted-versus-observed gap from 3–8% to about 1% (Appendix A5).

Picking all R lengths at once sounds combinatorial, but the survival probabilities have a property that makes it easy. Within a request, aᵣ,ⱼ = cᵣ,₁·cᵣ,₂⋯cᵣ,ⱼ is a product of numbers between 0 and 1, so tacking on another factor can only shrink it: aᵣ,₁ ≥ aᵣ,₂ ≥ … ≥ aᵣ,ᵧ. In other words, surviving to j+1 requires surviving to j first, so it’s the stricter condition.

That ordering is what licenses a greedy algorithm. Extending request r’s length from j−1 to j adds exactly aᵣ,ⱼ to τ and exactly one token to B, a gain and a cost both known in advance. So pour all candidate extensions from all requests into one pool, sort by aᵣ,ⱼ, and admit from the top, recomputing Θ after each admission (a table lookup). The within-request constraint (you can’t verify position 3 without positions 1 and 2) enforces itself: since each request’s survival probabilities are already in decreasing order, its position-2 candidate always sits above its position-3 candidate in the global sort.

When the batch is nearly empty, SPS(B) sits on its flat stretch, admitting another token raises τ almost for free, and the scheduler verifies long: 4–6 tokens per request in the paper’s numbers. As the batch fills, each admitted token drags SPS down, only tokens whose survival probability beats the drag get in, and the budgets shrink. Within one batch, a code request at 0.9 confidence keeps a long verification while a chat request whose confidence collapses by position 2 gets cut there, with no threshold set anywhere.

A version of this that breaks losslessness

Losslessness needs one more condition beyond the accept/reject rule of Part 2, and this one falls on the scheduler: whether token k gets admitted for verification must not depend on the value of token k. The proofs call this non-anticipation. Fixed verification length satisfies it trivially, but a length chosen by the greedy search above can violate it.

The violation runs through the confidence head, which reads the Markov embedding of the previous sampled token: c₂, and therefore a₂, is a function of which x₁ was drawn. The block is fully sampled before scheduling (Part 7), so a₂ is available; the question is whether the scheduler may consult it. Suppose it evaluates the whole admission path and takes the argmax: Θ at lengths 0, 1, 2. The length-2 value used a₂, which used x₁. So the comparison that decides whether x₁ is admitted at all already depends on which x₁ was drawn, and draft tokens that lead to confident continuations get admitted more often than ones that don’t.

For example, with a two-token vocabulary: the target wants {A: 0.7, B: 0.3}, the drafter samples from {A: 0.5, B: 0.5}, and suppose drawing A leads to a high c₂ while drawing B leads to a low one, so the argmax scheduler admits the draft after drawing A and skips it after drawing B. When A is drawn (probability 0.5), it is admitted and accepted with probability min(1, 0.7/0.5) = 1. When B is drawn, nothing is admitted and the target samples fresh from {0.7, 0.3}. Total: P(output = A) = 0.5 + 0.5 × 0.7 = 0.85 instead of 0.7.

The clean algorithm’s solution is an early-stopping break: walk the sorted admission path and stop at the first admission that lowers Θ. Then the decision about position k is finalized before anything computed from xₖ is ever consulted, and the proof goes through.

9. Making it run in a real engine

Inside DeepSeek’s actual engine, the Part 8 algorithm breaks in two places. The first is that the SPS curve isn’t smooth. Kernels are tuned for particular batch shapes, so pass time jumps at tile-size and dispatch boundaries rather than rising gradually. On a jagged curve the early-stopping break turns into a liability: Θ can dip at a cliff and recover just past it, and a search that quits at the first dip strands the system at a local optimum.

The second is about timing. A modern engine assembles the next pass while the current one runs, and with CUDA-graph replay the next batch size has to be fixed before the current pass finishes. The Part 8 scheduler can’t meet that deadline, since it needs the current step’s confidence scores, and those don’t exist until the step is done. Run it synchronously and the GPU stalls between every pair of steps.

The deployed version works around both problems by computing the batch’s capacity a couple of steps ahead of time. The scheduler fixes K, the number of tokens the next pass can afford to verify, using confidence scores from two steps back, so it’s ready before the pass launches. The tokens that actually fill those K slots are still chosen at the last moment from the current step’s real confidence scores, by sorting the live candidates as in Part 8 and keeping the top K.

This design also settles the losslessness question from Part 8, where the danger was that computing the cut-off consulted downstream token values. Here the cut-off is K, fixed from two-step-old data before any of this step’s tokens existed, and the fresh ranking that fills the slots consults only tokens earlier in the block, never token k itself or anything after it. That is exactly what non-anticipation demands, so it holds by construction, the early-stopping break can go, and the search over the jagged curve can run globally to the true maximum. The same design choice that fixed the pipeline stall also restored exactness; my guess is the pipeline constraint came first and the losslessness argument was noticed after the fact.

The live-traffic numbers

Deployed on DeepSeek-V4-Flash and V4-Pro under real user traffic, against the incumbent MTP-1:

The paper’s Figure 8 shows that at moderate concurrency the average verification budget sits at 4–6 tokens per request, and as concurrency rises the scheduler shrinks it, dropping low-confidence tokens before they occupy batch slots.

Next Steps

A few things the paper leaves open. The SPS table is profiled once and indexed by batch size alone, but real per-step cost also depends on the batch’s context-length mix, so a 1-D curve is an approximation. The confidence head is trained on the analytical acceptance labels under teacher-forced prefixes but deployed on sampled ones. That’s a train/inference mismatch. Calibration is fit on a held-out set, and live traffic drifts; whether the head stays calibrated online isn’t reported. And the drafter still burns a full γ-block forward on every request, even hopeless ones. The scheduler prunes verification, not drafting.

10. What to actually remember

The important thing about DSpark is not just that it makes speculative decoding faster. Earlier work mostly asked how to build a better drafter: make it cheaper, deeper, or more accurate. DSpark shows that this is only half the story. In a real serving system, the question is not “how many tokens can I draft?” but “which drafted tokens are worth spending target-model batch capacity on right now?” The paper’s two main ideas answer both sides of that question: a semi-autoregressive Markov head makes long parallel drafts much more coherent, and a throughput-aware scheduler decides how much of each draft to verify under the current load.

A. Appendix: the fine print

Details that back the main text but aren’t needed to follow it.

A1. Why the rejection rule is exact

Check any token v. It reaches the output two ways: drafted and kept, or rejected and resampled. If pᵗ(v) ≤ pᵈ(v), the kept route alone contributes pᵈ(v) · pᵗ(v)/pᵈ(v) = pᵗ(v) and the residual has zero mass on v. If pᵗ(v) > pᵈ(v), the kept route contributes pᵈ(v) and the resample supplies exactly the missing pᵗ(v) − pᵈ(v), because the overall rejection probability equals the residual’s normalizer. Either way: pᵗ(v). The same accounting shows why the replacement can’t simply be drawn from pᵗ: acceptance already gave every token min(pᵗ, pᵈ), so the rejection branch may supply only the shortfall. With pᵗ = {A: 0.7, B: 0.3} and pᵈ = {A: 0.5, B: 0.5}, resampling from the full pᵗ would give P(A) = 0.5 + 0.2 × 0.7 = 0.64 instead of 0.7, tilting the output toward the tokens the draft over-proposed.

A2. The distance is total variation, not KL

The distance in the acceptance formula is total variation, not KL. TV is symmetric, so there is no forward or reverse version of the statement, and Pinsker’s inequality (TV ≤ √(KL/2)) says pushing either KL down also pushes acceptance up. The paper’s distillation loss skips the surrogate entirely and minimizes the L1 term directly, so it is optimizing the acceptance rate itself.

A3. KV injection, in detail

Its central trick is how it sees the conversation, called KV injection. The drafter never reads the context as text, and it never runs its own forward pass over it. Instead it recycles work the target already did. When the target processes the context, every one of its layers produces a hidden state for every token: a vector encoding that token after the layer has mixed in information from everything before it. DFlash saves these hidden states from a handful of target layers; different depths carry different levels of abstraction, from surface features early to semantics late, so the drafter gets a cross-section rather than a single view. For each context token, the saved vectors are concatenated across the chosen layers and passed through a learned projection down into the drafter’s much smaller hidden size, giving one compact context vector per context token. All of this is computed once, during the target’s prefill, and reused on every drafting round after that.

These vectors enter the drafter through attention. Recall the split of roles there: queries ask, keys and values are what gets read. In every layer of the drafter, the context vectors are projected into keys and values and prepended to that layer’s own keys and values, so from a draft position’s point of view they behave like extra tokens it can attend to. The draft positions do the querying; the target’s representations do the answering. Each draft position therefore sees two things at once: the other positions in its block, and the target’s own internal summary of everything said so far, at several depths. The drafter isn’t trying to understand the conversation with 5 layers of its own. It’s reading the big model’s notes, and the notes were written by the very network it’s trying to imitate, which is a big part of why a 5-layer model can predict what a model thousands of times larger will say next.

One construction detail: in the original DFlash the anchor plus γ masks go in and only the mask positions are predicted; DSpark trims this to anchor plus γ−1 masks and predicts at the anchor slot too, which saves a little compute at the same quality.

A4. The Markov head and the confidence head: dimensions and training

At this vocabulary size the bigram table would have ~10¹⁰ entries, so it’s stored factorized: B = W₁W₂, with W₁ ∈ ℝ^{V×256} and W₂ ∈ ℝ^{256×V}. Row xₖ−₁ of W₁ is a 256-dimensional embedding of the previous token (the paper’s Markov embedding, which the confidence head in Part 8 also reads), and multiplying it by W₂ expands it back to a V-dimensional correction. Per position: one table lookup plus one 256-by-V matrix-vector product.

W₁ and W₂ are not counted from corpus statistics. They are learned by gradient descent along with the rest of the drafter, trained to imitate the frozen target’s outputs, with Part 2’s TV distance as part of the loss.

The confidence head’s training label is free. Part 2 showed that the acceptance probability at a position is exactly 1 − ½‖pᵈ − pᵗ‖₁. Training the drafter already computes both distributions: the frozen target runs on the training data to provide supervision, which yields pᵗ at every position, and pᵈ is the drafter’s own output. So the true acceptance probability is available in closed form at every training step, and the confidence head is supervised directly with it as a soft label, without ever simulating an accept/reject decision.

A5. Calibrating the confidence head

A confidence head is calibrated if its numbers mean what they say: of all the tokens it scores 0.8, about 80% should actually be accepted. Simpler schemes don’t need this. A threshold rule like “drop everything below 0.4” only compares scores to a cutoff, so it works as long as better tokens get higher scores, even if every score is inflated. DSpark’s scheduler does arithmetic with the scores. It multiplies them into survival probabilities and sums those into an expected token count for the whole batch, so if the head says 0.9 where the truth is 0.7, the count is wrong and the scheduler ends up maximizing a throughput that doesn’t exist. Neural confidence estimates are, reliably, overconfident in exactly this way.

The fix is temperature scaling with one twist, which the paper calls Sequential Temperature Scaling. Because the scheduler consumes cumulative products, aₖ = c₁⋯cₖ, the calibration targets the products rather than the raw scores: walking left to right, each position gets one temperature, fit on held-out data to shrink the gap between the predicted and the observed acceptance of the cumulative product, with earlier positions held fixed. Temperature scaling only rescales scores, it never reorders them, so the ranking the head learned survives. The average gap between predicted and observed acceptance drops from 3–8% to about 1%.

A6. The empty-system limit

In the limit of an empty system, the maximization says to verify the entire γ-token block, since an admitted token can only add to τ. Light-load speed is therefore capped by γ and by drafter quality rather than by the scheduler, which is part of why Part 6’s fight to keep acceptance high at long blocks matters. The one cost light load doesn’t forgive is T_{draft}, paid every round regardless of what gets verified.

Source: Cheng et al., DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation (DeepSeek-AI & Peking University, 2026). Figures in this post are stylized redraws of the paper’s Figures 1, 2, and 7; all numbers are from the paper. DeepSeek released the DSpark checkpoints for the V4 preview models along with DeepSpec, a training repo where Eagle3, DFlash, and DSpark are all trained on the same data, so the baselines in this comparison are held fixed for once. Background reading: Leviathan et al. and Chen et al. (2023) on speculative sampling; Gu et al. (2018) on non-autoregressive generation and multi-modal collision; Li et al. on the EAGLE series; Chen et al. (2026) on DFlash.

References and links

• Cheng et al. (2026), DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation

• Chen et al. (2026), DFlash: Block Diffusion for Flash Speculative Decoding

• Leviathan et al. (2023), Fast Inference from Transformers via Speculative Decoding

• Chen et al. (2023), Accelerating Large Language Model Decoding with Speculative Sampling

• Li et al. (2024), EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty

• Li et al. (2025), EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test

• Cai et al. (2024), Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads

• DeepSeek-AI (2024), DeepSeek-V3 Technical Report — includes the multi-token prediction (MTP) objective.

• Gu et al. (2018), Non-Autoregressive Neural Machine Translation

• Kwon et al. (2023), Efficient Memory Management for Large Language Model Serving with PagedAttention — vLLM.

• Zheng et al. (2023), SGLang: Efficient Execution of Structured Language Model Programs

• DeepSeek-AI DeepSpec repository

In this episode, we talked with Dimitris Papailiopoulos, researcher at Microsoft Research’s AI Frontiers lab and professor at the University of Wisconsin, about doing research in the age of agents. Dimitris told us about the Sunday morning that changed how he works: he handed Claude Code and Codex a question he’d been sitting on for years, went about his day, and came back to an answer. After a few days of dread about what’s left for humans, he landed somewhere more optimistic, calling this the golden age of asking questions.

We talked about his “smallest transformer that can add” leaderboard, a symbolic GSM8K solver built from if-else statements, and what happened when he put two Claude Code instances in the same file system and told them to do something cool (one pair invented a communication protocol, the other played Battleship). We also got into diversity and slop in agent-generated ideas, why agents get stubborn after a million tokens, harness overfitting on Terminal-Bench, continual learning and world models, whether agents need vision, and where information theory actually helps in AI and where it’s a katana used to make coffee.

Timeline

00:00 Intro
01:45 How agents changed the way Dimitris does research
04:30 A Sunday morning with Claude Code, Codex, and GSM8K
07:15 The dread, then the golden age of asking questions
08:20 Taste and verification, and how we train students now
09:53 Will models make human verification obsolete?
11:30 The smallest transformer that can add 10-digit numbers
13:40 Humans as initializers for gradient descent in idea space
15:32 Allen on diversity, slop profiles, and high temperature research
21:44 When Claudes meet: Battleship, invented protocols, and a grokking paper
25:53 Single agent vs multi-agent under fixed compute
30:28 Auto-research benchmarks and what agents actually accelerate
35:14 Inside the symbolic GSM8K solver (with a live progress check)
40:04 Idea overfitting and why agents refuse to change course
44:00 Learning from failure traces and harness overfitting
48:04 Continual learning, memory files, and world models
51:30 Why don’t labs personalize models on your own history?
57:52 Agent-to-agent communication: is Jira the right tool?
1:01:25 Multimodality: vision as a tool vs one unified model
1:05:40 Information theory and AI, or making coffee with a katana
1:11:23 Closing thoughts: ask bigger questions

Music:

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

We discuss the platonic representation hypothesis and its limits, why clustering structure matters more than global geometry, and Phillip's new neural thickets paper arguing that post-training is easier than people think because pre-trained weights already sit near solutions to downstream tasks. Phillip also explains why he thinks LLMs are already world models, why he's betting on RNNs making a comeback, and why his most exciting current direction is artificial life: putting LLM agents in open environments with no fixed task and studying them like new organisms.

Timeline:

00:00 Intro song
00:13 Intro
01:05 What is representation learning and why it matters
04:09 What makes a representation good: minimality and sufficiency
10:03 How cross entropy and contrastive learning shape representations
14:35 Dimensionality reduction and why dimension isn't the right complexity measure
16:35 Compression and geometric clustering during training
19:27 The platonic representation hypothesis and what actually converges
22:53 Local neighborhoods vs global structure: the Aristotelian follow-up
24:33 When convergence is strong: truth vs the space of possibility
28:09 Is there true similarity in the world? The Bouba-Kiki effect
30:56 World models vs autoregressive LLMs
32:14 Diffusion LLMs as a special case of autoregressive models
33:42 What architectures win in five years: the case for RNNs
36:11 Grad student descent, or do we actually have principles?
40:51 Feathers and wings: what to take from biology
43:17 How close are we to brain-like models? Marr's three levels
47:01 Are better models becoming less human-like?
49:38 Is pre-training all you need? The neural thickets paper
54:18 LoRA, low rank fine-tuning, and why post-training is easier than we thought
56:01 RL environments and what our benchmarks actually test
1:01:11 Artificial life: LLM agents as new organisms
1:07:20 What's overlooked in AI research right now
1:08:36 Why stay in academia, and doing science in the age of Opus

Music:

• "Kid Kodi" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

  ---

About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

A Transformer remembers by keeping everything. Every token it has read stays in the KV cache, and any later token can look back at any earlier one exactly. That is why attention is so good at recall, and why its memory and compute grow with the length of the context.

Linear attention makes the opposite bet. It throws the cache away and keeps a single fixed-size matrix: a running summary that every new token updates and every query reads. Memory stops growing and decoding gets cheap. But a fixed-size summary cannot hold an unbounded number of facts cleanly, so writing something new can disturb what is already stored. Almost all the recent progress here (DeltaNet, Gated DeltaNet, KDA, and now Gated DeltaNet-2) is about making that write more surgical.

This post builds the whole thing from the ground up. You do not need to know any of these models going in; just linear algebra and a rough sense of what attention does. Shape of the argument

1. A fixed-size state is an associative memory built by summing key–value outer products, and reading it is content-addressed lookup.

2. Because it is fixed-size, overlapping keys interfere. That is the one limitation everything else fights.

3. Giving an old key a new value is the hard case. Adding leaves the stale value behind; replacing the matrix destroys every other fact; the delta rule does the surgical thing.

4. The delta rule looks sequential but trains in parallel as one small triangular solve per chunk.

5. Decay, then per-channel decay (KDA), then decoupled erase/write gates (GDN-2) are three refinements that keep that solve intact.

Which memory we mean

“Memory” means three different things in a language model. This post is about one of them.

• The weights. The query/key/value projection matrices and the gates, learned during training and fixed afterward. Long-term knowledge, changed only by more training. Not this.

• The KV cache (softmax). The full list of past keys and values, so any query can look back exactly. Lossless, grows with context, reset each sequence. Linear attention removes this.

• The recurrent state (linear attention). One fixed-size matrix summarizing every token so far. Lossy, fixed size, reset each sequence. This is the memory we mean.

So this is in-context memory: holding the current input within a single forward pass, so token 5,000 can use what token 3 said. New prompt, empty state, nothing saved. It is not retrieval/RAG, not continual learning, not “remembering you across sessions”; it is the job plain attention does with its KV cache, just compressed into a fixed matrix instead of a growing list.

Where the state comes from

Each token has a representation, and three fixed learned matrices turn it into a query, a key, and a value:

The key is a token’s address, what it is about; the value is the content stored there; the query is what the current token is asking for, matched against the keys to decide what to pull out. A token writes itself in as a key–value pair and later reads with a query. The vectors depend on the input, but the three projection matrices are fixed weights, shared across every position and sequence.

Ordinary attention computes each output as a softmax-weighted sum over the past:

The exponential is what forces the cache. The score exp(query · key) does not split into a part that depends only on the query times a part that depends only on the key, so the weight on each value is tied to that specific key, and the normalizer sums over every past key. There is no running summary you can keep instead: you have to store every key–value pair and revisit them for each new query. That is the KV cache: memory grows linearly with sequence length, and producing all outputs scales quadratically with it.

Linear attention drops the softmax and uses a score that factorizes, in the simplest case just the dot product of query and key. Once it factorizes, the sum rearranges:

All of history collapses into one matrix of fixed size (key-dimension by value-dimension), and the query reads it in a single multiply. Memory no longer grows with context and the per-token cost is constant. This fixed state is the object the rest of this post is about; it exists precisely because the softmax is gone.

That fixed size is the appeal and the problem at once. Packing an unbounded history into one matrix is cheap, but it means many facts share the same finite space. The next section shows what that does to a read.

Why a fixed-size memory interferes

We have the fixed-size state. Before writing into it, look at what reading it gives you. Reading is applying a query to the memory:

Each stored value is weighted by how aligned its key is with the query, the dot product of the two. That is content-addressed recall: values whose keys match what you asked for, weighted by the match.

To expose the problem, take the cleanest possible query, one that exactly equals a key you already stored. This is the case that should return its value perfectly, so any mess is the memory’s fault, not a mismatched query. Splitting off that term:

If the stored keys were orthonormal, every cross term would be zero and the read would be clean. They are not. Each nonzero overlap leaks a fraction of some other value into the answer. And here is the structural reason they cannot all be orthogonal: the state is a single matrix, so the key space has only as many dimensions as the key vector is wide, and a space of that dimension holds at most that many mutually orthogonal directions. Store more associations than that and some keys must share directions; even below the limit, random unit keys have small but nonzero overlaps that add up.

As the context carries more associations, the term you want stays about the same size while the leakage is a sum over everything else, so it grows. Signal-to-noise falls with context length: a long document forces many distinct facts to share one fixed box and they smear together. That is why this whole family struggles on long, many-needle retrieval, and why the improvements below all aim at that pressure point.

Why softmax doesn’t have this problem

The leakage is not caused by folding the sum into the state matrix. The summed form and the matrix form are the same number; folding only fixes the size and the cost, not the value. The leakage is already there in the raw dot-product score.

Softmax runs those same dot products through an exponential and normalizes. The exponential sharpens them: the matching key saturates near one and the mismatched keys are crushed toward zero, so the wrong values effectively drop out of the read even when the keys overlap. Same overlaps, clean answer.

But that is exactly the property that cannot be summarized. The exponential of a dot product does not split into a query part times a key part, so there is nothing to precompute: you are forced to keep every key and recompute the exponential against each one, which is the growing cache. So it is an either/or: a sharp score reads cleanly but cannot be folded into a fixed state, while a foldable score gives the fixed state but leaks. Interference is not the cost of compressing; it is the cost of using a score weak enough to be compressible.

Updating a value when a key comes back

As the model reads a sequence, a later token sometimes produces a key close to one an earlier token already wrote, but carrying a different value. The state already holds a binding in that direction, and the new value should take its place. This is the update case, and it is the one ordinary outer-product memory gets wrong.

For example, a passage sets x = 5 and later sets x = 7. Both tokens produce nearly the same key (the direction standing for “the value of x”), but with different values. When a later token reads x, the answer should be 7. Plain addition cannot give that: it never removed the old binding, so the slot holds 5 and 7 at once and the read returns a blend. The same shape shows up whenever a key recurs with a new value: an entity whose state changes (”Alice is in Paris… now Tokyo”), a correction (”blue… actually green”), a form field revised.

Two clarifications, since “update” can mislead. The prompt itself is fixed; the forward pass only reads it left to right, and “update” means a later position’s binding should win over an earlier one. “x = 5” stays in the text; it just should not win the read. And keys are not matched by name: two tokens are “the same key” when their key vectors point in roughly the same direction, so their writes land on the same spot in the state. A repeated mention produces a nearby key, the later write hits that slot, and the read afterward should reflect the new value.

So every write is one of two cases. Add: the key points somewhere new, a fresh fact, which is most tokens; plain accumulation is fine, and that is what vanilla linear attention does. Overwrite: the key lands on a direction already in the state, and the slot has to be updated to the new value, not stacked on top of the old one.

Why not just replace the whole matrix?

Because the state is shared by every association at once. Three ways to write an update to one key, into a memory that also holds a second fact:

• Replace the whole matrix with the new key–value outer product: fixes the target key perfectly and deletes everyone else. Read the second key afterward and you get near zero. You wanted to change one slot and you erased the notebook.

• Add the new outer product: keeps the second fact, but leaves the old binding in place, so reading the target key returns old-plus-new, the stale value smeared into the fresh one.

• Delta: read what the key currently points to, subtract just that, then write the new value. Only the target slot changes; the other fact is untouched.

Add keeps the other fact but smears the target. Replace fixes the target but wipes the other fact. Only the third (read, subtract, write) gets both right. That third option is the delta rule.

The delta rule

The update that does this is the delta rule (Widrow & Hoff, 1960), used for linear attention in DeltaNet (Yang et al., 2024). It writes the new value relative to what is already stored, not absolutely. First read what the memory currently returns for the key:

This is whatever sits in that key’s direction right now. We never have to know in advance whether the key was used before; we just read it back. Then move the slot from that old value toward the target, by a fraction β (the write strength):

The bracket is the gap between the new value and the old one, and adding it back pushes the value stored at that key toward the target. One update covers both cases with no branching: if the key points somewhere new, the read is about zero, the gap is just the new value, and it reduces to a plain add; if the key lands on a direction that already holds a value, the read returns that old value, and the update subtracts it and writes the new value in its place. The memory tells the rule which case it is in.

Multiplying the correction out shows what it does to the whole state:

The second term writes the new value along the key. The first term removes a β fraction of whatever the state held along that key, and only along that key: the projection onto the key direction leaves everything orthogonal to it untouched. That is exactly why, in the previous widget, replacing the whole matrix wiped the bystander but the delta update did not; it only edits that one key’s line of the state.

Why β is not just 1

A write strength of 1 is a hard overwrite: erase the old binding completely, write the new value. So why not use it everywhere? β is produced per token by the model, and two things argue against pinning it to 1. Real keys are not exactly orthogonal, so erasing hard along one key also disturbs neighbors that partly share its direction, and a smaller β makes a gentler edit with less collateral damage. And not every write should fully replace: sometimes the right move is to nudge a value, accumulate evidence, or write weakly under uncertainty. So β between 0 and 1 is a dial: 1 overwrites, 0 leaves the slot alone, in between is a partial move. (In the online-learning view it is a per-step learning rate, and a rate of 1 everywhere is rarely what you want.)

One caveat the next widget makes concrete: the clean overwrite is exact only when the key is orthogonal to the others. When keys overlap, editing along one drags on whatever shares its direction, the same interference from before, now showing up in the write.

Training it in parallel

Training needs every output over the whole sequence at once, then a gradient. Plain linear attention gives them cheaply because the state is a running sum, so the outputs collapse into two matrix multiplies (with a causal mask zeroing the future):

Why this is fast: it is all dense matmuls, and a GPU runs a matmul as thousands of multiply-adds in parallel on its tensor cores, every output position at the same time. Nothing waits for anything else.

The delta rule breaks this. Its erase factor (the one from the operator form above) makes each state genuinely depend on the previous one, so you cannot write the answer as one sum of independent terms. Done literally you process tokens one at a time, each a tiny rank-one update that uses a sliver of the GPU while the rest sits idle.

DeltaNet’s contribution (Yang et al., 2024) was to recover the matmul form by working in chunks. A chunk is a contiguous block of C tokens; a length-L sequence is split into L/C of them. The expensive work happens inside a chunk, all as matmuls, and only a small summary state is passed from one chunk to the next.

The trick: solve for the values that were actually written

Every step adds a rank-one term whose left factor is a key, so the state is always the start state plus one such term per token:

The written value here is not the raw value, but the correction from the delta rule (target minus old value, scaled by β). The keys are known; these written values are the unknowns. The point is that if we can get all of them in a chunk at once, with a single matrix solve instead of a token-by-token walk, the whole chunk becomes parallel matmuls. So we solve for them jointly.

The written value at each step depends on the current read, and that read expands into known keys and earlier written values:

In words: reading a key against the state-so-far is the start-state read, plus every earlier written value weighted by how much its key overlaps the current one. Substituting gives a relation among the written values alone:

Each written value depends only on earlier ones, which makes this a triangular system. Stack the written values into a matrix, collect the pairwise key overlaps into a matrix T, and the whole set of equations becomes a single solve:

Because the matrix being inverted is unit lower-triangular, the inverse is one forward substitution on a small C-by-C matrix. Everything else is dense matmuls: build the overlap matrix from pairwise key dot products, then form the carried state and the outputs:

The sequential token loop is gone, replaced by matmuls plus one small triangular solve. Writing a product of rank-one factors as a single low-rank update this way is a classical move from numerical linear algebra, the WY representation (Bischof & Van Loan, 1985) and its UT-transform variant (Joffrain et al., 2006); DeltaNet borrows it to collapse the chunk into matrix operations.

Why the chunk size is small

The chunk size sets how often the state is handed off: there are L/C chunks, so that many sequential state updates. The two extremes make this concrete. A chunk of one token is the original fully sequential recurrence. A single chunk covering the whole sequence is one handoff, done in one parallel block. (This is the opposite of what it might sound like: a bigger chunk means fewer, larger steps, not more.)

So why not use one giant chunk and be fully parallel? Because the chunk builds and solves a C-by-C matrix, so its cost and memory grow quadratically in the chunk size. At the full length you are back to the quadratic cost of full attention, and the matrix no longer fits in the fast on-chip memory the matmul engine reads from. Too small, and you pay too many sequential steps and underfill each matmul. The kernels use 64.

Adding decay: Gated DeltaNet

Everything up to here is DeltaNet: a fixed-size associative memory, edited by the delta rule, trained in parallel. The last three sections are refinements, each adding expressive power with a small change that leaves the chunk algorithm intact.

The delta rule overwrites one slot at a time but cannot let old context fade on its own. Gated DeltaNet (Yang, Kautz & Hatamizadeh, 2025, arXiv:2412.06464) multiplies the state by a scalar decay before each edit:

Tracking the cumulative product of the decays, an earlier write contributes to a later read scaled by how much decay has accumulated in between. In the chunk algorithm this is just a per-row reweighting of the same matrices plus an extra factor in the causal mask; the triangular solve is unchanged. Decay is close to free to add. What it cannot do is forget different features at different rates, since it is one number.

Decay per channel: KDA

KDA, the linear-attention layer in Kimi Linear (Kimi Team, 2025, arXiv:2510.26692), replaces that single decay with a per-channel decay vector, a different forget rate for every key channel:

Now every channel is scaled differently at every step, which looks like it should break the chunk form. It does not, because of a change of variables: factor the cumulative per-channel decay out of the state, and it cancels from the recurrence, leaving a plain delta product in reweighted key and erase factors:

After this substitution the chunk equations have the same shape as before; only the entries carry the decay factors. KDA buys richer forgetting at no structural cost.

The per-channel rates are not hand-set hyperparameters; they are learned and data-dependent, produced from each token by a small projection (the Gated DeltaNet parameterization, a softplus of a learned linear map passed through an exponential). A per-head term and a per-channel bias set each channel’s baseline forget rate, and the per-token projection pushes that rate up or down, so the model learns both the typical decay profile and how to modulate it on the fly. The active edit, though, is still a single write-strength scalar, which scales both the erase and the write at once.

Splitting the edit: Gated DeltaNet-2

Erasing acts on the key side: which coordinates of the old read to remove. Writing acts on the value side: which coordinates of the new value to keep. These are different axes of the state, so GDN-2 (Hatamizadeh, Choi & Kautz, 2026, arXiv:2605.22791) gives each its own channel-wise gate, an erase gate on the key and a write gate on the value:

Compared with KDA, the write direction is unchanged (the left factor is still the key), but the read it subtracts is now channel-selected by the erase gate, and the value it writes is channel-selected by the write gate.

Forward: same machine

Run the same change of variables, now folding the erase gate into the reweighted factor, and the recurrence is again a plain (now asymmetric) delta product. The chunk pipeline keeps the same shape: the same overlap matrix, the same triangular inverse, the same state and output equations. The only difference is what fills them: the erase gate enters the key-side rows, the write gate the value-side rows, and the overlap matrix is now built from an asymmetric pair rather than a symmetric one.

Backward: one real difference

Training propagates a loss gradient back through the chunk. Write the solve as the triangular inverse applied to the written values. Backprop needs the gradient with respect to that inverse, which accumulates as a product of the incoming gradient with the written values:

The whole question is whether the gate can be pulled out of that inner product. In KDA the written value is a scalar times the value, so it slides straight out, and you can compute the gate-free products once as a matmul and scale afterward:

In GDN-2 the written value is a per-channel product, so the gate sits inside the sum over channels and there is nothing to pull out:

No single number multiplies the whole inner product; the gate reweights each channel before it is summed, so no row or column scaling recovers it from the gate-free version. The erase side has the same issue. The gate therefore has to be folded into the matmul itself, not applied as a scaling after. The forward pass is essentially KDA’s; the backward kernel is the part that must be rewritten to carry both gates inside its accumulation, and that gate-aware backward is the real implementation cost of the split.

Setting both gates to the same scalar recovers KDA exactly; tying the decay to a scalar as well gives Gated DeltaNet; dropping the decay gives the delta rule. Each model is the next with some gate held to a scalar.

Where this nets out

Step back and it is all one idea, taken in stages. Linear attention compresses an unbounded history into a fixed matrix, fast but lossy. The delta rule edits that matrix surgically instead of piling onto it. The chunked triangular solve makes the edit trainable at scale. Decay, per-channel decay, and decoupled erase/write gates each give the edit finer control over what to keep and what to remove, without giving up the fixed-size state or the parallel training. None of them recover the softmax cache's perfect recall; they make the compression smarter.

That is also where the measured gains land. In the Gated DeltaNet-2 paper the improvement over KDA is modest on language modeling but clear on long-context, multi-key retrieval, the regime where many associations are forced to share one fixed state and interference is worst. The ablation is honest about the split: a channel-wise erase gate with a scalar write recovers most of the gain, so the erase side is doing more work than the write side.

This is also why pure linear attention rarely replaces softmax outright. Exact recall is often worth the cost of the growing cache, so most production models stay softmax, and these layers show up where memory and throughput dominate: long context, high-throughput serving, constrained hardware. The common deployment is hybrid: interleave a few full or sliding-window attention layers for exact recall with many cheap linear layers. Recent open-weight models make this concrete. Qwen3-Next and Kimi Linear both stack three linear blocks (a Gated DeltaNet variant) per full-attention block, a 3:1 ratio, and MiniMax-01 mixes lightning (linear) and softmax attention in a similar pattern.

Sources:

• DeltaNet chunkwise algorithm (Yang, Wang, Zhang, Shen, Kim, NeurIPS 2024)

• Gated DeltaNet (Yang, Kautz, Hatamizadeh, ICLR 2025, arXiv:2412.06464);

• KDA / Kimi Linear (Kimi Team, 2025, arXiv:2510.26692);

• Gated DeltaNet-2 (Hatamizadeh, Choi, Kautz, 2026, arXiv:2605.22791).

In this episode, we talk with Qichao, the founder and CEO of Molecular Universe, the AI-for-science platform that grew out of SES AI, a high-energy-density battery developer he’s run for fourteen years. His core distinction is that companies from the AI world build tools, such as foundation models that predict properties, while companies from the science world care about the final product, such as the new battery or material that actually ships. Molecular Universe sits firmly on the science side, and the difference shows up everywhere from what they publish to what they refuse to.

We get into the actual workflow of materials discovery and where AI compresses it. A single trial in a traditional lab can take a year with maybe a 40% success rate; the goal is to run a thousand candidates in parallel and turn that year into a week. Qichao walks through improving low-temperature fast-charging for EV batteries: from hypothesis generation through molecule-, material-, and device-level property prediction, down to autonomous labs that synthesize and test the top candidates without a human touching a pipette.

The hardest problem, it turns out, isn’t predicting molecular properties or measuring device performance, but it’s the black box connecting the two. In batteries, that’s the solid-electrolyte interface, which the field has been hand-waving about since the seventies. And the thing standing in the way of cracking it isn’t a clever training trick but data: companies sitting on twenty years of records are finding it too messy, incomplete, and poorly labeled to train on, and are having to start collecting from scratch with new protocols and robots.

Timeline

• 00:13 — Intro and welcome;

• 01:19 — Shovel vs. gold

• 05:18 — Why the world’s smartest scientist doesn’t automatically give you a better battery

• 07:25 — The discovery workflow

• 09:37 — Exploration vs. exploitation

• 11:54 — Safety and filtering: screening novel molecules against banned and toxic-substance lists

• 17:55 — How hypotheses get generated, and where frontier LLMs help

• 20:29 — From hypothesis to ~400 formulations: property prediction, ranking, and handing off to autonomous labs

• 26:37 — “A foundation model for everything” — and the black box between molecular properties and device performance

• 30:01 — World models and physics

• 33:09 — The great unknown in batteries

• 37:08 — Simulation vs. reality: calibrating massive simulated datasets with a sliver of experimental data

• 41:47 — Lab robotics: how fast the hardware has caught up, and what a floor of autonomous labs looks like

• 43:50 — The real bottlenecks

• 50:21 — Pre-training from scratch vs. post-training LLMs, and why training tricks haven’t reduced the need for good data

• 52:42 — Evaluation

• 55:42 — Publish the B+ model, keep the A model

• 58:05 — Five years out

• 1:00:37 — Closing thoughts and wrap

Music:

• “Kid Kodi” - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

We talk why the real bottleneck is power, not chips, and why that favors Nvidia and Google. Why MoE keeps winning even when dense models look better on paper and why he'd rather run fungible capacity at 95% than specialized chips at 60%. We also talk about quantization limits, where RL efficiency has to go next, and his case that AI is still under-hyped. We also get into cross-region training, sparse autoencoders and why interpretability hasn't taken off in open source, whether open models can close the gap, and a frank read on Anthropic's go-to-market.

Timeline

• 00:00 — Intro: the part of AI nobody talks about

• 01:20 — What "infrastructure for AI" actually means: the layers, from GPUs up to routing

• 02:59 — Why not just buy your own GPUs and do it yourself?

• 05:17 — The scale Fireworks runs at

• 06:35 — Hardware inflation, GPU costs, and the real risk hiding in commit duration

• 10:14 — Nvidia vs AMD vs TPUs, and why power is the bottleneck

• 11:57 — Mixing GPU types and generations; fungibility vs. specialization

• 14:22 — Once you have the GPUs, what's the next layer to build?

• 17:04 — Dense vs. MoE, and why the hardware picks the winner

• 21:07 — Quantization: is FP4 the floor? TurboQuant and INT vs. FP

• 24:28 — How tied are the algorithms to the hardware?

• 25:12 — DeepSeek, DeepGEMM, and next-token prediction as reconstruction loss

• 28:50 — Why RL is still wildly inefficient compared to pre-training

• 30:08 — Speculative decoding, AI-generated kernels, and auto-research

• 34:00 — The AGI question: why text gets automated but vision may stay expensive

• 37:07 — Hype check: why Benny thinks AI is still under-hyped

• 41:28 — Training vs. inference at the infrastructure level

• 44:12 — Scaling across data centers: cross-region training with Cursor

• 45:40 — Sparse autoencoders, interpretability, and why open source is human-constrained

• 49:04 — Will open models catch up — on quality and on compute?

• 51:41 — Are we plateauing? Opus 4.7 vs. 4.6 and the coming data wars

• 54:41 — Physical limits, HBM, and whether chips keep getting faster

• 58:17 — The belief about inference everyone gets wrong

• 59:31 — Anthropic, mythos, and a frank take on go-to-market

• 1:04:41 — Wrap-up

  ---

Music:

• "Kid Kodi" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

Oded Rechavi is a biologist at Tel Aviv University and the co-founder of QED, a company building AI to review scientific work. He's also spent years studying worms.

We start with what's wrong with peer review and grant funding: why it takes years to publish, why reviewers are often your own competitors, and why the whole thing is locked to an economic model that rewards publishing more papers, not better ones. Oded explains why he doesn't call QED "peer review" at all, and what it would take to actually validate science instead of just stamping it.

Then we get into the biology. C. elegans has exactly 959 cells, every one of them named, and a fully mapped brain. Oded's lab studies how a worm's experiences get passed to its offspring through RNA rather than DNA — meaning what happens to a worm in its lifetime can change its descendants. We also talk about using ancient DNA to reassemble the Dead Sea Scrolls, what AI can and can't do for biology, and why he wants to build an "Ironman suit" for researchers rather than replace them.

00:00 Intro

01:35 Why scientific publishing is broken

04:02 Years to publish, and what it costs science

07:20 Bad reviewers, conflicts of interest, and the money

10:47 Why preprints don't fix it

15:37 How AI conferences handle review

22:07 Conferences vs. journals — does slow review help?

25:22 Building QED: review, not peer review

30:02 Tracking a paper from idea to submission

33:11 What writing a grant actually involves

35:00 The ERC reviewer crisis

37:06 Tailoring feedback to your field

41:48 Switching to biology

44:30 Every cell has a name: inside C. elegans

46:28 Inheritance without DNA

48:16 What the worm "thinks" changes its offspring

51:58 Reassembling the Dead Sea Scrolls with ancient DNA

56:07 Psychedelics and worms

58:36 Can AI run the research itself?

1:04:49 Automation vs. validation

1:07:12 The origin of life

1:08:49 Why people reject AI-written work

1:16:18 Will humans still have a role?

1:17:39 Wrap-up

Music:

• "Kid Kodi" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

Will AI take our jobs? We put the question to Alex Imas, the new Director of AGI Economics at Google DeepMind and a professor at Chicago Booth, whose entire job now is studying how frontier AI reshapes the economy. His short answer: probably some of them, but the popular story is mostly wrong about which jobs and how fast.

Alex makes the case that a job is a bundle of tasks, not a single thing AI either does or doesn't do, and that the number of people who should actually care about is how much consumer demand responds to falling prices. Get that wrong and you predict mass layoffs. Get it right and you sometimes predict more hiring. We get into why the automation panic is two centuries old, why he thinks blue-collar work is in more danger than white-collar, and why the people already winning are the ones adopting AI fastest.

We also cover the AGI versus ASI distinction and why it changes everything for the economy, what happens when there's no moat and open models stay six to eight months behind, the three-tier pricing future he sees coming after the 2026 compute crunch, and what any of this means if you're deciding whether to send your kids to college.

• The episode was recorded before Alex joined Google

Timestamps

00:00 Meeting Alex Imas

00:44 Will AI take our jobs?

03:35 Is this an AI question or an economics question?

06:18 The economy is already behind the AI we have

07:43 Why AI adoption is K-shaped

12:51 Was Andrew Yang right?

13:45 The automation panic is 200 years old

16:46 Dario's six-month claim, and why we don't see it yet

17:22 A job is not a task

22:38 The three numbers that actually predict the labor market

22:42 The chess engine analogy and the centaur phase

25:45 Recursive self-improvement and the hamburger problem

30:06 Should AI labs be the ones answering alignment questions?

31:17 The "invisible hand wave" and why nobody wants fully autonomous AI

33:27 AGI vs ASI, and why the difference is everything

35:28 Commodities vs relational goods

41:14 Star Trek, replicators, and predicting with sci-fi

45:20 Inequality and the Upper West Side VCs

46:21 Your money manager was automated in the 1960s

50:47 Are OpenAI and Anthropic overvalued? The moat problem

54:29 What has to be true for the losses to make sense

55:43 Cognitive atrophy and monopoly fears

57:00 The 2026 compute crunch and the three-tier pricing future

1:01:52 The Apple vs Android analogy

1:03:54 A rich-country perspective

1:04:16 Protecting the skills that actually matter

1:07:02 Will not using AI become a status symbol?

1:08:53 Does capitalism even survive?

1:13:44 Redistribution becomes the political battleground

1:18:16 Blue collar vs white collar: who's really at risk

1:21:18 Advice for parents in an AI world

1:22:43 Saving for retirement when the Valley says don't

1:25:06 Will non-elite colleges survive?

Music:

• "Kid Kodi" -Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

  ---

About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

In this episode, we sit down with Wenhu Chen, research scientist at Meta MSL, assistant professor at the University of Waterloo, and the person behind MMLU-Pro and MMMU. If you've read a frontier model release in the last two years, you've seen his benchmarks. That makes him one of the best people to answer the question everyone dances around: when a model jumps from 40% to 90% on your benchmark, how much of that is real? In this episode, we dig into why benchmarks have become the loss function of the entire field - design a bad one, and thousands of brilliant researchers will spend months hill-climbing in the wrong direction. Wenhu is surprisingly candid about the limits of his own creations: contamination is everywhere, saturation turns frontier benchmarks into unit tests, and popular alternatives, such as LM Arena, mostly measure tone and length rather than capability. His answer is to evaluate models where they've never been: private codebases, hospital data, and the messy, live internet.

We also talk about ClawBench, his new benchmark that deploys agents to over 140 real production websites to do things people actually want done, such, such as ordering food, booking tickets, and applying for jobs. The best model in the world completes about a third of these tasks. We unpack why: bot detection, models that refuse to click "pay," agents that give up the moment an environment doesn't match their training, and harnesses that can swing results by 20% without changing the model at all.

Along the way, we cover the overlooked science of evaluating pre-training, data flywheels, and synthetic environments for agent training, and whether RL teaches models to reason or just surfaces what's already there. We close with Wenhu's predictions: exploration and adaptability will improve rapidly, but security will become the field's hardest problem as agents gain real permissions in the real world.

Timestamps

00:00 – Intro
00:55 – What good evaluation means, and how it's changed since the early GPT days
03:35 – Benchmarks as the field's loss function
05:50 – Contamination: the problem nobody fully solves
08:08 – MMLU-Pro scores: real progress or training on the test set?
11:05 – Can you measure creativity?
12:34 – Why human judges and arenas are unreliable — and what to use instead
19:22 – What a good benchmark actually looks like
22:34 – Chain of thought: signal or scratchpad?
26:01 – Auto-research and hill-climbing agents
28:52 – Harnesses: 20% swings without touching the model
32:28 – Safety, model release, and an "FDA for models"
36:53 – The overlooked science of pre-training evaluation
43:49 – Designing pre-training benchmarks when one run costs a billion dollars
49:45 – ClawBench: agents on 140+ live websites, and why the best model gets 33%
54:42 – How MMLU-Pro and MMMU-Pro were born from public complaints
59:16 – Pixel agents vs. APIs: will MCP kill computer use?
1:02:11 – Training agents: data flywheels and synthetic environments
1:05:43 – SFT vs. RL, and does RL teach reasoning or reveal it?
1:09:21 – What gets solved next year — and what doesn't
1:14:32 – Undervalued ideas, and what's next for ClawBench

Music:

• "Kid Kodi" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

  ---

  About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

In the second half of our conversation with Jürgen Schmidhuber, we focus on the key ideas he's pursued since the early 1990s and discuss why he believes these concepts are only now being rediscovered.

We start with JEPA. Jürgen argues that the method LeCun named in 2022 is the same family he published in 1992 as Predictability Maximization. From there he traces the adversarial lineage back further still, to his 1990 world-model paper and 1991 Predictability Minimization  -  the curiosity-driven minimax games he sees as the real origins of GANs.

We also talk about why these ideas took thirty years to land, why today's trillion-dollar data-center buildout is driven by AGI fear, and why he thinks Apple may come out ahead.

The back half turns to what he sees as the real frontier: physical AI. Today's systems are superhuman behind the screen but helpless at a leaky pipe, and until a robot can use human tools, there's no AGI. He discusses self-replicating, self-improving machines as "a new kind of life," reframes continual learning and test-time training as ideas from his 1991 fast-weight work, and detours through Solomonoff's universal prior, Hutter's AIXI, and the Gödel machine.

We close on the subject Jürgen is famous for: scientific credit. He makes his case for rigorous attribution, casts himself as a "speaker for the dead" championing forgotten pioneers like Ivakhnenko, and reflects candidly on whether the fights are personal.

Timeline

00:30 — What JEPA is, and the 1992 Predictability Maximization story

04:54 — Implementing PMAX: autoencoders, Siamese networks, Infomax

09:10 — Predictability Minimization, factorial codes, and the roots of GANs

16:00 — Why it took 30 years: the economics of compute

20:52 — Data, the web, and 1990 as the origin point

23:09 — Hardware inflation, the trillion-dollar buildout, and the coming crash

34:05 — Physical AI: the plumber problem and self-replicating machines

41:14 — Which 90s ideas are being scaled right now

45:26 — Continual learning and test-time training as "old hats"

55:19 — Measuring intelligence: Solomonoff, AIXI, and the Gödel machine

1:05:26 — Self-replication and von Neumann

1:09:51 — Will he see AGI in his lifetime?

1:10:42 — Credit, integrity, and being a "speaker for the dead"

Music:

• "Kid Kodi" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

• "Palms Down" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

• Changes: trimmed

• ---

About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

In this episode, we host Jürgen Schmidhuber - the man, the legend, one of the godfathers of modern AI. His lab worked out many ideas behind today’s systems (LSTM, world models, artificial curiosity, Transformer variants, and even GAN-style setups) decades before they became fashionable, and he’s just as well known for making sure people remember who did what first. This is the first of two conversations with him.

We go back to his lab in the early 90s and ask how one small group came up with so many of the ideas that are now being scaled to a thousand billion dollars, back when compute was ten million times more expensive. A lot of the episode comes down to one distinction he keeps making: prediction vs. decision-making. His take is that LLMs are very good prediction machines that imitate the web, but that’s only half the problem. To actually act in the world, you need a controller that uses a world model to plan. He talks about his 1990 work on world models and artificial curiosity, where the controller gets rewarded for running experiments that improve its own model (an adversarial setup years before GANs), why planning millisecond by millisecond doesn’t scale, and why you need sub-goals instead.

We also talk about compression as the core of understanding, from falling apples to Kepler to Einstein, and why we still don’t have a robot that can do what a plumber does, even though the AI behind the screen keeps getting better. Then the conversation moves to credit assignment: how “to Schmidhuber” became a verb, what he thinks is broken about the award system, and a long exchange on PMAX vs. JEPA. He ends on the real origins of deep learning and a prediction about self-replicating machines in space.

Timeline

00:00  Intro
00:55  1991 in Munich, and why that lab mattered
02:38  "I'm not very smart"  and why compute getting 10× cheaper every 5 years changed everything
04:25  Chess as an AI proxy
08:27  Artificial curiosity in the 90s vs. today's RL exploration
09:10  Why RL is harder than supervised learning
20:48  Coding agents vs. robots, and how a baby learns its own hands
26:20  Compression as understanding
33:40  What's actually missing on the road to AGI
37:30  Why millisecond-by-millisecond planning is stupid
47:44  Convergence to LLMs, GPUs, and how far we still are from the Bremermann limit
51:49  Unsupervised learning, factorial codes, and predictability minimization
58:12  Credit assignment: the fights with LeCun and the Nobel critique
1:02:13  On his last name becoming a verb
1:05:17  The award system's missing peer review
1:07:03  Closed labs and the decline of open research
1:13:23  Audience questions
1:34:02  Closing: who really invented deep learning?

Music:

• "Kid Kodi" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

• "Palms Down" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

• Changes: trimmed

  ---

About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.

In this episode, we sit with Max Welling, Professor of Machine Learning at the University of Amsterdam, co-founder and CTO of CuspAI, and a foundational figure behind variational autoencoders (VAEs), equivariant networks, and Bayesian deep learning. We talk about AI for science, the physics underneath generative models, and what's still missing on the road to real intelligence.

Max starts with what impresses him and what worries him about the LLM era, then makes the case that the next leaps will come from physical AI and from science itself. We dig into how machine learning actually works in the lab, world models and whether priors like geometry and symmetry should be built in or simply learned, and whether transformers will still rule a decade from now. At the end, we talk about CuspAI's climate mission, AI risk and regulation, Max’s new book, and where neuroscience might inspire the next wave of ML.

Timeline

• 00:00 — Intro

• 00:47 — Are we happy with the LLM era?

• 03:14 — Embodiment and physical AI

• 08:05 — Does "AGI" even matter as a term?

• 11:34 — Verifiers, RL, and why math/coding are tractable

• 13:17 — What actually shifted to make materials discovery work

• 14:42 — From molecules to biology and wet labs

• 16:26 — Working with real labs: timescales, friction, and the "Mira" agent

• 20:29 — Balancing simulators vs. experiments: the exploration–exploitation trade-off

• 23:44 — Active learning for experimental design

• 24:23 — Why active learning hasn't been central to LLMs

• 25:24 — A general loop for ML-for-science across domains

• 27:10 — Foundation models for chemistry: a "mother ship" plus a zoo of fine-tuned models

• 30:04 — Quantum mechanics, interpretation, and AI as a creative theorist

• 31:54 — World models and Yann LeCun's view; priors vs. learning

• 34:57 — Should world knowledge be explicit? (responding to Stefano Ermon)

• 36:41 — Vision: equivariance vs. transformers, and the role of optimization

• 40:32 — Best model for molecular properties in 10 years? Will transformers survive?

• 43:16 — CuspAI's climate focus and what motivated it

• 47:10 — One platform for every material class — what transfers and what doesn't

• 48:42 — Where does the risk of human extinction really come from?

• 51:06 — The "pause AI" debate and the arms-race reality

• 52:40 — Regulating powerful models: government vs. self-regulation

• 55:16 — Who should design AI regulation?

• 56:29 — The new book

• 1:00:31 — Compression, the information bottleneck, and renormalization

• 1:03:30 — The role of foundational principles in modern AI

• 1:04:06 — Waves in computing, the brain, and the next wave of innovation

• 1:07:11 — Neuroscience and ML: are we in a better position now?

• 1:09:17 — Conferences, the ICLR keynote, and finding the right people

  ---

  Music:

  • "Kid Kodi" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

  • "Palms Down" - Blue Dot Sessions - via Free Music Archive - CC BY-NC 4.0.

  • Changes: trimmed

  ---

  About: The Information Bottleneck is hosted by Ravid Shwartz-Ziv and Allen Roush, featuring in-depth conversations with leading AI researchers about the ideas shaping the future of machine learning.