Sicheres Austauschen von LLM-Modellen: Menschliche Etiketten, Schritt-für-Schritt-Metriken, Anstrengungs-Einstellungen

Das Ändern des Modellnamens in einer Konfigurationsdatei scheint wie eine fünfminütige Aufgabe zu sein. In einem mehrstufigen LLM-Pipeline-Prozess ist das selten der Fall, und der Grund liegt meist nicht am neuen Modell selbst, sondern an der Messmethode, die zur Bewertung verwendet wird. Durch eine realistische Migration einer Filterpipeline von einer älteren Modellfamilie erfahren Sie, wie man zuverlässige Referenzwerte erstellt, Verluste auf einzelne Schritte zurückführt, einen veralteten Prompt eines schwächeren Modells erkennt sowie die Rechenanstrengung als einstellbare Größe pro Aufgabe statt als globale Einstellung betrachtet.

Der konkrete Auslöser in diesem Szenario ist eine Einstellung in den Ruhestand. OpenAI hat den 11. Dezember 2026 als Datum für den Rückzug von vier Modellen festgelegt: gpt-5 sowie dessen Mini- und Nano-Varianten sowie gpt-5-pro. Das ist der Stand zum Zeitpunkt der Erstellung dieses Textes; bestätigen Sie ihn daher auf der offiziellen Seite zu den Einstellungen in den Ruhestand. Der betreffende Prozesspfad setzte auf die beiden kleinsten dieser Modelle, weshalb ein Umstieg unvermeidlich war. Es standen zwei Ersatzoptionen zur Verfügung: gpt-5.4 in seinen verschiedenen Größen sowie gpt-5.6-luna. Modellnamen, Standardeinstellungen und Preisstrukturen ändern sich schnell, daher sollten Sie die unten genannten Details als Momentaufnahme betrachten und die Methode als den dauerhaften Bestandteil.

Der migrierte Prozesspfad

Das System verarbeitet etwa 2.600 Artikel pro Monat und reduziert diese auf rund 120 Kandidaten, die anschließend von einem Menschen manuell überprüft werden. Diese Reduzierung erfolgt nicht durch einen einzigen Befehl, sondern durch einen mit LangGraph erstellten Agenten, der aus etwa einem Dutzend Knoten besteht, von denen zehn unterschiedliche Modellaufrufe darstellen. Drei dieser Aufrufe enthalten den größten Teil der Informationen: ein Relevanzprüfer am Eingang, anschließend zwei Klassifikatoren – einer für den Inhaltstyp und einer für das Thema. Hinter diesen folgen eine Neuheitprüfung, ein Bewertungsschritt sowie ein Zusammenfassungsschritt.

Eine Eigenschaft des Designs prägt jede anschließende Entscheidung. Der erste Knoten dient dazu, Störungen zu beseitigen und nicht zur Qualitätseinschätzung, wobei seine beiden Fehlerarten sehr unterschiedliche Kosten haben:

• Eine falsche Beibehaltung ist günstig – ein leistungsstärkeres Modul weiter im Prozess oder der menschliche Prüfer am Ende werden dies erkennen.

Ein falscher Abbruch ist dauerhaft. Der Artikel wird als angezeigt markiert und gelangt nie wieder in den Verarbeitungspfad.

Jede Bewertung, die diese beiden Fehler symmetrisch behandelt, führt zu Fehleinschätzungen bezüglich des Verlaufs im Verarbeitungspfad.

Die mitgelieferte Konfiguration

Der Endzustand wurde absichtlich unausgeglichen gestaltet. Neun der zehn Aufrufe wurden an gpt-5.6-luna weitergeleitet, das sich bisher gut verhalten hat. Das Relevanzprüfsystem blieb bei gpt-5.4-nano; die Begründung für diese Ausnahme nahm den größten Teil der Untersuchungen in Anspruch. Zudem legt jeder Aufruf nun explizit seine Berechnungsaufwände fest, anstatt den Standardwert des Modells zu verwenden – und diese Entscheidung erwies sich als wichtiger als die Auswahl des Modells selbst.

Der Preis reduzierte die Auswahlliste bereits vor der Bewertung der Qualität, allerdings nicht anhand der Listenpreise. Fast der gesamte Datenverkehr wird im Rahmen von OpenAI’s Datenaustauschprogramm abgerechnet, und luna nutzt denselben größeren täglichen Datenvolumenrahmen wie die bereits verwendeten günstigsten Modelle. Die monatliche Rechnung bleibt daher in jedem Fall bei einigen Cent. Die leistungsstärkeren Modelle derselben Generation gehören zu einem viel kleineren Datenvolumenrahmen, der bei dieser Arbeitslast bereits bis zum Mittag aufgebraucht wäre – wodurch sie unabhängig von der Qualität ausgeschlossen wurden.

Folgend sind vier Überraschungen in der Reihenfolge, in der sie auftauchten. Diese Reihenfolge eignet sich zudem als sinnvolle Checkliste für Ihre eigene Migration.

Lektion 1: Verwenden Sie das alte Modell nicht als Grundlage

Die erste Bewertung verglich jede Kandidatenkonfiguration mit dem Ergebnis des zurückgezogenen Modells: Inwieweit reproduziert die neue Konfiguration das vorherige Ergebnis? Diese Vergleich zeigte einen Rückgang um 31 Artikel und löste die Suche nach einem Modellfehler aus, der nie existiert hatte.

Rückblickend ist das Problem offensichtlich. Die erste Durchlaufstufe des Pipelines erzeugt Kandidaten, von denen später 40 bis 60 Prozent vom menschlichen Prüfer entfernt werden. Die Messung der Übereinstimmung mit diesem Ergebnis bedeutet somit die Messung der Übereinstimmung mit einem bereits als mangelhaft bekannten Filter. Ein Kandidat wird belohnt, wenn er die Fehler des alten Modells nachahmt, und bestraft, wenn er sie korrigiert.

Menschliche Entscheidungen sind bereits als Referenzwerte erfasst

Eine weitaus bessere Setzung von Labels befand sich im Versionssystem. Der Schritt der menschlichen Überprüfung löscht Einträge aus der Kandidatenliste, wobei jede Löschung als Commit gespeichert wird. Im Testmonat reduzierte die erste Überprüfungsrunde 122 Kandidaten auf 72, und weitere Runden entfernten weitere. Durch Vergleich dieses Commits mit seinem Vorgänger entstehen zwei gelabelte Gruppen: Artikel, die eine Person beibehielt, und Artikel, die sie ablehnte.

Die Neubewertung der 31 „verlorenen“ Artikel unter Berücksichtigung dieser Labels veränderte das Bild völlig. Vierundvierzig Prozent davon waren Artikel, die der Prüfer ohnehin weggeworfen hatte. Gemessen am menschlichen Urteilsvermögen betrug der tatsächliche Verlust 15 gute Artikel, etwa die Hälfte des scheinbaren Rückgangs. Noch besser ist, dass die Labels mit den Entscheidungen pro Schritt verknüpft werden können, wodurch ersichtlich wird, welcher Knoten jeweils einen dieser 15 Artikel ausschloss. (Diese gelabelten Ergebnisse stammen aus der Konfiguration mit gpt-5.4-mini, nicht aus der veröffentlichten Luna-Konfiguration, da die Luna-Exekution früh abgebrochen wurde.) Ein einziger Knoten war für die Veränderung verantwortlich; kein anderer Schritt änderte sich um mehr als einen Artikel. Ein lokal begrenztes Problem mit 15 Artikeln in einer einzigen Anfrage ist weitaus leichter zu bewältigen als ein unerklärlicher Rückgang von 31 Artikeln.

Die allgemeine Lektion: Immer dann, wenn eine Person den letzten Anruf in Ihrem System tätigt, ist ihr Anruf die Grundwahrheit, und es gibt in der Regel bereits eine Aufzeichnung davon. Schauen Sie sich Genehmigungswarteschlangen, Moderationsänderungen, umklassifizierte Support-Tickets oder die Änderungen an generierten Entwürfen an. Der vorhandene Artikel zu der Bewertung von RAG-Systemen nach Fehlerstufe macht einen ähnlichen Vorschlag, um Fehler der Komponente zuzuschreiben, die sie verursacht hat.

Die schrittweise Messung bringt außerdem Fehler zutage, die nichts mit der Migration zu tun haben. In diesem Fall zeigte sich, dass die Neuheitprüfung Thema-Bezeichnungen erfindet, die nirgendwo in der von ihr erhaltenen Liste vorkommen, sowie für jede ihrer 24 Ablehnungen einen anderen erfundenen Namen – und das sowohl mit den alten als auch mit den neuen Modellen.

Lektion 2: Ein strengeres Modell könnte Ihre Anfrage korrekt interpretieren

Sobald der Fehler auf den Thema-Filter zurückgeführt werden konnte, war der verlockende Ansatz, seine Anweisungen so anzupassen, bis das neue Modell richtig funktionierte. In diesem Fall hätte das jedoch ernsthafte Schäden verursacht, denn ein leistungsstärkeres Modul weiter unten im System lädt genau diese Prompt-Dateien. Wenn man eine Regel lockert, sodass ein Modul der ersten Stufe mehr Artikel unbemerkt durchlässt, wird die Stufe geschwächt, die die eigentliche Bewertung vornimmt – und nichts, was in der ersten Stufe gemessen wird, würde das je zeigen.

Statt die Anweisungen zu editieren, bat die Untersuchung das Modell daher, sich selbst zu rechtfertigen. Für jeden Artikel, den der Thema-Filter ablehnte, wurde der angegebene Grund von GPT-5.4-mini aufgezeichnet – insgesamt etwa zwanzig Aufrufe.

Die Erklärungen waren schlüssig. Sie nannten konkrete Regeln und zitierten den Auftrag genau. In einem Fall wiederholte das Modell fast wortwörtlich eine Regel, die eine Optimierung der KI-Kosten „auch dann ausschloss, wenn sie an einer API-Gateway-Instanz umgesetzt wurde“, und nutzte diese Regel, um einen Artikel zu entfernen, den der Prüfer eigentlich beibehalten hatte.

Das alte gpt-5-mini hatte diese Regel einfach nie durchgesetzt. Bei genauerer Prüfung stellte sich heraus, dass zwei der ignorierten Regeln tatsächlich veraltet waren. Eine fehlte eine Ausnahme für Nachrichtenmuster, die innerhalb einer Anwendung erstellt werden; die andere war vor der Zeit verfasst worden, als API-Gateways zu einer relevanten Infrastruktur wurden. Diese beiden Regeln wurden korrigiert, die anderen unverändert gelassen, und die Korrektur wurde in einen eigenen Commit aufgenommen, getrennt von der Änderung am Modell, damit jede Änderung unabhängig gemessen werden konnte.

Ein einfacher Test, der zwei gegensätzliche Diagnosen unterscheidet

Dies ist die Überprüfung, die bei jeder Migration zuerst durchgeführt werden sollte. Wenn ein neueres Modell in einem Bewertungsschritt mehr Elemente ablehnt, liegt die Ursache oft daran, dass eine bessere Befolgung der Anweisungen mit einem Prompt kollidiert, der bereits seit einem Jahr veraltet ist. Hier ein Auszug aus den genannten Gründen:

• Wenn die Erklärungen Ihre tatsächlichen Regeln korrekt zitieren, ist der Prompt veraltet, und seine Korrektur hilft allen Phasen, die ihn verwenden.
• Wenn das Modell Regeln anwendet, die offensichtlich nicht zum jeweiligen Element passen, ist Ihr Prompt in Ordnung und das Modell trägt die Schuld.

Diese Schlussfolgerungen deuten in entgegengesetzte Richtungen, und eine reine Ablehnungszahl kann keinen Unterschied zwischen ihnen erkennen.

Lektion 3: Ein strengeres Urteil ist nicht automatisch ein schlechteres

Das Relevanzprüfsystem erzählte eine ähnliche Geschichte aus einer anderen Perspektive. An diesem Punkt lehnte Luna doppelt so viele Artikel ab wie GPT-5.4-Nano. Die offensichtliche Schlussfolgerung war, dass Luna bei dieser Aufgabe einfach schlechter ist – und das wurde fast zur endgültigen Entscheidung.

Tatsächlich beantwortet das Prüfsystem jedoch drei separate Fragen: Ist der Inhalt neu genug, ist die Sprache Englisch und fällt das Thema in den Anwendungsbereich? Nur das kombinierte Urteil wurde bisher untersucht.

Die getrennte Betrachtung der Urteile war aufschlussreich. Bei der Sprachfrage stimmten die Modelle vollkommen überein und markierten dieselben vier Artikel. Der ganze Unterschied lag bei der Frage zum Thema: Luna lehnte 64 Artikel ab, während GPT-5.4-Nano 32 Artikel ablehnte.

Die Begründungen von Luna zeigten kohärente, größtenteils nachvollziehbare Urteile: Zu den abgelehnten Vorschlägen gehörten eine Bibliothek für Go-Worker-Pools, eine Plattform zum Erstellen von Sprachassistenten sowie ein Artikel zur Migration von Datenbanken in die Cloud. Nichts war fehlerhaft. Luna interpretiert den Begriff „Hauptfokus“ enger, als es der Autor der Anfrage beabsichtigt hatte.

Das erfordert eine andere Lösung. Ein fehlerhafter Check sollte repariert werden. Eine nachvollziehbare, aber strengere Interpretation einer vagen Anfrage – an der einzigen Stelle, die alles weiterleitet und wo falsche Ergebnisse dauerhaft bleiben – sollte umgangen werden. Deshalb blieb dieser spezielle Aufruf bei gpt-5.4-nano. Im Allgemeinen sagt ein Gesamtscore nur aus, dass sich etwas geändert hat. Wenn eine Schrittantwort mehrere Fragen beantwortet, sollte jede Antwort getrennt aufgezeichnet werden, bevor man Theorien über das Modell entwickelt.

Lektion 4: Die Anstrengung beim Denken überträgt sich nicht zwischen Modellen oder Aufgaben

Sobald GPT-5.4-Nano für das Filterverfahren ausgewählt wurde, blieb die Frage offen, wie lange es nachdenken sollte. Bei Denkmodellen gibt es einen Anstrengungsparameter, der grob bestimmt, wie viel interne Abwägung vor der Antwort stattfindet. Die Annahme war, dass die Anstrengungsstufe wie ein Qualitätsregler funktioniert, der stets in dieselbe Richtung eingestellt wird, wobei jedes Modell auf seine eigene Weise reagiert.

Die Messungen zeigten zwei völlig unterschiedliche Muster:

• Am Relevanzfilter verdoppelte das Erhöhen der Anstrengungsstufe bei GPT-5.4-Nano fast die Anzahl der Abgelehnten, während LUNA überhaupt nicht auf die Einstellung reagierte.
• Am Themenfilter bewegte sich dasselbe LUNA-Modell im Anstrengungsbereich um 49 Artikel und lehnte weiterhin bei der höchsten Einstellung ab.
• Das zurückgezogene GPT-5-Nano war die nachsichtigste Konfiguration von allen.

Eine Aussage wie „Luna benötigt hohen Aufwand“ ist daher kein wiederverwendbarer Fakt. Sie galt für Luna bei einer Aufgabe, bedeutete aber bei einer anderen nichts. Der Aufwand ist eine Eigenschaft eines bestimmten Modells für eine bestimmte Aufgabe, und jedes solche Paar muss eigene Messungen aufweisen.

Ein größeres Modell ersetzt diese Messung nicht. Ein separates Testverfahren mit 80 Artikeln zur Überprüfung des Relevanzfilters, bei dem jedes Modell mit mittlerem Aufwand eingesetzt wurde, führte zu 31 Ablehnungen durch GPT-5.4-Mini, 34 durch Luna und 30 durch GPT-5.4-Nano. Ein größeres Modell änderte das Ergebnis kaum; die vollständige Deaktivierung der Logikfunktion bei GPT-5.4-Nano führte hingegen zu einer deutlichen Veränderung.

Auch der Aufwand weist ein Kostenprofil auf, das sich von allem anderen in der Rechnung unterscheidet, da er ohne feste Obergrenze ansteigen kann. Die Erhöhung des Themenfilters um ein Aufwandsniveau führte zu 10 weniger Ablehnungen, allerdings bei etwa dreimal höherem Tokenverbrauch – ein Kompromiss, der abgelehnt wurde.

Was nicht gemessen wurde

Die klare Benennung von Lücken ist Teil der Methode.

• Die versandte luna-Konfiguration wurde niemals anhand der menschlichen Etiketten bewertet; dieser Test wurde früh abgebrochen. Sie wird in der Produktion ohne einen einzigen fehlgeschlagenen Modellaufruf eingesetzt, was nichts über einen Qualitätsverlust aussagt.
• Ein einzelner Datensatz deutet darauf hin, dass luna bei der Klassifizierung von Content-Typen schlechter abschneidet als gpt-5.4-mini: 9 gute Artikel wurden fehlerhaft klassifiziert, während gpt-5.4-mini nur 5 Artikel fehlerhaft klassifizierte, und zwar bei einem nicht dokumentierten Aufwandsniveau. Wenn die Ausgabeanzahl abnimmt, ist dies der erste Punkt, den man überprüfen sollte.

Die Werte für das Thema-Filter wurden durch ein System erzeugt, das den gesamten Artikelbestand direkt an diesen Knoten sendet. Im tatsächlichen Ablauf wurden bereits in früheren Schritten die meisten Eingaben entfernt, wodurch die absoluten Zahlen überhöht sind. Das Relevanzprüfsystem ist davon unbeeinflusst, da es in der Produktion ebenfalls den gesamten Datenstrom erhält. Die Kalibrierungskontrolle für das Thema-Filter wurde nie durchgeführt, weshalb die Form seiner Kurve zuverlässig ist, aber seine absoluten Werte nicht.

Rauschen wirkt in beide Richtungen. Eine frühere Schlussfolgerung, dass ein Modell aufgrund eines 10-Punkte-Unterschieds „wirklich besser“ sei, musste zurückgenommen werden, als ein dritter Durchlauf mit derselben Konfiguration zum anderen Ergebnis führte. Die Lösung liegt in einem prozeduralen Ansatz: Man muss den Abweichungsgrad zwischen zwei Durchläufen derselben Einrichtung quantifizieren, bevor man einen Unterschied zwischen zwei verschiedenen Einrichtungen für gültig hält. Nur der Verlust von 15 Artikeln überschreitet diesen Schwellenwert, und er beschränkt sich auf einen einzigen Knoten.

Die Messdaten

Zwei Stichprobensets wurden verwendet. Bei den Anstrengungsversuchen wurden alle 198 im Cache gespeicherten Artikel direkt in einen Knoten gesendet, sodass nichts weiter flussaufwärts variieren konnte. Bei den End-zu-End-Versuchen wurde eine Stichprobe mit 200 Zeilen durch jeden Knoten geschickt; sie umfasste 72 von Menschen genehmigte Artikel und 49 von Menschen abgelehnte Artikel.

Bewertet anhand dieser menschlichen Etiketten:

• Ausgemusterte Konfiguration (gpt-5-mini plus gpt-5-nano): 48 gute Artikel konnten aus 72 behalten werden; 27 der 49 schlechten Artikel gelangten durch.
• gpt-5.4-mini zur Verarbeitung der Bewertungsknoten, mit angewandten Prompt-Anpassungen: 33 von 72 konnten behalten werden; 18 der 49 gelangten durch.
• Verwendete Konfiguration (luna bei neun von zehn Aufrufen): noch nicht gegen eines der Sets bewertet.

Der letzte Eintrag bleibt bis zur monatlichen Überprüfung leer, da die Etiketten erst nach dem Durchführen des Pruning-Commits vorhanden sind, und im Zeitpunkt der Analyse war September noch nicht pruned worden.

Frühes Produktionssignal

Produktionsdaten bieten einen teilweisen Ersatz. Luna ging am 30. August in Betrieb. Die Einbeziehungsraten für vergleichbare Zeiträume sehen wie folgt aus:

• Vorherige Modelle vom 1. bis 29. August: 4,55 Prozent (121 von 2.658).
• Vorherige Modelle in den letzten acht Tagen vor dem Umstieg: 4,86 Prozent (32 von 658).
• Luna vom 30. August bis zum 6. September: 4,08 Prozent (26 von 638).

Der Vergleich der beiden übereinstimmenden achttägigen Zeiträume mittels eines Z-Tests mit zwei Proportionen ergibt einen Wert von 0,69, der deutlich im Rahmen des Rauschens liegt. Zur Veranschaulichung: Die vorherige Konfiguration wies in den ersten acht Tagen im August einen Wert von 3,98 Prozent auf – ein größeres Schwanken innerhalb ihrer eigenen Historie als die durch luna verursachte Veränderung. Eine Woche und ein Tag ist eine kurze Zeitspanne, und die Einbeziehungsrate misst nicht die Qualität, doch das am meisten gefürchtete Szenario, dass luna den Datenfluss stillschweigend lahmlegt, ist bisher nicht eingetreten.

Während der Produktionsphase von Luna wurde erstmals eine Aufschlüsselung der Abgelehnten pro Knoten erstellt. In diesem Zeitraum wurden 603 Artikel von Luna ausgeschlossen. Davon waren 42 Prozent auf das Relevanzkriterium zurückzuführen, 38 Prozent auf den Inhaltstyp-Filter, 16 Prozent auf den Thema-Filter und 3 Prozent auf die Neuheitprüfung. Im Gegensatz dazu schloss die vorherige Konfiguration im Zeitraum vom 1. bis 29. August 2.526 Artikel aus, ohne einen einzigen Grund zu speichern; daher bedeutete die Rekonstruktion dieser Daten eine erneute Verarbeitung der Artikel anstelle einer einfachen Abfrage der Produktionsdaten. Falls Ihr Pipeline heute keinen Grund für die Ablehnung pro Schritt protokolliert, ist dessen Hinzufügen die günstigste Verbesserung, die Sie vor einer Migration vornehmen können.

Beschränkungen der Referenzwerte und einer einzelnen Ausführung

Die menschlichen Bewertungen weisen zwei eingebaute Beschränkungen auf. Sie umfassen nur die Artikel, die der alte Prozess durchgelassen hat, sodass eine neue Konfiguration niemals Anerkennung für das Retten von Inhalten erhalten kann, die der alte Prozess fälschlicherweise ausgeschlossen hat. Zudem weisen etwa 79 der 200 Beispiele keinerlei menschliche Bewertung auf.

Die Varianz zwischen den einzelnen Durchläufen ist groß. Drei wiederholte Durchläufe derselben Konfiguration über genau die gleichen 200 Zeilen ergaben bei einem einzigen Knoten Ablehnungsraten von 37, 48 beziehungsweise 55 Prozent – ein Unterschied, der weitaus größer ist, als es durch Störsignale aus dem Sampling zu erklären wäre. Ein vollständiger End-to-End-Durchlauf derselben Konfiguration führte zur Erstellung von vier neuen Artikeln und zum Verlust von vier weiteren. Beim erneuten Ausführen der ursprünglichen Konfiguration anhand dessen, was sie selbst in der Produktion erzeugt hatte, konnten lediglich 75 von insgesamt 121 markierten Artikeln wiederhergestellt werden; somit stimmte sie nur zu etwa 62 Prozent mit ihrer eigenen Historie überein. In der Praxis kann ein einzelner Durchlauf bei einem Knoten nur Unterschiede von rund 20 Punkten oder über den gesamten Prozessverlauf hinweg etwa acht Artikeln unterscheiden.

Ein besseres Vorgehen zur Überprüfung einzelner Änderungen besteht darin, jede Änderung genau auf den Elementen zu prüfen, die sie korrigieren soll, zusammen mit einer kleinen, unveränderlichen Menge von Elementen, die unberührt bleiben sollen, und sich auf den Gesamtprozess nur als grobe Warnung bei erheblichen Nebenschäden zu verlassen. Eine schnelle Korrektur zeigte, warum das sinnvoll ist: Sie schob vier Zielartikel über den reparierten Knoten hinaus, veränderte das Endergebnis jedoch kaum, da drei dieser vier später aus unbedeutenden Gründen abgelehnt wurden.

Wohin die Tokens tatsächlich gehen

Das Logis verbraucht Ausgabetokens, doch die eigentliche Ausgabe ist nicht das, was den Token-Vorrat aufbraucht. Bei den vorherigen Modellen machte die Ausgabe 13 Prozent aller Tokens aus, bei den neuen Modellen weniger als 3 Prozent; da die Anfragen lang sind, dominiert der Eingang.

Zum Zeitpunkt der Erstellung dieses Textes bietet das Datenaustauschprogramm zwei tägliche Pools an. Der größere Pool mit 2,5 Mio. Tokens pro Tag gilt für Luna sowie für die Nano- und Mini-Versionen von GPT-5.4. Der kleinere Pool mit 250.000 Tokens pro Tag gilt für die mittelgroßen und größeren Modelle. An einem normalen Werktag verbrauchte der Prozess mit den vorherigen Modellen etwa 1,95 Mio. Tokens und mit der neuen Modellreihe etwa 1,15 Mio. Tokens. Der exportierte Monatsdatensatz, hauptsächlich aus der alten Konfiguration plus acht Tagen der neuen, hätte bei den Flex-Raten ohne jegliche Vergünstigung etwa 4 Dollar gekostet.

Pro tausend Anfragen unterscheiden sich die Modelle erheblich:

• gpt-5-nano: 0,32 $
• gpt-5.4-nano: 0,52 $
• gpt-5.6-luna: 0,65 $
• gpt-5-mini: 1,49 $
• gpt-5.4-mini: 3,29 $ (kleine Stichprobe)

Luna ist bei der Kosten pro Anfrage nicht am günstigsten, und das ist in Ordnung. Sie kostet pro Anfrage deutlich weniger als die Mini-Modelle und nutzt denselben Pool wie die Nano-Modelle.

Zusatzkosten für Cache-Schreibvorgänge

In der Preisliste wird ein Detail versteckt, das man sorgfältig lesen sollte. Von den betrachteten Modellen berechnet nur Luna Gebühren für Cache-Schreibvorgänge, die 25 Prozent höher sind als die Kosten für normale, nicht im Cache gespeicherte Eingaben. Da die Anfragen hier über den ganzen Tag verteilt eintreffen und nicht in Schüben, verfallen die Cache-Einträge zwischen den Anfragen: 57 Prozent der Eingaben von Luna wurden als Cache-Schreibvorgänge abgerechnet, nur 41 Prozent als Cache-Lesevorgänge. Das Caching lohnt sich dennoch, da es die Kosten um 23 Prozent im Vergleich zu ohne Caching senkt – doch das ist noch weit entfernt von den 90 Prozent, die der Leserabatt nahelegt. Wenn Ihre Arbeitslast unregelmäßig ist, erhalten Sie einen größeren Rabatt; bei gleichmäßiger Belastung müssen Sie mit den zusätzlichen Schreibkosten rechnen.

API-Problemstellen, die jede Anfrage scheitern lassen

Bestimmte Verhaltensweisen von Parametern können eine Umbenennung in einen Ausfall verwandeln. Wie zum Zeitpunkt der Erstellung berichtet (überprüfen Sie dies anhand der aktuellen Dokumentation):

• Die Standard-Rechenanstrengung ist nicht in allen Versionen konstant: mittel für gpt-5, keine für die 5.4-Familie und wieder mittel für 5.6. Eine einfache Umbenennung des Modells ändert daher stillschweigend, wie intensiv jede Anfrage verarbeitet wird.
• Das höchste Rechenniveau ist nur bei Modellen der Version 5.6 verfügbar; dessen Anforderung bei einem Modell der Version 5.4 führt dazu, dass jede Anfrage fehlschlägt.
• Am Endpunkt für Chat-Completions wird jede Rechenanstrengung über „keine“ in Kombination mit Funktionswerkzeugen abgelehnt; solche Anfragen müssen an den Endpunkt für Antworten weitergeleitet werden. Da die Standard-Einstellung bei Luna „mittel“ ist, ist das Aufrufen von Werkzeugen mit Luna bei Chat-Completions unmöglich, es sei denn, die Rechenanstrengung wird ausdrücklich verringert.

Nichts davon kann zur Laufzeit wiederhergestellt werden. Typische Wiederholungslogiken kümmern sich um Serverfehler, Zeitüberschreitungen und Geschwindigkeitsbeschränkungen, nicht um ungültige Anfragen – daher versagt eine schlechte Kombination aus Modell und Aufwand bei jeder Zeile einer Ausführung statt nur einmal. Überprüfen Sie die Kombination aus Modell und Aufwand, wenn der Prozess gestartet wird, noch bevor die erste Zeile verarbeitet wird. Weitere Informationen zu den beiden Endpunkten finden Sie im vorhandenen Artikel über Items versus Messages in OpenAI’s Responses API.

Haupterkenntnisse

• Bewerten Sie niemals ein Ersatzmodell anhand seiner Übereinstimmung mit dem Modell, das es ersetzt; verwenden Sie stattdessen aufgezeichnete menschliche Entscheidungen als Referenzwahrheit.
• Zuordnen Sie jeden Verlust an einen Schritt im Pipeline-Prozess und teilen Sie mehrfach gestellte Fragen in separate, protokollierte Entscheidungen auf.

Vor der Neukalibrierung eines Prompts sollten Sie die angegebenen Gründe des neuen Modells lesen. Genaue Angaben zu Ihren Regeln deuten darauf hin, dass der Prompt veraltet ist – nicht das Modell.

Ein strengeres, aber rechtfertigbares Modell an einer Stelle, an der Ausfälle dauerhaft sind, lässt sich möglicherweise besser umgehen als es zu beheben.

Die Rechenleistung für das Reasoning gehört zum Modell-Pflichtenpaar. Legen Sie sie überall explizit fest, messen Sie sie Schritt für Schritt und bedenken Sie, dass es die einzige Kostenart ohne Obergrenze ist.

Quantifizieren Sie zunächst die Schwankungen von einer Ausführung zur nächsten; vertrauen Sie nur auf Abweichungen, die diese Schwankungen überschreiten.

Das nützlichste Dokument, das Sie vor der Freigabe einer Migration anfordern sollten, ist nicht die Anzahl der Abweisungen, sondern einige der eigenen Erklärungen des Modells dafür, was es weggelassen hat.