AI API-Cost Optimization

Hvad dækker AI API-Cost Optimization?

Færdigheden handler om at få et forbrug af sprogmodeller via API ned i pris, uden at produktet bliver dårligere. Regningen har en enkel form: antal tokens ind gange en pris, plus antal tokens ud gange en pris, for hvert eneste kald. Det svære er at koble beløbet på fakturaen til de linjer kode, der udløser det.

Derfor begynder en person med færdigheden med at måle, ikke med at skære. Vedkommende sørger for, at forbruget kan deles op: egne API-nøgler per team, produkt og miljø, adskilte arbejdsrum (workspaces) og mærkning af det enkelte kald. Både Anthropic og OpenAI har egne endpoints, hvor forbrug og omkostninger kan trækkes ud programmatisk og brydes ned på model, nøgle og arbejdsrum. Ovenpå ligger typisk et sporingslag (tracing), så man kan se prisen på ét enkelt svar og ikke kun på en hel måned. Uden det trin optimerer folk som regel den forkerte del af trafikken.

Selve håndværket består af nogle få mekanismer, som går igen hos alle udbydere.

Genbrug af fast tekst (prompt caching). Systemprompt, værktøjsdefinitioner og baggrundsmateriale sendes med i hvert kald og betales hver gang. Sendes de uændret, kan de genbruges. Anthropic oplyser i sin dokumentation, at læsning fra cache koster 10 procent af den normale inputpris, mens en cache-skrivning med fem minutters levetid koster 25 procent mere end normalt input. OpenAI slår caching til automatisk på nyere modeller. Det lyder nemt, men det er her, de fleste fejler: ligger der et tidsstempel, et bruger-id eller en dato tidligt i prompten, rammer man aldrig cachen. En dygtig person ved, hvor brudpunktet skal placeres, kender mindstelængden for at en prompt overhovedet kan caches, og kan bevise med tallene i svaret, at der faktisk blev læst fra cache.

Asynkron kørsel (batch). Anthropic oplyser 50 procents rabat på al brug gennem Message Batches API, med et behandlingsvindue på op til 24 timer og de fleste batches færdige på under en time. OpenAI har en tilsvarende batch-vej. Alt, der ikke skal svare et menneske med det samme, hører til her: klassificering, berigelse af data, evalueringer, natlige rapporter, engangsoprydning i gammelt indhold. Færdigheden er at kunne se, hvilke dele af trafikken der kan flyttes, uden at brugeren mærker forskel.

Modelvalg og fordeling af kald (routing). De fleste kald i et produkt er rutine. En person med færdigheden bruger den mindste model, der består testen, og sender kun de svære kald videre til den store. Det kræver, at man kan afgøre på forhånd eller undervejs, hvornår et kald er svært, og at man kan måle, om den billige model faktisk holder.

Styring af kontekst og output. Hele samtalehistorikken behøver sjældent at følge med i hvert kald. Det samme gælder lange søgeuddrag og en værktøjsliste, hvor halvdelen aldrig bruges. Konkret arbejde er kortere og skarpere systemprompter, opsummering af ældre samtaleturer, strammere uddrag fra videnbasen, loft over svarlængden og styring af, hvor meget modellen må tænke, før den svarer.

Kontrol over løbske kald. Agenter kalder modellen mange gange per brugerhandling. En løkke, der prøver igen og igen, kan koste mere på én nat end resten af måneden. Færdigheden omfatter budgetlofter, alarmer ved usædvanlige udsving og et loft over antal trin, før noget kører af sporet.

Endelig hører to former for ærlighed med. Den ene er kvalitetssikring: en besparelse, der koster præcision, er ikke en besparelse, og derfor følger et fast testsæt med enhver ændring. Den anden er at kunne sige fra. Er regningen lille, koster udviklingstimerne mere, end der er at hente.

Hvornår er det vigtigt at optimere?

Det bliver først for alvor vigtig, når noget går fra prototype til drift. I prototypen er forbruget usynligt. Når trafikken stiger, vokser regningen lineært, og mange team opdager først, at de bruger flere gange det budgetterede, når fakturaen kommer.

Det er vigtig i produkter, hvor AI er en del af selve leverancen, og hvor prisen per bruger eller per sag afgør, om forretningen hænger sammen. Et abonnement på et fast beløb om måneden kan tabe penge på de mest aktive brugere, hvis ingen har regnet på, hvad et gennemsnitligt forløb koster i tokens.

Det er vigtig i alt agentbaseret. En brugerhandling kan blive til mange modelkald, og historikken sendes med hver gang. Det er den arbejdstype, hvor forskellen mellem en naiv og en gennemtænkt opbygning er størst.

I roller viser det sig typisk hos den, der bygger AI-funktioner i produktet (AI-ingeniør, platform- eller backend-udvikler), hos den, der har ansvaret for cloud- og softwareøkonomi (FinOps-praktiker, cloud economist), og hos en teknisk chef i en mindre virksomhed, der selv skal svare på, hvorfor posten er vokset. Den er også relevant ved indkøb: skal I bruge en leverandørs færdige løsning eller jeres egne API-nøgler, afhænger svaret af de samme beregninger.

Det er derimod sjældent afgørende, hvis I bruger AI gennem færdige værktøjer med fast pris per bruger, eller hvis forbruget er så lille, at det drukner i andre poster. Der er den nyttig at kende, men ikke noget at ansætte efter.

Hvordan lærer man at optimere?

Færdigheden trænes på et rigtigt forbrug med en rigtig regning. Det er hovedpointen, og det er ubehagelig for enhver, der leder efter et kursus. Man kan læse om mekanismerne på en aften. At vide hvilken af dem, der betaler sig i netop denne trafik, kommer af at have prøvet at gætte forkert et par gange.

Grundlaget er udbydernes egen dokumentation. Anthropic og OpenAI beskriver selv, hvordan caching, batch og forbrugsopgørelser fungerer, og siderne opdateres oftere end nogen bog eller video kan følge med til. Priser og modelnavne ændrer sig løbende, så det holdbare er metoden, ikke satserne. Enhver, der lærer feltet, bør vænne sig til at slå den aktuelle pris op frem for at huske den.

En realistisk vej ser sådan ud. Først instrumentering: log tokens ind, tokens ud, cache-læsninger og cache-skrivninger på hvert kald, og gør det muligt at gruppere per funktion. Så en måling af, hvor pengene faktisk ligger, som næsten altid overrasker. Så én ændring ad gangen med et testsæt, der viser, om kvaliteten holder. Og så en gentagelse, når trafikmønsteret ændrer sig, for det gør det.

Af navngivne ting er der især to spor. Det økonomiske og organisatoriske spor har et anerkendt sted: FinOps Foundation, som er en del af Linux Foundation, har en ramme for AI-forbrug og et selvstudieforløb med eksamen, FinOps Certified: AI Value, opdelt i tre niveauer. Den koster 500 dollars ifølge FinOps Foundations egen side og er gyldig i 24 måneder. Der er ingen formelle forudsætninger, men de anbefaler selv en grunduddannelse i FinOps først. Den lærer dig at fordele omkostninger, lave prognoser og styre forbrug på tværs af en organisation. Den lærer dig ikke, hvor et cache-brudpunkt skal sidde.

Det tekniske spor har ingen tilsvarende certificering, og man skal være skeptisk over for dem, der påstår det. Til gengæld findes der værktøjer, det er værd at have arbejdet i: LiteLLM som fælles indgang og fordeling af kald mellem modeller, Langfuse og Helicone til sporing og pris per kald, og OpenTelemetry, hvis I i forvejen har et overvågningssetup, sporene skal ind i. Prøv dem på et projekt, ikke i en øvelse.

Den del, der tager længst tid, er dømmekraften: at kunne mærke, hvornår en besparelse begynder at koste kvalitet, og at turde stoppe der. Den kommer kun af at have brudt noget i produktion og rettet det igen.

Hvordan ved man, om folk kan det?

Spørg om tal frem for om metoder. En person med færdigheden svarer konkret på, hvor stor en del af inputtet der blev læst fra cache sidste måned, og hvordan vedkommende ved det. Kan vedkommende ikke svare, er caching sandsynligvis ikke sat rigtigt op, uanset hvad koden siger.

Gode spørgsmål at stille: Hvad koster jeres dyreste funktion per bruger, og hvordan er det regnet ud? Hvilke opgaver kører I i batch i dag, og hvorfor ikke flere? Hvordan opdager I samme dag, at en agent er kørt i ring? Fortæl om en gang, hvor en billigere model ikke holdt — hvad viste det, og hvad gjorde I? Og: har du nogensinde anbefalet at lade være med at optimere?

Lyt efter, om personen taler i tokens, cache-træfprocent og pris per sag, eller kun i kroner om måneden. Lyt efter, om måling kom før ændringer. Lyt efter, om der er et testsæt med i historien. En erfaren person kender også detaljerne, der driller: at cachen brydes af en enkelt variabel tidligt i prompten, at cache-skrivninger koster ekstra, og at en høj træfprocent i en langsom periode kan skjule et problem i myldretiden.

Advarselstegn er lige så tydelige. Et løfte om en bestemt besparelsesprocent, før nogen har set trafikken, er markedsføring, ikke analyse. Det samme gælder en person, der kun taler om at skifte model eller udbyder, og aldrig om hvordan kaldene er bygget. Vær også opmærksom på den, der har læst alt om emnet, men aldrig har haft ansvar for en regning. Feltet er nyt nok til, at teori og erfaring ligner hinanden på papiret.

En praktisk prøve virker bedre end en samtale. Giv adgang til et anonymiseret udsnit af jeres egne forbrugsdata, og bed om tre forslag med en begrundelse for hver, samt et bud på hvad hvert forslag kan koste i kvalitet. Svaret afslører hurtigt, om personen tænker i jeres trafik eller i en generel tjekliste.