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: Kleine LLMs für den Produktivbetrieb

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.

Architektonisch gestaltete Kletterschule mit Vorführungen des Lehrers, Übungsbereich des Schülers und einem getrennten Bereich für zurückgehaltene Testfälle
An Trainingsbeispielen lernt das Student-Modell. Ein separater Testdatensatz prüft, ob es die Aufgabe beherrscht.

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

Verfahren oder VergleichWas sich ändertWann es sinnvoll ist
Modelldestillation und Fine-TuningDestillation liefert das Lernsignal des Teacher-Modells; Fine-Tuning ist der Prozess, der das Student-Modell anpasstWenn ein Modell vorgeführtes Verhalten lernen soll; derselbe Trainingsjob kann beides sein
QuantisierungDie numerische Präzision, mit der ein Modell dargestellt wird oder rechnetWenn das Modell bereits funktioniert, aber sein Ressourcenbedarf bei der Bereitstellung zu hoch ist
Retrieval-Augmented GenerationRelevante Informationen werden zum Zeitpunkt der Anfrage bereitgestelltWenn Antworten von aktuellen oder privaten Informationen abhängen
ModellroutingDie Anwendung wählt das Modell aus, das eine Anfrage bearbeitetWenn einfache und schwierige Anfragen unterschiedliche Wege nehmen sollen

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.

AnbieterDokumentierter WegEntscheidende Einschränkung
OpenAITeacher-Ausgaben werden zu einem Datensatz für überwachtes Fine-TuningFür neue Fine-Tuning-Nutzer geschlossen; für berechtigte Bestandskunden läuft das Angebot aus
Google CloudÜberwachtes Tuning für Gemini; separate verwaltete Destillation für aufgeführte offene ModelleFür Gemini-Tuning und die Teacher-/Student-Unterstützung offener Modelle gelten unterschiedliche Modelllisten
Amazon Web ServicesBedrock automatisiert die Datenerzeugung durch den Teacher und das Fine-Tuning des Student-ModellsNur aufgeführte Teacher-/Student-Paare und Regionen; Destillation mit Anthropic derzeit nicht verfügbar

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

OpenAI-Dokumentation zum überwachten Fine-Tuning mit aktuellen Angaben zur Verfügbarkeit der Plattform
OpenAI: aktuelle Fine-Tuning-Dokumentation

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

Google-Dokumentation mit getrennten Angaben zur Unterstützung von überwachtem Fine-Tuning und Destillation offener Modelle
Google Cloud: Tuning und Destillation offener Modelle

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

Amazon-Bedrock-Dokumentation zum Ablauf der verwalteten Modelldestillation
Amazon Bedrock: verwaltete Modelldestillation

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Architektonische Entscheidungspfade von bestandener Evaluation über einen Canary-Rollout zum Produktivverkehr; bei gescheiterter Evaluation oder gescheitertem Canary führt der Weg zum Fallback zurück
Aufgabenevaluation bestehen, eine kontrollierte Freigabe testen und den Rückweg zum bestehenden System offenhalten.

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
Vision Language Models: Was in der Praxis verlässlich ist

Vision Language Models: Was in der Praxis verlässlich ist

Was Vision Language Models bei Screenshots und Dokumenten leisten, wo sie scheitern und wie sich API und Eigenbetrieb mit eigenen Bildern prüfen lassen.26. Okt. 2026Build
KI-Agenten: Wann ein Agent reicht und wann ein Team hilft

KI-Agenten: Wann ein Agent reicht und wann ein Team hilft

Wann lohnen sich mehrere KI-Agenten? Architekturmodelle, Beispiele und typische Fehler zeigen, wann ein Multiagentensystem hilft und wann ein Agent reicht.26. Okt. 2026Build
Prompt Injection: Wie sich KI-Agenten absichern lassen

Prompt Injection: Wie sich KI-Agenten absichern lassen

Wie direkte und indirekte Prompt Injection KI-Agenten manipuliert – und welche Zugriffsregeln, Freigaben und Prüfungen Postfach- und CRM-Workflows absichern.26. Okt. 2026Build
GraphRAG vs RAG: Wann sich ein Wissensgraph lohnt

GraphRAG vs RAG: Wann sich ein Wissensgraph lohnt

GraphRAG vs RAG: Wie Microsofts Ansatz funktioniert, welche Fragen er abdeckt und was Indexierung, Suchmodi und laufende Aktualisierung erfordern.26. Okt. 2026Build
KI-Agenten: Architektur für den produktiven Einsatz

KI-Agenten: Architektur für den produktiven Einsatz

KI-Agenten verlässlich betreiben: Modell, Tools, Gedächtnis, Orchestrierung und Freigaben am Support-Beispiel erklärt. Was zukaufen, was selbst entwickeln?25. Okt. 2026Build
Cursor Models: Welche Modelle nach der Oktober-Umstellung passen

Cursor Models: Welche Modelle nach der Oktober-Umstellung passen

Welche Cursor-Modelle nach der Oktober-Umstellung verfügbar sind, wie Auto auswählt und was bei Kontingenten, Drittanbieterkosten und API-Schlüsseln gilt.25. Okt. 2026Build
Temperature: LLM-Ausgaben steuern und Modellgröße verstehen

Temperature: LLM-Ausgaben steuern und Modellgröße verstehen

Was Temperature bei LLMs steuert, was Milliarden Parameter bedeuten und welche Einstellungen OpenAI, Anthropic und Google unterstützen: mit Praxisbeispielen.25. Okt. 2026Build
vLLM Batching: Wie Continuous Batching den Durchsatz erhöht

vLLM Batching: Wie Continuous Batching den Durchsatz erhöht

Wie Continuous Batching den LLM-Durchsatz steigert, Latenzen verändert und mit dem KV-Cache zusammenspielt: vLLM, SGLang, TensorRT-LLM und TGI im Vergleich.25. Okt. 2026Build
Newsletter

Ein Brief, jeden Sonntag.Funktionierende Systeme, keine heißen Takes.

Wöchentlich. Kein Spam. Jederzeit abbestellbar.