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 och globala 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 distributioner är tillgängliga i samma Azure OpenAI-resurser som icke-globala 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.

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 eller global etablerad 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 studio- och benchmarking-skriptet.

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

Region	gpt-4, 0613	gpt-4, 1106-Preview	gpt-4, 0125-Preview	gpt-4, turbo-2024-04-09	gpt-4o, 2024-05-13	gpt-4o, 2024-08-06	gpt-4o-mini, 2024-07-18	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	-	-	-	-	-	-	-	-	-	✅
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.

Nyckelbegrepp

Distributionstyper

När du skapar en etablerad distribution i Azure OpenAI Studio är distributionstypen i dialogrutan Skapa distribution Etablerad-hanterad. När du skapar en global etablerad hanterad distribution i Azure Open Studio är distributionstypen i dialogrutan Skapa distribution Global Provisioned-Managed.

När du skapar en etablerad distribution i Azure OpenAI via CLI eller API måste du ange sku-name till ProvisionedManaged. När du skapar en global etablerad distribution i Azure OpenAI via CLI eller API måste du ange sku-name till GlobalProvisionedManaged. sku-capacity Anger antalet PTU:er som tilldelats distributionen.

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 på regional basis, vilket definierar det maximala antalet PTU:er som kan tilldelas 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 OpenAI Studio som ett kvotobjekt med namnet Provisioned Managed Throughput Unit. För globala etablerade hanterade distributioner visas den nya kvoten i Azure OpenAI Studio som ett kvotobjekt med namnet Global Provisioned Managed Throughput Unit. När du expanderar kvotobjektet i fönstret Studio-kvot 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 ytterligare kvot krävs kan kunderna begära ytterligare kvot via länken Förfrågningskvot till höger om den etablerade enheten för hanterat dataflöde eller kvotobjekt för global etablerad hanterad dataflödesenhet i Azure OpenAI Studio. 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. Detta 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 är inte en garanti för 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

För att hjälpa användarna att hitta den kapacitet som behövs för deras distributioner använder kunderna en ny API- och Studio-upplevelse för att tillhandahålla information i realtid.

I Azure OpenAI Studio identifierar distributionsupplevelsen när en region saknar kapacitet för att stödja önskad modell, version och antal PTU:er, och dirigerar användaren till en alternativ region när det behövs.

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

API:et för nya modellkapaciteter kan också användas för att programmatiskt identifiera den maximala distributionen av en angiven modell som kan skapas i varje region baserat på tillgängligheten för både kvoten i prenumerationen och tjänstkapaciteten 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. Api:et för modellkapaciteter och Studio-upplevelsen överväger kvottillgänglighet för att returnera 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
• Större anrop är 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. Det innebär också att fördelningen av dessa anropsformer är viktig i det övergripande dataflödet. Trafikmönster med en bred distribution som innehåller vissa mycket stora anrop kan uppleva lägre dataflöde per PTU än en smalare fördelning med samma genomsnittliga storlek på token för fråga och slutförande.

Så här fungerar användningsprestanda

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

När kapaciteten överskrids returnerar API:et omedelbart ett 429 HTTP-statusfel i distributioner med etablerad hanterad och global etableringshanterad. Detta 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. Etableringshanterade och globala etablerade hanterade distributioner optimeras 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 erbjudandena Provisioned-Managed och Global Provisioned-Managed 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 Provisioned-Managed och Global Provisioned-Managed 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. 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.

Nästa steg

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