Was ist der bereitgestellte Durchsatz für Foundry Models? (klassisch)

Zurzeit wird folgendes angezeigt:Foundry (klassische) Portalversion - Wechseln zur Version für das neue Foundry-Portal

Das bereitgestellte Durchsatzangebot von Microsoft Foundry ist ein Modellbereitstellungs-Typ, mit dem Sie die Menge des benötigten Durchsatzes in einer Modellbereitstellung angeben können. Die Gießerei weist dann die erforderliche Modellverarbeitungskapazität zu und stellt sicher, dass sie für Sie bereit ist. Verwenden Sie den bereitgestellten Durchsatz, den Sie in einem vielfältigen Portfolio von models angefordert haben, die direkt von Azure verkauft werden. Zu diesen Modellen gehören Azure OpenAI-Modelle sowie neu eingeführte Flaggschiff-Modellfamilien wie Azure DeepSeek innerhalb der Foundry Models. Im Laufe der Zeit werden weitere Modellfamilien eingeführt.

Der bereitgestellte Durchsatz bietet Folgendes:

Voraussetzungen

• Ein Azure-Abonnement. Erstellen Sie eine kostenlos.
• Ein Microsoft Foundry-Projekt mit einem Modell, das mithilfe eines bereitgestellten Bereitstellungstyps für den Durchsatz implementiert wird.
• Bereitgestelltes Durchsatzkontingent, das Ihrem Abonnement in Ihrer Zielregion zugewiesen ist.
• Azure CLI (wenn Sie Bereitstellungen über die Befehlszeile erstellen möchten).

Wann man bereitgestellten Durchsatz verwendet

Erwägen Sie bereitgestellte Durchsatzbereitstellungen, wenn Sie über gut definierte, vorhersehbare Durchsatz- und Latenzanforderungen verfügen – in der Regel für Produktionsanwendungen mit bekannten Datenverkehrsmustern. Der bereitgestellte Durchsatz eignet sich auch für Echtzeit- oder Latenz-sensible Anwendungen.

Grundlegendes zur PTU-Zuweisung

Bereitgestellte Durchsatzeinheiten (PTU) und Bereitstellungstypen sind die Bausteine des bereitgestellten Durchsatzes. In den folgenden Abschnitten wird erläutert, wie sie funktionieren.

Bereitgestellte Durchsatzeinheiten (PTU)

Bereitgestellte Durchsatzeinheiten (PTU) sind generische Einheiten der Modellverarbeitungskapazität, die Sie für die Größe bereitgestellter Bereitstellungen verwenden, um den erforderlichen Durchsatz für die Verarbeitung von Eingabeaufforderungen und das Generieren von Fertigstellungen zu erzielen. Bereitgestellte Durchsatzeinheiten werden einem Abonnement als Kontingent gewährt und zum Definieren von Kosten verwendet. Jedes Kontingent ist spezifisch für eine Region und definiert die maximale Anzahl von PTU, die Bereitstellungen in diesem Abonnement und dieser Region zugewiesen werden kann.

Kostenmanagement bei gemeinsamer PTU-Reservierung

Verwenden Sie die PTU-Funktionalitäten, um die Kosten für Foundry-Modelle unter einer gemeinsamen PTU-Reservierung nahtlos zu verwalten. Die erforderlichen PTU-Einheiten für die Bereitstellung und Durchsatzleistung sind jedoch dynamisch auf die ausgewählten Modelle zugeschnitten. Weitere Informationen zu PTU-Kosten und Modelllatenzpunkten finden Sie unter "Grundlegendes zu PTU-Kosten".

Vorhandene PTU-Reservierungen werden automatisch aktualisiert, um Kunden mit verbesserter Effizienz und Kosteneinsparungen bei der Bereitstellung von Foundry Models zu unterstützen. Angenommen, Sie haben eine PTU-Reservierung mit 500 PTU gekauft. Sie verwenden 300 Einheiten für Azure OpenAI-Modelle, und Sie können PTU auch verwenden, um Azure DeepSeek, Azure Llama oder andere Modelle mit PTU-Funktion auf Foundry Models bereitzustellen.

• Wenn Sie die verbleibenden 200 PTU für DeepSeek-R1 verwenden, teilen Die 200 PTU den Reservierungsrabatt automatisch, und Ihre Gesamtnutzung für die Reservierung beträgt 500 PTU.

• Wenn Sie 300 PTU für DeepSeek-R1 verwenden, teilen 200 PTU den Reservierungsrabatt automatisch, während 100 PTU die Reservierung überschreiten und mit dem Stündsatz von DeepSeek-R1 belastet werden.

Informationen zum Sparen von Kosten mit PTU-Reservierungen finden Sie unter Kosten sparen mit Microsoft Foundry Provisioned Throughput Reservations.

Bereitstellungstypen

Wenn Sie eine bereitgestellte Bereitstellung in Foundry erstellen, kann der Bereitstellungstyp im Dialogfeld " Bereitstellung erstellen " auf den Bereitstellungstyp "Global Provisioned Throughput", "Data Zone Provisioned Throughput" oder "Regional Provisioned Throughput" festgelegt werden, je nachdem, welche Datenverarbeitungsanforderungen für die jeweilige Workload erforderlich sind.

Wenn Sie eine bereitgestellte Bereitstellung in Foundry über CLI oder API erstellen, kann sku-name auf GlobalProvisionedManaged, DataZoneProvisionedManaged oder ProvisionedManaged festgelegt werden, je nach der Datenverarbeitungsanforderung der jeweiligen Workload.

Um den folgenden Azure CLI Beispielbefehl an einen anderen Bereitstellungstyp anzupassen, aktualisieren Sie den Parameter sku-name entsprechend dem Bereitstellungstyp, den Sie bereitstellen möchten.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4o \
--model-version 2024-08-06  \
--model-format OpenAI \
--sku-capacity 15 \
--sku-name GlobalProvisionedManaged

Verwalten von Kapazität und Verfügbarkeit

Die Kapazität für den bereitgestellten Durchsatz unterliegt der regionalen Verfügbarkeit und der Echtzeitnachfrage. In den folgenden Abschnitten wird beschrieben, wie die Kapazität funktioniert und wie sie gefunden werden kann.

Kapazitätstransparenz

Die direkt von Azure verkauften Modelle sind sehr gefragte Dienste, bei denen die Kundennachfrage die Gpu-Kapazität des Diensts übersteigen kann. Microsoft ist bestrebt, Kapazitäten für alle Nachfrageregionen und Modelle bereitzustellen, aber der Verkauf einer Region ist immer eine Möglichkeit. Diese Einschränkung kann die Fähigkeit einiger Kunden einschränken, eine Bereitstellung ihres gewünschten Modells, ihrer Version oder der Anzahl von PTU in einer gewünschten Region zu erstellen – auch wenn sie Kontingente in dieser Region verfügbar haben.

Generell:

• Das Kontingent garantiert keine Kapazität. Das Kontingent beschränkt die maximale Anzahl von PTUs, die in einem Abonnement und einer Region bereitgestellt werden können.
• Die Kapazität wird zur Bereitstellungszeit zugeteilt und wird solange gehalten, wie die Bereitstellung vorhanden ist. Wenn die Dienstkapazität nicht verfügbar ist, schlägt die Bereitstellung fehl.
• Verwenden Sie Echtzeitinformationen zu Kontingent- und Kapazitätsverfügbarkeit, um eine geeignete Region für Ihr Szenario auszuwählen.
• Das Herunterskalieren oder Löschen einer Bereitstellung gibt die Kapazität zurück in die Region zurück. Es gibt keine Garantie dafür, dass die Kapazität verfügbar ist, wenn die Bereitstellung später skaliert oder neu erstellt wird.

Regionale Kapazitätsrichtlinien

Um die erforderliche Kapazität für ihre Bereitstellungen zu finden, verwenden Sie die Kapazitäts-API oder die Foundry-Bereitstellungsumgebung, um Echtzeitinformationen zur Kapazitätsverfügbarkeit bereitzustellen.

In Foundry identifiziert das Bereitstellungserlebnis, wann eine Region nicht genügend Kapazität zum Bereitstellen des Modells hat. Dies untersucht das gewünschte Modell, die Version und die Anzahl der PTU. Wenn die Kapazität nicht verfügbar ist, leitet die Benutzeroberfläche Die Benutzer an, eine alternative Region auszuwählen.

Details zur Bereitstellungserfahrung finden Sie im Foundry Provisioned Leitfaden für die ersten Schritte.

Verwenden Sie die Modellkapazitäts-API , um die maximale Größe der Bereitstellung eines angegebenen Modells programmgesteuert zu identifizieren. Die API berücksichtigt sowohl Ihre Kontingent- als auch Die Dienstkapazität in der Region.

Wenn eine akzeptable Region nicht verfügbar ist, um das gewünschte Modell, die gewünschte Version und/oder PTU zu unterstützen, können Kunden auch die folgenden Schritte ausprobieren:

• Versuchen Sie die Bereitstellung mit einer kleineren Anzahl von PTUs.
• Versuchen Sie die Bereitstellung zu einem anderen Zeitpunkt. Die Kapazitätsverfügbarkeit ändert sich dynamisch basierend auf Kundennachfrage, und später werden möglicherweise mehr Kapazitäten verfügbar.
• Stellen Sie sicher, dass das Kontingent in allen zulässigen Regionen verfügbar ist. Die Modellkapazitäts-API und die Foundry-Erfahrung berücksichtigen die Kontingentverfügbarkeit bei der Rückgabe alternativer Regionen für die Erstellung einer Bereitstellung.

Überwachen der Auslastung und Leistung

In den folgenden Abschnitten wird erläutert, wie Die Auslastung überwacht und Kapazitätsgrenzwerte behandelt werden.

Überwachen der Kapazität

Die Metrik Provisioned-Managed Utilization V2 misst in Azure Monitor eine bestimmte Bereitstellungsauslastung in 1-Minuten-Schritten. Alle bereitgestellten Bereitstellungstypen sind optimiert, um sicherzustellen, dass akzeptierte Anrufe mit einer konsistenten Modellverarbeitungszeit verarbeitet werden (die tatsächliche End-to-End-Latenz hängt von den Merkmalen eines Anrufs ab).

Auslastungsleistung

Bereitgestellte Implementierungen bieten Ihnen eine zugeordnete Menge an Modellverarbeitungskapazität, um ein bestimmtes Modell auszuführen.

Wenn die Kapazität überschritten wird, gibt die API in allen bereitgestellten Bereitstellungstypen einen HTTP-Statusfehler vom Typ 429 zurück. Die schnelle Antwort ermöglicht es dem Benutzer, Entscheidungen darüber zu treffen, wie er seinen Datenverkehr verwalten kann. Benutzer können Anforderungen an eine separate Bereitstellung, an eine Standardbereitstellungsinstanz umleiten oder eine Wiederholungsstrategie zum Verwalten einer bestimmten Anforderung verwenden. Der Dienst gibt weiterhin den 429 HTTP-Statuscode zurück, bis die Auslastung unter 100%fällt.

Behandeln von HTTP 429-Antworten

Die 429-Antwort ist kein Fehler, sondern teil des Entwurfs, um Benutzern mitzuteilen, dass eine bestimmte Bereitstellung zu einem bestimmten Zeitpunkt vollständig genutzt wird. Durch die Bereitstellung einer schnellen Fail-Antwort haben Sie die Kontrolle darüber, wie diese Situationen so behandelt werden können, dass sie ihren Anwendungsanforderungen am besten entsprechen.

Die Header retry-after-ms und retry-after in der Antwort informieren Sie darüber, wie lange Sie warten müssen, bis die nächste Anfrage akzeptiert wird. Wie Sie sich entscheiden, diese Antwort zu behandeln, hängt von den Anforderungen Ihrer Anwendung ab. Hier sind einige Überlegungen:

• Erwägen Sie, den Datenverkehr auf andere Modelle, Bereitstellungen oder Erfahrungen umzuleiten. Diese Option ist die Lösung mit der niedrigsten Latenz, da die Aktion ausgeführt werden kann, sobald Sie das 429-Signal erhalten. Ideen zur effektiven Implementierung dieses Musters finden Sie in diesem community post.
• Wenn Sie mit längeren Wartezeiten pro Anruf in Ordnung sind, implementieren Sie clientseitige Wiederholungslogik. Mit dieser Option erhalten Sie den höchsten Durchsatz pro PTU. Die Foundry-Clientbibliotheken enthalten integrierte Funktionen zur Handhabung von Wiederholversuchen.

Nutzungsbasierte Anforderungsauswertung

In allen bereitgestellten Bereitstellungstypen wird jede Anforderung einzeln entsprechend ihrer Eingabeaufforderungsgröße, der erwarteten Generation und dem Modell ausgewertet, um die erwartete Auslastung zu bestimmen. Dieses Verhalten steht im Gegensatz zu Standard-Deployments, die ein benutzerdefiniertes Rate-Limitierungsverhalten basierend auf der geschätzten Verkehrslast aufweisen. Bei Standardbereitstellungen kann dieses Verhalten für benutzerdefinierte Ratenbeschränkungen zu HTTP-429-Fehlern führen, bevor definierte Kontingentwerte überschritten werden, wenn der Datenverkehr nicht gleichmäßig verteilt wird.

Bei den Bereitstellungen wird eine Variation des Leaky-Bucket-Algorithmus verwendet, um die Auslastung unter 100 % zu halten und gleichzeitig Bursts bei Datenverkehr zuzulassen. Die allgemeine Logik lautet wie folgt:

1. Jeder Kunde verfügt über eine festgelegte Kapazität, die er für eine Bereitstellung verwenden kann.

2. Wenn eine Anforderung gestellt wird:

   a. Sobald die aktuelle Auslastung über 100 % liegt, gibt der Dienst einen 429-Code zurück, wobei der retry-after-ms-Header auf die Zeit eingestellt ist, bis die Auslastung unter 100 % fällt.

   B. Andernfalls schätzt der Dienst die inkrementelle Änderung der Auslastung, die zum Verarbeiten der Anforderung benötigt wird, indem die Prompttoken abzüglich etwaiger zwischengespeicherter Token und des für max_tokens angegebenen Werts im Aufruf kombiniert werden. Ein Kunde kann, abhängig von der Größe ihrer zwischengespeicherten Token, einen Rabatt von bis zu 100 % auf ihre Prompt-Token erhalten. Wenn der max_tokens Parameter nicht angegeben ist, schätzt der Dienst einen Wert. Diese Schätzung kann zu einer geringeren Parallelität führen als erwartet, wenn die Anzahl der tatsächlich generierten Token klein ist. Stellen Sie für die höchste Parallelität sicher, dass der max_tokens-Wert der tatsächlichen Generierungsgröße so nah wie möglich ist.

3. Wenn eine Anforderung abgeschlossen ist, wissen wir jetzt die tatsächlichen Berechnungskosten für den Anruf. Um eine genaue Buchhaltung sicherzustellen, korrigieren wir die Auslastung mithilfe der folgenden Logik:

   a. Wenn die tatsächlichen Kosten höher (>) als die geschätzten sind, wird die Differenz auf den Verbrauch der Bereitstellung angerechnet.

   B. Wenn die tatsächlichen Kosten niedriger geschätzt werden (<), wird die Differenz abgezogen.

4. Die Gesamtauslastung wird basierend auf der Anzahl der bereitgestellten PTUs um eine fortlaufende Rate verringert.

Grenzwerte für gleichzeitige Anrufe

Die Anzahl der gleichzeitigen Anrufe, die Sie für eine Bereitstellung erreichen können, hängt von der Struktur jedes Anrufs ab (Promptgröße, max_tokens-Parameter und ähnliche Faktoren). Der Dienst akzeptiert weiterhin Anrufe, bis die Auslastung 100%erreicht. Um die ungefähre Anzahl gleichzeitiger Anrufe zu ermitteln, können Sie die maximalen Anforderungen pro Minute für ein bestimmtes Anruf-Shape im Kapazitätsrechner modellieren. Wenn das System weniger als die Anzahl der ausgabetoken generiert, die für den max_tokens Parameter festgelegt wurden, akzeptiert die bereitgestellte Bereitstellung mehr Anforderungen.

Bereitgestellte Durchsatzfunktion für Modelle, die direkt von Azure verkauft werden

In diesem Abschnitt werden Foundry Models aufgeführt, die die bereitgestellte Durchsatzkapazität unterstützen. Verwenden Sie Ihr PTU-Kontingent und Ihre PTU-Reservierung in den Modellen, die in der Tabelle angezeigt werden.

• Die Modellversion ist in dieser Tabelle nicht enthalten. Überprüfen Sie die unterstützte Version für jedes Modell, wenn Sie die Bereitstellungsoption im Foundry-Portal auswählen.

• Regionale Bereitstellungsoptionen für den Durchsatz variieren je nach Region.

• Neue Modelle, die direkt von Azure verkauft werden, werden zuerst mit der Bereitstellungsoption Globaler bereitgestellter Durchsatz eingegliedert. Die bereitgestellte Option der Datenzone wird zu einem späteren Zeitpunkt eingerichtet.

• PTUs werden regional und nach Angebotstyp verwaltet. PTU-Kontingent und alle Reservierungen müssen sich in der Region und im Format (Global, Data Zone, Regional) befinden, das Sie verwenden möchten.

• Spillover ist eine optionale Funktion, die Datenverkehrsschwankungen bei bereitgestellten Systemen verwaltet. Weitere Informationen zu Spillover finden Sie unter Verwalten von Datenverkehr mit Spillover für bereitgestellte Implementierungen.

Regionale Verfügbarkeit für bereitgestellte Durchsatzkapazität

Verwandte Inhalte

• Informationen zu den Onboarding-Schritten für bereitgestellte Einsätze
• Leitfaden für die ersten Schritte mit bereitgestellten Durchsatzeinheiten (PTU)
• Verständnis von Bereitstellungstypen
• Verwalten von Datenverkehr mit Überlauf für bereitgestellte Bereitstellungen
• Überwachen Azure OpenAI-Modelle
• Verwalten Sie das Kontingent für Azure OpenAI
• Kosten sparen mit Microsoft Foundry Provisioned Throughput Reservations