Benchmarks
Hur Wäg-gatewayen står sig mot LiteLLM under identiska förhållanden. Den här sidan redovisar metoden i sin helhet och publicerar de mätvärden den gav. Vi publicerar inga multiplikatorer.
Så gjordes mätningen
Allt kördes i Docker på en maskin, med varje komponent låst till egna kärnor så att inget konkurrerade om CPU.
- Båda gatewayerna står framför samma upstream med identisk modellkonfiguration, så ingen av dem får den lättare vägen.
- Varje gateway körs som dess egen dokumentation rekommenderar: LiteLLM enligt sin produktionsguide med lika många workers som vCPU:er, Wäg med levererade standardvärden. Svarscache är avstängd i båda.
- Tester i sluten loop mäter maximal genomströmning. Tester i öppen loop skickar enligt fast schema och räknar latensen från den avsedda sändtidpunkten, så en gateway som köar kan inte dölja köandet.
- Varje svar valideras: status, kroppens struktur och för strömmar det förväntade antalet delar och avslutningen. Allt annat räknas som fel, aldrig som ett snabbt svar.
- Varje scenario körs tre gånger och tabellerna visar medianen. Utan gateway i vägen når samma last cirka 90 000 förfrågningar/s, långt över båda gatewayerna, så resultaten begränsas av gatewayen och inte av riggen.
Fotavtryck
Vad varje gateway kostar innan den levererar något: minne i vila, starttid, avbildningens storlek och den latens den lägger till en enskild förfrågan mot en upstream som svarar direkt.
Vad det betyder: Minnet avgör hur många repliker som ryms på en nod, och avbildningens storlek hur snabb en utrullning är. Med 3,8 MB i minnet och en avbildning på 123 MB får Wäg plats i en sidecar och är redo innan en hälsokontroll hinner löpa ut; 2,3 GB och 11 sekunder är en pod man planerar runt.
Den tillagda latensen är gatewayens p50 minus den p50 som mäts utan gateway i vägen.
Med en realistisk upstream
En riktig modell svarar på hundratals millisekunder, så tusentals förfrågningar är i luften samtidigt. Här tar upstreamen 300 ms och förfrågningar kommer i fast takt oavsett vad gatewayen gör. Vid 2 000 förfrågningar/s är omkring 600 under arbete i varje ögonblick.
| förfrågningar per sekund | Wäg p50 | Wäg p99 | Wäg Fel | Wäg CPU | LiteLLM p50 | LiteLLM p99 | LiteLLM Fel | LiteLLM CPU | × |
|---|---|---|---|---|---|---|---|---|---|
| 100 | 303 ms | 305 ms | 0,00% | 10,2% | 305 ms | 308 ms | 0,00% | 38,7% | 1,0× |
| 500 | 301 ms | 303 ms | 0,00% | 15,6% | 304 ms | 321 ms | 0,00% | 140,5% | 1,1× |
| 1 000 | 301 ms | 302 ms | 0,00% | 20,2% | 317 ms | 605 ms | 0,00% | 263,7% | 2,0× |
| 2 000 | 301 ms | 302 ms | 0,00% | 31,7% | 3,26 s | 28 s | 7,99% | 391,9% | 92× |
Vad det betyder: Så ser verklig trafik ut: en modell svarar på hundratals millisekunder och tusentals förfrågningar är i luften. En gateway som köar gör ett svar på 300 ms till flera sekunder, och ingen märker det förrän vid toppen. Wäg ligger kvar på golvet upp till 2 000 förfrågningar/s med mindre än en tredjedel av sin CPU-budget. LiteLLM köar redan vid 1 000 och missar 8 % av förfrågningarna vid 2 000.
Bara upstreamen tar 300 ms, så 300 ms är golvet. Allt däröver är tid i kö inne i gatewayen. Kolumnen × läses alltid likadant: högre betyder att Wäg ligger före. Den är Wäg ÷ LiteLLM för genomströmning och LiteLLM ÷ Wäg för latens.
Genomströmning och latens
Sluten loop mot en upstream som svarar direkt: ren gatewaykostnad, utan modellatens att gömma sig bakom. Det här är siffrorna en kapacitetsplan behöver. De är inte skälet att välja en control plane.
4 vCPU, utan databas
| Samtidiga klienter | Wäg req/s | Wäg p99 | Wäg CPU | LiteLLM req/s | LiteLLM p99 | LiteLLM CPU | × |
|---|---|---|---|---|---|---|---|
| 1 | 6 232 | 0,27 ms | 63,4% | 463 | 3,2 ms | 98,1% | 13× |
| 8 | 25 711 | 0,70 ms | 311,5% | 1 237 | 15 ms | 286,1% | 21× |
| 32 | 25 093 | 2,6 ms | 321,8% | 1 621 | 46 ms | 385,1% | 15× |
| 128 | 23 639 | 11 ms | 328,3% | 1 669 | 111 ms | 396,2% | 14× |
| 512 | 22 407 | 45 ms | 336,9% | 1 569 | 749 ms | 391,6% | 14× |
1 vCPU, utan databas
| Samtidiga klienter | Wäg req/s | Wäg p99 | LiteLLM req/s | LiteLLM p99 | × |
|---|---|---|---|---|---|
| 1 | 6 589 | 0,35 ms | 459 | 3,2 ms | 14× |
| 8 | 16 594 | 1,3 ms | 484 | 26 ms | 34× |
| 32 | 15 226 | 3,8 ms | 506 | 85 ms | 30× |
| 128 | 13 264 | 15 ms | 505 | 438 ms | 26× |
Vad det betyder: Det avgör hur många repliker en trafiknivå kräver, och därmed vad gatewayen kostar att driva. För Kubernetes är tabellen med 1 vCPU den som gäller: det är effektiviteten per kärna som en pod faktiskt får.
Strömning, payloads, embeddingar, failover
4 vCPU, utan databas. Strömmar är 50 tokens med 5 ms mellanrum; uthållighetstestet skickar 200 strömmar per sekund med svar på ungefär 1,2 sekunder under tre minuter.
| Scenario | Wäg | Wäg p99 | Wäg Fel | LiteLLM | LiteLLM p99 | LiteLLM Fel | × |
|---|---|---|---|---|---|---|---|
| Streaming, 64 clients | 233 | 286 ms | 0,00% | 179 | 674 ms | 0,00% | 1,3× |
| Streaming, 256 clients | 911 | 288 ms | 0,00% | 307 | 1,09 s | 0,00% | 3,0× |
| 64 KB conversation history, 32 clients | 3 583 | 29 ms | 0,00% | 568 | 106 ms | 0,00% | 6,3× |
| Embeddings (1,536 dims), 32 clients | 13 558 | 4,3 ms | 0,00% | 740 | 69 ms | 0,00% | 18× |
| Fallback after upstream 500, 16 clients | 19 816 | 1,8 ms | 0,00% | 584 | 62 ms | 0,00% | 34× |
| Soak: 200 streams/s for 3 minutes | 200 | 1,27 s | 0,00% | 176 | 20 s | 12,09% | 1,1× |
Vad det betyder: Strömning, långa prompter, embeddingar och failover är där en produktionslast tillbringar tiden. Läs felkolumnerna före genomströmningskolumnerna: en misslyckad förfrågan är en misslyckad användarförfrågan, inte en långsam.
Siffran för 64 KB-payloads ligger vid riggens tak: utan gateway i vägen når samma last 3 711 förfrågningar/s med 64 KB-kroppar på en kärna, så Wäg-siffran där är en undre gräns och inte ett maximum.
Vad detta inte visar
Varje benchmark beskriver en uppställning. Det här är gränserna för den här.
- Absoluta tal beror på värden. Båda gatewayerna kördes på samma maskin med låsta kärnor, så jämförelsen dem emellan håller, men räkna med andra absoluta tal på er egen hårdvara.
- Testriggen bakom de här körningarna är inte publicerad, så ni kan inte upprepa dem kommando för kommando. Metoden ovan är beskriven tillräckligt utförligt för att bygga en likvärdig uppsättning.
- LiteLLM släpper nästan varje vecka. Siffrorna är mätta mot v1.104.2, den aktuella stabila versionen. När en version ändrar vidarebefordringsvägen mäter vi om och publicerar vad vi får fram.
- LiteLLM konfigurerades utifrån sin produktionsguide, inte av sina underhållare. Det kan finnas en bättre konfiguration; hittar ni en kör vi om och publicerar på nytt.
- Båda gatewayerna kördes på en maskin med låsta kärnor. Inget här mäter beteende över ett nätverk, under Kubernetes-schemaläggning eller med störande grannar.