vLLM im Konzern: interner KI-Dienst für 100+ Entwickler

Ein erster vLLM-Endpunkt ist schnell konfiguriert. Acht GPUs, ein OpenAI-kompatibler Endpunkt, gute erste Antworten. Und dann blockiert ein einziger Entwickler mit drei parallelen Agenten die GPUs für alle anderen. Das ist kein Modellproblem. vLLM kennt weder Teams noch Prioritäten.

Der schwierige Teil beim Selbsthosten ist nicht das Modell. Es sind Identität, Quoten, faire Warteschlangen, Kontextgrößen, Client-Kompatibilität, Updates und ein Betriebsmodell. Also alles, was aus einem Modellserver einen internen KI-Dienst macht.

So sind die Zahlen in diesem Artikel zu lesen

• Dokumentiert: aus Modellkarten oder aktueller Produktdokumentation
• Berechnet: aus dokumentierten Werten abgeleitet
• Exemplarisch: Annahme für die fiktive Fixstern Versicherung
• Gemessen: nur Werte aus einem tatsächlich ausgeführten Benchmark

Dieser Artikel enthält noch keine eigenen Produktionsbenchmarks.

Technischer Stand: 29. August 2026. Angaben zu Modellen, Laufzeitumgebungen und Preisen können schnell veralten. Vor einer Entscheidung sollten sie anhand der jeweils aktuellen Primärquellen überprüft werden.

Überblick

• Ausgangslage: Beispielorganisation · Modellauswahl
• Dimensionierung: Drei Dienste · Kontextlimit · Hardware-Rechnung
• Zugang und Fairness: Referenzarchitektur · Identität · Fairness · Client-Seite · Kompatibilitätsprüfung
• Serving und Lifecycle: vLLM-Konfiguration · Prefix Caching · Netzwerkgrenzen · Updates
• Betrieb und Wirtschaftlichkeit: Beobachtung und SLOs · Runbooks · Kosten · Hybrid-Entscheidung · Rollout

vLLM ist der Motor, nicht das Verkehrssystem

vLLM weiß nicht, ob eine Anfrage aus einer interaktiven IDE, einem nächtlichen Batch-Job oder einer automatischen Pull-Request-Prüfung stammt. Es weiß auch nicht, ob ein Entwickler schon fünf weitere Anfragen laufen hat. Das Modell ist nicht abgestürzt und die GPUs sind ausgelastet. Genau das ist das Problem: Auslastung ohne Fairness.

Wer ein selbst gehostetes Coding-Modell für mehr als hundert Entwickler bereitstellt, baut deshalb keinen Modellserver. Er baut einen internen KI-Dienst. vLLM ist der Motor. Gateway, Scheduler und Betriebsmodell sind das Verkehrssystem.

Der Betrieb dieses Dienstes ist nur ein Ausschnitt. Der Leitfaden für KI Coding Agents ordnet im größeren Zusammenhang ein, wie Entwicklerteams KI Coding Agents einführen und absichern.

Der vorherige Artikel behandelt die Hosting-Entscheidung zwischen eigenem Rechenzentrum, privater Cloud und externem Anbieter. Sie legt die Kontrollgrenze fest, sagt aber noch nicht, wie der Dienst innerhalb dieser Grenze betrieben wird.

Dieser Artikel behandelt das Hosting und die gemeinsame Inferenzplattform. Die Absicherung der vom Agenten ausgeführten Tools, Shell-Kommandos und MCP-Server ist eine eigene Sicherheitsschicht und nicht Thema dieses Textes. Ebenfalls nicht behandelt: Sandbox- und Workstation-Sicherheit, Repository-Berechtigungen, Tool-Autorisierung und Prompt-Injection in Repository-Inhalten.

Die Beispielorganisation

Die fiktive Fixstern Versicherung beschäftigt 120 Entwickler in 15 Teams. Die Anwendungen reichen von normalen internen Services bis zu Systemen mit personenbezogenen und regulatorisch relevanten Daten. Das Unternehmen hat bereits Kubernetes, einen zentralen Identitätsanbieter, ein internes PKI-System (Public Key Infrastructure), Prometheus, Grafana, einen Object Store und ein GitOps-Verfahren.

Der erste Beschaffungsentwurf sieht einen Server mit acht GPUs vor.

Das klingt nach einer konkreten Hardwareplanung. Tatsächlich ist es nur eine Pilotplanung.

Für den Artikel gelten folgende Annahmen:

Die wichtigste Erkenntnis folgt bereits aus der Modellgröße:

Ein gewöhnlicher Server mit acht H100-, H200- oder B200-GPUs kann Kimi K3 nicht als einzelne vollständige Replik betreiben.

Damit verändert sich die Architektur. GLM-5.3-Flash wird im Beispiel als Kandidat für das wirtschaftlich realistischere Standardmodell evaluiert. Kimi K3 bleibt zunächst eine Vorabversion, die hier nur als technischer Grenzfall dient und auf eigener Hardware läuft, oder ein vertraglich abgesicherter externer Dienst.

Die Entscheidung in 60 Sekunden Fixstern plant GLM als internen Standarddienst, vorbehaltlich der internen Evaluation. LiteLLM verwaltet Identitäten und Quoten. Envoy und llm-d steuern zentral, welche Anfragen wann an eine Modellreplik weitergeleitet werden. vLLM läuft in einem gemeinsamen GLM-Pool mit getrennten Zugangsklassen für Standardanfragen und lange Kontexte sowie in eigenen Pools für Autocomplete und Embeddings. Kimi K3 bleibt vorerst im Testbetrieb oder wird für freigegebene Datenklassen über einen externen Anbieter genutzt.

Die gezeigte Architektur ist eine Referenz für die Annahmen von Fixstern, keine allgemeingültige Produktvorgabe.

Ein Leaderboard ist noch keine Produktionsentscheidung

Kimi K3 und GLM-5.3-Flash stehen auf aktuellen Open-LLM-Ranglisten weit oben. Das rechtfertigt einen technischen Test, aber noch keine Beschaffung.

Die Ergebnisse auf Vellums Rangliste wurden nicht durchgehend mit identischen Testaufbauten ermittelt. Bei Kimi K3 wurden unter anderem Kimi Code und Claude Code verwendet. Bei GLM-5.3-Flash kamen ebenfalls konkrete Claude-Code-Versionen und besondere Kontextkonfigurationen zum Einsatz. Unterschiede im verwendeten Agenten-Framework, in der Kontextkomprimierung und in den Werkzeugbeschreibungen können mehrere Prozentpunkte ausmachen. Die Werte sind deshalb keine direkte Messung dessen, was das Modell hinter dem eigenen vLLM-Endpunkt leisten wird. (Vellum Open LLM Leaderboard, Kimi-K3-Modellkarte, GLM-5.3-Flash-Modellkarte)

Die richtige Reihenfolge lautet:

1. Das Leaderboard liefert Kandidaten.
2. Die Modellkarte liefert technische Grenzen.
3. Ein interner Testsatz prüft die eigenen Repositories.
4. Ein Lasttest bestimmt die nutzbare Kapazität.
5. Erst danach folgt die Beschaffung.

Die Auswahl von GLM-5.3-Flash und Kimi K3 soll nicht bedeuten, dass beide Modelle für jedes Unternehmen die beste Wahl sind. Sie stehen vielmehr für zwei unterschiedliche Betriebsprofile: Bei GLM belegt eine Replik vier GPUs, bei Kimi einen vollständigen, leistungsstarken GPU-Knoten.

Ein Coding-Agent braucht mehr als einen Modellendpunkt

Die Plattform von Fixstern stellt nicht nur einen Dienst bereit, sondern drei unterschiedliche Dienste.

1. Das Agent-Modell

Dieses Modell plant Änderungen, liest Dateien, ruft Tools auf, verarbeitet Build-Ausgaben und arbeitet über viele Schritte hinweg.

Dafür gibt es vier Aliasse:

Die Clients verwenden nur den Alias. Welche Modellrevision dahinter läuft, entscheidet das Plattformteam. So lässt sich eine neue Revision zunächst mit einem kleinen Teil der Anfragen testen und bei Problemen zurücksetzen, ohne 120 Entwicklerrechner neu zu konfigurieren.

2. Das Autocomplete-Modell

Autocomplete erzeugt viele kurze Anfragen. Die Latenz ist wichtiger als tiefe Planung. Ein Vorschlag, der erst nach zwei Sekunden erscheint, kommt für die Inline-Nutzung zu spät.

Dieser Dienst gehört nicht in denselben Pool wie ein großes Agent-Modell. Ein Prefill mit langem Kontext darf nicht die nächste Inline-Vervollständigung blockieren.

Als Kandidat könnte Fixstern beispielsweise ein spezialisiertes Modell wie JetBrains/Mellum-4b-base prüfen. Mellum ist ein 4B-Modell für Code Completion mit Fill-in-the-Middle-Unterstützung. Es ist allerdings ein Basismodell und nicht automatisch ein produktionsreifer Standard. Seine Qualität müsste anhand der eigenen Repositories in den im Unternehmen verwendeten Sprachen getestet werden. (Hugging Face)

Das Ziel für code-completion könnte lauten:

• zwei unabhängige Repliken
• kleine dedizierte GPUs
• kurze Prompt-Limits
• kurze Output-Limits
• kein Reasoning
• keine Tool Calls
• p95-Latenzziel unter 200 Millisekunden

Das Ziel unter 200 Millisekunden meint die Ende-zu-Ende-Latenz vom Tastendruck bis zur sichtbaren Vervollständigung, nicht allein die reine Modelllatenz.

3. Der Embedding-Dienst

Repository-Indexierung ist überwiegend ein Batch- und Retrieval-Problem. Sie hat ein anderes Lastprofil als interaktive Agenten.

Ein aktueller Kandidat ist Qwen/Qwen3-Embedding-4B. Das Modell unterstützt bis zu 32.000 Tokens, variable Embedding-Dimensionen und mehrsprachige sowie codebezogene Retrieval-Aufgaben. Auch dieser Dienst bekommt einen eigenen Pool und ein eigenes Budget. (Hugging Face)

Ein nächtlicher Neuaufbau des Repository-Index darf niemals mit einem Entwickler um dieselbe Agent-Replik konkurrieren.

128K ist ein festgelegtes Kontextlimit, keine Modellgrenze

Sowohl GLM-5.3-Flash als auch Kimi K3 geben ein Kontextfenster von rund einer Million Tokens an. Daraus folgt nicht, dass jeder Entwickler standardmäßig eine Million Tokens verwenden sollte.

Aktuelle Coding-Agenten beginnen häufig bereits mit einem umfangreichen System-Prompt, Tool-Definitionen, Repository-Anweisungen und Session-Historie. Bei einer mehrstufigen Aufgabe kann der Kontext schnell auf 60.000 bis 120.000 Tokens anwachsen. Ein Standardlimit von 32.000 Tokens wäre deshalb zu klein.

Fixstern legt fest:

coding-standard: 131.072 Tokens
coding-long:     262.144 Tokens
coding-premium:  262.144 Tokens
coding-batch-1m: nur für genehmigte Evaluationen und Batch-Jobs

coding-batch-1m ist dabei kein regulärer Client-Alias aus der Tabelle oben, sondern eine gesondert freigeschaltete Zugangsklasse. Sie wird nur für genehmigte Evaluationen und Batch-Jobs geöffnet und läuft mit Batch-Priorität.

Die native Modellgrenze bleibt technisch verfügbar. Sie ist aber kein Produktversprechen.

Kimi selbst verwendet in veröffentlichten Evaluationen ab bestimmten Kontextgrößen eine Kontextkomprimierung. GLM-Evaluationen arbeiten ebenfalls mit expliziter Kontextverwaltung. Auch mit einer Million Tokens erübrigt sich die Aufbereitung und Begrenzung des Kontexts nicht. Ein größeres Kontextfenster verschiebt nur den Punkt, an dem schlechte Kontextpflege endgültig teuer wird. (Kimi-K3-Modellkarte, GLM-5.3-Flash-Modellkarte)

vLLM reserviert dabei nicht für jede Anfrage sofort den kompletten maximalen Kontext. Der KV-Cache wird seitenweise und abhängig von den tatsächlich aktiven Tokens belegt. Trotzdem verändert ein höheres Kontextlimit die mögliche Parallelität massiv, weil lange Sessions den Speicher länger belegen und mehr Prefill-Arbeit erzeugen.

Die erste Hardware-Rechnung

Für GPU-Speicher verwendet dieser Artikel GiB und TiB. Dezimale Herstellerangaben werden beim ersten Auftreten zusätzlich genannt.

GLM-5.3-Flash

GLM-5.3-Flash ist ein Mixture-of-Experts-Modell mit rund 321 Milliarden Gesamtparametern und 18 Milliarden aktiven Parametern pro Token. Der Standard-Checkpoint enthält native FP8-Gewichte und benötigt ohne Runtime- und KV-Cache-Overhead ungefähr 306 GiB. Die BF16-Variante benötigt grob das Doppelte. Das Modell unterstützt rund eine Million Tokens Kontext und setzt laut aktuellem vLLM-Konfigurationsbeispiel mindestens vLLM 0.29.0 voraus. Das aktuelle Konfigurationsbeispiel empfiehlt außerdem ein dediziertes Docker-Image, solange die Integration nicht vollständig im öffentlichen Hauptzweig ist. (vLLM Recipes)

Für den Betrieb auf vier MI355X-GPUs mit Tensor Parallelism 4 weist das aktuelle vLLM-Konfigurationsbeispiel für den FP8-Checkpoint einen KV-Pool von ungefähr 14,92 Millionen Tokens aus.

Rein speicherseitig ergibt das:

14.920.000 / 131.072 ≈ 113,8 Sequenzen bei 128K
14.920.000 / 262.144 ≈ 56,9 Sequenzen bei 256K

Diese Zahlen sind keine nutzbare Servicekapazität. Sie zeigen nur, wie viele vollständig gefüllte Sequenzen theoretisch in den ausgewiesenen Cache passen könnten. Time to First Token (TTFT), Time per Output Token (TPOT), Prefill-Kosten, Output-Länge, Tool-Calling und gewünschte Latenzen sind darin nicht berücksichtigt. Das aktuelle vLLM-Konfigurationsbeispiel sieht für einen Beispielbenchmark eine maximale Parallelität von 16 Anfragen vor. (vLLM Recipes)

Für Fixstern ergibt sich deshalb folgende Ausgangsarchitektur:

• 2 GPU-Knoten mit jeweils 8 × MI355X
• 2 GLM-Repliken pro Knoten
• 4 GPUs pro Replik
• Tensor Parallelism = 4
• insgesamt 4 unabhängige GLM-Repliken

Auf einem einzelnen 8-GPU-Knoten könnten zwei Repliken laufen. Ein solcher Knoten wäre aber gleichzeitig einzelner Ausfallpunkt und Kapazitätsgrenze und verhindert zugleich Wartung ohne Unterbrechung.

Zwei Knoten ermöglichen Failover. Sie liefern allerdings noch keine volle N+1-Kapazität. Fällt ein Knoten aus, verbleiben nur zwei der vier Repliken. Soll die Plattform auch bei Ausfall eines Knotens die volle Spitzenlast bedienen, braucht sie einen dritten Knoten oder muss im Normalbetrieb ungefähr die Hälfte der Kapazität als Reserve freihalten.

Kimi K3

Kimi K3 ist zum Veröffentlichungszeitpunkt eine Vorabversion (Pre-release) und dient hier als Beispiel für die obere Grenze des derzeit technisch Machbaren. Es ist keine uneingeschränkte Produktionsempfehlung.

Kimi K3 ist eine andere Größenklasse. Das Modell besitzt ungefähr 2,8 Billionen Gesamtparameter und aktiviert pro Token nur einen Teil davon. Der native MXFP4-Checkpoint benötigt laut aktuellem vLLM-Konfigurationsbeispiel mindestens rund 1.680 GB GPU-Speicher, etwa 1,53 TiB. Die empfohlene Einzelknoten-Konfiguration sieht acht GPUs mit Tensor Parallelism 8 vor. (vLLM Recipes)

Damit fallen viele verbreitete Systeme aus:

• 8 × H200: ungefähr 1,13 TB HBM (High Bandwidth Memory), zu wenig
• 8 × B200: ungefähr 1,44 TB HBM, zu wenig
• 8 × B300: mehr als 2,1 TB im aktuellen vLLM-Profil, ausreichend
• 8 × MI355X: von AMD für eine Kimi-K3-Instanz validiert

AMD beziffert den vollständigen Checkpoint auf rund 1,56 TB. In der veröffentlichten ATOM-Konfiguration ist die TP8-Belegung (Tensor Parallelism 8) wegen replizierter Tensoren jedoch nicht einfach durch acht teilbar: Pro MI355X werden rund 191 GiB Modellgewichte geladen. Zusammen mit den bekannten Zuständen für eine Sequenz mit einer Million Tokens ergibt sich eine Belegung von rund 205,4 GiB pro GPU. Vor weiteren Runtime-Overheads bleiben damit ungefähr 82,6 GiB. Für den konkreten vLLM-Ausführungspfad muss die tatsächliche Belegung mit dem freigegebenen Image erneut gemessen werden. Allgemeingültige Aussagen über TTFT oder den SLO-konformen Durchsatz, im Folgenden Goodput genannt, lassen sich daraus nicht ableiten. (AMD, vLLM Recipes)

Eine einzelne Kimi-Replik bedeutet somit:

• 1 vollständiger 8-GPU-Knoten
• Tensor Parallelism = 8
• keine zweite Replik
• keine Wartung ohne Unterbrechung
• kein Failover

Ein späterer produktiver Eigenbetrieb würde zwei unabhängige TP8-Repliken auf jeweils acht B300- oder MI355X-GPUs benötigen. Das wären 16 High-End-GPUs allein für einen internen Kimi-Dienst.

Bei Kimi K3 dominieren zunächst die Modellgewichte, nicht der Kontext. Der ausgewiesene Speicherbedarf für den Kontextzustand bei einer Million Tokens liegt pro GPU deutlich unter den rund 191 GiB der Gewichte. Trotzdem kostet der lange Kontext sehr viel Rechenzeit und senkt den Goodput. (AMD)

Warum Fixstern nicht einfach AWQ auswählt

Beide Modelle liegen bereits in hardwarebezogenen Niedrigpräzisionsformaten vor:

Eine nachträgliche Konvertierung ins AWQ-Format spart möglicherweise Speicher, verändert aber den Ausführungspfad, den Durchsatz, das numerische Verhalten und die Zuverlässigkeit der Werkzeugaufrufe. Für den Produktionsstart verwendet Fixstern deshalb die vom Modellanbieter und von vLLM dokumentierte Variante.

Jede andere Quantisierung muss dieselbe interne Abnahmesuite bestehen wie eine neue Modellrevision.

Die Referenzarchitektur

Die produktive Architektur sieht so aus:

LiteLLM kontrolliert Identität und organisatorische Limits. llm-d entscheidet anhand der verfügbaren Inferenzkapazität, wann eine Anfrage an vLLM weitergereicht wird.

KServe kann die Bereitstellung und Aktualisierung der vLLM-Instanzen über LLMInferenceService steuern. llm-d übernimmt das inferenzbewusste Routing und die vorgelagerte Laststeuerung (Flow Control). Die vLLM-Prozesse führen ausschließlich die Inferenz aus. (KServe, KServe)

Das Plattformteam darf nicht davon ausgehen, dass ein mitgeliefertes KServe- oder Helm-Image automatisch zu beiden Modellen passt. GLM-5.3-Flash setzt aktuell mindestens vLLM 0.29.0 voraus, Kimi K3 mindestens 0.27.1. Fixstern baut deshalb eine eigene ServingRuntime, deren Container-Image über den Digest versionsgenau festgelegt ist, und zertifiziert jede Kombination aus Runtime, Modell und Parser. (vLLM Recipes, vLLM Recipes)

LiteLLM braucht für diese Schicht zwei Zustandsspeicher. PostgreSQL hält Virtual Keys und das Nutzungstracking. Redis wird ab mehr als einer Proxy-Instanz für gemeinsame Rate-Limit-Zähler und Routingzustand nötig. Fällt Redis aus, setzt jede Instanz ihre Limits wieder getrennt durch, sodass das globale Limit in Summe überschritten werden kann. Ob die Ratenbegrenzungen in diesem Fall fail-open oder fail-closed reagieren, ist eine bewusste Konfigurationsentscheidung. Fällt PostgreSQL aus, kann die Admin-Oberfläche mit Keys und Budgets ausfallen, während die Datenebene mit bereits geladenem Zustand zunächst weiterläuft. (docs.litellm.ai)

Das eine Admin-Panel gibt es nicht

Große Anbieter wirken, als hätten sie eine einzige Verwaltungskonsole. Tatsächlich bündeln sie mehrere Systeme hinter einer Oberfläche.

Bei einer selbst betriebenen Plattform verteilt Fixstern die Aufgaben bewusst:

Der AMD GPU Operator kann Treiber, Device Plugin, Node Labels, Health Checks und den Device Metrics Exporter auf Kubernetes- und OpenShift-Clustern verwalten. Der Exporter stellt unter anderem Auslastung, Speicher, Temperatur, Stromverbrauch und PCIe-Metriken für Prometheus bereit. (instinct.docs.amd.com, instinct.docs.amd.com, instinct.docs.amd.com)

Die Antwort auf die Frage nach dem Admin-Panel lautet deshalb:

Kein einzelnes Open-Source-Produkt ersetzt die gesamte Steuerungsebene eines großen Modellanbieters. Man braucht eine Zugangsoberfläche, eine Betriebsoberfläche, ein Deployment-System und ein Audit-System.

Identität: Keine gemeinsamen API-Keys

Im Beispiel entscheidet sich Fixstern für LiteLLM Enterprise, weil SSO, SCIM, persönliche Identitäten und Audit-Protokolle nicht selbst entwickelt werden sollen.

LiteLLM OSS bietet bereits Virtual Keys, Benutzer, Teams, Budgets und grundlegende Nutzungs- und Kostenverfolgung. SSO, SCIM, OIDC/JWT, Audit-Protokolle und automatische Schlüsselrotation gehören jedoch zum Enterprise-Umfang. LiteLLM sieht diese Variante selbst für Umgebungen mit mehr als 100 Benutzern oder vielen produktiven Anwendungsfällen vor. (docs.litellm.ai)

Ein vorgeschalteter OIDC-Proxy wäre billiger, übernimmt aber nur die Authentifizierung am HTTP-Eingang. Persönliche Nutzungshistorie, pro Benutzer durchgesetzte Quoten, automatische Deaktivierung beim Austritt und sichere CLI-Authentifizierung wären damit noch nicht abgedeckt. All das müsste Fixstern selbst entwickeln.

Unternehmen mit einem strategisch gesetzten API-Gateway wie Kong können dieselben organisatorischen Kontrollen dort umsetzen. Die inferenzbewusste Admission Control bleibt davon unabhängig, denn ein klassisches API-Gateway ersetzt keine mandantenfaire Warteschlange vor den GPUs.

Der Zugangsprozess sieht deshalb so aus:

1. Eine Gruppe im Identitätsanbieter entspricht einem LiteLLM-Team.
2. SCIM provisioniert und entfernt Benutzer.
3. Clients mit JWT-Unterstützung senden ein kurzlebiges OIDC-Token.
4. LiteLLM ordnet den JWT-Client einer Richtlinie für persönliche virtuelle Schlüssel zu.
5. Clients ohne Token-Erneuerung erhalten einen persönlichen, zeitlich begrenzten Virtual Key.
6. Dienstkonten für CI und Batch erhalten eigene Identitäten und Quoten.
7. Der LiteLLM-Master-Key liegt ausschließlich im zentralen Geheimnisspeicher.

LiteLLM kann einzelne JWT-Clients über Claims wie sub, client_id oder azp persönlichen Virtual Keys zuordnen. Damit bleiben Modellzugriff, Budgets, RPM (Requests pro Minute) und TPM (Tokens pro Minute) pro Entwickler kontrollierbar, ohne jedem Client dauerhaft einen klassischen API-Key auszuhändigen. (docs.litellm.ai)

Für Clients, die nur statische Keys beherrschen, gelten folgende Regeln:

• maximale Laufzeit: 90 Tage
• Rotation mit kurzer Überlappung
• sofortige Sperre bei Offboarding
• keine Keys in gemeinsam versionierten Konfigurationsdateien
• keine Team-Keys
• keine Nutzung des Master-Keys durch Entwickler

Wenn jemand das Unternehmen verlässt, entfernt der Identitätsanbieter die Gruppenmitgliedschaft. SCIM deaktiviert den Benutzer. Noch aktive Virtual Keys werden gesperrt. Die Änderung erscheint im Audit-Protokoll und wird an das SIEM weitergeleitet.

Fairness braucht vier getrennte Schichten

Die vier folgenden Schichten erfüllen jeweils eine klar begrenzte Aufgabe. Werden ihre Limits vermischt, entsteht der Eindruck von Fairness, ohne dass eine Schicht sie durchsetzt.

Warum zwei Anfragen pro Entwickler nicht genügen

Eine naheliegende Rechnung lautet:

120 Entwickler × 2 parallele Requests = 240 mögliche Requests

Auf einem einzelnen 8-GPU-Knoten könnten zwei GLM-Repliken mit TP4 laufen. Selbst bei einem hypothetischen max-num-seqs 64 pro Replik ergäbe das:

2 Repliken × 64 Sequenzen = 128 Engine-Slots

240 mögliche Anfragen treffen auf 128 verfügbare Verarbeitungsplätze.

Schlimmer noch: max-num-seqs ist keine gemessene Servicekapazität. Es ist eine Obergrenze innerhalb der Engine. Schon deutlich vor diesem Wert können TTFT und TPOT das vereinbarte SLO (Service Level Objective) verfehlen.

Ein Parallelitätslimit pro Entwickler verhindert, dass eine Person 50 Anfragen startet. Es verhindert nicht, dass 100 Personen gleichzeitig jeweils zwei Anfragen senden.

Die Beispielrechnung für den Produktionsbetrieb

Für die folgende Beispielrechnung nehmen wir rein illustrativ ein Service-Level-Ziel mit TTFT p95 unter 2 Sekunden, TPOT p95 unter 60 Millisekunden und Wartezeit p95 unter 10 Sekunden an. Die produktiven Zielwerte legt Fixstern erst nach einem Lasttest fest und staffelt sie nach Eingabelänge. Erst ein festgelegtes Ziel macht die folgende Zahl prüfbar.

Für die Beispielrechnung gilt außerdem folgende Annahme:

Eine GLM-Replik hält das festgelegte Service-Level-Ziel bei bis zu 16 gleichzeitig aktiven Anfragen ein.

Dieser Wert wurde nicht gemessen. Im realen Projekt muss er durch einen Lasttest mit der tatsächlichen Verteilung von Promptlängen und Agentensitzungen ersetzt werden.

Alle vier Repliken des gemeinsamen GLM-Pools bedienen sowohl Standard- als auch Langkontextanfragen. Für den gesamten Pool ergibt sich:

4 × 16 = 64 SLO-konforme aktive Requests

Langkontextanfragen zählen gegen dieselbe Obergrenze, ein eigenes Budget gibt es für sie nicht. Fixstern reserviert zusätzlich 25 Prozent für Schwankungen:

64 × 0,75 = 48 reguläre Dispatch-Slots

Zunächst gelten folgende Grenzen:

Die maximale Wartezeit von 20 Sekunden widerspricht dem Wartezeitziel von p95 unter 10 Sekunden nicht. Das Ziel beschreibt den Normalbetrieb, die 20 Sekunden sind die harte Grenze, an der eine wartende Anfrage abgebrochen wird.

LiteLLM liefert einen 429, wenn ein persönliches oder Teamlimit überschritten wird.

llm-d liefert einen anderen 429, wenn die zentrale Warteschlange ihre konfigurierte Kapazität erreicht. Läuft die maximale Wartezeit ab, wird die Anfrage mit 503 Service Unavailable beendet. Bei aktivierter Laststeuerung leitet llm-d keine weiteren Anfragen an gesättigte Modellserver weiter. Stattdessen hält es sie in getrennten Warteschlangen im Arbeitsspeicher pro Fairness-ID und Priorität. (llm-d.ai)

Damit ist klar, wo der 429 bei GPU-Sättigung entsteht: in der Zulassungssteuerung (Admission Control) vor vLLM.

Laststeuerung beseitigt die Wartezeit nicht

llm-d verlagert die Warteschlange von der GPU in eine kontrollierte Schicht. Das schützt laufende Generierungen davor, durch immer neue Prefills und KV-Druck ausgebremst zu werden. Die Wartezeit verschwindet nicht. Sie wird sichtbar, messbar und fairer verteilt. (llm-d.ai)

Die Warteschlangen sind außerdem nicht persistent. Bei einem harten Neustart der Endpoint Picker Extension gehen wartende Anfragen verloren. Clients müssen deshalb Verbindungsabbrüche sowie 429 und 503 abfangen und Anfragen mit Backoff und Jitter erneut senden. Die Plattform darf kein Exactly-once-Verhalten versprechen. (llm-d.ai)

Die aktuelle Flow-Control-Doku beschreibt zwei Ausfallmodi der Endpoint Picker Extension (EPP): Das Router-Rezept verwendet FailOpen, während FailClose der API-Standard ist. Beim FailOpen kann Envoy Anfragen direkt an die Modellserver weiterreichen, wenn die EPP nicht erreichbar ist. In diesem Zeitraum gibt es keine Laststeuerung, keine Fairness und keinen Sättigungsschutz. (llm-d.ai)

Für einen regulierten Konzern kann FailClose konsistenter sein, für einen produktivitätskritischen Entwicklungsdienst FailOpen vertretbar. Fixstern verwendet für die internen GLM-Pools FailClose. Ist die Endpoint Picker Extension nicht erreichbar, werden neue Anfragen abgelehnt. So bleibt die zentrale Zulassungsgrenze auch während einer Störung wirksam.

Der x-llm-d-inference-fairness-id darf nie vom Client übernommen werden. Sonst kann ein Benutzer die Identität eines anderen Teams vortäuschen oder seine Anfragen auf viele Fairness-IDs verteilen. LiteLLM beziehungsweise ein vertrauenswürdiger Richtlinienfilter entfernt eingehende Werte und setzt die ID anhand der authentifizierten Teamzugehörigkeit neu.

Die Client-Seite ist Teil der Plattform

„OpenAI-kompatibel“ sagt über die tatsächliche Kompatibilität zu wenig aus.

Clients unterscheiden sich in folgenden Punkten:

• Chat Completions
• Responses API
• Anthropic Messages
• Streaming-Ereignisse
• Tool-Call-Format
• Reasoning-Felder
• Abbruchverhalten
• Wiederholungslogik
• Kontextkomprimierung

Für die Beispielorganisation ergibt sich zunächst folgende vorläufige Supportmatrix.

Continue dokumentiert vLLM und LiteLLM als OpenAI-kompatible Provider und erlaubt eine eigene apiBase. Bei Bedarf lässt sich die Responses API deaktivieren. Der Client greift dann auf Chat Completions zurück. (Continue Docs)

Aider verwendet ebenfalls einen konfigurierbaren OpenAI-Endpunkt und persönliche Zugangsdaten. (aider.chat)

opencode konfiguriert selbst gehostete Endpunkte als eigenen Provider auf Basis von @ai-sdk/openai-compatible mit eigener baseURL. Der API-Key kommt dabei aus einer Umgebungsvariablen statt aus einer versionierten Konfigurationsdatei. (opencode Docs)

Cline Enterprise kann einen OpenAI-kompatiblen Endpunkt organisationsweit vorgeben und Benutzer am Wechsel zu persönlichen Providern hindern. Die aktuelle Administration erfolgt allerdings über Cline-eigene, gehostete Verwaltungsoberflächen. Für eine vollständig getrennte Umgebung muss deshalb geprüft werden, ob dieser Control-Plane-Pfad akzeptabel ist. (Cline)

Codex CLI unterstützt benutzerdefinierte Modellanbieter mit eigener base_url, Responses-Dialekt und befehlsbasierter Authentifizierung. Dadurch kann ein internes Hilfsprogramm bei Bedarf ein kurzlebiges OIDC-Token abrufen, ohne einen statischen Key in einer Datei zu speichern. (OpenAI Developers)

Eine verwaltete Codex-Konfiguration könnte so aussehen:

model = "coding-standard"
model_provider = "fixstern"

[model_providers.fixstern]
name = "Fixstern AI"
base_url = "https://ai.intern.example/v1"
wire_api = "responses"

[model_providers.fixstern.auth]
command = "/usr/local/bin/fixstern-ai-token"
args = ["--audience", "coding-agents"]
timeout_ms = 5000
refresh_interval_ms = 300000

Claude Code ist der schwierigste Fall. LiteLLM kann einen Anthropic-kompatiblen /v1/messages-Endpunkt anbieten und Anfragen für andere unterstützte Modellprovider übersetzen. Anthropic erklärt jedoch ausdrücklich, dass Claude Code mit Nicht-Claude-Modellen über solche Gateways nicht unterstützt wird. Technisch möglich bedeutet hier nicht herstellerseitig unterstützt. Jede Claude-Code-Version muss deshalb erneut mit Kimi und GLM getestet werden. (docs.litellm.ai, Claude Platform Docs)

Cursor unterstützt benutzerdefinierte Modelle über OpenAI-kompatible Base URLs. Das bedeutet aber nicht, dass seine gesamte Steuerungsebene (Control Plane), seine Authentifizierung und seine Telemetrie selbst gehostet werden. Cursor dokumentiert selbst separate Datenpfade und Einschränkungen für BYOK, Custom Models und Datenresidenz. Deshalb bleibt Cursor eine bedingte Freigabe. (cursor.com)

Verteilung auf 120 Rechner

Basis-URL, Modellalias, CA-Zertifikat und Client-Richtlinien werden zentral verteilt, nicht über eine Anleitung im Wiki.

Fixstern verwendet:

• MDM (Mobile Device Management) für Betriebssystem-Zertifikate
• verwaltete Client-Konfigurationen
• standardisierte Devcontainer und Arbeitsplatzkonfigurationen
• ein internes Hilfsprogramm für kurzlebige Tokens
• freigegebene, versionsgenau festgelegte Client-Versionen

Persönliche Secrets stehen weder in Git-Repositories noch in gemeinsamen Dotfiles.

Die interne CA muss in allen relevanten Zertifikatsspeichern vorhanden sein. Dazu gehören je nach Client der Betriebssystem-Zertifikatsspeicher sowie Node-, Java-, Python- oder Container-Zertifikatsspeicher. „Funktioniert im Browser“ beweist nicht, dass ein CLI-Agent das Zertifikat akzeptiert.

Die Kompatibilitätsprüfung

Jede Kombination aus Client, Gateway, vLLM-Version und Modellrevision muss die folgenden Tests bestehen:

Bei Kimi ist zusätzlich wichtig, vollständige Assistant-Nachrichten aus Tool-Calling-Runden unverändert in die nächste Runde zurückzugeben. Ein Client, der Reasoning- oder Tool-Felder entfernt, kann das Modellverhalten verschlechtern. (Kimi API Platform)

Eine konkrete vLLM-Konfiguration

Die Konfiguration wird nicht direkt als Helm-Wert aus dem Internet kopiert. Fixstern legt folgende Bestandteile versionsgenau fest:

• Container-Image und Digest
• vLLM-Version
• Modell-Commit
• Tokenizer
• Chat Template
• Tool-Call-Parser
• Reasoning-Parser
• Attention-Backend
• Treiber- und ROCm- beziehungsweise CUDA-Version

GLM-5.3-Flash auf MI355X

Eine mögliche Ausgangskonfiguration für den gemeinsamen GLM-Pool sieht so aus:

Illustrative Konfiguration, nicht direkt ausführbar. Vor dem Produktivbetrieb gegen das aktuelle vLLM-Konfigurationsbeispiel mit exaktem Image-Digest, Modell-Commit und Testdatum verifizieren.

export VLLM_ROCM_USE_AITER=1

vllm serve /models/zai-org/GLM-5.3-Flash/<commit> \
  --served-model-name glm-5-3-flash \
  --tensor-parallel-size 4 \
  --max-model-len 262144 \
  --max-num-seqs 16 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --enable-auto-tool-choice \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --attention-backend ROCM_AITER_MLA_SPARSE \
  --generation-config vllm \
  --api-key "${VLLM_UPSTREAM_KEY}"

Die Werte max-num-seqs und gpu-memory-utilization sind Pilotwerte. Sie werden nach dem Lasttest angepasst.

Der Pool meldet das Modell unter einem internen Namen. Die Zuordnung der Aliasse coding-standard und coding-long übernimmt LiteLLM. Deshalb steht --max-model-len auf 262.144: Dieselben Repliken müssen auch Langkontextanfragen annehmen können. Das 128K-Limit von coding-standard setzt das Gateway pro Alias durch, bevor eine Anfrage den Pool erreicht.

Auf NVIDIA Blackwell kann zusätzlich FP8-KV-Cache verwendet werden. Das aktuelle vLLM-GLM-Konfigurationsbeispiel dokumentiert dort auch MTP Speculative Decoding. In der aktuell dokumentierten ROCm-Konfiguration steht MTP dagegen nicht zur Verfügung. Hopper unterstützt für dieses Modell laut Konfigurationsbeispiel keinen FP8-KV-Cache. (vLLM Recipes)

Ohne explizite Vorgabe läuft GLM-5.3-Flash auf der höchsten Reasoning-Stufe max. Fixstern senkt den Standardalias deshalb bewusst auf reasoning_effort=high ab. Sonst verbraucht schon eine einfache Dateiumbenennung unnötig Output-Tokens und Rechenzeit. max bleibt genehmigten Batch-Läufen und Evaluationen vorbehalten. (vLLM Recipes)

Kimi K3

Für den getrennten Kimi-Testbetrieb gibt es hier bewusst keinen kopierbaren Befehl. Das aktuelle vLLM-Konfigurationsbeispiel nennt für Kimi K3 je nach GPU-Profil unterschiedliche Attention-Backends und empfiehlt ausdrücklich, sie unter der eigenen Verteilung der Eingabelängen zu vermessen. Die Eckwerte bleiben dieselben wie in der Hardware-Rechnung: Tensor Parallelism 8 auf acht B300- oder MI355X-GPUs, ein Kontextlimit von 262.144 Tokens und die Parser kimi_k3 für Tool Calls und Reasoning. (vLLM Recipes)

Das Konfigurationsbeispiel warnt außerdem, dass Kimi K3 gelegentlich Tool-Call-Ausgaben erzeugt, die der Parser nicht erwartet. In diesem Fall sollte das Gateway die Ausgabe gegen das Schema prüfen und einen fehlerhaften Werkzeugaufruf wiederholen. Container-Tags wie latest aus dem Konfigurationsbeispiel ersetzt Fixstern durch geprüfte Image-Digests. (vLLM Recipes)

--trust-remote-code ist bei Kimi keine harmlose Komfortoption. Die Option erlaubt, Code aus dem Modellartefakt in der Inferenzumgebung auszuführen. Dieser Code muss vor der Übernahme geprüft, versioniert und zusammen mit den Gewichten freigegeben werden. (vLLM Recipes)

Prefix Caching mit echter Tenant-Isolation

Prefix Caching ist für Coding-Agenten attraktiv. System-Prompt, Tool-Definitionen und Teile des Repository-Kontexts wiederholen sich häufig.

Im Mehrmandantenbetrieb entsteht jedoch ein Timing-Kanal: Unterschiede in der Time to First Token können verraten, ob ein bestimmtes Präfix bereits im Cache vorhanden war. vLLM bietet deshalb das Request-Feld cache_salt. Nur Anfragen mit demselben Salt können dieselben Cache-Einträge gemeinsam nutzen. (vLLM)

LiteLLM setzt diesen Wert nicht automatisch passend zur Teamstruktur. Fixstern implementiert deshalb einen Pre-Call-Hook.

Der Ablauf:

1. Ein eventuell vom Client gesendeter cache_salt wird entfernt.
2. Der Hook liest die authentifizierte Team-ID.
3. Er bildet einen HMAC (Hash-based Message Authentication Code) aus Team-ID und einem geheimen Plattformschlüssel.
4. Er setzt das Ergebnis als cache_salt im ausgehenden vLLM-Request.
5. Der Schlüssel liegt in Vault. Bei jeder Rotation wird eine neue Version angelegt.

Schematisch:

import base64
import hashlib
import hmac
import os
from typing import Any

CACHE_SALT_SECRET = os.environ["CACHE_SALT_SECRET"].encode("utf-8")


def build_team_cache_salt(team_id: str) -> str:
    digest = hmac.new(
        CACHE_SALT_SECRET,
        team_id.encode("utf-8"),
        hashlib.sha256,
    ).digest()

    return base64.urlsafe_b64encode(digest).decode("ascii").rstrip("=")


def apply_tenant_policy(body: dict[str, Any], team_id: str) -> dict[str, Any]:
    # Nie einen vom Client kontrollierten Salt übernehmen.
    body.pop("cache_salt", None)

    body["cache_salt"] = build_team_cache_salt(team_id)
    return body

LiteLLM stellt dafür einen async_pre_call_hook bereit, der Request-Daten vor dem Modellaufruf verändern kann. Da sich interne Callback-Strukturen zwischen Versionen ändern können, wird der Hook zusammen mit der versionsgenau festgelegten Gateway-Version getestet. Ein Test auf HTTP-Ebene muss nachweisen, dass die ausgehende JSON-Anfrage tatsächlich den erwarteten Salt enthält. (docs.litellm.ai)

Dieselbe Policy-Schicht entfernt vom Client gesetzte Fairness- und Prioritätsheader und erzeugt sie aus der authentifizierten Identität neu.

vLLM darf nicht direkt erreichbar sein

--api-key gehört in die Konfiguration. Es ist aber kein vollständiger Schutz des vLLM-Servers.

vLLM stellt neben den normalen Inferenzpfaden auch Betriebs-, Diagnose- und teilweise verändernde Endpunkte bereit. Die eingebaute API-Key-Prüfung schützt nicht automatisch jede mögliche Route. Der Server darf deshalb weder aus dem Entwicklernetz noch aus dem Internet direkt erreichbar sein. (vLLM, vLLM)

Fixstern setzt folgende Grenzen:

• Entwickler dürfen nur LiteLLM erreichen.
• LiteLLM darf nur die freigegebenen Gateway-Routen erreichen.
• Das Routing-Gateway darf nur definierte Inferenzpfade erreichen.
• vLLM läuft ausschließlich als ClusterIP.
• Distributed- und KV-Transfer-Ports bleiben im GPU-Netz.
• Administrative Endpunkte sind per Positivliste zulässiger Routen blockiert.

Für reine Coding-Workloads läuft Kimi mit --language-model-only. Abrufe externer Medien bleiben deaktiviert. Falls multimodale Eingaben später freigegeben werden, müssen erlaubte Domains explizit begrenzt werden, damit der Inferenzserver nicht als SSRF-Proxy (Server-Side Request Forgery) missbraucht werden kann. (vLLM Recipes, vLLM)

Client-Abbrüche müssen über LiteLLM, Envoy und llm-d bis zu vLLM propagiert werden. Ein falsch konfigurierter Proxy, der die Verbindung zum Inferenzserver offen hält, verbraucht weiter GPU-Zeit, obwohl der Entwickler den Agenten bereits gestoppt hat. (vLLM)

Für nichtstreamende Anfragen muss in LiteLLM cancel_on_disconnect aktiviert werden. Die Einstellung steht standardmäßig auf false. Bei Streaming-Anfragen muss Fixstern die Weitergabe des Verbindungsabbruchs separat Ende zu Ende über alle beteiligten Komponenten testen. (docs.litellm.ai)

general_settings:
  cancel_on_disconnect: true

Updates sind Releases, keine Downloads

vLLM entwickelt sich schnell. Tool-Parser, Reasoning-Parser, Chat Templates, Attention-Kernels und Streaming-Verhalten können sich zwischen Versionen ändern.

Fixstern aktualisiert deshalb nie nur „vLLM“.

Ein Freigabepaket besteht aus:

• Runtime-Container
• vLLM-Version
• GPU-Treiber
• ROCm oder CUDA
• Modell-Commit
• Tokenizer
• Chat Template
• Tool-Call-Parser
• Reasoning-Parser
• Gateway-Version
• Client-Kompatibilitätsmatrix

Vor der Freigabe hält Fixstern die konkreten Stände fest.

Beispiel einer Freigabematrix für den eigenen Betrieb

Der Ablauf:

1. Das Freigabepaket läuft zunächst in der Testumgebung.
2. Die Agenten-Abnahmesuite wird ausgeführt.
3. Die interne Code-Evaluation läuft.
4. Ein Lasttest prüft Goodput und Queue-Verhalten.
5. Eine Testreplik erhält zunächst fünf Prozent der freigegebenen Anfragen.
6. Erst danach wird der Alias umgeschaltet.
7. Das vorherige Freigabepaket bleibt lokal verfügbar.

Treiber-Upgrades erfolgen über einen neuen GPU-Knotenpool. Fixstern aktualisiert nicht alle Produktionsknoten gleichzeitig direkt im bestehenden Knotenpool.

Beobachten, was die Entwickler tatsächlich erleben

GPU-Auslastung allein ist kein Service-Level-Ziel.

Eine GPU kann zu 100 Prozent ausgelastet sein, und trotzdem kann der Dienst schlecht funktionieren. Entscheidend sind:

• Time to First Token
• Time per Output Token
• End-to-End-Latenz
• Queue-Zeit
• laufende und wartende Requests
• Prompt- und Output-Tokens
• KV-Cache-Auslastung
• KV-Cache-Preemptions
• Abbrüche
• 429- und 503-Rate
• Tool-Call-Fehler

vLLM stellt Metriken für TTFT, Inter-Token-Latenz, Gesamtlaufzeit, Tokenmengen, laufende Requests, wartende Requests und Cache-Auslastung bereit. vllm bench serve kann bei Lasttests den Goodput anhand von TTFT-, TPOT- und End-to-End-Zielen auswerten. (vLLM, vLLM, vLLM)

Goodput statt maximaler Durchsatz

Maximaler Durchsatz beantwortet:

Wie viele Tokens kann die Hardware irgendwie erzeugen?

Goodput beantwortet:

Wie viele Anfragen können innerhalb des vereinbarten Service-Level-Ziels abgeschlossen werden?

Für die Dimensionierung zählt nur der zweite Wert.

Fixstern definiert:

C_SLO = maximale Parallelität einer Replik,
        bei der die festgelegten TTFT- und TPOT-Ziele
        bei der realen Agenten-Lastverteilung eingehalten werden

Dann gilt:

benötigte Repliken =
    maximale Zahl gleichzeitig zu bedienender Requests
    geteilt durch C_SLO
    zuzüglich Ausfall- und Wachstumsreserve

Die Lastverteilung muss aus echten Agenten-Sessions stammen. Ein synthetischer Chat-Benchmark mit 8.000 Input- und 1.000 Output-Tokens bildet eine 20-stufige Coding-Session mit wiederholten Tool Calls nicht ab.

Latenzklassen statt eines gemeinsamen Ziels

Ein einziges TTFT-Ziel für 8K- und 128K-Prompts ist zu grob, weil sich die Prefill-Arbeit stark unterscheidet. Statt eines pauschalen Ziels für 128K trennt Fixstern nach Eingabelänge:

Konkrete Zeiten werden erst nach einem Benchmark eingesetzt. Bis dahin gelten Platzhalter: TTFT p95 nach Promptgrößenklasse, TPOT p95 nach Modell und Reasoning-Stufe, Queue-Zeit p95 je Prioritätsklasse.

Welche Daten gespeichert werden

Fixstern erfasst standardmäßig:

• pseudonymisierte Benutzer- und Team-ID
• Modellalias und Modellrevision
• Clienttyp und freigegebene Clientversion
• Prompt-Tokenzahl
• Output-Tokenzahl
• TTFT
• TPOT
• Queue-Zeit
• Gesamtlaufzeit
• Statuscode
• Anzahl der Wiederholungsversuche
• Session-ID

Nicht standardmäßig gespeichert werden:

• Quellcode
• Prompt-Inhalte
• Modellantworten
• Tool-Ausgaben
• Dateinamen
• Repository-Inhalte

Für eng begrenzte Fehleranalysen kann eine temporäre Protokollierung von Inhalten aktiviert werden. Dafür gelten eine eigene Zugriffsregelung, eine kurze Aufbewahrungsfrist, ein dokumentierter Zweck und eine gesonderte Freigabe.

Nutzungsdaten dienen Kapazitätsplanung und Missbrauchserkennung. Sie werden nicht verwendet, um Entwickler nach erzeugten Codezeilen, Tokenverbrauch oder angeblich gesparten Stunden zu bewerten. Weil personenbezogene Telemetrie erfasst wird, gehört die Mitbestimmung früh geklärt. Was der Betriebsrat bei einem KI-Coding-Rollout mitbestimmt, betrifft genau diese Daten.

Die fünf Runbooks, die vor dem Rollout fertig sein müssen

vLLM kann bei KV-Cache-Druck Sequenzen preempten und später neu berechnen. Steigende Preemptions sind deshalb ein frühes Signal, dass Kontextverteilung, Parallelität oder Cache-Planung nicht mehr zum Lastprofil passen. (vLLM)

Das EPP-Neustart-Runbook muss den gewählten Ausfallmodus berücksichtigen. Bei FailOpen geht nicht nur die wartende Queue verloren. Es droht zusätzlich ein unkontrollierter Durchgriff auf bereits gesättigte vLLM-Repliken, weil Envoy die Anfragen ohne Flow Control direkt weiterreicht.

Die GPU-Runbooks müssen zur Plattform passen. In der MI355X-Variante gehören AMD GPU Operator, Device Metrics Exporter und GPU Field Health Checks dazu. Der aktuelle Operator unterstützt MI355X, Prometheus-Integration und GPU-Health-Monitoring. (instinct.docs.amd.com, instinct.docs.amd.com)

Showback und ein interner Tokenpreis

Teams sollen sehen, in welchem Umfang sie die Plattform nutzen. Daraus folgt noch keine interne Verrechnung.

Der einfache interne Preis lautet:

jährliche Vollkosten der Plattform
geteilt durch
SLO-konform verarbeitete Tokens

Zu den Vollkosten gehören:

• Abschreibung oder Leasing der Hardware
• Strom und Kühlung
• Rechenzentrumsunterbringung und Netzwerk
• Hardware-Support
• Gateway- und Plattformlizenzen
• Objektspeicher
• Personalaufwand
• Ausfall- und Wachstumsreserve

Besser ist eine getrennte Betrachtung von Input und Output. Prefill und Decode haben unterschiedliche Kostenprofile. Long-Context-Anfragen können zusätzlich anhand gemessener GPU-Sekunden gewichtet werden.

Showback, also eine transparente Zuordnung der Nutzung zu Teams ohne interne Verrechnung, zeigt Teamkosten, nicht individuelle Produktivität.

Was externe APIs im Beispielszenario kosten würden

Eine Beispielrechnung macht die Größenordnung sichtbar.

Angenommen, jeder der 120 Entwickler erzeugt an 20 Arbeitstagen pro Monat:

• 1 Million Input-Tokens pro Tag
• 100.000 Output-Tokens pro Tag

Das ergibt:

• 2,4 Milliarden Input-Tokens pro Monat
• 240 Millionen Output-Tokens pro Monat

Nehmen wir zusätzlich an, dass die Hälfte der Input-Tokens als Cache-Hit abgerechnet wird.

Auf Basis der veröffentlichten Listenpreise vom 29. August 2026 ergeben sich ungefähr folgende monatliche Modellkosten:

Ohne Cache-Hits wären es ungefähr:

Kimi nennt aktuell 3 US-Dollar je Million nicht gecachter Input-Tokens, 0,30 US-Dollar für Cache-Hits und 15 US-Dollar für Output. Z.ai nennt als Listenpreis 0,15 US-Dollar für Input, 0,03 US-Dollar für gecachten Input und 0,50 US-Dollar für Output. Eine zeitlich begrenzte GLM-Aktion ist in der Rechnung bewusst nicht berücksichtigt. (Kimi API Platform, Overview - Z.AI DEVELOPER DOCUMENT)

Die Rechnung ersetzt keinen Kostenvergleich mit einem konkreten Vertragsangebot. Sie ignoriert unter anderem Mindestabnahmen, Support, Datenresidenz, ausgehender Datenverkehr, garantierte Parallelität, Preisnachlässe und zusätzliche Agentendienste. Eine breitere Einordnung der Kosten verschiedener KI-Coding-Tools im Jahr 2026 zeigt, dass der reine Tokenpreis selten die ganze Rechnung ist.

Sie zeigt aber etwas Wichtiges:

Bei niedrigen API-Preisen muss ein internes GLM-Cluster vor allem durch Datenkontrolle, garantierte Verfügbarkeit oder hohe dauerhafte Auslastung begründet werden. Reine Tokenersparnis reicht möglicherweise nicht.

Bei Kimi sieht die Rechnung anders aus. Der API-Preis ist deutlich höher, der Bedarf an interner Hardware aber ebenfalls außergewöhnlich hoch. Zwei produktive TP8-Repliken benötigen 16 GPUs der B300- oder MI355X-Klasse. Ohne hohe und konstante Nutzung lässt sich die dediziert beschaffte Hardware nur schwer auslasten.

Für einen belastbaren Wirtschaftlichkeitsvergleich fehlen noch Beschaffungspreis, Finanzierung, Energie, Support, Personal und die tatsächliche Auslastung.

Deshalb ist die pragmatische Architektur hybrid

Für Fixstern ergibt sich folgende Entscheidung:

GLM-5.3-Flash intern

GLM wird im Beispiel als Kandidat für den Standarddienst für normale und sensible Repositories evaluiert.

Gründe:

• vier unabhängige Repliken auf zwei 8-GPU-Knoten möglich
• 128K als realistischer Standardkontext
• eigene Kontrolle über Protokolle und Datenfluss
• geringerer Hardwarebedarf als bei Kimi
• Kandidat im Beispiel, die interne Evaluation steht noch aus

Kimi K3 zunächst extern oder stark begrenzt intern

Kimi bleibt als Vorabversion zunächst auf einen getrennten Testbetrieb beschränkt.

Für freigegebene Datenklassen kann hinter diesem Alias ein vertraglich geprüfter Anbieter stehen. Der Vertrag muss mindestens Datenresidenz, Aufbewahrung, Training, Subprozessoren, Audit, Verfügbarkeit sowie Vertragsbeendigung, Datenrückgabe und Löschung regeln.

Für Code, der die Kontrollgrenze nicht verlassen darf, existieren zwei Möglichkeiten:

• Kimi auf eigener dedizierter Hardware betreiben
• oder auf GLM zurückfallen

Die Plattform darf eine interne Anfrage niemals stillschweigend an einen externen Anbieter weiterleiten. Die Datenklasse des Repositories bestimmt den erlaubten Routing-Pfad. Fehlt eine gültige Klassifizierung, bleibt die Anfrage intern.

Autocomplete und Embeddings intern

Beide Dienste sind vergleichsweise klein, gut auslastbar und einfach zu isolieren. Sie bleiben unabhängig vom großen Agent-Modell intern.

Rollout in fünf Phasen

Fazit

Die wichtigste technische Entscheidung lautet nicht „LiteLLM oder Kong“ und auch nicht „H100 oder MI355X“.

Sie lautet:

Kein Entwickler greift direkt auf vLLM zu. Jede Anfrage wird authentifiziert, anhand der geltenden Regeln geprüft und erst nach einer zentralen Zulassungsentscheidung an den passenden Inferenzpool weitergeleitet.

Fixstern verwendet in diesem Beispiel FailClose. Ist die Endpoint Picker Extension nicht erreichbar, werden neue Anfragen abgelehnt, statt die Zulassungssteuerung zu umgehen.

Drei Sätze sollte man sich merken:

1. Das Kontextfenster eines Modells ist nicht automatisch das Kontextlimit des Dienstes.
2. Ein persönliches Parallelitätslimit ist noch keine globale Zulassungssteuerung.
3. Ein einzelner Knoten mit acht GPUs ist ein Pilot, keine belastbare Plattform für mehr als hundert Entwickler.

vLLM führt die Modelle aus. LiteLLM verwaltet Identitäten und Quoten. llm-d steuert, welche Anfragen wann zu den GPUs gelangen. KServe und GitOps machen die Bereitstellungen reproduzierbar. Grafana zeigt, ob der Dienst seine technischen Ziele erreicht.

Erst dieses Zusammenspiel macht aus einem Modellserver einen internen KI-Dienst.

Häufige Fragen

Ist vLLM allein für den Mehrbenutzerbetrieb ausreichend?

Nein. vLLM erzeugt Tokens und verwaltet den KV-Cache, kennt aber weder Teams noch Prioritäten. Für mehr als hundert Entwickler kommen eine Identitäts- und Zugangsschicht, eine Zulassungssteuerung mit fairen Warteschlangen und getrennte Inferenzpools hinzu.

Wie verhindert man, dass ein Entwickler alle GPU-Ressourcen blockiert?

Über gestaffelte Limits und eine zentrale Zulassungssteuerung. LiteLLM begrenzt aktive Anfragen pro Entwickler und pro Team. Bei GPU-Sättigung puffert llm-d Flow Control die Anfragen in fairen Warteschlangen und lehnt bei voller Warteschlange mit 429 und nach Ablauf der Wartezeit mit 503 ab. Ein Parallelitätslimit pro Person allein genügt nicht, weil es die Gesamtlast vieler gleichzeitiger Nutzer nicht begrenzt.

Welcher API-Dialekt gilt für Claude Code, Codex CLI und Cursor?

Codex CLI nutzt den Responses-Dialekt über einen benutzerdefinierten Modellanbieter mit eigener base_url. Claude Code spricht Anthropic Messages, die LiteLLM über den kompatiblen /v1/messages-Pfad übersetzt. Für Nicht-Claude-Modelle ist das nicht offiziell unterstützt und bleibt experimentell. Cursor lässt sich über eine OpenAI-kompatible Custom Base URL anbinden, bleibt wegen separater Datenpfade aber eine bedingte Freigabe.

Wie viele GPUs braucht man für 100 Entwickler mit Coding Agents?

Das hängt vom Modell und vom gemessenen Goodput ab, nicht von einer festen Kopfzahl. Im Beispiel laufen für GLM-5.3-Flash als Standarddienst vier TP4-Repliken auf zwei Knoten mit je acht MI355X-GPUs, für volle Ausfallreserve käme ein dritter Knoten hinzu. Ein Kimi-K3-Premiumdienst belegt pro Replik einen kompletten 8-GPU-Knoten mit TP8, für einen Produktionsbetrieb also 16 High-End-GPUs. Ein einzelner Knoten mit acht GPUs bleibt ein Pilot, keine belastbare Plattform für mehr als hundert Entwickler.

LiteLLM, Kong oder llm-d: wann welches Gateway?

LiteLLM ist der pragmatische Einstieg für Identität, Keys, Teams und Quoten, wenn es noch keine KI-Gateway-Plattform gibt. Besitzt das Unternehmen bereits Kong als strategisches API Gateway, kann Kong den Zugang und das Regelwerk übernehmen. Die inferenzbewusste Zulassungssteuerung bleibt in beiden Fällen eine eigene Aufgabe: Sobald bei Sättigung fair gepuffert und abgelehnt werden muss, braucht es llm-d Flow Control oder eine gleichwertige Schicht. Ein klassisches API Gateway ersetzt keine mandantenfaire Warteschlange vor den GPUs.