Rendimiento

Medido, no prometido.

La sobrecarga del gateway, medida en hardware idéntico ante un upstream con keep-alive, cada ejecución verificada al 100 % HTTP 200. La compuerta cuesta un milisegundo en la mediana; frente a un modelo real, nada medible.

4,046 RPSRendimiento máximo
+1 msSobrecarga mediana de la compuerta
13.6×Rendimiento vs LiteLLM

Todo el plano de datos está escrito en Rust (axum, tokio, sin recolector de basura); por eso, con 256 conexiones simultáneas, la compuerta de cumplimiento añade un milisegundo en la mediana, y frente a un modelo real desaparece en el ruido del proveedor.

Un upstream, hardware idéntico, la misma carga.

Cada gateway se sitúa ante el mismo upstream simulado con keep-alive en la red interna (una respuesta OpenAI predefinida tras un retardo fijo de 60 ms), cargado por la misma herramienta, oha, con la misma concurrencia, durante la misma ventana. Eso aísla la sobrecarga del gateway de la varianza del proveedor. Un segundo carril, con tasa limitada, corre frente a un proveedor real para comprobar que la historia se sostiene fuera del laboratorio.

  • Un único upstream simulado compartido

    Los cuatro gateways enrutan al mismo upstream simulado de Node en la red interna (keep-alive activo, el mismo retardo fijo de 60 ms, el mismo cuerpo predefinido), así que ninguno tiene un backend más rápido. Las diferencias de latencia son la sobrecarga propia de los gateways.

  • Aislado, hardware idéntico

    Cada gateway corre en un contenedor fijado en CPU/memoria, cargado por oha con 256 conexiones durante la misma ventana, tras un calentamiento descartado igual. La misma carga, los mismos límites, cada vez.

  • Línea base con compuerta abierta

    Política de permitir todo, DLP solo en observación, contenido de auditoría desactivado: Sluis como proxy simple compatible con OpenAI.

  • Compuerta cerrada: el producto real

    Política de residencia en la UE, enmascarado DLP, retención de contenido y un registro de auditoría encadenado por hash: cada compuerta activa en la ruta crítica.

Construido para que el resultado no pueda amañarse en silencio.

Cada configuración está fijada y es idéntica en todos los gateways, de modo que la comparación no puede inclinarse en silencio.

  • Todos los gateways fijados a cgroups idénticos de CPU y memoria.
  • El upstream simulado es idéntico byte a byte y compartido; un único retardo fijo para todos.
  • LiteLLM y Bifrost corren configuraciones idénticas, sin banderas ocultas.
  • Igual calentamiento descartado e igual ventana de medición por gateway.
  • Cada ejecución se valida por sus códigos de estado: todo lo que no sea 100 % HTTP 200 se descarta, nunca se publica.
Resultados

Las cifras, exactamente como se midieron.

Dos columnas de Sluis: compuerta abierta, una comparación de proxy en igualdad de condiciones; compuerta cerrada, la sobrecarga de cumplimiento frente a nuestra propia línea base.

Medido el 2026-07-04 en un hardware idéntico (un solo Mac Apple Silicon, Docker) con 256 conexiones; una comparación relativa. Cada ejecución verificada al 100 % HTTP 200, con varianza entre ejecuciones inferior al 1 %. El RSS máximo no se capturó en esta ejecución, así que esa fila queda en TBD.
MétricaSluis compuerta abiertaSluis compuerta cerradaLiteLLMBifrost
Rendimiento (RPS)4,046
3,678
298
3,148
Latencia p50 (ms)62
63
743
80
Latencia p99 (ms)77
130
4,584
118
RSS máximo (MiB)TBD
TBD
TBD
TBD
Tasa de éxito100%
100%
100%
100%

La latencia se mide de extremo a extremo a través del gateway, sobre el mismo mock de latencia fija: las diferencias son la sobrecarga propia de los gateways.

La columna de compuerta cerrada es sobrecarga de cumplimiento frente a compuerta abierta, no un duelo.

Frente a un modelo real (con tasa limitada a 10 RPS para que el proveedor nunca estrangule), la compuerta no añade nada en la mediana: 289 ms cerrada frente a 291 ms abierta. Las colas p99 de ese carril pertenecen al proveedor, no a los gateways.

Una afirmación honesta, o ninguna.

Un benchmark en el que no se puede confiar es peor que ninguno. Por eso nos atamos a unas pocas reglas, escritas antes de publicar cifra alguna.

  • La afirmación de «el más rápido» en duelo es solo de compuerta abierta: Sluis como proxy simple frente a LiteLLM y Bifrost, que no tienen compuerta de cumplimiento.
  • La compuerta cerrada nunca se disfraza de victoria sobre los competidores. Es sobrecarga frente a nuestra propia línea base, dicha sin adornos: un milisegundo en la mediana, un nueve por ciento de rendimiento cedido en saturación sintética, y un p99 de 130 ms frente a 77 ms.
  • El carril en vivo frente a un proveedor real de la UE tiene tasa limitada y se etiqueta con honestidad: la compuerta no añade nada en la mediana, y las colas p99 son varianza del proveedor, no sobrecarga del gateway. Una comprobación de cordura, no el titular.
  • Si Sluis con compuerta abierta no es claramente más rápido, el titular pasa a ser «cumplimiento a coste insignificante». El encuadre honesto, no el más ruidoso.

Hecho para el regulador en la sala, no solo para la prueba de carga.

Lea cómo funciona el gateway y luego vea cómo se comporta la compuerta de cumplimiento.