Benchmarks

Hoe er is gemeten

Alles draaide in Docker op één machine, met elk onderdeel vastgezet op eigen cores zodat niets om CPU concurreerde.

• Beide gateways staan voor dezelfde upstream met identieke modelconfiguratie, dus geen van beide heeft het makkelijkere pad.
• Elke gateway draait zoals de eigen documentatie aanraadt: LiteLLM volgens de productiegids, met evenveel workers als vCPU's; Wäg met de meegeleverde standaardinstellingen. Response-caching staat bij beide uit.
• Closed-looptests meten de maximale doorvoer. Open-looptests versturen op een vast schema en rekenen de latency vanaf het bedoelde verzendmoment, zodat een gateway die in de wachtrij zet dat niet kan verbergen.
• Elk antwoord wordt gevalideerd: status, opbouw van de body en bij streams het verwachte aantal chunks met afsluiting. Al het andere telt als fout, nooit als snel antwoord.
• Elk scenario draait drie keer en de tabellen tonen de mediaan. Zonder gateway in het pad haalt dezelfde belasting ongeveer 90.000 req/s, ver boven beide gateways, dus de resultaten worden begrensd door de gateway en niet door het harnas.

Voetafdruk

Wat elke gateway kost voordat hij iets bedient: geheugen in rust, opstarttijd, imagegrootte en de latency die hij toevoegt aan één verzoek bij een direct antwoordende upstream.

Wat dit betekent: Geheugen bepaalt hoeveel replica's op een node passen, en imagegrootte hoe snel een uitrol is. Met 3,8 MB resident en een image van 123 MB past Wäg in een sidecar en is hij klaar voordat een health check verloopt; 2,3 GB en 11 seconden is een pod waar je omheen plant.

De toegevoegde latency is de p50 van de gateway minus de p50 gemeten zonder gateway in het pad.

Bij een realistische upstream

Een echt model antwoordt in honderden milliseconden, dus zijn er duizenden verzoeken tegelijk onderweg. Hier doet de upstream er 300 ms over en komen verzoeken op een vast tempo binnen, wat de gateway ook doet. Bij 2.000 req/s zijn er steeds ongeveer 600 verzoeken onderhanden.

Wat dit betekent: Dit is de vorm van echt verkeer: een model antwoordt in honderden milliseconden en duizenden verzoeken zijn onderweg. Een gateway die in de wachtrij zet maakt van een antwoord van 300 ms er een van meerdere seconden, en niemand merkt het tot de piek. Wäg blijft tot 2.000 req/s op de ondergrens met minder dan een derde van zijn CPU-budget. LiteLLM staat bij 1.000 al in de wachtrij en laat bij 2.000 8% van de verzoeken mislukken.

De upstream alleen kost al 300 ms: dat is de ondergrens. Alles daarboven is wachttijd in de wachtrij van de gateway. De kolom × leest altijd hetzelfde: hoger betekent dat Wäg voorligt. Het is Wäg ÷ LiteLLM voor doorvoer en LiteLLM ÷ Wäg voor latency.

Doorvoer en latency

Closed loop tegen een direct antwoordende upstream: puur de kosten van de gateway, zonder modellatency om je achter te verschuilen. Dit zijn de getallen die een capaciteitsplan nodig heeft. Ze zijn niet de reden om een control plane te kiezen.

4 vCPU, zonder database

1 vCPU, zonder database

Wat dit betekent: Dit bepaalt hoeveel replica's een verkeersniveau nodig heeft, en daarmee wat de gateway kost om te draaien. Voor Kubernetes is de tabel met 1 vCPU de relevante: dat is de efficiëntie per core die een pod werkelijk krijgt.

Streaming, payloads, embeddings, failover

4 vCPU, zonder database. Streams zijn 50 tokens met 5 ms ertussen; de duurtest stuurt drie minuten lang 200 streams per seconde van ongeveer 1,2 seconde.

Wat dit betekent: Streaming, lange prompts, embeddings en failover zijn de paden waar een productielast zijn tijd doorbrengt. Lees de foutkolommen vóór de doorvoerkolommen: een mislukt verzoek is een mislukt gebruikersverzoek, geen traag verzoek.

Het cijfer voor payloads van 64 KB zit tegen het plafond van het harnas: zonder gateway in het pad haalt dezelfde belasting 3.711 req/s aan bodies van 64 KB op één core, dus het getal van Wäg is daar een ondergrens en geen maximum.

Wat dit niet laat zien

Elke benchmark beschrijft één opstelling. Dit zijn de grenzen van deze.

• Absolute getallen hangen af van de host. Beide gateways draaiden op dezelfde machine met vastgezette cores, dus de vergelijking onderling houdt stand, maar verwacht op uw eigen hardware andere absolute waarden.
• Het harnas achter deze metingen is niet gepubliceerd, dus u kunt ze niet commando voor commando herhalen. De methode hierboven is gedetailleerd genoeg beschreven om een gelijkwaardige opstelling na te bouwen.
• LiteLLM brengt bijna wekelijks uit. Deze cijfers zijn gemeten tegen v1.104.2, de huidige stabiele release. Zodra een release het doorsturingspad verandert, meten we opnieuw en publiceren we wat eruit komt.
• LiteLLM is geconfigureerd volgens de eigen productiegids, niet door de maintainers. Er bestaat mogelijk een betere configuratie; vindt u er een, dan meten we opnieuw en publiceren we opnieuw.
• Beide gateways draaiden op één machine met vastgezette cores. Niets hiervan meet gedrag over een netwerk, onder Kubernetes-scheduling of met luidruchtige buren.