Freigeben über

Microsoft Foundry Models-Kontingente und Grenzwerte

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.

Dieser Artikel enthält eine Kurzübersicht und detaillierte Beschreibung der Kontingente und Grenzwerte für Microsoft Foundry Models. Kontingente und Grenzwerte für azure OpenAI in Foundry Models finden Sie unter "Kontingente und Grenzwerte" in Azure OpenAI.

Referenz zu Kontingenten und Grenzwerten

In Azure werden Kontingente und Grenzwerte verwendet, um Budgetüberschreitungen aufgrund von Betrug zu vermeiden und Azure-Kapazitätseinschränkungen durchzusetzen. Berücksichtigen Sie diese Grenzwerte bei der Skalierung für Produktionsworkloads. In den folgenden Abschnitten finden Sie eine kurze Anleitung zu den Standardkontingenten und Grenzwerten, die für den Azure AI-Modell-Rückschlussdienst in Foundry gelten:

Ressourcenbeschränkungen

Limitname Grenzwert
Gießereiressourcen pro Region pro Azure-Abonnement 100
Max. Projekte pro Ressource 250
Maximale Bereitstellung pro Ressource 32

Ratenbegrenzungen

In der folgenden Tabelle sind Grenzwerte für Foundry Models für die folgenden Tarife aufgeführt:

  • Token pro Minute
  • Anfragen pro Minute
  • Gleichzeitige Anforderung
Models Token pro Minute Anfragen pro Minute Gleichzeitige Anforderungen
Azure OpenAI-Modelle Variiert je nach Modell und SKU. Siehe Grenzwerte für Azure OpenAI. Variiert je nach Modell und SKU. Siehe Grenzwerte für Azure OpenAI. nicht zutreffend
- DeepSeek-R1
- DeepSeek-V3-0324		 5,000,000 5.000 300
- Llama 3.3 70B Anweisung
- Llama-4-Maverick-17B-128E-Instruct-FP8
- Grok 3
- Grok 3 mini		 400,000 1.000 300
- Flux.2-Pro nicht zutreffend - Niedrig (Standard): 15
- Mittel: 30
- Hoch (Unternehmen): 100		 nicht zutreffend
- Flux-Pro 1.1
- Flux.1-Kontext Pro		 nicht zutreffend 2 Kapazitätseinheiten (6 Anforderungen pro Minute) nicht zutreffend
Restliche Modelle 400,000 1.000 300

So erhöhen Sie Ihr Kontingent

Aufgrund der hohen Nachfrage bewerten wir die Anforderungen von Grenzwerterhöhungen pro Anforderung.

Andere Limits

Limitname Grenzwert
Maximale Anzahl von benutzerdefinierten Headern in API-Anforderungen1 10

1 Unsere aktuellen APIs ermöglichen bis zu 10 benutzerdefinierte Header, die über die Pipeline übergeben und zurückgegeben werden. Wenn Sie diese Headeranzahl überschreiten, führt ihre Anforderung zu einem HTTP 431-Fehler. Um diesen Fehler zu beheben, verringern Sie die Headermenge. In zukünftigen API-Versionen werden keine benutzerdefinierten Header mehr übergeben. Es wird empfohlen, dass Sie in zukünftigen Systemarchitekturen nicht auf benutzerdefinierte Header angewiesen sind.

Verwendungsebenen

Globale Standardbereitstellungen verwenden die globale Azure-Infrastruktur, um Kundendatenverkehr dynamisch an das Rechenzentrum weiterzuleiten, das die beste Verfügbarkeit für die Rückschlussanforderungen des Kunden bietet. Diese Infrastruktur ermöglicht eine konsistentere Wartezeit für Kunden mit geringem bis mittlerem Datenverkehr. Bei Kunden mit einer dauerhaft hohen Nutzung tritt möglicherweise eine höhere Variabilität der Antwortwartezeit auf.

Der Nutzungsgrenzwert bestimmt den Nutzungsgrad, über dem für Kunden möglicherweise eine höhere Variabilität der Antwortwartezeit auftritt. Die Nutzung eines Kunden ist pro Modell definiert und setzt sich aus der Gesamtanzahl der Token zusammen, die von einem bestimmten Mandanten durch alle Bereitstellungen in allen Abonnements und Regionen verbraucht werden.

Erhöhung der Standardgrenzwerte anfordern

Anfragen zur Kontingenterhöhung können über das Formular zum Anfordern einer Kontingenterhöhung übermittelt werden. Aufgrund der hohen Nachfrage werden Anfragen zur Kontingenterhöhung akzeptiert und in der Reihenfolge bearbeitet, in der sie eingehen. Die Priorität wird Kundschaft zugewiesen, die Datenverkehr generiert, der die vorhandene Kontingentzuordnung nutzt. Ihre Anforderung wird möglicherweise verweigert, wenn diese Bedingung nicht erfüllt ist.

Sie können eine Serviceanfrage für andere Tariflimits absenden.

Allgemeine bewährte Methoden, um innerhalb der Ratenbegrenzungen zu bleiben

Um Probleme im Zusammenhang mit der Ratenbegrenzung zu minimieren, nutzen Sie folgende Methoden:

  • Implementieren Sie eine Wiederholungslogik in der Anwendung.
  • Vermeiden Sie plötzliche Änderungen bei der Arbeitsauslastung. Erhöhen Sie die Workload nach und nach.
  • Testen Sie verschiedene Lasterhöhungsmuster.
  • Erhöhen Sie das Kontingent, das Ihrer Bereitstellung zugewiesen ist. Verschieben Sie Kontingent bei Bedarf aus einer anderen Bereitstellung.

Festlegen eines clientseitigen Timeouts

Es wird empfohlen, das clientseitige Timeout wie folgt explizit festzulegen.

Hinweis

Wenn nicht explizit festgelegt, könnte das clientseitige Timeout gemäß der verwendeten Bibliothek vorhanden sein und möglicherweise nicht den gleichen Grenzwerten wie oben entsprechen.

  • Begründungsmodelle: bis zu 29 Minuten.
  • Nicht-Schlussfolgerungs-Modelle
    • Für streaming, bis zu 60 Sekunden.
    • Bei Nicht-Streaming-Anforderungen bis zu 29 Minuten.

29 Minuten bedeutet hier nicht, dass alle Anforderungen 29 Minuten dauern, sondern je nach Kontexttoken, generierten Token und Cachetreffraten können Anforderungen bis zu 29 Minuten dauern.

Sie müssen einen Timeout festlegen, der kleiner als der oben genannte Wert und für Ihre Datenverkehrsmuster optimiert ist.

Für Begründungsmodelle, einschließlich Streaming-Anfragen, werden erst alle Verarbeitungstoken generiert und dann zusammengefasst, bevor das erste Antwort-Token an den Benutzer zurückgesendet wird.

Sie können den Parameter "Reasoning Effort " ändern, um die Anzahl der im Prozess generierten Begründungstoken zu steuern.

Nächste Schritte

  • Last updated on