Delen via

Wat is ingerichte doorvoer?

  • Artikel

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 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 ingerichte implementaties zijn beschikbaar in dezelfde Azure OpenAI-resources als alle andere 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. Op dezelfde manier zijn ingerichte implementaties in de gegevenszone ook beschikbaar in dezelfde resources als alle andere implementatietypen, maar kunt u de globale infrastructuur van Azure gebruiken om verkeer dynamisch te routeren naar het datacenter binnen de door Microsoft opgegeven gegevenszone 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 Een ingerichte beheerde doorvoereenheid, een wereldwijd ingerichte beheerde doorvoereenheid of een door de gegevenszone 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 Opgegeven groottecalculator in Azure AI Foundry.
Prompt opslaan in cache Voor ondersteunde modellen worden maximaal 100% van de invoertokens in de cache korting gegeven.

Hoeveel doorvoer 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. Voor de modellen die zijn opgegeven in de onderstaande tabel, telt 1 uitvoertoken als 3 invoertokens voor uw TPM per PTU-limiet. 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 opgegeven modellen om de grootte te vereenvoudigen. Als u inzicht wilt hebben in de impact van uitvoertokens op de TPM per PTU-limiet, gebruikt u het 3-invoertoken tot 1 uitvoertokenverhouding. Zie de Azure OpenAI-capaciteitscalculator voor gedetailleerde informatie over hoe verschillende verhoudingen van invoer- en uitvoertokens van invloed zijn op de doorvoer die uw workload nodig heeft. In de tabel ziet u ook Service Level Agreement (SLA) Latentiedoelwaarden per model. Zie de pagina Service Level Agreements (SLA) voor Online Services voor meer informatie over de SLA voor Azure OpenAI Service

Onderwerp gpt-4o gpt-4o-mini
Minimale implementatie van globale en gegevenszone ingericht 15 15
Ingerichte schaalverhoging voor globale & gegevenszone 5 5
Regionale ingerichte minimumimplementatie 50 25
Verhoging van regionale ingerichte schaal 50 25
INVOER-TPM per PTU 2500 37,000
Latentiedoelwaarde 25 tokens per seconde 33 tokens per seconde

Zie de Azure OpenAI-service in de Azure AI Foundry-portalcalculator voor een volledige lijst.

Notitie

Wereldwijde ingerichte implementaties in een gegevenszone worden momenteel alleen ondersteund voor gpt-4o- en gpt-4o-minimodellen. Raadpleeg de documentatie over modellen voor meer informatie over de beschikbaarheid van modellen.

Belangrijke concepten

Implementatietypen

Wanneer u een ingerichte implementatie maakt in Azure AI Foundry, kan het implementatietype in het dialoogvenster Implementatie maken worden ingesteld op het door Global Provisioned Managed, DataZone Provisioned-Managed of regionaal ingericht beheerde implementatietype, afhankelijk van de gegevensverwerkingsbehoeften voor de opgegeven workload.

Wanneer u een ingerichte implementatie maakt in Azure OpenAI via CLI of API, kunt u deze sku-name instellen GlobalProvisionedManagedop , DataZoneProvisionedManagedof ProvisionedManaged afhankelijk van de gegevensverwerkingsbehoefte voor de opgegeven workload. Als u de onderstaande Azure CLI-voorbeeldopdracht wilt aanpassen aan een ander implementatietype, werkt u de sku-name parameter bij zodat deze overeenkomt met het implementatietype dat u wilt implementeren.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4o \
--model-version 2024-08-06  \
--model-format OpenAI \
--sku-capacity 15 \
--sku-name GlobalProvisionedManaged

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.

Diagram van modelonafhankelijk quotum met één groep PTU's die beschikbaar zijn voor meerdere Azure OpenAI-modellen.

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

Schermopname van de quotumgebruikersinterface voor Azure OpenAI ingericht.

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 quotatabbladen voor het implementatietype in Azure AI Foundry. In 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 Azure AI Foundry-implementatie om realtime informatie te bieden over de beschikbaarheid van capaciteit.

In Azure AI Foundry 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 de capaciteit 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 uw quotum- als 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 modelcapaciteits-API en Azure AI Foundry-ervaring 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 doorvoer naar PTU's kan bij benadering worden gebruikt met behulp van historische tokengebruiksgegevens of schattingen van aanroepen van shape's (invoertokens, uitvoertokens en aanvragen per minuut) zoals beschreven in onze documentatie over prestaties en latentie . 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 implementaties bieden u een toegewezen hoeveelheid modelverwerkingscapaciteit om een bepaald model uit te voeren.

In alle ingerichte implementatietypen, wanneer de capaciteit wordt overschreden, retourneert de API een HTTP-statusfout van 429. 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. Alle ingerichte implementatietypen 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 alle ingerichte implementatietypen 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 ingerichte implementaties gebruiken we een variatie van het lek-bucketalgoritme 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 de prompttokens, minder cacehd-tokens en de opgegeven max_tokens in de aanroep te combineren. Een klant kan maximaal 100% korting ontvangen op hun prompttokens, afhankelijk van de grootte van hun tokens in de cache. 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.

Diagram waarin wordt getoond hoe volgende aanroepen worden toegevoegd aan het 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_tokens parameter, enzovoort). De service blijft aanroepen 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 genereert dan het aantal uitvoertokens dat is ingesteld voor de max_tokens parameter, accepteert de ingerichte implementatie meer aanvragen.

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

Beschikbaarheid van wereldwijd ingerichte beheerde modellen

Regio gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o-mini, 2024-07-18
australiaeast ✅ ✅ ✅
brazilsouth ✅ ✅ ✅
canadacentral ✅ ✅ ✅
canadaeast ✅ ✅ ✅
eastus ✅ ✅ ✅
eastus2 ✅ ✅ ✅
francecentral ✅ ✅ ✅
germanywestcentral ✅ ✅ ✅
japaneast ✅ ✅ ✅
koreacentral ✅ ✅ ✅
northcentralus ✅ ✅ ✅
norwayeast ✅ ✅ ✅
Polencentral ✅ ✅ ✅
southafricanorth ✅ ✅ ✅
US - zuid-centraal ✅ ✅ ✅
southindia ✅ ✅ ✅
spaincentral ✅ ✅ ✅
swedencentral ✅ ✅ ✅
switzerlandnorth ✅ ✅ ✅
zwitserlandwest ✅ ✅ ✅
uaenorth ✅ ✅ ✅
uksouth ✅ ✅ ✅
westeurope ✅ ✅ ✅
westus ✅ ✅ ✅
westus3 ✅ ✅ ✅

Notitie

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

Volgende stappen