Vad är tilldelad överföringskapacitet?

Azure AI Foundry-erbjudandet för etablerat dataflöde är en modelldistributionstyp som gör att du kan ange hur mycket dataflöde du behöver i en modelldistribution. Azure AI Foundry allokerar sedan den nödvändiga modellbearbetningskapaciteten och ser till att den är redo för dig. Du kan använda det etablerade dataflödet som du begärde i en mängd olika modeller som säljs direkt av Azure. Dessa modeller omfattar Azure OpenAI-modeller och nyligen introducerade flaggskeppsmodellfamiljer som Azure DeepSeek, Azure Grok, Azure Llama med mera i Azure AI Foundry Models.

Etablerat dataflöde ger:

• Ett bredare modellval på de senaste flaggskeppsmodellerna
• Flexibilitet att växla modeller och distributioner med en viss etablerad dataflödeskvot
• Betydande rabatter och möjligheten att öka reservationsanvändningen med ett mer flexibelt reservationsval
• Förutsägbara prestanda genom att tillhandahålla stabil maximal svarstid och dataflöde för enhetliga arbetsbelastningar.
• Allokerad bearbetningskapacitet: En distribution konfigurerar mängden dataflöde. När dataflödet har distribuerats är det tillgängligt oavsett om det används eller inte.
• Kostnadsbesparingar: Arbetsbelastningar med högt dataflöde kan ge kostnadsbesparingar jämfört med tokenbaserad förbrukning.

När ska du använda provisionerad bandbredd

Du bör överväga att byta från standarddistributioner till etablerade dataflödesdistributioner när du har väldefinierade, förutsägbara dataflödes- och svarstidskrav. Detta inträffar vanligtvis när programmet är redo för produktion eller redan har distribuerats i produktion och det finns en förståelse för den förväntade trafiken. Detta gör det möjligt för användare att korrekt prognostisera den kapacitet som krävs och undvika oväntad fakturering. Tilldelade genomströmningskonfigurationer är också användbara för program som har real- eller svarstidskänsliga krav.

Viktiga begrepp

Avsnitten som följer beskriver viktiga begrepp som du bör känna till när du använder det etablerade dataflödeserbjudandet.

Etablerade dataflödesenheter (PTU)

Etablerade dataflödesenheter (PTU) är allmänna enheter för modellbearbetningskapacitet som du kan använda för att storleksanpassa etablerade distributioner för att uppnå det dataflöde som krävs för bearbetning av frågor och generering av slutföranden. Tilldelade kapacitetsenheter tilldelas en prenumeration som en kvot och används för kostnadsdefiniering. Varje kvot är specifik för en region och definierar det maximala antalet PTU som kan tilldelas till distributioner i den prenumerationen och regionen.

Kostnadshantering under delad PTU-reservation

Du kan använda PTU-funktionen för att sömlöst hantera kostnader för Foundry-modeller under en delad PTU-reservation. De PTU-enheter som krävs för distributions- och dataflödesprestanda skräddarsys dock dynamiskt efter de valda modellerna. Mer information om PTU-kostnader och modellsvarstidspunkter finns i Förstå kostnader som är associerade med PTU.

Befintliga PTU-reservationer uppgraderas automatiskt för att ge kunderna bättre effektivitet och kostnadsbesparingar när de distribuerar Foundry-modeller. Anta till exempel att du har en befintlig PTU-reservation med 500 PTU köpt. Du använder 300 enheter för Azure OpenAI-modeller och väljer att även använda PTU för att distribuera Azure DeepSeek, Azure Llama eller andra modeller med PTU-funktioner på Foundry Models.

• Om du använder återstående 200 PTU för DeepSeek-R1 delar 200 PTU reservationsrabatten automatiskt och din totala användning för reservationen är 500 PTU.

• Om du använder 300 PTU för DeepSeek-R1 delar 200 PTU reservationsrabatten automatiskt medan 100 PTU överskrider reservationen och debiteras med DeepSeek-R1s timpris.

Mer information om hur du sparar kostnader med PTU-reservationer finns i Spara kostnader med Microsoft Azure AI Foundry Provisioned Throughput Reservations (Spara kostnader med Microsoft Azure AI Foundry Provisioned Throughput Reservations).

Distributionstyper

När du skapar en etablerad distribution i Azure AI Foundry kan distributionstypen i dialogrutan "Skapa distribution" anges till distributionstypen Globalt etablerat dataflöde, datazonetablerade dataflöden eller regionalt etablerat dataflöde beroende på databehandlingsbehoven för den angivna arbetsbelastningen.

När du skapar en etablerad distribution i Azure AI Foundry via CLI eller API sku-name kan du ställa in på GlobalProvisionedManaged, DataZoneProvisionedManagedeller ProvisionedManaged beroende på databehandlingsbehovet för den angivna arbetsbelastningen.

Om du vill anpassa följande Azure CLI-exempelkommando till en annan distributionstyp uppdaterar du parametern så att den sku-name matchar den distributionstyp som du vill distribuera.

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

Kapacitetstransparens

De modeller som säljs direkt av Azure är mycket eftertraktade tjänster där kundernas efterfrågan kan överskrida GPU-kapaciteten för tjänsten. Microsoft strävar efter att tillhandahålla kapacitet för alla regioner och modeller på begäran, men att sälja ut en region är alltid en möjlighet. Den här begränsningen kan begränsa vissa kunders möjlighet att skapa en distribution av önskad modell, version eller antal PTU i en önskad region – även om de har en tillgänglig kvot i den regionen. Generellt sett:

• Kvoten begränsar det maximala antalet PTU:er som kan distribueras i en prenumeration och region och garanterar inte kapacitetstillgänglighet.
• Kapaciteten allokeras vid distributionstillfället och lagras så länge distributionen finns. Om tjänstkapaciteten inte är tillgänglig misslyckas distributionen.
• Kunder använder realtidsinformation om kvot/kapacitetstillgänglighet för att välja en lämplig region för sitt scenario med den modellkapacitet som krävs.
• Om du skalar ned eller tar bort en distribution frigörs kapaciteten tillbaka till regionen. Det finns ingen garanti för att kapaciteten blir tillgänglig om distributionen skalas upp eller återskapas senare.

Vägledning för regional kapacitet

Om du vill hitta den kapacitet som behövs för deras distributioner använder du kapacitets-API:et eller Azure AI Foundry-distributionsmiljön för att tillhandahålla realtidsinformation om kapacitetstillgänglighet.

I Azure AI Foundry identifierar distributionsupplevelsen när en region saknar den kapacitet som krävs för att distribuera modellen. Detta tittar på önskad modell, version och antal PTU. Om kapaciteten inte är tillgänglig uppmanas användarna att välja en alternativ region.

Information om distributionsupplevelsen finns i kom igång-guiden för Azure AI Foundry Provisioned.

API:et för modellkapaciteter kan användas för att programmatiskt identifiera den maximala distributionen av en angiven modell. API:et tar hänsyn till både din kvot och tjänstkapacitet i regionen.

Om en acceptabel region inte är tillgänglig för att stödja önskad modell, version och/eller PTU kan kunderna också prova följande steg:

• Försök att genomföra med ett mindre antal PTU.
• Försök att distribuera vid en annan tidpunkt. Kapacitetstillgänglighet ändras dynamiskt baserat på kundernas efterfrågan och mer kapacitet kan bli tillgänglig senare.
• Se till att kvoten är tillgänglig i alla godkända regioner. Modellkapacitets-API:et och Azure AI Foundry-upplevelsen överväger kvottillgänglighet i returnerade alternativa regioner för att skapa en distribution.

Hur kan jag övervaka kapaciteten?

Måttet Etablerad hanterad användning V2 i Azure Monitor mäter en viss distributionsanvändning i steg om 1 minut. Alla etablerade distributionstyper är optimerade för att säkerställa att godkända anrop bearbetas med en consis tältläge l-bearbetningstid (faktisk svarstid från slutpunkt till slutpunkt är beroende av ett samtals egenskaper).

Så här fungerar användningsprestanda

Etablerade distributioner ger dig en allokerad mängd modellbearbetningskapacitet för att köra en viss modell.

När kapaciteten överskrids i alla etablerade distributionstyper returnerar API:et ett 429 HTTP-statusfel. Det snabba svaret gör det möjligt för användaren att fatta beslut om hur de ska hantera sin trafik. Användare kan omdirigera begäranden till en separat distribution, till en standarddistributionsinstans eller använda en strategi för återförsök för att hantera en viss begäran. Tjänsten fortsätter att returnera 429 HTTP-statuskoden tills användningen sjunker under 100 %.

Vad ska jag göra när jag får ett 429-svar?

429-svaret är inte ett fel, men i stället är det en del av designen för att berätta för användarna att en viss distribution används fullt ut vid en tidpunkt. Genom att tillhandahålla ett snabbt felsvar har du kontroll över hur du hanterar dessa situationer på ett sätt som bäst passar dina programkrav.

Med retry-after-ms huvudena och retry-after i svaret får du tid att vänta innan nästa anrop godkänns. Hur du väljer att hantera det här svaret beror på dina programkrav. Här följer några överväganden:

• Du kan överväga att omdirigera trafiken till andra modeller, distributioner eller upplevelser. Det här alternativet är lösningen med lägsta svarstid eftersom åtgärden kan vidtas så snart du får 429-signalen. Information om hur du effektivt implementerar det här mönstret finns i det här community-inlägget.
• Om du är okej med längre svarstider per anrop implementerar du logik för återförsök på klientsidan. Det här alternativet ger dig den högsta mängden dataflöde per PTU. Azure AI Foundry-klientbiblioteken innehåller inbyggda funktioner för att hantera återförsök.

Hur bestämmer tjänsten när en 429 ska skickas?

I alla etablerade distributionstyper utvärderas varje begäran individuellt enligt dess promptstorlek, förväntade generationsstorlek och modell för att fastställa dess förväntade användning. Det här beteendet står i kontrast till standarddistributioner, som har ett anpassat hastighetsbegränsningsbeteende baserat på den uppskattade trafikbelastningen. För standarddistributioner kan det här beteendet för anpassad hastighetsbegränsning leda till att HTTP 429-fel genereras innan definierade kvotvärden överskrids om trafiken inte distribueras jämnt.

För etablerade distributioner använder vi en variant av algoritmen för läckande bucketar för att upprätthålla användningen under 100 % samtidigt som viss bristning i trafiken tillåts. Logiken på hög nivå är följande:

1. Varje kund har en viss mängd kapacitet som de kan använda i en distribution

2. När en begäran görs:

   a. När den aktuella användningen är över 100 %, returnerar tjänsten en 429-kod med retry-after-ms huvudet inställt på tiden tills användningen är under 100 %

   b) I annat fall beräknar tjänsten den inkrementella ändring av användningen som krävs för att hantera begäran genom att kombinera prompttoken, mindre cachelagrade token och angivna max_tokens i anropet. En kund kan få upp till 100 % rabatt på sina prompttoken beroende på storleken på deras cachelagrade token. Om parametern max_tokens inte har angetts beräknar tjänsten ett värde. Den här uppskattningen kan leda till lägre samtidighet än förväntat när antalet faktiska genererade token är litet. För högsta samtidighet kontrollerar du att max_tokens värdet ligger så nära den verkliga generationsstorleken som möjligt.

3. När en begäran är klar vet vi nu den faktiska beräkningskostnaden för anropet. För att säkerställa en korrekt redovisning korrigerar vi användningen med hjälp av följande logik:

   a. Om den faktiska > uppskattningen läggs skillnaden till i distributionens användning.

   b) Om den faktiska < uppskattningen subtraheras skillnaden.

4. Den totala användningen minskas kontinuerligt baserat på antalet distribuerade PTU:er.

Hur många samtidiga anrop kan jag ha i distributionen?

Antalet samtidiga anrop som du kan uppnå beror på varje anrops form (promptstorlek, max_tokens parameter osv.). Tjänsten fortsätter att acceptera anrop tills användningen når 100 %. För att fastställa det ungefärliga antalet samtidiga anrop kan du modellera ut maximalt antal begäranden per minut för en viss anropsform i kapacitetskalkylatorn. Om systemet genererar mindre än det antal utdatatoken som angetts för parametern max_tokens accepterar den etablerade distributionen fler begäranden.

Tillhandahållen genomströmningskapacitet för modeller som säljs direkt av Azure

I det här avsnittet visas Foundry-modeller som stöder etablerat dataflöde. Du kan använda din PTU-kvot och PTU-reservation i de modeller som visas i tabellen.

Följande punkter är några viktiga lärdomar från tabellen:

• Modellversionen ingår inte i den här tabellen. Kontrollera vilken version som stöds för varje modell när du väljer distributionsalternativet i Azure AI Foundry-portalen.

• Alternativet för regional etablering av genomströmning varierar beroende på region.

• Nya modeller som säljs direkt av Azure integreras först med distributionsalternativet för tilldelade dataflöde Globalt. Alternativet för datazonens etablering kommer senare.

• PTU hanteras regionalt och utifrån erbjudandetyp. PTU-kvot och eventuella reservationer måste vara i den region och form (Global, Datazon, Regional) som du vill använda.

• Spillover är en valfri funktion som hanterar trafikfluktuationer på konfigurerade distributioner. Mer information om spillover finns i Hantera trafik med spillover för etablerade distributioner.

Regiontillgänglighet för etablerad kapacitet för dataflöde

Relaterat innehåll

• Lär dig mer om registreringsstegen för etablerade distributioner
• Kom igång-guide för tilldelade genomflödesenheter (PTU)