Design für Modell-Deprecations mit virtuellen Modellen und gestuften Umstellungen

Am 23. Juli 2026 wird OpenAI laut seiner Deprecation-Seite15 aufgeführte Modelleinträge abschalten – eine Mischung aus veralteten Snapshots und Aliasen für Codex-, Chat-, Deep-Research-, Search-, Audio-, Realtime- und Computer-Use-APIs. Die unmittelbare Aufgabe ist die Migration. Das dauerhafte Engineering-Problem ist die Abhängigkeitsverwaltung: Anwendungscode sollte nicht direkt von Identifikatoren abhängen, deren Lebensdauer von einem Modellanbieter kontrolliert wird.

Dieser Beitrag beschreibt ein sichereres Betriebsmuster: Inventarisierung der aktuellen Nutzung, Platzierung eines stabilen virtuellen Modell-Alias zwischen Anwendungen und Anbietermodellen, Evaluierung von Ersatzmodellen anhand arbeitslastspezifischer Tests, Umleitung des synchronen Traffics über ein gewichtetes Canary-Verfahren und Sicherstellung eines schnellen Rollback-Pfads.

1. Den Kalender wie ein SRE lesen

Die Deprecation-Seite von OpenAI definiert die Semantik direkt: Ein Modell gilt als deprecated ab dem Zeitpunkt der Ankündigung – es funktioniert zwar noch, hat aber nun ein Abschalt-Datum – und sobald es abgeschaltetist, werden Anfragen nicht mehr aufgelöst. Die veröffentlichte Richtlinie sieht eine Frist von mindestens sechs Monaten für allgemein verfügbare Modelle und mindestens drei Monaten für spezialisierte Varianten wie Codex- und Chat-Latest-Modelle vor. Preview-Modelle können eine Ankündigungsfrist von nur zwei Wochen haben, und OpenAI rät ausdrücklich davon ab, Previews für geschäftskritische Produktions-Workloads zu verwenden, es sei denn, das Team kann schnell migrieren (OpenAI Deprecation-Seite).

Die Ankündigung vom 22. April legte zwei konzentrierte Abschalt-Termine fest: 15 Einträge am 23. Juli und am 23. Oktober eine weitere Reihe von Legacy-Snapshots und Aliasen für GPT-3.5, GPT-4, GPT-4 Turbo, GPT-4.1 Nano, GPT-4o und die o-Serie, zusammen mit gpt-image-1 und mehreren feinabgestimmten Basismodell-Familien. Beachten Sie, was der 23. Oktober nicht ist: Es ist nicht die gesamte GPT-4-Familie und nicht die gesamte o-Serie – die veralteten o3-2025-04-16 und o3-pro-2025-06-10 Snapshots werden für den 11. Dezember separat aufgelistet, und nur der gpt-4o-2024-05-13 Snapshot erscheint aus der GPT-4o-Reihe.

Die Bildmodell-Sequenz verdient als Präzedenzfall Aufmerksamkeit. Als DALL·E 2 und 3 am 12. Mai abgeschaltet wurden, hatte OpenAI gpt-image-2, gpt-image-1oder gpt-image-1-mini als empfohlene Ersatzmodelle aufgeführt. Teams, die sich für gpt-image-1-mini entschieden haben, müssen nun vor der Abschaltung am 1. Dezember erneut migrieren, und gpt-image-1 selbst ist für den 23. Oktober zur Abschaltung vorgesehen. Die Lektion lässt sich verallgemeinern: das Migrationsziel kann ebenfalls ein Ablaufdatum haben, und eine Architektur, deren Reaktion auf eine Veraltung darin besteht, überall Modell-Strings zu bearbeiten und neu bereitzustellen, wird diese Arbeit im Takt des Anbieters wiederholen müssen.

Dies ist auch kein Muster eines einzelnen Anbieters. Anthropic listet Claude Opus 4.1 für die Einstellung am 5. August 2026, mit einer dokumentierten Richtlinie von mindestens 60 Tagen Vorankündigung für öffentlich veröffentlichte Modelle (Anthropic-Modell-Veraltungen). Google nennt den 16. Oktober 2026 als frühestes Abschaltdatum für Gemini 2.5 Pro, Flash und Flash-Lite sowie ein Preview-Modell – gemini-3.1-flash-lite-preview – lief vom 3. März bis zum 25. Mai 2026, also weniger als drei Monate von der Veröffentlichung bis zur Abschaltung (Gemini-Deprecations). Die API-Dokumentation von DeepSeek besagt, dass die Legacy-Aliase deepseek-chat und deepseek-reasoner am 24. Juli 2026 eingestellt werden und zur Kompatibilität auf die Thinking- und Non-Thinking-Modi von deepseek-v4-flashabgebildet werden; dieses Datum wird dort nicht als Abschaltung bezeichnet (DeepSeek-Modelle und Preise). Alle vier Anbieter veröffentlichen Änderungen am aktiven Modell-Lebenszyklus; ihre Ankündigungsfristen und Migrationspfade unterscheiden sich jedoch.

2. Das Inventarproblem: Was man nicht findet, kann man nicht migrieren

Jeder Migrationsleitfaden beginnt mit dem Hinweis, die Nutzung zu prüfen, und jedes Plattform-Team weiß, warum dieser Schritt oft untergeht: Modell-IDs verstecken sich in Service-Konfigurationen, Notebook-Konstanten, CI-Pipelines, Framework-Standardeinstellungen, Konfigurationsdateien von Coding-Agenten und Tools von Drittanbietern, deren Einführung längst vergessen ist. Grep findet die Strings in Ihren Repositories; es findet jedoch nicht das Volumen, den Verantwortlichen oder den Traffic, der außerhalb der Versionskontrolle entsteht. Eine verlässliche Bestandsaufnahme ist nur durch Beobachtung möglich: Wenn jeder Modellaufruf über ein zentrales Gateway läuft, lässt sich die Nutzung pro Modell – aufgeschlüsselt nach Team, Anwendung, Benutzer und virtuellem Konto, inklusive der anfallenden Kosten – einfach per Dashboard-Abfrage ermitteln. Die Frage „Wer ruft dieses auslaufende Modell noch auf?“ lässt sich dann mit konkreten Namen und Zahlen beantworten. Auch die Richtlinien von Anthropic weisen in diese Richtung und empfehlen Kunden, vor einer Migration Audits der Nutzung pro Schlüssel und Modell zu exportieren. Diese Bestandsaufnahme dient gleichzeitig als Priorisierungsfunktion: Ein Modell mit drei verbleibenden Aufrufen pro Tag aus einem vergessenen Batch-Job ist ein Ticket; eines, das ein kundenorientiertes Feature mit sechsstelligen monatlichen Kosten trägt, ist ein Projekt.

‍

‍