When DeepSeek-R1 dropped in January 2025, the AI community spent about 48 hours celebrating the open weights before the accusations started. OpenAI claimed DeepSeek had used outputs from ChatGPT to train their models. Anthropic stayed quieter about it publicly, but the implication was the same: distillation from frontier models without permission. The whole episode raised a question that I think most practitioners have been avoiding: where exactly is the line between learning from a model and stealing from it?
I've been thinking about this more than usual lately because I recently co-authored a paper on reasoning distillation for automated program repair during my research at Purdue. So I have some opinions.
What distillation actually is
The core idea is simple. You have a large, expensive model (the teacher) and a small, cheap model (the student). You fine-tune the student to mimic the teacher's behavior, not just its final answers but ideally its intermediate reasoning and probability distributions. The student ends up performing surprisingly close to the teacher on the target task, at a fraction of the inference cost.
The classic formulation from Hinton et al. (2015) uses a modified loss function:
loss = alpha * KL_divergence(
softmax(teacher_logits / T),
softmax(student_logits / T)
) + (1 - alpha) * cross_entropy(student_logits, hard_labels)
The temperature parameter T softens the probability distributions so the student can learn from the teacher's "dark knowledge," the relative probabilities assigned to incorrect classes. At T=1 you get the standard softmax. At higher temperatures the distribution flattens out and reveals more information about how the teacher ranks alternatives.
This works. It works really well. And it's been standard practice in ML for a decade.
The DeepSeek situation
Here's what made the DeepSeek case interesting. They weren't just distilling from an open-source model they had access to. The allegation is that they systematically queried commercial APIs (Claude, GPT-4) and used those responses as training data. OpenAI's terms of service explicitly prohibit using outputs to train competing models. Microsoft reportedly found instances where DeepSeek's outputs contained phrasing patterns characteristic of GPT-4.
DeepSeek's R1 paper itself describes distilling from their own R1 model into smaller variants (1.5B, 7B, 8B, 14B, 32B, 70B). That part is simple enough, they own R1. But the question is whether R1 itself was bootstrapped using data generated by proprietary models during earlier training stages. The paper is vague on the full data pipeline. Section 4 discusses their distillation methodology for the smaller models, but the pretraining data composition for the base model gets much less detail.
The uncomfortable truth is that the technical boundary between "I used GPT-4 to generate synthetic training data" and "I used GPT-4 as a research tool to help me understand what good outputs look like" is fuzzy. Almost every ML team I know has used ChatGPT or Claude outputs in some capacity during development. The question is scale and intent.
The ethics, honestly
I think there are three distinct positions here, and I find myself somewhere between the second and third.
Position 1: All outputs are fair game. Once a model generates text, it's just text. You can't own the output of a statistical process. This is the most permissive view and it's wrong, at least legally. ToS agreements exist and they matter.
Position 2: The spirit matters more than the letter. Using API outputs to build a direct competitor is clearly a violation. Using them to evaluate your own model, generate test cases, or augment a small dataset for a research project is a gray area that probably shouldn't be prosecuted. Most people live here.
Position 3: Build your own data pipeline. If you want to compete at the frontier, generate your own synthetic data from models you own or have explicit licenses for. Use reinforcement learning from human feedback with your own annotators. This is expensive, but it's the only position that's completely defensible.
The practical reality is that enforcement is nearly impossible. You can't fingerprint model outputs reliably enough to prove distillation in court. OpenAI knows this. Anthropic knows this. The ToS exists more as a deterrent and a basis for breach-of-contract claims than as a technical protection.
How distillation actually works in practice
Let me get concrete. In our paper, "Reasoning Distillation for Lightweight Automated Program Repair" (arXiv:2601.09087), Aanand Balasubramanian and I investigated whether you could make small program repair models significantly better by distilling structured reasoning from a larger model, not just the final predictions.
The setup: we used a large teacher model to generate symbolic reasoning tags alongside fix-type labels for buggy programs from the IntroClass benchmark. These weren't just "the answer is X" labels. The teacher produced structured annotations explaining the reasoning chain, things like identifying the bug category, mapping it to a repair strategy, and justifying the fix type. We then trained a CodeT5-based student model on these enriched labels.
The key insight was that reasoning supervision matters more than you'd expect. The student model didn't just learn to classify fix types better. It learned something about the structure of the reasoning process itself, which transferred to examples outside the training distribution.
Here's a simplified version of what the distillation pipeline looks like:
# 1. Generate teacher annotations
for buggy_program in dataset:
teacher_output = teacher_model.generate(
prompt=f"Analyze this buggy program. Provide symbolic reasoning "
f"tags and fix-type classification.\n{buggy_program}"
)
# teacher_output contains structured reasoning + label
annotated_data.append({
"input": buggy_program,
"reasoning_tags": parse_reasoning(teacher_output),
"fix_label": parse_label(teacher_output)
})
# 2. Train student with reasoning-augmented loss
for batch in dataloader:
student_out = student_model(batch["input"])
# Standard task loss
task_loss = cross_entropy(student_out.logits, batch["fix_label"])
# Reasoning alignment loss
reasoning_loss = compute_tag_alignment(
student_out.hidden_states,
batch["reasoning_tags"]
)
loss = task_loss + lambda_r * reasoning_loss
loss.backward()
The reasoning alignment loss is what makes this different from vanilla distillation. You're not just matching output distributions. You're encouraging the student's internal representations to align with the teacher's reasoning structure.
If you want to do this yourself
A few practical notes from having actually built these pipelines.
Start with task-specific distillation, not general-purpose. Distilling a model that's great at everything into a small model that's okay at everything is much harder than distilling a model that's great at one thing into a small model that's also great at that one thing. Pick your task. Curate your dataset for that task. Distill for that task.
Temperature matters more than you think. I've seen teams spend weeks tuning architectures when the real bottleneck was using T=1 instead of T=3 or T=5. Sweep it. The optimal temperature varies by task and by how different the teacher and student capacities are.
Synthetic data quality > quantity. 10,000 carefully generated teacher examples will outperform 100,000 sloppy ones. Filter aggressively. If you're using an LLM as the teacher, validate its outputs against ground truth where possible. In our APR work, we discarded teacher annotations that were internally inconsistent.
Watch for mode collapse. Small student models trained on distillation data can collapse to a narrow set of outputs, especially if the teacher has strong preferences. Mix in some fraction of original training data or use regularization.
# Simple but effective: mix distillation and original data
if random.random() < mix_ratio:
loss = distillation_loss(student_out, teacher_out, T=temperature)
else:
loss = cross_entropy(student_out, original_labels)
Consider the legal implications before you ship. If your teacher model is behind a commercial API, read the terms of service. If you're distilling from an open-weights model like Llama or Mistral, read the license. Some licenses explicitly permit distillation, others don't. "It's open source" doesn't mean "you can do whatever you want."
Where this is going
Distillation is becoming the default deployment strategy for LLMs in production. Train or fine-tune a large model, distill it down to something you can serve cheaply, ship the small model. OpenAI does this internally. Google does this. Every startup serving LLM-based features at scale does this or will soon.
The DeepSeek controversy won't be the last. As models get better and API access gets cheaper, the temptation to distill from competitors will only grow. I expect we'll see a combination of technical watermarking (probably ineffective), contractual enforcement (probably selective), and industry norms (probably the most important in practice) emerge to handle this.
The thing I keep coming back to is that distillation itself is not the problem. It's a powerful, well-understood technique that makes AI more accessible by making good models smaller and cheaper (I wrote more about the nuts and bolts of that in my quantization post). The problem is when the teacher didn't consent to being a teacher. That distinction, between the technique and its application, is what the field needs to get better at articulating.