Performance

Mesurée, pas promise.

La surcharge du gateway, mesurée sur matériel identique devant un upstream keep-alive, chaque exécution vérifiée à 100 % HTTP 200. La porte coûte une milliseconde à la médiane ; face à un modèle réel, rien de mesurable.

4,046 RPSDébit de pointe
+1 msSurcharge médiane de la porte
13.6×Débit vs LiteLLM

Tout le plan de données est écrit en Rust (axum, tokio, sans ramasse-miettes) : à 256 connexions simultanées, la porte de conformité ajoute donc une milliseconde à la médiane, et face à un modèle réel elle disparaît dans le bruit du fournisseur.

Un seul upstream, un matériel identique, la même charge.

Chaque gateway se place devant le même upstream factice keep-alive sur le réseau interne (une réponse OpenAI préenregistrée derrière un délai fixe de 60 ms), chargé par le même outil, oha, à la même concurrence, pour la même durée. Cela isole la surcharge du gateway de la variance du fournisseur. Une seconde voie, plafonnée en débit, tourne face à un vrai fournisseur pour vérifier que l'histoire tient hors du laboratoire.

  • Un seul upstream factice partagé

    Les quatre gateways routent vers le même upstream factice Node sur le réseau interne (keep-alive actif, même délai fixe de 60 ms, même corps préenregistré) : aucun ne bénéficie d'un backend plus rapide. Les écarts de latence sont la surcharge propre des gateways.

  • Isolé, matériel identique

    Chaque gateway tourne dans un conteneur épinglé en CPU/mémoire, chargé par oha à 256 connexions sur la même fenêtre, après une préchauffe écartée identique. Même charge, mêmes limites, à chaque fois.

  • Référence porte ouverte

    Politique tout-autorisé, DLP en observation seule, contenu d'audit désactivé : Sluis en simple proxy compatible OpenAI.

  • Porte fermée : le vrai produit

    Politique de résidence UE, masquage DLP, rétention de contenu et registre d'audit chaîné par hachage : chaque porte active sur le chemin critique.

Conçu pour qu'on ne puisse pas truquer le résultat en silence.

Chaque configuration est épinglée et identique d'un gateway à l'autre, pour que la comparaison ne puisse pas être discrètement biaisée.

  • Tous les gateways épinglés à des cgroups CPU et mémoire identiques.
  • L'upstream factice est identique à l'octet près et partagé ; un seul délai fixe pour tous.
  • LiteLLM et Bifrost tournent sur des configurations identiques, sans aucun drapeau caché.
  • Préchauffe écartée identique et fenêtre de mesure identique pour chaque gateway.
  • Chaque exécution est validée sur ses codes de statut : tout ce qui n'est pas 100 % HTTP 200 est écarté, jamais publié.
Résultats

Les chiffres, exactement tels que mesurés.

Deux colonnes Sluis : porte ouverte, une comparaison de proxy à parts égales ; porte fermée, la surcharge de conformité face à notre propre référence.

Mesuré le 2026-07-04 sur un matériel identique (un seul Mac Apple Silicon, Docker) à 256 connexions ; une comparaison relative. Chaque exécution vérifiée à 100 % HTTP 200, variance entre exécutions sous 1 %. Le RSS maximal n'a pas été relevé lors de cette exécution, cette ligne reste donc TBD.
MétriqueSluis porte ouverteSluis porte ferméeLiteLLMBifrost
Débit (RPS)4,046
3,678
298
3,148
Latence p50 (ms)62
63
743
80
Latence p99 (ms)77
130
4,584
118
RSS maximal (MiB)TBD
TBD
TBD
TBD
Taux de succès100%
100%
100%
100%

La latence est mesurée de bout en bout à travers le gateway, sur le même mock à latence fixe : les écarts représentent la surcharge propre des gateways.

La colonne porte fermée est la surcharge de conformité face à la porte ouverte, pas un duel.

Face à un modèle réel (plafonné à 10 RPS pour que le fournisseur ne limite jamais), la porte n'ajoute rien à la médiane : 289 ms porte fermée contre 291 ms porte ouverte. Les queues p99 de cette voie appartiennent au fournisseur, pas aux gateways.

Une affirmation honnête, ou aucune.

Un benchmark auquel on ne peut pas se fier est pire que pas de benchmark. Nous nous imposons donc quelques règles, écrites avant qu'aucun chiffre ne soit publié.

  • L'affirmation « le plus rapide » en duel ne concerne que la porte ouverte : Sluis en simple proxy face à LiteLLM et Bifrost, qui n'ont pas de porte de conformité.
  • La porte fermée n'est jamais maquillée en victoire sur les concurrents. C'est une surcharge face à notre propre référence, dite sans fard : une milliseconde à la médiane, neuf pour cent de débit cédés à saturation synthétique, et un p99 de 130 ms contre 77 ms.
  • La voie en direct face à un vrai fournisseur UE est plafonnée en débit et étiquetée honnêtement : la porte n'ajoute rien à la médiane, et les queues p99 sont la variance du fournisseur, pas la surcharge du gateway. Un contrôle de cohérence, pas le titre.
  • Si Sluis porte ouverte n'est pas nettement plus rapide, le titre devient « la conformité à coût négligeable ». Le cadrage honnête, pas le plus tapageur.

Conçu pour le régulateur dans la pièce, pas seulement pour le test de charge.

Découvrez le fonctionnement du gateway, puis voyez comment la porte de conformité se comporte.