Wat is ingerichte doorvoer?

Met de ingerichte doorvoermogelijkheid kunt u de hoeveelheid doorvoer opgeven die u nodig hebt in een implementatie. De service wijst vervolgens de benodigde modelverwerkingscapaciteit toe en zorgt ervoor dat deze gereed is voor u. Doorvoer wordt gedefinieerd in termen van ingerichte doorvoereenheden (PTU). Dit is een genormaliseerde manier om de doorvoer voor uw implementatie weer te geven. Elk modelversiepaar vereist verschillende hoeveelheden PTU om per PTU te implementeren en verschillende hoeveelheden doorvoer per PTU te bieden.

Wat biedt het ingerichte implementatietype?

• Voorspelbare prestaties: stabiele maximale latentie en doorvoer voor uniforme workloads.
• Gereserveerde verwerkingscapaciteit: Een implementatie configureert de hoeveelheid doorvoer. Zodra de doorvoer is geïmplementeerd, is deze beschikbaar, ongeacht of deze wordt gebruikt.
• Kostenbesparingen: workloads met hoge doorvoer kunnen kostenbesparingen bieden ten opzichte van verbruik op basis van tokens.

Een Azure OpenAI-implementatie is een beheereenheid voor een specifiek OpenAI-model. Een implementatie biedt klanttoegang tot een model voor deductie en integreert meer functies, zoals Inhoudsbeheer (zie documentatie over con tentmodus ration).

Notitie

Het ingerichte doorvoereenheidquotum (PTU) verschilt van het standaardquotum in Azure OpenAI en is standaard niet beschikbaar. Neem contact op met uw Microsoft-accountteam voor meer informatie over deze aanbieding.

Wat haalt u op?

Onderwerp	Ingericht
Wat is het?	Biedt gegarandeerde doorvoer in kleinere stappen dan de bestaande ingerichte aanbieding. Implementaties hebben een consistente maximale latentie voor een bepaalde modelversie.
Wie is het voor?	Klanten die gegarandeerde doorvoer willen met minimale latentievariantie.
Target	Door beheerde doorvoereenheden ingericht voor een bepaald model.
Latentie	Maximale latentie die is beperkt vanuit het model. De algehele latentie is een factor van de aanroepshape.
Gebruik	Ingerichte meting voor beheerd gebruik die is opgegeven in Azure Monitor.
Grootte schatten	De opgegeven calculator in het script voor studio & benchmarking.

Hoe kan ik toegang krijgen tot Ingericht?

U moet contact opnemen met uw Microsoft-verkoop-/accountteam om ingerichte doorvoer te verkrijgen. Als u momenteel geen verkoop-/accountteam hebt, kunt u geen ingerichte doorvoer aanschaffen.

Welke modellen en regio's zijn beschikbaar voor ingerichte doorvoer?

Regio	gpt-4, 0613	gpt-4, 1106-Preview	gpt-4, 0125-Preview	gpt-4, turbo-2024-04-09	gpt-4o, 2024-05-13	gpt-4-32k, 0613	gpt-35-turbo, 1106	gpt-35-turbo, 0125
australiaeast	✅	✅	✅	✅	✅	✅	✅	✅
brazilsouth	✅	✅	✅	-	-	✅	✅	-
canadacentral	✅	-	-	-	-	✅	-	✅
canadaeast	✅	✅	-	✅	✅	-	✅	-
eastus	✅	✅	✅	✅	-	✅	✅	✅
eastus2	✅	✅	✅	✅	-	✅	✅	✅
francecentral	✅	✅	✅	-	✅	✅	-	✅
germanywestcentral	✅	✅	✅	✅	-	✅	✅	-
japaneast	-	✅	✅	✅	✅	-	-	✅
koreacentral	✅	-	-	✅	✅	✅	✅	-
northcentralus	✅	✅	✅	✅	-	✅	✅	✅
norwayeast	✅	-	✅	-	-	✅	-	-
Polencentral	✅	✅	✅	-	-	✅	✅	✅
southafricanorth	✅	✅	-	-	-	✅	✅	-
US - zuid-centraal	✅	✅	✅	✅	✅	✅	✅	✅
southindia	✅	✅	✅	-	-	✅	✅	✅
swedencentral	✅	✅	✅	✅	✅	✅	✅	✅
switzerlandnorth	✅	✅	✅	✅	✅	✅	✅	✅
zwitserlandwest	-	-	-	-	-	-	-	✅
uksouth	✅	✅	✅	✅	-	✅	✅	✅
westus	✅	✅	✅	✅	✅	✅	✅	✅
westus3	✅	✅	✅	✅	✅	✅	✅	✅

Notitie

De ingerichte versie van gpt-4versie:turbo-2024-04-09 is momenteel beperkt tot alleen tekst.

Belangrijke concepten

Ingerichte doorvoereenheden

Ingerichte doorvoereenheden (PTU) zijn eenheden van modelverwerkingscapaciteit die u kunt reserveren en implementeren voor verwerkingsprompts en het genereren van voltooiingen. De minimale PTU-implementatie, stappen en verwerkingscapaciteit die aan elke eenheid is gekoppeld, verschilt per modeltype en versie.

Implementatietypen

Bij het implementeren van een model in Azure OpenAI moet u het sku-name instellen op Ingericht beheerd. Hiermee sku-capacity geeft u het aantal PTU's op dat is toegewezen aan de implementatie.

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 

Target

Het ingerichte doorvoerquotum vertegenwoordigt een specifieke hoeveelheid totale doorvoer die u kunt implementeren. Het quotum in de Azure OpenAI-service wordt beheerd op abonnementsniveau. Alle Azure OpenAI-resources binnen het abonnement delen dit quotum.

Het quotum wordt opgegeven in ingerichte doorvoereenheden en is specifiek voor een triplet (implementatietype, model, regio). Het quotum is niet uitwisselbaar. Dit betekent dat u geen quotum voor GPT-4 kunt gebruiken om GPT-3.5-Turbo te implementeren.

Hoewel we elke poging doen om ervoor te zorgen dat het quotum kan worden geïmplementeerd, vertegenwoordigt het quotum geen garantie dat de onderliggende capaciteit beschikbaar is. De service wijst capaciteit toe tijdens de implementatiebewerking en als de capaciteit niet beschikbaar is, mislukt de implementatie met een fout in de capaciteit.

Het aantal PTU's bepalen dat nodig is voor een workload

PTU's vertegenwoordigen een hoeveelheid modelverwerkingscapaciteit. Net als bij uw computer of databases verbruiken verschillende workloads of aanvragen voor het model verschillende hoeveelheden onderliggende verwerkingscapaciteit. De conversie van oproepshapekenmerken (promptgrootte, generatiegrootte en oproepsnelheid) naar PTU's is complex en niet-lineair. Om dit proces te vereenvoudigen, kunt u de Azure OpenAI-capaciteitscalculator gebruiken om de grootte van specifieke workloadshapes te wijzigen.

Enkele aandachtspunten op hoog niveau:

• Generaties vereisen meer capaciteit dan prompts
• Grotere aanroepen zijn geleidelijk duurder om te berekenen. Voor 100 aanroepen met een promptgrootte van 1000 token is bijvoorbeeld minder capaciteit nodig dan 1 aanroep met 100.000 tokens in de prompt. Dit betekent ook dat de distributie van deze aanroepshapes belangrijk is in de totale doorvoer. Verkeerspatronen met een brede distributie met enkele zeer grote aanroepen kunnen een lagere doorvoer per PTU ervaren dan een kleinere distributie met dezelfde gemiddelde prompt- en voltooiingstokengrootten.

Hoe de prestaties van het gebruik werken

Ingerichte implementaties bieden u een toegewezen hoeveelheid modelverwerkingscapaciteit om een bepaald model uit te voeren.

Bij ingerichte beheerde implementaties, wanneer de capaciteit wordt overschreden, retourneert de API onmiddellijk een HTTP-statusfout van 429. Hierdoor kan de gebruiker beslissingen nemen over het beheren van hun verkeer. Gebruikers kunnen aanvragen omleiden naar een afzonderlijke implementatie, naar een standaard betalen per gebruik-exemplaar of een strategie voor opnieuw proberen gebruiken om een bepaalde aanvraag te beheren. De service blijft de 429 HTTP-statuscode retourneren totdat het gebruik lager is dan 100%.

Hoe kan ik capaciteit bewaken?

Met de metrische gegevens voor ingericht beheerd gebruik V2 in Azure Monitor wordt het gebruik van bepaalde implementaties met één minuut berekend. Ingerichte beheerde implementaties zijn geoptimaliseerd om ervoor te zorgen dat geaccepteerde aanroepen worden verwerkt met een consis tentmodus l verwerkingstijd (werkelijke end-to-end latentie is afhankelijk van de kenmerken van een aanroep).

Wat moet ik doen wanneer ik een 429-antwoord ontvang?

Het 429-antwoord is geen fout, maar maakt deel uit van het ontwerp om gebruikers te vertellen dat een bepaalde implementatie op een bepaald moment volledig wordt gebruikt. Door een snel-fail-antwoord te bieden, hebt u controle over het afhandelen van deze situaties op een manier die het beste past bij uw toepassingsvereisten.

De retry-after-ms en retry-after kopteksten in het antwoord geven u de tijd om te wachten voordat de volgende oproep wordt geaccepteerd. Hoe u ervoor kiest om dit antwoord af te handelen, is afhankelijk van uw toepassingsvereisten. Hier volgen enkele overwegingen:

• U kunt het verkeer omleiden naar andere modellen, implementaties of ervaringen. Deze optie is de oplossing met de laagste latentie omdat de actie kan worden uitgevoerd zodra u het 429-signaal ontvangt. Zie deze communitypost voor ideeën over het effectief implementeren van dit patroon.
• Als u in orde bent met langere latenties per aanroep, implementeert u logica voor opnieuw proberen aan de clientzijde. Met deze optie krijgt u de hoogste hoeveelheid doorvoer per PTU. De Azure OpenAI-clientbibliotheken bevatten ingebouwde mogelijkheden voor het afhandelen van nieuwe pogingen.

Hoe bepaalt de service wanneer een 429 moet worden verzonden?

In de aanbieding ingericht beheerd wordt elke aanvraag afzonderlijk geëvalueerd op basis van de promptgrootte, de verwachte generatiegrootte en het model om het verwachte gebruik ervan te bepalen. Dit is in tegenstelling tot implementaties met betalen per gebruik, die een aangepast snelheidsbeperkingsgedrag hebben op basis van de geschatte verkeersbelasting. Voor implementaties met betalen per gebruik kan dit ertoe leiden dat HTTP 429's worden gegenereerd voordat gedefinieerde quotumwaarden worden overschreden als verkeer niet gelijkmatig wordt gedistribueerd.

Voor ingericht-beheerd gebruiken we een variatie van het lekbucketalgoritme om het gebruik onder de 100% te behouden, terwijl er sprake is van burstiviteit in het verkeer. De logica op hoog niveau is als volgt:

1. Elke klant heeft een vaste hoeveelheid capaciteit die ze kunnen gebruiken voor een implementatie

2. Wanneer een aanvraag wordt ingediend:

   a. Wanneer het huidige gebruik hoger is dan 100%, retourneert de service een 429-code waarbij de retry-after-ms header is ingesteld op de tijd totdat het gebruik lager is dan 100%

   b. Anders maakt de service een schatting van de incrementele wijziging in het gebruik dat nodig is om de aanvraag te verwerken door prompttokens en de opgegeven max_tokens in de aanroep te combineren. Als de max_tokens parameter niet is opgegeven, schat de service een waarde. Deze schatting kan leiden tot lagere gelijktijdigheid dan verwacht wanneer het aantal werkelijk gegenereerde tokens klein is. Voor de hoogste gelijktijdigheid moet u ervoor zorgen dat de max_tokens waarde zo dicht mogelijk bij de ware generatiegrootte ligt.

3. Wanneer een aanvraag is voltooid, weten we nu de werkelijke rekenkosten voor de aanroep. Om een nauwkeurige boekhouding te garanderen, corrigeren we het gebruik met behulp van de volgende logica:

   a. Als de werkelijke > schatting is, wordt het verschil toegevoegd aan het gebruik van de implementatie b. Als de werkelijke < geschatte waarde is, wordt het verschil afgetrokken.

4. Het totale gebruik wordt met een doorlopende snelheid afgebroken op basis van het aantal geïmplementeerde PTU's.

Notitie

Oproepen worden geaccepteerd totdat het gebruik 100% bereikt. Bursts van iets meer dan 100% zijn mogelijk toegestaan in korte perioden, maar in de loop van de tijd wordt uw verkeer beperkt tot 100% gebruik.

Hoeveel gelijktijdige aanroepen kan ik hebben voor mijn implementatie?

Het aantal gelijktijdige aanroepen dat u kunt bereiken, is afhankelijk van de shape van elke aanroep (promptgrootte, max_token parameter, enzovoort). De service blijft oproepen accepteren totdat het gebruik 100% bereikt. Als u het geschatte aantal gelijktijdige aanroepen wilt bepalen, kunt u de maximumaanvragen per minuut modelleren voor een bepaalde aanroepshape in de capaciteitscalculator. Als het systeem minder dan het aantal steekproeventokens genereert, zoals max_token, accepteert het meer aanvragen.

Volgende stappen

• Meer informatie over de onboardingstappen voor ingerichte implementaties
• Introductiehandleiding voor ingerichte doorvoereenheden (PTU)