Vad är en fråga, och vad är ett arbete?
Förslag och analys på eget initiativ, inte beslutat av Lunds Naturskyddsförening eller Naturskyddsföreningen. Siffrorna är hämtade ur källorna eller uppmätta och inte kvalitetssäkrade. Kontrollera mot källan innan något återges. Tillbaka till den korta versionen.
Kort version
Steg 1: kort version
Energin «per fråga» gäller en normal fråga och ett normalt svar: en kort, manuellt skriven fråga () och ett svar på ungefär en sida text (), tillsammans X = . Arbetet med den här analysen använde nya tokens (Y). Det är Z = Y ÷ X, alltså fler nya tokens än en normal fråga. Antagandena är versionerade och kan ändras när det finns nya källor, nya vanor eller nya modeller. Hur återlästa tokens ska räknas är en egen fråga, som besvaras längre ned: de kostar mycket mindre än nya, men inte noll.
Frågan
Nyckeltalet «energi per fråga» används överallt, men vad är en genomsnittlig fråga och ett genomsnittligt svar? Och är «en fråga, ett svar» ens det bästa sättet att använda generativ AI? Här definieras begreppen, en session mäts och energin redovisas som ett spann.
Vad en «fråga» är i källorna
| Källa | Vad som mäts | Vad som anges om längd |
|---|---|---|
| En typisk ChatGPT-fråga (GPT-4o), beräknad | Svar på cirka (cirka 400 ord, ungefär en maskinskriven sida). Epoch kallar det något pessimistiskt: en annan studie fann i snitt. Kort inmatad fråga. Bilder och röstläge ingår inte | |
| Median-textfråga till Gemini Apps, mätt i drift | Längden i tokens anges inte i artikelns abstract. Hela artikeln är inte läst (F-26) | |
| «Genomsnittlig fråga» | Ingen definition | |
| 1 000 användningar per uppgift och modell på en referensdatamängd | Uppgiftstyp snarare än fråga (till exempel textgenerering, bildgenerering) |
I praktiken är en «fråga» alltså en kort, manuellt skriven fråga och ett svar på ungefär en sida text, inget mer. Det är det som menas med energin per fråga på resten av sidorna. Längre indata kostar mer: uppskattar cirka för en fråga med 10 000 tokens indata (en kort artikel) och cirka med 100 000 tokens indata (cirka 200 sidor). Det är beräkningar för GPT-4o, och verkliga siffror beror på hur systemen cachar, men riktningen är tydlig.
En token är den enhet en språkmodell räknar text i. För OpenAI motsvarar en token i genomsnitt cirka per token. Olika modeller räknar olika.
Olika sätt att använda AI
| Nivå | Exempel | Storleksordning på användningen |
|---|---|---|
| 1. Enkel fråga och svar | «Vad är El Niño?» | En fråga enligt Tabell 1 |
| 2. Längre samtal | Ett utkast som förbättras i tio rundor | Tiotals frågor, och längre indata efterhand som samtalet växer |
| 3. Arbete med många steg | En hel analys: sökning, läsning av källor, filer som skrivs och granskas, kontroller | Många modellanrop med stor mängd indata i varje, se sessionen |
Nivå 3 använder mycket mer resurser än nivå 1, men den ersätter inte en fråga. Den ersätter ett arbete som annars tar en människa timmar eller dagar.
Definitioner: X, Y och Z
För att kunna jämföra och följa förändringar över tid definieras tre tal. De är antaganden, med version och källa, och ska kunna ändras när det finns nya källor, nya vanor eller nya modeller.
| Beteckning | Definition | Värde |
|---|---|---|
| X_IN | Indata i en normal fråga: en kort, manuellt skriven fråga på cirka 75 ord | |
| X_UT | Utdata i ett normalt svar: ungefär en sida text, cirka 400 ord | |
| X | En normal fråga och ett normalt svar, utan tidigare samtal: X = X_IN + X_UT | |
| Y_NY | Nya tokens i ett arbete: producerad text, ny indata och nya cachade tokens | uppmätt, se Tabell 4 |
| Y_ATER | Återlästa tokens: den tidigare kontexten som modellen läser om vid varje steg, ur cachen | uppmätt, se Tabell 4 |
| Z_NY | Hur många gånger fler nya tokens än en normal fråga: Z_NY = Y_NY ÷ X | |
| Z_UT | Samma för bara producerad text: Y_UT ÷ X_UT | |
| Z_ALLA | Samma för alla bearbetade tokens, även återlästa. Ger ett högre tal, men återlästa tokens kostar mindre per styck än nya |
Varför flera Z? En enda «mängd tokens» blandar saker som kostar olika mycket. Nya tokens (Z_NY) är det som faktiskt skrivs och läses första gången, och det är det som lyfts fram. Återlästa tokens är samma kontext som läses om i varje steg. En token är inte samma sak i alla modeller, så Z är en storleksordning.
Arbetet med analysen: uppmätt
Tokenanvändningen för arbetet med den här analysen är summerad ur arbetspassets egen loggfil med skriptet . Det är mätningar, inte uppskattningar, men en ögonblicksbild (2026-11-12, cirka kl. 13:14) som ökar medan arbetet fortsätter. Siffrorna omfattar huvudsessionen och fyra delegerade underagenter.
| Uppgift | Värde |
|---|---|
| Modellanrop | |
| Producerade tokens (utdata) | |
| Y_NY: nya tokens (producerade, ny indata och nya cachade) | |
| Y_ATER: återlästa ur cache |
| Mått | Beräkning | Z |
|---|---|---|
| Z_NY | Y_NY ÷ X | |
| Z_UT | Y_UT ÷ X_UT | |
| Z_ALLA | (Y_NY + Y_ATER) ÷ X |
Arbetet använder alltså cirka gånger fler nya tokens än en normal fråga och ett normalt svar, och cirka gånger mer producerad text. Med all återläsning av kontexten blir talet , men det överdriver kostnaden. Förbehåll: det är oklart om fältet för producerade tokens också räknar modellens interna resonemang (F-29), och arbetet är inte slut.
Räknas bara nya tokens, eller även gamla?
Steg 1: kort svar
Båda, men på olika sätt. Leverantörerna skiljer på nya och återlästa (cachade) tokens, och de återlästa är mycket billigare i pris. I energi sparar cachningen mest av arbetet att läsa in indatan (enligt ett förtryck cirka ), men inte kostnaden för att varje ny token ska ta hänsyn till hela den tidigare kontexten. Räknar man bara nya tokens underskattas energin, och räknar man alla lika överskattas den. Därför redovisas energin som ett spann. Modellerna skiljer sig åt, se nedan.
Vad leverantörerna redovisar och tar betalt för
| Leverantör | Hur cachningen fungerar | Pris för cachade läsningar | Hur det redovisas | Minsta längd och livslängd |
|---|---|---|---|---|
| Återanvänder ett tidigare bearbetat prefix (verktyg, systemtext, meddelanden) upp till en markerad brytpunkt | vanligt indatapris, lägre för vissa modeller (0,05 gånger för Opus 5.5 och Sonnet 5.5, 0,025 gånger för Fable och Mythos). Skrivning (5 minuter) eller 2 gånger (1 timme) | Separata fält för nya, cachade nyskrivna och cachade lästa tokens (input_tokens, cache_creation_input_tokens, cache_read_input_tokens) och för producerade tokens (output_tokens) | 512–4 096 tokens beroende på modell. 5 minuter som standard, förnyas vid användning. 1 timme som tillval | |
| Återanvänder redan beräknade tillstånd (KV-tillstånd) för ett gemensamt prefix. På som standard för stödda modeller | Rabatt på cachad indata upp till , varierar mellan modeller | Redovisas i användningsfältet (fältnamnen är inte kontrollerade här) | Inte kontrollerat här | |
| Implicit och explicit cachning. Modellen skiljer inte på cachade och vanliga indatatokens: cachat innehåll är ett prefix | «Reducerat pris», inget belopp angivet på sidan | I usage_metadata (fältnamnet skiljer mellan sidor) | 2 048–4 096 tokens för implicit cachning, beroende på modell. Explicit cachning har 1 timme som standardlivslängd |
Priset är leverantörens prissättning och säger inte hur mycket energi som sparas. Anthropic och Google beskriver mekanismen som att ett redan bearbetat prefix återanvänds. Det som skiljer är alltså vad som räknas och tas betalt för, inte hur mycket energi som åtgår.
Vad kostar de gamla tokens i energi?
När en modell läser in en text bearbetar den tokens och sparar mellanresultat, key-value-tillstånd (KV), som gör att den kan hänvisa tillbaka till tidigare tokens medan den bearbetar ny indata och skriver svar. Cachning sparar de tillstånden för ett prefix, så att modellen slipper bearbeta det igen (). Men för varje ny token modellen skriver måste den fortfarande läsa tillstånden för hela kontexten.
Det är exakt skillnaden som mäter. Varje token går in i KV-cachen och gör de följande tokens dyrare, så energin växer ojämnt längs en text. Deras modell skiljer indatan (prefill) från avkodningen och delar avkodningen i KV-cachen och själva nästa token.
| Vad | Effekt |
|---|---|
| Energin för att bearbeta indatan (prefill) med prefixcachning | Minskar med |
| Kostnaden för KV-cachen (att läsa all tidigare kontext vid varje ny token) | Opåverkad av cachningen |
| Ett anrop vid agentiskt arbete (lång indata), jämfört med ett icke-agentiskt anrop, utan cachning | så mycket energi |
| Samma anrop med prefixcachning | så mycket energi |
Förbehåll: artikeln är ett förtryck från 2 november 2026, mätt på 13 öppna modeller från sex familjer, inte på Claude eller andra slutna modeller. Jämförelserna gäller energi per anrop relativt ett icke-agentiskt anrop, inte absoluta värden. Hela artikeln är inte läst (F-34).
Skiljer det mellan modeller?
Ja, på flera sätt:
- Arkitektur. Enligt växer prefillenergin kvadratiskt med modellens dolda dimension, så större modeller drabbas mest av lång indata. Grupperad nyckelhantering (GQA) minskar energin per token med upp till jämfört med standardmetoden (MHA).
- Cachningsregler. Minsta längd, livslängd och vad som kräver en särskild markering skiljer mellan leverantörer och modeller (Tabell 7).
- Prissättning. Rabatten på cachade tokens varierar mellan leverantörer och modeller, även inom en leverantör (Tabell 7).
- Tokenräkning. En token är inte samma enhet i alla modeller, och leverantörerna redovisar olika fält. Talen är därför inte direkt jämförbara mellan modeller (F-35).
Konsekvens för Z och energispannet
- Z_NY (bara nya tokens) antar att återläsningen kostar inget. Det underskattar troligen energin, eftersom KV-cachen finns kvar.
- Z_ALLA (alla tokens lika) antar att en återläst token kostar som en ny. Det överskattar energin, eftersom det mesta av indatakostnaden sparas.
- Ett tredje räknesätt utgår från antalet anrop: arbetet hade anrop, och om varje anrop kostar som ett cachat respektive ocachat agentiskt anrop i förtrycket (– gånger en normal fråga) blir det . Det är en indikation, inte en mätning: förtryckets agentiska anrop är inte samma som de här, och de här anropen bearbetade i genomsnitt per anrop, vilket är en mycket längre kontext.
Bedömningen är att undre gränsen och det tredje räknesättet överlappar, så energin för arbetet ligger troligen i området några hundra Wh, men att långa kontexter kan ge mer. Övre gränsen ska läsas som ett tak som sannolikt inte nås. Det är en bedömning, inte ett mätvärde, och spannet behålls i redovisningen.
Kontextfönstret är inte förbrukningen
Appen visar hur stor del av modellens kontextfönster som är fylld, till exempel som en procentsats. Det är storleken på det som skickas med i nästa anrop, alltså allt som hittills sagts och gjorts i arbetet. Det är inte summan av det som förbrukats, och det säger inte direkt något om energin. Summan för arbetet är den uppmätta: anrop med nya tokens och återlästa tokens (Tabell 4).
Eftersom kontexten läses om vid varje anrop blir varje nytt steg dyrare ju längre arbetet pågår: det finns mer att läsa och KV-cachen är större. Därför växer också kvoten mellan den övre och den undre gränsen med arbetets längd (just nu ). Vad det betyder i tokens, energi och pengar för det här arbetet finns på sidan Min förbrukning. Ett sätt att hålla nere resursanvändningen är att spara det viktiga i filer och dela upp ett långt arbete i flera sessioner, så att varje session börjar med en kort kontext.
Skiljer det mellan Claude, ChatGPT, Gemini och Grok?
Troligen ja, men det är inte mätt för samma arbete. Det som finns är uppgifter per vanlig fråga: för Gemini (Google, egen mätning), för ChatGPT (beräkning av Epoch AI) och (OpenAI, utan metod). För Claude och Grok har ingen motsvarande uppgift hittats i det här underlaget. Enligt fann en benchmark av 30 modeller att de mest energikrävande modellerna överstiger för en lång fråga, över de mest effektiva. Spridningen mellan modeller kan alltså vara stor.
Dessutom beror energin för samma projekt på hur arbetet läggs upp: antal anrop, kontextens längd, cachning och om modellen resonerar länge. Att jämföra samma projekt mellan tjänsterna kräver att samma uppgift mäts i alla (F-36). Tabell 7 visar att cachningen redan skiljer mellan leverantörer.
Vad det betyder i energi: scenarier, inte mätningar
Energin per token är inte offentlig för den modell som användes. Hovra över, eller tryck på, en rad i tabellen för att se vad räknesättet betyder. Två gränser går att räkna på, med Googles och Epoch AI:s uppskattningar per normal fråga som proxy:
| Antagande | Energi | I mikrovågsugn | Direkt vatten |
|---|---|---|---|
| Bedömning: troligast (undre gränsens mitt, Z_NY × medelvärdet av energi per fråga) | |||
| Undre gräns: energin följer nya tokens, återläsningen kostar inget (Z_NY × energi per fråga) | |||
| Understöd: tredje räknesätt, anrop × 4,8–13 gånger energin per normal fråga (ur ett förtryck, se Konsekvens för Z) | |||
| Övre gräns: varje återläst token kostar lika mycket som en ny (Z_ALLA × energi per fråga) |
Det sanna värdet ligger troligen närmare den undre gränsen eftersom cachad indata inte beräknas om från början, men KV-cachen finns kvar, så det går inte att säga hur nära (se Räknas bara nya tokens, eller även gamla?). Att läsa lång kontext kostar mer än att läsa kort (se Tabell 1). Spannet är brett, och det är poängen: det är inte känt, och det ska inte låtsas vara känt.
Hur antagandena följs över tid
Varje ändring av ett antagande får en rad med version, datum, vilka poster det gäller och skäl. Z räknas alltid av sidan ur X och Y. Skriptet för mätningen kan köras på fler arbeten, så att Y blir ett genomsnitt över flera i stället för ett enskilt arbete (F-30).
Är det bättre att göra mer utförliga produkter?
- Resursanvändningen mäts bäst mot vad den ger. Att jämföra en hel produkt med en enskild fråga är som att jämföra en bilresa med ett steg. Frågan är vad produkten ersätter och vad den åstadkommer.
- Utförligt arbete gör sådant möjligt som en enkel fråga inte kan. Det som tar flera källor, kontroller och versioner går inte att göra i ett enda svar. Det är en beskrivning av arbetet, inte en uppmätt nytta.
- Det är inte automatiskt bra att använda mer. Där användningen är som störst samlas också resursanvändningen, vilket är skeptikernas poäng. Argumentet håller bara om arbetet ger nytta som motsvarar kostnaden.
- Planering sparar resurser. En kort specifikation i förväg minskar antalet varv och därmed antalet anrop.
- Belägg för nyttan saknas. Det finns inga källor här för hur mycket AI-stöd faktiskt sparar (F-24) eller för en jämförelse med människans resursanvändning för motsvarande arbete (F-28). Därför påstås ingen siffra för nyttan.
Slutsats: enkla frågor är den billigaste användningen, och utförliga arbeten kan vara mer värda trots att de kostar mer. Det är en värdering som ska göras i varje fall, med resurserna redovisade öppet och osäkerheten med.
Det som återstår
Det här ska analyseras och beskrivas bättre i kommande versioner:
Källor
Källorna som den här sidan hänvisar till, i Harvardformat. Hela förteckningen och hur varje källa kontrollerats finns på sidan Källor och logg.