Freigeben über

Was ist der bereitgestellte Durchsatz für Foundry Models?

Hinweis

Dieses Dokument bezieht sich auf das Microsoft Foundry(klassische) Portal.

🔄 Wechseln Sie zur Microsoft Foundry-Dokumentation (neu), wenn Sie das neue Portal verwenden.

Hinweis

Dieses Dokument bezieht sich auf das Microsoft Foundry (neue) Portal.

Tipp

Weitere Informationen zu aktuellen Änderungen am bereitgestellten Durchsatzangebot finden Sie im Updateartikel.

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. Verwenden Sie den bereitgestellten Durchsatz, 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:

Nutzen Description
Breitere Modellauswahl Zugriff auf die neuesten Flagship-Modelle
Flexibilität Wechseln Sie Modelle und Bereitstellungen mit einem bestimmten Kontingent an bereitgestelltem Durchsatz
Erhebliche Rabatte Steigern Sie Ihre Reservierungsnutzung mit einer flexibleren Reservierungsauswahl
Vorhersehbare Leistung Stabile maximale Latenz und Durchsatz für einheitliche Workloads
Zugeordnete Verarbeitungskapazität Der Durchsatz ist verfügbar, unabhängig davon, ob er nach der Bereitstellung verwendet wird oder nicht.
Kosteneinsparung Hohe Durchsatzarbeitslasten bieten möglicherweise Kosteneinsparungen im Vergleich zur tokenbasierten Nutzung

Tipp

Wann man den bereitgestellten Durchsatz verwenden sollte

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.

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 (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.

Cost Management bei gemeinsam genutzter 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-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 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 der Parameter sku-name je nach Datenverarbeitungsanforderung für die angegebene Workload auf GlobalProvisionedManaged, DataZoneProvisionedManaged oder ProvisionedManaged festgelegt werden.

Bereitstellungstyp SKU-Name in CLI
Global bereitgestellter Durchsatz GlobalProvisionedManaged
Durch die Datenzone bereitgestellter Durchsatz DataZoneProvisionedManaged
Regional bereitgestellter Durchsatz BereitgestelltVerwaltet

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 Kontingente in dieser Region verfügbar haben. Generell gilt:

  • Das Kontingent begrenzt die maximale Anzahl von PTUs, die in einem Abonnement und einer Region bereitgestellt werden können, 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“.

Verwenden Sie die Modellkapazitäts-API , 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 später werden möglicherweise mehr Kapazitäten verfügbar.
  • 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.

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.

Auslastungsleistung

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.

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 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:

  • Erwägen Sie, 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 verwenden 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 im retry-after-ms-Header die Zeit angeben 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.

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.

Diagramm des Leaky-Bucket-Algorithmus zur Nutzung der bereitgestellten Durchsatzkapazität, das zeigt, wie eingehende Anfragen zur Auslastung beitragen, während die Kapazität basierend auf der berechneten PTU-Anzahl abnimmt.

Grenzwerte für gleichzeitige Anrufe

Die Anzahl der gleichzeitigen Anrufe, die bei einer Bereitstellung möglich sind, hängt von den Eigenschaften jedes Anrufs ab (Aufforderungsgröße, max_tokens Parameter und ähnliche Faktoren). 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. 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 Option für die Datenzone wird zu einem späteren Zeitpunkt bereitgestellt.

  • PTUs 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.

Modellfamilie Modellname Global bereitgestellt In Datenzonen bereitgestellt Regionale Bereitstellung Überlauf-Funktion
Azure OpenAI Gpt 5.2 ✅ ✅
Gpt 5.1 ✅ ✅ ✅
Gpt 5.1-Codex ✅ ✅ ✅
Gpt 5 ✅ ✅ ✅ ✅
Gpt 5 mini ✅ ✅ ✅ ✅
Gpt 4.1 ✅ ✅ ✅ ✅
Gpt 4.1 mini ✅ ✅ ✅ ✅
Gpt 4.1 nano ✅ ✅ ✅ ✅
GPT-4.0 ✅ ✅ ✅ ✅
Gpt 4o mini ✅ ✅ ✅ ✅
Gpt 3.5 Turbo ✅ ✅ ✅ ✅
O1 ✅ ✅ ✅ ✅
O3 ✅ ✅ ✅ ✅
o3 mini ✅ ✅ ✅ ✅
o4 mini ✅ ✅ ✅ ✅
Azure DeepSeek DeepSeek-R1 ✅
DeepSeek-V3-0324 ✅
DeepSeek-R1-0528 ✅

Regionsverfügbarkeit der bereitgestellten Durchsatzkapazität

Verfügbarkeit des globalen Modells für bereitgestellten Durchsatz

Region gpt-5.2, 2025-12-11 gpt-5.1, 2025-11-13 gpt-5.1-codex, 2025-11-13 gpt-5, 2025-08-07 gpt-5-mini, 2025-08-07 o3, 2025-04-16 o4-mini, 2025-04-16 gpt-4.1, 2025-04-14 gpt-4.1-nano, 2025-04-14 gpt-4.1-mini, 2025-04-14 o3-mini, 2025-01-31 o1, 2024-12-17 gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o, 2024-11-20 gpt-4o-mini, 2024-07-18
australiaeast - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Brasilien Süd - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
kanadacentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Kanada Ost - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
centralus - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Deutschland West-Zentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
italiennord - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Japan Ost - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Northcentralus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norwegen Ost - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Polenzentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Südafrika Nord - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Südostasien - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Südindien - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Spanienzentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
schwedencentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
SchweizNord - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Schweizwesten - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uaenorth - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Westeuropa - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Hinweis

Die bereitgestellte Version von gpt-4Version:turbo-2024-04-09 ist derzeit ausschließlich auf Text beschränkt.

Verwandte Inhalte

  • Last updated on