Varför output-tokens i LLM-API:er kostar 4-8x mer än input-tokens

Titta på prissidan för vilket större LLM-API som helst — OpenAI, Anthropic, Google, det spelar ingen roll — och du kommer märka samma mönster varje gång: output-tokens kostar flera gånger mer än input-tokens. Inte heller en liten premie. Bland dagens modeller ligger förhållandet konsekvent mellan 4x och 8x. Det är ingen prisnyck specifik för en leverantör; det är en direkt konsekvens av hur dessa modeller faktiskt körs.

Den verkliga orsaken: input är parallell, output är sekventiell

Att bearbeta input-tokens — din prompt, systemmeddelande, konversationshistorik — sker i en enda framåtpassering. Modellen läser hela inputen på en gång och beräknar attention över allt samtidigt, parallellt. Moderna GPU:er är extremt bra på den här typen av batchad, parallell beräkning, så en prompt på 3 000 tokens och en på 300 tokens kostar inte proportionellt så mycket mer beräkningstid som deras tokenantal antyder — overheaden av att köra modellen en gång är den dominerande kostnaden, inte längden på det den läser.

Att generera output-tokens är fundamentalt annorlunda. Varje ny token beror på alla tokens som kom före den, inklusive de modellen just genererat — så token 500 i ett svar kan inte beräknas förrän token 499 existerar. Det tvingar fram en sekventiell loop: en framåtpassering per output-token, körda en efter en, utan möjlighet att parallellisera över sekvensen. Att producera 500 output-tokens innebär att köra modellen 500 gånger i rad, inte en gång.

Den asymmetrin i beräkning — en parallell passering för input, N sekventiella passeringar för N output-tokens — är varför alla större leverantörers prissättning ser likadan ut oavsett företag, modellarkitektur eller region. Det är inte så mycket ett affärsbeslut som en direkt vidarebefordring av den underliggande beräkningskostnaden.

Vad detta betyder för dina prompter

Den praktiska slutsatsen är rättfram: ett utförligt modellsvar kostar oproportionerligt mer än en lång prompt med ett kort svar, även när det totala tokenantalet ser likartat ut. Om du försöker minska API-kostnaderna sparar det oftast mer per token att korta ner outputlängden än att korta ner inputlängden.

Några konkreta hävstänger:

• Begränsa svarslängden explicit. En systemprompt-instruktion som “svara i ett stycke” eller en max_tokens-gräns gör mer för kostnaden än att förkorta din egen prompt.
• Be om strukturerad output istället för löptext. Ett JSON-objekt med tre fält är ofta betydligt kortare än motsvarande förklarat i meningar, och lika användbart längre fram i kedjan.
• Överförklara inte i systemprompten för att spara på output. En längre, mer precis systemprompt (input, billig) som pålitligt producerar ett kort korrekt svar (output, dyrt) är oftast en bättre avvägning än en kort, vag prompt som får modellen att hedga med ett långt svar.
• Använd en billigare modell för högvolym, lågkomplex output. Om en uppgift inte kräver toppmodellers resonemang — klassificering, extraktion, korta svar — är budgetmodellens outputprissättning ofta en storleksordning lägre.

Att räkna ut den faktiska kostnaden i kronor

Förhållandet förklarar varför output kostar mer, men den exakta summan beror på vilken modell du använder och hur många tokens varje sida av en förfrågan faktiskt förbrukar. Eftersom input/output-fördelningen — och multiplikatorn mellan dem — varierar äkta mellan modeller (en budgetmodell och en flaggskeppsmodell tillämpar inte samma förhållande) är det enda tillförlitliga sättet att veta din verkliga kostnad att mata in dina egna siffror per modell.

CodeKitHubs LLM API Pricing Calculator gör precis det: välj din modell, ange dina input- och output-tokenantal, och den visar inputkostnad, outputkostnad och totalsumma — plus en månadsuppskattning om du vet ungefär hur många förfrågningar du kommer göra. Om du inte är säker på hur många tokens din faktiska prompt använder ger Token Counter-verktyget dig det exakta antalet med hjälp av den riktiga tokeniseraren, istället för en ungefärlig teckenbaserad gissning.

Båda körs helt i din webbläsare — ingen API-nyckel, inget konto, inget skickas någonstans.