Benchmarks
Wie sich das Wäg-Gateway unter identischen Bedingungen gegen LiteLLM schlägt. Diese Seite legt die Methode vollständig offen und veröffentlicht die damit erzeugten Messwerte. Multiplikatoren veröffentlichen wir nicht.
So wurde gemessen
Alles lief in Docker auf einer Maschine, jede Komponente auf eigene Kerne fixiert, damit nichts um CPU konkurrierte.
- Beide Gateways stehen vor demselben Upstream mit identischer Modellkonfiguration, keines hat also den leichteren Weg.
- Jedes Gateway läuft so, wie es die eigene Dokumentation empfiehlt: LiteLLM nach seinem Produktionsleitfaden mit Workern in Höhe der vCPUs, Wäg mit den ausgelieferten Standardwerten. Response-Caching ist bei beiden aus.
- Closed-Loop-Tests messen den maximalen Durchsatz. Open-Loop-Tests senden nach festem Zeitplan und rechnen die Latenz ab dem vorgesehenen Sendezeitpunkt — ein Gateway, das Anfragen staut, kann das Stauen also nicht verbergen.
- Jede Antwort wird geprüft: Status, Struktur des Bodys und bei Streams die erwartete Anzahl Chunks samt Abschluss. Alles andere zählt als Fehler, nie als schnelle Antwort.
- Jedes Szenario läuft dreimal; die Tabellen zeigen den Median. Ohne Gateway im Pfad erreicht dieselbe Last rund 90.000 Anfragen/s, weit mehr als beide Gateways — die Ergebnisse sind also durch das Gateway begrenzt, nicht durch das Harness.
Fussabdruck
Was jedes Gateway kostet, bevor es irgendetwas ausliefert: Speicher im Leerlauf, Startzeit, Imagegrösse und die Latenz, die es einer einzelnen Anfrage gegen einen sofort antwortenden Upstream hinzufügt.
Was das bedeutet: Der Speicher bestimmt, wie viele Replicas auf einen Knoten passen, die Imagegrösse, wie schnell ein Rollout ist. Mit 3,8 MB im Speicher und einem 123-MB-Image passt Wäg in einen Sidecar und ist bereit, bevor ein Health-Check ausläuft; 2,3 GB und 11 Sekunden sind ein Pod, um den man planen muss.
Die zusätzliche Latenz ist der p50 des Gateways abzüglich des p50, der ohne Gateway im Pfad gemessen wurde.
Mit realistischem Upstream
Ein echtes Modell antwortet in Hunderten von Millisekunden, also sind Tausende Anfragen gleichzeitig unterwegs. Hier braucht der Upstream 300 ms, und Anfragen treffen mit fester Rate ein, was das Gateway auch tut. Bei 2.000 Anfragen/s sind jederzeit rund 600 Anfragen in Bearbeitung.
| Anfragen pro Sekunde | Wäg p50 | Wäg p99 | Wäg Fehler | Wäg CPU | LiteLLM p50 | LiteLLM p99 | LiteLLM Fehler | 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× |
Was das bedeutet: So sieht echter Verkehr aus: Ein Modell antwortet in Hunderten von Millisekunden, Tausende Anfragen sind gleichzeitig unterwegs. Ein Gateway, das staut, macht aus einer 300-ms-Antwort eine von mehreren Sekunden — und es fällt erst zur Spitzenlast auf. Wäg bleibt bis 2.000 Anfragen/s an der Untergrenze, mit weniger als einem Drittel seines CPU-Budgets. LiteLLM staut bereits bei 1.000 und lässt bei 2.000 acht Prozent der Anfragen scheitern.
Der Upstream allein braucht 300 ms, das ist die Untergrenze. Alles darüber ist Wartezeit in der Warteschlange des Gateways. Die Spalte × ist immer gleich zu lesen: höher heisst, Wäg liegt vorn. Beim Durchsatz ist es Wäg ÷ LiteLLM, bei der Latenz LiteLLM ÷ Wäg.
Durchsatz und Latenz
Closed Loop gegen einen sofort antwortenden Upstream: reine Gateway-Kosten, ohne Modelllatenz zum Dahinterverstecken. Das sind die Zahlen für die Kapazitätsplanung. Sie sind nicht der Grund, eine Control Plane zu wählen.
4 vCPU, ohne Datenbank
| Gleichzeitige Clients | 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, ohne Datenbank
| Gleichzeitige Clients | 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× |
Was das bedeutet: Das bestimmt, wie viele Replicas ein Verkehrsniveau braucht — und damit die Betriebskosten des Gateways. Für Kubernetes ist die Tabelle mit 1 vCPU die entscheidende: Das ist die Effizienz pro Kern, die ein Pod tatsächlich bekommt.
Streaming, Payloads, Embeddings, Failover
4 vCPU, ohne Datenbank. Streams bestehen aus 50 Tokens im Abstand von 5 ms; der Dauertest fährt drei Minuten lang 200 Streams pro Sekunde mit Antworten von rund 1,2 Sekunden.
| Szenario | Wäg | Wäg p99 | Wäg Fehler | LiteLLM | LiteLLM p99 | LiteLLM Fehler | × |
|---|---|---|---|---|---|---|---|
| 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× |
Was das bedeutet: Streaming, lange Prompts, Embeddings und Failover sind die Pfade, auf denen eine Produktionslast ihre Zeit verbringt. Lesen Sie die Fehlerspalten vor den Durchsatzspalten: Eine fehlgeschlagene Anfrage ist eine fehlgeschlagene Nutzeranfrage, keine langsame.
Der Wert für 64-KB-Payloads liegt an der Obergrenze des Harness: Ohne Gateway im Pfad erreicht dieselbe Last 3.711 Anfragen/s mit 64-KB-Bodies auf einem Kern. Die Wäg-Zahl ist dort also eine Unter-, keine Obergrenze.
Was hier nicht gezeigt wird
Jeder Benchmark beschreibt einen Aufbau. Das sind die Grenzen dieses Aufbaus.
- Absolute Zahlen hängen vom Host ab. Beide Gateways liefen auf derselben Maschine mit fixierten Kernen, der Vergleich untereinander trägt also — erwarten Sie auf Ihrer eigenen Hardware aber andere absolute Werte.
- Das Harness hinter diesen Läufen ist nicht veröffentlicht, Sie können sie also nicht Befehl für Befehl wiederholen. Die Methode oben ist ausführlich genug beschrieben, um einen gleichwertigen Aufbau nachzubauen.
- LiteLLM veröffentlicht fast wöchentlich. Diese Werte wurden gegen v1.104.2 gemessen, die aktuelle stabile Version. Sobald eine Veröffentlichung den Weiterleitungspfad verändert, messen wir erneut und zeigen das Ergebnis.
- LiteLLM wurde nach seinem Produktionsleitfaden konfiguriert, nicht von seinen Maintainern. Es mag eine bessere Konfiguration geben; wenn Sie eine finden, messen wir neu und veröffentlichen erneut.
- Beide Gateways liefen auf einer Maschine mit fixierten Kernen. Nichts hiervon misst das Verhalten über ein Netzwerk, unter Kubernetes-Scheduling oder mit lauten Nachbarn.