Benchmarks

Cómo se midió

Todo se ejecutó en Docker en una sola máquina, con cada componente fijado a sus propios núcleos para que nada compitiera por la CPU.

• Ambas pasarelas se sitúan ante el mismo upstream con idéntica configuración de modelo, así que ninguna tiene el camino más fácil.
• Cada pasarela se ejecuta como recomienda su propia documentación: LiteLLM según su guía de producción, con tantos workers como vCPU; Wäg con sus valores por defecto. La caché de respuestas está desactivada en ambas.
• Las pruebas en bucle cerrado miden el rendimiento máximo. Las de bucle abierto envían a un ritmo fijo y cuentan la latencia desde el instante de envío previsto, así que una pasarela que encola no puede ocultarlo.
• Cada respuesta se valida: estado, estructura del cuerpo y, en los flujos, el número de fragmentos esperado y su cierre. Todo lo demás cuenta como error, nunca como respuesta rápida.
• Cada escenario se ejecuta tres veces y las tablas muestran la mediana. Sin pasarela en el camino, la misma carga alcanza unas 90.000 req/s, muy por encima de ambas pasarelas: los resultados los limita la pasarela, no el arnés.

Huella

Lo que cuesta cada pasarela antes de servir nada: memoria en reposo, tiempo de arranque, tamaño de imagen y latencia añadida a una sola petición con un upstream instantáneo.

Qué significa: La memoria decide cuántas réplicas caben en un nodo, y el tamaño de la imagen, lo rápido que es un despliegue. Con 3,8 MB residentes y una imagen de 123 MB, Wäg cabe en un sidecar y está listo antes de que expire un health check; 2,3 GB y 11 segundos son un pod alrededor del cual hay que planificar.

La latencia añadida es el p50 de la pasarela menos el p50 medido sin pasarela en el camino.

Con un upstream realista

Un modelo real responde en cientos de milisegundos, así que hay miles de peticiones en vuelo a la vez. Aquí el upstream tarda 300 ms y las peticiones llegan a ritmo fijo haga lo que haga la pasarela. A 2.000 req/s hay unas 600 peticiones en curso en cada momento.

Qué significa: Esta es la forma del tráfico real: un modelo responde en cientos de milisegundos y hay miles de peticiones en vuelo. Una pasarela que encola convierte una respuesta de 300 ms en una de varios segundos, y nadie lo nota hasta el pico. Wäg se mantiene en el suelo hasta 2.000 req/s con menos de un tercio de su presupuesto de CPU. LiteLLM ya encola a 1.000 y falla el 8% de las peticiones a 2.000.

El upstream por sí solo tarda 300 ms: ese es el suelo. Todo lo que lo supere es tiempo en cola dentro de la pasarela. La columna × se lee siempre igual: más alto significa que Wäg va por delante. Es Wäg ÷ LiteLLM para el rendimiento y LiteLLM ÷ Wäg para la latencia.

Rendimiento y latencia

Bucle cerrado contra un upstream instantáneo: coste puro de la pasarela, sin latencia de modelo tras la que esconderse. Son las cifras que necesita un plan de capacidad. No son la razón para elegir un plano de control.

4 vCPU, sin base de datos

1 vCPU, sin base de datos

Qué significa: Esto determina cuántas réplicas necesita un nivel de tráfico y, por tanto, lo que cuesta operar la pasarela. Para Kubernetes, la tabla a leer es la de 1 vCPU: es la eficiencia por núcleo que un pod obtiene realmente.

Streaming, cargas útiles, embeddings, conmutación

4 vCPU, sin base de datos. Los flujos son 50 tokens separados 5 ms; la prueba de resistencia envía 200 flujos por segundo de respuestas de unos 1,2 segundos durante tres minutos.

Qué significa: Streaming, prompts largos, embeddings y conmutación son los caminos donde una carga de producción pasa el tiempo. Lea las columnas de errores antes que las de rendimiento: una petición fallida es una petición de usuario fallida, no una lenta.

La cifra de cargas de 64 KB está en el techo del arnés: sin pasarela en el camino la misma carga alcanza 3711 req/s de cuerpos de 64 KB en un núcleo, así que el número de Wäg ahí es una cota inferior, no un máximo.

Lo que esto no muestra

Todo benchmark describe un montaje. Estos son los límites de este.

• Las cifras absolutas dependen del host. Ambas pasarelas se ejecutaron en la misma máquina con núcleos fijados, así que la comparación entre ellas se sostiene, pero espere valores absolutos distintos en su propio hardware.
• El arnés que condujo estas mediciones no está publicado, así que no puede repetirlas comando a comando. El método anterior se describe con detalle suficiente para reconstruir uno equivalente.
• LiteLLM publica casi cada semana. Estas cifras se midieron con v1.104.2, la versión estable actual. Cuando una versión modifique la ruta de reenvío, repetiremos la medición y publicaremos lo que salga.
• LiteLLM se configuró a partir de su guía de producción, no por sus mantenedores. Puede existir una configuración mejor; si encuentra una, repetiremos la medición y volveremos a publicar.
• Ambas pasarelas se ejecutaron en una sola máquina con núcleos fijados. Nada de esto mide el comportamiento a través de una red, bajo la planificación de Kubernetes o con vecinos ruidosos.