Kostnad per fullført utfall: fire spaker for billigere AI-agenter i Foundry

En AI-agent er en løkke rundt en modell. Den planlegger, kaller et verktøy, leser svaret, og tenker en runde til. Ett fullført utfall kan fort koste ti eller tjue modellkall før agenten er ferdig. Jeg kjenner flere måle feil tall her: de sammenligner token-pris før og etter en modellbytte, og glemmer at antall runder i løkken kan doble seg samtidig. Regningen går opp selv om prisen per token går ned.

Kostnadsoptimalisering av AI-agenter handler derfor om noe annet enn å presse ned prisen på hvert enkelt kall. Det som betyr noe for bunnlinjen er kostnad per fullført utfall, ikke pris per token. Etter min erfaring er dette den vanligste feilkilden når AI-prosjekter går fra pilot til produksjon uten at noen tar en aktiv beslutning om arkitekturen på nytt.

Prototypens giftige arv

De fleste AI-løsninger starter likt. Man velger den sterkeste modellen som finnes, fyller prompten med alt agenten kanskje trenger, og bekrefter at ideen fungerer. Det er et riktig instinkt i en pilot. Problemet oppstår når pilotens snarveier stille og rolig blir arkitekturen i produksjon, uten at noen bestemte seg for det.

KI-arbeidsbelastninger er ikke like. En enkelt kundeserviceagent blander intensjonsklassifisering, dataekstraksjon, formatering og faktisk flertrinns resonnering, ofte i samme samtale. Jeg vet at 80 prosent av agentens trafikk er enkle klassifiseringsoppgaver. Alt går likevel til samme frontier-modell, fordi ingen tar seg tid til å dele trafikken opp etter kompleksitet. Det holder ikke i lengden.

Det andre problemet er at ett utfall er mange forespørsler. En agent som tar en feil beslutning kaller feil verktøy, prøver å rette opp feilen, og lander gjerne på et svakere svar likevel. Da betaler du to ganger, for feilen og for opprydningen etterpå. 

Microsoft Foundry gir fire spaker for disse avveiningene ved kjøretid. Du kan justere én om gangen, måle effekten mot ditt eget kvalitetsmål, og reversere hvis den ikke holder:

Spak 1: send hver forespørsel til riktig modell og riktig SKU

Prinsippet er enkelt, men sjelden fulgt i praksis: rutinemessige forespørsler skal ikke betale frontier-pris, og komplekse forespørsler skal ikke ofre kvalitet for å spare noen kroner på tokens. Model router i Foundry Models vurderer hver innkommende forespørsel i sanntid og sender den videre til riktig underliggende modell bak ett og samme endepunkt. Jeg skrev om denne ruteren da GPT-5 kom til Foundry, og siden den gang har jeg sett samme mønster bekrefte seg gang på gang: de fleste produksjonssamtaler trenger langt mindre modell enn teamet opprinnelig valgte i pilotfasen.

Deployment-typen er spaken norske team oftest lar stå urørt, og det er synd. Standard-distribusjon dekker de fleste behov med god fleksibilitet. Interaktive opplevelser med krav til jevn responstid kan trenge prioritets prosessering. Agentarbeid med stabilt, høyt volum bør vurdere Provisioned Throughput Units for forutsigbar kostnad, mens bakgrunnsjobber som dokument-klassifisering egner seg godt for Batch. Batch gir opptil 50 prosent lavere kostnad for arbeid som ikke krever umiddelbar respons, og jeg anbefaler det som første stopp for alt av asynkron etterbehandling.

Fine-tuning er den avanserte utgaven av samme spak. Der ruteren velger blant eksisterende modeller, lærer fine-tuning en mindre modell din oppgave, tone eller ditt format godt nok til å matche en større modell på akkurat den jobben. Gevinsten er lavere rate og kortere prompter. Jeg anbefaler det først når atferden er stabil og volumet er høyt nok til at innsatsen faktisk tjener seg inn.

Spak 2: slutt å betale for de samme tokenene to ganger

Agenter er svært cache-vennlige, om man bygger for det. Systeminstruksjoner, verktøyskjemaer og retningslinjer sendes på nytt hver eneste runde. En agent med ti runder betaler for den samme prefiksen ti ganger, med mindre du gjør noe aktivt med det. Prompt caching lar en tidligere prosessert prefiks gjenbrukes i stedet for å prosesseres på nytt. Det gir rabatt på standard-distribusjoner, og opptil 100 prosent rabatt på provisionert-distribusjoner.

Regelen er kort: stabilt innhold først, flyktig innhold sist. Systeminstruksjoner, verktøydefinisjoner og eksempler hører hjemme øverst i prompten. Brukerinput, hentede dokumentbiter og turhistorikk hører hjemme nederst. Caching krever eksakt match på starten av prompten. Et tidsstempel eller et brukernavn plassert øverst ødelegger treffraten for alle kall som følger, og jeg har sett dette være hele forskjellen mellom en cache som fungerer og en som aldri treffer.

Effekten stopper ikke ved selve modellkallet. Et gateway-lag foran Foundry-endepunktene, som AI Gateway i Azure API Management, kan holde sesjonsaffinitet mot samme endepunkt og matche nesten-like forespørsler på tvers av brukere og sesjoner gjennom semantisk caching. Deterministiske verktøyresultater kan i tillegg caches i eget lager, med en TTL tilpasset hvor ofte dataene faktisk endrer seg. Jeg pleier å sette denne TTL-en langt strammere enn utviklerne først foreslår, siden en for lang levetid fort blir en kilde til utdaterte svar. Konteksten her henger sammen med kostnadseksempelet i GPT-5.1-artikkelen, der context caching alene kunne kutte en vesentlig del av regningen.

Spak 3: optimer prompten, deretter agenten

Hvis modellvalg setter raten, setter instruksjonen volumet. Det er også det billigste å rette, fordi det ikke krever noen infrastruktur endring. Det som kutter tokens er stort sett de samme grepene som forbedrer svarene: still oppgaven først i teksten i stedet for å begrave den bakerst i en vegg av kontekst, vær konkret på hva slags output du vil ha, og bruk noen få gode eksempler fremfor lange forklaringer.

Det som hoper seg opp over turer bør holdes under kontroll:

• Oppsummer avsluttede samtaler i stedet for å spille av hele transkripsjonen igjen

• Begrens verktøy definisjoner til det som faktisk er relevant for akkurat denne oppgaven

• Lagre arbeidstilstand eksternt og hent den kun ved behov

Prompt optimizer i Foundry skriver om agentens systeminstruksjoner etter etablerte prinsipper for prompt-engineering, og viser resonnementet bak hver endring slik at du kan styre det og kjøre det på nytt. Agent optimizer i Foundry Agent Service går et hakk videre. Den kjører agenten din mot et datasett med reelle oppgaver, genererer kandidatkonfigurasjoner, skårer dem, og rangerer dem slik at du kan forfremme vinneren. Etter min erfaring er dette steget som overrasker flest team: det finner ofte en enklere modell eller kortere instruksjon som gjør jobben like godt, noe ingen i teamet hadde testet manuelt.

Spak 4: gjør det synlig med observability og evaluering

Du kan ikke justere det du ikke ser, og du kan ikke hevde en besparelse du ikke har målt. Observability i Foundry gir signalene som gjør de tre andre spakene trygge å dra i: input- og output-tokens, cache-treffrate, latens, hvilken modell som faktisk betjente forespørselen, og evalueringsskår som sier om kvaliteten holdt seg oppe. Dette er også temaet jeg dekker mer i dybden i artikkelen om agentobservabilitet i Foundry.

To tall betyr noe her, og det overrasker meg fortsatt hvor ofte team blander dem sammen. Kostnad per forespørsel forteller om den billigere veien fortsatt klarte kvalitetsmålet. Kostnad per fullført utfall forteller hva virksomheten faktisk betalte, på tvers av hver runde og hvert nytt forsøk det tok å komme i mål. En optimalisering som senker det første tallet mens antall runder øker, har gjort ting verre. Bare det andre tallet avslører det, og det er derfor jeg alltid ber kunder legge inn budsjettvarsler og kostnadstagging i Azure før de rører noen annen spak. Har du ikke gjort den øvelsen ennå, er veikartet for Azure AI-kostnadseffektivitet et godt sted å starte.

Sjekkliste: kom i gang denne uken

1. Legg kostnadstagging og budsjettvarsler på Foundry-ressursen din.

2. Aktiver prompt caching, og omorganiser prompten slik at stabilt innhold ligger øverst.

3. Test model router mot to av de mest brukte agent-flytene dine.

4. Kjør prompt optimizer på systeminstruksjonene og sammenlign mot et evalueringsdatasett.

5. Mål kostnad per fullført utfall, ikke bare kostnad per forespørsel.

Slik blir syklusen billigere for hver runde

Ingen av de fire spakene gir en engangsbesparelse. Sammen danner de en syklus som blir billigere og bedre for hver runde. Modell og tilbud avgjør hvor hver forespørsel kjører. Caching senker kostnaden i hver syklus, og det er det som lar deg kjøre syklusen ofte nok til at den betyr noe. Prompt- og agentoptimalisering genererer neste kandidat og tester den mot ditt evalueringssett. Observability forteller deg hvor du står, og om forrige endring faktisk holdt. Jeg har sett denne syklusen kutte kostnad per utfall betraktelig når man først målte riktig tall og deretter justerte én spak om gangen, i stedet for å endre alt samtidig og håpe det beste.

Trenger du hjelp til å sette dette opp i din egen Foundry-ressurs, ta kontakt på kontakt@jas-azure.com.

Les også