Everyone is arguing whether Kimi K3 distilled Anthropic. This whole conversation involves a horrible abuse of the term “distillation” which has come to mean almost anything the speaker wants it to mean.

I’m an AI researcher who’s ex-OpenAI, I was a co-author on the original RLHF paper that led to ChatGPT. I know what I’m talking about. So here’s how to actually understand the distillation debate, because it’s way more complicated than the government is trying to make it seem.

What do people mean by distillation?

There actually are multiple techniques here that often get mixed up for each other. But here are the three types of distillation, in order of how powerful they are.

1: Logit Distillation

This is what was originally meant by distillation. Most people (not Schmidhuber) would consider the original distillation paper as Hinton et al. There they show that models can be trained much more efficiently given a teacher’s raw outputs (“logits” - basically probabilities of each next token), which started the trend of using the technique to more efficiently train mostly smaller models given large teachers.

When people say that all the labs distill models, this is what they mean. Anthropic for example likely distilled Opus from training on Mythos logits, trying to get Opus’ logits to match Mythos’ logits as closely as possible.

But when talking about cross-lab distillation, no one refers to logit distillation. This is because logits aren’t returned via frontier APIs anymore (they used to be!), although it would be possible to do logit distillation on an open weight model. Obviously, if we’re accusing the Chinese of doing distillation, it’s not classic distillation, because they don’t have access to logits.

2: Behavior Cloning

Instead of learning the raw logits, one can instead learn to replicate output tokens from a teacher. It’s not as informative as distilling from logits, but is similar in expectation and most importantly, you can do it from the outputs of an API.

Supervised Fine-tuning (SFT), the first phase of most post-training algorithms, is equivalent to this, and it’s also commonly referred to as Imitation Learning.

When referring to cross-lab distillation, people almost always refer to behavior cloning, but importantly, this is not possible with today’s frontier reasoning models because reasoning models don’t return their full outputs! They show abridged reasoning traces which are just summaries, specifically to make behavior cloning less effective. The thinking goes, if you can’t see the actual steps the model took to reason and instead just see some “chicken scratch” and the final answer, you won’t be able to re-derive that yourself.

Distillation had been a big issue long before today, and the big labs have known this for a while, which is why when reasoning models were created, they chose not to share the reasoning traces with users and instead showed a summary. This allows for the model to do hidden work before outputting a final response, and this was supposed to prevent distillation - hence all the discussion about how distillation may not be possible (including from myself).

3: Behavior Parroting

Instead, I want to talk about what I call “behavior parroting” - mimicking the outputs of privileged work - and whether or not this can be used to train frontier models.

Note: past work (Chen et al.) has called the no-chain-of-thought version of this “Only Answer” training, though it was mostly negative results on small models.

Can Behavior Parroting work?

The case against behavior parroting: Hallucination

Intuitively, it doesn’t look like it should work. If you make a smart model do a lot of work in secret, then copy its outputs, the student doesn’t learn to mimic that work, it just learns to make plausible looking outputs. Hence, hallucination.

Case for behavior parroting #1: Style Transfer

Point 1.1: most of instruction following is style

This was a very bitter pill to swallow when first teaching models to follow instructions, but it’s unfortunately the simplest best explanation for a lot of the phenomena we’ve observed. One of the most surprising results here was in Hewitt et al. where training on only outputs without instructions closed most of the gap with fully trained RLHFed models. (Sounds familiar?)

Point 1.2: most of reasoning is style too

There is fairly strong evidence that this applies to reasoning models as well.

Reasoning models work almost as well when trained on reasoning traces that lead to incorrect answers. [source1] [source2]

Point 1.3: there seems to be transfer between reasoning and response

This one is more of a guess, but the final assumption to pull our argument together is that there is some style transfer between the reasoning and the final response (the text returned from an API). I don’t know of any papers on this, but some points in favor are that model providers have found a need to separate non-reasoning and reasoning models because they interface with each other.

The Hewitt et al. paper seems to also imply that a large amount of post-training is simple token-level output bias, which would facilitate that transfer.

Case for behavior parroting #2: Pre-training works

Fun fact: You can interpret large scale pre-training as behavior parroting on the Internet! Most would likely consider this Behavior Cloning, but when writing the internet, humans do all sorts of intermediate steps + have additional information not present in the tokens.

It’s hard to argue against the unreasonable effectiveness of pre-training!

Summary

• When talking about distillation in the future, we, as an industry, should be more clear about what type we’re talking about.

  • behavior parroting - learning to imitate token outputs after reasoning, but without reasoning traces (because they’re hidden)

  • behavior cloning - learning to imitate tokens

  • logit distillation - learning to imitate probabilities

• Overall, there is a pretty compelling case that distillation can occur from commercial APIs, but it is an approximation (behavior parroting) of an approximation (behavior cloning) of (logit) distillation.

• This is obviously an important problem, and I’d love to see scaling laws on behavior parroting of reasoning models!

Big thanks to Ke Deng, Sasha Sheng, Erik Gafni, and Haseeb Qureshi for helping me write/review this post.

Scaling laws were one of OpenAI’s most important results, both technically and philosophically (so much so that being scaling-pilled became a thing). They allow us to predict results for ever larger language model runs, and also allow for debugging models as we use exponentially more resources. All of this led to the era of LLMs we’re in today, but the craziest part was… the original Kaplan et al scaling laws were wrong.

Recently, Lilian Weng posted another awesome (and highly recommended) blog post on scaling laws. I was extra excited about the section “Reconciling Kaplan and Chinchilla”, the former being OpenAI’s original scaling laws and the latter being DeepMind’s follow-up with completely different scaling laws.

Figure 1 from Chinchilla. The black dotted line shows the original scaling laws, and the cyan star shows that significantly smaller models should be used.

Lilian’s article goes into the mainstream explanation of the difference between them from follow-up research (namely that it’s about how they counted the total number of parameters). That follow-up research unfortunately is inaccurate, though not due to any fault of the authors.

The reality of the difference between the original scaling laws and Chinchilla’s is that the former had a bug!

The bug: 3 ingredients

Non-researcher summary

• The 2 scaling laws (original and Chinchilla) give different “scaling recipes” for how to efficiently train large language models

• The former was incorrect because they:

  • Did not train on enough data (Step 1)

  • Gradually decreased the impact of data to make it look like more data wasn’t needed (Step 2)

  • Claimed that the gradual decrease was unimportant (Step 3)

• Thus, for a few years, people trained models that were much too large on too little data

Clue: Data scales with size.

It’s easier to identify this when working backwards: both scaling laws predict that data should scale with model size. The handwavy explanation is that bigger models have more capacity to soak up that data. Thus the amount of data is a very important parameter.

Step 1: Use a fixed amount of data.

The Chinchilla paper points out the root issue stating the original Kaplan et al paper authors “use a fixed number of training tokens and learning rate schedule for all models”. When every model is trained on the same fixed amount of data, the tiny model trained on ~130B tokens is getting way more training relative to its size than a giant model trained on the same ~130B tokens.

Relevant quote from Chinchilla’s related work section.

Figure 2 from Kaplan et al. showing all model sizes trained to the same ~130B tokens.

Figure 2 from Chinchilla with a pink arrow added to show roughly where the training curve would have been cut off if only trained to 130B tokens. It would have been obvious that training ended before reaching the scaling laws’ pareto frontier.

Keeping the amount of data fixed would be sufficient to get incorrect scaling laws, but if that was the only mistake, the results would look obviously incorrect. Except if you also…

Step 2: Use a cosine decayed learning rate schedule to zero.

This learning rate schedule caused learning to slow as training approached the target number of tokens. Performance naturally plateaued, appearing as if training is saturated. We now know that large models would have kept improving with more data and a different learning rate schedule, but the learning rate schedule artificially constrained results, making it appear that more data would not help.

Visualization of a cosine learning rate decay with a warmup (source) - you can see a smooth decay to lr=0, where learning stops entirely

The fixed amount of data and the learning rate schedule lead to both incorrect and hard to debug scaling laws, and it becomes even harder to debug if you…

Step 3: Claim that results were “largely independent of learning rate schedule”.

Given a maximum number of tokens, their conclusion is entirely accurate, but doesn’t apply to the true infinite data limit that scaling laws aim to model.

Aside: I too worked on LLM optimization at OpenAI at the time and missed the bug as well. 😅 The learning rate schedule seemed so obviously an important hyperparameter that it looked intentionally set.

Section 2.2 of Kaplan et al., describing how it was trained. Green box shows calculation for a constant number of tokens with model size. Red box shows the learning rate schedule.

Result: Models were undertrained and too large.

You can see how the difference of learning rate shows up: Chinchilla ended up with a model less than half the size of GPT-3, trained on over 4x more tokens. They could not have achieved this result if the learning rate decayed to 0 at just 300B tokens. 🙃

Table 1 from Chinchilla: showing how GPT-3 was both undertrained and oversized.

Conclusion

Eventually, the bug was discovered but not explicitly acknowledged (that I know of). By now, every big AI lab has long known this.

For future non-big-lab researchers: don’t waste your time on this question. Chinchilla’s scaling laws are the correct ones.

For whoever can amend the original scaling laws paper, it would be great to add a note that there was a bug.

Big thanks to Ke Deng, Sasha Sheng, Erik Gafni, David Dohan, and Sander Dieleman for helping me write/review this post.