Tokenprisen styrtdykker – regningen gør ikke
Lad os være ærlige. Pris pr. million tokens er blevet det nye KPI-kæledyr i mange bestyrelseslokaler. Kurven peger nedad. Over 90 procent ned på to år ifølge Unite.ai og gennemgåede prislister hos de store modeludbydere. Alligevel ringer CFO stadig og spørger, hvorfor cloudregningen for AI ikke falder tilsvarende. Den er ikke alene.
Prisfaldet er reelt og vigtigt. Officielle prissider fra OpenAI, Anthropic, Google og Mistral dokumenterer gentagne nedslag i 2024–2026: billigere “omni”/“turbo”-varianter og aggressive priser på mellemstore modeller. Det sænker adgangstærsklen. Men det løser ikke totaløkonomien i enterprise.
Hvad er der egentlig sket med priserne?
På tværs af førende modeller er prisen pr. million tokens faldet kraftigt. Unite.ai beskriver et samlet fald på over 90 procent i perioden, og de offentlige prissider understøtter retningen med konkrete prisrevisioner og nye produktlinjer, som er væsentligt billigere end deres forgængere. Det har gjort det muligt at udskifte dyre proof-of-concepts med billigere, bredere pilots.
Udbydere meldte prisreduktioner i 2024 (og igen i 2025 ifølge prisarkiver), ofte ledsaget af nye kapabiliteter. OpenAI sænkede især ind-prisen på nyere generalmodeller i forhold til de første GPT-4-generationer. Anthropic og Google lagde lignende pres på markedspriserne, og Mistral positionerede mellemstore modeller aggressivt. Den præcise procentsats varierer model for model, men retningen er klar.
Hvorfor falder den samlede regning så ikke
Kort svar: fordi pris pr. token kun er én linje i regnearket. Enterprise-AI koster på mange andre konti. Dataforberedelse. Evaluering og test. Fine-tuning og vedligehold. MLOps og observability. Governance, sikkerhed og compliance. Latency-krav der tvinger dyrere infrastruktur frem. Og så den organisatoriske del: ændringer i processer, træning, support.
Flere brancheanalyser og cloud-dokumentation peger på, at de poster kan dominere TCO, især når brugen går fra prototyper til forretningkritiske flows. Når datasets skal renses, annoteres og holdes ajour. Når der indføres CI/CD for modeller og prompts. Når audit-trails, PII-maskering og DLP bliver krav – ikke valg. Her knækker kurven for mange projekter, og den faldende tokenpris bliver en mindre del af ligningen.
De dyre poster, som sjældent står på slidet
Dataforberedelse og integration: at samle, strukturere, deduplikere og styre dataadgang. Det lyder kedeligt, men slår hårdt på TCO. Ved første produktionstrin ser man ofte engangsarbejde på data, men i praksis bliver det løbende: nye kilder, nye skemaer, nye retention-politikker. Skjulte udgifter opstår, når datakvalitet skaber fejl, som teams efterfølgende “lapper” med mere prompting – der så koster tokens uden at fjerne rodårsagen.
Fine-tuning og evaluering: selv med “billige” adaptere og instruct-tuning er der realtidsomkostninger. Træningskørsler, eval-suiter, human-in-the-loop review og regressionsvagter. Udgiften er ikke bare GPU-timer, men også tooling, datasikkerhed og kvalitetssikring. Når modeller eller prompts opdateres, følger der regressionsarbejde med – hver gang.
MLOps, drift og observability: produktionsassistenten skal have versionsstyring, rollback, feature-flags, cost- og latency-metrikker, alarmer, samt en supportproces. Cloud-dokumentation fra AWS, GCP og Azure angiver eksplicit behov for pipelines, modelregistry, promptversioner og A/B-kontroller. Det er nødvendig infrastruktur, men ikke gratis. Og kun noget af det kan automatiseres.
Governance, sikkerhed og compliance: audit-krav, retention, PII-håndtering, red-teaming, jailbreak-beskyttelse, kontraktuelle SLAs om datasuverænitet. Et særligt dyrt hjørne er krav om regional hosting eller on-prem – her kan den billigste model pludselig ikke bruges, og arkitekturen må laves om.
“Pris pr. token” kan forblænde
Unite.ai’s analyse rammer et ømt punkt: når ledelser stirrer sig blind på prisen pr. million tokens, kan de komme til at ignorere systemets virkelige flaskehalse. Metrikken er lineær og nem at forhandle på, men den beskriver ikke, om løsningen faktisk løser opgaven stabilt inden for SLA, uden at skabe driftsstøj eller compliance-risiko.
Der er modargumenter. For rene retrieval-opsætninger med god caching og stærk promptdisciplin kan en aggressiv fokusering på lave tokenpriser faktisk fungere udmærket. Især i stateless flows med korte svar og lav variation. Men kun så længe andre krav ikke strammer – som personalisering, sporbarhed, sprogvariation eller komplekse beslutningskæder. I praksis presser de fleste produktionsscenarier løsningen væk fra den “enkelte” metrik.
Når billigere tokens alligevel har rykket noget
Det er ikke det samme som, at prisfaldet er ligegyldigt. Det har gjort det væsentligt billigere at lægge intelligens ind, hvor man tidligere ville have brugt regler eller slet ingenting. Offentlige kundecases og leverandørannoncer siden 2024 peger på lavere cost-per-call for simple hjælpefunktioner, kundeservice-triage og kodeassistance. Det er særligt tydeligt i miljøer, hvor man har kunnet bytte en dyr high-end model ud med en mid-size model uden at miste kvalitet i opgaven.
Men så snart opgaven kræver kædning af flere værktøjer, retrieval over større korpora, eller robuste guardrails, begynder de ikke-tokeniserede omkostninger at dominere. Og det er her, de nye orkestreringsprodukter forsøger at hjælpe.
Sakana Fugu som case på cost-aware orkestrering
Sakana AI’s Fugu beskrives ikke som én grundmodel, men som en lært orkestrator, der ruter arbejde på tværs af en pulje af modeller bag en enkelt API. Idéen er enkel: lad en koordinator vurdere opgaven og vælge den billigste model, der stadig løser den tilfredsstillende – og kun kalde dyrere kapabilitet, når det er nødvendigt. Marktechpost dækker de seneste releases, Fugu Max og Fugu Ultra v2, som ifølge beskrivelsen optimerer henholdsvis for “output per dollar” og for maksimal kapabilitet på svære, flertrinsopgaver.
Der er kant. Ifølge den samme dækning leveres Fugu via en hosted, OpenAI-kompatibel API, uden open weights til selv-hosting, og servicen udbydes ikke i EU/EØS. Det er væsentlige enterprise-begrænsninger – både for datasuverænitet, vendor lock-in og driftsarkitektur.
Hvorfor routing overhovedet hjælper i praksis
Model-routing bygger på en simpel observation: mange produktionsforespørgsler er trivielle. Slår noget op. Udtrækker en nøgle. Oversætter en sætning. At sende dem til en stor, dyr model er penge ud af vinduet. En orkestrator, som pålideligt kan sortere i sværhedsgrad og vælge den rigtige “motor”, kan skære en tung del af spildet væk. Og ja, nogle opgaver er sjældent simple – juridisk rådgivning, flersprogede finansresuméer, fejlrobust kodegenerering – men selv dér findes delopgaver, der med fordel kan rutes til billigere komponenter.
Tekniske ledere, der har delt erfaringer offentligt de sidste par år, beskriver typisk besparelser ved at lade 60–80 procent af lette kald lande på en billig model og reservere de tunge kald til en dyrere. De præcise tal afhænger af domæne, kvalitetstærskler og fejlomkostning. Pointen er ikke et magisk procenttal, men at routing flytter omkostningskurven væk fra gennemsnittet.
Implementering gør forskellen
Det lyder nemt at “rute kloge kald rigtigt”. Det er det ikke. Man skal have:
- Observability for prompts, svar, latency og cost på modelniveau – og helst per feature og kunde.
- Eval-suiter, der kan måle kvalitet per opgavetype, ikke kun generelle benchmarks.
- CI/CD for prompts, værktøjsopkald og router-politikker, så ændringer kan rulles frem/tilbage uden at bryde SLA.
- Fallback- og de-escalation-logik, når en billig model fejler, eller når latency stiger.
- Data- og sikkerhedspolitikker, der matcher modelvalget, inklusiv logging, retention og PII-handling.
Hvis det ikke er på plads, risikerer man omvendt at øge TCO: flere kald pga. fejl, længere latency pga. ekstra lag, flere timer på fejlsøgning. Derfor skal governance og drift med ind i kernen af arkitekturen – ikke som en eftertanke.
Hvad skal man måle på i stedet
Tre metrikker bider bedre i praksis end rå tokenpris: cost-per-successful-task, kvalitetsscore per opgavetype og latency-percentiler under SLA. De tre peger samlet på, om løsningen leverer værdi til en bæredygtig pris. Tokenpris er input. Forretning betaler for output, der rent faktisk virker.
Det lyder måske som semantik. Det er det ikke. En lav tokenpris, der kræver to ekstra forsøg, dyrere eskalering og en manuel efterkontrol, vinder sjældent på TCO. Omvendt kan en lidt dyrere model, der rammer rigtigt første gang, være billigst i drift. Det kræver dog, at man måler det – og accepterer, at den “billigste” model ikke altid er billigst.
Begrænsninger, der sjældent står på landingssiden
Hosted orkestrering som Fugu kommer med tydelige tradeoffs: datalokation, leverandørafhængighed og compliance-afklaring. EU/EØS-tilgængelighed er specifikt nævnt som fraværende for Sakana i dækningen. Hvis din datapolitik kræver regional hosting, er det et rødt flag. Derudover kan routing i sig selv introducere performance-overhead. Hver ekstra beslutning tager tid. Det kan æde en del af besparelsen i lave-latency flows.
Vendor mix bliver også sværere at styre kontraktuelt. Hvem har ansvaret ved fejl, når en orkestrator kalder underliggende modeller fra flere udbydere? Bagved ligger der ofte begrænsninger i auditmulighed, især hvis weights ikke er åbne, og hvis logs ikke kan spejles lokalt.
Tre korte råd til beslutningstagere
1. Skift metrik. Mål cost-per-success og latency under SLA pr. use case. Tokenpris er et input, ikke målet i sig selv. Sæt tærskler for kvalitet, ikke kun for kroner pr. million tokens.
2. Invester i data- og driftsgrundlaget før du tuner mere. Få styr på datakilder, adgang, PII-maskering og eval-pipelines. Et solidt eval-setup betaler sig hver uge, fordi du kan skifte modeller og prompts med mindre risiko.
3. Brug routing med omtanke. Start med simple regler og caching. Først når observability og fallback virker, giver det mening at slippe en lært orkestrator løs. Og tjek forretningskrav til region og hosting, før du forelsker dig i en hosted løsning.
Hvad med tal for fordelingen af TCO
Det frister at kræve ét sæt universelle procenter. Men billedet varierer meget på tværs af brancher og modenhed. Offentlige analyser placerer ofte data- og driftsposter som hovedparten af TCO i produktionsopsætninger, med inference som en faldende andel i takt med prisfald. Spændvidden er bred, og metodikken bag opgørelserne er forskellig – nogle medregner personale og change management, andre ikke. Pointen er ikke et bestemt tal, men hvor beslutningerne træffes: i data og drift.
Et lille sidespor, men vigtigt: latency-krav kan vælte budgetter. Når svartider skal under en bestemt grænse, tvinges man ofte til dyrere modeller, kraftigere maskiner eller tættere regioner. Her falder tokenprisens betydning yderligere. Det ses især i kundevendte flows med peak-trafik.
Faldgruber at forvente næste uge
Tre klassikere dukker op i implementering: 1) Uklare kvalitetsmål, så routing “optimerer” mod lav pris, men med flere fejl og re-kald. 2) Mangel på eval-data, så teamet ikke kan påvise, hvornår en billig model er “god nok”. 3) Compliance, der kommer for sent ind, så man må bygge om for at møde audit og regionkrav. Ingen af delene løses ved at presse prisen pr. token endnu 10 procent ned.
Konklusionen er mindre elegant end en smuk graf. Tokenpriser vil sandsynligvis fortsætte ned. Godt. Men enterprise-AI bliver først billigere, når arkitektur, data og drift bærer deres del. Start med at måle rigtigt, få styr på fundamentet, og brug orkestrering, hvor den faktisk flytter bundlinjen. Man opdager først forskellen, når man sidder med det i hænderne.
