Knowledge Distillation: Kleine LLMs für den Produktivbetrieb
Wann sich Knowledge Distillation für LLMs lohnt, welche Trainingswege es gibt und wie sich Nutzungsrechte und Qualität vor dem Produktivstart prüfen lassen.
Veröffentlicht am

Knowledge Distillation lohnt sich, wenn ein kleines Spezialmodell eine wiederkehrende Aufgabe übernehmen kann. Das Frontier-Modell bleibt für die Fälle zuständig, die es nicht bewältigt. Inzwischen ist die Verfügbarkeit des Trainings ebenso wichtig wie die Modellwahl: Berechtigte Bestandskunden des Fine-Tuning-Angebots von OpenAI können ab dem 6. Januar 2027 keine neuen Trainingsjobs mehr starten – sofern ihr Basismodell nicht schon vorher abgeschaltet wird. OpenAIs Zeitplan zur Verfügbarkeit
Am besten eignet sich eine Funktion auf Basis eines großen Sprachmodells (LLM), deren Ein- und Ausgaben klar festgelegt sind: eine Anfrage klassifizieren, bestimmte Felder extrahieren, einen Verarbeitungsweg wählen oder ein exakt vorgegebenes Format liefern. Zunächst sollte ein kleineres Modell ohne zusätzliches Training getestet werden. Destillation wird dann sinnvoll, wenn das große Modell wichtige Fälle löst, an denen die kleine Ausgangsversion scheitert, und sich daraus verlässliche Trainingsbeispiele gewinnen lassen.
Anbieterdokumentation und Bedingungen für das Training mit Modellausgaben geprüft am 26. Oktober 2026. Die folgenden Unterscheidungen beziehen sich auf APIs für den Produktivbetrieb und die jeweils genannten Modelllizenzen. Für ein Chatbot-Abonnement für Endverbraucher oder einen anderen Hosting-Vertrag können andere Regeln gelten.
Wie funktioniert Knowledge Distillation?
Ein großes Teacher-Modell erzeugt Labels oder Beispielantworten. Ein kleineres Student-Modell lernt anhand dieser Beispiele, die Aufgabe zu erledigen. Nach dem Training kann das Student-Modell Routineanfragen beantworten, ohne bei jedem Aufruf den Teacher zu benötigen. Beim überwachten Fine-Tuning wird ein bestehendes Modell mit Beispieleingaben und den gewünschten Ausgaben trainiert. Ein verwalteter Destillationsprozess kann diese Ausgaben vom Teacher erzeugen lassen. Dokumentierter Destillationsablauf
Das Prinzip ähnelt einem Kletterlehrer, der eine kurze Route vermittelt. Der Schüler übt die dafür nötigen Bewegungen; er übernimmt damit nicht die Fähigkeit des Lehrers, jeden Berg zu besteigen. Für ein Student-Modell im Produktivbetrieb gilt dieselbe Grenze: Wer einen Klassifikator für Erstattungsanfragen trainiert, erhält keinen universellen Ersatz für den Teacher.
Ein Beispiel ist eine Supportfunktion, die Nachrichten den Kategorien billing, technical, cancellation oder needs_review zuordnet. Der Teacher liest repräsentative Nachrichten und schlägt Labels vor. Unklare Fälle werden von einem Menschen geprüft und entschieden. Das Student-Modell trainiert mit den freigegebenen Nachrichten-Label-Paaren. Anschließend muss es neue Nachrichten bearbeiten, deren korrekte Zuordnung unabhängig geprüft wurde.
Dieser letzte Schritt ist entscheidend, denn Übereinstimmung mit dem Teacher bedeutet nicht automatisch Richtigkeit. Wenn der Teacher Kündigungsanfragen regelmäßig als Rechnungsfragen missversteht, übernimmt ein Modell, das ihn exakt nachahmt, auch diesen Fehler.

LLM Distillation anhand von Modellausgaben
Für die Anwendungsentwicklung ist die Destillation anhand von Ausgaben meist der praktische Einstieg: Eingaben und akzeptable Teacher-Antworten speichern, dann das Student-Modell mit diesen Paaren trainieren. Für diesen dokumentierten Ablauf ist kein Zugriff auf die Gewichte des Teacher-Modells nötig, also auf die gelernten numerischen Parameter im Modell. Erforderlich sind aber das Recht, die Ausgaben weiterzuverwenden, und ein Trainingsverfahren für das Student-Modell, das die Aufgabe unterstützt. OpenAIs Anleitung zum überwachten Fine-Tuning
Destillation geht über das Nachbilden von Text hinaus. Die grundlegende Forschungsarbeit beschreibt auch, wie sich Wissen aus einem Ensemble, also einer Gruppe von Modellen, in ein einzelnes, leichter bereitzustellendes Modell übertragen lässt. Bei einer eng umrissenen Produktivfunktion zählt jedoch, ob das Student-Modell die benötigten Entscheidungen lernt – nicht, ob es den Teacher in jeder Hinsicht nachbildet. Distilling the Knowledge in a Neural Network
Diese Verfahren lassen sich kombinieren. Eine LLM-Quantisierung kann nach dem Training erfolgen, gefolgt von einer erneuten Evaluation. RAG oder Fine-Tuning erklärt, warum ein gelerntes Antwortmuster den Abruf veränderlicher Unternehmensinformationen nicht ersetzt.
Wann lohnt sich Modelldestillation – und wann nicht?
Destillation ist besonders interessant, wenn die Aufgabe eng umrissen bleibt, sich die Anfragen wiederholen und der Einsatz des Student-Modells einen messbaren Engpass verringert. Bei hohem Anfragevolumen verteilen sich Trainings- und Prüfaufwand auf mehr Anfragen. Auch eine Latenzvorgabe kann den Aufwand rechtfertigen, selbst wenn die Kosten nicht im Vordergrund stehen.
Ein Dienst zur Dokumentenverarbeitung kommt etwa infrage, wenn er immer wieder dieselben Felder aus vertrauten Dokumenttypen extrahiert. Ein Assistent, der beliebige Fragen beantworten, unbekannte Tools bedienen und in neuen Fachgebieten Schlussfolgerungen ziehen soll, hat eine wesentlich breitere Aufgabe. Diesen gesamten Assistenten zu verkleinern ist deutlich anspruchsvoller, als nur seinen Klassifikator zur Absichtserkennung zu spezialisieren.
Für die Entwicklung: Eingaben, Ausgaben und das Verhalten bei Fehlern müssen feststehen, bevor Daten gesammelt werden. Fehlt auf einer Rechnung die Bestellnummer, kann null die korrekte Extraktion sein – und keine plausibel wirkende Vermutung. Genau diesen Unterschied müssen die Trainingsbeispiele vermitteln.
Für den Betrieb: Verglichen werden muss der vollständige Ablauf der Anfragebearbeitung. Dazu gehören Wiederholungsversuche, fehlgeschlagene Validierungen, manuelle Prüfungen, an den Teacher weitergereichte Anfragen sowie laufende Evaluation und erneutes Training. Ein geringerer Ressourcenbedarf bei der Inferenz hilft nur, wenn diese Pflichten den Vorteil nicht aufzehren. Es gibt keine allgemeingültige Mindestzahl an Anfragen, ab der sich Destillation lohnt.
Für den Einkauf: Zu prüfen ist, ob der benötigte Teacher, das Student-Modell, das Trainingsverfahren und der Bereitstellungsort gemeinsam unterstützt werden. Dass ein Anbieter beide Modelle für gewöhnliche Inferenz anbietet, belegt noch nicht, dass sich bei ihm das eine in das andere destillieren lässt.
Datenschutz kann ein Grund für ein kleineres, passend gehostetes Student-Modell sein. Klein bedeutet jedoch nicht automatisch datenschutzfreundlich. Entscheidend ist, wo sich Rohdaten, Teacher-Aufrufe, Trainingsdateien, Protokolle und das bereitgestellte Modell befinden. Ein lokal betriebenes Student-Modell macht nicht rückgängig, dass bei der Datensatzerstellung bereits sensible Daten an einen entfernten Teacher gesendet wurden.
Abwarten ist sinnvoll, wenn sich die Aufgabendefinition häufig ändert, die verfügbaren Beispiele nicht repräsentativ sind, die Labels des Teacher-Modells unzuverlässig bleiben oder die Trainingsrechte ungeklärt sind. Erfüllt ein kleineres Modell ohne Anpassung bereits die Anforderungen, ist kein Training nötig. Google weist ausdrücklich darauf hin, dass der Zugewinn durch Destillation kleiner ausfällt, wenn das Student-Modell bei der Zielaufgabe schon nahe am Teacher liegt. Googles Hinweise zu geeigneten Destillationsaufgaben
Welche verwalteten Angebote stehen derzeit zur Verfügung?
Bei der Wahl eines verwalteten Angebots zählen zunächst die aktuell unterstützten Trainingsverfahren und der Produktlebenszyklus. Danach sind die Bedingungen für genau diesen Weg zu prüfen. Der folgende Vergleich gibt den Stand der am 26. Oktober 2026 geprüften Dokumentation wieder.
Model Distillation bei OpenAI: Zugang für Bestandskunden mit Enddatum
Der dokumentierte Ablauf von OpenAI beginnt mit einem verbesserten Teacher-Prompt. Anschließend werden Antworten erfasst, die die festgelegten Kriterien erfüllen, daraus ein Datensatz erstellt und ein kleineres Modell per Fine-Tuning angepasst. Als Erklärung des Verfahrens bleibt das nützlich. Als allgemeine Empfehlung für neue Projekte taugt es nicht mehr: Laut aktueller Anleitung steht die Fine-Tuning-Plattform neuen Nutzern nicht zur Verfügung. Überwachtes Fine-Tuning bei OpenAI
Berechtigte aktive Kunden können nur noch bis zum 6. Januar 2027 neue Jobs anlegen; frühere Modellabschaltungen bleiben vorbehalten. GPT-4.1 und GPT-4.1 mini werden einschließlich ihrer per Fine-Tuning angepassten Versionen am 14. Januar 2027 abgeschaltet. Die dokumentierte Abschaltung von GPT-4.1 nano und o4-mini erfolgte am 23. Oktober 2026. Diese Fristen machen eine neue, langfristige Abhängigkeit schwer vertretbar, selbst wenn das eigene Konto noch Zugriff hat. OpenAIs Abkündigungen
Für die Praxis heißt das: Bestandskunden sollten die Migration planen und ihre Evaluationsdaten sichern. Neue Projekte sollten einen verfügbaren Trainingsweg wählen, statt sich auf die damalige Einführung des Destillationsangebots zu stützen.
Google Vertex AI: Gemini-Tuning und Destillation offener Modelle unterscheiden
Die Dokumentation zu generativen Modellen von Google Vertex AI ist inzwischen unter Gemini Enterprise Agent Platform zu finden. Die Anleitung zum Gemini-Tuning beschreibt überwachtes Fine-Tuning, also Training mit gelabelten Beispielen, und nennt unter anderem Gemini 3.5 Flash und Gemini 3.5 Flash-Lite. Empfohlen wird das Verfahren für Klassifikation, Sentimentanalyse und Entitätsextraktion. Googles aktuelle Tuning-Übersicht
Separat dokumentiert Google die verwaltete Destillation offener Modelle über das GenAI SDK. Auf der Teacher-Liste stehen beispielsweise DeepSeek R1 0528 und DeepSeek V3.2; zu den Student-Modellen gehören Qwen 3 8B und Gemma 3 4B IT. Für das überwachte Tuning offener Modelle gibt es außerdem vollständiges Fine-Tuning und LoRA, bei dem weniger Parameter angepasst werden. Die hierfür aufgeführten Modelle sind nicht mit der Liste der für Destillation zugelassenen Modelle identisch. Dokumentation zum Tuning offener Modelle
Die Grenze setzt die Kombination aus Verfahren, Modell und Standort. Neben dem Training benötigt auch die Teacher-Inferenz ein Kontingent. Der globale Endpunkt wählt eine unterstützte Region aus. Anforderungen an den Datenstandort verlangen deshalb eine gezielte regionale Konfiguration. Bei einfacher Klassifikation sollte zunächst das kleinere Modell getestet werden, bevor die Entscheidung für Googles auf Reasoning ausgerichtete Destillation fällt.
Amazon Bedrock Model Distillation: verwalteter Ablauf mit festen Modellpaaren
Amazon Bedrock Model Distillation verbindet die Erzeugung von Teacher-Antworten, die Datensynthese und das Fine-Tuning des Student-Modells in einem Ablauf. Als Ausgangspunkt dienen bereitgestellte Prompts oder vorhandene Protokolle von Modellaufrufen, also Aufzeichnungen früherer Anfragen und Antworten, die in Amazon Simple Storage Service (Amazon S3) gespeichert sind. Daneben bietet Bedrock überwachtes Fine-Tuning und Reinforcement Fine-Tuning als eigenständige Anpassungsverfahren an. Destillationsablauf, Anpassungsverfahren
Die aktuelle Tabelle unterstützter Paare nennt Amazon Nova Pro → Nova Lite oder Nova Micro in US East (N. Virginia). Zu den Llama-Optionen in US West (Oregon) gehört Meta Llama 3.3 70B → Llama 3.1 8B. Dort steht ausdrücklich, dass Destillation für Anthropic-Modelle derzeit nicht verfügbar ist. Einen bestätigten Termin für die Wiederherstellung gibt es nicht. Unterstützte Modellpaare und Regionen
Bedrocks Anleitung zur Datenvorbereitung begrenzt die bereitgestellten Eingaben auf 15K Prompts oder Prompt-Antwort-Paare. Das ist eine Obergrenze pro Job, kein Beleg dafür, dass eine Aufgabe so viele Beispiele benötigt. Die Datenauswahl sollte die tatsächlichen Entscheidungen und Fehlerfälle abdecken. Grenzen bei der Datensatzvorbereitung
Dieser Weg ist praktikabel, wenn das gewünschte Modellpaar unterstützt wird und die Anforderungen an die Bereitstellung dazu passen. Beliebige Teacher lassen sich damit nicht in beliebige Student-Modelle destillieren.
Die Vertragsfalle: Rechte an Ausgaben sind keine Trainingserlaubnis
Bevor Modellausgaben zum Training eines anderen Modells verwendet werden, muss der Vertrag für den Endpunkt geprüft werden, der diese Daten erzeugt hat. Rechte an den Ausgaben, die Zusage des Anbieters, nicht mit Kundendaten zu trainieren, und das Recht, selbst ein Student-Modell zu trainieren, sind unterschiedliche Regelungen.
Die folgenden Auszüge sind bewusst kurz gehalten. Ihr Geltungsbereich ist ebenso wichtig wie der zitierte Wortlaut. Maßgeblich für die tatsächliche Nutzung sind der unterzeichnete Vertrag, das Bestellformular und die anwendbaren Produktbedingungen.
OpenAI: Wettbewerbsbeschränkung mit ausdrücklich benannten Ausnahmen
OpenAIs Services Agreement beschränkt die Verwendung von Ausgaben zur Entwicklung von Modellen, die mit den Produkten und Dienstleistungen von OpenAI konkurrieren (“compete with OpenAI’s products and services”), sofern keine zulässige Ausnahme greift. Diese Definition umfasst interne Modelle, die vorwiegend Daten kategorisieren, klassifizieren oder organisieren sollen, sofern sie nicht an Dritte weitergegeben oder Dritten kommerziell angeboten werden. Sie umfasst außerdem das Fine-Tuning oder die Anpassung von Modellen, die über die angegebenen OpenAI-Dienste bereitgestellt werden. Services Agreement: Beschränkung und Definitionen
Ein interner Klassifikator unterscheidet sich dadurch wesentlich von einem allgemeinen generativen Modell, das Kunden angeboten wird. Es wäre falsch, automatisch jede Extraktionsfunktion, jeden gehosteten Klassifikator oder jedes private Universalmodell unter diese Ausnahme zu fassen. Die für den Vertrag zuständige Person sollte den konkreten Einsatz bestätigen.
Hinzu kommt ein zeitlicher Unterschied. OpenAI hat eine Richtlinienänderung veröffentlicht, die am 20. November 2026 in Kraft tritt, also nach dem Prüfdatum dieses Artikels. Sie betrifft die Verwendung von Modellen oder Ausgaben als Trainingssignale für Alternativen oder Ersatzangebote, darunter Labels, Feedback und Filterung. Nutzungen, die der anwendbare Vertrag ausdrücklich erlaubt, bleiben dabei zulässig. Es handelt sich um eine bevorstehende Änderung, nicht um eine am Prüfdatum bereits geltende Regel. Veröffentlichte Änderung der Nutzungsrichtlinien
Anthropic: Training konkurrierender Modelle nur mit ausdrücklicher Genehmigung
Anthropics Commercial Terms verbieten den Zugriff auf die Dienste zum Aufbau eines konkurrierenden Produkts oder Dienstes, einschließlich des Trainings konkurrierender KI-Modelle (“train competing AI models”), sofern dies nicht ausdrücklich genehmigt wurde. Die gesonderte Übertragung von Rechten an den Ausgaben hebt diese Beschränkung nicht auf. Anthropic Commercial Terms, D.4
Bevor Claude-Ausgaben zum Trainingsdatensatz eines anderen Modells werden, ist deshalb eine Prüfung des konkreten Vertrags nötig. Eine ältere Ankündigung zur Destillation in der Cloud belegt weder die heutige Verfügbarkeit noch eine entsprechende Erlaubnis.
Google: Für Cloud und Gemini-Entwickler-API gelten getrennte Verträge
Google Clouds Modellbeschränkungen untersagen es, Dienstausgaben zu verwenden, um die Nutzung eines Google-Modells zu substituieren, zu ersetzen oder zu umgehen (“substitute, replace, or circumvent the use of a Google Model”) oder Modelle zu erstellen oder zu verbessern, die einem Google-Modell ähneln (“create or improve models similar to a Google Model”). Eine ausdrückliche Ausnahme gilt, wenn der Dienst Fine-Tuning oder Destillation anbietet: Dann dürfen seine Ausgaben verwendet werden, um Modified Google Models anzupassen und anstelle von Google Pre-Trained Models zu nutzen. Für separate Angebote gelten separate Bedingungen. Google Cloud Service Specific Terms
Die Gemini-Entwickler-API verwendet eine andere Formulierung: Ihre Dienste dürfen nicht dazu genutzt werden, Modelle zu entwickeln, die mit den Diensten konkurrieren (“develop models that compete with the Services”). Diese Zusatzbedingungen grenzen die direkte Nutzung über Google Cloud Platform ausdrücklich ab. Eine Erlaubnis innerhalb eines verwalteten Cloud-Ablaufs lässt sich nicht ohne Weiteres auf einen davon unabhängigen Plan zur Datenerzeugung über die Gemini API übertragen. Gemini API Additional Terms
Amazon: Die Erlaubnis des Dienstes bildet die Ausnahme
Die einschlägige Beschränkung in den AWS Service Terms beginnt mit “Except where permitted by the AI Service”, also „Sofern nicht durch den KI-Dienst erlaubt“. Ansonsten verbietet sie die Erzeugung von Inhalten zum ausdrücklichen Zweck des Trainings eines KI-Modells oder -Dienstes (“the express purpose of training an AI model or service”) sowie die Entwicklung eines im Wesentlichen vergleichbaren Modells oder Dienstes. Bedrock bezieht zudem die anwendbaren Modellbedingungen von Drittanbietern ein. AWS Service Terms: KI-Dienste und Bedrock
Der dokumentierte verwaltete Ablauf mit seinen zugelassenen Modellpaaren ist der konkrete Weg, den es zu prüfen gilt. Seine Existenz ist keine pauschale Erlaubnis, die Antworten jedes Bedrock-Modells in beliebige externe Trainingsjobs zu exportieren.
Meta Llama: Modellname und Weitergabe unterliegen Bedingungen
Metas Lizenz für Llama 3.3 behandelt ausdrücklich das Training eines anderen Modells mit Llama-Materialien oder -Ausgaben. Wird das daraus entstandene Modell weitergegeben oder bereitgestellt, verlangt sie Llama am Anfang jedes solchen KI-Modellnamens (“at the beginning of any such AI model name”). Auch Lizenz-, Namensnennungs- und weitere anwendbare Bedingungen sind zu beachten. Llama 3.3 Community License
Das ist eine Lizenz für ein konkret benanntes Modell, keine allgemeine Aussage über sämtliche Meta-Modelle oder gehosteten Endpunkte. Die genaue Modellversion und die Hosting-Bedingungen gehören deshalb in die Dokumentation des Datensatzes.
Mistral AI: Textausgaben von bildspezifischen Beschränkungen trennen
Die aktuelle kommerzielle Ausgabebeschränkung von Mistral AI nennt Bildausgaben (“image Outputs”), die verwendet werden, um ein konkurrierendes Produkt zur Bilderzeugung zu entwickeln oder zu trainieren (“develop or train any image generation product that competes”). Diese Klausel bezieht sich auf Bilder. Sie als pauschales Verbot des Trainings mit Text darzustellen, würde ihren Inhalt überdehnen. Dieselben Bedingungen untersagen separat die Verwendung von Ausgaben für das Reverse Engineering von Mistral-AI-Produkten. Zusätzliche Produkt- oder Bereitstellungsbedingungen können ebenfalls gelten. Mistral AI Commercial Terms
Bei einem LLM-Datensatz ist die Textnutzung anhand des anwendbaren Vertrags zu prüfen. Weder eine Beschränkung für Bilder noch die Annahme einer unbegrenzten Erlaubnis lässt sich einfach darauf übertragen.
Grok: Training mit Enterprise-Ausgaben nur mit Ausnahme im Bestellformular
Groks Enterprise-Bedingungen auf x.ai untersagen es, beliebige Ausgaben zum Training von Foundation Models, großen Sprachmodellen oder anderen Systemen künstlicher Intelligenz zu verwenden (“any Output to train any foundation models, large language models, or other artificial intelligence systems”), sofern dies nicht ausdrücklich in einem Bestellformular erlaubt wird. Die Seite nennt SpaceXAI LLC als Vertragspartner und verwendet dafür den Namen SpaceXSI. Grok Enterprise Terms: Rechte an Ein- und Ausgaben
Diese Formulierung geht über ein Verbot hinaus, das nur konkurrierende Modelle betrifft. Ein internes Student-Modell ist nicht allein deshalb ausgenommen, weil es innerhalb des Unternehmens bleibt.
DeepSeek-R1: ausdrückliche Destillationserlaubnis für eine bestimmte Version
Laut dem offiziellen Repository von DeepSeek-R1 stehen Code und Gewichte unter der MIT License. Es erlaubt ausdrücklich die Destillation zum Training anderer LLMs (“distillation for training other LLMs”). Außerdem nennt es die ursprünglichen Qwen- und Llama-Lizenzen der bereits destillierten Versionen. Lizenzabschnitt von DeepSeek-R1
Das ist eine nützliche Erlaubnis für eine bestimmte Veröffentlichung. Sie legt aber nicht die Bedingungen jedes künftigen DeepSeek-Modells, Hosting-Dienstes oder Student-Basismodells fest. Sowohl die Erlaubnis für den Teacher als auch die Lizenz des Student-Modells gehören in die Freigabedokumentation.
Vor der Umstellung des Produktivverkehrs evaluieren
Ein Student-Modell ist einsatzbereit, wenn es die Abnahmekriterien der Funktion an unbekannten, produktionsnahen Eingaben erfüllt und einen kontrollierten Rollout besteht. Ein sinkender Trainingsverlust, also ein während des Trainings gemessener Fehlerwert, beweist keines von beidem.
Das folgende Vorgehen ist ein Vorschlag für die Freigabe, kein Bericht über Benchmark-Ergebnisse.
Aufgabe und Ausgangsbasis festlegen
Eingabeanforderungen, zulässige Ausgabewerte, Pflichtfelder und das Verhalten bei bewusstem Antwortverzicht schriftlich festhalten. Die Ergebnisse des aktuellen Teachers und eines kleinen Modells mit passendem Prompt für eine repräsentative Stichprobe sichern. Akzeptable Qualität und Latenz definieren, bevor das Ergebnis des trainierten Student-Modells betrachtet wird.
Training, Validierung und Abschlusstest trennen
Trainingsdaten dienen zur Anpassung der Gewichte, Validierungsdaten zur Auswahl von Prompts oder Checkpoints. Ein abschließender Testdatensatz bleibt unberührt, bis diese Entscheidungen feststehen. Zusammengehörige Kundengespräche, Dokumentvorlagen und nahezu identische Beispiele so gruppieren, dass Kopien nicht in unterschiedliche Teilmengen gelangen. Aktuelle reale Anfragen, seltene Klassen und schwierige Beispiele einbeziehen.
Teacher-Beispiele sorgfältig aufbereiten
Die Trainingseingaben von einem Teacher labeln lassen, dessen Nutzung dafür erlaubt ist. Das Format validieren, Zweifelsfälle prüfen und wichtige Fehler korrigieren. Beispiele beibehalten, bei denen ein Antwortverzicht oder ein fehlender Wert die richtige Ausgabe ist. Teacher-Modell, Prompt, Rechte an den Quelldaten und Datensatzversion dokumentieren. Der Leitfaden zur Erzeugung synthetischer Daten behandelt diese Datenarbeit ausführlicher.
Aufgabenerfolg statt Ähnlichkeit messen
Bei Klassifikation die Fehler je Klasse messen, besonders den Recall bei folgenreichen übersehenen Fällen: Wie viele tatsächliche Kündigungsanfragen wurden erkannt? Bei Extraktion die exakten Werte der Pflichtfelder und den Umgang mit fehlenden Feldern prüfen. Bei Ausgaben in einem festen Format die Schemagültigkeit, also die Einhaltung der geforderten Struktur, getrennt von der sachlichen Richtigkeit prüfen. Beim Routing messen, ob der gewählte nachgelagerte Verarbeitungsweg die Anfrage löst. Abweichungen zwischen Teacher- und Student-Modell anhand unabhängig geprüfter Antworten untersuchen.
Zuerst Shadow-Betrieb, dann Canary-Rollout
Im Shadow-Betrieb werden Live-Eingaben an das Student-Modell kopiert, während weiterhin das bestehende System die für Nutzer sichtbaren Ergebnisse liefert. Antwortqualität, langsame Anfragen, Zeitüberschreitungen und Eskalationsbedarf unter realer Last messen. Besteht das Student-Modell diese Prüfung, wird ihm im Canary-Rollout nur ein kontrollierter Anteil des Anfrageverkehrs zugewiesen – mit ausdrücklich festgelegten Abbruchkriterien und einer funktionierenden Rückkehr zur bisherigen Version.
Rückfallweg sichern und Drift überwachen
Nicht unterstützte Eingaben, fehlgeschlagene Validierungen und definierte Fälle mit hohem Risiko an den Teacher oder zur manuellen Prüfung weiterleiten. Veränderungen in der Zusammensetzung der Eingaben, Fehler je Klasse und den Anteil der Anfragen mit Fallback-Bedarf beobachten. Nach Änderungen an Prompts, Schemata, Student-Checkpoints, Quantisierung oder vorgelagerten Daten erneut evaluieren. Ein häufig genutzter Fallback ist ein Hinweis darauf, das Konzept zu überarbeiten.
Ein praktisches Freigabekriterium für eine Extraktionsfunktion könnte verlangen, dass das Student-Modell bei jeder wichtigen Dokumentfamilie die Genauigkeit der Pflichtfelder hält, das Latenzziel des bestehenden Dienstes einhält und bei fehlenden Informationen korrekt auf eine Antwort verzichtet. Die verantwortliche Person legt die Schwellenwerte anhand der Fehlerfolgen fest. Ein allgemeiner Anbieter-Benchmark kann diese Entscheidung nicht übernehmen.

Der Leitfaden zum Modellrouter hilft dabei, die Grenze zwischen Student-Anfragen und dem Rückfall auf ein Frontier-Modell zu gestalten. Die vom Student-Modell selbst angegebene Sicherheit sollte dafür nicht die einzige Grundlage sein. Regeln für zulässige Eingaben, Ausgabevalidierung und gemessene Fehlermuster geben dem Router konkrete Entscheidungskriterien.
Welche Erwartungen an Destillation sind überzogen?
„Das kleine Modell wird zum großen Modell.“ Es lernt aus den vorgegebenen Lernsignalen und der Abdeckung der Trainingsdaten. Erfolg bei vertrauten Extraktionsmustern sagt wenig über eine unbekannte Sprache, eine neue Dokumentfamilie oder eine umfassendere Denkaufgabe aus.
„Generierte Daten lösen das Labeling-Problem.“ Ein Teil der Arbeit verlagert sich vom Erstellen der Labels auf deren Prüfung. Ein Teacher kann eine große Sammlung durchgehend falscher Beispiele erzeugen. Menschliche Entscheidungen in Zweifelsfällen und unabhängige Testantworten bleiben wertvoll.
„Ein kleineres Modell spart garantiert Kosten.“ Zur bereitgestellten Funktion gehören auch Fallback, Prüfung, Hosting, Überwachung und erneutes Training. Entscheidend ist das Gesamtergebnis. Latenzverbesserungen müssen gemessen werden; die Modellgröße allein ist kein Versprechen.
„Verwaltete Destillation klärt die Rechtefrage.“ Sie bietet einen dokumentierten Ablauf mit konkreten Grenzen. Dadurch werden nicht sämtliche Modellausgaben zu frei verwendbarem Trainingsmaterial.
„Gültiges JSON bedeutet, dass die Funktion arbeitet.“ Eine perfekt formatierte falsche Konto-ID bleibt falsch. Formatprüfungen sind ein Freigabekriterium, nicht die gesamte Evaluation.
Häufige Fragen zur Modelldestillation
Funktioniert Modelldestillation tatsächlich?
Sie kann nützliches Aufgabenverhalten von einem Teacher auf ein Student-Modell übertragen. Für die konkrete Funktion zählt die Leistung bei unbekannten, unabhängig geprüften Eingaben, gefolgt von einem kontrollierten Rollout im Produktivbetrieb. Eine allgemeine Leistungsfähigkeit auf Teacher-Niveau ist damit nicht garantiert.
Was unterscheidet Modelldestillation von Fine-Tuning?
Destillation bezeichnet das Lernen anhand der Lernsignale eines anderen Modells. Fine-Tuning bezeichnet die Anpassung eines bereits trainierten Modells mit aufgabenspezifischen Daten. Werden Teacher-Antworten zu Beispielen für das überwachte Training des Student-Modells, ist derselbe Trainingsjob sowohl Destillation als auch Fine-Tuning.
Wie lässt sich ein LLM destillieren?
Zunächst eine eng umrissene Aufgabe definieren und die Rechte an Teacher-Ausgaben und Student-Modell klären. Dann repräsentative Teacher-Beispiele aufbereiten, über einen unterstützten Weg trainieren und das Student-Modell mit dem Teacher sowie einem kleinen Modell ohne zusätzliches Training vergleichen. Vor einer breiteren Umstellung stehen die Evaluation mit zurückgehaltenen Daten, Shadow-Betrieb und ein Canary-Rollout.
Was ist ein destilliertes Modell?
Ein Modell, das mit Lernsignalen eines anderen Modells trainiert wurde, häufig mit dem Ziel, ein kleineres Modell für eine bestimmte Aufgabe leistungsfähig zu machen. Was es beherrscht, hängt weiterhin vom Student-Modell, den Trainingsdaten und dem Umfang der Evaluation ab.
Was ist Modelldestillation?
Modelldestillation überträgt erlerntes Verhalten durch Training von einem Teacher-Modell auf ein Student-Modell. In einem verbreiteten LLM-Ablauf erzeugt der Teacher Labels oder Antworten, und das Student-Modell lernt aus freigegebenen Eingabe-Ausgabe-Paaren.
Welche vier Arten der Destillation gibt es?
Für die Destillation von LLMs gibt es keine allgemeingültige Einteilung in vier Arten. Listen mit dieser Formulierung beziehen sich häufig auf die Trennung von Flüssigkeiten, also eine andere Bedeutung von Destillation. Bei einer LLM-Funktion sollten die tatsächlichen Lernsignale und das Trainingsverfahren bestimmt werden, statt eine Kategorie aus der Chemie zu wählen.
Was sind 5 Beispiele für Destillation?
Mögliche Aufgaben in LLM-Anwendungen sind die Weiterleitung von Supporttickets, die Kennzeichnung von Nutzerabsichten, die Extraktion von Rechnungsfeldern, die Normalisierung von Datensätzen und die Erzeugung von Antworten in einem festen Format. Das sind Einsatzmöglichkeiten, die geprüft werden müssen, keine Zusage, dass ein destilliertes Modell automatisch alle fünf beherrscht.
Welche Nachteile hat Modelldestillation?
Das Student-Modell kann Fehler des Teacher-Modells übernehmen und bei seltenen Eingaben versagen. Die Datenprüfung kann teuer werden, und eine veränderte Aufgabe kann erneutes Training erfordern. Auch der Produktlebenszyklus des Anbieters, Beschränkungen für Teacher-Ausgaben und die Lizenz des Student-Modells können den Einsatz begrenzen.
Was ist ein einfaches Destillationsverfahren?
Bei LLMs erzeugt ein dafür zugelassener Teacher Antworten auf repräsentative Eingaben. Diese Antworten werden geprüft, anschließend wird ein Student-Modell mit den freigegebenen Paaren per überwachtem Fine-Tuning trainiert. Getestet wird an separaten realen Fällen. Das ist von der einfachen Destillation im Labor zu unterscheiden.
Der nächste Schritt in der Entwicklung
In der nächsten Woche die Verantwortung für eine wiederkehrende Funktion festlegen. Die zuständige Person definiert deren Ausgabeanforderungen, stellt aus realen Anfragen eine zurückgehaltene Stichprobe zusammen und vergleicht den aktuellen Teacher mit einem kleinen Modell mit passendem Prompt. Bleibt eine relevante Qualitätslücke, wird ein verfügbarer und zulässiger Weg vom Teacher- zum Student-Modell bestätigt. Der Trainingsdatensatz richtet sich dann gezielt auf die Fehlerfälle aus.
Besteht das kleine Ausgangsmodell die Prüfung bereits, genügt diese einfachere Verbesserung. Können weder der Teacher noch die prüfenden Personen schwierige Fälle konsistent labeln, muss vor dem Training die Aufgabendefinition geklärt werden.
Den Newsletter abonnieren für praktische Entscheidungen bei der Entwicklung und dem Betrieb von KI-Funktionen.
- Veröffentlicht
- Kategorie
- Build
- Sprache










