Hvad AI koster i drift

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, og 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, og 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, men i praksis er det næsten altid det lange input der fylder på regningen, altså systemprompten, produktkataloget og samtalehistorikken.

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 bliver til fem millioner tokens dagligt, bare til systemprompten.

Lad os regne et konkret eksempel igennem.

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

Forbruget fordeler sig sådan her pr. besked.

En typisk samtale er fire beskeder, og input pr. besked er cirka 6.000 tokens som 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, altså cirka 252 millioner ind og 9 millioner ud på en måned.

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, altså 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, og Anthropic satte den ned til omkring 0,25 dollar pr. million tokens i september 2026.

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

• Uden caching890
• Med caching550
• Med caching og lille model til de lette opgaver310

Det kræver tre ting. Den statiske del af prompten skal stå først og den variable til sidst, den statiske del skal være bogstaveligt identisk hver gang, for é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 nok 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, men de fleste opgaver i en webshop er ikke svære.

Skal teksten klassificeres i en af otte kategorier, kan en lille model klare det. Skal et svar trækkes ud af et dokument, ligeså. Skal en produkttekst skrives på baggrund af felter, er en mellemstor model nok rigtig. Skal en kompliceret reklamation vurderes med afvejning af flere hensyn, er det den store.

Det praktiske greb er at dele opgaven op. Lad en lille model afgøre hvilken 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, og flere modeller tager nu en million tokens.

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

Der er to grunde til ikke at fylde vinduet. Det koster, for en million tokens ind ved 3 dollar pr. million er 3 dollar pr. kald. Og det virker dårligere, fordi 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, og det er tyve gange billigere.

Samtalehistorik er det sted hvor det oftest løber løbsk. En lang samtale hvor hele historikken sendes med hver gang, vokser kvadratisk i pris, så 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, og så er RAG det rigtige.

Omkostningen ved RAG er ikke opslaget, for embeddings er meget billige. Den ligger i kompleksiteten: indeksering, opdatering, chunking og 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, hvor 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.

Der er fire poster som ikke står i modelprisen, men som er der alligevel.

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, så 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 og ikke fra et gæt. Kør tyve virkelige eksempler igennem og se det faktiske forbrug.

Gang op med det forventede antal om måneden, og 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, for alle større udbydere kan det, og 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 og 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.

Der er 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, altså cachevenlig promptstruktur og 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, men alle kan vurdere om 40 øre pr. besvaret henvendelse er billigere end et menneske.