Trusting What You Cannot See: Auditable Fine-Tuning and Inference for Proprietary AI

Die Arbeit stellt AFTUNE vor, ein Framework, das durch leichte Aufzeichnung und Stichprobenprüfungen die Integrität von Fine-Tuning und Inferenz proprietärer KI-Modelle in der Cloud nachweisbar und überprüfbar macht, ohne dabei einen unpraktischen Rechenaufwand zu verursachen.

Das Wesentliche

Stell dir vor, du bist ein Koch, der ein geheimes Familienrezept (dein KI-Modell) besitzt, aber du hast keine eigene Küche. Du mietest stattdessen eine riesige, professionelle Küche bei einem Cloud-Anbieter, um dein Gericht für viele Leute vorzubereiten.

Das Problem: Du gibst dem Küchenchef (dem Cloud-Anbieter) deine Zutaten und das Rezept. Aber du kannst nicht in die Küche schauen. Wie kannst du sicher sein, dass er:

1. Das Rezept wirklich genau befolgt hat?
2. Nicht einfach billige Ersatzzutaten benutzt hat?
3. Nicht heimlich Gift in das Essen gemischt hat, damit es später schmeckt, wie er will?

Bisher gab es zwei Möglichkeiten, das zu überprüfen, aber beide waren unpraktisch:

• Die "Alles-überprüfen"-Methode: Du stellst einen Wachmann in jede Ecke der Küche. Das kostet aber so viel Zeit und Geld, dass das Essen nie fertig wird.
• Die "Alles-übergeben"-Methode: Du gibst dem Chef dein geheimes Rezept. Das willst du aber nicht, weil es dann gestohlen werden könnte.

AFTUNE ist wie ein geniales neues System für diese Küche, das beides löst: Es ist sicher, aber es stört den Koch nicht.

Wie funktioniert AFTUNE? (Die Analogie)

Stell dir vor, der Koch muss einen riesigen Berg von Aufgaben erledigen (das Trainieren der KI). Anstatt jeden einzelnen Schritt zu überwachen, teilt AFTUNE den Berg in kleine, überschaubare Kästen (Blöcke) auf.

1. Die "Grenzsteine" (Boundary States)
An den Rändern jedes Kastens (z. B. nach jedem 4. Schritt oder nach jedem 4. Stockwerk im Gebäude) macht der Koch einen Foto-Abdruck (einen Hash) von dem, was gerade passiert ist.

• Beispiel: Er sagt: "Nach Schritt 4 sah das Essen so aus: Suppe war gelb und heiß." Er schreibt das auf und verschlüsselt es.
• Wichtig: Er muss nicht das ganze Rezept oder den ganzen Kochprozess offenlegen, nur diese kleinen "Grenzsteine".

2. Der "Geheime Prüfer" (TEE)
Der Cloud-Anbieter hat einen kleinen, unsichtbaren und unzerstörbaren Safe (einen TEE – Trusted Execution Environment). Wenn du (der Kunde) später überprüfen willst, ob der Koch ehrlich war, sagst du: "Ich will den Kasten zwischen Schritt 10 und 20 überprüfen."

Der Anbieter schickt nur diesen kleinen Kasten in den Safe. Dort rechnet der Safe die Schritte noch einmal durch, aber nur für diesen kleinen Teil.

• Wenn das Ergebnis im Safe mit dem Foto-Abdruck übereinstimmt, war der Koch ehrlich.
• Wenn es nicht übereinstimmt, hat er geschummelt.

3. Das "Zufalls-Spiel" (Sampling)
Du musst nicht jeden einzelnen Kasten überprüfen. Das wäre zu viel Arbeit. Stattdessen wählst du zufällig ein paar Kästen aus.

• Die Logik: Wenn der Koch schummelt, weiß er nicht, welche Kästen du später überprüfen wirst. Wenn er auch nur in einem Kasten schummelt, hast du eine Chance, ihn zu erwischen. Da er nicht weiß, wo du hinschaust, traut er sich gar nicht erst, zu schummeln. Es ist wie bei einer Polizei, die zufällige Kontrollen macht – die Fahrer halten sich trotzdem an die Regeln, weil sie Angst haben, erwischt zu werden.

Warum ist das so cool?

• Es ist schnell: Der Koch kann in seiner normalen, schnellen Küche arbeiten. Er muss nicht warten, bis der Wachmann jeden Schritt genehmigt hat.
• Es ist geheim: Dein geheimes Rezept bleibt im Safe des Anbieters. Niemand sieht die genauen Gewürzmengen (die KI-Parameter).
• Es ist billig: Du musst nicht den ganzen Prozess speichern, sondern nur die kleinen "Grenzsteine". Wenn du einen Kasten überprüfen willst, kann der Anbieter den Rest sogar löschen, um Platz zu sparen.

Zusammenfassung für den Alltag

AFTUNE ist wie ein digitaler "Schwarzer Kasten" für KI-Modelle in der Cloud. Es erlaubt dir, einem fremden Anbieter zu vertrauen, ohne ihm blind zu vertrauen. Es nutzt kleine, zufällige Stichproben und geheime, sichere Taschenrechner (Safes), um sicherzustellen, dass die KI genau das tut, wofür du bezahlt hast – ohne dass du dein geistiges Eigentum preisgeben musst oder die Leistung der KI leidet.

Es verwandelt den undurchsichtigen "Black Box"-Service in eine transparente, überprüfbare Küche, in der du sicher sein kannst: Das Essen ist so, wie es sein soll.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Trusting What You Cannot See: Auditable Fine-Tuning and Inference for Proprietary AI" auf Deutsch.

1. Problemstellung

Cloud-Infrastrukturen sind zum dominanten Plattform für das Fine-Tuning und die Inferenz großer Sprachmodelle (LLMs) geworden. Dies schafft jedoch eine fundamentale Vertrauenslücke:

• Fehlende Transparenz: Kunden können nicht unabhängig überprüfen, ob der Cloud-Anbieter die Fine-Tuning- und Inferenzprozesse gemäß der vertraglichen Vereinbarung (Daten, Hyperparameter, Modellarchitektur) ausführt.
• Risiko von Missbrauch: Unvertrauenswürdige Anbieter könnten den Dienst abschwächen, Bias einfügen, Hintertüren (Backdoors) installieren oder während der Inferenz das falsche Modell verwenden, ohne dass der Kunde dies bemerkt.
• Limitationen bestehender Lösungen:
  • Zero-Knowledge Proofs (ZKP): Bieten zwar mathematische Integrität, verursachen aber bei großen Modellen einen prohibitiven Rechenaufwand (oft tausendfach langsamer als Standardausführung).
  • Trusted Execution Environments (TEE): Herkömmliche Ansätze, die den gesamten Trainings- oder Inferenzprozess in einem TEE (z. B. Intel SGX) ausführen, scheitern an den Speicherbeschränkungen moderner LLMs. Fine-Tuning erfordert zudem zusätzliche Zustände (Optimierer-Momente, Gradienten), die den Speicherbedarf weiter erhöhen als bei der reinen Inferenz.

2. Methodik: AFTUNE Framework

Das Paper stellt AFTUNE vor, ein Framework, das die Integrität von Cloud-basiertem Fine-Tuning und Inferenz durch eine Kombination aus Block-Decomposition, kryptografischen Commitments und TEE-basierter Stichprobenprüfung gewährleistet.

A. Zweidimensionale Block-Struktur

Anstatt jeden Schritt jeder Schicht zu protokollieren (was zu enormen Speicherkosten führen würde), unterteilt AFTUNE den Trainingsprozess in ein zweidimensionales Gitter aus Blöcken:

• Layer-Blöcke: Aufeinanderfolgende Schichten des Modells werden gruppiert.
• Step-Blöcke: Aufeinanderfolgende Trainingsschritte werden gruppiert.
• Grenzzustände (Boundary States): Es werden nur die Zustände an den Rändern dieser Blöcke aufgezeichnet:
  • Aktivierungen und Gradienten an den Kanten der Layer-Blöcke.
  • Parameter und Optimierer-Zustände an den Grenzen der Step-Blöcke.
• Prinzip der Zusammensetzbarkeit: Da die Ausgabe eines Blocks die Eingabe des nächsten ist, können Blöcke unabhängig voneinander verifiziert werden. Die Korrektheit des gesamten Prozesses ergibt sich aus der Konsistenz dieser Grenzpunkte.

B. Map-Reduce Hashing-Schema

Um die Overhead-Kosten für die Erstellung von Commitments zu minimieren:

• Große Tensoren werden in Chunks partitioniert.
• Die Hash-Berechnung (z. B. BLAKE3) erfolgt parallel auf den Beschleunigern (GPUs) für alle Chunks.
• Die Ergebnisse werden zu einem einzigen Commitment aggregiert. Dies verhindert, dass die Hash-Berechnung zum Flaschenhals für den Trainingsdurchsatz wird.

C. Stichprobenbasierte Verifizierung (Spot-Checking)

Der Kunde muss nicht jeden Block verifizieren, sondern wählt zufällige Blöcke aus:

1. Der Anbieter speichert die Hashes der Grenzzustände.
2. Der Kunde fordert die Verifizierung bestimmter Blöcke an.
3. Der Anbieter lädt diese spezifischen Blöcke in ein TEE (auf der Anbieterseite).
4. Das TEE rechnet den Block unter Verwendung der gespeicherten Randzustände und der Modellparameter neu durch.
5. Die neu berechneten Werte werden mit den gespeicherten Hashes verglichen (Hash-Matching für Integrität, numerische Toleranz für Floating-Point-Genauigkeit).

D. Speicheroptimierung

AFTUNE unterstützt Sparse Checkpointing. Statt Parameter bei jedem Schritt zu speichern, werden sie nur in Intervallen gespeichert. Fehlende Zwischenzustände können zur Verifizierung durch Nachberechnung (Recomputation) aus den nächsten gespeicherten Checkpoints rekonstruiert werden. Dies ermöglicht einen Trade-off zwischen Speicherkosten und Rechenzeit bei der Verifizierung.

3. Hauptbeiträge

1. AFTUNE Framework: Ein verifizierbares System für Fine-Tuning und Inferenz proprietärer Modelle, das die Verifizierung vom eigentlichen Trainingsprozess entkoppelt.
2. Effiziente Verifizierungsstrategie: Einführung einer stichprobenbasierten Verifizierung mit probabilistischen Nachweisgarantien und einem Map-Reduce-Hashing-Schema für effiziente Commitment-Generierung.
3. Implementierung und Evaluation: Integration in CUDA-basierte Pipelines und Evaluation auf echter TEE-Hardware (Intel SGX/TDX) mit verschiedenen Open-Source-Modellen (Llama-3.1, Qwen2.5, DINOv2, ViT).

4. Ergebnisse und Evaluation

Die Evaluation zeigt, dass AFTUNE praktikable Overhead-Kosten bei gleichzeitig hoher Sicherheit bietet:

• Performance-Overhead: Im Vergleich zu einem vollständigen TEE-Ansatz (der oft unmöglich ist) oder ZKP-basierten Methoden ist der Overhead gering.
  • Bei Fine-Tuning von Llama-3.1-8B lag der Overhead bei ca. 18–21 % (abhängig von der Blockgröße).
  • Bei Inferenz lag der Latenz-Overhead bei nur 8–14 %.
• Speichereffizienz: Durch die Block-Struktur und Sparse Checkpointing wurden die Speicherkosten im Vergleich zu einem Schritt-für-Schritt-Verfahren um mehr als die Hälfte reduziert.
• Verifizierungsgenauigkeit:
  • Die numerischen Fehler durch Nachberechnung blieben innerhalb akzeptabler Toleranzen (bei Verwendung von float32 oder float64).
  • Sicherheitsanalyse: Die Autoren zeigten, dass Angriffe, die versuchen, die numerischen Toleranzen auszunutzen (z. B. durch kleine Perturbationen von Aktivierungen oder Gewichten), bei Verwendung von bfloat16 riskant sind, da die Fehlergrenzen zu groß sind. Mit float32 oder höher ist jedoch eine klare Trennung zwischen legitimen Rechenfehlern und böswilligen Manipulationen möglich.
• Detektionswahrscheinlichkeit: Selbst bei Stichprobenverifizierung (z. B. Prüfung von 1 % der Blöcke) ist die Wahrscheinlichkeit, einen Angreifer zu entlarven, der 10 % der Blöcke manipuliert hat, hoch (ca. 65 %). Bei wiederholten Audits steigt diese Wahrscheinlichkeit gegen 100 %.

5. Bedeutung und Fazit

AFTUNE adressiert ein kritisches Problem im Bereich der Cloud-KI: Wie man Vertrauen in proprietäre Modelle schafft, ohne die Geschäftsgeheimnisse (Modellgewichte) preiszugeben oder die Leistung massiv zu beeinträchtigen.

• Paradigmenwechsel: Statt den gesamten Prozess in einem TEE zu isolieren (was bei großen Modellen nicht geht), wird das Vertrauen durch kryptografische Bindungen an Grenzzustände und nachträgliche, selektive Nachberechnung in einem TEE hergestellt.
• Praktische Anwendbarkeit: Das System ist kompatibel mit bestehenden ML-Infrastrukturen und erfordert keine Änderungen an den Beschleunigern oder Frameworks, sondern nutzt vorhandene CPU-TEE-Infrastruktur für die Verifizierung.
• Vertrauensbildung: Es ermöglicht Kunden, die Integrität von Fine-Tuning und Inferenz zu überprüfen, was Missbrauch durch Cloud-Anbieter (wie Datenvergiftung oder Modellsubstitution) effektiv verhindert oder aufdeckt.

Zusammenfassend demonstriert AFTUNE, dass vertrauenswürdige KI-Dienste in heutigen Cloud-Umgebungen realisierbar sind, indem Transparenz durch verifizierbare Beweise statt durch blindes Vertrauen in den Anbieter hergestellt wird.