Was ist bereitgestellter Durchsatz?
Hinweis
Das Angebot „Azure OpenAI Provisioned“ erhielt am 12. August 2024 erhebliche Updates, einschließlich der Anpassung des Kaufmodells an Azure-Standards und die Umstellung auf modellunabhängige Kontingente. Es wird dringend empfohlen, dass Kunden, die vor diesem Datum eingebunden wurden, das „Azure OpenAI Bereitgestellt“-Update vom August lesen, um mehr über diese Änderungen zu erfahren.
Mithilfe der Funktionalität „Bereitgestellter Durchsatz“ können Sie den in einer Bereitstellung erforderlichen Durchsatz angeben. Der Dienst weist daraufhin die erforderliche Modellverarbeitungskapazität zu und stellt sicher, dass diese für Sie bereit ist. Der Durchsatz wird als bereitgestellte Durchsatzeinheiten (Provisioned Throughput Units, PTUs) definiert. Dabei handelt es sich um eine normalisierte Methode zur Darstellung des Durchsatzes für Ihre Bereitstellung. Jedes Modellversionspaar benötigt unterschiedliche PTU-Mengen, um unterschiedliche Durchsatzmengen pro PTU bereitzustellen.
Was bieten die Typen „Bereitgestellter Durchsatz“?
- Vorhersagbare Leistung: stabile maximale Wartezeit und stabilen maximalen Durchsatz für einheitliche Workloads.
- Reservierte 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.
Eine Azure OpenAI-Bereitstellung ist eine Verwaltungseinheit für ein bestimmtes OpenAI-Modell. Eine Bereitstellung bietet Kunden den Zugriff auf ein Modell zum Rückschluss und integriert weitere Features wie die Inhaltsmoderation (Informationen finden Sie in der Dokumentation zur Inhaltsmoderation). Globale Bereitstellungen stehen in denselben Azure OpenAI-Ressourcen zur Verfügung wie alle anderen Bereitstellungstypen, ermöglichen Ihnen jedoch, die globale Infrastruktur von Azure zu nutzen, um den Datenverkehr dynamisch an das Rechenzentrum mit der besten Verfügbarkeit für jede Anforderung weiterzuleiten. Ebenso sind Bereitstellungen in Datenzonen in derselben Ressourcen wie alle anderen Bereitstellungstypen verfügbar, ermöglichen Ihnen jedoch, die globale Azure-Infrastruktur zu nutzen, um Datenverkehr dynamisch an das Rechenzentrum innerhalb der von Microsoft definierten Datenzone mit der besten Verfügbarkeit für jede Anforderung weiterzuleiten.
Was erhalten Sie?
Thema | Bereitgestellt |
---|---|
Was ist das? | Bietet einen garantierten Durchsatz in kleineren Schritten als das bestehende bereitgestellte Angebot. Bereitstellungen verfügen über eine konsistente maximale Wartezeit für eine bestimmte Modellversion. |
Für wen ist das gedacht? | Kunden, die den garantierten Durchsatz mit minimalen Abweichungen hinsichtlich der Wartezeit wünschen. |
Kontingent | Bereitgestellte verwaltete Durchsatzeinheit, globale bereitgestellte verwaltete Durchsatzeinheit oder in einer Datenzone bereitgestellte verwaltete Durchsatzeinheit pro Region zugewiesen. Das Kontingent kann für jedes verfügbare Azure OpenAI-Modell verwendet werden. |
Latency | Die maximale durch das Modell eingeschränkte Wartezeit Die Gesamtwartezeit bestimmt unter anderem die Form des Aufrufs. |
Nutzung | In Azure Monitor bereitgestelltes Measure „Provisioned-Managed Utilization V2“. |
Größenschätzung | Bereitgestellter Rechner in Azure KI Foundry und Benchmarkingskript |
Promptzwischenspeicherung | Bei unterstützten Modellen wird ein Rabatt von bis zu 100 % für zwischengespeicherte Eingabetoken gewährt. |
Durchsatz pro PTU für jedes Modell
Der Durchsatz (Token pro Minute oder TPM), den eine Bereitstellung pro PTU erhält, ist eine Funktion der Eingabe- und Ausgabetoken in der Minute. Das Generieren von Ausgabetoken erfordert mehr Verarbeitung als Eingabetoken. Daher gilt: Je mehr Ausgabetoken generiert werden, desto niedriger ist der gesamte TPM-Wert. Der Dienst gleicht die Eingabe- und Ausgabekosten dynamisch aus, sodass Benutzer keine spezifischen Eingabe- und Ausgabegrenzwerte festlegen müssen. Dieser Ansatz bedeutet, dass Ihre Bereitstellung resilient gegenüber Schwankungen der Workload ist.
Um die Dimensionierung zu vereinfachen, finden Sie in der folgenden Tabelle die TPM pro PTU für die Modelle gpt-4o
und gpt-4o-mini
, die den maximalen TPM darstellen, vorausgesetzt, dass der gesamte Datenverkehr eingehend oder ausgehend ist. Informationen dazu, wie sich unterschiedliche Verhältnisse von Eingabe- und Ausgabetoken auf Ihr Max TPM pro PTU auswirken, finden Sie im Azure OpenAI-Kapazitätsrechner. Die Tabelle zeigt auch die SLA-Latenz-Zielwerte pro Modell. Weitere Informationen über die SLA für Azure OpenAI Service finden Sie auf der Seite Service Level Agreements (SLA) für Online-Dienste
Thema | gpt-4o, 2024-05-13 & gpt-4o, 2024-08-06 | gpt-4o-mini, 2024-07-18 |
---|---|---|
Globale und in einer Datenzone bereitgestellte Mindestbereitstellung | 15 | 15 |
Globale und in einer Datenzone bereitgestellte Skalierungsschritte | 5 | 5 |
Regionale bereitgestellte Mindestbereitstellung | 50 | 25 |
Regionale bereitgestellte Skalierungsschritte | 50 | 25 |
Max Eingabe-TPM pro PTU | 2\.500 | 37.000 |
Max Ausgabe-TPM pro PTU | 833 | 12.333 |
Latenz-Zielwert | 25 Token pro Sekunde | 33 Token pro Sekunde |
Eine vollständige Liste finden Sie im AOAI Foundry-Rechner.
Hinweis
Global bereitgestellte Installationen werden derzeit nur für die Modelle gpt-4o, 2024-08-06 und gpt-4o-mini, 2024-07-18 unterstützt. Bereitstellungen in einer Datenzone werden derzeit nur für die Modelle gpt-4o, 2024-08-06, gpt-4o, 2024-05-13, und gpt-4o-mini, 2024-07-18 unterstützt. Weitere Informationen zur Modellverfügbarkeit erfahren Sie in der Modelldokumentation.
Wichtige Begriffe
Bereitstellungstypen
Beim Erstellen einer Bereitstellung in Azure KI Foundry kann der Bereitstellungstyp je nach den Datenverarbeitungsanforderungen für die jeweilige Workload im Dialogfeld „Bereitstellung erstellen“ auf den Typ „Global bereitgestellt-verwaltet“, „In Datenzone bereitgestellt-verwaltet“ oder „Regional bereitgestellt-verwaltet“ festgelegt werden.
Beim Erstellen einer Bereitstellung in Azure OpenAI über die Befehlszeilenschnittstelle oder die API kann sku-name
abhängig von den Datenverarbeitungsanforderungen für die jeweilige Workload auf GlobalProvisionedManaged
, DataZoneProvisionedManaged
oder ProvisionedManaged
festgelegt werden. Um den folgenden Azure CLI-Beispielbefehl an einen anderen Bereitstellungstyp anzupassen, aktualisieren Sie einfach den sku-name
-Parameter entsprechend dem gewünschten Bereitstellungstyp.
az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4 \
--model-version 0613 \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged
Kontingent
Bereitgestellte Durchsatzeinheiten
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 zugewiesen. Jedes Kontingent ist spezifisch für eine Region und definiert die maximale Anzahl von PTUs, die Bereitstellungen in diesem Abonnement und dieser Region zugewiesen werden können.
Modellunabhängiges Kontingent
Im Gegensatz zum Kontingent „Token pro Minute“ (TPM), das von anderen Azure OpenAI-Angeboten verwendet wird, sind PTUs modellunabhängig. Die PTUs können verwendet werden, um beliebige unterstützten Modelle/Versionen in der Region bereitzustellen.
Das neue Kontingent wird für Bereitstellungen in Azure KI Foundry als Kontingentelement mit dem Namen Bereitgestellte verwaltete Durchsatzeinheit angezeigt. Das neue Kontingent wird für Bereitstellungen in Azure KI Foundry als Kontingentelement namens Global bereitgestellte verwaltete Durchsatzeinheit angezeigt. Für Bereitstellungen in einer Datenzone wird das neue Kontingent in Azure KI Foundry als Kontingentelement namens In Datenzone bereitgestellte verwaltete Durchsatzeinheit angezeigt. Im Bereich „Foundry-Kontingent“ werden durch Erweitern des Kontingentelements die Bereitstellungen angezeigt, die zum Verbrauch jedes Kontingents beitragen.
Abrufen von PTU-Kontingent
Das PTU-Kontingent ist standardmäßig in vielen Regionen verfügbar. Wenn mehr Kontingent erforderlich ist, können Kunden ein Kontingent über den Link „Kontingent anfordern“ anfordern. Dieser Link befindet sich rechts neben der Registerkarte des Kontingents des jeweiligen Bereitstellungstyps in Azure KI Foundry. Das Formular ermöglicht Kunden, eine Erhöhung des angegebenen PTU-Kontingents für eine bestimmte Region anzufordern. Der Kunde erhält eine E-Mail an die eingefügte Adresse, sobald die Anforderung genehmigt ist, in der Regel innerhalb von zwei Werktagen.
PTU-Mindestwerte pro Modell
Die minimalen Werte für PTU-Bereitstellung, Inkremente und Verarbeitungskapazität, die jeder Einheit zugeordnet sind, variieren je nach Modelltyp und Version.
Kapazitätstransparenz
Azure OpenAI ist ein sehr gefragter Dienst, bei dem die Kundennachfrage möglicherweise 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 Möglichkeiten einiger Kunden begrenzen, eine Bereitstellung des gewünschten Modells, der gewünschten Version oder der gewünschten Anzahl von PTUs in einer gewünschten Region zu erstellen – selbst wenn sie in dieser Region über ein Kontingent verfügen. Ganz allgemein gesprochen:
- Das Kontingent begrenzt die maximale Anzahl von PTUs, die in einem Abonnement und einer Region bereitgestellt werden können, und ist keine Garantie für 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 zu wä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 sein wird, wenn die Bereitstellung später aufskaliert oder neu erstellt wird.
Leitfaden für regionale Kapazität
Um die erforderliche Kapazität für die Bereitstellungen zu ermitteln, verwenden Sie die Kapazitäts-API oder die Bereitstellungsumgebung von KI Foundry, um Echtzeitinformationen zur Kapazitätsverfügbarkeit bereitzustellen.
In Azure KI Foundry ist auf der Bereitstellungsoberfläche angegeben, wenn eine Region nicht die zum Bereitstellen des Modells erforderliche Kapazität bietet. Dabei werden das gewünschte Modell, die Version und die Anzahl der PTUs untersucht. Wenn keine Kapazität verfügbar ist, werden die Benutzenden umgeleitet, um eine alternative Region auszuwählen.
Details zur neuen Bereitstellungserfahrung finden Sie im Leitfaden für die ersten Schritte in „Azure OpenAI Provisioned“.
Die neue 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 Version und/oder die PTUs 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 API für Modellkapazität und die Benutzeroberfläche von KI Foundry berücksichtigen die Verfügbarkeit von Kontingenten bei der Rückgabe alternativer Regionen für die Erstellung einer Bereitstellung.
Ermitteln der Anzahl der für eine Workload erforderlichen PTUs
PTUs stellen eine Modellverarbeitungskapazität dar. Ähnlich wie auf Ihrem Computer oder in Datenbanken verbrauchen verschiedene Workloads oder Anforderungen an das Modell unterschiedliche Mengen der zugrunde liegenden Verarbeitungskapazität. Die Konvertierung von Aufrufformmerkmalen (Promptgröße, Generierungsgröße und Aufrufrate) in PTUs ist komplex und nicht linear. Um diesen Vorgang zu vereinfachen, können Sie den Azure OpenAI-Kapazitätsrechner verwenden, um die Größe bestimmter Workloadformen zu ermitteln.
Einige allgemeine Überlegungen:
- Generierungen erfordern mehr Kapazität als Prompts.
- Bei GPT-4o und höheren Modellen wird der TPM-Wert pro PTU separat für Eingabe- und Ausgabetoken festgelegt. Bei älteren Modellen ist die Berechnung größerer Aufrufe progressiv teurer. Beispielsweise erfordern 100 Aufrufe mit einer Promptgröße von 1000 Tokens weniger Kapazität als ein Aufruf mit 100 000 Tokens im Prompt. Dieses Tiering bedeutet, dass die Verteilung dieser Aufrufformen im Gesamtdurchsatz wichtig ist. Bei Datenverkehrsmustern mit einer breiten Verteilung, die einige große Aufrufe enthält, kann der Durchsatz pro PTU geringer sein als bei einer engeren Verteilung mit der gleichen durchschnittlichen Größe von Prompts und Vervollständigungstoken.
Funktionsweise der Verwendungsleistung
Bereitgestellte Bereitstellungen bieten Ihnen eine zugewiesene Modellverarbeitungskapazität, um ein bestimmtes Modell auszuführen.
Bei allen Bereitstellungstypen gilt: Wenn die Kapazität überschritten wird, gibt die API einen Fehler mit dem HTTP-Status 429 zurück. Durch diese schnelle Reaktion können Benutzer entscheiden, wie der Datenverkehr verwaltet werden soll. Benutzer können Anforderungen an eine separate Bereitstellung oder an eine Standardinstanz mit nutzungsbasierter Bezahlung 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.
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.
Was sollte ich tun, wenn ich eine 429-Antwort erhalte?
Die 429-Antwort ist kein Fehler, sondern soll als Teil des Entwurfs Benutzer*innen darüber informieren, dass eine bestimmte Bereitstellung zu einem bestimmten Zeitpunkt vollständig ausgelastet ist. 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 einige Überlegungen dazu:
- 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 Azure OpenAI-Clientbibliotheken enthalten integrierte Funktionen für die Behandlung von Wiederholungen.
Wie entscheidet der Dienst, wann eine 429-Antwort gesendet werden soll?
Bei allen Bereitstellungstypen wird jede Anforderung einzeln entsprechend ihrer Promptgröße, ihrer erwarteten Generationsgröße und ihres Modells ausgewertet, um die erwartete Auslastung zu bestimmen. Bei Bereitstellungen mit nutzungsbasierter Bezahlung ist das anders: Hier wird ein benutzerdefiniertes Ratenbegrenzungsverhalten verwendet, das auf der geschätzten Datenverkehrslast basiert. Be Bereitstellungen mit nutzungsbasierter Bezahlung kann dies dazu führen, dass HTTP 429-Fehler generiert werden, bevor die festgelegten Quotenwerte überschritten werden, wenn der Datenverkehr nicht gleichmäßig verteilt ist.
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:
Jeder Kunde verfügt über eine festgelegte Kapazität, die er für eine Bereitstellung nutzen kann.
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 Prompttoken und die angegebenen
max_tokens
im Aufruf kombiniert werden. Bei Anforderungen, die mindestens 1.024 zwischengespeicherte Token enthalten, werden die zwischengespeicherten Token vom Prompttokenwert subtrahiert. Ein Kunde kann je nach Größe der zwischengespeicherten Token bis zu 100 % Rabatt auf seine Prompttoken erhalten. Wenn dermax_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 dermax_tokens
-Wert der tatsächlichen Generierungsgröße so nah wie möglich ist.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.
Die Gesamtauslastung wird basierend auf der Anzahl der bereitgestellten PTUs in fortlaufenden Dekrementen verringert.
Hinweis
Aufrufe werden angenommen, bis die Auslastung 100 Prozent erreicht. Bursts, die nur wenig über 100 Prozent liegen, sind möglicherweise für kurze Zeiträume zulässig, aber im Zeitverlauf wird Ihr Datenverkehr auf eine Auslastung von 100 % begrenzt.
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_token“ usw.). Der Dienst akzeptiert Aufrufe weiterhin, bis die Nutzung 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 als die Anzahl der Samplingtoken wie max_token generiert, nimmt es mehr Anfragen an.
Welche Modelle und Regionen sind für den bereitgestellten Durchsatz verfügbar?
Region | gpt-4o, 2024-05-13 | gpt-4o, 2024-08-06 | gpt-4o-mini, 2024-07-18 | gpt-4, 0613 | gpt-4, 1106-Preview | gpt-4, 0125-Preview | gpt-4, turbo-2024-04-09 | gpt-4-32k, 0613 | gpt-35-turbo, 1106 | gpt-35-turbo, 0125 |
---|---|---|---|---|---|---|---|---|---|---|
australiaeast | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
brazilsouth | ✅ | - | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | - |
canadacentral | ✅ | - | - | ✅ | - | - | - | ✅ | - | ✅ |
canadaeast | ✅ | - | ✅ | ✅ | ✅ | - | ✅ | - | ✅ | - |
eastus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
eastus2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
francecentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | - | ✅ |
germanywestcentral | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | - |
japaneast | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ | - | - | ✅ |
koreacentral | ✅ | ✅ | ✅ | ✅ | - | - | ✅ | ✅ | ✅ | - |
northcentralus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
norwayeast | ✅ | - | ✅ | ✅ | - | ✅ | - | ✅ | - | - |
polandcentral | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
southafricanorth | ✅ | - | - | ✅ | ✅ | - | ✅ | ✅ | ✅ | - |
southcentralus | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
southindia | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
swedencentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
switzerlandnorth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
switzerlandwest | - | - | - | - | - | - | - | - | - | ✅ |
uaenorth | ✅ | - | - | - | ✅ | - | - | - | ✅ | ✅ |
uksouth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
westus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
westus3 | ✅ | ✅ | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Hinweis
Die bereitgestellte Version von gpt-4
Version: turbo-2024-04-09
ist derzeit ausschließlich auf Text beschränkt.