Resumé Pris pr. token er ikke hele billedet
AWS skriver, at mange sammenligner generative modeller på dollars per million tokens, fordi tallet står på alle prissider og derfor ender i regneark (kilde 3396). Men driftsopgaver handler om udfald: et løst support‑ticket, et færdigt research‑brief eller et korrekt finansresumé (kilde 3396). Blogindlægget deler derfor resultater fra en åben benchmark‑harness, der måler forskelle mellem listepris og reelle udfald på tværs af udvalgte OpenAI‑modeller.
Benchmarken kører samme OpenAI Responses API‑kodesti mod flere backends og modeller. AWS sammenligner tre OpenAI‑familie‑modeller på Amazon Bedrock (gpt‑5.6‑luna, gpt‑5.6‑terra, gpt‑5.6‑sol) med to udbredte, prisoptimerede OpenAI API‑modeller (gpt‑5.4‑mini og gpt‑5.4‑nano) (kilde 3396). Formålet er at vise, hvad et korrekt svar, agentiske forløb og professionelle leverancer faktisk koster i praksis.
Hvad benchmarken måler og hvordan
AWS’ harness, openai‑on‑aws/benchmarks‑openai, afvikler én identisk Responses API‑klient og skifter backend og model‑ID, mens evalueringslogikken holdes konstant (kilde 3396). Det gør det muligt at sammenligne praksisforskelle uden at ændre selve evalueringen.
I den rapporterede opsætning kørte modeller på Amazon Bedrock med reasoning slået fra, mens OpenAI API‑baselines kørte i default‑konfiguration. AWS beskriver det som en sammenligning af praktiske deployments frem for iboende modelkapabilitet, og opfordrer til at gentage testen på egne opgaver før en beslutning (kilde 3396).
Hvad der blev testet
AWS fokuserer på tre spørgsmål: Hvad koster et korrekt svar; hvad koster agentiske forløb målt i turn‑count; og kan modellen levere arbejde, en professionel ville acceptere vurderet på reelle faglige leverancer (kilde 3396). Prøvestørrelserne i materialet spænder fra 48 til 198 items, og små forskelle bør læses som vejledende. AWS anbefaler at køre harnessen på egne workloads (kilde 3396).
AWS’ rapportering fremhæver, at resultater stadig afspejler forskelle i modeller, udbyderinfrastruktur og model‑specifikke valg, selv når evalueringslogikken holdes konstant (kilde 3396). Det er en central ramme for at læse tallene.
Sådan beregnes cost‑per‑outcome
AWS beskriver en simpel metode: For hver benchmark divideres en models totale spend – akkumuleret på både rigtige og forkerte forsøg – med antallet af korrekte svar (kilde 3396). Fejl og retries tæller altså med, som i drift.
AWS peger også på multiplikatorer mellem prisside og udfald: hvor ofte modellen har ret, hvor mange tokens den bruger for at nå frem, og for agentiske workloads hvor mange turns der skal til, fordi hver turn gensender en voksende samtale (kilde 3396).
Fra tokenpris til outcome‑målinger
Snillds manual‑brief anbefaler at skifte fokus fra token‑metrikker til outcome‑KPI’er som first‑time resolution, fejlrate, kundetilfredshed og cost‑per‑resolved‑case, og at medregne omkostninger ved fejlsvar og menneskelige eskalationer i en samlet cost‑per‑outcome (kilde 3397). Det er en styringsramme for at læse AWS’ målinger ind i drift.
Manual‑briefen peger samtidig på praksisgreb som kontekststyring og prompt‑caching med henblik på at reducere unødige tokens og gentagelser i agentiske forløb (kilde 3397). Det knytter an til AWS’ bemærkning om, at turn‑count kan dominere regningen (kilde 3396).
Agent‑harnessens rolle
MarkTechPost beskriver en agent‑harness som koden rundt om modellen: eksekveringsloop, værktøjer, kontekst, state, recovery og verifikation (kilde 3398). Pointen er, at harnessen i sig selv kan påvirke udfaldet væsentligt.
Som illustration anfører artiklen, med henvisning til Terminal‑Bench 2.1, at GPT‑5 løste 35,2 procent af opgaverne i Terminus 2 men 49,6 procent i Codex CLI med identiske weights, hvilket viser afhængigheden af harnessen (kilde 3398). Det understreger også AWS’ tilgang med at holde evalueringslogikken konstant på tværs af backends (kilde 3396).
Implikationer for modelvalg og måling
AWS’ metode adresserer et praktisk spørgsmål: hvad koster korrekthed og agentiske forløb på fakturaen, ikke kun i tokens (kilde 3396). Nøjagtighed, tokenforbrug og turn‑count kan ændre totalen markant i forhold til listeprisen (kilde 3396).
Manual‑briefen fra Snilld lægger op til outcome‑KPI’er og helhedsøkonomi. Det indebærer at logge turn‑count, retries og fejludfald samt at indregne omkostninger ved fejlsvar og eskalationer i budgettet, når man følger en cost‑per‑outcome‑logik (kilde 3397).
Metode og reproducerbarhed i korte træk
AWS angiver, at de fem modeller evalueres gennem samme Responses API‑klient, mens backend og model‑ID skiftes, og evalueringen holdes konstant. De betegner harnessen som open‑source og opfordrer læsere til at køre den på egne opgaver (kilde 3396). For sammenligningens gyldighed er det væsentligt at holde harnessen fast, når modeller sammenlignes (kilder 3396, 3398).
Afgrænsningen er også tydeliggjort: Bedrock‑kørslerne var med reasoning slået fra, OpenAI‑baselines i default‑opsætning, og prøvestørrelserne var små nok til at forskelle skal tolkes vejledende (kilde 3396). AWS fremhæver, at dette er praktiske deployments, ikke en kontrolleret måling af iboende modelkapabilitet (kilde 3396).
Økonomi og afgrænsning
AWS’ formel for cost‑per‑outcome er baseret på total modelspend fordelt på korrekte svar, hvor både rigtige og forkerte forsøg tælles med (kilde 3396). Manual‑briefen anbefaler at udvide regnskabet med menneskelige eskalationer og fejlsvar i driftsøkonomien, så totalen afspejler det reelle outcome‑cost (kilde 3397).
For agentiske forløb bemærker AWS, at “Turn count can dominate the bill” (kilde 3396). Manual‑briefen peger på, at effektiv kontekststyring og caching kan dæmpe unødige tokens og gentagelser, hvilket i praksis kan reducere forbruget pr. turn (kilde 3397).
Begrænsninger og hvad man bør validere
AWS’ materiale fremhæver tre centrale forbehold: konfigurationsforskellen mellem Bedrock og OpenAI‑baselines, små prøvestørrelser samt at resultater afspejler både model og infrastrukturvalg (kilde 3396). Derfor anbefales det at køre harnessen på egne opgaver før indkøb (kilde 3396).
MarkTechPost understreger, at harnessen rummer loop, tools, kontekst, state, recovery og verifikation, og at målinger kan afhænge af denne konstruktion (kilde 3398). Det underbygger at holde harnessen konstant ved sammenligninger og at være eksplicit om ændringer mellem kørseler.
Anbefalet handleplan med kildeangivelse
- Definér repræsentative opgavefamilier og mål succes med outcome‑KPI’er som first‑time resolution, fejlrate, kundetilfredshed og cost‑per‑resolved‑case. (kilde 3397)
- Afvikl openai‑on‑aws/benchmarks‑openai, så kandidater kører via samme Responses API‑kodesti, mens backend og model‑ID skiftes. (kilde 3396)
- Mål tre akser: cost‑per‑outcome, agent‑turns og professionel accept på reelle leverancer. (kilde 3396)
- Log agent‑turns, retries og tokenforbrug pr. turn; indregn omkostninger ved fejlsvar og eskalationer i den samlede økonomi. (kilde 3397)
- Hold harnessen konstant ved sammenligninger, da resultater kan variere med loop, tools og verifikation. (kilde 3398)
- Gentag på egne opgaver før valg af model eller udbyder. (kilde 3396)
Hvad man med fordel kan følge op på
Det er relevant at observere, hvordan agent‑turns påvirker regningen i egne flows, og at dokumentere effekten af ændringer i harnessen. AWS’ opfordring til at reproducere på egen workload er central for robuste valg (kilde 3396). MarkTechPosts gennemgang af harness‑komponenter kan fungere som tjekliste for, hvad der bør holdes fast eller dokumenteres ved ændringer (kilde 3398).
Konklusion Fra tokenpris til mål på udfald
AWS’ benchmark og metode viser, at pris pr. token ikke afspejler driftsøkonomien alene. Med en ensartet Responses API‑kodesti på tværs af backends bliver cost‑per‑outcome, agent‑turns og vurdering af faglige leverancer styrende mål for valg og drift (kilde 3396). Manual‑briefen peger på outcome‑KPI’er og helhedsøkonomi, hvor fejlsvar og eskalationer indgår i beregningerne (kilde 3397). AWS anbefaler at reproducere opsætningen på egne opgaver og træffe valg på dokumenterede udfald (kilde 3396).
