Microsoft Foundry Models-kvoter och -gränser

Den här artikeln innehåller en snabbreferens och detaljerad beskrivning av kvoter och gränser för Foundry-modeller som säljs av Azure. Kvoter och begränsningar som är specifika för Azure OpenAI i Foundry Models finns i Quotas and limits in Azure OpenAI.

Kvothantering på prenumerationsnivå

Från och med Realtime Translate och Realtime Transcribe, och snart alla modeller, spårar Foundry kvoten för distributioner på prenumerationsnivå i stället för per resurs eller per region. Den här metoden ger konsekvens och förutsägbarhet för hur kvoten hanteras mellan distributioner, eftersom alla resurser och regioner i en prenumeration delar samma kvotpool.

Den här ändringen konsoliderar kvoten till delade pooler:

• Global Standard: Distributioner av samma modell och version delar en kvotpool i alla regioner i en prenumeration.
• Data Zone Standard: Distributioner av samma modell och version delar en kvotpool per datazon (till exempel USA eller EU).

Kontrollera omfånget för kvothantering

Du hittar det kvothanteringssystem som gäller för en viss modell genom att gå till foundry-portalens kvotsida . Värdet i kolumnen Omfång för en viss modell anger hur Foundry hanterar kvoten för modellen. Ett omfångsvärde för:

• Global eller datazon, anger kvothantering på prenumerationsnivå.
• En region (till exempel USA, östra eller USA, västra) anger kvothantering per region för den prenumerationen och modellen.

Ändringar för registrerade modeller

För de modeller som registreras i kvothanteringssystemet på prenumerationsnivå:

• Alla Global Standard-distributioner av samma modell och version under en prenumeration hämtas nu från en enda delad kvotpool i alla regioner.
• Alla Data Zone Standard-distributioner av samma modell och version under en prenumeration hämtas nu från en delad kvotpool inom varje datazon.
• Befintlig godkänd kvot behålls och tillämpas automatiskt på prenumerationsnivå – ingen åtgärd krävs.

Med den här konsolideringen kan Microsoft Foundry erbjuda modeller som stöds konsekvent i alla Foundry-regioner, oavsett hur kvoten fördelas mellan resurser eller regioner.

Kvotgränser när en modell uppgraderas

När en befintlig modell uppgraderas anges dess nya kvotgräns för global eller datazon till den större av:

• Den tillämpliga nivågränsen.
• Den totala kvoten som tilldelats till alla befintliga distributioner av modellen inom kvotomfånget.

Om en modell till exempel har Global Standard-distributioner i fem regioner är den nya globala kvotgränsen lika med den kombinerade kvoten för dessa distributioner om den summan överskrider nivågränsen. Annars gäller nivågränsen.

Referens för kvoter och gränser

Följande avsnitt innehåller en snabbguide till de standardkvoter och gränser som gäller för Foundry-modeller. Kvoter och gränser tillämpas inte på klientorganisationsnivå. I stället begränsas den högsta nivån av kvotbegränsningar på Azure prenumerationsnivå. Gränser för token per minut (TPM) och begäranden per minut (RPM) definieras per region, per prenumeration och per modell eller distributionstyp.

Resursgränser (per Azure prenumeration, per region)

Hastighetsgränser

I följande tabell visas begränsningar för Foundry Models för följande priser:

• Token per minut
• Begäranden per minut
• Samtidig begäran

Om du vill öka kvoten använder du Microsoft Foundry Service: Begäran om kvotökning för att skicka din begäran. På grund av hög efterfrågan utvärderas begäranden om att öka kvoten individuellt. Mer information om begäranden om kvotökning finns i begära höjning av standardgränserna.

Andra gränser

¹ Aktuella API:er tillåter upp till 10 anpassade huvuden, som pipelinen passerar genom och returnerar. Om du överskrider det här antalet huvuden resulterar din begäran i ett HTTP 431-fel. Du kan lösa det här felet genom att minska rubrikvolymen. Framtida API-versioner kommer inte att gå via anpassade huvuden. Var inte beroende av anpassade rubriker i framtida systemarkitekturer.

Användningsnivåer

Global Standard-distributioner använder Azure globala infrastruktur för att dynamiskt dirigera kundtrafik till datacentret med bästa tillgänglighet för kundens slutsatsdragningsbegäranden. Den här infrastrukturen möjliggör mer konsekvent svarstid för kunder med låg till medelhög trafiknivå. Kunder med hög ihållande användningsnivå kan se fler variabiliteter i svarsfördröjningen.

Användningsgränsen anger den användningsnivå över vilken kunder kan uppleva större variationer i svarslatensen. En kunds användning definieras per modell och är det totala antalet tokens som förbrukas i alla distributioner i alla prenumerationer i alla regioner för en viss klientorganisation.

Begär ökningar av standardgränserna

Skicka in formuläret för begäran om kvotökning för att begära kvotökningar för Foundry Models som säljs av Azure, Azure OpenAI-modeller och Anthropic-modeller. Förutom Anthropic-modeller stöder modeller från partners och communityn inte kvotgränser.

Begäranden om kvotökning bearbetas i den ordning de tas emot och prioriteten går till kunder som aktivt använder sin befintliga kvotallokering. Begäranden som inte uppfyller det här villkoret kan nekas.

Allmänna metodtips för att hålla sig inom hastighetsgränser

Använd följande tekniker för att minimera problem som rör hastighetsbegränsningar:

• Implementera logik för återförsök i ditt program.
• Undvik kraftiga ändringar i arbetsbelastningen. Öka arbetsbelastningen gradvis.
• Testa olika mönster för belastningsökning.
• Öka den kvot som tilldelats distributionen. Flytta vid behov kvoten från en annan distribution.

Ange tidsgräns på klientsidan

Ange tidsgränsen på klientsidan explicit baserat på följande vägledning.

• Resonemangsmodeller (modeller som genererar mellanliggande resonemangstoken innan du skapar ett sammanfattat svar): upp till 29 minuter.
• Modeller som inte resonerar:
  • För direktuppspelning upp till 60 sekunder.
  • För icke-strömmande förfrågningar, upp till 29 minuter.

29 minuter här innebär inte att alla begäranden tar 29 minuter, utan snarare beroende på kontexttoken, genererade token och cacheträffar kan begäranden ta upp till 29 minuter.

Ange en timeout som är mindre än dessa värden, justerad efter dina trafikmönster.

För resonemangsmodeller, inklusive strömningsbegäranden, genereras först alla resonemangstoken och sammanfattas sedan innan den första svarstoken skickas tillbaka till användaren.

Du kan ändra parametern för resonemangsinsats för att styra antalet resonemangstoken som genereras i processen.

Felsökning

Relaterat innehåll

• Modeller som är tillgängliga i Foundry-modeller
• Hantera och öka kvoter för Foundry-resurser
• Quotas och gränser i Azure OpenAI