Mein Team und ich betreiben LLM-Serving-Infrastruktur für Unternehmen und die öffentliche Hand, und ich sehe immer wieder starke Teams an derselben Hürde scheitern: Ein KI-Produkt zu skalieren ist etwas völlig anderes, als einen Prototyp zu bauen. Laut IDC schafft es nur etwa jedes achte KI-Pilotprojekt in die Produktion,[1] und MIT hat festgestellt, dass 95 Prozent keinen messbaren ROI liefern.[2] Selten liegt es am Modell. Meist liegt es daran, dass niemand die Produktion vor oder während des Pilotprojekts eingeplant hat.
Hier sind sechs Punkte, die Sie berücksichtigen sollten – mit einer vollständigen Checkliste am Ende.
1. Erfassen Sie die nicht-funktionalen Anforderungen. Ja, schon für den Piloten.
Erwartete Last, Latenz, Concurrency: KI-Produkte brauchen sie wie jedes andere System, aber eine Chat-Demo verbirgt sie. Zu den wichtigsten Kennzahlen gehören die Zeit bis zum ersten Token, die End-to-End-Antwortzeit, die Länge von Prompt und Ausgabe sowie die Zahl gleichzeitiger Nutzer oder Anfragen.
Diese Parameter bestimmen Ihr Setup. Sprachanwendungen erfordern niedrige Latenz, was Kapazitätsreserven und oft dedizierte Instanzen bedeutet. Latenzkritische Workloads auf geteilter Infrastruktur versagen genau dort, wo Nutzer es am wenigsten tolerieren.
Kennen Sie Ihre Nutzungsmuster. Werden alle Ihre Nutzer gleich am Morgen aktiv? Welche Aufgaben können warten? Sie zahlen für die Spitze.
Die erwartete Ausgabequalität gehört auf dieselbe Liste, auch wenn sie keine klassische nicht-funktionale Anforderung ist. Sie bestimmt Ihre Modellwahl und damit Ihre Infrastrukturkosten und Ihren Betrieb. 100 Prozent Genauigkeit zu verlangen ignoriert die nicht-deterministische Natur von KI. Definieren Sie die akzeptable Qualität pro Funktion und messen Sie sie kontinuierlich.
Beispiel. 5.000 Mitarbeitende × 10 % gleichzeitig aktiv zwischen 9 und 10 Uhr = 500 gleichzeitige Anfragen, zehnmal so viel wie der Tagesdurchschnitt vermuten lässt. Dimensionieren Sie für den Durchschnitt, und jeder Morgen beginnt mit Timeouts.
2. Wählen Sie das Modell für die Aufgabe, nicht für das Ranking
Das größte Modell ist meist nur die teuerste Standardwahl: eine Kettensäge, um Karotten zu schneiden. Gehen Sie von dem aus, was die Aufgabe erfordert.
Die Architektur ist ebenso wichtig wie die Größe. Ein Dense-Modell aktiviert bei jeder Anfrage alle Parameter; ein Mixture-of-Experts-Modell nur einen Bruchteil. Das bestimmt Ihr Tempo und Ihre Hardware-Rechnung. Beurteilen Sie Modelle nach ihren Betriebskosten und ihrer Token-Effizienz, nicht allein nach ihrem Ranking-Platz.
Evaluieren Sie mit Ihren eigenen Daten. Kleine interne Evaluierungen aus echten Fehlerfällen schlagen öffentliche Benchmarks und überstehen Modellwechsel. Siehe den Applied-LLMs-Leitfaden.[3]
Beginnen Sie im Zweifel mit überprüfbaren Aufgaben. Laut a16z[4] haben die erfolgreichen Enterprise-Anwendungsfälle ein prüfbares Ergebnis: Code läuft oder eben nicht, ein Support-Ticket wird gelöst oder an einen Menschen eskaliert. In solchen Szenarien lässt sich der Nutzen einer KI-Einführung auch leichter belegen.
Beispiel. Ticket-Klassifikation: kleines Modell = 94 % Genauigkeit bei 0,05 €/Mio. Tokens; Frontier-Modell = 96 % bei 15 €/Mio. Das sind +2 Punkte für den 300-fachen Preis. Manchmal lohnt es sich, aber das wissen Sie erst, nachdem Sie beide mit Ihren eigenen Daten getestet haben.
3. Wissen Sie, worauf Sie jede Deployment-Option festlegt
Token-APIs ermöglichen den schnellsten Start. Setzen Sie Kontingente, halten Sie Rate-Limits ein, überwachen Sie die Kosten von Tag eins an. Laut Gartner[5] verbrauchen Agenten pro Aufgabe zwischen 5- und 30-mal so viele Tokens wie ein Chatbot. Seien Sie vorsichtig, wenn Sie Pilotkosten hochrechnen: Ein Produktionsagent macht aus einer Aufgabe zum Beispiel zehn oder zwanzig Aufrufe, deren Kontext jeweils wächst – ein Budget, das auf Pilotökonomie beruht, liegt also um ein Vielfaches daneben, nicht nur um eine Marge.
Dedizierte Kapazität ist der richtige Weg bei planbarer Last und strengen Latenzanforderungen. Der Nachteil: Sie zahlen, ob ausgelastet oder im Leerlauf. Fangen Sie das auf, indem Sie nicht zeitkritische Workloads in Randzeiten einplanen.
Self-Hosting ist die letzte Option – für den Fall, dass eine dauerhaft hohe Auslastung die Rechnung kippt oder Regulierung keine Alternative lässt. Hardware veraltet innerhalb von zwei bis drei Jahren, und Inferenz gut zu betreiben erfordert knappe, teure Spezialisten. Solange Ihre Auslastung nicht hoch und dauerhaft ist, kaufen Sie Serving ein, statt es zu bauen. Kunden in regulierten Branchen wählen unser LLM Serving genau aus diesem Grund: Open-Weight-Modelle auf europäischer Infrastruktur, mit dedizierten, mandantengetrennten Instanzen, wo nötig.
Beispiel. Dedizierte Instanz zu 10.000 €/Monat ÷ API-Preis von 2 €/Mio. Tokens = Break-even bei 5 Mrd. Tokens/Monat. Darunter zahlen Sie für ungenutzte Hardware; darüber schlägt jedes Token den Listenpreis. Die Auslastung entscheidet.
4. Schätzen Sie die Kosten, bevor sie zum Rollout-Blocker werden
Jede KI-Funktion verursacht bei jeder Nutzung variable Kosten, die Marge hängt also direkt an der Nutzung. Eine Demo, die im Vorstand begeistert, kann die Marge im großen Maßstab still und leise zerstören. Das CFO's Playbook for AI Unit Economics[6] bietet einen einfachen Test, ob ein Team das im Griff hat: Kann es sagen, was jede Funktion in Tokens kostet? Wenn nicht, gibt es keine Kostentransparenz – und keine Grundlage für die Preisgestaltung.
Definieren Sie Ihre Einheit, ob Kosten pro Anfrage, pro Sitzung oder pro gelöster Aufgabe. Bandbreiten genügen. Budgetieren Sie für den Erfolg der Einführung: Zwar sinken die Token-Preise, doch die Rechnungen steigen, weil die Nutzung schneller wächst als der Preis fällt.
Hinter jedem Token-Preis steckt Hardware, und Hardware ist der dominierende Kostenblock. Ihre Anforderungen bestimmen die Architektur, die Architektur bestimmt die Kosten. Überspringen Sie Schritt eins, und jede Schätzung ist Fiktion. Eine Überschlagsrechnung reicht, und bei großem Maßstab können Sie Ihre Annahmen mit Ihrem KI-Anbieter abgleichen.
Beispiel. Chatbot: 1.000 Nutzer × 10 Anfragen × 2.000 Tokens × 30 Tage = 0,6 Mrd. Tokens/Monat → einige hundert Euro. Agentische Variante: × 15 Aufrufe × 2× Kontext = 18 Mrd. Tokens/Monat → fünfstellig. Gleiche Nutzer, gleiche Funktion, rund 30-mal die Kosten.
5. Bauen Sie die langweiligen Teile
Nichts davon ist KI-spezifisch, und doch werden diese Best Practices umso häufiger ignoriert, je schneller und einfacher sich Software bauen lässt. Führen Sie Lasttests beim Ein-, Zwei- und Fünffachen der erwarteten Spitze durch. Vor dem Launch.
Planen Sie Resilienz von Anfang an ein: Fallbacks, Hochverfügbarkeit, echte SLAs. Halten Sie eine Staging-Umgebung vor. Ein sicherer Ort zum Experimentieren ist das, was Sie nach dem Launch schnell hält.
Überwachen Sie Kosten pro Anfrage, Latenz-Perzentile und Qualität über die Zeit. Modelle driften; manche Anbieter spielen stille Updates ein. Eine Stanford-Studie zu 51 Enterprise-Deployments[7] fand, dass die Gewinner vor allem außerhalb des Modells investieren: in Prozesse, Daten und menschliche Aufsicht.
Beispiel. 10 gleichzeitige Anfragen → P95 = 0,9 s. 60 gleichzeitige → P95 = 8 s, nicht 1,5 s, weil ausgelastete GPUs in die Warteschlange gehen. Der Durchsatz hat eine Kante; ein Lasttest findet sie, bevor Ihr Launch es tut.
6. Sicherheit, Daten und die Regeln
Klassifizieren Sie Ihre Daten vor dem Piloten. Das schränkt die Wahl des Anbieters, das Hosting-Modell und die Dokumentationspflichten ein. Wählen Sie einen Anbieter, der die geltenden Vorschriften erfüllt.
Setzen Sie die nötigen Leitplanken. Denken Sie an KI-spezifische Bedrohungen wie Prompt Injection, Halluzination und Datenabfluss. Planen Sie das von vornherein ein, statt es nachzurüsten. In SmartChat etwa verbinden wir eine UX, die vor versehentlichem Datenabfluss schützt, mit souverän gehosteten Modellen für sensible Arbeit. Ziel sollte es sein, die Verantwortung für den Datenschutz nicht auf den Nutzer abzuwälzen.
Beispiel. Ein Pilot fasst Verträge über eine in den USA gehostete API zusammen. Die Rechtsabteilung stuft Verträge später als vertraulich ein → Anbieter, Hosting und Logging ändern sich mitten im Projekt = Wochen der Migration und ein ins Stocken geratener Rollout. Die Daten zuerst zu klassifizieren = ein Meeting.
Die Checkliste
Ich habe alles Vorstehende in einer einseitigen Checkliste zusammengefasst, die es unten auch als PDF (öffnet in neuem Tab) gibt. Teilen Sie sie mit dem Team, das den Piloten baut, und mit dem Team, das das fertige Produkt betreiben wird. Diese Fragen früh zu stellen, spart Ihnen später Zeit und Geld.
Die Teams, die mit KI wirklich ankommen, experimentieren nicht weniger. Ihre Experimente sind darauf ausgelegt, den Erfolg zu überstehen.