Was ist bereitgestellter Durchsatz?

Das Von Microsoft Foundry bereitgestellte Durchsatzangebot ist ein Modellbereitstellungstyp, mit dem Sie den in einer Modellbereitstellung benötigten Durchsatz angeben können. Die Gießerei weist dann die erforderliche Modellverarbeitungskapazität zu und stellt sicher, dass sie für Sie bereit ist. Sie können den bereitgestellten Durchsatz verwenden, den Sie in einem vielfältigen Portfolio von Modellen angefordert haben , die direkt von Azure verkauft werden. Zu diesen Modellen gehören Azure OpenAI-Modelle und neu eingeführte Modellfamilien wie Azure DeepSeek, Azure Grok, Azure Llama und mehr in Foundry Models.

Der bereitgestellte Durchsatz bietet Folgendes:

• Eine größere Modellauswahl für die neuesten Flagship-Modelle
• Flexibilität beim Wechseln von Modellen und Bereitstellungen mit einem bestimmten bereitgestellten Durchsatzkontingent
• Erhebliche Rabatte und die Möglichkeit, Ihre Reservierungsnutzung mit einer flexibleren Reservierungsauswahl zu steigern
• Vorhersehbare Leistung, indem eine stabile maximale Latenz und ein Durchsatz für einheitliche Workloads bereitgestellt werden.
• Zugeordnete Verarbeitungskapazität: Eine Bereitstellung konfiguriert die Durchsatzmenge. Nach der Bereitstellung ist der Durchsatz verfügbar, unabhängig davon, ob er verwendet wird.
• Kosteneinsparungen: Workloads mit hohem Durchsatz bieten im Vergleich zur tokenbasierten Nutzung möglicherweise Kosteneinsparungen.

Wann man den bereitgestellten Durchsatz verwenden sollte

Sie sollten in Erwägung ziehen, von Standardbereitstellungen zu bereitstellungsfähigen Durchsatzbereitstellungen zu wechseln, wenn Sie über gut definierte, vorhersehbare Durchsatz- und Latenzanforderungen verfügen. In der Regel tritt dies auf, wenn die Anwendung für die Produktion bereit ist oder bereits in der Produktion bereitgestellt wird, und es gibt ein Verständnis des erwarteten Datenverkehrs. Auf diese Weise können Benutzer die erforderliche Kapazität genau prognostizieren und unerwartete Abrechnungen vermeiden. Der bereitgestellte Durchsatz ist auch für Anwendungen mit sensiblen Anforderungen hinsichtlich Echtzeit oder Latenz nützlich.

Wichtige Begriffe

In den folgenden Abschnitten werden die wichtigsten Konzepte beschrieben, die Sie bei Verwendung des bereitgestellten Durchsatzangebots beachten sollten.

Bereitgestellte Durchsatzeinheiten (PTU)

Bereitgestellte Durchsatzeinheiten (Provisioned Throughput Units, PTUs) sind generische Einheiten der Modellverarbeitungskapazität, mit denen Sie die Größe bereitgestellter Bereitstellungen anpassen können, um den erforderlichen Durchsatz für die Verarbeitung von Prompts 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.

Cost Management bei gemeinsam genutzter PTU-Reservierung

Sie können die PTU-Funktion verwenden, um die Kosten für Foundry-Modelle unter einer gemeinsam genutzten 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-Modellen 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 Einsparen von Kosten mit Microsoft Foundry-Reservierungen für bereitgestellten Durchsatz.

Bereitstellungstypen

Wenn Sie eine bereitgestellte Bereitstellung in Foundry erstellen, kann der Bereitstellungstyp im Dialogfeld "Bereitstellung erstellen" auf den globalen Bereitgestellten Durchsatz, den bereitgestellten Datenzonendurchsatz oder den Bereitstellungstyp für den regionalen bereitgestellten Durchsatz festgelegt werden, abhängig von den Anforderungen der Datenverarbeitung für die angegebene Workload.

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

Um den folgenden Azure CLI-Beispielbefehl an einen anderen Bereitstellungstyp anzupassen, aktualisieren Sie den sku-name Parameter 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

Kapazitätstransparenz

Die direkt von Azure verkauften Modelle sind sehr gefragte Dienste, bei denen die Kundennachfrage die Gpu-Kapazität des Diensts überschreitet. Microsoft ist bestrebt, Kapazitäten für alle nachgefragten Regionen und Modelle bereitzustellen, aber der Ausverkauf in 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 Kontingent in dieser Region verfügbar haben. Generell gilt:

• Das Kontingent beschränkt die maximale Anzahl von PTU, die in einem Abonnement und einer Region bereitgestellt werden kann, und garantiert nicht die Verfügbarkeit der Kapazität.
• 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.
• Kunden verwenden Echtzeitinformationen zur Verfügbarkeit von Kontingenten/Kapazitäten, um eine geeignete Region für ihr Szenario mit der erforderlichen Modellkapazität auszuwählen.
• Durch das Herunterskalieren oder Löschen einer Bereitstellung wird die Kapazität in die Region wieder freigegeben. Es gibt keine Garantie dafür, dass die Kapazität verfügbar ist, wenn die Bereitstellung später skaliert oder neu erstellt wird.

Leitfaden für regionale Kapazität

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 die Bereitstellungserfahrung, wann eine Region nicht über die erforderliche Kapazität zum Bereitstellen des Modells verfügt. 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 Leitfaden für die ersten Schritte in „Foundry Provisioned“.

Die Modellkapazitäts-API kann verwendet werden, um die maximale Größe der Bereitstellung eines angegebenen Modells programmgesteuert zu identifizieren. Die API berücksichtigt sowohl das 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 mehr Kapazität kann später verfügbar werden.
• Stellen Sie sicher, dass das Kontingent in allen akzeptablen 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.

Wie kann ich die Kapazität überwachen?

Die Metrik Provision-managed Utilization V2 in Azure Monitor misst im Minutentakt die Auslastung einer bestimmten Bereitstellung. Alle Bereitstellungstypen sind so optimiert, dass sie die Verarbeitung akzeptierter Aufrufe mit einer konsistenten Modellverarbeitungszeit sicherstellen, wobei die tatsächliche End-to-End-Wartezeit von den Merkmalen eines Aufrufs abhängt.

Funktionsweise der Verwendungsleistung

Bereitgestellte Bereitstellungen bieten Ihnen eine zugewiesene 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 oder an eine Standardbereitstellungsinstanz umleiten oder eine Wiederholungsstrategie nutzen, um eine bestimmte Anforderung zu verwalten. Der Dienst gibt weiterhin den HTTP-Statuscode vom Typ „429“ zurück, bis die Auslastung unter 100 Prozent fällt.

Was sollte ich tun, wenn ich eine 429-Antwort erhalte?

Die 429-Antwort ist kein Fehler, sondern ist Teil des Entwurfs, um Benutzern mitzuteilen, dass eine bestimmte Bereitstellung zu einem bestimmten Zeitpunkt vollständig genutzt wird. Durch die Bereitstellung einer Fast-Fail-Antwort können Sie bestimmen, wie mit diesen Situationen umgegangen werden soll, um Ihren Anwendungsanforderungen zu entsprechen.

Die Header retry-after-ms und retry-after in der Antwort geben die Wartezeit bis zur Annahme des nächsten Aufrufs an. Wie Sie mit dieser Antwort umgehen, hängt von Ihren Anwendungsanforderungen ab. Hier sind einige Überlegungen:

• Sie können erwägen, den Datenverkehr auf andere Modelle, Bereitstellungen oder Erfahrungen umzuleiten. Diese Lösung bietet die kürzeste Wartezeit, da die Aktion ausgeführt werden kann, sobald Sie das 429-Signal erhalten. Anregungen zur effektiven Implementierung dieses Musters finden Sie in diesem Communitybeitrag.
• Wenn längere Wartezeiten pro Aufruf Ihren Vorstellungen entsprechen, implementieren Sie eine clientseitige Wiederholungslogik. Mit dieser Option erhalten Sie den höchsten Durchsatz pro PTU. Die Foundry-Clientbibliotheken enthalten integrierte Funktionen für die Behandlung von erneuten Versuchen.

Wie entscheidet der Dienst, wann eine 429-Antwort gesendet werden soll?

In allen bereitgestellten Bereitstellungstypen wird jede Anforderung einzeln anhand ihrer Eingabeaufforderungsgröße, der erwarteten Generation und des Modells ausgewertet, um die erwartete Auslastung zu ermitteln. Dieses Verhalten steht im Gegensatz zu Standardbereitstellungen, die ein benutzerdefiniertes Rate-Limit-Verhalten aufweisen, das auf der geschätzten Datenverkehrslast basiert. Bei Standardbereitstellungen kann dieses benutzerdefinierte Ratenbegrenzungsverhalten zu HTTP 429-Fehlern führen, die auftreten, 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 folgendermaßen:

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

2. Wenn eine Anforderung gestellt wird, passiert Folgendes:

   a) Wenn die aktuelle Auslastung über 100 % liegt, gibt der Dienst einen 429-Code zurück, wobei der retry-after-ms-Header auf die Zeit festgelegt ist, bis die Auslastung unter 100 % liegt.

   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 je nach Größe der zwischengespeicherten Token bis zu 100 % Rabatt auf seine Prompttoken erhalten. Wenn der max_tokens Parameter nicht angegeben ist, schätzt der Dienst einen Wert. Diese Schätzung kann zu einer tieferen 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. Nach dem Abschluss einer Anforderung sind die tatsächlichen Computekosten für den Aufruf bekannt. Um eine genaue Berechnung zu gewährleisten, wird die Auslastung mithilfe der folgenden Logik korrigiert:

   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 mit einer konstanten Rate basierend auf der Anzahl der bereitgestellten PTUs verringert.

Wie viele gleichzeitige Aufrufe kann ich in meiner Bereitstellung haben?

Die erreichbare Anzahl gleichzeitiger Aufrufe hängt von der Form des jeweiligen Aufrufs ab (Promptgröße, Parameter max_tokens usw.). Der Dienst akzeptiert weiterhin Aufrufe, bis die Auslastung 100 % erreicht. Um die ungefähre Anzahl gleichzeitiger Aufrufe zu bestimmen, können Sie die maximalen Anforderungen pro Minute für eine bestimmte Aufrufform im Kapazitätsrechner modellieren. Wenn das System weniger Ausgabetoken als die für den Parameter max_tokens festgelegte Anzahl generiert, akzeptiert die Bereitstellung weitere Anforderungen.

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

In diesem Abschnitt werden Foundry Models aufgeführt, die die bereitgestellte Durchsatzleistung unterstützen. Sie können Ihr PTU-Kontingent und ihre PTU-Reservierung in den in der Tabelle angezeigten Modellen verwenden.

Die folgenden Punkte sind einige wichtige Punkte aus der Tabelle:

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

• Die Bereitstellungsoption für den regionalen Durchsatz variiert je nach Region.

• Neue Modelle, die direkt von Azure verkauft werden, werden zuerst mit der Bereitstellungsoption für den globalen Durchsatz eingeführt. Die Option für die Datenzone wird zu einem späteren Zeitpunkt bereitgestellt.

• PTU werden regional und nach Angebotstyp verwaltet. Das PTU-Kontingent und alle Reservierungen müssen sich in der gewünschten Region und Form (Global, Datenzone, Regional) befinden, die Sie verwenden möchten.

• Der Überlauf ist eine optionale Funktion, die Schwankungen im Datenverkehr für bereitgestellte Bereitstellungen verwaltet. Weitere Informationen zum Überlauf finden Sie unter Verwalten von Datenverkehr mit Überlauf für bereitgestellte Bereitstellungen.

Regionsverfügbarkeit der bereitgestellten Durchsatzkapazität

Verwandte Inhalte

• Weitere Informationen zu den Onboardingschritten für bereitgestellte Bereitstellungen
• Leitfaden zu den ersten Schritten mit bereitgestellten Durchsatzeinheiten (PTUs)