Das Jupyter-Notebook des Data Scientists funktioniert. Das Modell liefert korrekte Ergebnisse. Die Demo beeindruckt die Geschäftsführung. Dann fragt jemand: „Können wir das in Produktion bringen?"
An diesem Punkt stocken viele KI-Initiativen — nicht weil das Modell versagt, sondern weil die Lücke zwischen einem funktionierenden Notebook und einer zuverlässigen Produktions-API systematisch unterschätzt wird. Die technische Hürde ist selten die Modellqualität. Es ist das Model Serving: die unsichtbare Schicht, die aus einem Skript, das auf einem Laptop läuft, einen Endpunkt macht, dem nachgelagerte Systeme, Kunden und Aufsichtsbehörden vertrauen können. Wer diese Schicht überspringt, baut keine Produktion — er baut eine Demo, die zufällig im Rechenzentrum steht.
Die Lücke zu Produktionsanforderungen
Ein Notebook läuft auf einem einzelnen Rechner, verarbeitet eine Anfrage nach der anderen, hat kein Error-Handling, keine Authentifizierung, kein Monitoring und keinen Wiederherstellungsmechanismus. Produktion verlangt all das gleichzeitig — und das ist kein Polieren am Rand, sondern eine andere Disziplin.
Nebenläufigkeit ist der erste Bruch. Produktions-APIs verarbeiten viele Anfragen parallel. Ein Modell, das hundert gleichzeitige Nutzer bedient, braucht Request-Queuing, Batch-Verarbeitung und Ressourcenmanagement, die ein Notebook-Skript schlicht nicht kennt. Zuverlässigkeit ist der zweite: Produktionssysteme brauchen Health-Checks, definiertes Verhalten bei Überlastung und automatischen Neustart im Fehlerfall. Ein Notebook stürzt still ab; ein Produktionssystem löst einen Alarm beim Bereitschaftsdienst aus. Latenzkonsistenz ist der dritte. Ein Notebook braucht so lange, wie es braucht. Produktion erfordert vorhersagbare Antwortzeiten — nicht nur im Durchschnitt, sondern am p95 und p99, denn genau dort sitzt der Nutzer, der abspringt, und das nachgelagerte System, das in den Timeout läuft.
Dazu kommt Sicherheit — Authentifizierung, Rate-Limiting, Eingabevalidierung, Ausgabebereinigung. Ein Modell, das beliebige Eingaben ungeprüft annimmt, ist in der Produktion eine offene Flanke. Und schließlich Beobachtbarkeit: In der Produktion muss in Echtzeit bekannt sein, wie das Modell performt — Anfragevolumen, Latenzverteilung, Fehlerraten, GPU-Auslastung und Ausgabequalität. Was hier nicht gemessen wird, existiert im Ernstfall nicht.
Der Model-Serving-Stack
Drei Schichten überbrücken die Lücke vom Notebook zur Produktion, und keine davon ist optional.
Schicht 1: Containerisierung. Modell, Abhängigkeiten und Inferenz-Code werden in einem Docker-Container verpackt, beim GPU-Betrieb über das NVIDIA Container Toolkit. Das Ergebnis ist eine portable, reproduzierbare Einheit, die in Entwicklung, Staging und Produktion identisch läuft. Der Container beseitigt das „Bei mir funktioniert's" — den häufigsten und teuersten Fehlerfall beim Deployment, weil er nie im Test auftritt, sondern erst beim Kunden.
Schicht 2: Serving-Framework. Ein Serving-Framework übernimmt HTTP-API, Request-Batching, Modellladung und GPU-Speicherverwaltung — die Arbeit, die man sonst von Hand und fehleranfällig nachbauen würde. Für LLM-Inferenz ist vLLM die naheliegende Standardwahl. Sein PagedAttention-Algorithmus verwaltet den Key-Value-Cache wie ein Betriebssystem virtuellen Speicher: in festen Blöcken statt als ein großer zusammenhängender Bereich, was die Speicherverschwendung gegen null drückt und damit bestimmt, wie viele gleichzeitige Sequenzen eine GPU überhaupt halten kann. Text Generation Inference (TGI) von Hugging Face bringt enge Hub-Integration und OpenAI-kompatible Endpunkte mit und ist für Standardmodelle einfacher aufzusetzen. NVIDIA Triton Inference Server ist die Enterprise-Option für gemischte Landschaften — mehrere Modelle, mehrere Frameworks, Ensemble-Modelle, dynamisches Batching, Modellversionierung. Triton kann am meisten und ist entsprechend am aufwendigsten zu konfigurieren; wer nur ein, zwei LLMs serviert, holt sich damit Komplexität ohne Gegenwert ins Haus.
Schicht 3: Orchestrierung. Kubernetes verwaltet Container-Lebenszyklus, Skalierung und Ressourcenzuteilung; Load-Balancer verteilen Anfragen auf Replikate; Health-Checks ersetzen ausgefallene Container automatisch. Für den Mittelstand ist Kubernetes beim ersten Deployment allerdings fast immer überdimensioniert — eine zweite Plattform, die selbst betrieben und verstanden werden will. Ein einzelner Container hinter einem Reverse-Proxy wie NGINX oder Traefik, orchestriert über Docker Compose, trägt die ersten ein bis drei Modelle problemlos. Der Umstieg auf Kubernetes lohnt sich, wenn echtes Auto-Scaling gebraucht wird oder die Zahl der Modelle so wächst, dass manuelles Management zur Fehlerquelle wird — nicht, weil es auf der Referenzarchitektur steht.
Die Deployment-Patterns
Ein Modell zu deployen ist einfach. Ein Modell zu ersetzen, ohne den laufenden Betrieb zu gefährden, ist die eigentliche Kunst — und dafür gibt es drei etablierte Muster.
Blue-Green-Deployment. Die neue Version läuft vollständig parallel zur alten. Nach der Validierung wird der Traffic umgeschaltet; treten Probleme auf, schaltet man sofort zurück. Das kostet während der Übergangsphase die doppelte Infrastruktur, eliminiert aber Ausfallzeit und macht das Rollback zur Sekundensache. Canary-Deployment ist das vorsichtigere Geschwister: Ein kleiner Anteil des Traffics — typisch fünf bis zehn Prozent — geht auf die neue Version, deren Metriken gegen die alte verglichen werden. Bleiben sie stabil, wächst der Anteil schrittweise; verschlechtern sie sich, wird zurückgerollt, bevor die Mehrheit der Nutzer es überhaupt bemerkt. Für laufende Modell-Updates in der Produktion ist das das sicherste Muster. Shadow-Deployment schließlich spiegelt den gesamten Traffic an beide Versionen, nutzt aber nur die Antworten der alten für Produktion und vergleicht die der neuen offline. So lassen sich Leistungsunterschiede ohne jedes Nutzerrisiko erkennen — zum Preis verdoppelter Inferenzkosten während der Testphase. Welches Muster richtig ist, hängt weniger vom Modell ab als von Ihrer Risikotoleranz und Ihrem Budget für parallele Hardware.
Leistungsoptimierung, bevor „produktionsreif" gilt
Bevor ein Modell den Stempel „produktionsreif" bekommt, sollten vier Stellschrauben geprüft sein, weil sie über die Wirtschaftlichkeit des gesamten Deployments entscheiden.
Quantisierung reduziert den Speicherbedarf und erhöht den Durchsatz, indem Gewichte mit geringerer Präzision — etwa INT8 oder INT4 — geführt werden; vLLM und TGI unterstützen verbreitete Verfahren wie GPTQ und AWQ. Der Genauigkeitsverlust ist für viele Inferenz-Aufgaben vernachlässigbar, für manche aber spürbar — deshalb gilt: für die konkrete Aufgabe vor und nach der Quantisierung messen, nicht auf ein allgemeines „funktioniert meistens" vertrauen. Batching ist der größte Hebel überhaupt. Statisches Batching lässt die GPU einen Großteil der Zeit im Leerlauf — Auslastungen im Bereich von zwanzig bis vierzig Prozent sind die Regel. Continuous Batching, das neue Anfragen aufnimmt, sobald ein Slot frei wird, statt auf feste Batch-Fenster zu warten, treibt die Auslastung deutlich über neunzig Prozent. In der Praxis bedeutet das: dieselbe Hardware bedient ein Mehrfaches des Traffics. Sowohl vLLM als auch TGI bringen das nativ mit.
KV-Cache-Management ist der Grund, warum vLLM in vielen LLM-Workloads vorne liegt. Bei Transformer-Modellen bestimmt die Verwaltung des Key-Value-Caches, wie viele gleichzeitige Sequenzen eine GPU halten kann; PagedAttention behandelt diesen Cache in festen Blöcken wie virtuellen Speicher und vermeidet so die Fragmentierung naiver Strategien. Aufwärmen ist die unscheinbarste, aber am leichtesten vergessene Maßnahme: Das Modell wird geladen und auf repräsentativen Eingaben durchgespielt, bevor es echten Traffic annimmt. Die erste Anfrage nach dem Laden — der Cold Start — ist deutlich langsamer als der Regelbetrieb und sollte niemals einen Nutzer erreichen.
Was der EU AI Act ab August 2026 verlangt
Für den DACH-Mittelstand ist Model Serving 2026 nicht mehr nur eine Frage der Performance, sondern der Rechtskonformität. Ab dem 2. August 2026 greifen die Pflichten für Hochrisiko-KI-Systeme nach dem EU AI Act — und sie treffen nicht nur Anbieter, sondern auch Betreiber (Artikel 26). Betreiber müssen den Betrieb des Systems überwachen, qualifiziertes Personal mit echter menschlicher Aufsicht betrauen und die vom System automatisch erzeugten Logs für mindestens sechs Monate vorhalten, soweit diese in ihrer Kontrolle liegen. „Automatisch" ist dabei wörtlich gemeint: Das System muss die Protokollierung selbst leisten — manuelle Dokumentation genügt nicht.
Das ist keine abstrakte Compliance-Anforderung, sondern eine konkrete Architekturentscheidung, die in die Serving-Schicht gehört. Wer Logging, Latenz-Telemetrie und Audit-Trail erst nachträglich anflanscht, baut die Produktion zweimal. Parallel verschärft die deutsche NIS2-Umsetzung über das novellierte BSI-Gesetz — seit Dezember 2025 in Kraft — die Anforderungen an Vorfallmanagement und Meldewege: signifikante Sicherheitsvorfälle sind binnen 24 Stunden zu melden, mit detailliertem Bericht nach 72 Stunden. Ein Modell-Endpunkt ohne durchgängige Beobachtbarkeit ist unter diesen Regeln nicht produktionsreif — er ist ein Haftungsrisiko mit API.
Die gute Nachricht: Genau die Beobachtbarkeit, die der AI Act und NIS2 erzwingen, ist dieselbe, die Sie ohnehin für stabilen Betrieb brauchen. Compliance und betriebliche Exzellenz zeigen hier in dieselbe Richtung — wenn man die Serving-Schicht von Anfang an richtig schneidet.
Ein Fit Call bringt Ihre Produktions-Architektur für Model Serving auf den Punkt — Serving-Framework, Deployment-Pattern und Skalierungsstrategie passend zu Ihrem Team — bevor die Hochrisiko-Pflichten des AI Act im August 2026 greifen.
Referenzen: EU Artificial Intelligence Act, „Article 26: Obligations of Deployers of High-Risk AI Systems" (artificialintelligenceact.eu/article/26); BSI / NIS2-Umsetzungsgesetz, in Kraft seit Dezember 2025 (Meldepflichten 24/72 Stunden); vLLM, „PagedAttention" und Continuous-Batching-Dokumentation (docs.vllm.ai).