Wer aktuell mit Azure AI Foundry, Azure OpenAI oder modernen Foundation Models arbeitet, merkt relativ schnell, dass ein Thema immer wichtiger wird: Quotas. Am Anfang wirkt das oft wie ein technisches Nebenthema. Ein paar Limits für Tokens oder Requests, die man irgendwann später vielleicht einmal optimieren muss. In der Praxis entscheidet dieses Thema inzwischen aber darüber, ob eine KI-Anwendung stabil läuft oder unter Last plötzlich auseinanderfällt. Gerade jetzt verändert Microsoft dieses gesamte System massiv. Und ich glaube, viele haben noch gar nicht realisiert, wie groß dieser Wandel eigentlich ist.
Die alte Azure-OpenAI-Welt
Wer Azure OpenAI schon etwas länger nutzt, kennt vermutlich noch das klassische Modell. Man erstellt eine neue Azure-Subscription, deployed ein Modell und bekommt zunächst relativ kleine Standardlimits. Für erste Tests reicht das meistens problemlos aus. Die ersten Chatbots funktionieren, erste Demos laufen sauber und alles wirkt unkompliziert.
Sobald allerdings echte Last entsteht, wird das Thema plötzlich sichtbar. Dann tauchen die bekannten 429-Fehler auf, Requests werden gedrosselt und Teams beginnen damit, Quota-Erhöhungen über Support-Tickets zu beantragen. Das war lange Zeit ein ziemlich normaler Prozess.
Aus Microsoft-Sicht war das nachvollziehbar. GPU-Ressourcen sind teuer und vor allem bei großen Foundation Models nicht unbegrenzt verfügbar. Gleichzeitig musste verhindert werden, dass einzelne Kunden komplette Regionen blockieren. Das Problem war nur: In echten Projekten fühlt sich das schnell nicht mehr wie ein „Limit“, sondern wie ein harter Produktionsfehler an.
Ein Beispiel aus der Praxis: Der Chatbot, der im Demo-Modus perfekt lief
Ein klassisches Szenario, das ich immer wieder sehe:
Ein Unternehmen baut einen internen KI-Chatbot für Support-Mitarbeiter. In der Testphase läuft alles perfekt. Zehn bis zwanzig Nutzer, saubere Antwortzeiten, gute Qualität.
Dann geht das System live.
Plötzlich greifen 300 Mitarbeiter gleichzeitig darauf zu. Innerhalb weniger Minuten kippt das System in 429-Fehler. Nicht, weil der Code schlecht ist, sondern weil das Deployment schlicht nicht für diese Last dimensioniert war.
Die Reaktion ist fast immer dieselbe:
„Wir brauchen mehr Quota.“
Und genau hier begann früher oft der klassische Azure-Prozess:
Gerade bei kurzfristigen Lastspitzen war das oft schwierig.
Microsoft verändert gerade das gesamte Modell
Genau deshalb führt Microsoft inzwischen zunehmend ein neues Tier-System für Azure AI Foundry und Azure OpenAI ein.
Die Idee dahinter ist relativ simpel: Wer die Plattform produktiv und sinnvoll nutzt, soll automatisch mehr Kapazität bekommen. Statt ständig Support-Tickets zu schreiben, skaliert die verfügbare Leistung schrittweise mit der tatsächlichen Nutzung.
Das verändert vor allem eines: Planung wird dynamischer.
Neue Subscriptions starten meist mit eher kleinen Limits, während produktive Umgebungen über Zeit höhere Stufen erreichen können. Mit jedem Tier steigen typischerweise die verfügbaren Tokens pro Minute, die Anzahl paralleler Requests und die allgemeine Verarbeitungskapazität.
Die wichtigsten Veränderungen dabei:
Das klingt zunächst nach einer kleinen technischen Änderung, verändert in der Praxis aber ziemlich viel.
Praxisbeispiel: RAG-System im E-Commerce
Ein zweites Beispiel kommt oft aus dem E-Commerce.
Ein Shop baut ein RAG-System, das Produktfragen beantwortet. Die Architektur ist eigentlich sauber: Vektordatenbank, Retrieval, GPT-Modell, alles funktioniert.
Im normalen Betrieb ist die Last moderat.
Dann kommt ein Marketing-Event. Newsletter raus, Traffic steigt, tausende Kunden stellen gleichzeitig Fragen wie:
„Passt dieses Teil zu meinem Gerät?“
oder
„Welche Alternative gibt es?“
Innerhalb kurzer Zeit steigt der Tokenverbrauch massiv, weil jede Anfrage Produktdaten, Retrieval-Kontext, User-Historie und System-Prompts kombiniert.
Das System funktioniert technisch weiterhin, aber die Rate Limits greifen. Die User Experience bricht nicht komplett zusammen, aber sie wird sichtbar langsamer.
Hier wird Quota plötzlich kein „Cloud-Thema“ mehr, sondern ein direktes Business-Thema.
Warum das Thema plötzlich so wichtig wird
Vor zwei Jahren waren viele KI-Projekte noch relativ klein. Heute sieht die Realität anders aus.
Ein modernes System besteht oft aus Agenten, Tool Calling, langen Kontextfenstern und mehreren parallelen Modellen. Dazu kommen Realtime-Komponenten, teilweise sogar Voice Interfaces.
Ein Beispiel aus der Praxis: Ein Voice-Agent im Customer Support. Ein Kunde spricht mit dem System, das Modell verarbeitet Sprache in Echtzeit, ruft interne APIs auf, generiert Antworten und gibt sie wieder aus.
Das bedeutet faktisch, dass ein einzelner aktiver Call kontinuierlich Tokens produziert – nicht nur einzelne Requests.
Wenn dann gleichzeitig hunderte oder tausende Calls laufen, entsteht eine komplett andere Lastklasse als klassische Chat-APIs.
Und genau deshalb reichen starre Limits heute oft nicht mehr aus.
Bedeutet das jetzt das Ende von Quota-Requests?
Nicht ganz.
Und genau hier entsteht aktuell viel Missverständnis.
Microsoft bewegt sich klar in Richtung automatischer Skalierung. Viele kleinere Projekte profitieren tatsächlich davon, dass Quotas heute oft ohne manuelle Eingriffe wachsen.
Aber in der Realität bleibt das System hybrid.
Ein drittes Praxisbeispiel zeigt das gut: Ein Unternehmen betreibt einen internen Copilot für Entwickler. Die Nutzung wächst organisch. Am Anfang reicht ein kleines Tier völlig aus. Nach einigen Wochen greift das System automatisch höher.
Dann kommt ein neues Team dazu, plötzlich steigen die gleichzeitigen Requests stark an. Die automatische Skalierung greift zwar, aber nicht schnell genug für die neue Lastspitze.
Ergebnis: kurze Drosselung, Performance-Schwankungen, erneute Optimierung.
Das zeigt ziemlich gut, dass „automatisch“ nicht gleich „unendlich“ bedeutet.
Im Alltag hängt die tatsächliche Skalierung weiterhin von mehreren Faktoren ab:
Die Region als unterschätzter Faktor
Ein weiterer Punkt, der in der Praxis extrem wichtig ist: die Region.
Viele Teams erleben, dass ein Deployment in einer Region stabil läuft, während ein identisches Setup in einer anderen Region plötzlich deutlich niedrigere Limits hat.
Das hat weniger mit Konfiguration zu tun, sondern mit echter GPU-Kapazität im Hintergrund.
Ein typisches Beispiel: Ein Unternehmen deployt ein Modell in „West Europe“ und stößt schnell an Grenzen. In einer alternativen Region funktioniert dasselbe Setup plötzlich deutlich besser.
Das ist kein Fehler, sondern schlicht Kapazitätsverteilung.
Genau deshalb wird Multi-Region-Architektur zunehmend wichtiger, besonders bei größeren produktiven KI-Systemen.
Warum PTUs in echten Systemen weiterhin wichtig bleiben
Provisioned Throughput Units bleiben trotz allem ein zentraler Baustein für produktive Systeme.
Der Unterschied wird besonders in der Praxis sichtbar.
Ein weiteres Beispiel: Ein Contact Center mit KI-gestütztem Support. Hier ist nicht nur wichtig, dass die KI funktioniert, sondern dass sie konstant mit niedriger Latenz antwortet.
Wenn Kunden in einer Warteschleife hängen, sind Schwankungen bei der Antwortzeit direkt spürbar.
Genau hier helfen PTUs, weil sie nicht von geteilter Kapazität abhängig sind. Sie sorgen für stabile, planbare Leistung, unabhängig von globaler Last.
Vor allem bei produktiven Enterprise-Systemen bleiben deshalb Themen wie:
weiterhin extrem relevant.
Fazit – Was sich bei Azure AI Foundry Quotas gerade wirklich geändert hat
Die wichtigste Veränderung ist nicht einfach nur „mehr oder weniger Limits“, sondern ein grundlegender Wechsel im Systemdesign.
Früher waren Quotas statisch und mussten aktiv beantragt werden. Du hattest feste Default-Limits und wenn eine Anwendung gewachsen ist, bist du relativ schnell in Support-Prozesse geraten. Skalierung war damit eher ein administrativer Vorgang als ein technisches Systemverhalten.
Heute bewegt sich Microsoft klar in Richtung eines dynamischen Modells mit sogenannten Quota-Tiers. Diese Tiers werden teilweise automatisch anhand der Nutzung angepasst und sollen verhindern, dass Wachstum sofort an manuellen Freigabeprozessen scheitert.
Gleichzeitig bleibt Quota aber weiterhin ein mehrdimensionales System. Es hängt nicht nur vom Tier ab, sondern auch stark von Region, Modell und aktueller Kapazität. Genau das führt dazu, dass zwei identische Deployments in unterschiedlichen Umgebungen heute sehr unterschiedliche Limits haben können.
Die drei wichtigsten Veränderungen lassen sich so zusammenfassen:
In der Praxis bedeutet das: weniger klassische „Quota-Anträge“, aber dafür mehr dynamisches Kapazitätsmanagement im Hintergrund. Gleichzeitig bleiben manuelle Erhöhungen in bestimmten Szenarien weiterhin relevant, vor allem bei großen Workloads oder knapper GPU-Verfügbarkeit.
Der eigentliche Paradigmenwechsel ist damit ziemlich klar: Quotas sind kein statisches Limit-Problem mehr, sondern Teil der Infrastruktur-Skalierung selbst.