Hvad AI koster i drift: regnestykket, ingen viser jer, før regningen kommer

Alt, hvad en sprogmodel læser og skriver, måles i tokens. Et token er omtrent tre fjerdedele af et ord på engelsk og lidt mindre på dansk, fordi danske ord deles oftere op.

Regn med cirka 1,3 tokens pr. dansk ord som tommelfingerregel. En A4-side er omkring 700 tokens. Et gennemsnitligt kundeservicespørgsmål med svar er 300 til 800 tokens i alt.

Der er to priser: en for tokens ind og en for tokens ud. Tokens ud koster typisk tre til fem gange så meget som tokens ind.

Det er vigtigt, fordi det vender intuitionen på hovedet. De fleste tror, at et langt svar er problemet. I praksis er det næsten altid det lange input — systemprompten, produktkataloget, samtalehistorikken — der fylder på regningen.

En assistent med en systemprompt på 4.000 tokens, der bliver sendt med ved hver eneste besked, betaler for de 4.000 tokens hver gang. Tusind samtaler om dagen med fem beskeder i hver: fem millioner tokens dagligt, bare til systemprompten.

Lad os regne et konkret eksempel igennem.

En webshop med 300 kundeservicehenvendelser om dagen. Assistenten skal kunne svare på levering, returnering, produktspørgsmål og ordrestatus.

Systemprompt med retningslinjer og tone: 3.000 tokens. Relevante produkt- og politikuddrag hentet ind: 2.000 tokens. Samtalehistorik, gennemsnitligt: 1.000 tokens. Svar: 250 tokens.

En typisk samtale er fire beskeder. Input pr. besked er cirka 6.000 tokens, og det vokser gennem samtalen. Kald det 28.000 tokens ind og 1.000 ud pr. samtale.

300 samtaler om dagen bliver 8,4 millioner tokens ind og 300.000 ud dagligt. På en måned: cirka 252 millioner ind og 9 millioner ud.

Med en mellemstor model til omkring 3 dollar pr. million ind og 15 dollar pr. million ud lander det på cirka 890 dollar om måneden. Godt 6.000 kroner.

Det er ikke vildt. Men det er heller ikke de 40 kroner, prototypen kostede, og det er tallet, der skal stå i beslutningsgrundlaget.

Nu det interessante. I eksemplet ovenfor er 3.000 af de 6.000 input-tokens den samme systemprompt hver eneste gang.

Prompt-caching betyder, at den del kun betales fuld pris for første gang og derefter til en brøkdel. Hos de store udbydere er cache-læsninger i dag typisk en tiendedel af normal inputpris — Anthropic satte den ned til omkring 0,25 dollar pr. million tokens i september 2026.

I regnestykket ovenfor: flytter 3.000 af 6.000 input-tokens til cache, falder inputregningen med omkring 45 procent. Månedsprisen går fra cirka 890 til cirka 550 dollar. Uden at ændre en eneste linje i, hvad assistenten kan.

Det kræver tre ting. Den statiske del af prompten skal stå først, den variable til sidst. Den statiske del skal være bogstaveligt identisk hver gang — ét ekstra mellemrum, og cachen rammer ikke. Og kaldene skal komme tæt nok på hinanden til, at cachen stadig lever, typisk inden for minutter.

Det er den største enkeltbesparelse, de fleste kan hente, og den bliver sprunget over i ni ud af ti prototyper.

Den anden store post er modelvalget, og her er fejlen næsten altid at bruge for stor en model.

En stor model koster typisk fem til femten gange så meget som den lille i samme familie. Den er bedre til svære opgaver. De fleste opgaver i en webshop er ikke svære.

Skal teksten klassificeres i en af otte kategorier? Lille model. Skal et svar trækkes ud af et dokument? Lille model. Skal en produkttekst skrives på baggrund af felter? Mellem. Skal en kompliceret reklamation vurderes med afvejning af flere hensyn? Stor model.

Det praktiske greb er at dele opgaven. Lad en lille model afgøre, hvad slags spørgsmål der er tale om, og send kun de svære videre til den store. I en typisk kundeserviceopsætning kan 70 til 80 procent klares af den lille.

Mål det i stedet for at gætte. Kør hundrede rigtige henvendelser gennem begge modeller, og få et menneske til at vurdere svarene uden at vide, hvilken model der har skrevet hvad. Som regel er forskellen mindre, end man frygter.

Kontekstvinduer er blevet enorme. Flere modeller tager nu en million tokens.

Det er nyttigt. Det er også en fælde, fordi det gør det let at putte alt ind i stedet for at vælge.

To grunde til ikke at fylde vinduet. Det koster: en million tokens ind ved 3 dollar pr. million er 3 dollar pr. kald. Og det virker dårligere: modeller bliver mindre præcise, når det relevante er begravet i meget irrelevant.

Vi ser bedre svar fra 4.000 velvalgte tokens end fra 100.000 tilfældige. Det er også tyve gange billigere.

Samtalehistorik er det sted, det oftest løber løbsk. En lang samtale, hvor hele historikken sendes med hver gang, vokser kvadratisk i pris. Klip den: behold de sidste par udvekslinger og et kort resumé af resten.

Spørgsmålet kommer hver gang: skal vi bygge RAG, eller kan vi bare sende det hele med?

Regn på det i stedet for at diskutere det.

Er jeres videnbase under omkring 50.000 tokens, og er den den samme for alle spørgsmål, så send den med og cache den. Det er enklere, billigere at bygge og billigere at drive end en vektordatabase.

Er den større, eller ændrer den sig pr. kunde eller pr. produkt, så hent kun det relevante ind. Så er RAG det rigtige.

Omkostningen ved RAG er ikke opslaget — embeddings er meget billige. Den er kompleksiteten: indeksering, opdatering, chunking, kvalitetssikring af hvad der hentes. Det er et system, der skal vedligeholdes.

Den fejl, vi ser oftest, er RAG bygget til et produktkatalog på tredive sider. Det kunne have været én cachet prompt.

Ikke alle svar skal komme med det samme.

Skal I generere produkttekster til 4.000 varer, opsummere ordrer fra i går eller klassificere en måneds henvendelser, er der ingen der venter. De fleste udbydere giver 40 til 50 procent rabat på den slags kørsler, hvis de må tage nogle timer.

Det er gratis penge for enhver opgave, der kan vente til natten.

Modstykket er alt, hvor en kunde sidder og venter. Der betaler I for hastighed, og der giver det til gengæld ikke mening at spare på modellen, hvis det koster svartid.

Fire poster, der ikke står i modelprisen, men som er der.

Fejlede kald og gentagelser. En model, der svarer forkert formateret, og hvor koden prøver igen, betaler to gange. Struktureret output i stedet for at bede om JSON i prosa fjerner det meste af det.

Udviklingsforbruget. Et hold, der bygger og tester i to måneder, bruger ofte mere end den første måned i drift. Læg et beløb ind til det, og sæt et loft på udviklingsnøglerne.

Evaluering. Skal I vide, om ændringer gør svarene bedre, skal I køre en fast prøvesamling igennem ved hver ændring. Det koster tokens hver gang, og det er penge, der er godt givet ud.

Overvågning og logning. Gemmer I alle samtaler for at kunne fejlsøge — og det bør I — er der en lageromkostning og en GDPR-samtale, der følger med.

Sådan gør vi det, og det tager en formiddag.

Estimer tokens pr. handling ud fra en rigtig prototype, ikke fra et gæt. Kør tyve virkelige eksempler, og se det faktiske forbrug.

Gang op med det forventede antal om måneden. Læg tredive procent til, fordi folk bruger det mere end forventet, når det virker.

Regn med og uden caching, så I kan se, hvad optimeringen er værd, før I bygger den.

Sæt et forbrugsloft på nøglen. Alle større udbydere kan det. Det er forskellen mellem en dyr måned og en katastrofe, når nogen sætter en løkke forkert op.

Og mål pr. handling, ikke kun samlet. Pris pr. besvaret henvendelse, pr. genereret tekst, pr. klassificeret ordre. Det er det tal, der kan holdes op mod, hvad opgaven kostede før.

Tre mønstre.

Det første er at bygge færdigt og derefter kigge på prisen. Så er arkitekturen låst, og de billige greb — cachevenlig promptstruktur, den lille model til de lette opgaver — kræver en ombygning.

Det andet er at spare på det forkerte. Vi har set hold bruge en uge på at barbere 200 tokens af en prompt, mens de sendte hele samtalehistorikken med ved hvert kald.

Det tredje er at regne i dollar pr. million tokens uden at oversætte det til pris pr. handling. Ingen kan vurdere, om 3 dollar pr. million er dyrt. Alle kan vurdere, om 40 øre pr. besvaret henvendelse er billigere end et menneske.