Sieben Entscheidungen, sechs Systeme
Eine einzelne Anfrage durchläuft sieben Stationen. An jeder wird etwas entschieden — und jede dieser Entscheidungen beruht auf einer Konfiguration, die vorher jemand von Hand angelegt hat.
| Station | Entschieden wird | Konfiguriert liegt das in | |
|---|---|---|---|
| 1 | Authentifizierung | Wer ist das, zu welchem Team gehört er | Keycloak |
| 2 | Kontingentprüfung | Budget erschöpft? RPM, TPM überschritten? | LiteLLM |
| 3 | Inhaltsbewertung | Enthält der Prompt schutzwürdige Daten? | Gateway-Regeln |
| 4 | Modellauswahl | Darf dieser Nutzer dieses Modell für diese Datenklasse? | LiteLLM · Allowlist |
| 5 | Serving | Welche Modellversion, läuft eine Instanz? | KServe |
| 6 | Ausführung | Passt die Anfrage in den Batch, reicht der KV-Cache? | vLLM-Argumente |
| 7 | Verbrauchsbuchung | Wie viele Token, welche Kosten, welches Team | LiteLLM · DCGM · Kostenstelle |
Sechs Systeme, sechs Formate, sechs Orte.
Kein System sieht mehr als sein eigenes Stück. Wer die Kontextlänge eines Modells ändert, muss selbst wissen, ob die Kontingente der zugewiesenen Teams danach noch aufgehen — nachgerechnet wird das heute mit dem Taschenrechner, wenn überhaupt.
Im Anhang des Enterprise AI Platform Lab Guide steht eine Zeile darüber, was nicht ins Repository gehört:
Wird aus dem Katalog gebaut, nicht gepflegt.
Lab Guide, Anhang B.5
Im Buch ist das eine Handlungsanweisung an den Leser: Schreiben Sie sich ein Skript. nyrvex ist die Antwort auf die Frage, was passiert, wenn dieses „gebaut“ ein Produkt wird — mit eigenem Zustand, Erkennung von Abweichungen, Rückbau und einer Oberfläche.
Der Katalog ist die einzige Wahrheit. Alles andere wird daraus erzeugt.
Das Buch, aus dem diese Architektur stammt
Die fehlende Ebene ist nicht am Reißbrett entstanden. Sie ist das Ergebnis von 398 Seiten darüber, wie man diese Arbeit heute von Hand macht — jede Station des Anfragepfads, jede Rechnung, jeder Betriebsfehler, der schon jemandem passiert ist.
Der Enterprise AI Platform Lab Guide beschreibt den Handbetrieb vollständig: GPU-Infrastruktur und NVIDIA-Stack, GPU-Sharing, vLLM und KServe, Distributed Inference, Gateway, Identity, Governance, Observability, FinOps und Kapazitätsplanung. Wer wissen will, warum nyrvex so geschnitten ist, findet dort die Begründung — mit Labs, die auf einer einzelnen Karte laufen.
- Umfang
- 398 Seiten · 17 Kapitel · 4 Anhänge
- Stand
- September 2026 — geschrieben gegen Kubernetes 1.31, vLLM 0.8.x
- Englisch
- 386-seitige Ausgabe bei Leanpub, ab 25 $
- Lizenz
- CC BY-ND 4.0 — Weitergabe im Unternehmen ausdrücklich erlaubt
PDF kostenlos herunterladen · 7 MB Englische Ausgabe kaufen
Kostenlos. Keine Anmeldung, keine Adresse, kein Newsletter davor.
Kein Werkzeugkasten, ein Kreislauf
Katalog
was gelten soll
Modelle, Teams, Umgebungen. Ein Modell hat einen Zweck, eine Datenklasse, eine Kontextlänge, eine Freigabe mit Datum und Unterschrift, und einen Prüfsatz, den es bestehen muss. Ein Team hat eine Kostenstelle, eine Datenklasse, erlaubte Modelle, ein Budget und Grenzen. Diese Struktur ist nicht neu erfunden, sondern die des Referenz-Repositories aus dem Buch — nur nicht mehr als Konvention, sondern als Datenmodell.
Auslegung
ob es aufgeht
Bevor eine Änderung ausgerollt wird, wird sie durchgerechnet: nutzbarer KV-Cache, gleichzeitige Sequenzen, Anfragen im System nach Little, Preis je Million Token. nyrvex kennt dabei sowohl das Modell als auch die Kontingente der Teams, die es benutzen dürfen — und stellt deshalb fest, wenn beides nicht zusammenpasst.
Abgleich
wer es ausführt
Aus dem Katalog werden die Konfigurationen der beteiligten Systeme erzeugt und nachgehalten: Modellliste und Kontingente des Gateways, die InferenceServices des Serving-Layers, Gruppen und Mapper im Identity-Provider, die Provider-Schlüssel in der Secret-Verwaltung. Weicht ein System vom Katalog ab, ist das sichtbar und rückführbar.
Auswertung
was tatsächlich geschah
Verbrauch und Kosten entstehen am Gateway, Auslastung an der GPU, Bereitschaft am Serving-Layer. Erst zusammengeführt ergeben sie eine beantwortbare Frage: Was kosten tausend Token im Eigenbetrieb, und welches Team hat sie verursacht?
↺ Die Auswertung liefert die Messwerte, mit denen die Auslegung ihre eigenen Annahmen korrigiert. Deshalb ein Kreislauf und keine Kette.
Kubernetes hat einen Scheduler. Für GPUs taugt er nicht.
Kubernetes besteht aus drei Teilen: einem deklarativen Ressourcenmodell, einem Scheduler, der Wunsch auf verfügbare Kapazität abbildet, und Regelkreisen, die den Ist- an den Sollzustand ziehen.
Der Scheduler lässt sich hier nicht ausleihen. Er behandelt eine GPU als ganzzahlige, nicht überbuchbare Ressource: Er weiß, dass eine Karte frei ist. Er weiß nichts von Videospeicher, Kontextlänge, Gewichten oder KV-Cache — also von genau den Größen, die darüber entscheiden, ob ein Modell tatsächlich läuft.
Diese Rechnung ist bekannt. Sie ist nur bislang nicht Teil des Systems, sondern Aufgabe des Betreibers.
$ nyrvex apply -f katalog/modelle.yaml # Entwurf ✓ unternehmen-chat ausgelegt · ausgerollt ⏸ unternehmen-rag ausgelegt · wartet auf Kapazität $ nyrvex describe modell unternehmen-rag Zustand Wartet auf Kapazität — seit 4 min Auslegung kontext 16384 · 2 Repliken · Pool a100-40g Gewichte 7,1 GB Aktivierungen 1,8 GB nutzbar 36,0 GB KV-Cache übrig 27,1 GB je Sequenz 1,05 GB → 25 gleichzeitige Sequenzen je Replika, 50 gesamt Die zugewiesenen Teams verlangen 118 gleichzeitig. Vorschlag Kontext 8192 → 51 je Replika 5 Repliken → 125 gesamt auslegung: erzwingen (wird protokolliert)
Entwurf der Kommandozeilenausgabe. Rechenweg nach den Formeln aus Anhang C.8.
Die Deklaration wird angenommen, die Ausrollung nicht. Das Modell steht im Katalog und wartet — mit dem Rechenweg als Begründung, nicht mit einer Fehlermeldung nach zwanzig Minuten Ladezeit. Wer die Rechnung übersteuern will, kann das; es wird protokolliert.
Was nyrvex nicht ist
- Kein Ersatz für die vorhandenen Werkzeuge. Gateway, Serving-Layer, Inferenz-Server, Identity-Provider und Secret-Verwaltung bleiben, was sie sind. nyrvex konfiguriert sie — so wie Kubernetes die Container-Runtime nicht ersetzt hat, sondern dirigiert.
- Kein Inferenz-Server. nyrvex führt keine Modelle aus und steht nicht im Anfragepfad. Fällt es aus, laufen die Anfragen weiter; es lässt sich dann nur nichts mehr ändern.
- Keine ML-Plattform. Kein Training, kein Feintuning, keine Experimentverwaltung. Die Innenansicht des Modells interessiert nur so weit, wie sie Betriebsentscheidungen bestimmt.
- Kein Ersatz für Kubernetes. Die Analogie beschreibt das Verhältnis, nicht den Ehrgeiz.
Eine Architektur, kein Produkt
Es gibt keine herunterladbare Fassung und keinen Zeitplan. Die gezeigten Kommandos sind Entwurf. Wer hier ein Anmeldeformular für eine Warteliste erwartet hat: gibt es auch nicht.
Entschieden ist ein eigenes Ressourcenmodell als alleinige Wahrheit, aufbauend auf der Repository-Struktur des Lab Guide; die vier Bausteine; Bedienung über Kommandozeile und Oberfläche; und dass die Auslegung die Ausrollung zurückhält, statt die Deklaration abzulehnen.
Drei Entscheidungen — und warum
Keine davon war offensichtlich. Wenn Sie anders entschieden hätten, ist das das Nützlichste, was Sie mir schreiben können.
Der Katalog trennt die Datei von der Zusage
Ein Model sagt, was über das Artefakt wahr ist; ein Endpoint sagt, was wir über den Dienst versprechen. Dieselben Gewichte bedienen Chat mit 8k und RAG mit 16k, ohne zweimal deklariert zu werden — und eine Revisionshebung wird ein Vorgang, der jeden Endpunkt markiert, dessen Freigabe zu erneuern ist.
Die Auslegung hält die Ausrollung zurück — sie lehnt die Deklaration nicht ab
Ein Apply gelingt immer, ein GitOps-Abgleich bricht also nicht, weil jemand eine Kontextlänge geändert hat. Was wartet, ist die Ausrollung, mit dem Rechenweg als Begründung. Übersteuern ist möglich und wird protokolliert.
Die Control Plane steht dort, wo die Gateway-Datenbank steht
Ein Operator in dem Cluster, der Gateway, Identität und Secrets ohnehin trägt — nicht einer je Cluster. Ein Team hat ein Budget, also braucht es einen Zähler. Endpunkte und GPU-Pools bleiben lokal; alles, wovon ein Kontingent abhängt, bleibt zentral.
Wenn Sie eine KI-Plattform betreiben, haben Sie mindestens eine dieser Entscheidungen vermutlich anders getroffen. Ich lese jede Zuschrift: contact@nyrvex.com
Die Architektur dahinter ist ausführlich beschrieben im Enterprise AI Platform Lab Guide: thomaszachmann.de/buch