Skip to main contentSkip to user menuSkip to navigation

Knowledge Distillation & Model Compression

Learn knowledge distillation end to end: soft targets, temperature, teacher-student losses, transfer data, evaluation, and deployment release gates.

50 min readAdvanced
Not Started
Loading...

What is Knowledge Distillation?

Knowledge distillation trains a student model to learn from a qualified teacher model. The student usually has a smaller or cheaper inference path. Instead of learning only from one-hot labels, it can also learn from the teacher's output distribution or internal representations.

In plain language, a label says "this example is a fox." A teacher can add "fox is most likely, dog is the closest alternative, and truck is very unlikely." That extra structure can guide the student, but it can also transfer the teacher's mistakes.

The core invariant is measurable: the deployed student must satisfy its own quality, slice, latency, memory, safety, and cost contract. Matching the teacher during training is evidence, not a production guarantee.

Follow the teacher-to-student path

The teacher helps create the training signal, but the student normally serves requests by itself. Distillation changes training; it does not automatically add teacher work to student inference.

  1. 1

    Baseline

    Qualify the teacher

    Freeze a version whose task quality, calibration, failure slices, and data lineage are understood.

  2. 2

    Inputs

    Build transfer examples

    Use representative, permitted inputs that cover the workload the student must handle.

  3. 3

    Signals

    Train the student

    Combine ground-truth loss with teacher outputs or compatible intermediate features.

  4. 4

    Evidence

    Release independently

    Benchmark the exported student on target hardware and block promotion when any required gate fails.

Review ML fundamentals, model training, and model evaluation first if logits, loss functions, holdout sets, or slice metrics are new.

Name the four moving parts

Knowledge source

Teacher

A trained model or ensemble that produces the behavior to transfer. It is kept in evaluation mode and is not updated by the student loss.

Deployment candidate

Student

A separately parameterized model that receives gradients. Its architecture can differ from the teacher as long as the selected transfer signals are compatible.

Teacher signal

Soft targets

A probability distribution made from teacher logits. It exposes relative preferences across classes instead of only the winning class.

Ground truth

Hard targets

Labels or task outcomes that anchor training to observed truth. They matter because a teacher can be uncertain, biased, stale, or wrong.

See what temperature and loss weight actually change

For response distillation, divide teacher and student logits by temperature T before applying softmax. Larger T spreads probability across more classes. The soft loss is commonly multiplied by so its gradient scale remains comparable as temperature changes.

A clear objective names the convention instead of relying on an ambiguous alpha:

total_loss = teacher_weight × soft_loss + (1 - teacher_weight) × label_loss

The right temperature and weight are empirical hyperparameters. They must be selected on validation evidence, not copied from a universal range.

Choose a transfer signal the architectures can support

Match outputs

Response distillation

Match teacher and student output distributions. This is the simplest fit when both models solve the same task and produce aligned output dimensions.

Match representations

Feature distillation

Match selected hidden representations. Different feature shapes need an explicit projection or pooling rule, and the chosen layer pairing needs validation.

Match structure

Relational distillation

Transfer relationships such as pairwise distances, attention maps, or similarity structure. This can preserve useful geometry without requiring component-wise feature equality.

No signal is automatically superior. Feature or attention matching can add memory, implementation, and architecture-coupling costs without improving the deployed student.

Implement one correct response-distillation step

The teacher runs in evaluation mode under torch.no_grad(). The student remains trainable. PyTorch's KLDivLoss contract expects the model input in log space, so the student branch uses log_softmax; reduction="batchmean" preserves the mathematical KL definition.

A model-agnostic PyTorch distillation step

The function returns the differentiable total loss plus detached metrics. The caller still owns mixed precision, gradient accumulation, optimizer stepping, checkpointing, distributed reduction, and evaluation.

Build a transfer set that represents deployment

Distillation cannot transfer behavior the teacher never produces on the transfer inputs. Treat the transfer set as a versioned dataset with the same rigor as ordinary training data.

  • Cover important classes, cohorts, languages, sequence lengths, devices, and difficult examples.
  • Keep validation and test examples out of training, teacher-output caches, and hyperparameter selection.
  • Record the teacher artifact, preprocessing version, label mapping, and output schema with every cached signal.
  • Recompute teacher outputs when the teacher or preprocessing contract changes.
  • Confirm that data licenses, privacy rules, and retention policies allow teacher inference and output storage.

For an online teacher, training spends teacher compute on every batch. For cached logits, training is cheaper and reproducible, but storage grows with examples and output width. Neither mode changes the need for an untouched evaluation set.

Select a student using measured deployment evidence

Parameter count and artifact size are useful inventory fields, but they do not determine end-to-end latency or peak memory. Kernel support, sequence shape, batching, preprocessing, data movement, and the target runtime all matter.

The next lab uses an illustrative benchmark snapshot, not a universal model ranking. Change the target profile and candidate to see which constraint becomes the release blocker.

Encode the release contract beside the training recipe

The release gate should compare the exact exported artifact against the approved baseline on identical inputs and target hardware. Aggregate quality alone is not enough when a required slice can regress.

Versioned distillation and release-gate configuration

Promotion should require all of the following:

  • Overall task quality meets the declared floor.
  • Every required slice meets its own floor or maximum regression budget.
  • Calibration, robustness, safety, and fairness checks match the product risk.
  • Target-runtime p50 and p95 latency, peak memory, throughput, and energy or cost are measured.
  • A bounded canary can roll back to the previous artifact.
  • Training lineage identifies the teacher, student initialization, transfer data, loss convention, and hyperparameters.

Diagnose failures before adding complexity

Copied error

Teacher-label disagreement

A high teacher weight can pull the student toward a wrong prediction. Inspect disagreement slices and preserve a ground-truth anchor.

Weak signal

Uninformative soft targets

Very sharp outputs resemble hard labels; very diffuse outputs can weaken class contrast. Sweep temperature and validate the resulting student.

Underfitting

Capacity gap

The student may be too small or structurally mismatched to represent the teacher's behavior. Increase capacity, improve the transfer set, or change the signal.

Wrong alignment

Feature mismatch

Hidden states can differ in shape and meaning. Add an explicit adapter and verify that the extra objective improves holdout behavior.

Hidden regression

Aggregate-only evaluation

A small average change can hide concentrated harm. Gate the worst required slices and important task families separately.

False speedup

Proxy deployment math

Smaller parameter counts do not prove latency, memory, or cost gains. Benchmark the compiled or exported artifact in its actual runtime.

Combine compression techniques deliberately

Distillation, quantization, and pruning change different parts of the system:

  • Distillation trains a separate student to reproduce selected behavior.
  • Quantization changes numeric representation and often depends on backend support and calibration.
  • Pruning removes weights or structures and only speeds inference when the runtime can exploit the resulting sparsity.

They can be combined, but each additional transform creates a new artifact that needs the same quality and target-hardware evaluation. Learn the numeric trade-offs in model quantization and the broader release discipline in model compression techniques.

Use primary references for the implementation contract

No quiz questions available
Could not load questions file
Spotted an issue or have a better explanation? This page is open source.Edit on GitHub·Suggest an improvement