Benchmarks

Sådan blev der målt

Alt kørte i Docker på én maskine, med hver komponent bundet til egne kerner, så intet konkurrerede om CPU.

• Begge gateways står foran den samme upstream med identisk modelkonfiguration, så ingen af dem får den lettere vej.
• Hver gateway kører, som dens egen dokumentation anbefaler: LiteLLM efter sin produktionsvejledning med lige så mange workers som vCPU'er, Wäg med de leverede standardindstillinger. Svarcache er slået fra i begge.
• Test i lukket sløjfe måler maksimal gennemstrømning. Test i åben sløjfe sender efter en fast plan og tæller latensen fra det tiltænkte afsendelsestidspunkt, så en gateway der sætter i kø, ikke kan skjule det.
• Hvert svar valideres: status, kroppens opbygning og for streams det forventede antal dele og afslutningen. Alt andet tæller som fejl, aldrig som et hurtigt svar.
• Hvert scenarie køres tre gange, og tabellerne viser medianen. Uden gateway i vejen når den samme belastning omkring 90.000 forespørgsler/s, langt over begge gateways, så resultaterne begrænses af gatewayen og ikke af riggen.

Fodaftryk

Hvad hver gateway koster, før den betjener noget som helst: hukommelse i hvile, opstartstid, billedstørrelse og den latens, den lægger til en enkelt forespørgsel mod en upstream der svarer med det samme.

Hvad det betyder: Hukommelsen afgør, hvor mange replikaer der er plads til på en node, og billedstørrelsen, hvor hurtig en udrulning er. Med 3,8 MB i hukommelsen og et billede på 123 MB er der plads til Wäg i en sidecar, og den er klar, før et health check løber ud; 2,3 GB og 11 sekunder er en pod, man planlægger omkring.

Den tilføjede latens er gatewayens p50 minus den p50, der måles uden gateway i vejen.

Med en realistisk upstream

En rigtig model svarer på hundredvis af millisekunder, så tusindvis af forespørgsler er undervejs samtidig. Her tager upstreamen 300 ms, og forespørgsler ankommer i fast takt, uanset hvad gatewayen gør. Ved 2.000 forespørgsler/s er omkring 600 i gang på ethvert tidspunkt.

Hvad det betyder: Sådan ser rigtig trafik ud: en model svarer på hundredvis af millisekunder, og tusindvis af forespørgsler er undervejs. En gateway, der sætter i kø, gør et svar på 300 ms til flere sekunder, og ingen opdager det før spidsbelastningen. Wäg bliver på gulvet op til 2.000 forespørgsler/s med under en tredjedel af sit CPU-budget. LiteLLM sætter allerede i kø ved 1.000 og fejler 8 % af forespørgslerne ved 2.000.

Upstreamen alene tager 300 ms, så 300 ms er gulvet. Alt derover er tid brugt i kø inde i gatewayen. Kolonnen × læses altid ens: højere betyder, at Wäg er foran. Den er Wäg ÷ LiteLLM for gennemstrømning og LiteLLM ÷ Wäg for latens.

Gennemstrømning og latens

Lukket sløjfe mod en upstream der svarer med det samme: rene gatewayomkostninger, uden modellatens at gemme sig bag. Det er tallene, en kapacitetsplan har brug for. De er ikke grunden til at vælge en control plane.

4 vCPU, uden database

1 vCPU, uden database

Hvad det betyder: Det afgør, hvor mange replikaer et trafikniveau kræver, og dermed hvad gatewayen koster at drive. For Kubernetes er tabellen med 1 vCPU den relevante: det er effektiviteten pr. kerne, som en pod reelt får.

Streaming, payloads, embeddings, failover

4 vCPU, uden database. Streams er 50 tokens med 5 ms mellemrum; udholdenhedstesten sender 200 streams i sekundet med svar på cirka 1,2 sekunder i tre minutter.

Hvad det betyder: Streaming, lange prompts, embeddings og failover er der, hvor en produktionsbelastning bruger tiden. Læs fejlkolonnerne før gennemstrømningskolonnerne: en fejlet forespørgsel er en fejlet brugerforespørgsel, ikke en langsom.

Tallet for 64 KB-payloads ligger ved riggens loft: uden gateway i vejen når den samme belastning 3.711 forespørgsler/s med 64 KB-kroppe på én kerne, så Wäg-tallet er dér en nedre grænse og ikke et maksimum.

Hvad dette ikke viser

Enhver benchmark beskriver én opstilling. Dette er grænserne for denne.

• Absolutte tal afhænger af værten. Begge gateways kørte på den samme maskine med bundne kerner, så sammenligningen mellem dem holder, men forvent andre absolutte tal på jeres egen hardware.
• Testriggen bag disse kørsler er ikke offentliggjort, så I kan ikke gentage dem kommando for kommando. Metoden ovenfor er beskrevet detaljeret nok til at bygge en tilsvarende opsætning.
• LiteLLM udgiver næsten hver uge. Tallene er målt mod v1.104.2, den aktuelle stabile udgave. Når en udgivelse ændrer videresendelsesvejen, måler vi igen og offentliggør, hvad vi finder.
• LiteLLM blev konfigureret ud fra sin produktionsvejledning, ikke af dens vedligeholdere. Der findes måske en bedre konfiguration; finder I en, måler vi igen og offentliggør på ny.
• Begge gateways kørte på én maskine med bundne kerner. Intet her måler adfærd over et netværk, under Kubernetes-scheduling eller med støjende naboer.