Vad är etablerat dataflöde?

Kommentar

Azure OpenAI Provisioned-erbjudandet fick betydande uppdateringar den 12 augusti 2024, inklusive anpassning av inköpsmodellen med Azure-standarder och övergång till modelloberoende kvot. Vi rekommenderar starkt att kunder som registrerats före det här datumet läser den Azure OpenAI-etablerade augustiuppdateringen för att lära sig mer om dessa ändringar.

Med funktionen för etablerat dataflöde kan du ange hur mycket dataflöde du behöver i en distribution. Tjänsten allokerar sedan den nödvändiga modellbearbetningskapaciteten och ser till att den är redo för dig. Dataflödet definieras i termer av etablerade dataflödesenheter (PTU) som är ett normaliserat sätt att representera dataflödet för distributionen. Varje modellversionspar kräver olika mängder PTU för att distribuera och tillhandahålla olika mängder dataflöde per PTU.

Vad tillhandahåller de etablerade distributionstyperna?

• Förutsägbar prestanda: stabil maximal svarstid och dataflöde för enhetliga arbetsbelastningar.
• Reserverad 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.

En Azure OpenAI-distribution är en hanteringsenhet för en specifik OpenAI-modell. En distribution ger kundåtkomst till en modell för slutsatsdragning och integrerar fler funktioner som Innehållsmoderering (se dokumentationen om con tältläge ration). Globala etablerade distributioner är tillgängliga i samma Azure OpenAI-resurser som alla andra distributionstyper, men gör att du kan utnyttja Azures globala infrastruktur för att dynamiskt dirigera trafik till datacentret med bästa tillgänglighet för varje begäran. På samma sätt är etablerade distributioner i datazoner också tillgängliga i samma resurser som alla andra distributionstyper, men gör att du kan utnyttja Azures globala infrastruktur för att dynamiskt dirigera trafik till datacentret i Den Microsoft-angivna datazonen med bästa tillgänglighet för varje begäran.

Vad får du då?

Område	Etablerad
Vad är det?	Ger garanterat dataflöde i mindre steg än det befintliga etablerade erbjudandet. Distributioner har en konsekvent maximal svarstid för en viss modellversion.
Vem är det avsett för?	Kunder som vill ha garanterat dataflöde med minimal svarstidsavvikelse.
Kvot	Etablerad enhet för hanterat dataflöde, global etablerad hanterad dataflödesenhet eller datazonetablerad hanterad dataflödesenhet tilldelad per region. Kvoten kan användas för alla tillgängliga Azure OpenAI-modeller.
Svarstid	Maximal svarstid som är begränsad från modellen. Övergripande svarstid är en faktor för anropsform.
Utnyttjande	Måttet Etablerad hanterad användning V2 som tillhandahålls i Azure Monitor.
Beräkna storlek	Tillhandahållen kalkylator i Azure AI Foundry och benchmarking-skript.
Promptcachelagring	För modeller som stöds rabatterar vi upp till 100 % av cachelagrade indatatoken.

Hur mycket dataflöde per PTU du får för varje modell

Mängden dataflöde (token per minut eller TPM) som en distribution hämtar per PTU är en funktion av in- och utdatatoken i minuten. Att generera utdatatoken kräver mer bearbetning än indatatoken, så ju fler utdatatoken genererade desto lägre total TPM. Tjänsten balanserar dynamiskt indata- och utdatakostnaderna så att användarna inte behöver ange specifika in- och utdatagränser. Den här metoden innebär att distributionen är motståndskraftig mot variationer i arbetsbelastningsformen.

För att underlätta storleksändringen beskriver följande tabell TPM per PTU för gpt-4o modellerna och gpt-4o-mini som representerar maximal TPM förutsatt att all trafik antingen är indata eller utdata. Information om hur olika förhållande mellan indata- och utdatatoken påverkar max TPM per PTU finns i Kapacitetskalkylatorn för Azure OpenAI. Tabellen visar även målvärden för tjänstnivåavtal (SLA) för svarstid per modell. Mer information om serviceavtalet för Azure OpenAI-tjänsten finns på sidan serviceavtal (SLA) för onlinetjänster

Område	gpt-4o, 2024-05-13 & gpt-4o, 2024-08-06	gpt-4o-mini, 2024-07-18
Global och etablerad minsta distribution i datazonen	15	15
Global & datazonsetablerade skalningssteg	5	5
Regionalt etablerad minsta distribution	50	25
Regionalt etablerad skalningsökning	50	25
Maximal TPM för indata per PTU	2 500	37,000
Maximal utdata-TPM per PTU	833	12,333
Målvärde för svarstid	25 token per sekund	33 token per sekund

En fullständig lista finns i Azure OpenAI-tjänsten i Azure AI Foundry-portalkalkylatorn.

Kommentar

Globala etablerade distributioner stöds endast för modellerna gpt-4o, 2024-08-06 och gpt-4o-mini, 2024-07-18 just nu. Allokerade distributioner i datazoner stöds endast för gpt-4o-, 2024-08-06, gpt-4o, 2024-05-13 och gpt-4o-mini, 2024-07-18 för närvarande. Mer information om modelltillgänglighet finns i dokumentationen om modeller.

Nyckelbegrepp

Distributionstyper

När du skapar en etablerad distribution i Azure AI Foundry kan distributionstypen i dialogrutan Skapa distribution anges till Global Provisioned-Managed, DataZone Provisioned-Managed eller regional Distributionstyp för etablerad hanterad, beroende på databehandlingsbehoven för den angivna arbetsbelastningen.

När du skapar en etablerad distribution i Azure OpenAI via CLI eller API sku-name kan du ange till GlobalProvisionedManaged, DataZoneProvisionedManagedeller ProvisionedManaged beroende på databehandlingsbehovet för den angivna arbetsbelastningen. Om du vill anpassa Azure CLI-exempelkommandot nedan till en annan distributionstyp uppdaterar du bara 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-4 \
--model-version 0613  \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged

Kvot

Etablerade dataflödesenheter

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. Etablerade dataflödesenheter beviljas till en prenumeration som kvot. Varje kvot är specifik för en region och definierar det maximala antalet PTU:er som kan tilldelas till distributioner i den prenumerationen och regionen.

Modelloberoende kvot

Till skillnad från den TPM-kvot (Token per minut) som används av andra Azure OpenAI-erbjudanden är PTU:er modelloberoende. PTUs kan användas för att distribuera valfri modell/version som stöds i regionen.

För etablerade distributioner visas den nya kvoten i Azure AI Foundry som ett kvotobjekt med namnet Provisioned Managed Throughput Unit. För globala etablerade distributioner visas den nya kvoten i Azure AI Foundry som ett kvotobjekt med namnet Global Provisioned Managed Throughput Unit. För etablerade distributioner i datazonen visas den nya kvoten i Azure AI Foundry som ett kvotobjekt med namnet Data Zone Provisioned Managed Throughput Unit. När du expanderar kvotobjektet i fönstret Foundry Quota (Kvot för gjutning) visas de distributioner som bidrar till användningen av varje kvot.

Hämta PTU-kvot

PTU-kvoten är tillgänglig som standard i många regioner. Om det krävs mer kvot kan kunder begära kvot via länken Förfrågningskvot. Den här länken finns till höger om kvotflikarna för den avsedda etablerade distributionstypen i Azure AI Foundry Formuläret gör att kunden kan begära en ökning av den angivna PTU-kvoten för en viss region. Kunden får ett e-postmeddelande på den inkluderade adressen när begäran har godkänts, vanligtvis inom två arbetsdagar.

PTU-minimum per modell

Den minsta PTU-distribution, ökningar och bearbetningskapacitet som är associerad med varje enhet varierar beroende på modelltyp och version.

Kapacitetstransparens

Azure OpenAI är en mycket eftertraktad tjänst 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:er 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 nödvändig modellkapacitet
• 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. Då tittar vi på önskad modell, version och antal PTU:er. Om kapaciteten inte är tillgänglig dirigeras användarna till en alternativ region.

Information om den nya distributionsupplevelsen finns i kom igång-guiden för Azure OpenAI Provisioned.

API:et för nya 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 lustmodellen, versionen och/eller PTUs kan kunderna också prova följande steg:

• Försök att distribuera med ett 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:et och Azure AI Foundry-upplevelsen överväger kvottillgänglighet i returnerade alternativa regioner för att skapa en distribution.

Fastställa antalet PTU:er som behövs för en arbetsbelastning

PTU:er representerar en mängd modellbearbetningskapacitet. På samma sätt som din dator eller dina databaser förbrukar olika arbetsbelastningar eller begäranden till modellen olika mängder underliggande bearbetningskapacitet. Konverteringen från egenskaper för anropsform (promptstorlek, generationsstorlek och anropsfrekvens) till PTU:er är komplex och icke-linjär. För att förenkla den här processen kan du använda Azure OpenAI-kapacitetskalkylatorn för att ändra storlek på specifika arbetsbelastningsformer.

Några övergripande överväganden:

• Generationer kräver mer kapacitet än uppmaningar
• För GPT-4o- och senare modeller anges TPM per PTU för in- och utdatatoken separat. För äldre modeller är större anrop progressivt dyrare att beräkna. Till exempel kräver 100 anrop av med en 1 000 token-promptstorlek mindre kapacitet än ett anrop med 100 000 token i prompten. Den här nivåindelningen innebär att fördelningen av dessa anropsformer är viktig i det övergripande dataflödet. Trafikmönster med en bred distribution som innehåller vissa stora anrop kan uppleva lägre dataflöde per PTU än en smalare fördelning med samma genomsnittliga storlek på prompt- och slutförandetoken.

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 här 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 standardinstans med betala per användning 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 %.

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

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

429-svaret är inte ett fel, utan 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 OpenAI-klientbiblioteken innehåller inbyggda funktioner för hantering av å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. Detta står i kontrast till betala per användning-distributioner, som har ett anpassat beteende för hastighetsbegränsning baserat på den uppskattade trafikbelastningen. För betala per användning-distributioner kan detta 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 och angivna max_tokens i anropet. För begäranden som innehåller minst 1 024 cachelagrade token subtraheras de cachelagrade token från värdet för prompttoken. 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 i kontinuerlig takt baserat på antalet distribuerade PTU:er.

Kommentar

Anrop accepteras tills användningen når 100 %. Bursts drygt 100 % kan tillåtas under korta perioder, men med tiden är din trafik begränsad till 100 % användning.

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

Antalet samtidiga anrop som du kan uppnå beror på varje anrops form (promptstorlek, max_token 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 antalet samplingstoken som max_token kommer det att acceptera fler begäranden.

Vilka modeller och regioner är tillgängliga för etablerat dataflöde?

Region	gpt-4o, 2024-05-13	gpt-4o, 2024-08-06	gpt-4o-mini, 2024-07-18	gpt-4, 0613	gpt-4, 1106-Preview	gpt-4, 0125-Preview	gpt-4, turbo-2024-04-09	gpt-4-32k, 0613	gpt-35-turbo, 1106	gpt-35-turbo, 0125
australiaeast	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
Brasilien, södra	✅	-	✅	✅	✅	✅	-	✅	✅	-
canadacentral	✅	-	-	✅	-	-	-	✅	-	✅
canadaeast	✅	-	✅	✅	✅	-	✅	-	✅	-
eastus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
eastus2	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
francecentral	✅	✅	✅	✅	✅	✅	-	✅	-	✅
germanywestcentral	✅	-	-	✅	✅	✅	✅	✅	✅	-
Japan, östra	✅	✅	✅	-	✅	✅	✅	-	-	✅
koreacentral	✅	✅	✅	✅	-	-	✅	✅	✅	-
northcentralus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
norwayeast	✅	-	✅	✅	-	✅	-	✅	-	-
polencentral	✅	-	-	✅	✅	✅	✅	✅	✅	✅
southafricanorth	✅	-	-	✅	✅	-	✅	✅	✅	-
USA, södra centrala	✅	-	-	✅	✅	✅	✅	✅	✅	✅
southindia	✅	✅	✅	✅	✅	✅	-	✅	✅	✅
swedencentral	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
switzerlandnorth	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
switzerlandwest	-	-	-	-	-	-	-	-	-	✅
uaenorth	✅	-	-	-	✅	-	-	-	✅	✅
uksouth	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
westus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
westus3	✅	✅	-	✅	✅	✅	✅	✅	✅	✅

Kommentar

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

Nästa steg

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