Die meisten AI-Teams behandeln Production noch immer wie ein Schulprojekt.
Das ist die unbequeme Wahrheit, die in Raghul Gopals Vortrag auf dem AWS Student Community Day Tirupati steckt. Er ist Data Scientist und AWS Community Builder – und er stellte eine Frage, die jeden ML-Engineer nachts wach halten sollte: “AWS gibt dir alles an einem Ort, um ML-Modelle zu bauen. Aber nutzen wir das wirklich richtig in der Production?”
Und das ist der Knackpunkt – ob du ein Zwei-Personen-Startup leitest oder Modelle über 500 Engineers verwaltest – der Abstand zwischen einem trainierten Modell auf dem Laptop und einem produktiven, stabilen, skalierten System in der echten Welt ist nicht klein. Das ist ein Graben.
Das Restaurant-Küchen-Problem
Ein großartiges Gericht zu Hause zu kochen ist das eine. Eine Restaurant-Küche zu betreiben, die jede Nacht hunderte Gäste versorgt – ohne Fehler? Das braucht Infrastruktur, Prozesse, Disziplin und etwas, das die meisten Data Scientists ungerne bedenken: Operations.
Diese Analogie stammt direkt aus Gopals Vortrag. Und sie ist die beste Erklärung, warum MLOps, FMOps und LLMOps gerade so wichtig sind.
Bevor es theoretisch wird, legte Gopal eine Selbstbewertungs-Checkliste vor – ein echter Lackmustest für Production-Readiness:
“Sind die Features deines Modells getrennt und korrekt versioniert? Wird das Modell ständig überwacht, um sicherzustellen, dass es weiterhin korrekte Ergebnisse liefert? Gibt es CI/CD-Pipelines, die Code von Development über Pre-Production bis zur Production verschieben?”
Wer die meisten Fragen mit “eher nicht” beantwortet hat, ist in der Mehrheit. Und genau das ist das Problem, das dieser Maturity-Ansatz lösen soll.
Was diese Akronyme wirklich bedeuten (und warum es zählt)
Ohne Umschweife: drei verschachtelte Ebenen, jede spezialisierter als die vorherige.
MLOps ist die Basis – der Prozess, um Standard-ML-Modelle (Betrugserkennung, Empfehlungssysteme, Churn-Prediction) systematisch in Production zu bringen. Feature-Tracking, Modell-Repositories, automatisiertes Testing, Monitoring. Das handwerkliche Rüstzeug der AI-Operations.
FMOps sitzt eine Ebene höher. Foundation Models – Claude, Llama, Titan – trainiert auf Terabytes an Daten mit Milliarden von Parametern. Diese Giganten brauchen ganz andere operative Strategien, weil sie etwas tun, das Standard-MLOps-Modelle nicht tun: neuartige Inhalte generieren (Text, Bilder, Musik, Video).
LLMOps ist der innerste Ring. Das ist das, was Chatbots, Schreib-Assistenten und Coding-Tools wirklich in Production am Laufen hält. Es ist eine Spezialisierung von FMOps speziell für Sprachmodelle.
Das Mental Model funktioniert tatsächlich gut: drei konzentrische Kreise. Alle drei folgen denselben Operationsprinzipien – Monitoring, Versionierung, Testing, Deployment – aber in unterschiedlichen Größenordnungen und mit unterschiedlichen Fehlermodi.
Das Maturity Model: Wo die meisten Teams wirklich stehen
Gopals vierstufiges MLOps-Maturity-Model – hier wird es konkret.
Level 1 ist reine Exploration. Data Scientists drehen Amazon SageMaker Studio an (AWS’s Cloud IDE), schreiben Code in VS Code, trainieren Modelle lokal. Keine Automatisierung, keine Pipeline, keine Versionierung jenseits von “modell_v2_final_WIRKLICH_FINAL.pkl”. Alles läuft von Hand. Hier operiert die überwiegende Mehrheit der Teams.
Der Tech-Stack auf dieser Stufe sieht so aus:
- Amazon SageMaker (Kernplattform)
- Amazon S3 (Raw-Data-Storage)
- AWS Glue (ETL)
- Amazon Athena (SQL auf Daten)
- AWS Lambda (Workflow-Trigger)
- CodeCommit oder GitHub (Code-Versionierung)
Aber hier ist, was niemand laut ausspricht: Dieses Level ist für Prototypen und POCs völlig in Ordnung. Für alles, das echte Nutzer sehen, ist es eine Katastrophe.
Und trotzdem.
Die meisten Production-Systeme stecken hier fest. Modelle driften. Datenqualitätsprobleme tauchen erst nach Wochen auf. Ein einzelner Engineer weiß, wie die Pipeline funktioniert – und wenn er geht, geht sein Wissen mit ihm.
