Hvad er tokens i AI? Forstå pris, context length og output

Hvad er tokens i AI?

En token er den mindste tekst-enhed, en sprogmodel (LLM) faktisk arbejder med. Det er ikke et helt dokument og ofte heller ikke et helt ord, men små stykker tekst, som modellen læser, forstår og skriver én efter én.

I AI-sammenhæng betyder token altså:

• et helt ord (“hund”)
• en del af et ord (“program” + “mering”)
• tal (“2024”)
• tegnsætning (“.”, “,”, “?”)
• special tokens (f.eks. markører for start/slut på en chat-besked)

Når du skriver til en AI-model, bliver din tekst først skåret op i tokens. Modellen ser ikke “rigtige ord” som du gør, men en sekvens af token-id’er (tal). Hele prisen, begrænsningen på hvor meget du kan sende ind, og længden på svaret styres af, hvor mange tokens der er i spil.

Det er vigtigt at skelne: Her handler “tokens” om tekst i sprogmodeller, ikke om krypto- eller blockchain-tokens. Hvis du arbejder med webapps, har du måske også mødt auth-tokens til login. Det er noget helt andet end AI-tokens. Hvis du vil have den forskel på plads, kan du kigge på artiklen om at gemme tokens rigtigt i din webapp.

Når du forstår, hvad tokens er, forstår du også:

• hvorfor en bestemt AI-model koster det, den gør
• hvorfor den nogle gange stopper midt i et svar
• hvorfor lange prompts og meget historik pludselig bliver dyrt

Hvordan tokeniserer en AI tekst?

Før modellen kan arbejde med din tekst, skal den “tokenisere” den. Det er processen, hvor tekst bliver opdelt i små bidder og lavet om til tal, som modellen kan forstå.

Et meget brugt overslag er:

• 1 token ≈ 4 tegn på engelsk
• 1.000 tokens ≈ ca. 750 ord almindelig tekst

På dansk kan forholdet variere, især på grund af sammensatte ord som “softwareudviklingskursus”. Hvor engelsk måske ville bruge 3 ord og flere tokens, kan dansk ofte ende som ét langt ord, som tokenizeren skærer lidt anderledes op.

Under motorhjelmen bruges forskellige tokeniseringsmetoder, f.eks.:

• BPE (Byte Pair Encoding)
• WordPiece
• Unigram

De har alle samme idé: meget brugte ord og orddele får deres egne tokens, mens sjældne ord bliver delt op i flere tokens. Du behøver ikke kunne algoritmen. Det vigtigste er at vide, at modellen arbejder i små tekststykker, ikke i hele sætninger eller hele filer.

Eksempel:

Tekst: "Jeg elsker programmering!"
Mulig tokenisering (forenklet):
["Jeg", " elsker", " program", "mering", "!"]

Her er sætningen blevet til 5 tokens. I virkeligheden vil en rigtig tokenizer bruge sine egne regler, men princippet er det samme. Hver token vil senere blive prissat og tælle med i context length.

Input tokens vs. output tokens

Når du bruger en LLM, er der to slags tokens, du skal holde styr på:

• Input tokens – det modellen læser
• Output tokens – det modellen skriver

Input tokens er alle de tokens, du sender ind til modellen i én request. Det er typisk:

• systemprompt (faste instruktioner om rolle, tone, regler)
• din aktuelle prompt eller brugerbesked
• chat-historik (tidligere spørgsmål og svar)
• indsatte dokumenter, kode, e-mails, manualer osv.

Output tokens er de tokens, modellen genererer som svar. Det kan være:

• forklarende tekst
• kode (Python, JavaScript, SQL, osv.)
• opsummeringer
• strukturerede svar (JSON, tabeller osv.)

Vigtigt: Et kort input kan stadig blive dyrt, hvis det udløser et meget langt output. Du kan f.eks. sende en kort prompt:

"Skriv en detaljeret rapport på 10 sider om vores logs."

Her er input-tokens få, men output kan være tusindvis af tokens. Omvendt kan du også have et meget langt input (f.eks. et helt dokument), hvor du kun beder om en kort opsummering. Så er det primært input-delen, der fylder i regningen.

Som udvikler vil du ofte se to tal i logs eller API-respons:

• prompt_tokens (eller input_tokens)
• completion_tokens (eller output_tokens)

Deres sum kaldes typisk total_tokens. Det er det tal, din faktura bygger på.

Sådan påvirker tokens prisen

De fleste LLM-udbydere, f.eks. OpenAI, tager betaling pr. 1 million tokens. Prisstrukturen ser typisk sådan ud:

• én pris for input tokens
• en anden (ofte højere) pris for output tokens
• evt. en meget lavere pris for cachelagret input (genbrug af kontekst)

Et eksempel inspireret af OpenAI’s officielle prisside (tal kan ændre sig over tid):

Andre modelkategorier kan ligge langt højere, f.eks. omkring $32 for input og $64 for output pr. 1 mio. tokens. Pointen er ikke det præcise tal, men forholdet: output er ofte væsentligt dyrere end input.

Prisen regnes typisk sådan:

1. Udbyderen tæller input- og outputtokens i hver request.
2. De ganger med prisen pr. 1.000 eller 1 mio. tokens.
3. De summerer alle kald i løbet af måneden.

Et simpelt regneeksempel:

• du bruger 10.000 input tokens og 20.000 output tokens på en dag
• prisen er $4/mio. for input og $24/mio. for output

Så er dagsprisen:

• Input: 10.000 / 1.000.000 * $4 ≈ $0,04
• Output: 20.000 / 1.000.000 * $24 ≈ $0,48
• I alt ≈ $0,52 for den dag

Det lyder billigt i test. Men hvis du pludselig kører 200.000 kald om dagen, eller output bliver dobbelt så langt, vokser beløbet hurtigt. Derfor er det vigtigt at designe prompts og arkitektur med tokenforbrug for øje, ikke først kigge på det, når fakturaen ligger i indbakken.

Bemærk også at nogle udbydere har særregler, f.eks. at “søgeindholdstokens er gratis”, og at priser kan være forskellige ved meget lange kontekster (over f.eks. 270K tokens). Læs altid den officielle prisside for den model, du bruger.

Hvis du bygger egne integrationer, er det også værd at se på hvordan du håndterer API-nøgler og styring af forbrug. Der er gode pointer i artikler som gemmer du også dine API-nøgler det forkerte sted og logs vs. mavefornemmelse.

Hvad betyder context length eller context window?

Context length (eller context window) er den maksimale mængde tokens, en model kan have “i hovedet” på én gang i en request eller en samtale.

Alt dette tæller med i context length:

• systemprompt (faste regler)
• hele chat-historikken, du sender med
• brugerens aktuelle besked
• indsatte dokumenter, kode, logs, osv.
• modellen eget genererede output i samme svar

Hvis modellen f.eks. har en context length på 8.000 tokens, kan summen af input- og outputtokens i et enkelt kald ikke overstige de 8.000. Nogle populære modeller har (cirka-værdier, afhænger af version):

• GPT-3.5: omkring 4.096 tokens i context
• GPT-4 varianter: op til 32.768 tokens
• Claude 2.1: omkring 200.000 tokens
• Gemini 1.5 Pro: omkring 128.000 tokens

Større context betyder, at du kan:

• indsætte længere dokumenter
• bevare mere chat-historik
• arbejde på større kodebaser

Men det betyder også typisk:

• flere tokens pr. kald
• højere pris pr. request
• ofte langsommere svar, fordi modellen skal læse mere input

Hvis du vil forstå, hvordan context spiller sammen med fx API-design og performance, er det værd at kende de grundlæggende API-principper. Her er artiklen om at stoppe med at være bange for REST-API’er et fint sted at starte.

Hvad sker der, når man rammer token-grænsen?

Når du rammer context length, kan der ske flere ting, afhængigt af model og API-indstillinger:

• modellen afviser kaldet med en fejl om for mange tokens
• modellen trunker (skærer) i historik eller dokumenter, ofte de ældste dele
• modellen afslutter svaret midt i en sætning, fordi der ikke er flere tokens til output

En anden vigtig parameter er max_tokens, som du ofte kan sætte i API-kaldet. Det er et loft for, hvor mange outputtokens modellen må bruge. Hvis du sætter max_tokens for lavt, får du korte eller afbrudte svar, selv om context length ikke er udnyttet. Sætter du det for højt, risikerer du meget lange og dyre svar.

Konsekvenserne af at presse mod grænsen er:

• dårligere kvalitet, fordi modellen mister noget kontekst
• uforudsigelig længde på svar
• højere omkostninger uden bedre resultater

Ofte er det mere effektivt at begrænse historikken og arbejde med opsummeringer eller retrieval end bare at skrue context length op og håbe på det bedste.

Hvorfor output ofte er dyrere og langsommere end input

De fleste udbydere prissætter output højere end input. Det afspejler, hvordan beregningen foregår:

• Input bliver læst relativt hurtigt og kan ofte behandles mere parallelt.
• Output bliver genereret token for token. Hver ny token afhænger af alle de tidligere tokens i konteksten.

Det betyder, at:

• lange svar tager længere tid at generere
• lange svar bruger mange flere beregninger og dermed energi
• lange svar derfor også typisk er dyrere

Fra brugerens perspektiv mærker du det som:

• hurtig “tænkepause” når modellen læser din prompt
• langsom “skrivning” når modellen spytter svaret ud

Hvis du bygger noget, hvor svartid betyder meget (f.eks. en kundevendt chatbot), er det værd at tænke over, hvordan du holder output så kort som muligt uden at miste kvalitet. Der er i øvrigt en god parallel til almindelig webperformance, som du kan se i indlægget om Core Web Vitals uden panik.

Konkrete eksempler på tokenforbrug

Det bliver nemmere at forholde sig til tokens, når man ser dem i en hverdagssituation. Her er tre typiske scenarier.

1. Kundeservice-chatbot

Forestil dig en chatbot, der hjælper kunder med spørgsmål til et produkt.

For hver besked kan input indeholde:

• systemprompt: 500 tokens (rolle, regler, stil)
• chat-historik: 1.000 tokens (tidligere spørgsmål/svar)
• kundens nye besked: 50 tokens
• ekstra dokumentuddrag: 450 tokens

Samlet input ≈ 2.000 tokens.

Hvis du lader modellen svare med op til 500 tokens, ligger du på:

• 2.000 input + 500 output = 2.500 tokens pr. besked

Hvis chatbotten håndterer 10.000 beskeder om måneden:

• 2.500 tokens * 10.000 = 25.000.000 tokens

Det er 25 mio. tokens. Med en prisstruktur omkring $4 input og $24 output pr. 1 mio. tokens ender vi (i meget grove træk) på nogle hundrede dollars om måneden. Og det var bare én kanal.

2. Kodeassistent

En kodeassistent i dit IDE får typisk:

• stykker af din nuværende fil
• nogle få nærliggende filer
• din korte prompt: “Refactor denne funktion”

En typisk request kan måske ligge på:

• input: 1.500 tokens (kode + lidt historik)
• output: 300 tokens (forslag til ny kode)

Samlet: 1.800 tokens.

Hvis du bruger den flere hundrede gange om dagen på et team, kan det hurtigt løbe op – især hvis folk begynder at bruge assistenten til lange forklaringer frem for korte kodeforslag. Det er også her, det bliver tydeligt, hvorfor det er en dårlig idé bare at copy-paste AI-kode uden at forstå den. Du betaler både i tokens og i teknisk gæld.

3. Dokumentsummering

Du har et dokument på 30 sider, som du vil have opsummeret.

Du sender hele dokumentet ind som input:

• tekst: 12.000 tokens
• prompt: 100 tokens
• systemprompt: 300 tokens

Input ≈ 12.400 tokens.

Du beder om en opsummering på maks. 400 tokens. Så har du:

• 12.400 input + 400 output = 12.800 tokens pr. dokument

Hvis du gør det for 1.000 dokumenter pr. måned:

• 12.800.000 tokens i alt

Her er det tydeligt, at det primært er inputtet, der koster. Måske giver det mere mening at dele dokumentet op (chunking) eller bruge en retrieval-løsning, hvor modellen kun ser de relevante bidder, i stedet for at sende alt ind.

Sådan reducerer du tokenforbrug og holder output kort

Heldigvis er der meget, du kan gøre for at holde tokenforbruget nede uden at ødelægge kvaliteten. Her er de greb, jeg selv ender med igen og igen.

1. Gør systemprompts kortere og mere præcise

Systemprompts kan vokse stille og roligt, når man “lige tilføjer” en ekstra regel. Pludselig er de flere tusinde tokens, der bliver sendt med hver gang.

• skær gentagelser væk
• brug korte, klare regler i punktform
• flyt faste tekster (som lange stilguides) ud og hent dem kun ved behov

2. Begræns historikken

Gem ikke hele samtalen for evigt.

• send kun de seneste få beskeder med, hvis det er nok
• brug opsummeringer af ældre historik i stedet for rå tekst
• overvej faste “afskæringer”, f.eks. kun sidste 10 beskeder

3. Sæt realistiske max_tokens

Et almindeligt mønster er bare at sætte max_tokens til noget meget højt “for en sikkerheds skyld”. Det er sjældent en god idé.

• sæt loftet efter den reelle brugssituation (f.eks. 200 tokens til korte svar)
• hav forskellige presets til forskellige endpoints (kort svar vs. rapport)
• log hvor ofte loftet rammes, og juster ud fra det

4. Send kun det relevante ind

Hvis du indsætter hele dokumenter, kodebaser eller logs hver gang, brænder du mange tokens af uden effekt.

• brug pre-filtering eller søgning til at vælge relevante uddrag
• til kode: send kun relevante filer og funktioner
• til tekster: send kun de afsnit, spørgsmålet handler om

5. Overvej caching og batchning

Hvis mange brugere stiller de samme spørgsmål, er det oplagt at genbruge svar i stedet for at generere dem igen hver gang.

• brug en cache over ofte stillede spørgsmål og deres svar
• overvej at cache prompts og kontekst, som er ens på tværs af brugere
• læs mere om principperne i cachen lyver oftere end din kode

Hvis du har mange små kald, kan batchning og baggrundsjob også hjælpe. Artiklen om baggrundsjob uden drama viser nogle af de mønstre, der også giver mening for LLM-kald.

6. Skriv prompts, der inviterer til korte svar

Modellen gør ofte det, du beder om. Hvis du altid spørger “forklar meget detaljeret”, så gør den det.

• vær eksplicit: “Svar kort”, “Maks 5 punkter”, “Maks 150 ord”
• brug opsummeringer frem for hele rapporter som standard
• lad brugeren selv vælge, hvornår de vil “udvide” svaret

Typiske faldgruber ved AI-tokens

Der er nogle mønstre, jeg efterhånden har set mange gange, både hos mig selv og andre.

1. At undervurdere API-omkostninger

I små tests virker alt billigt. 10-20 øre pr. kald føles ikke af meget. Men når du går i drift, får du:

• flere brugere
• flere kald pr. bruger
• længere historik pr. kald
• flere features, der alle bruger modellen

Pludselig er du på tusindvis af kroner om måneden. Derfor skal du regne på tokenforbrug pr. feature tidligt, ikke bagefter.

2. At sende for meget historik med hver gang

Det er fristende bare at sende hele samtalen med for at være sikker på, at modellen “forstår” konteksten. Men ældre dele af en samtale er ofte ligegyldige.

Løsningen er som regel:

• trim historikken hårdt
• brug korte opsummeringer af tidligere dele
• hav klare regler for, hvor meget der sendes med

3. At vælge for dyr model til simple opgaver

Store modeller er gode, men ofte overkill:

• en simpel klassifikation eller sentimentanalyse kan klares af en billigere model
• en lille model kan måske generere bullets lige så godt som en stor
• brug den store model til få, vigtige steder, ikke til alt

4. Abonnementsillusionen

Mange blander deres oplevelse med ChatGPT Plus eller lignende sammen med API-brug. Et månedligt abonnement betyder, at du som bruger ikke tænker i tokens. Men når du integrerer via API, er det næsten altid ren token-baseret fakturering.

Det gælder om at designe med tokens i hovedet fra starten. Ellers ender du med at “tælle tokens baglæns” i logs, når regningen kommer. Her er artiklen om logs vs. mavefornemmelse relevant igen.

Hvad skal du især være opmærksom på i virksomheds- og udviklingskontekst?

Hvis du bygger noget med LLM’er til andre end dig selv, bliver tokens hurtigt et forretningsspørgsmål, ikke bare et teknisk.

1. Tænk tokens ind i designfasen

Når du designer en løsning, så spørg dig selv:

• hvor ofte bliver denne feature kaldt?
• hvor lang er en typisk prompt + historik?
• hvor langt et svar har vi faktisk brug for?
• hvilken model er “god nok” her?

Lav simple overslagsberegninger pr. endpoint eller feature. Du behøver ikke være millimeter-præcis. Bare få et niveau-billede af, om vi taler 100 kr., 1.000 kr. eller 10.000 kr. pr. måned.

2. Mål tokenforbrug pr. feature

I stedet for at stirre på én samlet token-tæller, er det mere nyttigt at se:

• hvilke endpoints bruger flest tokens?
• hvilke features har højest pris pr. kald?
• hvor er forskellen mellem input og output størst?

Det kræver typisk lidt ekstra logging og struktur, men det er det, der gør det muligt at optimere rigtigt. Artiklen om at bygge et lille Express API giver en god ramme for at tænke robuste integrationer, hvor du også kan putte token-logging ind.

3. Sikkerhed og governance

Når du først har API-nøgler til dyre modeller liggende i din kode eller dit miljø, er det fristende for både udviklere og andre systemer “lige at prøve noget af”. Det kan blive dyrt og usikkert.

• opbevar API-nøgler som rigtige secrets (se f.eks. secrets skal være kedelige, ikke spændende)
• sæt quotas og rate limits på dine endpoints, så misbrug ikke eksploderer omkostningerne (rate limiting i praksis er værd at læse)
• log brug pr. bruger/team, så du kan tage reelle snakke om behov vs. omkostning

På den måde bliver tokens ikke bare en teknisk detalje, men en del af din styring af budget, kvalitet og sikkerhed.

Kort opsummering: sådan arbejder du klogt med tokens

Hvis jeg skal koge det ned til de vigtigste punkter:

• En token er den lille tekst-enhed, modellen læser og skriver. Alt måles i tokens.
• Input tokens er det, du sender ind. Output tokens er det, modellen sender tilbage.
• Priser opgøres typisk pr. 1 mio. tokens, og output er ofte dyrere end input.
• Context length er den samlede token-grænse for både input og output i ét kald.
• Rammer du token- eller max_tokens-grænser, får du afbrudte eller forringede svar.
• Hold systemprompts korte, trim historik, sæt realistiske max_tokens, og send kun relevant tekst ind.
• Mål tokenforbrug pr. feature, ikke kun samlet, og tænk pris ind allerede i designet.

Når du først har en intuitiv fornemmelse for tokens, bliver det meget nemmere at bygge AI-løsninger, der både er gode at bruge og til at betale.