Kapitel 11 — Die Plattform- und Orchestrierungsschicht

Elfter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel argumentiert, dass die Plattformwahl keine Feature-Frage ist, sondern die Frage, welches Betriebsmodell zur bestehenden Ops-Kultur des Teams passt.

Warum es dieses Kapitel gibt

Eine Engine umhüllt ein Modell auf einer GPU und produziert Tokens. Das ist ihre vollständige Aufgabenbeschreibung. Sobald die Produktion zwei Replicas hinter einem Loadbalancer braucht, oder zwei verschiedene Engines unter einem Endpoint, oder eine Pipeline, die embed → retrieve → rerank → generate als einen logischen Aufruf ausführt, oder ein Quota-System, das verhindert, dass ein Tenant den anderen aushungert, oder einen Autoscaler, der Replicas hinzufügt, wenn die Warteschlangentiefe steigt, sind der Engine die Antworten ausgegangen. Kapitel 11 geht die vier Plattformen ab, die diese Aufgabe 2026 dominieren — Ray Serve, KServe, BentoML, Triton Inference Server — und argumentiert, dass die Wahl zwischen ihnen eine Frage der Passung zur Ops-Kultur des Teams ist, nicht eine Feature-Frage.

11.1 Ray Serve ist Python-first; KServe ist Kubernetes-first

Ray Serve ist die Plattform, die entsteht, wenn die Ausgangsfrage lautet: „Wie sähe ein Serving-Framework aus, wenn ich für Komposition, Skalierung und Deployment einer Modell-Pipeline nie Python verlassen müsste?" Die Antwort sind Python-Klassen, als Aktoren dekoriert, mit Python-Funktionsaufrufen verdrahtet, von der Ray-Laufzeit repliziert, platziert und autoskaliert. Deployments komponieren sich zu Pipelines, indem sie die Methoden der jeweils anderen aufrufen; die Pipeline ist Python, die Observability ist Python, die Ops-Story ist Python. Es ist die natürliche Wahl, wenn derselbe Cluster ohnehin Ray für Training betreibt. KServe geht vom entgegengesetzten Ausgangspunkt aus: Kubernetes-first, herstellerneutral, deklarativ. Ein KServe-InferenceService ist eine CRD, die einfängt, wo die Gewichte liegen, welche Laufzeit sie ausliefert und wie sich das Autoscaling verhalten soll. Die Plattform verdrahtet die Pods über Knative für Scale-to-Zero und Istio für Traffic-Routing und stellt einen stabilen HTTP-Endpoint bereit. Der Handel ist Ausdrucksstärke — Pipeline-Komposition in KServe ist YAML-lastiger als in Ray Serve — für Portabilität und Standardisierung.

11.2 BentoML paketiert; Triton batched heterogene Modelle

BentoML nimmt eine dritte Haltung ein: die primäre Aufgabe der Plattform ist es, Modell + Code + Abhängigkeiten zu einem einzigen zusammenhängenden Artefakt — einem Bento — zu machen und die Auslieferung dieses Artefakts an beliebige Ziele (Kubernetes, Lambda, Cloud Run, eine nackte VM) zu einer Ein-Befehl-Operation zu machen. Es ist das, was ein Docker-Image für allgemeine Anwendungen ist, auf der Modell-Serving-Ebene. Die Autoren-Erfahrung ist FastAPI-artiges Python; die Deploy-Story ist der artefakt­orientierte Zug. Beste Passung ist ein kleiner Ops-Fußabdruck und ein Team, das den schnellsten Weg von „Python-Klasse" zu „deployter Endpoint, der überall läuft" will. Triton Inference Server ist der Enterprise-Grade dynamische Batcher, der historisch das NVIDIA-orientierte Serving beherrscht hat. Er beheimatet TensorFlow, PyTorch, ONNX, TensorRT, TensorRT-LLM und Python-Backends nebeneinander, wendet seinen dynamischen Batcher auf Nicht-LLM-Arbeitslasten an (Recommender, Klassifizierer, Embedder) und nutzt den Continuous-Batching-Scheduler für LLMs unter seinem TensorRT-LLM-Backend. Beste Passung sind heterogene Arbeitslasten oder ein Team, das tief im NVIDIA-Stack steckt.

11.3 Die vier Wahlmöglichkeiten teilen sich nach Ops-Kultur-Passung auf

Die vier Plattformen teilen sich sauber auf. Python und Ray als Schwerpunkt → Ray Serve. Kubernetes, deklarative Manifeste, Multi-Cloud-Portabilität, Multi-Tenant-Isolation → KServe. Kleiner Ops-Fußabdruck, schnellster Weg von Klasse zu Endpoint → BentoML. Heterogene Arbeitslasten oder NVIDIA-orientiertes Haus → Triton. Sie schließen sich auf Organisationsebene nicht gegenseitig aus: ein häufiges Muster in größeren Organisationen ist Triton für die volumenreichsten Produktions-LLMs, Ray Serve für RAG- und Agenten-Pipelines, die mehrere Modellaufrufe komponieren, KServe als Dach, das Multi-Tenancy erzwingt, und BentoML in Entwickler-Umgebungen. Die nützliche Übung bei der Auswahl ist, drei operative Eigenschaften aufzuzählen, die das Team unbedingt braucht, und drei, auf die es verzichten kann, und die Plattformen dann gegen diese Liste zu ordnen. Widerstehe der Plattform, die „alles unterstützt" — jede Plattform unterstützt ihren Kern gut und ihre Peripherie schlecht, und diejenige, deren Kern die Muss-Kriterien überdeckt, ist die, mit deren Betrieb das Team Freude haben wird.

Was Kapitel 11 vorbereitet

Die Engine-/Plattform-Grenze ist sauber, solange die Replikationseinheit ein Pod ist, der ein Modell auf einem GPU-Knoten besitzt. Sie ist nicht mehr sauber, sobald wir der Erkenntnis aus Kapitel 1 folgen, dass Prefill und Decode widersprüchliche Arbeitslasten sind. Kapitel 12 teilt sie auf separate GPU-Pools auf, verschickt den KV-Cache zwischen den Pools über die Netzwerk-Fabric und drückt die Aufteilung in Kubernetes-Primitiven aus — LeaderWorkerSet, Groves PodCliqueSet, KAI Schedulers Topologie-Bewusstsein. Die Plattformschicht ist das, was die Aufteilung betreibbar macht; die Plattformschicht ist der Grund, warum die Aufteilung überhaupt ausdrückbar ist.

Als Nächstes — Kapitel 12: Disaggregiertes Serving und Kubernetes. Prefill und Decode in separate Pods aufteilen und die Kubernetes-Primitive, die die Aufteilung ausdrücken.