Benchmark

Come è stata fatta la misura

Tutto è girato in Docker su una sola macchina, con ogni componente fissato ai propri core perché nulla competesse per la CPU.

• Entrambi i gateway stanno davanti allo stesso upstream con configurazione del modello identica: nessuno dei due ha il percorso più facile.
• Ogni gateway gira come raccomanda la sua documentazione: LiteLLM secondo la guida di produzione, con worker pari alle vCPU; Wäg con i valori predefiniti. La cache delle risposte è disattivata su entrambi.
• I test a ciclo chiuso misurano il throughput massimo. Quelli a ciclo aperto inviano a cadenza fissa e contano la latenza dall'istante di invio previsto: un gateway che accoda non può nasconderlo.
• Ogni risposta viene validata: stato, struttura del corpo e, per gli stream, il numero di chunk atteso e la chiusura. Tutto il resto conta come errore, mai come risposta veloce.
• Ogni scenario viene eseguito tre volte e le tabelle mostrano la mediana. Senza gateway nel percorso lo stesso carico raggiunge circa 90.000 req/s, ben oltre entrambi i gateway: i risultati sono limitati dal gateway, non dall'harness.

Impronta

Quanto costa ogni gateway prima di servire alcunché: memoria a riposo, tempo di avvio, dimensione dell'immagine e latenza aggiunta a una singola richiesta con upstream istantaneo.

Che cosa significa: La memoria decide quante repliche stanno su un nodo, la dimensione dell'immagine quanto è rapido un rollout. Con 3,8 MB residenti e un'immagine da 123 MB, Wäg sta in un sidecar ed è pronto prima che scada un health check; 2,3 GB e 11 secondi sono un pod attorno al quale bisogna pianificare.

La latenza aggiunta è il p50 del gateway meno il p50 misurato senza gateway nel percorso.

Con un upstream realistico

Un modello reale risponde in centinaia di millisecondi, quindi migliaia di richieste sono in volo insieme. Qui l'upstream impiega 300 ms e le richieste arrivano a cadenza fissa qualunque cosa faccia il gateway. A 2.000 req/s circa 600 richieste sono in corso in ogni momento.

Che cosa significa: Questa è la forma del traffico reale: un modello risponde in centinaia di millisecondi e migliaia di richieste sono in volo. Un gateway che accoda trasforma una risposta da 300 ms in una da diversi secondi, e nessuno se ne accorge fino al picco. Wäg resta alla soglia fino a 2.000 req/s con meno di un terzo del suo budget di CPU. LiteLLM accoda già a 1.000 e fallisce l'8% delle richieste a 2.000.

Il solo upstream impiega 300 ms: quella è la soglia minima. Tutto ciò che la supera è tempo passato in coda dentro il gateway. La colonna × si legge sempre allo stesso modo: più alto significa che Wäg è avanti. È Wäg ÷ LiteLLM per il throughput e LiteLLM ÷ Wäg per la latenza.

Throughput e latenza

Ciclo chiuso verso un upstream istantaneo: puro costo del gateway, senza latenza del modello dietro cui nascondersi. Sono i numeri che servono a un piano di capacità. Non sono il motivo per scegliere un control plane.

4 vCPU, senza database

1 vCPU, senza database

Che cosa significa: Questo determina quante repliche servono a un dato livello di traffico, e quindi quanto costa far girare il gateway. Per Kubernetes la tabella da leggere è quella a 1 vCPU: è l'efficienza per core che un pod ottiene davvero.

Streaming, payload, embedding, failover

4 vCPU, senza database. Gli stream sono 50 token a 5 ms di distanza; il test di durata invia 200 stream al secondo di risposte da circa 1,2 secondi per tre minuti.

Che cosa significa: Streaming, prompt lunghi, embedding e failover sono i percorsi su cui un carico di produzione passa il tempo. Leggete le colonne degli errori prima di quelle del throughput: una richiesta fallita è una richiesta utente fallita, non una lenta.

Il valore sui payload da 64 KB è al soffitto dell'harness: senza gateway nel percorso lo stesso carico raggiunge 3711 req/s di corpi da 64 KB su un core. Il numero di Wäg è quindi un limite inferiore, non un massimo.

Che cosa questo non mostra

Ogni benchmark descrive un allestimento. Questi sono i limiti del nostro.

• I valori assoluti dipendono dall'host. Entrambi i gateway hanno girato sulla stessa macchina con core fissati, quindi il confronto tra loro regge, ma aspettatevi valori assoluti diversi sul vostro hardware.
• L'harness che ha guidato queste prove non è pubblicato, quindi non potete ripeterle comando per comando. Il metodo sopra è descritto in modo abbastanza dettagliato da ricostruirne uno equivalente.
• LiteLLM rilascia quasi ogni settimana. Questi dati sono stati misurati con v1.104.2, l'attuale versione stabile. Quando una versione cambia il percorso di inoltro, rieseguiamo la prova e pubblichiamo i risultati.
• LiteLLM è stato configurato secondo la sua guida di produzione, non dai suoi manutentori. Potrebbe esistere una configurazione migliore: se ne trovate una, rieseguiremo e ripubblicheremo.
• Entrambi i gateway hanno girato su una sola macchina con core fissati. Nulla qui misura il comportamento attraverso una rete, sotto lo scheduling di Kubernetes o con vicini rumorosi.