Prestaties

Gemeten, niet beloofd.

De gateway-overhead, gemeten op identieke hardware vóór één upstream met keep-alive, elke run geverifieerd op 100 % HTTP 200. De sluis kost één milliseconde op de mediaan; tegen een echt model niets meetbaars.

4,046 RPSPiekdoorvoer
+1 msMediane sluis-overhead
13.6×Doorvoer vs LiteLLM

Het hele data plane is in Rust geschreven (axum, tokio, geen garbage collector). Daarom voegt de compliance-sluis bij 256 gelijktijdige verbindingen één milliseconde toe op de mediaan, en tegen een echt model verdwijnt ze in de ruis van de provider.

Eén upstream, identieke hardware, dezelfde belasting.

Elke gateway staat voor dezelfde mock-upstream met keep-alive op het interne netwerk (een vooraf vastgelegde OpenAI-respons achter één vaste vertraging van 60 ms), belast door hetzelfde gereedschap, oha, met dezelfde gelijktijdigheid, gedurende hetzelfde venster. Dat isoleert de gateway-overhead van de variantie van de provider. Een tweede baan, met begrensd tempo, draait tegen een echte provider om te toetsen of het verhaal buiten het lab overeind blijft.

  • Eén gedeelde mock-upstream

    Alle vier de gateways routeren naar dezelfde Node-mock-upstream op het interne netwerk (keep-alive aan, dezelfde vaste vertraging van 60 ms, dezelfde vastgelegde body), dus niemand krijgt een snellere backend. De latentieverschillen zijn de eigen overhead van de gateways.

  • Geïsoleerd, identieke hardware

    Elke gateway draait in een op CPU/geheugen vastgezette container, belast door oha met 256 verbindingen over hetzelfde venster, na een gelijke verworpen opwarming. Dezelfde belasting, dezelfde limieten, elke keer.

  • Sluis-open-basislijn

    Alles-toestaan-beleid, DLP in alleen-observeren, auditinhoud uit: Sluis als kale OpenAI-compatibele proxy.

  • Sluis dicht: het echte product

    EU-residentiebeleid, DLP-maskering, contentbewaring en een hash-geketend auditgrootboek: elke sluis actief op het hete pad.

Zo gebouwd dat het resultaat niet stilletjes te sjoemelen is.

Elke configuratie is vastgezet en identiek over alle gateways, zodat de vergelijking niet stilletjes scheef te trekken is.

  • Alle gateways vastgezet op identieke CPU- en geheugen-cgroups.
  • De mock-upstream is byte-identiek en gedeeld; één vaste vertraging voor iedereen.
  • LiteLLM en Bifrost draaien identieke configuraties, zonder verborgen vlaggen.
  • Gelijke verworpen opwarming en gelijk meetvenster per gateway.
  • Elke run wordt getoetst op zijn statuscodes: alles wat geen 100 % HTTP 200 is wordt verworpen, nooit gerapporteerd.
Resultaten

De cijfers, precies zoals gemeten.

Twee Sluis-kolommen: sluis open, een gelijke-monniken-proxyvergelijking; sluis dicht, de compliance-overhead tegen onze eigen basislijn.

Gemeten op 2026-07-04 op identieke hardware (één Apple Silicon-Mac, Docker) met 256 verbindingen; een relatieve vergelijking. Elke run geverifieerd op 100 % HTTP 200, herhaalvariantie onder 1 %. Piek-RSS is bij deze run niet vastgelegd, dus die rij blijft TBD.
MetriekSluis openSluis dichtLiteLLMBifrost
Doorvoer (RPS)4,046
3,678
298
3,148
Latentie p50 (ms)62
63
743
80
Latentie p99 (ms)77
130
4,584
118
Piek-RSS (MiB)TBD
TBD
TBD
TBD
Slagingspercentage100%
100%
100%
100%

Latentie is end-to-end door de gateway gemeten, over dezelfde mock met vaste latentie: de verschillen zijn de eigen overhead van de gateways.

De kolom sluis dicht is compliance-overhead tegenover sluis open, geen duel.

Tegen een echt model (begrensd op 10 RPS zodat de provider nooit afknijpt) voegt de sluis niets toe op de mediaan: 289 ms sluis dicht tegenover 291 ms sluis open. De p99-staarten van die baan horen bij de provider, niet bij de gateways.

Een eerlijke claim, of geen.

Een benchmark die je niet kunt vertrouwen is erger dan geen benchmark. Daarom binden we onszelf aan een paar regels, opgeschreven voordat er ook maar één getal verschijnt.

  • De directe “snelste”-claim geldt alleen voor sluis open: Sluis als kale proxy tegen LiteLLM en Bifrost, die geen compliance-sluis hebben.
  • Sluis dicht presenteren we nooit als winst op concurrenten. Het is overhead tegen onze eigen basislijn, onverbloemd benoemd: één milliseconde op de mediaan, negen procent doorvoer ingeleverd bij synthetische verzadiging, en een p99 van 130 ms tegenover 77 ms.
  • De live-baan tegen een echte EU-provider heeft een begrensd tempo en is eerlijk gelabeld: de sluis voegt niets toe op de mediaan, en de p99-staarten zijn providervariantie, geen gateway-overhead. Een sanity check, niet de kop.
  • Is Sluis met de sluis open niet duidelijk sneller, dan wordt de kop “compliance tegen verwaarloosbare kosten”. Het eerlijke kader, niet het luidere.

Gebouwd voor de toezichthouder in de kamer, niet alleen voor de loadtest.

Lees hoe de gateway werkt en zie dan hoe de compliance-sluis presteert.