Overzicht van kosten en tokengebruik van de agentoptimizer

De agent optimizer in Foundry Agent Service biedt een gemodelleerde kostenraming voordat u een optimalisatietaak verzendt. Nadat de taak is voltooid, kan het resultaat gemeten tokengebruik bevatten. Gebruik de schatting voor planning en het gemeten gebruik om inzicht te hebben in de modelactiviteit die is opgetreden tijdens de uitvoering.

De vooraf uitgevoerde schatting en het gebruik van tokens na uitvoering dienen verschillende doeleinden. Geen van beide waarden is een bestedingslimiet of een vervanging voor uw Azure factuur.

Kostenraming vooraf uitvoeren voor promptagenten

Voordat u een optimalisatietaak voor promptagenten maakt in de Foundry-portal, ziet u in de beoordelingsstap een kostenraming voor de aangevraagde instellingen. Optimalisatiestromen voor gehoste agents worden momenteel niet weergegeven in deze vooraf uitgevoerde schatting.

De schatting voorspelt modeloproepen en tokenkosten. Als u een schatting aanvraagt, wordt er geen optimalisatietaak gemaakt of worden de modellen aangeroepen. De aanroepaantallen worden berekend op basis van de taakinvoer. De valutawaarden worden gemodelleerd door statische tokenveronderstellingen en referentiemodelprijzen toe te passen op die aanroepaantallen.

In de portal worden drie gemodelleerde valutawaarden weergegeven:

De samenvatting identificeert het aantal kandidaten, het aantal gegevenssetrijen, het aantal evaluatoren en de datum van de referentieprijs. Vouw Uitsplitsing van kosten (geschat) uit om elke fase te controleren.

Invoer voor de schatting

De optimizer berekent het aantal oproepen van de configuratie van de opgeloste taak. In de berekening worden de volgende invoerwaarden gebruikt:

Bij een gegevensset waarnaar wordt verwezen, bepaalt de service eerst het aantal rijen voordat deze een schatting retourneert. Als het aantal niet-lege rijen niet kan worden bepaald, wordt er geen schatting gemaakt op basis van een aangenomen gegevenssetgrootte.

Voor runs voor modelselectie worden in de schatting agentaanroepen niet afzonderlijk geprijsd voor elk model in de zoekruimte. Het geconfigureerde basismodel van de agent wordt gebruikt als dat beschikbaar is. Als dat model niet kan worden opgelost, wordt de prijs van het evaluatiemodel voor de agentlaag gebruikt.

Aannames van statisch token

De schatting scheidt modelactiviteit in lagen, zodat u kunt zien welk deel van de uitvoering bijdraagt aan het totaal. Hierbij worden de volgende statische TokensPerCall aannames gebruikt:

Deze door de service beheerde veronderstellingen kunnen veranderen wanneer de estimator wordt gekalibreerd. Voor elke laag vermenigvuldigt de optimalisator het bereik van het aantal aanroepen met de statische aannames voor prompt- en voltooiingstokens. Vervolgens worden datumreferentieprijzen per 1 miljoen tokens toegepast:

modeled layer cost = calls × ((prompt tokens × input price) + (completion tokens × output price)) / 1,000,000

Het totaal is de som van de lagen die kunnen worden geprijsd. Als een modelprijs of tokenaanname niet beschikbaar is voor een laag, identificeert de schatting de niet-geprijsde laag en sluit deze uit van het totaal.

Wat gebeurt er tijdens een optimalisatieuitvoering

Om inzicht te hebben in de kostenlagen, helpt het om te weten hoe de optimizer elk model achter de schermen gebruikt. Een optimalisatieronde verloopt volgens deze cyclus voor zowel prompt-agents als gehoste agents:

1. Evalueer de basislijn (agent + rechter). De optimizer roept uw agent aan op elke gegevenssetrij om antwoorden te verzamelen. Vervolgens beoordeelt het evaluatiemodel elk antwoord op elke evaluator om basislijnscores vast te stellen.
2. Genereer een kandidaat (reflectie). Het optimalisatiemodel ontvangt de basislijnscores, analyseert zwakke punten en produceert een verbeterde agentconfiguratie. Afhankelijk van het agenttype kan de configuratie herschreven instructies, verfijnde vaardigheden, betere beschrijvingen van hulpprogramma's of een ander model bevatten.
3. Evalueer de kandidaat (agent + rechter). De optimizer laat de agent met de kandidaatconfiguratie draaien op dezelfde rijen in de dataset en scoort de antwoorden.
4. En herhalen maar. Stap 2 tot en met 3 herhalen voor elke extra kandidaat. Elke cyclus voegt nog een ronde reflectie- en evaluatiegesprekken toe.

De drie kostenlagen komen rechtstreeks overeen met deze lus:

• Uw agent uitvoeren — telkens wanneer de agent wordt aangeroepen voor een rij in de dataset (basislijn en elke kandidaat).
• Antwoorden scoren — elke keer dat het evaluatiemodel een antwoord beoordeelt aan de hand van een evaluator.
• Verbeteringen genereren : telkens wanneer het optimalisatiemodel de resultaten weerspiegelt en een nieuwe kandidaat produceert.

Uitgewerkt voorbeeld: uitvoering met 2-max-candidate

In het volgende voorbeeld ziet u hoe de formule van toepassing is op een concrete taakconfiguratie. Alle prijzen zijn alleen ter illustratie.

Taakinstellingen:

Geschatte aantal aanroepen:

De optimizer leidt het aantal aanroepen af van de taakconfiguratie:

De formule toepassen op elke laag:

De optimizer zoekt de datum van de referentie-invoer- en uitvoerprijzen voor elk model op en past de formule toe. De berekening van de agentlaag is bijvoorbeeld:

60 × ((2,000 × <input price>) + (400 × <output price>)) / 1,000,000

Hetzelfde patroon geldt ook voor de beoordelings- en reflectielagen, waarbij elke laag gebruikmaakt van de aannames over tokens en referentieprijzen voor het bijbehorende model. In de portal worden vervolgens alle lagen opgeteld om de waarden Minimum, Geschat en Maximum te produceren die worden weergegeven in de beoordelingsstap .

In een typische 2-kandidaatuitvoering is de weerspiegelingslaag (optimalisatiemodel) verantwoordelijk voor het grootste aandeel van de geschatte kosten, omdat er een geschikter model wordt gebruikt met hogere tarieven per token. De beoordelingslaag is meestal het minst duur, omdat die een kleiner evaluatiemodel gebruikt met een laag aantal tokens per aanroep.

Schattingsveronderstellingen en beperkingen

De schatting is een planningswaarde in plaats van een definitieve kosten omdat het een algoritmeaanroepbudget combineert met gemodelleerd tokengebruik.

• Tokenveronderstellingen zijn gemiddelden voor elke kostenlaag. De werkelijke vraag, reactie, redenering en het aantal tokens in de cache variëren per model en aanvraag.
• Een optimalisatietaak kan vroeg stoppen nadat er geen verdere verbetering is gevonden. Vroeg stoppen kan het werkelijke gebruik onder de geschatte of maximumwaarde verminderen.
• Het gebruik van agents varieert afhankelijk van instructies, gespreksbeurten, de lengte van antwoorden, aanroepen van hulpprogramma's en de uitvoer van hulpprogramma's.
• Referentiemodelprijzen zijn gedateerd en kunnen verschillen van prijzen voor uw abonnement, regio, implementatietype of overeenkomst.
• De schatting bevat geen kosten van externe API's, databases, zoekservices of andere hulpprogramma's die uw agent aanroept.
• De waarde Maximum is geen bestedingslimiet.

Gemeten tokengebruik na uitvoering

Wanneer een optimalisatietaak is voltooid, kan het resultaat ervan gemeten tokengebruik bevatten voor elke fase van de uitvoering. De weergave Tokengebruik kan beschikbaar zijn voor zowel prompt-agent-runs als hosted-agent-runs.

Voor gehoste agents is het uitvoeren van uw agentgebruik alleen beschikbaar wanneer het evaluatievoorbeeld of de tracering van de agent gebruiksgegevens van tokens bevat. Als de gehoste agent geen gebruik rapporteert, laat de portal de agentfase weg in plaats van deze als nul te rapporteren. Het portaal legt het gebruik van scoreantwoorden en verbeteringen genereren afzonderlijk vast wanneer die modelaanroepen gebruik rapporteren.

De weergave kan meerdere rijen bevatten voor het uitvoeren van uw agent wanneer de optimizer meerdere agentmodellen evalueert.

De portal berekent een geschatte kosten op basis van gemeten tokengebruik en referentiemodelprijzen. Selecteer Prijzen weergeven om de prijsbron te bekijken. De schatting is niet het uiteindelijke gefactureerde bedrag.

Een ontbrekende fase of tokenwaarde betekent dat het gebruik niet is gemeten. Dit betekent niet dat de fase nultokens heeft gebruikt of dat er geen kosten in rekening worden gebracht. Sommige gehoste agents en oudere optimalisatietaken bieden mogelijk geen agentgebruik.

Het onderliggende taakresultaat kan meer details bevatten over gecachte tokens en redeneertokens. Tokens in de cache zijn een subset van invoertokens en redeneringstokens vormen een subset van uitvoertokens. Voeg deze subsetwaarden niet toe aan de invoer- of uitvoertotalen.

Modelkosten berekenen op basis van gemeten gebruik

Gemeten tokengebruik is representatiever dan de vooraf uitgevoerde aannames, maar rapporteert tokenaantallen in plaats van het uiteindelijke gefactureerde bedrag. Pas de prijzen voor elke modelrij toe om de modelkosten bij benadering te bepalen:

approximate model cost = ((input tokens × input price) + (output tokens × output price)) / 1,000,000

Als gedetailleerd gebruik een aantal tokens in de cache biedt en het model een afzonderlijke invoersnelheid in de cache heeft, trekt u tokens in de cache af van het invoertotaal en prijst u de in de cache opgeslagen en niet-in de cache geplaatste gedeelten afzonderlijk.

Bereken elke fase en modelrij afzonderlijk en voeg vervolgens de resultaten toe. Als een rij geen model identificeert, kunt u een implementatiespecifieke prijs niet betrouwbaar toepassen op dat gebruik.

Gebruik de tarieven die van toepassing zijn op uw abonnement, regio, implementatietype en factureringsovereenkomst. Zie Azure OpenAI Service prijzen voor gepubliceerde tarieven. Het resultaat sluit nog steeds kosten uit van externe hulpprogramma's en services.

Verwante onderwerpen

• Overzicht van de agent-optimalisator
• Quickstart: Een promptagent optimaliseren
• Quickstart: Een gehoste agent optimaliseren