Leistung

Gemessen, nicht versprochen.

Der Gateway-Overhead, gemessen auf identischer Hardware vor einem Keep-Alive-Upstream, jeder Lauf zu 100 % HTTP 200 verifiziert. Die Schleuse kostet eine Millisekunde im Median; gegen ein echtes Modell nichts Messbares.

4,046 RPSSpitzendurchsatz
+1 msMedian-Overhead der Schleuse
13.6×Durchsatz vs. LiteLLM

Die gesamte Datenebene ist in Rust geschrieben (axum, tokio, kein Garbage Collector). Bei 256 gleichzeitigen Verbindungen kostet die Compliance-Schleuse daher eine Millisekunde im Median, und gegen ein echtes Modell verschwindet sie im Rauschen des Anbieters.

Ein Upstream, identische Hardware, dieselbe Last.

Jedes Gateway steht vor demselben Keep-Alive-Mock-Upstream im internen Netz (eine vorgefertigte OpenAI-Antwort hinter einer festen Verzögerung von 60 ms), belastet vom selben Werkzeug, oha, mit derselben Nebenläufigkeit über denselben Zeitraum. Das trennt den Gateway-Overhead von der Anbieter-Varianz. Eine zweite, ratenbegrenzte Bahn läuft gegen einen echten Anbieter und prüft, ob die Geschichte auch außerhalb des Labors hält.

  • Ein geteilter Mock-Upstream

    Alle vier Gateways routen zum selben Node-Mock-Upstream im internen Netz (Keep-Alive aktiv, gleiche feste Verzögerung von 60 ms, gleicher vorgefertigter Body), also bekommt keines ein schnelleres Backend. Die Latenzunterschiede sind der Eigen-Overhead der Gateways.

  • Isoliert, identische Hardware

    Jedes Gateway läuft in einem CPU/Speicher-festgelegten Container, belastet von oha mit 256 Verbindungen über dasselbe Fenster, nach gleichem verworfenem Warmup. Gleiche Last, gleiche Grenzen, jedes Mal.

  • Basislinie bei offener Schleuse

    Alles-erlauben-Richtlinie, DLP nur im Beobachtungsmodus, Audit-Inhalt aus: Sluis als reiner OpenAI-kompatibler Proxy.

  • Geschlossene Schleuse: das echte Produkt

    EU-Residenzrichtlinie, DLP-Maskierung, Inhaltsaufbewahrung und ein hash-verkettetes Audit-Ledger: jede Schleuse aktiv auf dem heißen Pfad.

So gebaut, dass das Ergebnis nicht heimlich manipuliert werden kann.

Jede Konfiguration ist festgelegt und über alle Gateways identisch, sodass der Vergleich nicht heimlich verzerrt werden kann.

  • Alle Gateways auf identische CPU- und Speicher-cgroups festgelegt.
  • Der Mock-Upstream ist byte-identisch und geteilt; eine feste Verzögerung für alle.
  • LiteLLM und Bifrost laufen mit identischen Konfigurationen, ohne versteckte Flags.
  • Gleiches verworfenes Warmup und gleiches Messfenster pro Gateway.
  • Jeder Lauf wird an seinen Statuscodes gemessen: alles außer 100 % HTTP 200 wird verworfen, nie berichtet.
Ergebnisse

Die Zahlen, genau wie gemessen.

Zwei Sluis-Spalten: offene Schleuse, ein Äpfel-mit-Äpfeln-Proxy-Vergleich; geschlossene Schleuse, der Compliance-Overhead gegenüber unserer eigenen Basislinie.

Gemessen am 2026-07-04 auf identischer Hardware (ein Apple-Silicon-Mac, Docker) bei 256 Verbindungen; ein relativer Vergleich. Jeder Lauf zu 100 % HTTP 200 verifiziert, Wiederholungsvarianz unter 1 %. Spitzen-RSS wurde in diesem Lauf nicht erfasst, daher bleibt diese Zeile TBD.
MetrikSluis offene SchleuseSluis geschlossene SchleuseLiteLLMBifrost
Durchsatz (RPS)4,046
3,678
298
3,148
Latenz p50 (ms)62
63
743
80
Latenz p99 (ms)77
130
4,584
118
Spitzen-RSS (MiB)TBD
TBD
TBD
TBD
Erfolgsquote100%
100%
100%
100%

Die Latenz wird Ende-zu-Ende durch das Gateway über denselben Mock mit fester Latenz gemessen: die Unterschiede sind der Eigen-Overhead der Gateways.

Die Spalte geschlossene Schleuse ist Compliance-Overhead gegenüber offener Schleuse, kein Duell.

Gegen ein echtes Modell (ratenbegrenzt auf 10 RPS, damit der Anbieter nie drosselt) kostet die Schleuse im Median nichts: 289 ms geschlossen gegenüber 291 ms offen. Die p99-Ausläufer dieser Bahn gehören dem Anbieter, nicht den Gateways.

Eine ehrliche Aussage, oder gar keine.

Ein Benchmark, dem man nicht trauen kann, ist schlimmer als gar keiner. Daher binden wir uns an einige Regeln, niedergeschrieben, bevor eine Zahl veröffentlicht wird.

  • Die direkte „am schnellsten“-Aussage gilt nur für die offene Schleuse: Sluis als reiner Proxy gegen LiteLLM und Bifrost, die keine Compliance-Schleuse haben.
  • Die geschlossene Schleuse wird nie als Sieg über Konkurrenten ausgegeben. Sie ist Overhead gegenüber unserer eigenen Basislinie, klar benannt: eine Millisekunde im Median, neun Prozent Durchsatz bei synthetischer Sättigung abgegeben, und ein p99 von 130 ms gegenüber 77 ms.
  • Die Live-Bahn gegen einen echten EU-Anbieter ist ratenbegrenzt und ehrlich gekennzeichnet: die Schleuse kostet im Median nichts, und die p99-Ausläufer sind Anbieter-Varianz, kein Gateway-Overhead. Ein Plausibilitätscheck, nicht die Schlagzeile.
  • Ist Sluis bei offener Schleuse nicht klar schneller, lautet die Schlagzeile „Compliance zu vernachlässigbaren Kosten“. Die ehrliche Darstellung, nicht die lautere.

Gebaut für den Regulierer im Raum, nicht nur für den Lasttest.

Lesen Sie, wie das Gateway funktioniert, und sehen Sie dann, wie sich die Compliance-Schleuse schlägt.