A context window, a token és a számla mérve

Ebben az üzletben a legdrágább félreértés az, hogy egy model emlékszik a beszélgetésre.

Nem emlékszik, és a 13. fejezet mechanizmusa pontosan megmondja, miért. Egy transformer állapota generálás közben a KV cache: a sorozat minden tokenjéhez kiszámolt kulcsok és értékek. Ez a cache egyetlen kérés idejéig él. Amikor a kérés véget ér, a folyamat, amely tartotta, szabadon kiszolgálhat valaki mást, a cache pedig eltűnik. A túloldalon nincs felhasználónkénti tároló, és nincs munkamenet.

Ezért a következő kérésnek magával kell hoznia mindent, amit a modelnek tudnia kell, a model pedig úgy építi újra ezt az állapotot, hogy lefuttat egy forward passt a teljes prompton, mielőtt egyetlen új tokent kibocsátana. A 15. fejezet a promptot „a teljes állapotnak” nevezte. Ez a fizikai oka: a prompt a teljes állapot, mert a hívás után semmi más nem marad meg.

A context window a prompt és a válasz maximális együttes hossza. Annak a felső határa, mennyi állapotot tudsz újraépíteni, nem pedig egy tároló, amely bármit megtartana a kérések között. Ha „a model memóriájának” nevezed, megfordítod az okozatiság irányát — nem egy memóriát töltesz fel, hanem azért fizetsz, hogy újra létrehozz egyet.

Innen jön a huszonkettes szorzó. A(z) $n$. kör magával viszi az összes $n-1$ korábbi kört, így egy $n$ körös beszélgetés teljes inputja egy növekvő sorozat összege, vagyis négyzetes:

ahol $s$ a system prompt, $h_i$ pedig az előzmények a(z) $i$. körben. A mért kumulatív inputot a negyven körre $an^2 + bn$ alakra illesztve $60.22\,n^2 + 432.25\,n$ adódik, ami a 40. körre 113 645 tokent jósol a mért 112 617 helyett. A négyzetes tag dominál, a lineáris tag pedig az, amit a felhasználó ténylegesen begépelt.

A fejezet legfontosabb mondata ez: a számlád a beszélgetés négyzetével nő, nem az utolsó kérdéssel. Ugyanez a negyven kérdés előzmények nélkül $0.066036-ba került volna. Az előzmények megtartása $0.274386-ba került. Az előzmények 4,2-szeresére növelték a számlát, és továbbra is szorozni fogják, mert a szorzó maga a beszélgetés hossza.

A window két okból véges, és mindkettő ugyanabba az irányba húz. Az első a 9. fejezeté: az attention minden tokent minden más tokennel összehasonlít, ezért ennek a rétegnek a munkája a sorozathossz négyzetével nő. A második a memória: a KV cache lineárisan nő a sorozathosszal, és a 13. fejezet elvégezte ezt a számítást — hosszú sorozatoknál nagyobb, mint a súlyok.

Mindkét korlátot támadták már, de egyiket sem tüntették el. A FlashAttention¹ úgy szervezi át a számítást, hogy sokkal kevesebbet olvasson és írjon a nagy sávszélességű memóriába, így a hosszú sorozatok praktikussá válnak anélkül, hogy az aszimptotikus költség változna. A Position Interpolation² és a YaRN³ egy betanított model használható windowját azzal bővíti, hogy a 9. fejezetből ismert pozicionális kódolásokat skálázza át, nem pedig újratanít. Együtt ezek miatt jutottunk öt év alatt 2K-ról 1M-es windowig.

Amit nem tettek meg: nem tették ingyenessé a hosszú kontextusokat. Magasabbra emelték a plafont, és enyhítették a meredekséget. A meredekség továbbra is ott van, és ezt mérik a fejezet későbbi árazási sávjai.

Az interneten szinte minden költségkalkulátor úgy modellez egy API-hívást, hogy input tokens szorozva input árral, plusz output tokens szorozva output árral. Ez 2023-ban igaz volt. Ma már úgy téves, hogy mindkét irányba akár kétszeres vagy nagyobb eltérést is okozhat a számlában.

Öt számlázható token-kategória van:

Ebből az ötből három két éve még nem létezett külön sorként, és a két cache-sor az, amit az emberek félreértenek, mert a cache write többe kerül, mint a sima input, nem kevesebbe. Felárat fizetsz azért, hogy valamit eltárolj, hogy aztán kedvezménnyel olvashasd vissza; hogy ez megéri-e, teljesen attól függ, hányszor olvasod vissza.

A reasoning kosár a 12. fejezet témája, most árcédulával, és van benne egy részlet, amit érdemes világosan kimondani: a Google dokumentációja szerint az árazás „a model által generálandó teljes thought tokens alapján történik, annak ellenére, hogy az API csak az összefoglalót adja ki.”⁴ Olyan tokenekért fizetsz, amelyeket soha nem továbbítanak neked. Ez az egyetlen kosár, amelynek tartalmát nem tudod megszámolni, megvizsgálni vagy ellenőrizni.

Most jön az a rész, ami ezt normalizálási problémává teszi, nem szorzási problémává. Minden provider más néven jelenti ezeket a kosarakat, és — ez a csapda — ketten ugyanazt a szót két különböző mennyiségre használják.

Vegyünk egy hívást: 4 837 token cache-ből olvasva, 110 friss, 142 látható output token, 300 reasoning token.

// OpenAI-compatible
{ "usage": { "prompt_tokens": 4947,
             "prompt_tokens_details": { "cached_tokens": 4837 },
             "completion_tokens": 442,
             "completion_tokens_details": { "reasoning_tokens": 300 } } }

// Anthropic
{ "usage": { "input_tokens": 110,
             "cache_read_input_tokens": 4837,
             "cache_creation_input_tokens": 0,
             "output_tokens": 442 } }

// Gemini
{ "usageMetadata": { "promptTokenCount": 4947,
                     "cachedContentTokenCount": 4837,
                     "candidatesTokenCount": 142,
                     "thoughtsTokenCount": 300 } }

Nézd meg a(z) prompt_tokens: 4947 és input_tokens: 110 mezőt. Mindkét mező ugyanannak a promptnak az input token száma. Az OpenAI-é tartalmazza a cached tokeneket; az Anthropicé nem — a dokumentációja explicit kimondja az azonosságot: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Az Anthropic input_tokens mezője azt jelenti: „a legutóbbi cache breakpoint utáni tokenek”.

És nézd meg az outputot. Az OpenAI és az Anthropic is 442-t jelent, amely már tartalmazza a 300 reasoning tokent. A Gemini 142-t jelent, és a 300-at külön mezőbe teszi. A 12. fejezet ezt ugyanannak a munkának két eltérő számlálási módja közötti inkompatibilitásként jelölte meg; itt látszik, mennyibe kerül.

Egy normalizáló harminc sor, és nem opcionális:

export interface Usage {
  promptTokens?: number;        // input, NOT cached
  cachedInputTokens?: number;   // read from cache
  cacheWriteTokens?: number;    // written to cache on this call
  completionTokens?: number;    // output
  reasoningTokens?: number;     // billed apart from output (Gemini only)
}

const num = (v: unknown) => (typeof v === "number" && isFinite(v) ? v : 0);

export const fromOpenAI = (raw: any): Usage => {
  const u = raw.usage ?? {}, d = u.prompt_tokens_details ?? {};
  const cached = num(d.cached_tokens), write = num(d.cache_write_tokens);
  return {
    promptTokens: Math.max(0, num(u.prompt_tokens) - cached - write), 
    cachedInputTokens: cached,
    cacheWriteTokens: write,
    completionTokens: num(u.completion_tokens),   // reasoning already inside
    reasoningTokens: 0,
  };
};

export const fromAnthropic = (raw: any): Usage => {
  const u = raw.usage ?? {};
  return {
    promptTokens: num(u.input_tokens),            // already excludes cache
    cachedInputTokens: num(u.cache_read_input_tokens),
    cacheWriteTokens: num(u.cache_creation_input_tokens),
    completionTokens: num(u.output_tokens),
    reasoningTokens: 0,
  };
};

export const fromGemini = (raw: any): Usage => {
  const m = raw.usageMetadata ?? {}, cached = num(m.cachedContentTokenCount);
  return {
    promptTokens: Math.max(0, num(m.promptTokenCount) - cached),
    cachedInputTokens: cached,
    cacheWriteTokens: 0,
    completionTokens: num(m.candidatesTokenCount), // EXCLUDES thinking
    reasoningTokens: num(m.thoughtsTokenCount),    // billed at output rate
  };
};

Futtasd át a fenti három payloadot a három readeren, és mindhárom ugyanazt a(z) Usage eredményt adja, ezért ugyanazt a számot: $0.006491. Ennek az egyezésnek az elérése az egész réteg megírásának lényege.

Ha elrontod, ennyibe kerül ugyanazon a híváson:

A harmadik veszélyes, mert csendben hibázik, mégpedig a jó hír irányába. A dashboardod azt mutatja, hogy egy reasoning model kevesebb mint feleannyiba kerül, mint valójában, és sehol sem keletkezik hiba.

Miután a kosarakat normalizáltuk, a költségfüggvény rövid. Az egyetlen nem magától értetődő rész a sávkeresés, amit a következő szakasz magyaráz:

export interface Tier { maxPromptTokens: number | null; price: number }
export interface Pricing {
  input: Tier[]; output: Tier[];
  cachedInput?: Tier[]; cacheWrite?: Tier[]; reasoning?: Tier[];
}

const tierPrice = (tiers: Tier[] | undefined, contextSize: number, fallback?: Tier[]) => {
  const table = tiers ?? fallback;
  if (!table?.length) return 0;
  const sorted = [...table].sort(
    (a, b) => (a.maxPromptTokens ?? Infinity) - (b.maxPromptTokens ?? Infinity));
  for (const t of sorted)
    if (t.maxPromptTokens === null || contextSize <= t.maxPromptTokens) return t.price;
  return sorted[sorted.length - 1].price;
};

export function computeCost(pricing: Pricing, usage: Usage): number {
  const fresh = usage.promptTokens ?? 0;
  const read  = usage.cachedInputTokens ?? 0;
  const write = usage.cacheWriteTokens ?? 0;
  const out   = usage.completionTokens ?? 0;
  const think = usage.reasoningTokens ?? 0;
  const contextSize = fresh + read + write;   // the tier depends on the WHOLE prompt
  return fresh * tierPrice(pricing.input, contextSize)
       + read  * tierPrice(pricing.cachedInput, contextSize, pricing.input)
       + write * tierPrice(pricing.cacheWrite,  contextSize, pricing.input)
       + out   * tierPrice(pricing.output, contextSize)
       + think * tierPrice(pricing.reasoning, contextSize, pricing.output);
}

Két tervezési döntést érdemes megvédeni. A fallbackek — cache-árak fallbackje inputra, reasoning fallbackje outputra — azt kódolják, mit jelent egy hiányzó tábla: a Gemini reasoning tokenjeit output díjon számlázzák, ezért egy hiányzó reasoning ár nem nulla, hanem az output ár. A(z) contextSize pedig mindhárom input kosarat összeadja, nem csak a frisseket, mert a sávot az választja ki, milyen hosszú a prompt, nem az, hogy mennyit számláztak belőle teljes áron.

A prompt cache a modeled kiszámolt állapotát tárolja a promptod egy prefixére, így egy későbbi, ugyanazzal a prefixszel érkező kérés kihagyhatja az újraszámítást. A „prefix” szóból négy tulajdonság következik, és mind a négy meglepi az embereket.

A megtérülési pont elég kicsi ahhoz, hogy fejben tartsd, és az OpenAI dokumentációja elvégzi a számítást: egy prefix egyszeri írása és egyszeri újrafelhasználása a szokásos inputköltség 1,35-szörösébe kerül, szemben a kétszeri uncached feldolgozás 2× költségével; tíz kérésnél egy write és kilenc read 2,15×, szemben a 10× értékkel. Egyetlen reuse visszahozza az írás árát. Az Anthropic ugyanoda jut: egy read az ötperces cache-nél, kettő az egyórás cache-nél.

Most újra a negyvenkörös beszélgetés, bekapcsolt cachinggel és stabil prefixszel:

Hatvannyolc százalékkal olcsóbb, és a táblázatban három szám megéri a figyelmet.

A cache csak a 6. körben lép működésbe. A prompt addig nem éri el az 1 024 tokent, ezért az első öt kört pontosan úgy számlázzák, mint korábban — a hatodikat pedig rosszabbul, az 1,25× write felárral, mert ez a kör tölti fel a cache-t. Az első read a 7. körben érkezik. A táblázat 2 887 uncached tokenje a számtan: öt környi, nem hat. A caching a hosszú promptok kedvezménye, egy rövid beszélgetés semmit sem nyer vele.

A write felár $0.002474, ami a cached számla 2,8 %-a. Minden kör megírja az új végét, negyvenszer, és a teljes write felár kerekítési hiba ahhoz képest, amit a readek megtakarítottak. A write díjat azért érdemes pontosan érteni, hogy ne aggódj miatta.

Csak 2 887 tokent számláztak teljes input áron a 112 617-ből. Így néz ki egy működő cache: szinte minden read.

Íme a hiba, amely valódi pénzbe kerül, és egy egysoros bug.

Tegyél valamit a prompt elejére, ami minden hívásnál változik — timestampet, request id-t, a felhasználó nevét, egy „ma van” sort, egy frissen retrieved dokumentumot —, és a prefix már az első byte-tól eltér. Semmi sem illeszkedik. Minden hívás miss. És mivel minden hívás új prefixet mutat, minden hívás ír is.

Ugyanaz a beszélgetés, ugyanaz a negyven kör, bekapcsolt caching, de hívásonkénti timestamp a system prompt tetején:

A prompt caching bekapcsolása húsz százalékkal drágábbá tette a beszélgetést annál, mintha be sem kapcsoltad volna. 109 730 tokenen fizetted meg az 1,25× write felárat, és nullát olvastál vissza. Nincs hiba, nincs figyelmeztetés, a funkció pedig be van kapcsolva.

Ezért a szabály — és ez a prompt caching egyetlen sorban: stabil tartalom előre, változó tartalom hátra. System utasítások, tool-definíciók és referencianyag először; timestamp, felhasználói identitás és az aktuális kérdés utoljára. Az Anthropic explicitté teszi a hierarchiát — a cache a(z) tools → system → messages sorrendet követi, és bármely szinten bekövetkező változás érvényteleníti azt a szintet és mindent utána, így egyetlen tool-leírás szerkesztése az egész cache-t érvényteleníti.⁵

Két következményen sokan elcsúsznak. Ha változik, mely toolok vannak engedélyezve, változnak a tool-definíciók is, tehát egy feature flag, amely egyes felhasználóknak hozzáad egy toolt, kettévágja a cache-edet. Anthropicnál pedig a webes keresés vagy a hivatkozások kapcsolgatása módosítja a system promptot, ami érvényteleníti a system és message cache-eket anélkül, hogy a saját szövegedből akár egy sort megváltoztatnál.

A négyzetesen növő számlára adódó kézenfekvő válasz, hogy ne küldd el a teljes előzményt: tartsd meg az utolsó tucat üzenetet, a többit dobd el. Ez csökkenti a számlát, és általában rossz lépés, a mérés pedig megmondja, miért.

A tizenkét üzenetes windowra csonkítás 57 %-kal olcsóbb, mint mindent uncached elküldeni — ezt az összehasonlítást teszi mindenki, és ezért népszerű a technika. De 39 %-kal drágább, mint mindent működő cache-sel elküldeni, és a caching bekapcsolása csonkítás mellett kicsit ront, nem javít.

A mechanizmus megint a prefix. Egy csúszó window minden körben eldobja a legrégebbi üzenetet, ezért a prompt már nem ott kezdődik, ahol legutóbb kezdődött, és minden kör új prefixet mutat. Az OpenAI útmutatása pontosan ezt mondja: „a summarisation, compaction vagy context truncation megváltoztathatja a prefixet, és lenullázhatja a cache reuse-t.”⁶ A 40. körre a windowed prompt 813 token, az 1 024 tokenes minimum alatt, így egyáltalán nem cache-elhető.

A pénz pedig a költség olcsóbbik fele. Amit eldobtál, az a felhasználó 2. körben adott utasítása, amelyre a modelnek a 40. körben szüksége volt. A truncation egy látható számlát cserél egy láthatatlan hibára, és ezt rendesen csinálni — compaction, a windowon kívül tartott strukturált jegyzetek, előzmények igény szerinti retrievalje — a 24. fejezet témája.

A hosszú kontextusok nem pusztán azért drágábbak, mert hosszabbak. Egy küszöb felett tokenenként is drágábbak, és a küszöb visszamenőleg az egész promptra vonatkozik.

Az OpenAI gpt-5.6-terra modeloldala egyetlen mondatban kimondja: „A >272K input tokens promptok 2× input és 1,5× output áron kerülnek számlázásra a teljes kérésre.”⁷ Nem a többletre. Az egészre.

prompt 271,999 + 500 output  ->  $0.5500
prompt 272,000 + 500 output  ->  $0.5500
prompt 272,001 + 500 output  ->  $1.0970

Egy token, ötvenöt cent. Ha a szolgáltatásod olyan retrieved dokumentumokból épít promptokat, amelyek méretét nem te kontrollálod, akkor van egy szakadék a költségmodelledben egy olyan határon, amelyet senki a csapatodból nem írt le.

A Google árazása ugyanígy működik 200 000 tokenes küszöbbel: a Gemini 2.5 Pro $1.25 per millió input token a legfeljebb 200K-s promptoknál, és $2.50 felette, az output pedig $10.00-ról $15.00-ra nő.⁸ Az Anthropic a másik irányba ment — 2026. szeptember 6-án a dokumentációja azt írta, hogy a Claude 4.6 és későbbi modellek a teljes egymillió-tokenes windowt standard árazással tartalmazzák, így „egy 900k-token request ugyanazon a tokenenkénti díjon kerül számlázásra, mint egy 9k-token request.”⁹ A korábbi modellek megtartották a felárat.

Ezért az ár nem egy szám. Az ár prompt-hossz alapján kulcsolt sávok táblázata; ezért van a(z) Tier[] a költségfüggvényben, és ezért választja ki a(z) computeCost a sávot a teljes prompt alapján, nem kosaranként külön.

Az öt kosár a 13. fejezet két fázisára képezhető le, és ha ezt a leképezést meglátod, az árarányok már nem tűnnek önkényesnek.

Az input tokens a prefill. A teljes prompt egy menetben megy át a modellen, párhuzamos feldolgozással — nagy mátrixszorzások, compute-bound. A tokenenkénti költség alacsony, és ez a fázis határozza meg a time to first token értéket: egy 4 947 tokenes promptnál 4 947 tokennyi prefillt kell elvégezni, mielőtt az első szó megjelenik.

Az output tokens a decode. Egyenként keletkeznek, mindegyik egy teljes forward pass, amely beolvassa az egész KV cache-t, miközben a GPU többnyire memóriára vár, nem számol. Ez a fázis határozza meg a tokens per second értéket, egy válaszon belül nem párhuzamosítható, és ezért kerül az output körülbelül hatszor annyiba, mint az input az itt árazott modellen: $12.00 szemben $2.00 per millió tokennel.

Három következmény közvetlenül adódik. Egy cache read prefill munkát vált ki, tehát egyszerre vesz késleltetést és pénzt — ugyanaz a kedvezmény alacsonyabb számlában és rövidebb várakozásban jelenik meg az első tokenig. A reasoning tokens olyan decode, amit soha nem látsz, ezért egy reasoning model több másodpercig semmit sem streamel, majd gyorsan válaszol: a 12. fejezet az interfész-következményre figyelmeztetett, ez pedig a számla-következmény. És egy stream megszakítása nem állítja le a generálást — a 14. fejezet megépítette a lemondást, az árát erre a fejezetre hagyta, az ár pedig a teljes output count, mert a tokenek létrejönnek és számlázódnak, akár figyel valaki, akár nem. Ugyanez igaz arra a válaszra is, amelyet senki sem tart meg: egy 40. körös válasz ötszöri újragenerálása $0.057990-ba kerül azért az egyért, amely a képernyőn marad.

A 7. fejezet tokenizálója Python volt, és ott is maradt. A budgetelés abban a szerverben történik, amely a kérést összeállítja, ezért itt kell megtörténnie, és pontosan három pontossági szint létezik.

Első szint: számolj lokálisan. A(z) js-tiktoken ugyanazokat a BPE merge táblákat szállítja, mint a Python tiktoken, így OpenAI encodingoknál byte-ról byte-ra azonos countot ad hálózati hívás nélkül:

import { getEncoding } from "js-tiktoken";

const enc = getEncoding("o200k_base");
const PER_MESSAGE = 4;   // role and delimiters added by the chat template
const PER_REPLY = 3;     // priming for the assistant turn

export function promptTokens(messages: { role: string; content: string }[]) {
  return messages.reduce(
    (sum, m) => sum + enc.encode(m.content).length + PER_MESSAGE, PER_REPLY);
}

A két konstans számít, és itt kezdenek elsodródni a lokális countok. Nem a szöveged kerül tokenizálásra — a 11. fejezet chat template-je előbb minden üzenetet role markerekkel csomagol be, és ezek olyan tokenek, amelyekért fizetsz. Üzenetenként négy, a reply priminghoz három a szokásos közelítés OpenAI chat modelleknél; a fenti beszélgetés nyolcvanegy üzenetén ezek 324 tokent adnak ki, a hossz 6,4 %-át. Az itteni countokat a 7. fejezet Python tiktoken kódjával keresztellenőriztük mind a nyolcvanegy stringen, és azonosak.

Második szint: kérdezd a providert. Az Anthropic /v1/messages/count_tokens végpontot, a Google count_tokens végpontot ad, mindkettő ugyanazt a request shape-et fogadja, mint egy valódi hívás, és ingyen input token countot ad vissza. Használd őket, amikor nem tudsz lokálisan számolni — és Anthropicnál nem tudsz lokálisan számolni, mert a tokenizálója nincs publikálva. Az Anthropic dokumentációja óvatosan fogalmaz arról, mit ad: a count „becslés”, és „tartalmazhat Anthropic által automatikusan hozzáadott tokeneket system optimalizációkhoz”, amelyekért „nem számláznak”.¹⁰

Harmadik szint: olvasd ki a(z) usage mezőt a válaszból. Ez az igazság, és azután érkezik, hogy a pénzt elköltötted. Pontosan ezért létezik az első két szint — hogy eldöntsd, elküldöd-e a kérést, nem azért, hogy számlázz.

Négy tétel, amely nem jelenik meg tételként.

A system prompt, minden hívásnál fizetve. A fenti a template overheadjével együtt 192 token. Negyven híváson át ez 7 680 token — a beszélgetés teljes számlájának 5,6 %-a, nyolc egyszer megírt sorért. Egyben a lehető legjobb cache-jelölt is, mert stabil és első.

Tool-definíciók. Minden tool neve, leírása és JSON sémája minden kérésben kimegy, és a providerek erre még scaffoldingot is tesznek. Az Anthropic közzéteszi a számot: a toolok engedélyezése önmagában 496 tokennyi rejtett system promptot ad hozzá Claude Sonnet 4.5-nél, ha a(z) tool_choice értéke auto, vagy 588-at any, illetve named tool esetén.⁹ Ez még a saját sémáid előtt van. A 18. fejezet felépíti a katalógust; a 24. fejezet megméri, mit eszik meg.

Minden generálás, azok is, amelyeket eldobasz. Öt regenerálás ötször annyiba kerül. A chat egyet mutat.

Gondolatok, amelyeket nem mutatnak meg. A számlázás a teljes thought tokens alapján történik, bár csak összefoglaló tér vissza, és a saját könyvelésed nem tudja auditálni ezt a számot.

Zárásként egy figyelmeztetés, mert ez a természetes következő gondolat, és a válasz nem az, ami kézenfekvő.

Az egymillió-tokenes window nem jelent egymillió használható tokent. A retrieval pontossága romlik a pozícióval: Liu és mtsai. azt találták, hogy a modellek megbízhatóan találják meg az információt egy hosszú input elején és végén, a közepén viszont jóval kevésbé.¹¹ A nagyobb window azt veszi meg, hogy többet küldhetsz, nem azt, hogy biztosan el is olvassa.

Ezt a jelenséget a kurzus egyszer méri — a retrieval rate-et kilenc pozíción ugyanabban a 853 tokenes promptban —, és a 24. fejezethez tartozik, ahol megváltoztatja, mit csinál egy agent. Azért hivatkozunk rá itt, mert megváltoztatja, mit érdemes megvenned: a legolcsóbb token az, amit el sem küldtél.

Most már meg tudod jósolni, mennyibe fog kerülni egy hívás, mielőtt elküldöd, ki tudod olvasni utólag, mennyibe került, és meg tudod különböztetni a kettőt. Ez mindent lefed a kérésről, kivéve azt a részt, amihez még nem nyúltál: a tekerőket.

A 17. fejezet a sampling — temperature, top-p, top-k, a büntetések, és az a determinizmus, amid nincs. Azzal kezd, hogy lebontja a terület legelterjedtebb tévedését: hogy a temperature kreativitás-tekerő. Nem az: a temperature a 4. fejezet logitjait osztja el a softmax előtt, és ha növeled, nem kreatívabbá teszed a modelt, hanem növeled azoknak a tokeneknek a valószínűségét, amelyeket maga a model rosszabbnak pontozott. Innen jön, hogy a greedy decoding miért ad mérhetően rosszabb szöveget, mint a sampling, miért bukik el a top-k és a top-p ellentétes eloszlásformákon, és a fejezetet záró kísérlet: húsz azonos forward pass temperature 0 mellett bitről bitre azonosan tér vissza, amikor a model egyedül fut, és ugyanazt a promptot valaki más kérései mellé batchbe téve a logitok 97 %-a elmozdul.

Nem mind egyezik. Az ok a 2. fejezet lebegőpontos dobozával kezdődik.

A fejezetben szereplő összes árat, küszöböt és szorzót a providerek saját oldalairól olvastuk 2026. szeptember 6-án, és azért szerepel mellettük a dátum, mert változni fognak. A módszer fontosabb, mint a számok: a kosarak, a prefix-szabály és a sávszámítás két éve stabilak, miközben bennük minden szám megmozdult.

A Stanford CS336 2. előadása, Resource accounting, ennek az anyagnak a legközelebbi akadémiai feldolgozása és a megfelelő következő olvasmány: ugyanazt a számtant végzi el a training oldalon, amelyet ez a fejezet az inference oldalon. Az itteni token countokat a(z) js-tiktoken 1.0.21 készítette a(z) o200k_base és cl100k_base encodingokkal, egy 5 090 tokenes, negyvenkörös beszélgetésen; az üzenetenkénti template overhead a szokásos négy-plusz-három közelítés, és mindenhol jelezzük, ahol benne van. A cache-, sáv- és truncation-számok a dokumentált árazási szabályok alkalmazásai ezekre a mért token countokra, nem élő API-válaszok megfigyelései — a fejezet elkészítéséhez nem történt fizetős hívás, ami egyben az őszinte oka annak is, hogy a latency-állítások kvalitatívak, a költségállítások viszont nem.