Dela via

Vad är allokerat dataflöde för Foundry-modeller?

Anmärkning

Det här dokumentet refererar till Microsoft Foundry-portalen (klassisk).

🔄 Växla till dokumentationen för Microsoft Foundry (ny) om du använder den nya portalen.

Anmärkning

Det här dokumentet refererar till Microsoft Foundry-portalen (ny).

Tips/Råd

Mer information om de senaste ändringarna av det tillhandahållna genomströmningserbjudandet finns i artikeln om uppdateringen.

Microsoft 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. Foundry allokerar sedan den nödvändiga modellbearbetningskapaciteten och ser till att den är redo för dig. Använd det etablerade dataflöde 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 Foundry Models.

Etablerat dataflöde ger:

Förmån Description
Bredare modellval Åtkomst till de senaste flaggskeppsmodellerna
Flexibilitet Växla modeller och distributioner med en viss etablerad dataflödeskvot
Betydande rabatter Öka reservationsanvändningen med ett mer flexibelt reservationsval
Förutsägbar prestanda Stabil maximal svarstid och dataflöde för enhetliga arbetsbelastningar
Allokerad bearbetningskapacitet Dataflöde är tillgängligt oavsett om det används eller inte när det har implementerats.
Kostnadsbesparingar Arbetsbelastningar med högt dataflöde kan ge kostnadsbesparingar jämfört med tokenbaserad förbrukning

Tips/Råd

När ska du använda provisionerad bandbredd

Överväg att etablera distributioner av dataflöde när du har väldefinierade, förutsägbara dataflödes- och svarstidskrav – vanligtvis för produktionsprogram med kända trafikmönster. Etablerat dataflöde är också användbart för realtids- eller svarstidskänsliga program.

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.

Provisionerad genomströmningskapacitet (PTU)

Etablerade dataflödesenheter (PTU) är generiska enheter för modellbearbetningskapacitet som du använder 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. Provisionerade genomflödesenheter beviljas till en prenumeration som en kvot och används för att definiera kostnader. 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

Använd PTU-funktionen för att sömlöst hantera kostnader för Foundry-modeller under en delad PTU-reservation. Men de PTU-enheter som krävs för distributions- och dataflödesprestanda skräddarsys 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 Foundry Provisioned Throughput Reservationer.

Distributionstyper

När du skapar en etablerad distribution i Foundry kan distributionstypen i dialogrutan Skapa distribution ställas in på global etablerat dataflöde, datazonetablerade dataflöden eller regionalt etablerat dataflödesdistributionstyp beroende på databehandlingsbehoven för den angivna arbetsbelastningen.

När du skapar en konfigurerad driftsättning i Foundry via CLI eller API kan sku-name ställas in till GlobalProvisionedManaged, DataZoneProvisionedManaged eller ProvisionedManaged beroende på databehandlingsbehovet för den angivna arbetsbelastningen.

Distributionstyp sku-name i CLI
Globalt tilldelad genomströmning GlobalProvisionedManaged
Datazon reserverad genomströmning DataZoneTillhandahållenHanterad
Regionalt provisionerat genomflöde FörseddHanterad

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 sätter en gräns för 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 är 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 Foundry-distributionsmiljön för att tillhandahålla realtidsinformation om kapacitetstillgänglighet.

I 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 Foundry Provisioned.

Använd API:et för modellkapaciteter 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 utplacera med mindre antal PTU:er.
  • 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 och Foundry-upplevelsen tar hänsyn till kvottillgänglighet när alternativa regioner returneras för att skapa en distribution.

Övervaka kapacitet

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

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

Hantera HTTP 429-svar

429-svaret är inte ett fel, utan är 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:

  • Överväg 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. 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 för 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 headern retry-after-ms som anger 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.

Anmärkning

Anrop accepteras tills användningen når 100 %. Bursts drygt 100% kan tillåtas under korta perioder, men över tid är din trafik begränsad till max 100% utnyttjandegrad.

Diagram över den läckande hink-algoritmen för tillhandahållen genomflödesanvändning som visar hur inkommande begäranden ökar användningen medan kapaciteten minskar baserat på utplacerat PTU-antal.

Gränser för samtidiga samtal

Antalet samtidiga anrop som du kan uppnå på en distribution beror på varje anrops form (promptstorlek, max_tokens parameter och liknande faktorer). 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.

Tilldelad genomströmningskapacitet för modeller som säljs direkt via Azure

I det här avsnittet visas Foundry-modeller som stöder etablerat dataflöde. Använd din PTU-kvot och PTU-reservation i de modeller som visas i 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 Foundry-portalen.

  • Distributionsalternativen för tilldelad genomströmning per region varierar beroende på region.

  • Nya modeller som säljs direkt av Azure registreras med distributionsalternativet global etablering av reserverad kapacitet först. Alternativet för datazonens etablering kommer senare.

  • PTU:er hanteras regionalt och efter 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.

Modellfamilj Modellnamn Global tillhandahållen Datazon tillhandahållen Regionalt tillhandahållen Spilloverfunktion
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 ✅ ✅ ✅ ✅
Gpt 4o mini ✅ ✅ ✅ ✅
Gpt 3,5 Turbo ✅ ✅ ✅ ✅
o1 ✅ ✅ ✅ ✅
o3 ✅ ✅ ✅ ✅
o3 mini ✅ ✅ ✅ ✅
o4 mini ✅ ✅ ✅ ✅
Azure DeepSeek DeepSeek-R1 ✅
DeepSeek-V3-0324 ✅
DeepSeek-R1-0528 ✅

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

Tillgänglighet för global tilldelad genomströmningsmodell

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
Australia East - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Brasilien Södra - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Kanadacentrala - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Kanada Öst - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
centralus - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Tyskland Västra Centrala - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norra Italien - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Japan Öst - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norge öst - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
polencentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Sydafrika Nord - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Sydostasien - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Södra Indien - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
swedencentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
norra Schweiz - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Schweizväst - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Uaenorth - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westeurope - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Anmärkning

Den etablerade versionen av gpt-4version:turbo-2024-04-09 är för närvarande begränsad till endast text.

Relaterat innehåll

  • Last updated on