🤖 machine learning

Training-Inference Kernel Contracts: Bounding Divergence in Post-Training and Deployment

Dieses Paper schlägt ein „Kernel Contracts“-Framework vor, um die distributional Divergenz zwischen Trainings- und Inferenz-Kerneln in Post-Training-Pipelines formal zu spezifizieren und zu begrenzen, theoretische Schranken für den Policy-Gradient-Bias abzuleiten und eine strukturierte Deployment-Pipeline zu skizzieren, während es gleichzeitig feststellt, dass es ein konzeptionelles Framework ohne empirische Validierung auf Produktionsskala darstellt.

Ursprüngliche Autoren: Bruce Changlong Xu, Lan Wu

Veröffentlicht 2026-06-09

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Bruce Changlong Xu, Lan Wu

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben einen brillanten Chefkoch (das KI-Modell), der jahrelang gelernt hat, in einer High-End-Testküche zu kochen, die perfekt kalibriert ist. In dieser Küche verwendet er präzise digitale Waagen, frische Zutaten und einen langsamen, sorgfältigen Kochprozess, um sicherzustellen, dass jedes Gericht perfekt ist. Dies ist die Trainingsküche.

Nun stellen Sie sich vor, Sie möchten die Rezepte dieses Chefkochs an tausende hungrige Kunden in einem belebten Foodtruck servieren. Um mit der Nachfrage Schritt zu halten, wechseln Sie zu einem anderen Setup: Sie verwenden vorportionierte Gewürzbeutel, einen schnelleren (aber etwas weniger präzisen) Grill und ein System, bei dem Bestellungen gebündelt werden, um Zeit zu sparen. Dies ist die Inferenzküche.

Das Problem ist laut diesem Paper, dass – obwohl es derselbe Chefkoch ist, der dasselbe geheime Rezept (die Modellgewichte) verwendet – das Essen aus dem Foodtruck nicht exakt dasselbe ist wie aus der Testküche. Der Unterschied ist winzig – vielleicht eine Prise Salz hier oder ein etwas anderer Bratvorgang dort – aber über tausende Bestellungen hinweg können sich diese winzigen Unterschiede summieren. Manchmal kommt ein Gericht, das eigentlich „scharf“ sein sollte, als „mild“ heraus, oder eine Sicherheitsprüfung, die in der Küche funktionierte, versagt auf dem Foodtruck.

Das Paper nennt diese Lücke den „Training-Inference Kernel Contract“. Hier ist eine einfache Aufschlüsselung ihrer Lösung:

1. Das Problem: „Zwei verschiedene Köche“

Wenn wir heute KI bauen, gehen wir davon aus, dass der „Trainings-Chefkoch“ und der „Inferenz-Chefkoch“ exakt das Gleiche tun. In Wirklichkeit nutzen sie jedoch unterschiedliche Werkzeuge und Methoden.

Training verwendet hochpräzise Mathematik (wie eine digitale Waage).
Inferenz verwendet schnelle, weniger präzise Mathematik (wie eine visuelle Schätzung), um schneller zu sein und Kosten zu sparen.

Weil sie unterschiedliche Werkzeuge benutzen, treffen sie manchmal auch unterschiedliche Entscheidungen. In einem normalen Restaurant bedeutet das vielleicht nur, dass eine Suppe leicht anders schmeckt. Aber für eine KI kann das bedeuten:

Das „Reward Hacking“: In der Reinforcement Learning (wo die KI durch Versuch und Irrtum lernt) könnte die KI denken, sie mache einen großartigen Job, weil die „schnelle“ Küche ihr eine gute Bewertung gegeben hat, während die „präzise“ Küche ihr eine schlechte gegeben hätte. Es ist, als würde ein Schüler in einer Übung eine Eins bekommen, aber in der echten Prüfung durchfallen, weil sich das Bewertungsschema geändert hat.
Der „Sicherheitsfehler“ (Safety Slip): Ein Prompt, den das Modell in der Testküche verweigern würde, könnte in der Foodtruck-Variante versehentlich doch beantwortet werden, weil der schnelle Grill den Geschmack gerade so weit verändert hat, dass der Sicherheitsfilter umgangen wurde.

2. Die Lösung: Der „Kernel Contract“

Die Autoren schlagen ein neues Regelwerk vor, den Kernel Contract. Betrachten Sie dies nicht als ein juristisches Dokument für Anwälte, sondern als eine Qualitätskontroll-Checkliste, die mit der KI mitreist.

Dieser Vertrag besagt: „Wir wissen, dass die schnelle Küche (Inferenz) nicht 100 % identisch mit der Testküche (Training) sein wird. Das ist okay. Aber hier sind die spezifischen Regeln, die wir NICHT brechen werden.“

Der Vertrag besteht aus vier Abschnitten:

Numerische Regeln (N): „Die Mathematik darf nicht mehr als X abweichen.“ (z. B. Der Gewürzgrad darf sich nicht um mehr als 10 % ändern).
Statistische Regeln (S): „Der Endgeschmack muss konsistent sein.“ (z. B. In 99 % der Fälle muss das Gericht immer noch als ‚scharf‘ erkannt werden).
Runtime-Regeln (R): „Es muss immer noch schnell genug sein.“ (z. B. Der Foodtruck darf nicht langsamer werden, nur weil wir eine Sicherheitsprüfung hinzugefügt haben).
Observability-Regeln (O): „Wir müssen in der Lage sein, jede einzelne Bestellung später nachzuprüfen.“ (Wenn sich ein Kunde beschwert, müssen wir in der Lage sein, genau diese Bestellung in beiden Küchen zu reproduzieren, um zu sehen, was schiefgelaufen ist).

3. Die „Eskalationspolitik“ (Was passiert, wenn man gegen die Regeln verstößt?)

Der Vertrag ist nicht nur eine Liste; er hat ein Ampelsystem:

Grün (L1): „Achtung.“ Wir haben eine winzige Abweichung protokolliert. Kochen Sie weiter.
Gelb (L2): „Warnung.“ Der Unterschied wird zu groß. Wir hören auf, neue Bestellungen an diese Küche zu senden, und leiten sie stattdessen an eine Backup-Küche um, bis wir das Problem behoben haben.
Rot (L3): „Notfall.“ Etwas ist kritisch schiefgelaufen. Wir schalten diese Küche sofort ab und wechseln zu einer bekannten, funktionierenden Version.

4. Die „Vier-Stufen-Promotion“ (Wie man vor dem Servieren testet)

Man schaltet die neue Küche nicht einfach per Knopfdruck für die Öffentlichkeit frei. Das Paper schlägt einen vierstufigen Sicherheitstunnel vor:

Offline CI: Führen Sie die Checkliste mit einem festen Satz von Testbestellungen im Labor durch. Wenn sie fehlschlägt, verlassen Sie das Labor gar nicht erst.
Shadow (Schattenmodus): Lassen Sie die neue Küche zwar kochen, aber servieren Sie den Kunden das Essen der alten Küche. Wir beobachten dabei nur, ob die neue Küche Fehler gemacht hätte.
Canary (Kanarienvogel-Phase): Lassen Sie die neue Küche eine winzige Gruppe echter Kunden bedienen (wie 1 %). Wenn sich diese beschweren, stoppen wir sofort.
Full (Vollbetrieb): Wenn alle zufrieden sind, lassen wir die neue Küche das gesamte Menü servieren.

5. Warum dies für „lernende“ KI (RL) wichtig ist

Das Paper macht einen spezifischen Punkt über KI, die selbst lernt (Reinforcement Learning).

Das Problem: Wenn die KI lernt, macht sie eine „Momentaufnahme“ der Welt mithilfe der schnellen Küche, versucht aber dann, aus der präzisen Küche zu lernen. Es ist, als würde man versuchen, ein Auto zu fahren, indem man ein Video von einem Rennwagen beobachtet, dann aber ein völlig anderes Automodell fährt. Die KI wird verwirrt und lernt die falschen Lektionen.
Die Lösung: Der Vertrag zwingt die KI dazu, zuzugeben: „Hey, meine schnelle Küche und meine präzise Küche sind unterschiedlich.“ Er fügt einen „Korrekturfaktor“ zum Lernprozess hinzu, damit die KI nicht durch die Geschwindigkeit des Foodtrucks getäuscht wird.

Zusammenfassung

Das Paper argumentiert, dass wir aufhören müssen, so zu tun, als wären die „Trainings-KI“ und die „servierende KI“ dasselbe. Stattdessen sollten wir sie als zwei verschiedene Partner behandeln, die einen Vertrag unterzeichnet haben. Dieser Vertrag legt explizit fest, wie sehr sie voneinander abweichen dürfen, was passiert, wenn sie zu stark voneinander abweichen, und wie man diese Unstimmigkeiten abfängt, bevor sie das Kundenerlebnis ruinieren.

Es geht darum, von „wir hoffen, dass alles funktioniert“ zu „wir messen genau, wo die Unterschiede liegen, und managen diese“.

Technisches Resümee: Training-Inference Kernel Contracts

Problemstellung

Moderne Post-Training-Pipelines für Large Language Models (LLMs) behandeln die Policy $\pi_\theta$ als ein einzelnes mathematisches Objekt. In endlicher Präzision wird $\pi_\theta$ jedoch durch zwei unterschiedliche Programme evaluiert: einen Training-Kernel ( $K_{train}$ ), der auf Differenzierbarkeit optimiert ist (unter Verwendung von hochpräzisen Akkumulatoren, festen Shapes und Referenz-Attention), und einen Inference-Kernel ( $K_{inf}$ ), der auf Durchsatz optimiert ist (unter Verwendung von Low-Precision-Operatoren, Paged Key-Value Caches und dynamischen Attention-Tiles).

Das Paper identifiziert eine kritische „Spezifikationslücke“: Diese beiden Kernel berechnen messbar unterschiedliche Funktionen derselben Gewichte $\theta$ . Diese Divergenz tritt nicht gleichmäßig auf; sie konzentriert sich auf spezifische Slices (z. B. Long-Context-Inputs, sicherheitskritische Prompts), die in aggregierten Benchmarks oft unterrepräsentiert sind. Die Konfundierung von $K_{train}$ und $K_{inf}$ führt zu mehreren Fehlermodi:

Off-Policy-Bias in RL: Reinforcement-Learning-Pipelines (z. B. PPO, GRPO) sampeln Rollouts aus $K_{inf}$ , berechnen aber Gradienten mittels $K_{train}$ . Der Standard-Schätzer nimmt an, dass das Importance-Ratio $w = \pi^{K_{train}}_\theta / \pi^{K_{inf}}_\theta$ gleich 1 ist, was einen Bias einführt, der sich als KL-Kollaps, Reward-Hacking oder plötzliche Leistungsdegradation manifestiert.
Deployment Drift: Modelle, die in BF16 feinjustiert wurden, können signifikant driften, wenn sie bei der Inferenz auf FP8 oder INT4 gecastet werden, insbesondere bei seltenen Sicherheits-Prompts oder strukturierten Outputs.
Nicht-Reproduzierbarkeit: Heterogene Serving-Fleets (unterschiedliche Hardware/Kernel-Builds) produzieren divergente Outputs für dieselbe Anfrage, was A/B-Tests und Sicherheits-Audits nicht reproduzierbar macht.

Derzeit existiert keine maschinenlesbare Spezifikation, die definiert, welches Maß an Divergenz zwischen $K_{train}$ und $K_{inf}$ tolerierbar ist, für welche Datenslices gilt und welche Maßnahmen zu ergreifen sind, wenn Grenzwerte überschritten werden.

Methodik: Der Kernel Contract

Die Autoren schlagen ein formales Spezifikations-Objekt vor, das als Kernel Contract bezeichnet wird, bezeichnet mit $C = (N, S, R, \Pi)$ . Dieser Contract begleitet den Modell-Checkpoint und den Kernel-Build durch die CI/CD-Pipeline.

1. Die Struktur des Contracts

Der Contract besteht aus vier Familien von Klauseln und einer Eskalationsrichtlinie:

Numerisch ( $N$ ): Beschränkungen bezüglich roher numerischer Disagreements, wie Logit-Drift ( $\Delta_{logit}$ ), KL-Divergenz, Total Variation (TV) Distanz und das Importance-Ratio $w$ für RL.
Statistisch ( $S$ ): Beschränkungen bezüglich verhaltensbasierter Ergebnisse, einschließlich Top- $k$ Token-Agreement, Kalibrierungsdrift ( $\Delta_{ECE}$ ), Reward-Deltas und der Parsierbarkeit strukturierter Outputs.
Laufzeit ( $R$ ): Operative Beschränkungen bezüglich Latenz, Durchsatz, Speicherverbrauch (einschließlich KV-Cache) und Fehlerraten.
Observability ( $O$ ): Anforderungen an Trace-Felder, Kernel-Fingerprints und Replay-Signaturen, um sicherzustellen, dass Verletzungen zurechenbar sind.
Eskalationsrichtlinie ( $\Pi$ ): Eine Abbildung von Verletzungsschweregraden ( $L1$ : informativ, $L2$ : qualitätsbeeinträchtigend, $L3$ : sicherheitskritisch) auf Routing-Aktionen (Log, Guard, Fallback/Rollback).

Klauseln sind definiert mit Schwellenwerten ( $\tau$ ), erlaubten Überschreitungsraten ( $\rho$ ) und spezifischen Datenslices ( $\Sigma$ ), auf die sie Anwendung finden.

2. Theoretische Schranken (Die Kette)

Das Paper leitet eine Kette von Lipschitz-artigen Schranken her, die niedrigniveau numerische Fehler mit High-Level-Reward-Fehlern verbinden:

Logit zu Verteilung: Eine Schranke für den Logit-Drift ( $\|\varepsilon\|_\infty$ ) propagiert zu einer Schranke für die Total Variation Distanz ( $\Delta_{TV}$ ) und die KL-Divergenz, skaliert durch die Temperatur $T$ .
Verteilung zu Reward: Für eine beschränkte Reward-Funktion $r$ ist die erwartete Differenz des Rewards durch $2R \cdot \Delta_{TV}$ beschränkt.
Anwendung auf RL: Unter Annahmen von Support-Overlap und beschränkter Advantage beweist das Paper, dass eine pro-Token-Schranke für das Importance-Ratio $w$ (oder äquivalent die TV-Distanz zwischen den $K_{train}$ und $K_{inf}$ Policies) den Bias des Standard-Policy-Gradient-Schätzers begrenzt. Dies interpretiert den PPO-Clipping-Parameter $\epsilon$ nicht nur als Trust-Region für Policy-Updates, sondern als Budget für das Train-Infer-Kernel-Paar.

3. Enforcement-Pipeline

Das Framework schlägt eine vierstufige Promotions-Pipeline vor, um den Contract durchzusetzen:

Offline CI: Evaluiert harte numerische Klauseln gegen feste Datensätze.
Shadow: Spiegelt Live-Traffic auf den Kandidaten-Kernel, um workloads-abhängige Regressionen zu detektieren.
Canary: Routet einen kleinen Bruchteil des Live-Traffics zum Kandidaten, wobei die Eskalationsrichtlinie aktiv ist.
Full Promotion: Erfolgt erst nach nachhaltiger Compliance über ein Stabilitätsfenster hinweg.
Ein Online-Routing-Loop überwacht kontinuierlich die Contract-Gesundheit ( $h_t$ ) und schaltet den Traffic basierend auf Echtzeit-Verletzungsleveln auf geschützte oder sichere Kernel um.

Kernbeiträge

Das Paper leistet drei primäre Beiträge:

Konzeptionell: Es identifiziert die korrekte Speifikationseinheit in modernen LLM-Pipelines nicht als den Checkpoint oder die Engine allein, sondern als das Paar $(K_{train}, K_{inf})$ zusammen mit den spezifischen Datenslices, in denen sie übereinstimmen müssen.
Technisch: Es liefert eine Kette von Schranken, die es Ingenieuren ermöglicht, Constraints auf der messbaren numerischen Ebene (Logits) zu spezifizieren und Garantien auf der Verhaltensebene (Rewards) zu erben.
Anwendungsorientiert: Es demonstriert, dass Standard-RL-Stabilitätsheuristiken (wie PPO Clipping) formal als Contract-Klauseln interpretiert werden können, die die Kernel-Divergenz begrenzen, und skizziert ein minimales YAML-DSL zur Implementierung dieser Artefakte.

Ergebnisse und Validierung

Das Paper stellt explizit klar, dass es keine empirische Validierung im Produktionsmaßstab berichtet und nicht behauptet, dass Kernel-Divergenz die alleinige Ursache der diskutierten Fehlermodi ist. Stattdessen präsentiert es ein Framework- und Vokabular-Paper.

Die „Ergebnisse“ sind theoretische Ableitungen und ein vorgeschlagenes experimentelles Protokoll (Sektion 8) für zukünftige Validierungen:

Theoretisch: Beweise, dass Logit-Drift-Schranken Reward-Drift-Schranken implizieren und dass Kernel-Mismatch einen berechenbaren Bias in Policy-Gradienten einführt.
Vorgeschlagene Experimente: Die Autoren skizzieren fünf falsifizierbare Experimente (E1–E5), um das Framework zu testen, einschließlich der Kartierung numerischer Drift-Baselines, des Testens der Hardware-Sensitivität, der Validierung des RL-Bias-Bounds, der Untersuchung von Contract-aware Distillation und der Simulation von Self-healing Routing unter Fault-Injection.

Bedeutung und Umfang

Das Paper positioniert sich als eine fundamentale Spezifikationsschicht, die mehrere parallele Literaturen verbindet: RL Post-Training, High-Throughput Serving, formale Verifikation und Software-Contracts.

Bescheidenheit: Die Autoren sind explizit darin, dass dies ein „Framework- und Vokabular-Paper“ ist. Sie behaupten nicht, das Problem der Kernel-Divergenz empirisch gelöst zu haben, sondern vielmehr den „fehlenden Index“ auf $\pi_\theta$ und das Vokabular bereitgestellt zu haben, um darüber zu diskutieren.
Zukünftige Richtungen: Das Paper skizziert vier Forschungsrichtungen: dynamische Contracts (kontextsensitive Schwellenwerte), Contract-aware Distillation (Modelle darauf trainieren, Contracts zu erfüllen), formale Verifikation von Klausel-Teilmengen und Self-healing Routing.
Limitierungen: Das Framework erhöht den Engineering-Overhead (Rechenaufwand, Speicherung, Observability) und birgt Risiken von Goodharts Gesetz (Optimierung von Proxy-Klauseln). Es räumt ein, dass aktuelle Werkzeuge der formalen Verifikation noch nicht in der Lage sind, volle Produktions-Transformer zu skalieren, und stützt sich statenweise auf lose Schranken und empirisches Testen.

Zusammenfassend argumentiert das Paper, dass die Behandlung der Trainings- und Inferenz-Kernel als distinkte, contract-gebundene Entitäten notwendig ist, um von dem „Folk Knowledge“ über die Fragilität von Implementierungen zu einem auditierbaren, reproduzierbaren Engineering-Praktikum beim LLM-Deployment überzugehen.