Migrationsprozess für Modelle

In diesem Artikel wird ein sechsstufiger Prozess für die Migration einer LLM-basierten Workload von einem Basismodell zu einem anderen beschrieben: Was sie in jeder Phase berücksichtigen müssen, welche Microsoft Foundry-Features gelten und wie sich die Arbeitsänderungen für verschiedene Arten von Teams ändern.

Was die Modellmigration bedeutet

Jedes Modell, das Sie im Produktivbetrieb einsetzen, hat ein Außerbetriebnahmedatum. Wenn ein Modell, von dem Sie abhängig sind, ersetzt wird oder wenn ein neueres Modell Ihre Arbeitsauslastung besser erfüllen würde, migrieren Sie. Das Austauschen eines Modells ist keine einzeilige Änderung: Ein anderes Modell kann den Ton, die Formatierung, das JSON-Shape, die Latenz, die Kosten oder das Toolaufrufverhalten leise verschieben und nachgeschalteten Code unterbrechen, der vom alten Verhalten abhängt.

Eine erfolgreiche Migration behält das Verhalten der Anwendung bei oder verbessert es auf messbare Weise. Erfolg erfordert einen wiederholbaren Prozess, um Drift zu erkennen, sich sicher anzupassen und qualität vor dem breiten Rollout zu beweisen.

Zeitpunkt der Migration

Eine Migration beginnt in der Regel aus vier Gründen:

• Ein Modell wird außer Betrieb genommen. In Foundry hat jedes allgemein verfügbare Modell ein Außerbetriebnahmedatum und ältere Modellfamilien werden nach und nach ersetzt. Richtlinien und Termine zur Außerbetriebnahme finden Sie unter Lebenszyklus- und Support-Richtlinie für Foundry Models und Zeitplan für die Außerbetriebnahme von Modellen.
• Ein besseres Modell ist verfügbar. Ein neueres Modell bietet eine höhere Qualität, niedrigere Kosten, eine bessere Latenz oder eine Funktion (z. B. strukturierte Ausgabe oder verbesserte Toolaufrufe), die Ihre Workload benötigt.
• Ein Kosten- oder Latenzproblem erzwingt eine Änderung. Die Latenz- oder Stückkosten des aktuellen Modells erfüllen ihre Anforderungen nicht mehr.
• Eine Funktionslücke blockiert das Produkt. Das aktuelle Modell kann nicht mehr tun, was Ihr Produkt jetzt erfordert.

Was geschieht am Rententermin?

Was Azure tut, wenn ein Modell außer Betrieb genommen wird, hängt davon ab, wie Sie Kapazität erwerben, und Foundry verwendet für jede dieser Optionen eine unterschiedliche Terminologie:

• Bereitstellungen vom Typ Standard, Global Standard und Data Zone Standard (pay-as-you-go) werden nach einem gestaffelten Zeitplan Region für Region automatisch aktualisiert. Sie steuern den Zeitpunkt, indem Sie versionUpgradeOption auf einen der folgenden Werte festlegen: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired oder NoAutoUpgrade (was bedeutet, dass die Bereitstellung bei Außerbetriebnahme nicht mehr funktioniert). Die Prioritätsverarbeitung folgt demselben Pfad.
• Bereitgestellte (PTU)-Bereitstellungen werden nicht automatisch aktualisiert. Sie migrieren diese selbst, entweder direkt (der Datenverkehr wird innerhalb eines Zeitfensters von 20–30 Minuten ohne Ausfallzeiten umgeleitet) oder nebeneinander (die neue Bereitstellung aufsetzen, testen, den Datenverkehr umleiten, die alte Bereitstellung löschen).
• Batch-Bereitstellungen folgen dem Side-by-Side-Pfad: das neue Modell bereitstellen, Aufträge erneut übermitteln, die alte Bereitstellung außer Betrieb nehmen.

Unabhängig davon, welcher Pfad gilt, ist die Entwickler-Herausforderung identisch: Bei einem festgelegten Datum beginnt Ihr Datenverkehr mit einem anderen Modell. Ein Endpunkt, der immer noch reagiert, bedeutet nicht, dass sich Ihre App weiterhin ordnungsgemäß verhält, sodass sowohl automatisch aktualisierte als auch manuell migrierte Workloads von der Bewertung und Überprüfung profitieren, die in diesem Artikel beschrieben wird.

Migrieren vor dem Einstellungsdatum

Das automatische Upgrade ist nur ein Sicherheitsnetz für pay-as-you-go-Bereitstellungen, nicht für einen Migrationsplan. Bereitgestellte Bereitstellungen verfügen über keinen Schutzmechanismus. Auf beide Weise ist es kein Ersatz für einen Migrationsplan. Zwei Richtlinienverpflichtungen bieten Ihnen Raum für die Migration in Ihrem eigenen Zeitplan, anstatt auf den Stichtag zu warten:

• Das Ersatzmodell wird etwa 90 Tage vor der Pensionierung in Global Standard verfügbar und etwa 30 Tage vor dem Ruhestand in den bereitgestellten Regionen, in denen der Vorgänger eingestellt wird. Verwenden Sie dieses Fenster, um das neue Modell auszuwerten und manuell zu migrieren.
• Die Einstellungstermine sind nicht erweiterbar. Es gibt kein Ausnahmeverfahren, daher gilt ein Termin, den Sie nicht eingeplant hatten, trotzdem für Sie.

Sie benötigen keinen Veraltungshinweis, um zu beginnen. Wenn ein neueres Modell günstiger, schneller oder fähiger ist, führen Sie es jetzt durch den Prozess. Die Migration wandelt den Ruhestand absichtlich in eine Formalität um. Da Migrationen auftreten, lohnt es sich, den Prozess wiederholbar zu machen.

Wer sollte den Migrationsprozess verwenden?

Der Migrationsprozess passt am besten, wenn Ihr Team ein LLM-basiertes Feature innerhalb eines größeren Produkts oder einer größeren Plattform erstellt, zu einem ungefähr vierteljährlichen Rhythmus migriert und einen klaren Besitzer (z. B. ein zentrales Plattformteam oder das App-Team) besitzt, das jede Migration absichtlich ausführt.

Dieser Prozess passt auch zu KI-nativen Teams, bei denen das Modell das Produkt ist. Die Phasen sind identisch, aber sie laufen schneller und oft parallel statt in strenger Reihenfolge.

Bei diesem Prozess wird davon ausgegangen, dass Sie von einem Basismodell zu einem anderen wechseln, also zwischen Modellen, die Sie so bereitstellen, wie sie im Modellkatalog veröffentlicht sind, ohne Anpassungen auf Gewichtsebene. Feinabgestimmte Workloads fallen nicht in den Geltungsbereich. Sie können nicht automatisch aktualisiert werden, da sie ihre eigene Uhr für das Training und die Außerbetriebnahme der Bereitstellung tragen. Das Anpassen fein abgestimmter Workloads bedeutet Destillation oder erneutes Training anstelle von Prompt- und Schemaänderungen. Wenn Sie fein abgestimmte Bereitstellungen ausführen, sollten Sie frühzeitig eine erneute Abstimmung des Ersatzbasismodells planen.

Migrationsphasen

Eine Migration durchläuft sechs Phasen. Jede Phase erzeugt ein Ergebnis, das in der nächsten Phase verwendet wird. Die Migrationsphasen sind:

Entdecken → Bewerten → Anpassen → Validieren → Einführen → Außer Betrieb nehmen

In der folgenden Tabelle werden die einzelnen Phasen und die Foundry-Features und -Tools beschrieben, die sie unterstützen. Funktionen sind sowohl in Microsoft Foundry als auch in Azure OpenAI verfügbar, es sei denn, sie sind mit nur Foundry gekennzeichnet; das bedeutet, dass Azure OpenAI kein Äquivalent hat.

In den Abschnitten pro Phase weiter unten in diesem Artikel wird erläutert, warum jede Phase vorhanden ist, wie ein erfolgreiches Ergebnis aussieht, was zu berücksichtigen ist, wann jedes Feature verwendet werden soll und wo die Phase häufig unterbrochen wird.

Vor der Migration: Vorbereiten eines Testdatensatzes

Dieser Vorbereitungsschritt fasst eine Reihe repräsentativer Eingaben, erwarteter Ausgaben und vereinbarter Erfolgskriterien zusammen, bevor eine Migration beginnt. Dieses Set ist eine einschränkende Abhängigkeit für die Mitte des Prozesses: Sie können in der Anpassungsphase ohne Eingaben keine erneute Ausführung durchführen und Sie können in der Validierungsphase ohne Grundwahrheit und Kriterien keine Bewertung vornehmen.

Zu berücksichtigende Aspekte

• Erstellen Sie das Dataset, bevor Sie ein Ziel auswählen. Das Dataset beschreibt Ihre Arbeitsauslastung, nicht das Kandidatenmodell, sodass Sie sie parallel zu Discover zusammenstellen können.
• Sammeln Sie Eingaben aus realen oder synthetischen Quellen. Verwenden Sie erfassten Produktionsdatenverkehr oder kuratierte Domänenbeispiele als CSV oder JSONL. Wenn Sie noch keine repräsentativen Daten haben, generieren Sie synthetische und gegnerische Eingaben mit dem Simulator.
• Instrumenterfassung, bevor Sie es benötigen. Die Aufnahme von Produktionsinhalten ist opt-in und nie rückwirkend, sodass Sie den Datenverkehr nicht auswerten können, den Sie nicht aufgezeichnet haben. Beginnen Sie jetzt mit der Protokollierung von Eingabeaufforderungen, Antworten, Latenz und Tokenanzahl.
• Frieren Sie den Datensatz ein. Halten Sie die Eingaben, Referenzwerte und Erfolgskriterien während der gesamten Migration fest. Wenn sich eine dieser Änderungen ändert, können Sie die Quell- und Zielergebnisse nicht mehr vergleichen.

Außerdem benötigen Sie ein Inventar der Modellbereitstellungen, die von Ihrer Workload verwendet werden, einschließlich ihrer Bereitstellungstypen (Standard, bereitgestellt oder Batch). Notieren Sie sich für jedes Quellmodell den Außerbetriebnahmetermin und den vorgeschlagenen Ersatz aus dem Außerbetriebnahmezeitplan für Modelle.

Phase 1: Entdecken

Der Zweck der Discover-Phase besteht darin, zu erkennen, dass eine Modelländerung bevorsteht oder sinnvoll ist, und zu entscheiden, ob gehandelt werden soll. Das Ergebnis ist eine Go-/No-Go-Entscheidung, und beim aktuellen Modell zu bleiben, ist eine legitime Option. Ein erfolgreiches Ergebnis ist ein frühes, strukturiertes Signal, das Ihnen das Abkündigungsdatum, das Nachfolgemodell und das Migrationszeitfenster nennt oder eine bewusste Entscheidung widerspiegelt, beim aktuellen Modell zu bleiben.

Zu berücksichtigende Aspekte

• Was ist der Ruhestand und wie viel Laufbahn haben Sie eigentlich? Betrachten Sie das Abkündigungsdatum abzüglich Ihrer Validierungs- und Rolloutzeit als den tatsächlichen Stichtag.
• Gibt es einen benannten vorgeschlagenen Ersatz, oder müssen Sie kandidaten selbst shortlisten?
• Bringt die Änderung Compliance-Anforderungen oder regionale Vorgaben mit sich (bei regulierten Workloads sind Verfügbarkeit und Zertifizierung oft wichtiger als Qualität)?

Wo es häufig zu Ausfällen kommt

Teams erfahren uneinheitlich von Abkündigungen – per E-Mail, über ein Banner im Portal oder durch eine interne Nachricht – und nehmen den Hinweis erst spät wahr. Diese Verzögerung verkürzt ein bereits enges Fenster. Soloentwickler und kleine Teams erfahren oft erst durch einen Fehler im Produktivbetrieb statt durch eine Ankündigung, dass etwas außer Betrieb genommen wurde.

Was Sie mitbringen

Der Einstellungszeitplan und die Models-API machen die Daten in einem stabilen Vertrag verfügbar. Reife Organisationen fügen oben eine dünne interne Benachrichtigungsebene hinzu, um sie an die richtigen Besitzer weiterzuleiten.

Phase 2: Bewerten

Der Zweck der Bewertungsphase besteht darin, das Kandidatenzielmodell zu wählen und zu bestätigen, dass Sie es ausführen können: die richtige Region, den richtigen Bereitstellungstyp, genügend Kontingent und Verfügbarkeit zusammen mit dem aktuellen Modell, damit ein Rollback möglich bleibt. Ein erfolgreiches Ergebnis ist eine klare Entscheidung für eines der Kandidatenmodelle, wobei Region, SKU, Kontingent und Kosten vor Beginn der Optimierung bestätigt sind.

Zu berücksichtigende Aspekte

• Qualität und Positionierung zwischen Kandidaten. Wenn mehrere Modelle im Einsatz sind, entscheiden Sie anhand der Qualität, welches zu Ihrem Workload passt, und nicht nur danach, welches in einem öffentlichen Benchmark am besten abschneidet.
• Kosten für Ihren eigenen Datenverkehr. Die Preisstruktur wechselt zwischen Modellgenerationen. Reasoning-Token, zwischengespeicherte Eingaben und der Mehraufwand für strukturierte Ausgaben können die Stückkosten um das Doppelte oder mehr beeinflussen. Kalkulieren Sie die monatlichen Kosten daher anhand historischer Nutzungsdaten, statt sich nur am Listenpreis zu orientieren.
• Betriebsverfügbarkeit. Vergewissern Sie sich, dass Region, SKU und Kontingent korrekt sind und dass das Ziel parallel zur Quelle ausgeführt werden kann, sodass ein Rollbackpfad erhalten bleibt.
• Compliance-Gating. Für regulierte Workloads können Zertifizierungen und regionale Verfügbarkeit die Kandidatenliste eingrenzen, bevor die Qualität überhaupt zum Thema wird.

Wo es häufig zu Ausfällen kommt

Entscheidungsparalyse tritt ein, wenn mehrere Kandidaten unklar positioniert sind. Teams stellen erst mitten in der Planung fest, dass das ausgewählte Modell in ihrer Region oder für ihre SKU nicht verfügbar ist. Oder eine Kostenprojektion zeigt, dass das neue Modell im realen Verkehr wesentlich teurer ist.

Was Sie mitbringen

Benchmarks werden auf öffentlichen Datensätzen berechnet, betrachten Sie die Bestenliste also eher als Filter denn als Endziel und überprüfen Sie die engere Auswahl anhand Ihrer eigenen Workloads. Für die Kostenprognose gilt dasselbe: Die Monatsansicht ergibt sich aus Ihren eigenen Token-Logs, was unkompliziert ist, sobald Ihnen die Traffic-Daten vorliegen.

Phase 3: Anpassen

Der Zweck der Anpassungsphase besteht darin, die Arbeitsauslastung für das neue Modell gut zu gestalten. Führen Sie zunächst die bestehende Workload unverändert erneut aus (um modellbedingte Verhaltensänderungen zu isolieren), analysieren Sie, was sich geändert hat, und überarbeiten Sie sie anschließend iterativ. Ein erfolgreiches Ergebnis ist ein Parallelverhaltensvergleich mit realem oder repräsentativem Datenverkehr, wobei jede Änderung nachverfolgt wird.

Adapt ist mehr als nur die Bearbeitung von Prompts.

Eingabeaufforderungen sind die sichtbarste Oberfläche, aber eine Migration berührt in der Regel vier weitere:

• Parameter temperature, top_p, max_tokens und Steuerelemente für den Argumentationsaufwand lassen sich nicht generationenübergreifend eins zu eins zuordnen und neuere Modellfamilien unterstützen einige Parameter möglicherweise nicht.
• Tooldefinitionen. Möglicherweise müssen Sie Argumentnamen, Beschreibungen und erforderliche Felder umformulieren oder präzisieren, an denen sich das alte Modell zuverlässig orientierte.
• Ausgabeschemata. Modelle unterscheiden sich darin, wie gut sie strukturierte Ausgaben einhalten. Möglicherweise müssen Sie einem Schema explizite Einschränkungen hinzufügen, die das alte Modell lose erfüllt hat, oder Sie können schließlich ein Schema erzwingen.
• Aufrufcode. Unterschiede zwischen API-Oberflächen und SDK (Chat-Vervollständigungen im Vergleich zu Antworten, Streaming-Shape und neuen oder umbenannten Anforderungsfeldern). Möglicherweise müssen Sie auch das nachgelagerte Parsing aktualisieren, das von der alten Antwortstruktur ausging.

Bei Agenten- und Workflow-Workloads überwiegt häufig die Arbeit an Schemas und Tool-Aufrufen gegenüber der Prompt-Arbeit.

Zu berücksichtigende Aspekte

• Geben Sie es unverändert wieder, bevor Sie Abstimmungen vornehmen. Führen Sie ihre aktuelle Konfiguration ohne Änderungen auf dem Zielmodell aus. Mit diesem Ansatz können Sie das Verhalten trennen, das das Modell von den von Ihnen eingeführten Änderungen geändert hat, und bietet Ihnen einen Basisplan.
• Beobachten Sie, was sich tatsächlich ändert. Ausführlichkeit, Argumentationstiefe, Einhaltung strukturierter Ausgabeformate, Form von Tool-Aufrufen, Ablehnungsverhalten und Latenzschwankungen ändern sich alle häufig.
• Geben Sie echte Ablaufverfolgungen wieder, um Regressionen bei Tool-Aufrufen zu erkennen. Zusätzliche Felder, umbenannte Argumente und eine geänderte Reihenfolge treten nur in echten Ablaufverfolgungen zutage, nicht in Benchmarks mit nur einer Interaktion.
• Verfolgen Sie Ihre Änderungen. Prompt-Re-Engineering ist einfach umzusetzen und geht leicht verloren. Behalten Sie das Original bei, und notieren Sie, was sich geändert hat und warum.

Gießerei-Features

Drei Foundry-Features unterstützen diese Phase:

• Prompt Optimizer ist die Schaltfläche "Optimieren " direkt unterhalb des Felds "Systemanweisungen" im Agent-Playground. Sie strukturiert Ihre Anweisungen mithilfe bewährter Methoden für das Eingabeaufforderungs-Engineering neu, zeigt die Gründe pro Absatz für jede Änderung an und unterstützt eine iterate Schleife: Fügen Sie einen Vorschlag hinzu, z. B. "Das JSON-Schema genau beibehalten" und optimieren Sie es erneut. Nur in Foundry verfügbar, nicht Azure OpenAI.
• Agentenoptimierung stimmt Anweisungen, Werkzeuge und Modellauswahl gemeinsam aufeinander ab – für Agenten-Workloads. Nur in Foundry verfügbar, nicht Azure OpenAI.
• Simulator generiert synthetische und adversariale Eingaben, wenn Sie keine Produktionsdaten zur Wiedergabe haben.

Wo es häufig zu Ausfällen kommt

Bei eingebetteten, produktbezogenen Workloads dauert diese Phase in der Regel die meiste Zeit, da die Diagnoseschleife manuell ist: Teams führen Aufforderungen erneut aus, vergleichen die Unterschiede und notieren selten, was sie geändert haben oder warum.

Was Sie mitbringen

• Beginnen Sie mit den Optimierern, und überprüfen Sie dann. Sie wenden allgemeine bewährte Methoden in einem einzigen Durchlauf an, anstatt sie an Ihr Dataset anzupassen, und sie optimieren Anweisungstext anstelle von Tooldefinitionen oder Ausgabeschemas. Behandeln Sie die Ausgabe als soliden ersten Entwurf: Kopieren Sie zuerst Ihren ursprünglichen Prompt (es gibt keinen Versionsverlauf) und prüfen Sie ihn dann erneut anhand Ihres eingefrorenen Datensatzes, bevor Sie der Änderung vertrauen.
• Planen Sie zusätzliche praktische Arbeit für familienübergreifende Verschiebungen ein. Es gibt keinen Workflow zum „Optimieren für Zielmodell X“, daher erfordert der Wechsel zwischen Modellfamilien eine bewusste Übersetzung von Prompt und Schema.
• Notieren Sie den Datenverkehr, bevor Sie ihn benötigen. Die Wiedergabe ist nur so gut wie Ihre Aufnahme, und die Inhaltserfassung ist opt-in und nie rückwirkend.

Phase 4: Überprüfen

Der Zweck der Validierungsphase besteht darin, zu entscheiden, ob die angepasste Workload sicher versendet werden kann, indem sie mit einer Qualitätsrubrik für einen kuratierten Datensatz bewertet wird. Die Rubrik kann regelbasiert, referenzbasiert, ein LLM als Bewertungsinstanz, eine menschliche Überprüfung oder ein domänenspezifisches Rahmenwerk sein. Ein erfolgreiches Ergebnis besteht darin, eine vertrauenswürdige Evaluierungssuite zu liefern, die auf einem festgeschriebenen Datensatz ausgeführt wird und die sowohl das App-Team als auch alle Prüfer für glaubwürdig halten.

"Validate" ist eine Phase, hat aber zwei Touchpoints. Behandeln Sie sie daher nicht als einzelnes End-of-Line-Ereignis:

• Bereiten Sie sich frühzeitig vor. Fixieren Sie den Datensatz und die Erfolgskriterien in Bevor Sie migrieren, bevor Sie adaptieren. Im Moment, in dem diese Änderungen geändert werden, ist Ihre Quelle und Ihr Ziel nicht mehr vergleichbar.
• Gate spät, in zwei Durchgängen. Führen Sie zunächst das aktuelle Modell auf dem fixierten Datensatz aus, um eine Ausgangsbaseline zu ermitteln – den Wert, den Sie übertreffen müssen. Bewerten Sie dann das Ziel für denselben Datensatz und entscheiden Sie.

Zu berücksichtigende Aspekte

• Halten Sie den Datensatz und die Kriterien unverändert. Dies ist die einzige wichtigste Disziplin im Prozess, um Die Ergebnisse vergleichbar zu halten.
• Messen Sie die drei Dimensionen, die der Abmeldung zugeordnet sind: Qualität (Auswertungs- oder Prüferbewertungen), Latenz (Zeit-zu-Erster-Token und Durchsatz, isoliert vom Aufruf, den Sie migrieren) und Kosten (Eingabe- und Ausgabetokenkosten pro Anforderung).
• Stimmen Sie die Rubrik mit der Arbeitsauslastung überein. Ein Bewertungsraster für klinische Zusammenfassungen, eine Vorgabe zur Reihenfolge von Tool-Aufrufen für Agenten oder bereits vorhandene Signale aus Nutzerfeedback könnten aussagekräftiger sein als ein allgemeiner Bewertungswert.
• Behandeln Sie das Tor als Signal für KI-native Teams. Anstelle eines einmaligen Durchlaufs/Fehlers wird die Auswertung kontinuierlich bei jedem Commit ausgeführt und mit dem Rollout verschmolzen.

Gießerei-Features

Zwei Foundry-Features unterstützen diese Phase:

• Azure AI Evaluation SDK umfasst mehr als 30 integrierte Evaluatoren für Fundiertheit, Relevanz, Retrieval, Kohärenz, Sprachflüssigkeit, referenzbasierte Metriken (F1, BLEU und ROUGE), Sicherheit sowie Agenten- und Azure OpenAI-Bewerter. Sie enthält auch ein benutzerdefiniertes LLM als Bewertungsinstanz für aufgabenspezifische Bewertungsschemata.
• Die Portalbewertung führt dieselben Auswerter für Modell-, Agent-, Datensatz- und Ablaufverfolgungsziele aus.

Führen Sie dieselbe Gruppe von Evaluatoren auf dem eingefrorenen Datensatz gegen beide, Quelle und Ziel, aus, damit die Zahlen vergleichbar sind.

Wo es häufig zu Ausfällen kommt

Die meisten Teams verfügen nicht über eine Evaluierungssuite, und diejenigen, die eine haben, haben sie oft selbst entwickelt. Bei regulierten Workloads ist zusätzlich eine verpflichtende menschliche oder qualitätssichernde Prüfung vorgeschaltet. Diese wird damit zu dem Engpass schlechthin. Diese Migrationen bleiben bei Validate hängen, nicht bei Adapt.

Was Sie mitbringen

Die Auswerter sind einsatzbereit, aber das Zusammenstellen eines domänenrelevanten Testsatzes aus Ihrem eigenen Produktionsverkehr ist bei Modell-Workloads (Nicht-Agenten-Workloads) mit praktischem Aufwand verbunden. Dieser Bedarf ist der Grund, warum sich der Vorbereitungsschritt auszahlt.

Phase 5: Einführung

Der Zweck dieser Phase besteht darin, die validierte Konfiguration stufenweise in die Produktion zu überführen: zuerst in einer Nicht-Produktionsumgebung, dann als Canary oder mit einem gewichteten Prozentsatz des Datenverkehrs und anschließend mit breiterer Verfügbarkeit. Überwachen Sie währenddessen die Latenz in Echtzeit, Fehler und idealerweise die Qualität im Vergleich zum Ausgangswert vor der Migration. Führen Sie dann einen Commit oder einen Rollback durch. Ein erfolgreiches Ergebnis ist eine schrittweise Verfügbarkeit über Canary-, gewichteten oder Schattenverkehr, ein Qualitätssignal im Live-Betrieb jenseits von Latenz und Fehlern sowie ein erhaltener Rollback-Pfad.

Zu berücksichtigende Aspekte

• Kennen Sie Ihren Bereitstellungstyp. Ihr Bereitstellungstyp bestimmt die Mechanismen: Standardfamilienbereitstellungen können automatisch ein Upgrade nach einem von Ihnen gesteuerten Zeitplan durchführen. Bereitgestellte, Batch- und fein abgestimmte Bereitstellungen werden manuell migriert. Die folgende Tabelle zeigt die Mechanismen nach Typ.
• Bewahren Sie einen Rollbackkorridor auf. Halten Sie die alte Bereitstellung erreichbar, bis Sie sich sicher sind. Entscheidungen zum Rollback, die durch den Ablauf einer Veraltungsfrist statt durch Fakten erzwungen werden, sind ein Warnzeichen dafür, dass Sie zu spät begonnen haben.
• Wenn ein Canary nicht möglich ist, verwenden Sie den Schatten- oder Spiegelmodus. Regulierte Datenflüsse (PHI, Finanztransaktionen) lassen es häufig nicht zu, ein neues Modell echtem Kundenverkehr auszusetzen. Das Äquivalent führt das neue Modell für Produktionseingaben offline aus und vergleicht Die Ausgaben mit dem alten Modell, ohne dass sich dies auf die Benutzer auswirkt.
• Achten Sie auf Regressionen, die von der Offline-Evaluierung übersehen wurden. Die Latenz realer Nutzer und das Verhalten in Randfällen können erst unter Produktionslast zutage treten.

Migrationsmechanik nach Bereitstellungstyp

Nachdem der Datenverkehr verlegt wurde, richten Sie die kontinuierliche Evaluierung ein, um einen stichprobenartig ausgewählten Anteil des Produktionsdatenverkehrs im Foundry Observability-Dashboard zu bewerten, verknüpft mit Ablaufverfolgungen für die Ursachenanalyse, sowie Azure Monitor-Warnungen, wenn die Qualität nachlässt.

Wo es häufig zu Ausfällen kommt

Qualitätsregressionen, die die Offlineauswertung verpasst hat, werden unter Produktionslast angezeigt. Rollbackentscheidungen werden häufig eher durch eine Abkündigungsfrist als durch Belege erzwungen, was ein Zeichen dafür ist, dass die Migration zu spät begann.

Was Sie mitbringen

Gewichtetes Routing zwischen zwei Bereitstellungen wird in Ihrer eigenen Gateway- oder Anwendungsschicht implementiert und der Rollbackkorridor ist eine bewusste Wahl, um die alte Bereitstellung für ein Fenster warm zu halten (eingebettete Teams möchten in der Regel etwa 30 Tage). Beide lohnen sich, einmal zu entwerfen und bei jeder Migration wiederzuverwenden.

Phase 6: Zurückziehen

Der Zweck der Stilllegungsphase besteht darin, die alte Bereitstellung außer Betrieb zu nehmen, Kapazitäten freizugeben, Bewertungsartefakte zu archivieren und die Änderung an nachgelagerte kundenorientierte Dokumentation, Marketingseiten, Support-Runbooks und Audit-Protokolle zu kommunizieren, sofern dort eine Aufbewahrung erforderlich ist. Am Ende ist das alte Deployment verschwunden, die Anzahl der Deployments geht zurück, und die gewonnenen Erkenntnisse fließen in den nächsten Zyklus ein.

Zu berücksichtigende Aspekte

• Betrachten Sie die Stilllegung als Governance-Thema, nicht nur als Bereinigung. Für regulierte Arbeitslasten können Aufbewahrungspflichten die Aufbewahrung von Artefakten für Jahre erfordern.
• Vergewissern Sie sich, dass die Quelle tatsächlich nicht mehr vorhanden ist. Überprüfen Sie, ob die alte Version eingestellt ist, und löschen Sie die Bereitstellung, damit sie die Kapazität nicht mehr verbraucht.
• Erkenntnisse weitertragen. Falten Sie frische Produktionsablaufverfolgungen zurück in Ihr goldenes Dataset, damit die nächste Migration billiger beginnt.

Wo es häufig zu Ausfällen kommt

Teams verzichten auf die Außerbetriebnahme, was zu einer Ansammlung von Zombie-Deployments führt. Teams, die alte Bereitstellungen nicht aktiv stilllegen, haben deutlich mehr Live-Bereitstellungen als vergleichbare Teams, und der Großteil davon ist struktureller Ballast aus früheren Migrationen. Ein gängiger verpasster Unterschritt ist die Kommunikation: Marketing- und Produktdokumentation beziehen sich nach dem Tausch noch auf das alte Modell.

Was Sie mitbringen

Das Observability-Dashboard zeigt die Anzahl der Bereitstellungen nach unten an, aber die Entscheidung, welche Bereitstellungen weiterhin lastbelastet sind, ist ein Urteil, das Ihr Team vorgibt. Machen Sie die Außerbetriebnahme zu einer klar definierten und nachverfolgten Aufgabe, statt bloß zu hoffen.

Die Migration ist selten binär

Reale Migrationen befinden sich häufig in einem geteilten Zustand: Ein Teil einer Arbeitslast läuft auf dem neuen Modell, während ein latenzsensibler oder riskanterer Pfad auf dem alten verbleibt, manchmal wochenlang. Planen Sie partielles Rollout und partielles Rollback anstelle eines einzelnen Wechsels vom alten Modell zum neuen Modell. Die Außerbetriebnahme hinkt dem Rollout oft um Wochen oder Monate hinterher, und diese weiterhin vorhandenen alten Bereitstellungen machen sich als Häufung bemerkbar.

Verwandte Inhalte

• Veraltungs- und Supportzeiträume in der Lebenszyklus- und Supportrichtlinie für Foundry-Modelle verstehen
• Überprüfen Sie Stilllegungsdaten und Ersatzmodelle im Zeitplan für die Stilllegung von Modellen
• Welche Modelle bereits außer Betrieb genommen wurden, sehen Sie in Außer Betrieb genommene Microsoft Foundry-Modelle.
• Vergleichen von Kandidatenmodellen mit Modell-Benchmarks und Bestenlisten
• Eingabeaufforderungen für ein neues Modell anpassen mit Eingabeaufforderungen mit Prompt Optimizer optimieren
• Überprüfen Sie die Qualität, bevor Sie wechseln, indem Sie Auswertungen aus dem Foundry-Portal ausführen.
• Überwachen Sie die migrierte Workload mit Observability in generative AI