What Is a Teacher Model in Knowledge Distillation?
A teacher model is the large language model that generates and validates the synthetic training data a smaller student model learns from. You never deploy it. It produces the training signal, the student absorbs it, and the teacher is discarded once training finishes.
What does the teacher model actually do?
The teacher does three jobs, none of which involve serving production traffic.
First, it is a feasibility test. Before any student training runs, the platform asks the teacher to solve your task on a held-out set. If the teacher cannot do it, no student will. This is the teacher evaluation step, and it is deliberately cheap relative to a full training run.
Second, it is a data generator. From a short task description and a handful of seed examples, the teacher writes thousands of new input-output pairs in your domain. Our platform benchmark used roughly 10,000 generated examples per task before filtering.
Third, it is a quality benchmark. The teacher’s accuracy on your test set is the first honest estimate of what the student can reach. Docs are blunt about this: “the accuracy of the teacher LLM provides the first approximation of the performance you can expect from your trained SLM.”
The mechanism differs from the original formulation of knowledge distillation in Hinton et al. (2015), where the student matched the teacher’s softened output probabilities directly. Text-level distillation from an LLM teacher instead transfers behaviour through generated examples — what the survey on knowledge distillation of LLMs calls black-box distillation. No weight access, no logits, no shared tokenizer required.
Which models can act as a teacher?
Only models in the platform’s supported models catalog. Teachers are large frontier-class open-weight models, and they come from families that never appear in the student list.
| Teacher family | Catalog values | Notes |
|---|---|---|
| GPT OSS | openai.gpt-oss-120b, openai.gpt-oss-20b, plus Thinking variants |
Documented base default; 120B Thinking runs medium reasoning effort |
| DeepSeek | deepseek.r1, deepseek.v3.1, deepseek.v3.2 |
Only V3.2 supports tool calling |
| Qwen3 | Qwen3-235B-A22B-Instruct-2507, Qwen3-480B-A35B-Coder, Qwen2.5-VL-72B-Instruct |
The 235B is the tool-calling-capable one |
| Other | zai.glm-5, moonshotai.kimi-k2-thinking, moonshotai.kimi-k2.5, minimax.minimax-m2-thinking |
All support tool calling |
The documented default for base.teacher_model_name is openai.gpt-oss-120b, described in the docs as “a strong choice for all task types.”
It is not the only default in the config, though, and it is not what recent work reaches for. The second teacher slot, trace_processing.teacher_model_name, defaults to zai.glm-5, and GLM-5 is the teacher in our trace benchmarking study, the Claude skill walkthrough and the deferral work. DeepSeek V3.1 was the teacher for the pytest generator. The large MoE teachers in the table — GLM-5, both Kimi K2 variants, MiniMax M2 Thinking, DeepSeek V3.2 and Qwen3-480B — are ordinary choices, not exotic ones.
One constraint applies across most of them. Reasoning teachers — the GPT OSS, DeepSeek, GLM, Kimi and MiniMax families — require synthgen.teacher_temperature between 0.5 and 0.7, even though the parameter’s own range in the config reference is 0.0 to 1.0. A value outside 0.5–0.7 with one of those teachers raises a validation error.
Does a bigger teacher always mean a better student?
No. What matters is whether the teacher is accurate on your task, not how many parameters it has.
We measured five teachers on the same held-out multi-turn tool-calling set in our traces-vs-synthetic benchmark:
| Teacher | LLM-as-a-judge | Std |
|---|---|---|
| GLM-5 | 0.835 | 0.006 |
| Qwen3-235B | 0.768 | 0.018 |
| GPT-OSS-120B | 0.765 | 0.020 |
| MiniMax-M2 | 0.762 | 0.010 |
| DeepSeek-3.2 | 0.744 | 0.014 |
A nine-point spread on one task, and the ordering does not follow the catalog. That is the argument for testing rather than assuming.
Nor is the teacher’s score a ceiling. In the dlt trace-distillation case study a 120B teacher scored 50.0% tool call equivalence on a smart-home routing task while the 0.6B student trained from it reached 79.49%. The teacher was still useful — it produced good synthetic coverage of the domain — but it was not the limit.
The practical rule is to run teacher evaluation on two or three candidates and pick on measured accuracy. That is covered in how to choose a teacher model.
How is a teacher different from a student model?
The teacher writes the curriculum; the student model is the thing you ship.
| Teacher | Student | |
|---|---|---|
| Role | Generates and validates training data | Learns the task, serves traffic |
| Size | Tens to hundreds of billions of parameters | 135M to 9B |
| Lifetime | Used during training only | Deployed and maintained |
| Chosen for | Accuracy on your task | Latency, cost, hardware fit |
Both are configured in the same place, in the base block of your config, as teacher_model_name and student_model_name. The pairing between them is the core of teacher-student distillation, and the fact that they come from different model families is not an accident — see does the student need the same architecture as the teacher.
Related terms
- Synthetic data generation — the teacher’s main output during training.
- Teacher evaluation — the feasibility and benchmarking step that runs before training.
- Black-box distillation — transferring behaviour through generated text rather than weights.
- Student model — the small model that learns from the teacher and gets deployed.