Die Abschaltung eines Modells ist der normale Lebenszyklus jeder LLM-Anwendung. Dies ist die Geschichte eines produktiven Modell-Wechsels von GPT-4o zu GPT-5.6: 48 Stunden, mit Evidenz bei jedem Schritt.
Warum der Wechsel nötig wurde
Einer unserer Kunden, ein Unternehmen in einer regulierten Branche, betreibt eine KI-gestützte Suche (damals auf GPT-4o) auf seiner öffentlichen Website. Besucher stellen eine Frage, das System findet die passenden Seiten, und ein LLM formuliert eine kompakte Antwort mit Quellen und Verweisen.
Zwei Dinge erzwangen den Wechsel. Erstens die Zeit: Microsoft schaltet GPT-4o auf Azure zum 1. Oktober 2026 ab. Jede Anwendung, die noch darauf läuft, muss umziehen, idealerweise geplant statt in Panik.
Zweitens, und dringender: Die Performance war bereits eingebrochen. Antworten, die früher in 3 bis 5 Sekunden kamen, brauchten plötzlich 8 bis 60 Sekunden. Der Kunde musste sein clientseitiges Timeout von 8 auf 60 Sekunden anheben, nur damit das Feature nutzbar blieb. Unsere eigenen Evaluationsläufe gegen den produktiven Endpunkt maßen im Schnitt 11,9 Sekunden pro Antwort. Für ein Suchfeld.
Für ein kundenseitiges Feature in einer regulierten Branche kam “einfach auf das neue Modell zeigen” nicht infrage. Antworten müssen korrekt sein, sauber belegt, gut formatiert und robust gegen Missbrauch. Die Frage lautete also: Wie schnell gelingt ein Modell-Wechsel in Produktion, wenn jede Aussage über Qualität belegt sein muss?
Die Antwort: 48 Stunden. Hier ist, was an den beiden Tagen passiert ist.
Tag 1: Baseline ziehen, neues Modell testen
Ohne aktuellen Referenzdatensatz lassen sich Modelle nicht vergleichen. Unser bestehender Referenzdatensatz war veraltet: Die Website-Inhalte hinter der Suche hatten sich seit der Erstellung der Beispiele im Jahr 2025 geändert, und ein veralteter Referenzdatensatz führt zu veralteten Schlussfolgerungen.
Der erste Schritt war also ein unspektakulärer Neuaufbau der Evaluations-Collection. 73 kuratierte Beispiele mit echten Nutzerfragen, abgerufenem Kontext, erwarteten Links und erwarteten Inhalten, frisch vom produktiven Such-Endpunkt gezogen und auf Inkonsistenzen geprüft. (Wie ein Referenzdatensatz für eine Retrieval-Anwendung entsteht, beschreiben wir ausführlicher in unserem Beitrag zur Evaluation von RAG-Anwendungen.) Die Collection liegt versioniert in elluminate, neben allen Collections, die sich über die Projektlaufzeit angesammelt haben: Top-Fragen, Tippfehler, Edge Cases, gemeldete Fehler.
Danach lief die Baseline: der produktive GPT-4o-Endpunkt gegen die aktualisierte Collection, bewertet nach den bestehenden Korrektheitskriterien des Projekts. Ergebnis: 77,2 % Erfolgsrate bei 11,9 Sekunden pro Antwort. Diese Zahl ist der Anker für alles Weitere, denn ohne sie ist “das neue Modell ist besser” nur eine Meinung.
Dann der Moment, auf den jede Migration insgeheim hofft: Wir haben exakt denselben Prompt, Version 19, unverändert, auf GPT-5.6 gerichtet und dieselbe Evaluation laufen lassen.
GPT-5.6 schlug die Produktions-Baseline out of the box: 81,3 % gegenüber 77,2 %, bei 4,86 statt 11,91 Sekunden pro Antwort. Zu Listenpreisen kostet die Luna-Stufe von GPT-5.6 zudem einen Bruchteil von GPT-4o: 1 USD (GPT-5.6) statt 2,50 USD (GPT-4o) pro Million Input-Tokens, 6 USD (GPT-5.6) statt 10 USD (GPT-4o) pro Million Output-Tokens. Harder, better, faster, stronger, ohne eine einzige Zeile am Prompt zu ändern.
Das hätte das Ende der Geschichte sein können. Leider leben wir in der echten Welt, und es war es nicht. Zum Glück ist der Grund genau das, wofür es Evaluationsplattformen gibt. Wir haben dem Kunden einen Link auf die Vergleichsansicht geschickt: altes Modell auf der einen Seite, neues Modell auf der anderen, Beispiel für Beispiel.
Tag 2: Nachschärfen, Red-Teaming, Rollout
Der Fachexperte widerspricht
Am nächsten Morgen lag das Urteil vor. Eine Fachexpertin des Kunden war die Antworten durchgegangen und hatte 14 Kommentare direkt in der Vergleichsansicht hinterlassen. Keine Meetings, keine exportierten Tabellen, keine Screenshots in E-Mails.
Die Kommentare waren eindeutig: Die neuen Antworten waren korrekt, aber die Formatierung hatte sich verschlechtert. Fettungen und die klare Schritt-für-Schritt-Struktur waren verschwunden. Kommentar für Kommentar stand sinngemäß dasselbe da: “Gliederung und Fettung waren im alten Modell besser.”
Die Ursache ist eine Verhaltensänderung zwischen den Modellgenerationen: GPT-4o hat Antworten von sich aus mit Markdown strukturiert. GPT-5.6 tut, was im Prompt steht. Und im Prompt stand nie “verwende Überschriften und Fettungen”, weil es nie nötig war.
Wörtliche Modelle decken nachlässige Prompts auf
Das war die zentrale Lektion dieses Modell-Wechsels. GPT-5.6 folgt Anweisungen deutlich wörtlicher als GPT-4o, und genau das brachte alles ans Licht, was der alte Prompt sich geleistet hatte:
- Eine Regel “keine Zwischenüberschriften” aus einer frühen Prompt-Iteration, die GPT-4o still ignoriert hatte. GPT-5.6 befolgte sie und entfernte genau die Struktur, die die Experten schätzten.
- Ein fest im Prompt hinterlegter Erstattungsbetrag, der veraltet war: Auf der Website stand eine Zahl, im Prompt eine andere. GPT-4o antwortete meist aus dem abgerufenen Kontext; GPT-5.6 vertraute dem Prompt.
- Eine abgeschnittene URL, die seit Monaten unbemerkt im Prompt stand.
Es waren latente Fehler, die das alte Modell zufällig überspielt hat. Offenbar ist ein gehorsameres Modell ein Prompt-Audit, das niemand bestellt hat.
Wir haben das Prompt-Template von Version 19 auf Version 23 iteriert und dabei Schritt für Schritt explizite Formatierungsregeln für Überschriften, Fettungen und Aufzählungen ergänzt. Das subjektive Feedback der Expertin wurde ein neues, messbares Kriterien-Set für Layout und Struktur: Überschriften vorhanden, Antworten lesbar, Formatierung konsistent, Quellen verlinkt. Das alte Modell erreichte auf diesen Kriterien 82,2 %, das neue Modell mit dem überarbeiteten Prompt 91,5 %.
Red-Teaming, dann Rollout
Korrekt und gut formatiert reicht für ein öffentlich erreichbares LLM nicht. Das Projekt pflegt eine eigene Red-Teaming-Collection mit 60 adversarialen Fragen, die die Suche von ihrer Aufgabe wegziehen sollen: Prompt-Extraktion, themenfremde Anfragen, schädliche Anweisungen im Gewand einer Kundenfrage. Das erwartete Verhalten ist eine konsequente, wortgleiche Ablehnung.
Hier war das neue Modell zunächst schlechter. GPT-5.6 will stärker helfen und schlug statt einer Ablehnung lieber Alternativen vor. Statt eine Antwort zum Base-Jumping zu verweigern, empfahl es zum Beispiel hilfsbereit einen Kletter-Artikel für Einsteiger. Freundlich, fast schon komisch, aber für diesen Anwendungsfall falsch. Der ungehärtete Prompt erreichte 86,7 % Ablehnungsquote, weniger als die 88,3 % des alten Modells.
Also haben wir den Prompt gehärtet: eine explizite Liste verbotener Verhaltensweisen und eine erzwungene Standard-Ablehnung. Zwei Prompt-Versionen später lag die Ablehnungsquote auf der Red-Teaming-Collection bei 100 %, alle 60 adversarialen Fragen wurden mit der byte-identischen Standardantwort beantwortet. Die erneut durchgeführte Korrektheits-Evaluation bestätigte, dass die Härtung den regulären Antworten nicht geschadet hat. Der Wert stieg sogar leicht.
Ein ehrlicher Hinweis, weil Evaluations-Hygiene zählt: Einige Fehlerfälle aus den Red-Teaming-Läufen sind als explizite Regeln zurück in den Prompt geflossen. Ohne diese Regeln lagen wir bei 90 %. Das ist teils echte Härtung, teils Lernen für den Test. Wer so vorgeht, sollte ein Held-out-Set behalten, das der Prompt nie gesehen hat. Sonst misst der Sicherheits-Score das Gedächtnis, nicht die Sicherheit.
Getestet wurde gegen das echte (wenn auch lokal laufende) System. Eine Instanz der Anwendung war als eigener Endpunkt an elluminate angebunden, sodass jedes Experiment durch dasselbe Retrieval, denselben Prompt-Aufbau und dasselbe Modell-Routing lief wie die Produktion.
Der Rollout selbst war bewusst unspektakulär. Die Anwendung bekam eine kleine Provider-Abstraktion: Das Antwortmodell lässt sich per Umgebungsvariable auf jeden OpenAI-kompatiblen Endpunkt umstellen, die alte Konfiguration bleibt der Default. Nachdem der Kunde den finalen Vergleich geprüft und freigegeben hatte, ging das neue Modell innerhalb von 20 Minuten live. Von der ersten Baseline bis zum neuen Modell im Produktivbetrieb: knapp 48 Stunden.
Die Ergebnisse
| Kriterium | GPT-4o (vorher) | GPT-5.6 (nachher) |
|---|---|---|
| Antwortzeit (Durchschnitt) | 11,9 s | ~4–5 s |
| Korrektheit (73 Referenzbeispiele) | 77,2 % | 82,2 % |
| Layout- und Strukturkriterien | 82,2 % | 91,5 % |
| Red-Teaming-Ablehnungsquote (60 Fragen) | 88,3 % | 100 % |
| Kosten pro 1 Mio. Tokens (Listenpreis, In/Out) | 2,50 / 10 USD | 1 / 6 USD |
| Zeit von der ersten Baseline bis zum Livegang | N/A | 48 Stunden, 1 PR |
Jede Zahl in dieser Tabelle ist ein Experiment, das sich anklicken lässt. Das ist der Unterschied zwischen einem Modell-Wechsel, von dem man glaubt, dass er funktioniert, und einem, den man belegen kann: gegenüber dem Team, dem Kunden und jedem, der das System später prüft.
Die Blaupause für den Modell-Wechsel
Dass dieser Wechsel 48 Stunden gedauert hat statt Monate, liegt daran, dass jeder Schritt günstig war:
- Referenzdatensatz aktualisieren. Referenzbeispiele gegen das produktive System neu erzeugen, denn veraltete Ground Truth entwertet alles Nachgelagerte.
- Baseline mit dem alten Modell ziehen. Das aktuelle Produktionsmodell gegen den aktualisierten Datensatz laufen lassen.
- Baseline mit dem neuen Modell ziehen. Das trennt den Modell-Effekt vom Prompt-Effekt.
- Fachexperten früh einbinden. Einen Link auf die Vergleichsansicht teilen; Kommentare dort sammeln, wo die Antworten stehen. Experten sehen, was Kriterien noch nicht messen.
- Feedback in Kriterien übersetzen. Jeder wiederkehrende Kommentar wird ein messbarer Check für alle künftigen Läufe.
- Den Prompt als versionierte Templates iterieren. Jede Version ist ein Experiment, Regressionen fallen sofort auf. (Prompt-Templates lassen sich auch per SDK abrufen, die Anwendung kann die freigegebene Version also programmatisch ziehen statt per Copy-and-paste.)
- Vor dem Rollout red-teamen. Neue Modelle scheitern auf neue Weise. Hilfsbereiter kann unsicherer bedeuten.
- Umkehrbar ausrollen. Provider-Wechsel hinter einem Konfigurationsschalter, altes Modell als Fallback, Kundenfreigabe auf dem finalen Vergleich.
Neue Frontier-Modelle erscheinen inzwischen alle paar Monate, und Anbieter schalten alte nach festen Fristen ab. Die GPT-4o-Abschaltung wird nicht der letzte erzwungene Umzug gewesen sein. Behandeln Sie den Ablauf oben als Vorlage, denn Sie werden ihn wieder brauchen.
Wenn bei Ihnen ein Modell-Wechsel ansteht: Genau für diesen Ablauf ist elluminate gebaut, von Collections über Experimente und Vergleichslinks für Fachexperten bis zu Kriterien und Prompt-Versionierung. Nehmen Sie Kontakt auf, wenn Sie das am eigenen Anwendungsfall sehen möchten.
FAQ
Wann wird GPT-4o auf Azure abgeschaltet? Microsofts Abschaltplan nennt den 1. Oktober 2026 für die GA-Versionen von GPT-4o auf Azure OpenAI. Fine-Tuning-Deployments haben eigene, spätere Fristen. Prüfen Sie den offiziellen Model-Retirement-Plan für Ihre konkrete Version.
Müssen Prompts für GPT-5.6 neu geschrieben werden? Meist nicht neu geschrieben, aber auditiert. GPT-5.6 folgt Anweisungen wörtlicher als GPT-4o. Veraltete Regeln, überholte Fakten und stillschweigende Annahmen im Prompt, die das alte Modell ignoriert hat, greifen plötzlich. Auch das Formatierungsverhalten ändert sich: GPT-5.6 strukturiert Antworten nur dann mit Markdown, wenn der Prompt es verlangt.
Wie viele Testbeispiele braucht ein Modell-Wechsel? Weniger als gedacht, wenn sie kuratiert sind. Dieser Wechsel lief auf 73 Referenzbeispielen plus einer Red-Teaming-Collection mit 60 Fragen. Der Wert entsteht dadurch, dass die Beispiele aktuell sind, von Fachexperten geprüft und an explizite Kriterien gebunden. Nicht durch schiere Menge.
Wie evaluiert man die echte Anwendung statt nur das Modell? Das produktive System als eigenen Endpunkt anbinden, sodass Experimente durch den vollständigen Stack laufen (Retrieval, Prompt-Aufbau, Modell-Routing), statt das Modell isoliert zu testen. In elluminate ist das eine eigene LLM-Konfiguration, die auf Ihre API zeigt.
