Wat is voorziene doorvoercapaciteit?

Het ingerichte doorvoeraanbod van Azure AI Foundry is een modelimplementatietype waarmee u de hoeveelheid doorvoer kunt opgeven die u nodig hebt in een modelimplementatie. Azure AI Foundry wijst vervolgens de benodigde capaciteit voor modelverwerking toe en zorgt ervoor dat deze gereed is voor u. U kunt de ingerichte doorvoer gebruiken die u hebt aangevraagd voor een divers portfolio met modellen die rechtstreeks door Azure worden verkocht. Deze modellen omvatten Azure OpenAI-modellen en nieuw geïntroduceerde modelfamilies zoals Azure DeepSeek, Azure Grok, Azure Llama en meer in Azure AI Foundry-modellen.

Ingerichte doorvoer biedt:

• Een bredere modelkeuze op de nieuwste vlaggenschipmodellen
• Flexibiliteit om modellen en implementaties te veranderen met een bepaald ingerichte doorvoerquotum
• Aanzienlijke kortingen en de mogelijkheid om uw reserveringsgebruik te verhogen met een flexibelere reserveringskeuze
• Voorspelbare prestaties door stabiele maximale latentie en doorvoer te bieden voor uniforme workloads.
• Toegewezen verwerkingscapaciteit: Een implementatie configureert de hoeveelheid doorvoer. Zodra de doorvoer is ingezet, is deze beschikbaar, ongeacht of hij wordt gebruikt.
• Kostenbesparingen: Workloads met hoge doorvoer kunnen kostenbesparingen bieden ten opzichte van token-gebaseerd verbruik.

Wanneer moet u ingerichte doorvoer gebruiken

Overweeg om over te schakelen van standaardimplementaties naar ingerichte doorvoerimplementaties wanneer u goed gedefinieerde, voorspelbare doorvoer- en latentievereisten hebt. Dit gebeurt meestal wanneer de toepassing gereed is voor productie of al in productie is geïmplementeerd en er een goed begrip is van het verwachte verkeer. Hierdoor kunnen gebruikers de vereiste capaciteit nauwkeurig voorspellen en onverwachte facturering voorkomen. Ingeconfigureerde doorvoercapaciteit is ook handig voor toepassingen met vereisten voor realtime- en latentiegevoeligheid.

Belangrijke concepten

In de volgende secties worden de belangrijkste concepten beschreven waarvan u rekening moet houden bij het gebruik van de ingerichte doorvoeraanbiedingen.

Ingerichte doorvoereenheden (PTU)

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. Ingeregelde doorvoereenheden worden als quotum toegewezen aan een abonnement en gebruikt om de kosten te bepalen. 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.

Kostenbeheer onder gedeelde PTU-reservering

U kunt de PTU-mogelijkheid gebruiken om de kosten voor Foundry-modellen naadloos te beheren onder een gedeelde PTU-reservering. De vereiste PTU-eenheden voor implementatie- en doorvoerprestaties zijn echter dynamisch afgestemd op de gekozen modellen. Zie Inzicht in de kosten van PTU's en modellatentiepunten voor meer informatie over PTU-kosten en modellatentiepunten.

Bestaande PTU-reserveringen worden automatisch bijgewerkt om klanten te voorzien van verbeterde efficiëntie en kostenbesparingen bij het implementeren van Foundry-modellen. Stel dat u een bestaande PTU-reservering hebt waarvoor 500 PTU's zijn gekocht. U gebruikt 300 eenheden voor Azure OpenAI-modellen en u kiest ervoor om ook PTU te gebruiken voor het implementeren van Azure DeepSeek, Azure Llama of andere modellen met PTU-functionaliteit op Foundry-modellen.

• Als u de resterende 200 PTU voor DeepSeek-R1 gebruikt, deelt de 200 PTU de reserveringskorting automatisch en is uw totale gebruik voor de reservering 500 PTU.

• Als u 300 PTU voor DeepSeek-R1 gebruikt, deelt 200 PTU de reserveringskorting automatisch terwijl 100 PTU de reservering overschrijdt en wordt het uurtarief van DeepSeek-R1 in rekening gebracht.

Zie Kosten besparen met ingerichte doorvoerreserveringen van Microsoft Azure AI Foundry voor meer informatie over het besparen van kosten met PTU-reserveringen.

Implementatietypen

Wanneer u een ingerichte implementatie maakt in Azure AI Foundry, kan het implementatietype in het dialoogvenster Implementatie maken worden ingesteld op de globale ingerichte doorvoer, de ingerichte doorvoer van de gegevenszone of het implementatietype Regionale ingerichte doorvoer, afhankelijk van de gegevensverwerkingsbehoeften voor de opgegeven workload.

Wanneer u een ingerichte implementatie maakt in Azure AI Foundry via CLI of API, kunt u de sku-name instellen op GlobalProvisionedManaged, DataZoneProvisionedManaged of ProvisionedManaged afhankelijk van de gegevensverwerkingsbehoefte voor de opgegeven workload.

Als u de volgende 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

Transparantie van capaciteit

De modellen die rechtstreeks door Azure worden verkocht, zijn zeer gewilde services 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 te maken in een gewenste regio, zelfs als er quota beschikbaar zijn in die regio. Algemeen:

• Quotum stelt een limiet in 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. Dit bekijkt het gewenste model, de versie en het aantal PTU's. Als de capaciteit niet beschikbaar is, worden gebruikers door de ervaring omleiden om een alternatieve regio te selecteren.

Meer informatie over de implementatie-ervaring vindt u in de introductiehandleiding voor Azure AI Foundry Provisioned.

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

Als een acceptabele regio niet beschikbaar is ter ondersteuning van het gewenste model, de gewenste versie en/of PTU, 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 bij het aanbieden van alternatieve regio's voor het maken van een implementatie.

Hoe kan ik capaciteit bewaken?

De Provisioned-Managed Utilisatie V2-metriek in Azure Monitor meet de benutting van een gegeven implementatie in intervallen van één minuut. Alle voorziene implementatietypen zijn geoptimaliseerd om ervoor te zorgen dat geaccepteerde oproepen worden verwerkt met een consistente modelverwerkingstijd (de werkelijke end-to-end latentie is afhankelijk van de kenmerken van een oproep).

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 het snelle antwoord kan de gebruiker beslissingen nemen over het beheren van hun verkeer. Gebruikers kunnen aanvragen omleiden naar een afzonderlijke implementatie, naar een standaardimplementatie-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%.

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 AI Foundry-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 ervan te bepalen. Dit gedrag is in tegenstelling tot standaardimplementaties, die een aangepast snelheidsbeperkingsgedrag hebben op basis van de geschatte verkeersbelasting. Voor standaardimplementaties kan dit aangepaste snelheidsbeperkingsgedrag leiden tot HTTP 429-fouten die worden gegenereerd voordat gedefinieerde quotumwaarden worden overschreden als verkeer niet gelijkmatig wordt gedistribueerd.

Voor geconfigureerde implementaties gebruiken we een variatie van het lekbucket-algoritme om het gebruik onder de 100% te houden, terwijl enige pieken in het verkeer worden toegestaan. 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:

   een. 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 verandering in het gebruik die nodig is om de aanvraag te verwerken door de prompt-tokens, exclusief eventuele tokens in de cache, en de opgegeven max_tokens in de oproep 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:

   een. Als de werkelijke > schatting is, wordt het verschil toegevoegd aan het gebruik van de implementatie.

   b. Als de < geschatte waarde werkelijk is, wordt het verschil afgetrokken.

4. Het totale gebruik wordt met een constant tempo verlaagd op basis van het aantal geïmplementeerde PTU's.

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.

Ingerichte doorvoermogelijkheden voor modellen die rechtstreeks door Azure worden verkocht

In deze sectie vindt u Foundry-modellen die ondersteuning bieden voor de voorziene doorvoermogelijkheid. U kunt uw PTU-quotum en PTU-reservering gebruiken voor de modellen die in de tabel worden weergegeven.

De volgende punten zijn enkele belangrijke punten uit de tabel:

• De modelversie is niet opgenomen in deze tabel. Controleer de versie die voor elk model wordt ondersteund wanneer u de implementatieoptie kiest in de Azure AI Foundry-portal.

• De instellingsoptie voor regionaal geconfigureerde doorvoer verschilt per regio.

• Nieuwe modellen die rechtstreeks door Azure worden verkocht, worden eerst gestart met de implementatieoptie voor wereldwijd geprovisioneerde doorvoer. De optie voor de geconfigureerde gegevenszone komt later beschikbaar.

• PTU worden regionaal en naar aanbodtype beheerd. PTU-quotum en eventuele reserveringen moeten zich in de juiste regio en vorm bevinden (Globaal, Gegevenszone, Regionaal) die u wilt gebruiken.

• Overloop is een optionele mogelijkheid waarmee verkeersschommelingen voor ingerichte implementaties worden beheerd. Zie Verkeer beheren met overloop voor ingerichte implementaties voor meer informatie over overloop.

Beschikbaarheid van regio voor voorziene doorvoercapaciteit

Verwante inhoud

• Meer informatie over de onboardingstappen voor ingerichte implementaties
• Beginnershandleiding voor vooraf ingestelde doorvoereenheden (PTU)