Praxiserprobte integrierte Best Practices für den Betrieb von AI ohne unnötige Kosten

• Um LLMs und AI-Plattformen in Produktionsumgebungen stabil zu betreiben, ist ein strukturzentrierter Designansatz erforderlich, der auf Veränderungen reagieren kann
• Um auf Änderungen bei Modellen und APIs vorbereitet zu sein, werden alle AI-Aufrufe als Services getrennt und ein Migrationsmuster auf Basis von Dual Execution angewendet
• Mit dem Flex Service Tier von OpenAI lassen sich bei gleicher Modell- und Datenqualität 50 % der Kosten einsparen
• Wiederkehrende Daten werden am Anfang des Prompts platziert, um die Effizienz bei der Nutzung von Cache-Tokens zu maximieren, sodass nur 10 % der Kosten anfallen
• Um übermäßige Kosten zu verhindern, müssen Rate Limiting und Circuit Breaker zwingend im Backend implementiert werden

---

AI-Integrationsstrategie mit Blick auf Veränderungen

• AI-Modelle und APIs verändern sich ständig, und die aktuell funktionierende Vorgehensweise kann jederzeit scheitern
• Statt einzelnen Tools oder Modellen hinterherzulaufen, ist ein Systemdesign entscheidend, das sich an Veränderungen anpassen kann
• Das Ziel beim Einsatz von AI ist nicht, der neuesten Technik hinterherzulaufen, sondern stabiler Betrieb und Kostenkontrolle

Das Migrationsmuster (The Migration Pattern)

• Alle AI-API-Aufrufe werden in Services ausgelagert, die Anbindung, Prompt-Erstellung und spezifische Prompts intern verarbeiten
• Diese Services werden in einem Zustand dauerhafter Migrationsfähigkeit (permanent migratability) betrieben, sodass immer entweder die neueste Version und das neueste Modell oder auch eine zuvor verwendete Version nutzbar sind
• Erfahrungen mit Problemen bei der Migration von GPT 4.1 auf GPT-5
  • Ein für GPT 4.1 perfekt ausgearbeiteter Prompt verlor bei GPT-5 an Zuverlässigkeit, etwa indem JSON-Keys fehlten
  • GPT-5 orientiert sich statt an einfachem JSON-Format eher an strukturierten JSON-Schemas (structured JSON schemas)
  • Es ist nötig zu erklären, wie Keys und mögliche Werte definiert und im Prompt ausgefüllt werden
• Umsetzung der Migrationsstrategie
  • Für einen bestimmten Zeitraum oder in Test-/Staging-Umgebungen werden der alte Prompt mit dem alten Modell sowie der neue Prompt mit dem neuen Modell parallel ausgeführt
  • Auch vollständig unterschiedliche Datenstrukturen und API-Aufrufe sind möglich (OpenAI empfiehlt den Wechsel von einer chat-style API zu einer response-style API)
  • Beide Ergebnisse werden geloggt; bei wichtigen Abweichungen meldet das System diese und zeigt ein Diff an
  • Ein Dual-Execution-Server verursacht zwar doppelte Kosten, macht aber Unterschiede zwischen altem und neuem Modell sowie Prompt-Unterschiede in Bezug auf Qualität, Vorhersagbarkeit und Zuverlässigkeit sichtbar
• Besonders nützlich für Hintergrundanalysen, Datenverarbeitung und semantische Analyse statt für rein konversationelle Anwendungsfälle
• Wenn neue Ergebnisse die Erwartungen nicht erfüllen, ist jederzeit ein Rollback auf die Legacy-Version möglich
• API-Systeme werden irgendwann deprecated, daher ist Migrationsbereitschaft unverzichtbar
• Ein Diff von JSON-Daten hilft bei der Neugestaltung von Prompts
  • Mit Claude Code oder OpenAI Codex lassen sich Prompts so anpassen, bis beide Ergebnisse ähnlich werden
• Dieses Muster gilt für alle Services, die mit externen ML-Modellen kommunizieren
• Wenn ein neuer Service plötzlich Leistungseinbußen zeigt, kann per Umschalten auf die alte Version zurückgekehrt werden, um wieder zuverlässig Daten wie zuvor zu erhalten

Das Geheimnis der Service Tiers (The Service Tier Secret)

• Cloud-Services bieten Service Tiers, bei denen je nach Wichtigkeit des API-Aufrufs unterschiedliche Preise gelten
• Im Fall von OpenAI
  • Default Tier: der auf der Website angezeigte Preis
  • Batched Requests: deutlich günstiger, aber für quasi-synchrone Aufgaben ungeeignet, weil unklar ist, wann ein Batch gefüllt und verarbeitet wird
  • Flex Tier: zum halben Preis des Default Tiers
    • Kann 50 % langsamer sein und zu bestimmten Zeitpunkten nicht verfügbar sein, liefert aber dieselbe Modell- und Datenqualität
• Einsatzbeispiele für das Flex Tier
  • Verwendet für Backend-Aufgaben wie Gast-Extraktion, Analyse von Aussagen, Zusammenfassungen usw.
  • Dank der Auto-Retries im OpenAI SDK ist keine zusätzliche Logik nötig
  • Fallback bei 429-Fehlern implementieren: einige Versuche mit Flex, bei Fehlschlag Wechsel auf das Standard-Tier und erneuter Versuch
• Ergebnisse beim großflächigen Einsatz
  • Sofortige Kostensenkung um 50 % erreicht (das Flex Tier ist die meiste Zeit verfügbar)
  • Bei vielen Input-Tokens und wenigen Output-Tokens (große Podcast-Transkripte → kleine JSON-Zusammenfassungsdaten) kosten Cache-Tokens ebenfalls nur die Hälfte
  • Das Volumen von Extraktions- und Inferenzaufgaben lässt sich verdoppeln, was zu besserer Plattformqualität und höheren Konversionsraten führt
• Was plattformseitig geprüft werden sollte
  • Batch-Preise entsprechen den Kosten der Flex-Verarbeitung
  • Flex-Preise gibt es für GPT-5, 5.1, o3 und o4
  • Für Codex, Pro, GPT-4o, Echtzeit-Audio-Tools usw. sind Flex-Preise unter Umständen nicht ohne Weiteres verfügbar
• Wenn Preisstufen existieren und nicht genutzt werden, ist das finanzielle Fahrlässigkeit (financial negligence)
• Wenn auch bei hoher Auslastung schnelle Ergebnisse nötig sind, kann ein Priority Tier konfiguriert werden (doppelter Preis, schnellere Ergebnisse)
  • Auch Priority ist bei manchen Modellen möglicherweise nicht verfügbar
• Da sich Modelle und Nutzungsarten stark unterscheiden, ist Flexibilität bei Implementierung und Optimierung notwendig

Front-Loading für Cache-Effizienz (Front-Loading for Cache Efficiency)

• Wenn viele Daten analysiert werden müssen, sollten wiederkehrende Teile an den Anfang gestellt werden
• Der System-Prompt kommt nach vorn; wenn dieselben Daten mehrfach analysiert werden, sollte der Prompt mit diesen Daten beginnen
• Reihenfolge des Prompts
  1. System-Prompt (Beschreibung der Rolle)
  2. Immer gleiche Systemanweisungen ("Daten in diesem Format extrahieren")
  3. Daten, die sich zwischen mehreren Prompts überschneiden können
  4. Die spezifischen Anweisungen des jeweiligen Prompts
• Vorn platzierte Daten werden als Cache-Tokens verarbeitet, sodass nur 10 % der Kosten anderer Tokens anfallen
• Praxisbeispiel
  • Zuerst wird das vollständige Transkript eingefügt, danach folgen am Ende des Transkripts die konkreten Arbeitsanweisungen (bestimmten Gast finden, Sponsor finden, Kundenfrage bearbeiten usw.)
• Prüfung auf Optimierung über mehrere Prompts hinweg
  • Prompts als Daten in Claude Code oder einen ChatGPT-Dialog eingeben und eine Optimierungsanalyse anfordern
  • Die AI-Ergebnisse nicht ungeprüft übernehmen, sondern nur als Referenz nutzen (AI ist letztlich nur Token-Vorhersage; nur weil etwas als nützlicher beschrieben wird, ist es das nicht automatisch)
  • Die gleichzeitige Analyse mehrerer Prompts kann wertvolle Erkenntnisse liefern

Rate Limiting und Circuit Breakers

• Bei der Nutzung externer Plattformen mit tokenbasierten Kosten ist Rate Limiting unverzichtbar
• Wo Rate Limits angewendet werden sollten
  • Bei kundenorientierten Aktionen, die AI-Interaktionen auslösen
  • Bei AI-Interaktionen, die der Backend-Server senden kann
• Es muss verhindert werden, dass durch Race Conditions derselbe Prozess wiederholt neu gestartet wird und denselben Aufruf mehrfach auslöst (selbst bei Cache-Tokens entstehen dabei Kosten)
• Erkennung von Auffälligkeiten
  • Es braucht Benachrichtigungen und eine Stop-Funktion, wenn in einem bestimmten Zeitraum 10-mal mehr AI-Tokens als normal genutzt werden
• Implementierung eines Circuit Breakers
  • Ein globaler Circuit Breaker für alle AI-Funktionen der Anwendung oder für bestimmte Teilbereiche
  • Feature-Toggles, die sich per Laravel-Kommando oder Admin-Oberfläche ein- und ausschalten lassen
  • Auch Self-Onboarding-Funktionen wie ein Button à la „coole Einstellungen erstellen“ sollten ein-/ausschaltbar sein
  • Wenn jemand etwas automatisiert und dadurch Kosten von Hunderten Dollar pro Stunde verursacht, kann dies per Toggle sofort blockiert werden
• Feature-Toggles gehören ins Backend, nicht ins Frontend (dort, wo das Problem tatsächlich entsteht)
• Nutzung von AI-Scans
  • Mit agentischen Coding-Tools den Code scannen, um Stellen zu finden, an denen AI-Aufrufe missbraucht werden könnten, und um zu sehen, wo Feature-Toggles ergänzt werden sollten
• Jede AI-Nutzung muss über das Backend-System laufen
  • Keine direkten Aufrufe der AI-Plattform vom Client aus mit Tokens (das ist ohnehin keine gute Praxis)
  • Nur über das Backend sind Ein-/Ausschalten von Funktionen und Warnungen bei hoher Nutzung möglich
• Implementierte Sicherheitsebenen
  • Rate Limits für alle Funktionen
  • Rate Limits für Frontend-Nutzer
  • Backend-Rate-Limits
  • Feature-Toggles
  • Warnungen bei Funktionsmissbrauch (pro Konto, nach Abonnententyp, nach IP)
• Es ist zu erwarten, dass solche Funktionen künftig standardmäßig in Tools und Frameworks enthalten sein werden; derzeit müssen sie jedoch noch selbst implementiert werden

Zentrale Lehre: Systeme für Veränderungen bauen

• Die AI-Landschaft verändert sich ständig (Modelle, APIs, Preise), daher ist es unmöglich, bei allem Schritt zu halten
• Entscheidend für den AI-Betrieb ist nicht das neueste Modell, sondern ein Systemdesign, das sich bei Veränderungen anpassen kann
• Unverzichtbare Bausteine:
  • Migrationsmuster
  • Optimierung von Service Tiers
  • Prompt-Caching
  • Rate Limiting
  • Circuit Breakers
• Das sind keine Nice-to-haves, sondern die Grundlage, um AI in Produktion zu betreiben und Verluste zu vermeiden
• Sobald AI in Produktion eingesetzt wird, sind Kosten und Stabilität kein rein technisches Problem mehr, sondern ein Strukturproblem

„Build for Change“ – schaffen Sie die Grundlage für Veränderung