Kostet Sie ein Sovereign AI Gateway Geschwindigkeit?

Jedes Team, das On-Premise-KI evaluiert, stellt sich dieselbe Frage. Ein Gateway, das Authentifizierung, Anfragezulassung, Wiederholungen und Observability hinzufügt, klingt nach Overhead. Overhead klingt nach Latenz. Macht also das Vorschalten einer Enterprise-Schicht vor Ihr Modell dieses langsamer?

Wir haben es gemessen und den Test so konzipiert, dass er gegen uns arbeitet.

Die wichtigsten Erkenntnisse

• Auf identischer Hardware und mit denselben Modellgewichten erreichte das Xinity-Gateway bei der Token-Rate pro Stream dieselbe Geschwindigkeit wie das reine vLLM und übertraf es beim maximalen Durchsatz.

• Bei 512 gleichzeitigen Benutzern mit Prompts von 65.536 Token schloss Xinity 85,0 % der Anfragen erfolgreich ab. Das reine vLLM schloss 4,6 % ab.

• Das bedeutet, dass unter extremer Last, also an dem Punkt, an dem ein unkonfigurierter Server abstürzt, bis zu 18-mal mehr Anfragen erfolgreich abgeschlossen werden.

• Die einzigen Kosten sind etwa 56 ms zusätzliche Zeit bis zum ersten Token (Time to First Token, TTFT), was am Netzwerkpfad liegt, nicht am Modell.

• Das Gateway lief über das öffentliche Internet mit WireGuard und TLS. Das reine vLLM lief auf Loopback (Localhost) ohne jegliches Netzwerk. Wir haben trotzdem gewonnen.

Der ehrliche Test

Die Versuchung bei einem herstellerseitigen Benchmark ist groß, die Bedingungen zu den eigenen Gunsten zu beeinflussen. Wir haben sie in die andere Richtung beeinflusst.

Beide Durchläufe nutzten dieselbe Benchmark-Umgebung, dieselbe Hardware und dieselben Modellgewichte. Die einzige Variable war der Netzwerkpfad.

• Xinity-Gateway: Anfragen liefen über das öffentliche Internet, durch einen WireGuard-Tunnel und anschließend über eine TLS-Terminierung. Etwa 60 IP-Hops, bevor ein Token generiert wurde.

• Reines vLLM: Anfragen erreichten das Modell über Loopback (Localhost). Null Netzwerk dazwischen.

Wenn ein Gateway die Geschwindigkeit bremst, deckt dieses Setup das gnadenlos auf. Wir haben der Baseline jeden Vorteil gegeben und uns selbst absichtlich benachteiligt.

Das Setup

• Hardware: 1x NVIDIA DGX Spark, 128 GB

• Modell: Qwen 3.6-35B-A3B-FP8

• Szenarien: 120, bestehend aus 5 Eingabegrößen, 3 Ausgabegrößen und 8 Nebenläufigkeitsstufen (Concurrency)

• Prompt-Größe: 256 bis 65.536 Token

• Ausgabelänge: 64 bis 2.048 Token

• Nebenläufigkeit (Concurrency): 1 bis 512 aktive Anfragen parallel

• Volumen: 31.200 Anfragen pro Durchlauf

Die Ergebnisse

Der entscheidende Wert ist die Erfolgsquote (Completion Rate) unter Last. Beide Systeme bedienen einzelne Streams mit der gleichen Geschwindigkeit. Der Unterschied zeigt sich, wenn das System ausgelastet ist. Das reine vLLM hält bis zu etwa 8 gleichzeitigen Benutzern stand und stürzt dann ab. Xinity bleibt über den gesamten Verlauf bis hin zu 512 Benutzern fast konstant an der Spitze des Diagramms.

Warum ist das Gateway unter Last schneller und nicht langsamer?

Dies ist der kontraintuitive Teil, daher erklären wir den Mechanismus im Folgenden in einfachen Worten.

Die Verzögerung beim ersten Token liegt rein am Netzwerk

Die Differenz von 56 ms bei der Zeit bis zum ersten Token ist die Roundtrip-Zeit über das öffentliche Internet, WireGuard und TLS. Das sind die Kosten des Netzwerkpfads, nicht der Gateway-Logik. Sobald die Generierung beginnt, ist die Token-Rate pro Stream mit 50,0 Tok/s absolut identisch.

Begrenzte Anfragezulassung hält den Scheduler stabil

Der maximale Gesamtdurchsatz ist über das Gateway höher, weil eine kontrollierte Anfragezulassung den Scheduler von vLLM in seinem effizienten Arbeitsbereich hält. Ein unkonfigurierter Server akzeptiert alles auf einmal, fängt an zu „Thrashen“ (Überlastung durch Ressourcenwechsel) und sein effektiver Durchsatz bricht ein. Die Zulassungssteuerung (Admission Control) bedeutet hier keinen Overhead. Sie sorgt vielmehr dafür, dass die Hardware ihre Arbeit optimal erledigen kann.

Transparente Wiederholungsversuche fangen Fehler ab, bevor sie den Client erreichen

Unter anhaltender Überlastung beginnt das reine vLLM fehlerhafte Streaming-Chunks auszugeben. Der Client stellt Parse-Fehler im Stream fest und die Anfrage schlägt fehl. Das Xinity-Gateway fängt diese Fehler intern ab und sendet die Anfrage erneut, noch bevor der Fehler den Aufrufer erreicht. Das ist der Unterschied zwischen einer Erfolgsquote von 4,6 % und 85,0 %.

Das Ergebnis ist ein System, das in der Produktion nutzbar bleibt, anstatt bei der ersten Traffic-Spitze zusammenzubrechen.

Was das für regulierte Branchen bedeutet

Wenn Sie KI im Finanzwesen, im Gesundheitswesen, im Rechtsbereich oder im öffentlichen Sektor einsetzen, ist die interessante Zahl nicht die Anzahl der Token pro Sekunde auf einem System im Leerlauf. Es zählt vielmehr, wie viele Anfragen erfolgreich abgeschlossen werden, wenn am Montagmorgen um 9:00 Uhr alle Benutzer gleichzeitig auf das System zugreifen.

Ein Modell, das isoliert betrachtet schnell ist, aber unter Last 95 % der Anfragen fallen lässt, ist kein produktionsreifes System. Es ist eine Demo. Die Gateway-Schicht macht aus nackter Inferenz ein System, das Sie echten Benutzern auf Ihrer eigenen Hardware zur Verfügung stellen können, ohne Daten in die Cloud eines Drittanbieters senden zu müssen.

Das ist es, was wir unter „souverän durch Architektur, nicht durch Verträge“ verstehen. Die Kontrolle liegt in der Infrastruktur, nicht in einer Auftragsverarbeitungsvereinbarung.

Ehrliche Einschränkungen

Wir möchten, dass Sie den Zahlen vertrauen, anstatt später von ihnen überrascht zu werden.

• Die Zeit bis zum ersten Token ist über das Gateway um etwa 56 ms langsamer. Für ein System im öffentlichen Internet im Vergleich zu einem auf Loopback ist das zu erwarten und minimal. Wenn Ihr Workload aus vielen winzigen Einzelschuss-Prompts ohne Nebenläufigkeit besteht, fühlt sich das reine vLLM auf derselben Maschine beim ersten Token geringfügig schneller an.

• „Bis zu 18-mal mehr“ beschreibt das Extremverfahren. Gemessen wurde dies bei 512 gleichzeitigen Benutzern bei Prompts mit 65.536 Token – dem anspruchsvollsten Szenario des Tests. Bei geringer Nebenläufigkeit liegen die beiden Systeme nah beieinander, da noch nichts überlastet ist. Das Gateway spielt seine Vorteile erst bei steigender Last voll aus.

• Dies ist ein reiner Vergleich der Netzwerkpfade. Wir haben bewusst nur eine Variable isoliert. Es ist ein fairer Weg, um die Frage „Kostet das Gateway Geschwindigkeit?“ zu beantworten – und die Antwort lautet Nein.

Häufig gestellte Fragen (FAQs)

Reduziert das Hinzufügen eines Enterprise-Gateways zu vLLM die Inferenzgeschwindigkeit? Nein. In unserem Benchmark war die Token-Generierungsrate pro Stream mit 50,0 Tok/s identisch und der Spitzendurchsatz über das Gateway sogar höher. Die einzigen messbaren Kosten waren etwa 56 ms zusätzliche Zeit bis zum ersten Token, was auf den Netzwerkpfad zurückzuführen ist.

Wie hoch ist der Unterschied bei der Erfolgsquote zwischen Xinity und reinem vLLM unter Last? Bei 512 gleichzeitigen Benutzern bei Prompts mit 65.536 Token schloss das Xinity-Gateway 85,0 % of der Anfragen ab (870 von 1024), während das reine vLLM 4,6 % (47 von 1024) abschloss – also etwa 18-mal mehr.

Warum versagt ein unkonfigurierter vLLM-Server unter hoher Nebenläufigkeit? Ohne Anfragezulassungssteuerung akzeptiert der Scheduler zu viele Anfragen auf einmal und verlässt seinen effizienten Arbeitsbereich. Unter anhaltender Überlastung gibt er zudem fehlerhafte Streaming-Chunks aus, die beim Client als Fehler ankommen. Ein Gateway mit begrenzter Zulassung und transparenten Wiederholungen verhindert beides.

Welche Hardware und welches Modell wurden verwendet? Eine einzelne NVIDIA DGX Spark mit 128 GB, auf der Qwen 3.6-35B-A3B-FP8 lief, getestet in 120 Szenarien und mit 31.200 Anfragen pro Durchlauf.

Ist dieser Benchmark reproduzierbar? Ja. Beide Durchläufe verwendeten denselben Code für die Testumgebung, dieselbe Hardware und dieselben Modellgewichte. Der einzige Unterschied war der Netzwerkpfad. Vollständige Berichte pro Szenario und aggregierte Zusammenfassungen sind zusammen mit den Daten veröffentlicht.

Methodik und Daten

Beide Durchläufe nutzten dieselbe Benchmark-Umgebung, dieselbe DGX Spark und dieselben Qwen 3.6-35B-A3B-FP8-Gewichte. Der Xinity-Pfad lief von einem öffentlichen Endpunkt über das Internet, durch WireGuard bis zur TLS-Terminierung auf dem Server. Der reine vLLM-Pfad lief über Loopback. Jeder Durchlauf deckte 120 Szenarien ab (5 Eingabegrößen mal 3 Ausgabegrößen mal 8 Nebenläufigkeitsstufen bei insgesamt 31.200 Anfragen).

Vollständige Berichte pro Szenario und aggregierte Zusammenfassungen sind auf Anfrage erhältlich. Wenn Sie den Test auf Ihrer eigenen Hardware ausführen möchten, teilen wir die Testumgebung gerne mit Ihnen.

Souverän durch Architektur, nicht durch Verträge. Erfahren Sie, wie Xinity auf Ihrer Infrastruktur läuft, unter xinity.ai.