Wat is toegewezen doorvoercapaciteit voor Foundry Models?

Momenteel weergeven:Nieuwe foundry-portalversie - Overschakelen naar versie voor de klassieke Foundry-portal

Ingerichte doorvoer is een implementatietype in Microsoft Foundry dat toegewezen doorvoer voor modelverwerking biedt voor uw implementatie. In tegenstelling tot standaardimplementaties, waarbij deductiecapaciteit wordt gedeeld door klanten en doorvoer kan variëren met de vraag, bevat een ingerichte implementatie een vaste hoeveelheid verwerkingscapaciteit uitsluitend voor het gebruik van uw implementatie, ongeacht of er aanvragen worden gedaan.

In dit artikel worden de belangrijkste concepten voor ingerichte doorvoer geïntroduceerd: wat het is, wanneer deze moet worden gebruikt, hoe capaciteit wordt gemeten en gefactureerd en wat u moet weten over quota en capaciteit voordat u implementeert.

Implementatiecategorieën vergeleken

Standaardimplementaties, batchimplementaties, prioriteitsverwerking en ingerichte doorvoer zijn manieren om modellen te implementeren in Microsoft Foundry. De juiste keuze is afhankelijk van uw latentievereisten, verkeerspatronen en kostentolerantie.

Implementatietype Billing Service Level Agreement (SLA) voor latentie Type workload en behoeften
Standard Betaal per token Geen Evenwichtige workloads: ontwikkeling, testen en productie met variabel of onvoorspelbaar verkeer
Prioriteitsverwerking Betalen per token (tarief voor prioriteitslaag) Gedefinieerd latentiedoel per model Latentiegevoelige productieworkloads hebben consistente lage latentie nodig zonder een langetermijnverplichting
Aangeleverd Per PTU per uur (of via Azure-reserveringen) Gedefinieerd latentiedoel per model Bedrijfskritieke, grootschalige productieworkloads vereisen gegarandeerde doorvoer en consistente latentie
Batch Betaal per token (gereduceerd batchtarief) Geen Workloads voor bulkverwerking zonder latentievereisten. Resultaten worden asynchroon geretourneerd.

Wanneer moet u ingerichte doorvoer gebruiken

Ingerichte doorvoer is de juiste keuze wanneer uw toepassing het volgende heeft:

  • Voorspelbare verkeerspatronen: U hebt een redelijke schatting van aanvragen per minuut en tokenvolumes.
  • Latentiegevoelige vereisten: uw gebruikers of downstreamsystemen hebben consistente antwoorden met lage latentie nodig.
  • Volume op productieschaal: toepassingen met een hoge doorvoer waarbij facturatie per token duur wordt.
  • Realtime- of interactieve scenario’s: Chattoepassingen, copilots of agents waarbij wisselende responstijden afbreuk doen aan de gebruikerservaring.

Standaardimplementaties blijven des te beter passen bij ontwikkeling, testen, laag volumegebruik of zeer variabel verkeer, waardoor het lastig is om vooraf een implementatie groot te maken.

Toegewezen doorvoereenheden

Ingerichte doorvoereenheden (PTU's) zijn de maateenheid voor ingerichte doorvoer. Een PTU vertegenwoordigt een vaste hoeveelheid modelverwerkingscapaciteit. Wanneer u een ingerichte implementatie maakt, geeft u op hoeveel PTU's moeten worden toegewezen. Foundry reserveert die hoeveelheid rekenkracht en bewaart deze voor uw implementatie.

Belangrijkste kenmerken van PTU's:

  • Modelonafhankelijk: hetzelfde PTU-quotum kan worden gebruikt om elk ondersteund model te implementeren. Je koopt geen PTU's voor een specifiek model.
  • Regiospecifiek: PTU-quotum wordt verleend per abonnement, per regio en per implementatietype. Quota in VS - oost wordt niet overgezet naar West-Europa.
  • Doorvoer varieert per model: de tokens per minuut (TPM) die een bepaald aantal PTU's leveren, is afhankelijk van het model. Een zwaarder model vereist meer PTU's om dezelfde TPM te bedienen als een lichtere. Zie doorvoerparameters per model voor PTU-naar-TPM-verhoudingen.
  • Minimale implementatiegrootten zijn van toepassing: elk model heeft een minimum aantal PTU's dat is vereist om een implementatie te maken. Minimumwaarden variëren per model en worden weergegeven in implementatieparameters en doorvoerwaarden per model.

Quotum en capaciteit

PTU-quotum en -capaciteit zijn verwante, maar verschillende concepten die beide van invloed zijn op de vraag of u een implementatie kunt aanmaken. In deze sectie wordt uitgelegd wat elk is, hoe u extra quota kunt aanvragen en hoe u kunt controleren of de capaciteit beschikbaar is in uw regio.

Wat is PTU-quotum?

PTU-quotum is het maximum aantal PTU's dat u per abonnement, per regio en per implementatietype kunt implementeren. Quotum is een beleidslimiet die wordt afgedwongen door Azure en heeft geen gekoppelde kosten. Het quotum is gericht op het niveau van de aanbieding (Global Provisioned, Data Zone Provisioned en Regional Provisioned zijn afzonderlijke quotumgroepen) en op regioniveau (quotum in VS - oost is bijvoorbeeld niet van toepassing op Europa - west).

Er wordt een standaardhoeveelheid quotum toegewezen aan in aanmerking komende abonnementen in verschillende regio's.

Wat is capaciteit?

Capaciteit is het daadwerkelijke aantal PTU's per modelversie dat kan worden geïmplementeerd. De capaciteit wordt toegewezen tijdens de implementatie en wordt bewaard voor de levensduur van de implementatie.

Belangrijk

Het PTU-quotum garandeert niet dat de capaciteit beschikbaar is. Als de capaciteit in de regio onvoldoende is voor het aangevraagde aantal PTU's, mislukt de implementatie. Controleer altijd de beschikbaarheid van capaciteit voordat u een implementatie plant of een reservering aanschaft.

Omdat capaciteit een eindige, dynamisch veranderende resource is:

  • Capaciteitsbeschikbaarheid verandert de hele dag op basis van de vraag van klanten in alle regio's en modellen.
  • Als u een implementatie verwijdert of omlaag schaalt, wordt de capaciteit teruggezet naar de regiogroep. Er is geen garantie dat dezelfde capaciteit beschikbaar is als u de implementatie later opnieuw maakt of omhoog schaalt.

Quotum ophalen

Een standaard hoeveelheid aan globale, gegevenszone en regionale ingerichte quota wordt toegewezen aan in aanmerking komende abonnementen in verschillende regio's. U kunt meer quota of capaciteit aanvragen door het aanvraagformulier voor quota in te dienen. Het formulier is ook beschikbaar in de Foundry-portal op de pagina Quota .

Goedkeuring kan enkele dagen duren op basis van de beschikbaarheid van quota en u ontvangt een e-mailmelding wanneer de aanvraag is goedgekeurd.

Beschikbare capaciteit controleren

Beschikbaarheid van realtime capaciteit controleren:

  • Gebruik de implementatie-ervaring van De Foundry-portal, waarmee wordt aangegeven of de capaciteit beschikbaar is wanneer u een implementatie probeert te maken en alternatieve regio's weergeeft met beschikbare capaciteit als uw doelregio niet voldoende heeft.
  • Gebruik de API voor modelcapaciteiten om programmatisch een query uit te voeren op het maximale aantal implementeerbare PTU's voor een bepaald model en een bepaalde regio.

Als uw doelregio geen beschikbare capaciteit heeft:

  • Dien het aanvraagformulier voor het quotum in om meer quota of capaciteit aan te vragen.
  • Probeer te implementeren met minder PTU's.
  • Probeer het later opnieuw, omdat de beschikbaarheid van capaciteit de hele dag dynamisch verandert.

Zie Aan de slag met ingerichte implementaties voor stapsgewijze instructies voor het maken van ingerichte implementaties en het afhandelen van capaciteitsbeperkingen.

Grootte van PTU

Voordat u een ingerichte implementatie maakt, moet u een schatting maken van het aantal PTU's dat uw workload nodig heeft. Drie factoren bepalen de berekening:

  • Aanvraagshape: De verwachte aanvragen per minuut (RPM), de gemiddelde promptgrootte (invoertokens) en de gemiddelde antwoordgrootte (uitvoertokens).
  • Uitvoer-naar-invoerverhouding: voor uitvoertokens is meer verwerkingscapaciteit nodig dan invoertokens. Elk model heeft een verhouding waarmee wordt aangegeven hoeveel invoertokens één uitvoertoken gelijk is aan voor capaciteitsdoeleinden. Voor GPT-4.1 en hoger Azure OpenAI-modellen komt deze verhouding overeen met de globale standaardprijsverhouding van het model tussen uitvoer- en invoertokens. Zie Implementatieparameters en doorvoerwaarden per model voor meer informatie over deze verhouding.
  • Cachesnelheid: het deel van invoertokens dat wordt geleverd vanuit de promptcache. Tokens in de cache verbruiken geen PTU-capaciteit, waardoor een hogere cachesnelheid de vereiste PTU's vermindert.

Bij de dimensioneringsberekening worden deze factoren gebruikt om uw verwachte tokenvolumes om te zetten in één genormaliseerde TPM-waarde, waarna dit wordt gedeeld door de invoer-TPM per PTU van het model om zo het vereiste aantal PTU's te bepalen.

U kunt de grootte handmatig aanpassen met behulp van de formules en waarden per model of de capaciteitscalculator in de Foundry-portal gebruiken voor een begeleide schatting.

Zie PTU-grootte bepalen voor een workload voor de volledige groottemethodologie, inclusief formules, werkvoorbeelden en de referentie voor capaciteitscalculators.

Ingerichte doorvoerimplementatietypen

Ingerichte doorvoercapaciteit is beschikbaar in drie implementatietypen. Ze bieden allemaal toegewezen capaciteit en voorspelbare latentie zodra ze zijn geïmplementeerd. Het verschil is waar uw deductieverkeer wordt verwerkt:

Implementatietype sku-name in CLI Gegevensroutering Ideaal voor
Globaal voorzien GlobalProvisionedManaged Gerouteerd over Azure regio's wereldwijd Hoogste beschikbaarheid; wanneer de routeringsregio niet is beperkt
Gegevenszone geconfigureerd DataZoneProvisionedManaged Blijft binnen een geografische zone (VS of EU) Gegevensresidentie op zoneniveau met hogere beschikbaarheid dan op regionaal niveau
Regionaal geprovisioneerd ProvisionedManaged Blijft in de specifieke Azure regio van de implementatie Strikte vereisten voor dataresidentie binnen één regio

Zie Implementatietypen voor Microsoft Foundry-modellen voor een volledige vergelijking van alle implementatietypen van Foundry, waaronder standaard-, batch- en ingerichte implementaties.

Ondersteunde modellen

Zie Region-beschikbaarheid voor Foundry-modellen die rechtstreeks worden verkocht door Azure voor een volledige lijst met Foundry-modellen die ondersteuning bieden voor ingerichte doorvoer, waaronder welke implementatietypen elk model ondersteunt en regionale beschikbaarheid.

Overloop

Overloop is een optionele configuratie voor het beheren van verkeersschommelingen voor ingerichte implementaties door aanvragen voor overloop automatisch te routeren naar een overeenkomstige standaardimplementatie in dezelfde Foundry-resource. Wanneer een geconfigureerde implementatie volledig wordt benut en niet-200-antwoorden retourneert (zoals een 429 wanneer PTU's zijn uitgeput), leidt spillover die aanvragen om naar de standaardimplementatie, waardoor verstoringen tijdens verkeerspieken worden beperkt.

Alle Azure OpenAI in Foundry-modellen die ondersteuning bieden voor ingerichte doorvoer, bieden ook ondersteuning voor overloop. Foundry Models van andere providers (Azure DeepSeek, Meta Llama) bieden momenteel geen ondersteuning voor overloop.

Overloop kan worden geconfigureerd voor alle aanvragen op een implementatie of beheerd per aanvraag met behulp van de x-ms-spillover-deployment aanvraagheader. Zie Verkeer beheren met overloop voor ingerichte implementaties voor configuratiestappen.

Facturering per uur en Azure reserveringen

Ingerichte implementaties ondersteunen twee factureringsmodi: hourly billing voor flexibel gebruik op korte termijn en Azure Reserveringen voor duurzame productieworkloads tegen een gereduceerd tarief.

Facturering per uur

Alle ingerichte implementatietypen worden gefactureerd tegen een uurtarief ($/PTU/hr) op basis van het aantal geïmplementeerde PTU's, ongeacht het aantal verbruikte tokens. De meter begint wanneer de implementatie wordt gemaakt en stopt wanneer deze wordt verwijderd.

Facturering per uur is praktisch voor scenario's op korte termijn, zoals benchmarking van een nieuw model of tijdelijk opschalen voor een gebeurtenis zoals een hackathon. Het is echter niet de bedoeling om geprovisioneerde implementaties op en af te schalen op basis van het verkeer om facturering per uur te behouden, om de volgende redenen:

  • Capaciteit is mogelijk niet beschikbaar wanneer u weer omhoog moet schalen.

  • Doorlopende facturering per uur bij hoog gebruik overschrijdt doorgaans de reserveringsprijzen.

Raadpleeg Facturering per uur voor volledige richtlijnen over facturering per uur en het schalen van geprovisioneerde implementaties.

Azure-reserveringen

Azure-reserveringen zijn een financiële korting die wordt toegepast op de PTU-factureringsmeter (de teller voor het gebruik per uur waarop Azure kosten in rekening brengt), niet op afzonderlijke implementaties. In ruil voor een verbintenis van 1 maand of 1 jaar krijgt u een verlaagd effectief tarief van $/PTU/hr. Enkele belangrijke aandachtspunten voor reserveringen zijn:

  • Reserveringen worden aangeschaft per implementatietype (globaal, gegevenszone of regionaal) en kunnen worden afgestemd op een of meer abonnementen of resourcegroepen.

  • Reserveringen en implementaties zijn losjes gekoppeld, wat betekent dat u onafhankelijk implementaties en reserveringen maakt.

  • Reserveringen garanderen geen capaciteit. Maak eerst implementaties om te bevestigen dat de capaciteit beschikbaar is en koop vervolgens de reservering om het kortingstarief te vergrendelen.

Zie Azure-reserveringen voor ingerichte doorvoercapaciteit voor volledige richtlijnen over capaciteitsbepaling, aanschaf en het beheren van reserveringen.

Hoe u PTU-kosten en -facturering kunt bijhouden

Gebruik Microsoft Cost Management om uw PTU-gebruiks- en reserveringskosten bij te houden en te analyseren:

Wat u wilt doen? Artikel
Bekijk welk percentage van uw gereserveerde PTU's actief in gebruik is in uw implementaties Gebruik van Azure-reserveringen weergeven
Aankoopgeschiedenis en eventuele restitutieactiviteiten bekijken Bekijk Azure-reserveringsaankoop- en restitutietransacties
Inzicht in de afgeschreven kostenimpact van uw reserveringen voor duidelijker inzicht in facturering per implementatie Afgeschreven batenkosten weergeven
Reserveringskosten verdelen over teams of projecten voor interne kostentoerekening Azure-reserveringskosten terugboeken
Automatische verlenging instellen om het verlopen van reserveringen te voorkomen en het kortingstarief te behouden Automatisch Azure-reserveringen verlengen

Verwante inhoud

  • Last updated on