🤖 AI

IMMACULATE: A Practical LLM Auditing Framework via Verifiable Computation

Die Arbeit stellt IMMACULATE vor, ein praktisches Framework zur Überprüfung kommerzieller Large Language Models, das mithilfe verifizierbarer Berechnungen betrügerische Abweichungen wie Modellsubstitution oder Token-Überabrechnung ohne vertrauenswürdige Hardware erkennt und dabei den Durchsatz um weniger als 1 % beeinträchtigt.

Ursprüngliche Autoren: Yanpei Guo, Wenjie Qu, Linyu Wu, Shengfang Zhai, Lionel Z. Wang, Ming Xu, Yue Liu, Binhang Yuan, Dawn Song, Jiaheng Zhang

Veröffentlicht 2026-02-27

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yanpei Guo, Wenjie Qu, Linyu Wu, Shengfang Zhai, Lionel Z. Wang, Ming Xu, Yue Liu, Binhang Yuan, Dawn Song, Jiaheng Zhang

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

Stell dir vor, du bestellst jeden Tag ein riesiges, komplexes Essen in einem Restaurant, das du nie betreten darfst. Du zahlst für ein "5-Sterne-Menü" mit dem besten Steak der Welt, aber der Koch (der KI-Anbieter) sitzt hinter einer verschlossenen Tür. Du bekommst nur das fertige Gericht auf einem Teller.

Das Problem? Der Koch könnte dir in Wahrheit ein billiges Hackfleisch-Schnitzel servieren, das er nur so aussehen lässt wie das teure Steak. Oder er könnte behaupten, er habe 100 Gramm Fleisch verwendet, obwohl er nur 10 Gramm nahm, und dich trotzdem für 100 Gramm bezahlen. Da du die Küche nicht betreten darfst, kannst du das kaum überprüfen.

Das ist genau das Problem mit KI-Modellen (LLMs) heute: Wir nutzen sie über eine Art "Blackbox", vertrauen aber blind darauf, dass der Anbieter das Versprochene auch wirklich liefert.

Die Forscher haben IMMACULATE entwickelt. Das ist wie ein genialer, unsichtbarer Lebensmittelinspektor, der das Restaurant überprüft, ohne die Küche zu betreten oder den Koch zu stören.

Hier ist, wie es funktioniert, mit ein paar einfachen Vergleichen:

1. Der Trick: Nicht jeden Gast kontrollieren

Früher dachte man: "Um sicherzugehen, müssen wir jeden einzelnen Teller überprüfen." Das wäre aber extrem teuer und langsam.
IMMACULATE nutzt einen cleveren statistischen Trick: Der Inspektor wählt zufällig nur einen von tausend Teller aus.

Wenn der Koch fair spielt, passiert nichts.
Wenn der Koch aber oft (z. B. bei 10 % der Teller) schummelt, wird er bei der zufälligen Kontrolle fast sicher erwischt.
Das ist wie bei einer Polizei, die nicht jeden Autofahrer anhalten kann, aber durch zufällige Kontrollen sicherstellt, dass niemand ständig mit 200 km/h fährt.

2. Der "Fingerabdruck" der Mathematik (LDD)

Das Schwierige an KI ist: Selbst wenn der Koch das richtige Rezept benutzt, kann das Essen durch winzige Unterschiede in der Zubereitung (z. B. "ein bisschen mehr Hitze") minimal anders schmecken. Das ist normal. Aber wenn er ein falsches Rezept nimmt, schmeckt es komplett anders.

IMMACULATE nutzt eine Methode namens LDD (Logit Distance Distribution). Stell dir das so vor:

Der Inspektor hat eine perfekte Referenz-Karte (das ideale Rezept).
Er schaut sich nicht das fertige Essen an, sondern die Zwischenschritte der Zubereitung (die "Logits").
Er vergleicht: "Weicht der Weg, den der Koch gegangen ist, nur ein winziges bisschen von meinem perfekten Rezept ab (wegen normaler Ungenauigkeit)?" oder "Weicht er so stark ab, als hätte er ein ganz anderes Rezept benutzt?"

Wenn der Koch das billige Hackfleisch (ein anderes Modell) nimmt oder die Hitze zu stark drosselt (Quantisierung), ist der "Geschmacksunterschied" in den Zwischenschritten so groß, dass er sofort auffällt.

3. Der Beweis ohne Einbruch

Wie kann der Inspektor sicher sein, dass der Koch nicht einfach eine gefälschte Karte vorlegt?
Hier kommt Verifiable Computation (überprüfbare Berechnung) ins Spiel.
Stell dir vor, der Koch muss einen mathematischen Beweis liefern, der zeigt: "Ich habe tatsächlich diesen spezifischen Weg gegangen."

Der Koch kann diesen Beweis nicht fälschen, ohne extrem viel Zeit und Energie zu verschwenden (so viel, dass es sich für ihn nicht lohnt).
Der Inspektor kann den Beweis in Sekunden prüfen.
Wichtig: Der Koch muss sein geheimes Rezept (die KI-Parameter) nicht preisgeben. Er beweist nur, dass er es benutzt hat.

4. Warum ist das so wichtig?

Aktuell gibt es zwei Probleme:

Vertrauenskrise: Anbieter könnten heimlich billigere Modelle nutzen, um Kosten zu sparen, oder die Rechnung für die "Rechenleistung" (Tokens) manipulieren.
Technische Hürden: Bisherige Methoden waren entweder zu teuer (benötigten spezielle, teure Hardware) oder zu langsam (mussten alles neu berechnen).

IMMACULATE löst das:

Es ist günstig: Da nur sehr wenige Anfragen geprüft werden, verlangsamt es das Restaurant kaum (weniger als 1 % langsamer).
Es ist sicher: Es findet Betrug fast immer, wenn er häufig genug passiert.
Es ist diskret: Der Anbieter muss seine Geheimnisse nicht verraten.

Zusammenfassung

IMMACULATE ist wie ein unsichtbarer, mathematisch brillanter Inspektor für KI-Restaurants. Er überprüft zufällig, ob der Koch das versprochene Menü serviert, ohne die Küche zu betreten, ohne die Geheimnisse des Kochs zu stehlen und ohne den Service für die anderen Gäste zu verlangsamen. Es stellt sicher, dass wir für das bekommen, wofür wir bezahlen – und dass die KI ehrlich bleibt.

1. Problemstellung

Kommerzielle Large Language Models (LLMs) werden meist als Black-Box-APIs bereitgestellt. Dies schafft ein fundamentales Vertrauensungleichgewicht: Nutzer müssen darauf vertrauen, dass Anbieter die Inferenz korrekt durchführen und den Token-Verbrauch ehrlich abrechnen. Es bestehen jedoch erhebliche Anreize für Anbieter, vom beworbenen Protokoll abzuweichen, um Kosten zu senken oder Einnahmen zu steigern. Zu den Hauptbedrohungen gehören:

Modellersatz (Model Substitution): Nutzung eines kleineren, günstigeren Modells statt des beworbenen Modells.
Aggressive Quantisierung: Nutzung von niedrigerer Präzision (z. B. FP8 statt BF16), um Rechenleistung zu sparen, was die Modellqualität beeinträchtigen kann.
Token-Überabrechnung (Token Overbilling): Abrechnung von internen Tokens (z. B. Chain-of-Thought), die dem Nutzer nicht angezeigt werden.

Bestehende Lösungen haben gravierende Nachteile:

Vertrauenswürdige Ausführungsumgebungen (TEEs): Erfordern spezielle Hardware (z. B. NVIDIA GPUs), was die Skalierbarkeit und Kosten erhöht und proprietäre Infrastrukturen (wie TPUs) ausschließt.
Kryptografische Beweise (Zero-Knowledge Proofs): Sind oft auf deterministische Ganzzahl-Arithmetik beschränkt, was für moderne LLMs (die Gleitkommazahlen nutzen) ineffizient oder unpraktikabel ist.
Empirische Methoden: Fehlende formale Garantien und Anfälligkeit für adaptive Angriffe.

Das Ziel ist ein Auditierungsframework, das wirtschaftlich effizient ist, keine vertrauenswürdige Hardware benötigt, die Proprietätsrechte (Modellparameter) wahrt und dennoch starke mathematische Garantien gegen Betrug bietet.

2. Methodik: IMMACULATE

IMMACULATE löst das Problem durch eine Kombination aus stochastischer (zufälliger) Auditierung und verifizierbarer Berechnung (Verifiable Computation, VC), gestützt auf eine neue Metrik namens Logit Distance Distribution (LDD).

A. Zufällige Auditierung (Randomized Auditing)

Anstatt jeden einzelnen Request zu verifizieren (was zu hohe Kosten verursachen würde), prüft der Auditor nur eine kleine, zufällige Teilmenge der Anfragen.

Prinzip: Ein rationaler Anbieter, der auf einer signifikanten Menge von Anfragen (z. B. $\alpha = 10\%$ ) betrügt, wird mit überwältigender Wahrscheinlichkeit bei einer zufälligen Stichprobe auffliegen.
Effizienz: Der kryptografische Overhead wird auf wenige tausend Anfragen pro Tag amortisiert, während Milliarden von Anfragen normal bedient werden.

B. Logit Distance Distribution (LDD)

Da LLMs aufgrund von Gleitkomma-Nichtdeterminismus auf GPUs keine bitgenaue Reproduzierbarkeit garantieren, ist ein direkter Beweis der exakten Ausführung unmöglich.

Hybrides Rechenmodell: Das Paper abstrahiert die Inferenz in kontinuierliche Transformationen (Neuronale Netze) und diskrete Entscheidungen (Token-Auswahl).
Alignment: Der Server verpflichtet sich kryptografisch zu den Logits (Wahrscheinlichkeitsvektoren) vor der diskreten Entscheidung. Der Auditor kann so die diskreten Entscheidungen reproduzieren.
Metrik: Statt die Ausgabe zu vergleichen, wird die Distanz zwischen den Logits des ausgeführten Modells ( $\ell_i$ ) und den Logits eines idealen, vollpräzisen Referenzmodells ( $\ell^*_i$ ) gemessen.
Erkennungsmuster:
- Normale numerische Fehler: Erzeugen eine stabile, vorhersehbare Verteilung der Logit-Distanzen.
- Betrug (Modellersatz/Quantisierung): Erzeugen systematische Verzerrungen oder eine signifikant breitere Verteilung (schwere „Tails" in der Verteilung).

C. Verifizierbare Berechnung (VC)

Für die zufällig ausgewählten Anfragen muss der Server einen kryptografischen Beweis erbringen, dass:

Die diskreten Entscheidungen aus den commiteten Logits abgeleitet wurden.
Die kontinuierlichen Transformationen korrekt berechnet wurden.
Die Verteilung der Logit-Distanzen (LDD) innerhalb akzeptabler Grenzen liegt.

Dies geschieht ohne Offenlegung der Modellparameter (Privacy), da nur die Logits und der Beweis offengelegt werden.

3. Wichtige Beiträge

IMMACULATE Framework: Ein praktisches Auditierungsframework für Black-Box-LLMs, das keine GPU-TEEs benötigt und mit bestehender Infrastruktur kompatibel ist.
Logit Distance Distribution (LDD): Eine neue Metrik zur Quantifizierung der Approximationsgüte zwischen einem bereitgestellten Modell und einem Vollpräzisions-Referenzmodell. Sie ermöglicht Verifizierung trotz numerischer Nichtdeterministik.
Evidenzbasierte Effizienz: Demonstration, dass durch die Kombination von zufälliger Stichprobenprüfung und LDD-Verifizierung ein Overhead von unter 1 % erreicht werden kann, während gleichzeitig starke Sicherheitsgarantien bestehen.
Open Source: Veröffentlichung des Codes und der Implementierung auf Basis von vLLM.

4. Ergebnisse

Die Autoren evaluieren IMMACULATE an verschiedenen Modellen (LLaMA3-70B, Qwen3, DeepSeek-V2) und Angriffsszenarien (Modellersatz, FP8-Quantisierung).

Diskriminierungsfähigkeit: Die LDD zeigt klare Trennungen zwischen benignen (BF16) und bösartigen Ausführungen.
- Modellersatz: Führt zu einer massiven Verschiebung der Verteilung nach rechts (hohe Distanzen).
- Quantisierung (FP8): Erhöht die Wahrscheinlichkeit von „Tail-Events" (großen Distanzen) um Größenordnungen im Vergleich zu BF16.
Detektionsraten:
- Bei Modellersatz werden Anfragen mit einer Wahrscheinlichkeit von >40% (bis zu 99% je nach Modell) erkannt.
- Bei Quantisierungsangriffen liegt die Detektionswahrscheinlichkeit pro Anfrage bei ca. 1–10%.
Falsch-Positiv-Rate (False Positive): Durch die Anwendung der Extremwerttheorie (EVT) wird die Falsch-Positiv-Rate für legitime Anfragen auf $< 10^{-5}$ geschätzt.
Overhead:
- Der Durchsatzverlust für einen ehrlichen Server liegt bei unter 1% (z. B. 0,3% bis 1,0%).
- Der kryptografische Beweis (VC) auf einer CPU-TEE ist zwar hunderte Male langsamer als die GPU-Inferenz, aber da nur ein winziger Bruchteil der Anfragen ( $< 10^{-5}$ ) auditiert wird, ist der Gesamtkostenfaktor vernachlässigbar.

5. Bedeutung und Ausblick

IMMACULATE adressiert eine kritische Lücke im Vertrauen in kommerzielle LLM-Dienste. Es bietet einen Weg, um die Integrität von Inferenzdiensten zu gewährleisten, ohne dass Nutzer Zugriff auf proprietäre Modelle erhalten müssen oder dass Anbieter teure Hardware-Upgrades vornehmen müssen.

Vertrauen: Schafft eine Grundlage für transparente Abrechnung und Qualitätskontrolle in der KI-Ökonomie.
Skalierbarkeit: Da das Framework hardwareunabhängig ist und nur minimale Overheads verursacht, ist es für den Einsatz in großen Cloud-Infrastrukturen geeignet.
Zukunft: Das Paper ebnet den Weg für eine neue Klasse von Auditierungsframeworks, die auf probabilistischen Garantien und verifizierbaren Metriken basieren, anstatt auf reinem Vertrauen oder teurer Hardware.

Zusammenfassend stellt IMMACULATE einen praktischen Durchbruch dar, der die Lücke zwischen theoretischer Verifizierbarkeit und praktischer Anwendbarkeit bei Black-Box-LLMs schließt.