Vad är etablerat dataflöde?
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 den etablerade distributionstypen?
- 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).
Kommentar
PTU-kvoten (provisioned throughput unit) skiljer sig från standardkvoten i Azure OpenAI och är inte tillgänglig som standard. Om du vill veta mer om det här erbjudandet kontaktar du ditt Microsoft-kontoteam.
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 till för? | Kunder som vill ha garanterat dataflöde med minimal svarstidsavvikelse. |
| Säljbudget | Enheter för etablerat hanterat dataflöde för en viss modell. |
| 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 som anges i Azure Monitor. |
| Beräkna storlek | Tillhandahållen kalkylator i studio- och benchmarking-skriptet. |
Hur gör jag för att få åtkomst till Etablerad?
Du måste tala med ditt Microsoft-sälj-/kontoteam för att hämta etablerat dataflöde. Om du inte har ett sälj-/kontoteam kan du tyvärr inte köpa etablerat dataflöde just nu.
Nyckelbegrepp
Etablerade dataflödesenheter
Etablerade dataflödesenheter (PTU) är enheter för modellbearbetningskapacitet som du kan reservera och distribuera för att bearbeta frågor och generera slutföranden. Den minsta PTU-distribution, ökningar och bearbetningskapacitet som är associerad med varje enhet varierar beroende på modelltyp och version.
Distributionstyper
När du distribuerar en modell i Azure OpenAI måste du ange att den sku-name ska vara Etablerad-hanterad. 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
Säljbudget
Etablerad dataflödeskvot representerar en viss mängd totalt dataflöde som du kan distribuera. Kvoten i Azure OpenAI-tjänsten hanteras på prenumerationsnivå. Alla Azure OpenAI-resurser inom prenumerationen delar den här kvoten.
Kvoten anges i etablerade dataflödesenheter och är specifik för en trilling (distributionstyp, modell, region). Kvoten är inte utbytbar. Det innebär att du inte kan använda kvoten för GPT-4 för att distribuera GPT-35-turbo. Du kan skapa en supportbegäran om att flytta kvoten mellan distributionstyper, modeller eller regioner, men växlingen är inte garanterad.
Vi gör varje försök att se till att kvoten kan distribueras, men kvoten representerar inte en garanti för att den underliggande kapaciteten är tillgänglig. Tjänsten tilldelar kapacitet under distributionsåtgärden och om kapaciteten inte är tillgänglig misslyckas distributionen med ett fel med out-of-capacity.
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 anropsformegenskaper (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 med en storlek på 1 000 tokenprompter mindre kapacitet än 1 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 några 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ändningsframtvingande
Etablerade distributioner ger dig en allokerad mängd modellbearbetningskapacitet för att köra en viss modell. Måttet Provisioned-Managed Utilization i Azure Monitor mäter en viss distributionsanvändning i steg om 1 minut. Etableringshanterade distributioner ä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). När arbetsbelastningen överskrider den allokerade PTU-kapaciteten returnerar tjänsten en 429 HTTP-statuskod 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, 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.
- 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?
Vi använder 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:
Varje kund har en viss mängd kapacitet som de kan använda i en distribution
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-mshuvudet 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_tokensi anropet. Om parameternmax_tokensinte 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 attmax_tokensvärdet ligger så nära den verkliga generationsstorleken som möjligt.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.
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% kanske tillåts 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.