🤖 AI

FuseFSS: Efficient Secure LLM Inference with Function Secret Sharing

FuseFSS ist ein Compiler, der die sichere LLM-Inferenz durch den Ersatz maßgeschneiderter Protokolle pro Operator durch eine einheitliche Pipeline für Fixed-Point-Nichtlinearitäten optimiert und dabei signifikante Geschwindigkeitssteigerungen sowie reduzierten Kommunikations- und Vorverarbeitungsaufwand bei gleichbleibender Genauigkeit erzielt.

Ursprüngliche Autoren: Yuhan Ma, Yong Li, Stefan Schmid

Veröffentlicht 2026-06-09

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yuhan Ma, Yong Li, Stefan Schmid

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 möchten einer superintelligenten KI (einem Large Language Model) eine geheime Frage stellen, wie etwa eine private medizinische Diagnose oder eine vertrauliche Geschäftsstrategie. Sie möchten nicht, dass der Besitzer der KI Ihre Frage sieht, und Sie möchten auch nicht, dass die KI ihr „Gehirn“ (das Modell) vor Ihnen preisgibt.

Um dies zu lösen, nutzen Forscher einen „Zwei-Server“-Trick. Sie teilen das Geheimnis zwischen zwei Servern auf, die nicht miteinander kommunizieren. Keiner der beiden Server kennt das vollständige Bild, aber zusammen können sie die Antwort berechnen. Das ist so, als würden zwei Köche in getrennten Küchen arbeiten; sie können weder die Zutaten des jeweils anderen sehen, noch können sie gemeinsam einen Kuchen backen, ohne das Rezept oder die geheime Zutat preiszugeben.

Doch es gibt ein Problem. Während die „einfachen“ mathematischen Teile (wie das Addieren von Zahlen) in diesem geheimen Modus schnell ablaufen, sind die „schwierigen“ Teile (wie die Entscheidung, ob eine Zahl positiv oder negativ ist, oder das Runden von Dezimalzahlen) langsam und umständlich. Derzeit müssen Ingenieure für jeden dieser schwierigen mathematischen Schritte eine maßgeschneiderte, einzigartige Maschine bauen. Es ist, als müsste man für jede einzelne Schraube in einem Auto einen speziellen, maßgeschneiderten Schraubenschlüssel anfertigen. Das ist teuer, langsam und leicht beschädigbar.

Hier kommt FuseFSS ins Spiel.

Die Autoren dieser Arbeit haben einen Compiler (einen Übersetzer) namens FuseFSS entwickelt. Anstatt für jede Schraube einen maßgeschneiderten Schraubenschlüssel zu bauen, sagt FuseFSS: „Lassen Sie uns einfach zwei universelle Werkzeuge für alle schwierigen mathematischen Schritte verwenden.“

So funktioniert es, erklärt mit einer einfachen Analogie:

Die „Maskierte Umschlag“-Analogie

Stellen Sie sich vor, Sie haben eine geheime Zahl, können sie aber nicht direkt zeigen. Also legen Sie sie in einen Umschlag zusammen mit einem Stück Papier (der „Maske“) und übergeben diesen den Servern. Die Server können das Gesamtgewicht des Umschlags (den „maskierten Wert“) sehen, wissen aber weder Ihre geheime Zahl noch das zufällige Papier im Inneren.

Auf dem alten Weg (dem „Sigma“-System) mussten die Server jedes Mal, wenn sie einen komplexen mathematischen Trick anwandten (wie „Ist diese Zahl größer als 5?“), eine spezifische, maßgeschneiderte Protokoll-Box nur für diese eine Frage öffnen.

FuseFSS ändert die Spielregeln:

Eine Spezifikation: Die Autoren haben eine standardisierte „Bedienungsanleitung“ für jeden mathematischen Trick erstellt. Sie beschreiben den Trick als eine Menge von Zonen (Intervallen) und einfachen Formeln.
Zwei magische Werkzeuge: Anstatt neue Boxen zu bauen, nutzt FuseFSS für jeden Trick einfach nur zwei Standardwerkzeuge:
- Werkzeug A (Der Komparator): Dieser prüft alle „Ist es größer als X?“-Fragen gleichzeitig und liefert den Servern eine Liste von „Ja/Nein“-Antworten (die geheim geteilt werden).
- Werkzeug B (Der Lookup): Dieser fungt wie ein Verkaufsautomat. Basierend auf den Antworten von Werkzeug A liefert er sofort die richtigen Zahlen und Formeln aus, die benötigt werden, um die Berechnung abzuschließen.
Das Ergebnis: Die Server führen die Mathematik durch und ziehen dann das zufällige Papier (die Maske) ab, um das endgültige Ergebnis zu enthüllen.

Warum ist das eine große Sache?

Die Arbeit behauptet, dass durch den Wechsel von „maßgeschneiderten Schraubenschlüsseln“ zu diesen „zwei universellen Werkzeugen“ der Prozess signifikant schneller und leichter geworden ist.

Geschwindigkeit: Sie haben den gesamten Prozess 1,24- bis 1,5-mal schneller gemacht. Wenn eine Berechnung früher 10 Sekunden dauerte, dauert sie jetzt etwa 7 Sekunden.
Weniger Kommunikation: Die beiden Server müssen weniger Daten hin und her senden (etwa 9 % bis 16 % weniger).
Weniger Vorbereitung: Bevor sie überhaupt beginnen, müssen sie einige „Schlüssel“ generieren (so ähnlich wie das Anbringen von Schlössern an den Umschlägen). FuseFSS macht diesen Setup 14 % bis 23 % schneller und die Schlüssel selbst sind 20 % bis 24 % kleiner.

Das Fazit

Die Arbeit behauptet nicht, eine neue Art von KI oder eine neue Methode zur Börsenprognose erfunden zu haben. Sie behauptet lediglich, einen besseren „Motor“ für das sichere Ausführen bestehender KI-Modelle gebaut zu haben.

Sie haben dies an populären KI-Modellen (wie BERT und GPT) getestet und festgestellt, dass es genauso genau arbeitet wie die alten Methoden, aber viel reibungsloser läuft. Es ist wie die Aufrüstung eines Automotors: Das Auto fährt die gleiche Geschwindigkeit und transportiert die gleichen Passagiere, aber der Motor ist effizienter gestaltet, wodurch das Auto einen besseren Kraftstoffverbrauch hat und schneller beschleunigt.

Kurz gesagt: FuseFSS ist ein Compiler, der einen unordentlichen, maßgeschneiderten Prozess für geheime KI-Mathematik in eine saubere, standardisierte und viel schnellere Routine verwandelt, indem er nur zwei leistungsstarke, wiederverwendbare Werkzeuge nutzt.

Technisches Resümee: FuseFSS

Problemstellung

Bei der Zwei-Server-Sicheren Inferenz für Large Language Models (LLMs) können Clients Modelle hosten, ohne ihre Prompts oder Embeddings preiszugeben, indem die Eingaben mittels Secret-Sharing zwischen nicht kolludierenden Servern aufgeteilt werden. Während jüngste GPU-basierte Systeme unter Verwendung von Function Secret Sharing (FSS) lineare Schichten effizient gestaltet haben, bleiben signifikante Engpässe bei festkomma-basierten Nichtlinearitäten (z. B. Aktivierungen wie GELU, Softmax-Komponenten) und Rescaling-Operationen bestehen.

Der aktuelle Stand der Technik (z. B. Sigma) stützt sich auf maßgeschneiderte, operatorspezifische Protokolle. Jeder Operator erfordert eine eigene Implementierung, die spezifische Vergleiche, Wrap-around-Korrekturen und Preprocessing-Material umfasst. Dieser Ansatz ist fragil: Er erschwert Korrektheitsbeweise, dupliziert die Logik zur Schlüsselgenerierung und macht das Hinzufügen neuer Operatoren schwierig, ohne subtile Fehler im Zusammenhang mit Modulo- $2^n$ -Wrap-around oder Vorzeichenbehandlung einzuführen. Darüber hinaus führen diese maßgeschneiderten Protokolle oft zu einem hohen Online-Kommunikationsaufwand und hohen Preprocessing-Kosten (Schlüsselgenerierungszeit und -größe).

Methodik: FuseFSS

Die Autoren präsentieren FuseFSS, einen Compiler, der die Entwicklung von pro-Operator-Protokollen durch eine einheitliche, GPU-freundliche Kompilationspipeline ersetzt. Die zentrale Erkenntnis ist, dass die datenabhängige Logik über gängige Festkomma-Nichtlinearitäten hinweg einem ähnlichen Muster folgt: der Auswahl eines Bereichs mithilfe einer kleinen Menge von Prädikat-Bits und der anschließenden Anwendung einer niedergradigen arithmetischen Form mit einer geringen Anzahl von Konstanten.

1. Operator-Spezifikationen

FuseFSS führt eine typisierte Operator-Spezifikation ein, die als Zwischenrepräsentation (IR) für elementweise Festkomma-Operatoren dient. Eine Spezifikation definiert:

Intervall-Partition: Eine vollständige Partition der kanonischen Repräsentanten von $\mathbb{Z}_{2^n}$ in Intervalle $I_i = [\alpha_i, \alpha_{i+1})$ .
Arithmetische Stücke: Für jedes Intervall einen Vektor von niedergradigen Polynomen $P_i(x)$ , um die arithmetische Ausgabe zu berechnen.
Prädikat-Bits: Boolesche Formeln $B_i(x)$ , die aus primitiven Prädikaten (z. B. $x < \beta$ ) aufgebaut sind, um zu bestimmen, welches Intervall aktiv ist.

2. Masken-bewusste Kompilierung (Mask-Aware Compilation)

Der Compiler übersetzt diese Spezifikationen in ein einheitliches Protokoll, das auf einem öffentlichen maskierten Wert $\hat{x} = x + r_{in} \pmod{2^n}$ operiert, wobei $r_{in}$ eine frische, secret-shared Maske ist, die während des Preprocessings gezogen wurde.

Prädikat-Umschreibung: Der Compiler schreibt Prädikate auf den geheimen Input $x$ in Vergleiche auf den öffentlichen $\hat{x}$ um, wobei secret-shared Carry-Bits verwendet werden, die aus der Maske $r_{in}$ abgeleitet wurden, um den Modulo-Wrap-around korrekt zu handhaben.
Einheitliche Struktur: Unabhängig vom spezifischen Operator emittiert der Compiler exakt zwei Standard-FSS-Evaluierungen auf dem öffentlichen $\hat{x}$ $\overset{x}{^}$ :
1. Gepackter Vergleich (Packed Comparison): Eine einzige Evaluierung, die die XOR-Shares aller erforderlichen Prädikat-Bits zurückgibt (Intervall-Indikatoren).
2. Vektor-Intervall-Lookup: Eine einzige Evaluierung, die die additiven Shares der aktiven Polynomkoeffizienten und Konstanten für das ausgewählte Intervall zurückgibt.

3. Post-Processing

Die verbleibende Berechnung ist ein fester, Share-basierter Post-Processing-Schaltkreis. Dieser umfasst:

Horner-Schema: Die Evaluierung des ausgewählten niedergradigen Polynoms auf den geheimen Shares von $x$ (abgeleitet aus $\hat{x}$ und $r_{in}$ ) unter Verwendung von Beaver-Triples.
Hilfsoperationen: Anwendung von boolescher Logik (XOR, AND) und Mixed-Domain-Konvertierungen (B2A/A2B), um arithmetische und boolesche Ergebnisse zu kombinieren.
Spezifikationskompatible Gates: Für Operationen, die nicht rein polynomiell sein können (z. B. Truncation, arithmetische Rechtsverschiebungen), fügt der Compiler einen deterministischen Post-Processing-Schaltkreis $\Phi$ hinzu, der den Polynom-Output und die maskenabgeleiteten Konstanten nutzt, um das Endergebnis zu erzeugen.

4. Sicherheit und Leakage

FuseFSS hält sich an die Masked-Wire-Semantik, die frische, unabhängige Masken pro Wire sicherstellt. Entscheidend ist, dass der Compiler maskenunabhängige öffentliche Formen (public shapes) erzwingt. Die Anzahl der Vergleiche, Bitbreiten und die Dimensionen des Intervall-Lookups hängen nur von der öffentlichen Operator-Spezifikation und den Festkomma-Metadaten ab, nicht von den gezogenen Masken. Dies verhindert das Durchsickern (Leakage) geheimer Informationen durch Schlüsselgrößen oder Instanzformen. Das Sicherheitsmodell setzt einen Semi-Honest-Adversary in einem Zwei-Server-Preprocessing-Szenario voraus.

Kernbeiträge

State-of-the-Art Performance: FuseFSS erreicht die am besten berichtete End-to-End-Performance für FSS-basierte sichere Inferenz auf BERT- und GPT-ähnlichen Modellen, wobei es die Latenz verbessert und die Preprocessing-Kosten senkt, während die Modellgenauigkeit beibehalten wird.
Praktisches Compiler-Target: Es zeigt, dass eine breite Palette von Festkomma-Skalar-Operatoren unter einem einzigen Spezifikationsformat vereinheitlicht werden kann, die über zwei Standard-FSS-Aufrufe plus einheitliches Post-Processing ausgeführt werden, wodurch die Notwendigkeit für maßgeschneiderte Protokolldesigns entfällt.
Masken-bewusste Kompilierung mit Sicherheit: Das System leitet korrekte Prädikat-Evaluierungen aus öffentlichen maskierten Inputs ab und erzwingt gleichzeitig Form-Invarianz, was eine einheitliche Korrektheits- und Semi-Honest-Sicherheitsbewertung über verschiedene Operatoren hinweg ermöglicht.

Experimentelle Ergebnisse

Die Autoren evaluierten FuseFSS gegen Sigma, den aktuellen FSS-basierten State-of-the-Art-Baseline, auf BERT- und GPT-ähnlichen Modellen (einschließlich BERT-tiny/base/large, GPT-2 und GPT-Neo) mit Sequenzlänge 128 und Batchgröße 1.

End-to-End Beschleunigung: FuseFSS erreicht eine 1,24×–1,50× Beschleunigung in der Online-Latenz. Beispielsweise sank die BERT-base-128 Inferenzzeit von 1613,80 ms (Sigma) auf 1149,50 ms (FuseFSS), was einer Reduktion um 28,8 % entspricht.
Reduktion der Kommunikation: Die Online-Kommunikation wird um 9 %–16 % reduziert.
Effizienz des Preprocessings:
- Schlüsselgenerierungszeit: Reduziert um 14 %–23 %.
- Schlüsselgröße: Reduziert um 20 %–24 %.
Skalierbarkeit: Die Beschleunigung bleibt mit zunehmender Sequenzlänge von 32 auf 512 konsistent (1,36×–1,45×).
Attribution: Die Gewinne werden primär durch die Beschleunigung der Skalar-Nichtlinearitäten und Hilfsblöcke (z. B. GELU, Softmax-Komponenten) getrieben, welche den Großteil der Latenz in der Baseline ausmachen. Beispielsweise sah der kompilierte Pfad für Softmax (nExp + Reziprok) eine 4,5×–4,7× Beschleunigung.

Bedeutung und Ansprüche

Das Paper behauptet, dass FuseFSS den primären Engpass der Zwei-Server-Sicheren Inferenz adressiert: die Engineering-Komplexität und den Performance-Overhead von Festkomma-Nichtlinearitäten. Durch den Wechsel von maßgeschneiderten Pro-Operator-Protokollen zu einer einheitlichen Kompilationspipeline vereinfacht FuseFSS das Systemdesign, verbessert die Korrektheitsgarantien und reduziert sowohl die Online- als auch die Offline-Kosten signifikant.

Die Autoren positionieren FuseFSS als praktische Lösung für den Einsatz von datenschutzwahrender LLM-Inferenz in Umgebungen, die eine starke Vertraulichkeit für Prompts und Embeddings erfordern (z. B. Gesundheitswesen, Finanzwesen). Sie merken explizit an, dass sich ihre Arbeit auf Skalar-Nichtlinearitäten konzentriert; Vektor-Operationen (wie Reduktionen oder Attention-Sparsification) liegen außerhalb der Operator-Spezifikations-IR und werden durch Standard-MPC-Subprotokolle gehandhabt. Die Sicherheitsanalyse beschränkt sich auf das Semi-Honest-Modell mit zwei nicht-kolludierenden Servern und räumt ein, dass die Erweiterung auf stärkere Adversarial-Modelle eine zukünftige Richtung darstellt.