Picking a Teacher Model

The teacher you choose sets the ceiling on the whole distillation run. A student can only imitate behavior the teacher actually demonstrates — so when we pick a teacher for an ADI model, we pick for purpose, not for raw parameter count. A bigger teacher is not automatically a better one.

In practice that splits cleanly: every general-knowledge student in the fleet learns from glm-5.2, and every coding student learns from kimi-k2.7-code. The rest of this article is the framework we use to land on that mapping — and to avoid the trap of a teacher whose strengths a 4B student can't elicit.

#Match the teacher to the purpose

Step one is the only one that's non-negotiable: a generalist teacher for a generalist student, a coding specialist for a coding student. We don't ask a code model to teach trivia or a generalist to teach idiomatic Rust. The fleet's split makes this concrete:

#The five selection criteria

#1 · Purpose match

Covered above, but it bears repeating because it dominates every other factor. If the purpose is wrong, nothing downstream rescues the run.

#2 · Answer cleanliness

If the teacher is a thinking/reasoning model, run it with thinking disabled so the student copies clean final answers. A small student physically cannot reproduce a long chain-of-thought — train it on reasoning traces and you teach it to ramble, not to answer.

#3 · Cost and license

Our teachers run through Ollama Cloud (glm-5.2:cloud, kimi-k2.7-code:cloud), and every generated token burns against cloud limits. So we budget tokens before committing: a recent general run produced 2,068 pairs from ~1.36M teacher tokens. Knowing that ratio up front keeps a dataset build from quietly draining the month's allowance.

#4 · Format compatibility

The teacher's output has to fit the student's chat template. If the teacher emits a structure the student's template can't represent cleanly, you spend the run fighting reformatting bugs instead of learning behavior.

#5 · Determinism

For code teachers we pull the temperature low (~0.3) so solutions come out tight and reproducible. We want the same prompt to yield a clean, canonical solution — not a different stylistic gamble each time.

payload = {
    "model": "kimi-k2.7-code:cloud",
    "messages": [{"role": "user", "content": prompt}],
    "think": False,                 # clean final answers, no chain-of-thought
    "stream": False,
    "options": {"temperature": 0.3} # low temp → tight, reproducible code,
}

#Sanity-check before you commit GPU time

Don't take the teacher on faith. We generate a few thousand pairs, hold some out, and read them before committing a single training step. If the teacher's style isn't visibly worth copying on the held-out sample, the fix is a different teacher — not more epochs.