Beregning og forudsigelse af API-omkostninger

API-omkostninger for LLM-applikationer kan blive overraskende store i stor skala. En enkelt forespørgsel, der virker billig til $0,002, bliver til $200, når den køres 100.000 gange. Uden omkostningsforudsigelse og overvågning kan AI-funktioner generere uventede cloudregninger, der overstiger hele din infrastrukturudgift.

Den gode nyhed er, at LLM-omkostninger kan forudsiges fuldstændigt, før du sender en forespørgsel: Du kender modellen, du kan tælle inputtokens med tiktoken, og du kan estimere outputtokens ud fra din indstilling af max_tokens eller historiske gennemsnit. Hvis du indbygger omkostningsforudsigelse i din applikation fra starten, undgår du overraskelser på regningen.

OpenAI opkræver separat betaling for inputtokens og outputtokens, hvor output typisk koster 3-4 gange mere. Priserne varierer fra model til model. Som vejledning for 2025 (tjek altid den aktuelle prisside, da priserne ændrer sig):

• gpt-4o-mini: cirka $0,15 pr. million inputtokens, cirka $0,60 pr. million outputtokens
• gpt-4o: cirka $2,50 pr. million inputtokens, cirka $10,00 pr. million outputtokens
• text-embedding-3-small: cirka $0,02 pr. million tokens

Prisforskellen mellem modellerne er enorm: gpt-4o er cirka 17 gange dyrere end gpt-4o-mini pr. inputtoken. Valg af model er dit vigtigste middel til omkostningskontrol — start altid med den billigste model, der opfylder dine kvalitetskrav.

Byg en omkostningsestimator, som du kalder, før du sender en forespørgsel. Den tæller inputtokens med tiktoken, estimerer outputtokens ud fra din max_tokens-parameter, slår prisen pr. model op og returnerer den estimerede pris i dollars. Kald den under udviklingen, og log resultaterne, så du opbygger en fornemmelse for, hvad forskellige typer forespørgsler koster.

Efter hvert API-kald indeholder svarobjektet de faktiske antal tokens, der blev brugt. Udtræk disse oplysninger for at logge de reelle omkostninger og sammenligne dem med dine estimater. Med tiden viser forskellen mellem estimerede og faktiske outputtokens, hvor præcist du forudsiger forbruget, og loggene giver dig en omkostningsopdeling efter funktion eller brugersegment.

Når du kender den gennemsnitlige pris pr. forespørgsel og det forventede antal forespørgsler, er det enkelt at fremskrive de månedlige omkostninger. Byg et regneark med en omkostningsmodel eller et enkelt Python-script, som lader dig afprøve forskellige antagelser: Hvad hvis antallet af dagligt aktive brugere fordobles? Hvad hvis vi tilføjer en funktion, der foretager 3 API-kald pr. brugerhandling i stedet for 1?

Det vigtigste middel til at reducere omkostningerne er at bruge den billigste model, der opfylder dit kvalitetskrav. Til mange opgaver klarer gpt-4o-mini sig omtrent lige så godt som gpt-4o, men til cirka 17 gange lavere pris. Før du vælger den kraftigste model som standard, skal du måle den billigere model på din specifikke opgave og kun skifte til den dyrere, hvis kvaliteten falder under din grænse.

En strategi med niveaudelt routing er endnu mere effektiv: Klassificér indgående forespørgsler efter kompleksitet, og send enkle forespørgsler til billige modeller og komplekse forespørgsler til dyre modeller. Selv hvis du sender 70 % af trafikken til den billige model og 30 % til den dyre, sparer du cirka 70 % af dine AI-omkostninger.

Hver token i din prompt koster penge. En udførlig systemprompt, der kunne forkortes uden at miste betydning, øger direkte din API-regning for hver forespørgsel. Mål antallet af tokens i dine prompts, og se efter muligheder for at gøre formuleringerne mere kompakte. På samme måde kan lange few-shot-eksempler ofte erstattes af kortere ækvivalenter uden at gå på kompromis med nøjagtigheden.

I RAG-systemer udgør den hentede kontekst ofte den største del af prompten. Hvis du returnerer 10 store tekststykker, selv om 3 velvalgte, mindre stykker ville være nok, spilder du tokens ved hver forespørgsel. Juster din hentning, så overflødig kontekst minimeres, samtidig med at relevansen maksimeres.

OpenAI tilbyder en Batch API, der behandler forespørgsler asynkront til 50 % af standardprisen. Hvis dit anvendelsesområde ikke er følsomt over for svartid — dokumentbehandling, natlige analysejob eller masseproduktion af indhold — kan Batch API halvere dine omkostninger med minimale kodeændringer.

Batchforespørgsler indsendes som JSONL-filer, behandles inden for 24 timer, og resultaterne hentes fra API'et. Det er ideelt til forbehandlingspipelines, der kører efter en tidsplan og ikke har brug for svar i realtid.

Konfigurer altid forbrugsgrænser for at forhindre løbske omkostninger. I OpenAI-dashboardet kan du angive månedlige forbrugslofter, der afbryder API-adgangen, når grænsen nås. Sæt en hård grænse ved det maksimale beløb, du vil acceptere at bruge, og en blød grænse ved 80 % af dette beløb, så du modtager en advarsel via e-mail, før den hårde grænse nås.

Implementer i din programkode et budget pr. bruger eller funktion, som spores i din database. Kontroller budgettet før hvert API-kald, og returner en fejl, hvis det er opbrugt. Det forhindrer, at en enkelt løbsk bruger eller en fejl i et batchjob bruger hele din månedlige kvote på få timer.

Det billigste API-kald er det, du aldrig foretager. Implementer caching på applikationslaget, så identiske forespørgsler kan besvares fra cachen i stedet for at kalde API'et igen. Selv en simpel Redis-cache, der bruger SHA256-hashen af prompten som nøgle, kan eliminere en betydelig andel af overflødige kald i en produktionsapplikation.

For embeddings har caching særlig stor effekt: Den samme tekst bør kun konverteres til en embedding én gang. Gem embeddings i din vektordatabase med den oprindelige tekst som nøgle, og undersøg, om der allerede findes en embedding, før du kalder embeddings-API'et. I en RAG-pipeline beregnes dokumentembeddings én gang ved indeksering og genbruges for hver forespørgsel, der henter dem.

I produktion har du brug for overblik over dine AI-omkostninger fordelt på funktion, bruger og model. Opbyg et omkostningsdashboard ved at logge tokenantallet og de tilknyttede metadata (bruger-id, funktionsnavn og model) for hvert API-kald i en tidsseriedatabase. Aggreger derefter dataene for at besvare spørgsmål som: Hvilken funktion står for det største forbrug? Skaber storforbrugere uforholdsmæssigt høje omkostninger? Stiger omkostningen pr. forespørgsel efter en ændring af en prompt?

Dette overblik er afgørende for at kunne træffe datadrevne optimeringsbeslutninger i stedet for at gætte på, hvor omkostningerne skal reduceres. De fleste virksomheder opdager, at 20 % af deres funktioner står for 80 % af deres AI-forbrug, og at optimering af disse funktioner har en uforholdsmæssigt stor effekt.

I denne lektion har du lært, at API-omkostninger kan forudsiges, før du sender en forespørgsel, ved at tælle inputtokens med tiktoken og estimere outputtokens, at valg af model er den vigtigste omkostningsfaktor — gpt-4o-mini kan være 17 gange billigere end gpt-4o til passende opgaver, og at caching, batchbehandling og forbrugsgrænser forhindrer løbske omkostninger i produktion. Nu ser vi på strategier til håndtering af lange samtaler, der overskrider kontekstvinduet.