Design zur Unterstützung der Lebenszyklen von Foundationmodellen

Foundation-Modelle sind versionsierte Abhängigkeiten, die Sie in Ihrer KI-Workload verwenden. Jedes Foundation-Modell verfügt über einen Lebenszyklus, der berücksichtigt werden muss. Wie Codebibliotheken und andere Abhängigkeiten in Ihrer Workload erhalten Foundation-Modelle Nebenversionsupdates, die Leistungsverbesserungen und Optimierungen bieten. Hauptversionsupdates führen wesentliche Änderungen an Funktionen, Leistung oder Schulungsdaten-Aktualität ein. Im Laufe der Zeit können Grundlagenmodelle veraltet sein, weil sie überholt sind oder weil die Host-Einstellungen Ihres Modells außerhalb Ihrer Kontrolle liegen.

Sie müssen Ihre Arbeitsauslastung so entwerfen, dass sie die dokumentierten Lebenszyklen der Modelle unterstützt, die Sie als Abhängigkeiten auswählen. Wenn Sie die Lebenszykluszyklen der Modelle nicht in Betracht ziehen, führen Sie möglicherweise unnötig riskante Upgrades durch, führen untestete Verhaltensänderungen ein, nehmen unnötige Arbeitsauslastungsausfallzeiten ein oder erleben Ausfalle aufgrund der Art und Weise, wie Ihre Hostingplattform End-of-Life-Modelle verarbeitet.

Eine Arbeitslast, die entwickelt wurde, um die Lebenszyklen ihrer Modelle zu unterstützen, erleichtert das Experimentieren und die sichere Migration zu neuen Basismodellen, sobald sie auf den Markt kommen.

Typen von Modellupdates

Der Umfang des Modellupdates in Ihrer generativen KI-Lösung kann drastisch variieren, von einem Upgrade für eine geringfügige Überarbeitungsänderung bis hin zur Auswahl einer neuen Modellfamilie. Es gibt verschiedene Gründe, warum Sie das Modell in Ihrer Lösung aktualisieren möchten. In der folgenden Tabelle sind verschiedene Updatebereiche sowie ein Beispiel und die Vorteile dieses Upgrades aufgeführt.

Änderungsbereich	Vorteile der Aktualisierung des Modells	Beispiel
Kleines Versionsupdate	Bietet verbesserte Leistung und optimierte Funktionen, in der Regel ohne erhebliche Änderungen an Ihrer vorhandenen Implementierung	Wechsel von GPT-4o v2024-08-06 zu GPT-4o v2024-11-20
Zwischenversionsupdate	Bietet erhebliche Leistungsverbesserungen, neue Funktionen und verbesserte Zuverlässigkeit bei gleichzeitiger Beibehaltung der meisten Abwärtskompatibilität und erfordert nur moderate Implementierungsanpassungen.	Wechsel von GPT-3 zu GPT-3.5
Hauptversionsupdate	Bietet transformative Verbesserungen in logischem Denken, Fähigkeiten, Kontextgröße und Leistung, die umfassende Implementierungsänderungen und die Anpassung der Eingabeaufforderungen rechtfertigen.	Wechsel von GPT-3 zu GPT-4
Aktualisierung einer Variante	Bietet spezielle Optimierungen, z. B. erhöhte Verarbeitungsgeschwindigkeit und reduzierte Latenz, während die Kernarchitektur beibehalten und in der Regel die Abwärtskompatibilität mit dem Basismodell gewährleistet wird	Wechsel von GPT-4 zu GPT-4-Turbo
Generationsübergreifendes Versionsupdate	Bietet erhebliche Verbesserungen bei der Begründung, der multimodalen Funktionen und der Leistung, die den Nutzen des Modells grundlegend erweitern und gleichzeitig eine vollständige Neuaufstellung der Implementierungsstrategien erfordern	Wechsel von GPT-4 zu GPT-4o
Allgemeiner Modellwechsel	Bietet Zugriff auf spezielle Funktionen, verschiedene Preis-Leistungs-Verhältnisse und potenziell bessere Ausrichtung mit bestimmten Anwendungsfällen	Wechsel von GPT-4 zu DeepSeek
Änderung eines spezialisierten Modells	Bietet domänenspezifische Optimierung, verbesserte Leistung für bestimmte Aufgaben und potenziell niedrigere Kosten im Vergleich zur Verwendung von allgemeinen Modellen für spezialisierte Anwendungen	Wechsel von GPT-4 zu Prizedata
Änderung der Bereitstellungsoption	Bietet eine bessere Kontrolle über Infrastruktur, Anpassungsoptionen und potenzielle Kosteneinsparungen und ermöglicht gleichzeitig eine spezialisierte Optimierung und einen verbesserten Datenschutz auf Kosten erhöhter Verwaltungsverantwortung.	Wechsel von LLaMa-1, das als verwalteter Online-Endpunkt in Azure AI Foundry gehostet wird, zu selbst gehostetem LLaMa-1 auf einer virtuellen Maschine

Wie in der Tabelle dargestellt, sind die Vorteile des Wechsels zu einem neuen Modell in der Regel eine Kombination der folgenden Faktoren:

• Leistung, z. B. Geschwindigkeit und Latenz

• Kapazität, z. B. Durchsatz, der in Transaktionen pro Minute gemessen wird

• Verfügbarkeit von Kontingenten

• Kosteneffizienz

• Regionale Verfügbarkeit

• Multimodale Funktionen

• Aktualisiertes Schulungswissen

• Fehlerkorrekturen

• Spezialisierung oder Entspezialisierung, um sich besser an Ihren Anwendungsfall anzupassen

• Vermeiden von Arbeitsausfällen aufgrund von Modell-Hostlebenszyklusrichtlinien

Verhalten beim Ablösen des Modells

Das Verhalten beim Ablösen eines Modells hängt von Ihrer Strategie zur Bereitstellung des Modells ab. Es gibt drei wichtige Strategien für die Bereitstellung von Modellen. Es ist wichtig, dass Sie verstehen, wie jede Strategie mit dem Ablösen von Versionen umgeht:

• MaaS-Lösungen (Modell as a Service) sind vortrainierte Modelle, die als APIs verfügbar gemacht werden, die Skalierbarkeit und Einfache Integration bieten. Sie haben einen Kompromiss zwischen potenziell höheren Kosten und einer niedrigeren Kontrolle über Modelle. Beispiele für MaaS-Lösungen sind Modelle, die in Azure OpenAI in Foundry Models und Modellen aus dem Modellkatalog bereitgestellt werden, die als serverlose APIs bereitgestellt werden.

• MaaP-Lösungen (Modell als Plattform) sind Modelle, die in einer größeren Plattform bereitgestellt und verwaltet werden, z. B. Modelle aus dem Azure-Modellkatalog, der in verwalteter Compute bereitgestellt wird. Diese Lösung bietet in der Regel eine größere Kontrolle über Modelle, erfordert jedoch mehr Verwaltung als MaaS-Lösungen.

• Self-Hosting-Modelle sind Modelle , die in Ihrer eigenen Infrastruktur bereitgestellt werden. Diese Bereitstellung bietet maximale Kontrolle über Modelle, erfordert jedoch eine erhebliche Verantwortung für Infrastruktur, Verwaltung und Wartung.

Sowohl die MaaS- als auch die MaaP-Strategien beziehen sich in Azure auf Modellquellen aus dem Azure AI-Modellkatalog. Modelle im Modellkatalog folgen einem Lebenszyklus, in dem Modelle veraltet und dann zurückgezogen werden. Sie müssen diese Eventualitäten in Ihrer Workload planen.

Warnung

Bei MaaS-Diensten, einschließlich von Azure OpenAI bereitgestellten Modellen und Modellen, die mithilfe des serverless-API-Modells bereitgestellt werden, ist es wichtig zu verstehen, dass vorhandene Bereitstellungen für abgeschaltete Modelle HTTP-Fehler zurückgeben. Wenn Sie kein Upgrade auf ein unterstütztes Modell durchführen, funktioniert Ihre Anwendung nicht mehr wie erwartet. Für veraltete Modelle können Sie keine neuen Bereitstellungen für diese Modelle erstellen, vorhandene Bereitstellungen funktionieren jedoch weiterhin, bis sie eingestellt sind. Für weitere Informationen lesen Sie Serverless-API-Modellabschaffungen und -einstellungen sowie Abschaffungen und Einstellungen des Azure OpenAI-Modells.

Wenn Sie selbstgehostete Modelle nutzen oder verwaltete Rechenkapazität verwenden, behalten Sie die volle Kontrolle und sind nicht verpflichtet, Modelle zu aktualisieren. Möglicherweise möchten Sie jedoch einen Modelllebenszyklus für die zusätzlichen Vorteile replizieren, die ein neueres Modell zu Ihrer Arbeitsauslastung bringen kann.

Breite der Änderung für Modellupdates

Ein Diagramm zeigt eine Verbindung, die von einem Benutzer zu einer intelligenten Anwendung und dann zu einem Orchestrator wechselt. Drei Kästchen weisen mit gestrichelten Zeilen auf den Orchestrator hin: Konfiguration, Prompt und Orchestrierungslogik. Der Orchestrator verfügt über durchgehende Linien, die auf drei verschiedene KI-Modelle verweisen: Model-x-v1, Model-x-v1.1 und Model-y-v1. Der Orchestrator verfügt außerdem über einen Pfeil, der auf ein Feld verweist, das mit API oder Agent gekennzeichnet ist. Das API- oder Agent-Feld verfügt über eine durchgezogene Linie, die auf ein Feld mit der Aufschrift Wissensdatenbank verweist. Eine Pipeline mit vier Schritten verweist auf die Wissensdatenbank mit einer gestrichelten Linie. Die vier Schritte sind: Chunk-Dokumente, Anreichern von Chunks, Einbetten von Chunks und Persistieren von Chunks. Nummerierte Kreise kommentieren mehrere Teile des Diagramms. Der erste Kreis befindet sich neben den Modellen. Der zweite Kreis befindet sich neben der Konfiguration. Der dritte Kreis steht neben dem Prompt. Der vierte Kreis befindet sich neben der Orchestrierungslogik. Der fünfte Kreis befindet sich neben der gestrichelten Linie von der Pipeline zur Wissensdatenbank. Der sechste Kreis befindet sich unter den Modellen.

Sie müssen bewerten, wie sich ein Modellupdate auf Ihre Arbeitsauslastung auswirkt, damit Sie den Übergang vom alten Modell zum neuen Modell planen können. Der Umfang der Arbeitsauslastungsänderung hängt von den funktionalen und nicht funktionsfreien Unterschieden zwischen den alten und neuen Modellen ab. Das Diagramm zeigt eine vereinfachte Chatarchitektur mit nummerierten Abschnitten, die Bereiche hervorheben, in denen eine Modellaktualisierung auswirkungen kann.

Berücksichtigen Sie für jeden dieser Bereiche Ausfallzeiten durch Updates und wie Sie mit Anforderungen umgehen, die das System bearbeitet. Wenn Wartungsfenster für Ihre Workload verfügbar sind, verwenden Sie diese Fenster, wenn der Umfang der Änderung groß ist. Wenn keine Wartungsfenster verfügbar sind, sollten Sie Änderungen in diesen Bereichen vornehmen, um die Funktionalität Ihres Workloads und die Ziele des Servicelevels während der Modellaktualisierung aufrechtzuerhalten.

1. Das Modell: Die offensichtliche Änderung ist das Modell selbst. Sie stellen das neue Modell mithilfe Der ausgewählten Modellbereitstellungsstrategie bereit. Sie müssen die Kompromisse zwischen In-Place Upgrades und Side-by-Side Bereitstellung evaluieren.

   Wenn Sie von einem fein abgestimmten Modell zu einer neuen Modellrevision wechseln, müssen Sie die Feinabstimmung der neuen Modellversion erneut durchführen, bevor Sie es verwenden. Wenn Sie auf ein anderes Modell aktualisieren, müssen Sie feststellen, ob eine Feinabstimmung erforderlich ist.

2. Die Modellkonfiguration: Wenn Sie das Foundation-Modell in Ihrer KI-Lösung aktualisieren, müssen Sie möglicherweise Hyperparameter oder Konfigurationen anpassen, um die Leistung für die Architektur und die Funktionen des neuen Modells zu optimieren. Beispielsweise kann ein Wechsel von einem transformatorbasierten Modell zu einem wiederkehrenden neuralen Netzwerk unterschiedliche Lernraten und Batchgrößen erfordern, um optimale Ergebnisse zu erzielen.

3. Die Eingabeaufforderung: Wenn Sie Foundation-Modelle in Ihrer Workload ändern, müssen Sie möglicherweise Systemaufforderungen in Ihren Orchestratoren oder Agents anpassen, um die Stärken und Funktionen des neuen Modells anzupassen.

   Zusammen mit dem Aktualisieren der Modellkonfiguration ist die Aktualisierung der Eingabeaufforderung eine der häufigsten Änderungen, wenn Sie Modelle aktualisieren. Wenn Sie ein neues Modell auswerten, auch für ein Nebenversionsupdate, testen Sie Änderungen an der Eingabeaufforderung, wenn es Ihre Anforderungen nicht erfüllt. Dieser Ansatz stellt sicher, dass Sie Leistungsprobleme beheben, bevor Sie andere Änderungen untersuchen. Sie müssen sich mit der Aufforderung befassen, wenn Sie zu neuen Modellen wechseln. Wahrscheinlich müssen Sie sich auch mit dem Prompt befassen, wenn Sie große Revisionsänderungen vornehmen.

4. Die Orchestrierungslogik: Bei einigen Modellupdates, insbesondere wenn Sie neue Features nutzen, müssen Sie Änderungen an Ihrer Orchestrierungs- oder Agentlogik vornehmen.

   Wenn Sie ihr Modell beispielsweise auf GPT-4 aktualisieren, um funktionsaufrufe nutzen zu können, müssen Sie ihre Orchestrierungslogik ändern. Ihr altes Modell hat ein Ergebnis zurückgegeben, das Sie an den Aufrufer zurückgeben konnten. Beim Aufrufen von Funktionen gibt der Aufruf des Modells eine Funktion zurück, die Ihre Orchestrierungslogik aufrufen muss. In Azure ist es typisch, die Orchestrierungslogik im Azure AI Foundry Agent Service oder mithilfe codebasierter Lösungen wie Semantikkern oder LangChain zu implementieren, die in Azure gehostet werden.

5. Die Erdungsdaten: Bei einigen Modellaktualisierungen und größeren Bereichsänderungen müssen Sie möglicherweise Änderungen an Ihren Erdungs- oder Feinabstimmungsdaten vornehmen oder wie Sie diese Daten abrufen.

   Wenn Sie z. B. von einem generalisierten Modell zu einem domänenspezifischen Modell wechseln, z. B. ein Modell, das sich auf Finanzen oder Medizin konzentriert, müssen Sie möglicherweise keine domänenspezifischen Erdungsdaten mehr an das Modell übergeben. Ein weiteres Beispiel ist, wenn ein neues Modell ein größeres Kontextfenster verarbeiten kann. In diesem Szenario möchten Sie möglicherweise andere relevante Blöcke abrufen oder die Größe Ihrer Blöcke optimieren. Weitere Informationen finden Sie unter Entwurf und Entwicklung einer RAG-Lösung (Retrieval Augmented Generation).

6. Hardware: Bei Modellen, die in MaaP ausgeführt werden, kann eine Modelländerung neue Hardware erfordern. Nur bestimmte Compute-SKUs sind für Modelle aus dem Katalog aktiviert. Außerdem kann Hardware veraltet sein, was erfordert, dass Sie das Modell auf neuer Hardware ausführen.

Gestaltung für Veränderung

Sie werden höchstwahrscheinlich Modelle in Ihrem Workload aktualisieren. Wenn Sie die MaaS-Bereitstellungsstrategie in Azure verwenden, werden Modelle eingestellt und müssen auf eine neuere Version aktualisiert werden. Sie können auch zu verschiedenen Modellen oder Modellversionen wechseln, um neue Features, niedrigere Preise oder verbesserte Leistung zu nutzen. In jedem Fall muss Ihre Architektur die Aktualisierung des Modells unterstützen, das von Ihrer generativen KI-Arbeitslast verwendet wird.

Im vorherigen Abschnitt wurden die verschiedenen Änderungsbreiten erläutert. Sie sollten die richtigen Methoden für maschinelles Lernen (MLOps), Datenvorgänge (DataOps) und generative KI-Vorgänge (GenAIOps) befolgen, um automatisierte Pipelines für modellbezogene Feinabstimmungen, Technikeraufforderungen, Ändern von Hyperparametern und Verwalten der Orchestrierungslogik zu erstellen und zu verwalten.

Aktualisierungen der Hyperparameter und Eingabeaufforderungen sind in den meisten Modellupdates üblich. Da diese Änderungen so häufig sind, sollte Ihre Architektur einen kontrollierten Änderungsmechanismus für diese Bereiche unterstützen. Ein wichtiger Aspekt ist, dass Eingabeaufforderungen und Hyperparameter für bestimmte Modellversionen entwickelt werden. Sie müssen sicherstellen, dass die Eingabeaufforderungen und Hyperparameter immer mit dem richtigen Modell und der richtigen Version verwendet werden.

Automatisierte Pipelines

Implementieren Sie automatisierte Pipelines, um die unterschiedlichen Aspekte Ihrer generativen KI-Anwendung zu testen und zu bewerten:

• MLOps: Befolgen Sie die Azure MLOps-Anleitung zum Erstellen von Pipelines für die Modelloptimierung, falls zutreffend.

• GenAIOps: Implementieren Sie GenAIOps-Pipelines zum Testen und Auswerten von Änderungen am Modell, modellieren von Hyperparametern, Eingabeaufforderungen und Orchestrierungslogik.

• DataOps: Implementieren Sie DataOps-Pipelines zum Testen und Auswerten von Änderungen an Ihren RAG-Erdungsdaten.

Sie sollten Pipelines aus den folgenden Gründen implementieren:

• Zu Ihrer Unterstützung im iterativen Entwicklungsprozess und bei der Experimentierung (innere Schleife)
• So führen Sie eine sichere Bereitstellung und Operationalisierung Ihrer generativen KI-Lösung (äußere Schleife) durch

Verwenden Sie nach Möglichkeit die gleichen Basisplandaten, die Sie mit der Produktionsanwendung verwenden, um die Änderungen an Ihrer generativen KI-Anwendung zu testen. Dieser Ansatz ist möglicherweise nicht möglich, wenn die aktualisierte Anwendung neue Modellfeatures verwendet, die eine Änderung an den Daten erfordern.

Überlegungen zur Architektur

In einfachen Architekturen wie der unten beschriebenen ruft der Client das Modell direkt mit der richtigen Aufforderungsversion und Konfiguration auf. Wenn Änderungen an der Eingabeaufforderung vorhanden sind, wird ein neuer Client mit der neuen Eingabeaufforderung bereitgestellt und ruft das neue Modell auf. Das Verknüpfen der Eingabeaufforderungs-, Konfigurations- und Modellversionen ist keine Herausforderung.

Ein Diagramm zeigt einen Benutzer, der eine Verbindung mit einer intelligenten Anwendung herstellt, die sich direkt mit model-x-v1 verbindet. Drei Elemente zeigen auf die intelligente App mit gestrichelten Linien, die angeben, dass die App diese Elemente enthält. Die Elemente sind die Konfiguration, der Prompt und die Orchestrierungslogik.

Produktionsarchitekturen sind nicht einfach. In der Regel implementieren Sie einen Orchestrator oder Agent, dessen Verantwortung es ist, den Fluss der Interaktionen zwischen jeder Wissensdatenbank und den Modellen zu verwalten. Ihre Architektur kann auch eine oder mehrere Abstraktionsebenen implementieren, z. B. einen Router oder ein Gateway:

• Router: Ein Router leitet den Datenverkehr an verschiedene Orchestrator-Installationen weiter. Ein Router eignet sich bei Bereitstellungsstrategien wie blaugrünen Bereitstellungen, bei denen Sie einen bestimmten Prozentsatz des Datenverkehrs als Teil Ihrer sicheren Bereitstellungsmethoden an eine neue Orchestratorversion weiterleiten möchten. Diese Komponente kann auch für A/B-Tests oder die Spiegelung des Datenverkehrs verwendet werden, um getestete, aber nicht validierte Änderungen mit dem Produktionsverkehr zu evaluieren.

• Tor: Es ist üblich, den Proxyzugriff auf KI-Modelle aus verschiedenen Gründen zu verwenden. Sie können z. B. das Lastenausgleichsmodul aktivieren oder Failover zwischen mehreren Back-End-Instanzen aktivieren, benutzerdefinierte Authentifizierung und Autorisierung implementieren oder Protokollierung und Überwachung für Ihre Modelle implementieren.

Ein Diagramm zeigt einen Benutzer, der eine Verbindung mit einer intelligenten Anwendung herstellt, die eine Verbindung mit einem Router herstellt. Der Router stellt eine Verbindung zu zwei Bereitstellungen im Orchestrator her. Jede Bereitstellung verbindet sich mit einem Gateway. Das Gateway stellt eine Verbindung mit drei verschiedenen Modellen her: model-x-v1, model-x-v1.1 und model-y-v1. Der Orchestrator stellt auch eine Verbindung mit einer API oder einem Agenten her, die eine Verbindung zu einer Wissensdatenbank herstellt. Pfeile zeigen auf den Router und das Gateway mit der Beschriftung "Gemeinsame Abstraktionsebenen in einer generativen KI-Arbeitslast".

Aufgrund der verschiedenen Abstraktionsebenen muss Ihre Architektur so gestaltet sein, dass bestimmte Versionen von Eingabeaufforderungen an bestimmte Modelle oder Modellversionen gesendet werden können. Sie können z. B. eine Eingabeaufforderung in der Produktion haben, z. B. "prompt1", die für ein Modell entwickelt wurde, z. B. "Model1". Wenn Sie ein Upgrade auf Model1.1 durchführen, müssen Sie möglicherweise die Eingabeaufforderung1 auf "Eingabeaufforderung2" aktualisieren. In diesem Beispiel muss Ihre Architektur immer "prompt1" mit "model1" und "prompt2" mit "model1.1" verwenden.

Router

Das folgende Diagramm veranschaulicht eine Architektur, die einen Router verwendet, um Anforderungen an mehrere Bereitstellungen weiterzuleiten. Ein weiteres Beispiel für diese Architektur umfasst Azure AI Foundry und verwendet einen verwalteten Online-Endpunkt als Router. Und die verschiedenen Versionen des Orchestrators werden auf verwalteten Rechenressourcen bereitgestellt.

Ein Diagramm zeigt einen Benutzer, der eine Verbindung mit einer intelligenten Anwendung herstellt, die eine Verbindung mit einem Router herstellt (mit der Bezeichnung 1). Der Router stellt eine Verbindung zu zwei Bereitstellungen in einem Orchestrator her (gekennzeichnet mit 2). Jede Bereitstellung enthält eine Konfiguration, Aufforderung (bezeichnet 3) und Orchestrierungslogik (mit der Bezeichnung 4). Jede Bereitstellung stellt eine Verbindung mit einem bestimmten Modell her (mit der Bezeichnung 5). Bereitstellung 1 stellt eine Verbindung mit Modell-x-v1 her, während Bereitstellung 2 eine Verbindung mit Modell-x-v1.1 herstellt. Der Orchestrator stellt auch eine Verbindung mit einer API oder einem Agenten her, die eine Verbindung zu einer Wissensdatenbank herstellt.

Der folgende Flow beschreibt, wie verschiedene Bereitstellungen eines Orchestrators das richtige Modell aufrufen. Jede Bereitstellung hat ihre eigene Version der Modellkonfiguration und einen Prompt:

1. Ein Benutzer gibt eine Anforderung aus einer intelligenten Anwendung aus und diese Anforderung wird an einen Router gesendet.

2. Der Router stellt je nach seiner Logik entweder die Bereitstellung 1 oder die Bereitstellung 2 des Orchestrators bereit.

3. Jede Implementierung verfügt über eine eigene Version der Eingabeaufforderung und Konfiguration.

4. Der Orchestrator ist mit dem jeweiligen Modell und der spezifischen Version konfiguriert. Sie verwendet diese Informationen, um das entsprechende Modell und die entsprechende Version direkt aufzurufen.

5. Da die spezifische Version der Eingabeaufforderung zusammen mit dem Orchestrator bereitgestellt wird, der mit dem spezifischen Modell und der Version konfiguriert ist, wird die richtige Eingabeaufforderung an die richtige Modellversion gesendet.

Tor

Das folgende Diagramm veranschaulicht eine Architektur, die einen Router verwendet, um Anforderungen an mehrere Bereitstellungen weiterzuleiten. In dieser Architektur werden jedoch alle Modellanforderungen über ein Gateway weitergeleitet. Es ist üblich, den Proxyzugriff auf KI-Modelle aus verschiedenen Gründen zu ermöglichen, einschließlich lastenausgleich, das Failover zwischen mehreren Back-End-Instanzen in einer einzelnen Region oder mehreren Regionen zu ermöglichen und eine bereitgestellte Durchsatzeinheit mit einer Pay-as-you-go-Überlaufstrategie zu implementieren.

Ein Diagramm zeigt einen Benutzer, der eine Verbindung mit einer intelligenten Anwendung herstellt, die eine Verbindung mit einem Router herstellt (mit der Bezeichnung 1). Der Router stellt eine Verbindung zu zwei Bereitstellungen in einem Orchestrator her (gekennzeichnet mit 2). Jede Bereitstellung enthält eine Konfiguration, Aufforderung (bezeichnet 3) und Orchestrierungslogik (mit der Bezeichnung 4). Jede Bereitstellung stellt eine Verbindung mit einem Gateway mit der Bezeichnung 5 her. Jede Verbinderzeile verfügt über eine Beschriftung, die einen HTTP-Header anzeigt, der das Modell und die Version angibt. Bereitstellung 1 gibt model-x-v1 an, während Bereitstellung 2 model-x-v1.1 angibt. Das Gateway stellt eine Verbindung mit model-x-v1 und model-x-v1.1 her (mit der Bezeichnung 6). Der Orchestrator stellt eine Verbindung zu einer API oder einem Agenten her, die wiederum eine Verbindung zu einer Wissensdatenbank herstellt.

Der folgende Ablauf beschreibt, wie verschiedene Implementierungen eines Orchestrators das richtige Modell über ein Gateway aufrufen. Jede Bereitstellung hat ihre eigene Version der Modellkonfiguration und einen Prompt:

1. Ein Benutzer gibt eine Anforderung aus einer intelligenten Anwendung aus und diese Anforderung wird an einen Router gesendet.

2. Der Router routet je nach seiner Logik entweder zu Bereitstellung 1 oder zu Bereitstellung 2.

3. Jede Bereitstellung hat ihre eigene Version des Prompts.

4. Der Orchestrator ist mit dem jeweiligen Modell und der spezifischen Version konfiguriert. Diese Informationen werden verwendet, um einen HTTP-Header festzulegen, der das richtige Modell und die richtige Version angibt, die aufgerufen werden soll.

5. Der Orchestrator ruft das Gateway auf. Die Anforderung enthält den HTTP-Header, der den Namen und die Version des zu verwendenden Modells angibt.

6. Das Gateway verwendet den HTTP-Header, um die Anforderung an das entsprechende Modell und die entsprechende Version weiterzuleiten. Es kann auch eine konfiguration anwenden, die auf dem Gateway definiert ist.

Externalisieren der Konfiguration

Das Cloud-Entwurfsmuster für externen Konfigurationsspeicher ist eine gute Möglichkeit, Anweisungen und Konfigurationen zu speichern. Bei einigen Bereichen von Modelländerungen können Sie die Bereitstellung des Modells möglicherweise mit dem System Prompt und den Konfigurationsänderungen koordinieren, wenn diese an einem aktualisierbaren Speicherort außerhalb des Codes Ihres Orchestrators oder Agenten gespeichert sind. Dieser Ansatz funktioniert nicht, wenn Sie die Orchestrierungslogik anpassen müssen, ist aber bei vielen kleineren Modellaktualisierungen nützlich.

Wahl der Rechenleistung

Bei MaaP-Hosting sind Modelle häufig auf eine Teilmenge der vom Host bereitgestellten Computeressourcen beschränkt. Die gesamte Datenverarbeitung unterliegt Kontingenten, Verfügbarkeitsbeschränkungen und End-of-life-Ankündigungen. Verwenden Sie die Routingmuster, um den Übergang zu neuer Hardware zu unterstützen, wenn Ihre aktuelle Hardware nicht mehr unterstützt wird, oder es gibt Einschränkungen, die zusätzliche Skalierung verhindern.

Ein Beispiel für eine End-of-life-Ankündigung ist die Ankündigung der NC A100 v4 Compute-Serie. Wenn Sie Modelle auf dieser Hardware hosten, müssen Sie zu einer anderen unterstützten SKU wechseln, die nicht am Ende der Lebensdauer ist und mehr Verfügbarkeit hat. Dieser Übergang kann parallel auch einen Modellwechsel erfordern, wenn die neue SKU Ihr aktuelles Modell nicht unterstützt.

Empfehlungen

• Fügen Sie Ebenen der Abstraktion und Dereferenzierung hinzu, um kontrollierte Änderungen an bestimmten Bereichen Ihrer Workload zu ermöglichen. Zu diesen Bereichen gehören der Client, die intelligente Anwendungs-API, die Orchestrierung, das Modellhosting und das Grundlagenwissen.

• Alle Änderungen an Modellversionen, Eingabeaufforderungen, Konfigurationen, Orchestrierungslogik und der Abfrage von Grundwissen müssen vor der Nutzung in der Produktion getestet werden. Stellen Sie sicher, dass getestete Kombinationen in der Produktion zusammengeheftet werden, was bedeutet, dass sie bei der Bereitstellung eng miteinander verknüpft bleiben. A/B-Tests, Lastenausgleich und blaugrüne Bereitstellungen dürfen keine Komponenten kombinieren, um zu vermeiden, dass Benutzer nicht getesteten Kombinationen ausgesetzt werden.

• Testen und bewerten Sie neue Versionen und neue Modelle mithilfe automatisierter Pipelines. Sie sollten die Ergebnisse mit den Ergebnissen Ihres Basisplans vergleichen, um sicherzustellen, dass Sie die erforderlichen Ergebnisse erhalten.

• Achten Sie darauf, Modelle zu aktualisieren. Vermeiden Sie die Verwendung von Plattformfeatures, die Produktionsmodelle automatisch auf neue Versionen aktualisieren, ohne die Möglichkeit zu testen. Sie müssen wissen, wie sich jedes Modellupdate auf Ihre Arbeitsauslastung auswirkt. Wenn Sie die Azure AI Foundry Models-API verwenden, legen Sie Ihre Bereitstellungen mit einer bestimmten Version fest und stellen keine Upgraderichtlinie bereit. Für dieses Setup ist ein manuelles Upgrade erforderlich, wenn eine neue Version veröffentlicht wird. Legen Sie für Azure OpenAI Bereitstellungen auf "Kein automatisches Upgrade" fest, um automatische Upgrades zu deaktivieren.

• Stellen Sie sicher, dass Ihre Observability- und Protokollierungslösung genügend Metadaten sammelt, um das beobachtete Verhalten mit der spezifischen Eingabeaufforderung, Konfiguration, Modell und Datenabruflösung zu korrelieren. Mit dieser Korrelation können Sie unerwartete Regressionen in der Systemleistung identifizieren.

Zusammenfassung

Es gibt verschiedene Gründe, das grundlegende Modell in Ihrer generativen Workload zu aktualisieren. Diese Gründe reichen von erforderlichen Versionsupgrades, wenn Modelle eingestellt werden, bis hin zu der Entscheidung, zu einem anderen Modell zu wechseln. Je nach Umfang der Modellaktualisierung müssen Sie möglicherweise Änderungen am Modell implementieren und auswerten, einschließlich Änderungen an der Eingabeaufforderung, der Modellkonfiguration, der Orchestrierungslogik oder der Datenpipeline. Sie sollten mlOps, DataOps und GenAIOps Anleitungen befolgen, um automatisierte Workflows für die verschiedenen Aspekte Ihrer Lösung zu erstellen. Mit automatisierten Workflows können Sie neue Versionen testen, auswerten und bereitstellen. Außerdem müssen Sie sicherstellen, dass Ihre Architektur das Ausführen mehrerer Versionen eines Orchestrators unterstützt, bei dem jede Version ihre Konfiguration und die zugehörige Aufforderungsversion mit einer bestimmten Modellversion verknüpft.

Ihre Architektur sollte Updates für neue oder unterschiedliche Modelle und alle erforderlichen Änderungen an der Eingabeaufforderungs- oder Modellkonfiguration unterstützen, ohne dass Änderungen an der intelligenten Anwendung oder der Benutzeroberfläche erforderlich sind. Diese Updates sollten in ihren entsprechenden Komponenten gekapselt werden, und Ihre Vorgänge sollten die Tests, Auswertungen und Bereitstellung dieser Änderungen automatisieren.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

• Ritesh Modi | Hauptsoftwareingenieur

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächster Schritt

• Azure OpenAI Modell veraltet und Abschaffung

Verwandte Ressourcen

• Referenzarchitektur von Baseline AI Foundry Chat
• MLOps
• GenAIOps für MLOps-Praktiker