Wat is ingerichte doorvoer?

Notitie

De ingerichte Azure OpenAI-aanbieding heeft op 12 augustus 2024 aanzienlijke updates ontvangen, waaronder het afstemmen van het aankoopmodel met Azure-standaarden en het overstappen op modelonafhankelijk quotum. Het wordt ten zeerste aanbevolen dat klanten vóór deze datum de ingerichte update van augustus van Azure OpenAI lezen voor meer informatie over deze wijzigingen.

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 bieden de ingerichte en globale ingerichte implementatietypen?

• 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). Globale implementaties zijn beschikbaar in dezelfde Azure OpenAI-resources als niet-globale implementatietypen, maar u kunt de globale infrastructuur van Azure gebruiken om verkeer dynamisch naar het datacenter te routeren met de beste beschikbaarheid voor elke aanvraag.

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.
Voor wie is het?	Klanten die gegarandeerde doorvoer willen met minimale latentievariantie.
Quotum	Ingerichte beheerde doorvoereenheid of globale ingerichte beheerde doorvoereenheid die per regio is toegewezen. Quota kunnen worden gebruikt voor elk beschikbaar Azure OpenAI-model.
Latentie	Maximale latentie die is beperkt vanuit het model. De algehele latentie is een factor van de aanroepshape.
Gebruik	De meting Ingericht beheerd gebruik V2 die is opgegeven in Azure Monitor.
Grootte schatten	De opgegeven calculator in het script voor studio & benchmarking.

Hoeveel hoewelput per PTU u krijgt voor elk model

De hoeveelheid doorvoer (tokens per minuut of TPM) die een implementatie per PTU ontvangt, is een functie van de invoer- en uitvoertokens in de minuut. Voor het genereren van uitvoertokens is meer verwerking vereist dan invoertokens en hoe meer uitvoertokens de totale TPM lager hebben gegenereerd. De service zorgt voor dynamisch evenwicht tussen de invoer- en uitvoerkosten, zodat gebruikers geen specifieke invoer- en uitvoerlimieten hoeven in te stellen. Deze benadering betekent dat uw implementatie bestand is tegen schommelingen in de workloadshape.

De volgende tabel bevat een overzicht van de TPM per PTU voor de gpt-4o en gpt-4o-mini modellen om de grootte te vereenvoudigen

	gpt-4o, 2024-05-13 & gpt-4o, 2024-08-06	gpt-4o-mini, 2024-07-18
Implementeerbare stappen	50	25
INVOER-TPM per PTU	2500	37,000
UITVOER-TPM per PTU	833	12,333

** Zie de AOAI Studio-calcualator voor een volledige lijst

Belangrijke concepten

Implementatietypen

Wanneer u een ingerichte implementatie maakt in Azure OpenAI Studio, wordt het implementatietype in het dialoogvenster Implementatie maken ingericht en beheerd. Wanneer u een globale, ingerichte beheerde implementatie maakt in Azure Open Studio, wordt het implementatietype in het dialoogvenster Implementatie maken globaal ingericht beheerd.

Wanneer u een ingerichte implementatie maakt in Azure OpenAI via CLI of API, moet u de sku-name instelling ProvisionedManagedinstellen op . Wanneer u een globale ingerichte implementatie maakt in Azure OpenAI via CLI of API, moet u de sku-name instelling instellen op .GlobalProvisionedManaged 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 

Quotum

Ingerichte doorvoereenheden

Ingerichte doorvoereenheden (PTU) zijn algemene eenheden van modelverwerkingscapaciteit die u kunt gebruiken om de grootte van ingerichte implementaties te bepalen om de vereiste doorvoer te bereiken voor verwerkingsprompts en het genereren van voltooiingen. Ingerichte doorvoereenheden worden als quotum aan een abonnement verleend. Elk quotum is specifiek voor een regio en definieert het maximum aantal PTU's dat kan worden toegewezen aan implementaties in dat abonnement en die regio.

Onafhankelijk quotum modelleren

In tegenstelling tot het TPM-quotum (Tokens Per Minute) dat wordt gebruikt door andere Azure OpenAI-aanbiedingen, zijn PTU's modelonafhankelijk. De PTU's kunnen worden gebruikt om elk ondersteund model/elke ondersteunde versie in de regio te implementeren.

Voor ingerichte implementaties wordt het nieuwe quotum weergegeven in Azure OpenAI Studio als een quotumitem met de naam Ingerichte beheerde doorvoereenheid. Voor globale ingerichte beheerde implementaties wordt het nieuwe quotum weergegeven in Azure OpenAI Studio als een quotumitem met de naam Global Provisioned Managed Throughput Unit. In het deelvenster Quota van Studio toont het uitbreiden van het quotumitem de implementaties die bijdragen aan het gebruik van elk quotum.

PTU-quotum verkrijgen

PTU-quotum is standaard beschikbaar in veel regio's. Als er meer quotum is vereist, kunnen klanten quota aanvragen via de koppeling Quotum aanvragen. Deze koppeling vindt u rechts van de ingerichte beheerde doorvoereenheid of quotumtabbladen voor globale ingerichte beheerde doorvoereenheden in Azure OpenAI Studio. Met het formulier kan de klant een verhoging aanvragen van het opgegeven PTU-quotum voor een bepaalde regio. De klant ontvangt een e-mail op het inbegrepen adres zodra de aanvraag is goedgekeurd, meestal binnen twee werkdagen.

PTU-minimum per model

De minimale PTU-implementatie, stappen en verwerkingscapaciteit die aan elke eenheid is gekoppeld, verschilt per modeltype en versie.

Transparantie van capaciteit

Azure OpenAI is een zeer gewilde service waarbij de vraag van klanten de GPU-capaciteit van de service kan overschrijden. Microsoft streeft ernaar om capaciteit te bieden voor alle in-demand regio's en modellen, maar het verkopen van een regio is altijd een mogelijkheid. Deze beperking kan de mogelijkheid van sommige klanten beperken om een implementatie van hun gewenste model, versie of aantal PTU's in een gewenste regio te maken, zelfs als er quota beschikbaar zijn in die regio. Algemeen:

• Quotum plaatst een limiet voor het maximum aantal PTU's dat kan worden geïmplementeerd in een abonnement en regio, en biedt geen garantie voor capaciteitsbeschikbaarheid.
• Capaciteit wordt toegewezen tijdens de implementatie en wordt bewaard zolang de implementatie bestaat. Als de servicecapaciteit niet beschikbaar is, mislukt de implementatie
• Klanten gebruiken realtime informatie over de beschikbaarheid van quota/capaciteit om een geschikte regio te kiezen voor hun scenario met de benodigde modelcapaciteit
• Door een implementatie te verkleinen of te verwijderen, wordt de capaciteit weer naar de regio vrijgegeven. Er is geen garantie dat de capaciteit beschikbaar is als de implementatie later wordt opgeschaald of opnieuw wordt gemaakt.

Richtlijnen voor regionale capaciteit

Als u de capaciteit wilt vinden die nodig is voor hun implementaties, gebruikt u de capaciteits-API of de Studio-implementatie-ervaring om realtime informatie te bieden over de beschikbaarheid van capaciteit.

In Azure OpenAI Studio identificeert de implementatie-ervaring wanneer een regio niet beschikt over de capaciteit die nodig is om het model te implementeren. Hiermee wordt gekeken naar het gewenste model, de versie en het aantal PTU's. Als cpacity niet beschikbaar is, worden gebruikers door de ervaring omleiden naar een alternatieve regio.

Meer informatie over de nieuwe implementatie-ervaring vindt u in de aan de slag met Azure OpenAI Ingericht.

De API voor nieuwe modelcapaciteiten kan worden gebruikt om programmatisch de maximale implementatie van een opgegeven model te identificeren. De API beschouwt zowel het quotum als de servicecapaciteit in de regio.

Als een acceptabele regio niet beschikbaar is om het wensmodel, de versie en/of de PTU's te ondersteunen, kunnen klanten ook de volgende stappen uitvoeren:

• Probeer de implementatie uit te voeren met een kleiner aantal PTU's.
• Probeer de implementatie op een ander moment uit te proberen. Capaciteitsbeschikbaarheid verandert dynamisch op basis van de vraag van klanten en er kunnen later meer capaciteit beschikbaar komen.
• Zorg ervoor dat het quotum beschikbaar is in alle acceptabele regio's. De API en Studio-ervaring voor modelcapaciteiten houden rekening met de beschikbaarheid van quota in het retourneren van alternatieve regio's voor het maken van een implementatie.

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 de kenmerken van oproepshapes (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
• Voor GPT-4o- en latere modellen is de TPM per PTU afzonderlijk ingesteld voor invoer- en uitvoertokens. Voor oudere modellen zijn grotere aanroepen geleidelijk duurder om te berekenen. Voor 100 aanroepen met een promptgrootte van 1000 token is bijvoorbeeld minder capaciteit nodig dan één aanroep met 100.000 tokens in de prompt. Deze lagen betekenen dat de distributie van deze aanroepshapes belangrijk is in de totale doorvoer. Verkeerspatronen met een brede distributie met enkele 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 en globale ingerichte implementaties bieden u een toegewezen hoeveelheid modelverwerkingscapaciteit om een bepaald model uit te voeren.

Wanneer de capaciteit wordt overschreden, retourneert de API een HTTP-statusfout van 429 wanneer de capaciteit wordt overschreden. Met deze snelle reactie 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 HTTP-statuscode 429 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 en globale, door inrichting 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 ingerichte en global provisioned managed-aanbiedingen wordt elke aanvraag afzonderlijk geëvalueerd op basis van de promptgrootte, de verwachte generatiegrootte en het model om het verwachte gebruik 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 leiden tot HTTP 429-fouten die worden gegenereerd voordat gedefinieerde quotumwaarden worden overschreden als verkeer niet gelijkmatig wordt gedistribueerd.

Voor ingericht en globaal ingericht beheerd 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 in korte perioden toegestaan, maar na verloop van tijd is 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.

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-4o, 2024-08-06	gpt-4o-mini, 2024-07-18	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-4 versie: turbo-2024-04-09 is momenteel beperkt tot alleen tekst.

Volgende stappen

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