Context window, tokeny i rachunek — zmierzone

Najdroższym błędnym przekonaniem w tej branży jest to, że model pamięta rozmowę.

Nie pamięta, a mechanizm z rozdziału 13 mówi dokładnie dlaczego. Stan transformera podczas generowania to KV cache: keys i values policzone dla każdego tokena w sekwencji. Ten cache żyje przez czas trwania jednego requestu. Gdy request się kończy, proces, który go trzymał, może obsłużyć kogoś innego, a cache znika. Po drugiej stronie nie ma per-user store ani sesji.

Następny request musi więc przyjść z wszystkim, co model ma wiedzieć, a model odbudowuje ten stan, wykonując forward pass przez cały prompt, zanim wyemituje choćby jeden nowy token. Rozdział 15 nazwał prompt „całym stanem”. Oto fizyczny powód: prompt jest kompletnym stanem, bo nic innego nie przeżywa wywołania.

Context window to maksymalna długość tego promptu plus jego odpowiedzi. To sufit określający, ile stanu możesz odbudować, a nie pojemnik, który przechowuje cokolwiek między requestami. Nazywanie go „pamięcią modelu” odwraca kierunek przyczynowości — nie wypełniasz pamięci, tylko płacisz za jej ponowne ustanowienie.

Stąd bierze się te dwadzieścia dwa. Tura $n$ niesie wszystkie $n-1$ poprzednie tury, więc łączny input w rozmowie o $n$ turach jest sumą rosnącego szeregu, czyli jest kwadratowy:

gdzie $s$ to system prompt, a $h_i$ to historia w turze $i$. Dopasowanie zmierzonego skumulowanego inputu do $an^2 + bn$ na przestrzeni czterdziestu tur daje $60.22\,n^2 + 432.25\,n$, co przewiduje 113 645 tokenów w turze 40 wobec 112 617 zmierzonych. Człon kwadratowy dominuje, a człon liniowy jest tym, co użytkownik naprawdę wpisał.

Konsekwencją jest zdanie, które warto wynieść z tego rozdziału: twój rachunek rośnie z kwadratem rozmowy, nie z ostatnim pytaniem. Te same czterdzieści pytań zadanych bez żadnej historii kosztuje $0.066036. Utrzymanie historii kosztowało $0.274386. Historia pomnożyła rachunek przez 4,2 i będzie mnożyć dalej, bo mnożnikiem jest długość rozmowy.

Okno jest skończone z dwóch powodów, które ciągną w tę samą stronę. Pierwszy to powód z rozdziału 9: attention porównuje każdy token z każdym innym tokenem, więc praca tej warstwy rośnie z kwadratem długości sekwencji. Drugi to pamięć: KV cache rośnie liniowo z długością sekwencji, a rozdział 13 wykonał tę arytmetykę — przy długich sekwencjach jest większy niż weights.

Oba limity atakowano i żadnego nie usunięto. FlashAttention¹ reorganizuje obliczenia tak, by znacznie mniej czytać i zapisywać w pamięci o dużej przepustowości, co czyni długie sekwencje praktycznymi bez zmiany kosztu asymptotycznego. Position Interpolation² i YaRN³ rozszerzają użyteczne okno wytrenowanego modelu przez przeskalowanie positional encodings z rozdziału 9 zamiast retrainingu. Razem wyjaśniają, dlaczego okna urosły z 2K do 1M w pięć lat.

Nie sprawiły jednak, że długie contexts stały się darmowe. Podniosły sufit i złagodziły nachylenie. Nachylenie wciąż istnieje i to właśnie mierzą tier cenowe w dalszej części tego rozdziału.

Prawie każdy kalkulator kosztów w internecie modeluje wywołanie API jako input tokens razy cena inputu plus output tokens razy cena outputu. To było prawdziwe w 2023 roku. Dziś jest błędne w sposób, który potrafi rozjechać rachunek o czynnik dwa albo więcej w obie strony.

Istnieje pięć rozliczalnych kategorii tokenów:

Trzy z tych pięciu nie istniały jako osobne pozycje dwa lata temu, a dwie linie cache są tym, co ludzie mylą najczęściej, bo cache write kosztuje więcej niż zwykły input, nie mniej. Płacisz premię za zapisanie czegoś, żeby potem zapłacić mniej za odczyt, a opłacalność tej wymiany zależy wyłącznie od tego, ile razy to odczytasz.

Koszyk reasoning należy do rozdziału 12, teraz z ceną, i niesie szczegół, który warto powiedzieć wprost: dokumentacja Google mówi, że pricing „is based on the full thought tokens the model needs to generate, despite only the summary being output from the API”.⁴ Rozliczane są tokens, które nigdy nie są do ciebie transmitowane. To jedyny koszyk, którego zawartości nie możesz policzyć, obejrzeć ani zweryfikować.

Teraz część, która robi z tego problem normalizacji, a nie mnożenia. Każdy provider raportuje te koszyki pod innymi nazwami i — to jest pułapka — dwóch z nich używa tego samego słowa dla dwóch różnych wielkości.

Weź jedno wywołanie: 4 837 tokenów odczytanych z cache, 110 świeżych, 142 widoczne output tokens, 300 reasoning tokens.

// 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 } }

Spójrz na prompt_tokens: 4947 i input_tokens: 110. Oba pola są liczbą input tokens dla tego samego promptu. Pole OpenAI zawiera cached tokens; pole Anthropic je wyklucza — jego dokumentacja podaje tożsamość wprost, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Anthropicowe input_tokens oznacza „tokens po ostatnim cache breakpoint”.

Spójrz też na output. OpenAI i Anthropic raportują 442, co już zawiera 300 reasoning tokens. Gemini raportuje 142 i wkłada 300 do osobnego pola. Rozdział 12 oznaczył to jako niekompatybilność między dwoma sposobami liczenia tej samej pracy; tutaj widać, ile to kosztuje.

Normalizator ma trzydzieści linii i nie jest opcjonalny:

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
  };
};

Przepuść trzy powyższe payloady przez trzy readery, a wszystkie trzy wyprodukują to samo Usage, a więc tę samą kwotę: $0.006491. Ta zgodność jest całym sensem pisania tej warstwy.

Pomyłka kosztuje tak, dla tego samego wywołania:

Trzeci jest niebezpieczny, bo zawodzi po cichu w kierunku dobrych wiadomości. Dashboard pokazuje, że reasoning model kosztuje mniej niż połowę realnego kosztu, i nigdzie nic nie zgłasza błędu.

Po znormalizowaniu koszyków funkcja kosztu jest krótka. Jedyna nieoczywista część to lookup tier, który wyjaśnia następna sekcja:

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);
}

Warto bronić dwóch decyzji projektowych. Fallbacki — ceny cache spadające do inputu, reasoning do outputu — kodują znaczenie brakującej tabeli: reasoning tokens w Gemini są rozliczane według stawki outputu, więc brak ceny reasoning nie oznacza zera, tylko cenę outputu. A contextSize sumuje wszystkie trzy koszyki inputu, nie tylko świeże, bo tier wybiera się według długości promptu, a nie według tego, za ile z niego zapłaciłeś pełną cenę.

Prompt cache przechowuje obliczony stan modelu dla prefiksu twojego promptu, więc późniejszy request z tym samym prefiksem pomija jego ponowne liczenie. Ze słowa „prefiks” wynikają cztery własności i wszystkie cztery zaskakują ludzi.

Próg opłacalności jest na tyle mały, że da się go trzymać w głowie, a dokumentacja OpenAI robi rachunek: zapisanie prefiksu raz i użycie go ponownie raz kosztuje 1,35× zwykłego kosztu inputu, wobec 2× za przetworzenie go dwa razy bez cache; w dziesięciu requestach jeden zapis i dziewięć odczytów kosztują 2,15× wobec 10×. Jedno ponowne użycie spłaca zapis. Anthropic ląduje w tym samym miejscu: jeden odczyt dla cache pięciominutowego, dwa dla godzinnego.

Teraz znów czterdziestoturowa rozmowa, z włączonym caching i stabilnym prefiksem:

O sześćdziesiąt osiem procent taniej, a trzy liczby w tej tabeli są warte uwagi.

Cache nie włącza się aż do tury 6. Prompt nie osiąga 1 024 tokenów wcześniej, więc pierwsze pięć tur jest rozliczane dokładnie jak przedtem — a szósta jest rozliczana gorzej, z premią 1,25× za zapis, bo to tura, która wypełnia cache. Pierwszy odczyt przychodzi w turze 7. 2 887 uncached tokens w tabeli to arytmetyka: pięć tur, nie sześć. Caching jest rabatem na długie prompty, a krótka rozmowa nic z niego nie ma.

Premia za zapis to $0.002474, czyli 2,8 % rachunku z cache. Każda tura zapisuje nowy ogon, czterdzieści razy, a cała premia za zapis jest błędem zaokrąglenia wobec tego, co oszczędziły odczyty. Opłatę za zapis warto rozumieć precyzyjnie po to, żeby przestać się nią martwić.

Tylko 2 887 tokenów rozliczono po pełnej cenie inputu z 112 617. Tak wygląda działający cache: prawie wszystko jest odczytem.

Oto awaria, która kosztuje prawdziwe pieniądze, i jest jednolinijkowym bugiem.

Umieść coś, co zmienia się przy każdym wywołaniu, blisko początku promptu — timestamp, request id, imię użytkownika, linię „dziś jest”, świeżo pobrany dokument — a prefiks różni się od pierwszego bajtu. Nic nie pasuje. Każde wywołanie jest pudłem. A ponieważ każde wywołanie prezentuje nowy prefiks, każde wywołanie także zapisuje.

Ta sama rozmowa, te same czterdzieści tur, włączony caching, z timestampem per call na górze system promptu:

Włączenie prompt caching uczyniło rozmowę o dwadzieścia procent droższą niż niewłączanie go. Zapłaciłeś premię 1,25× za zapis na 109 730 tokenach i odczytałeś z powrotem zero. Nie ma błędu, nie ma warningu, a funkcja jest włączona.

Zasada, czyli całe prompt caching w jednym zdaniu: stabilna treść z przodu, zmienna treść z tyłu. System instructions, definicje tooli i materiały referencyjne najpierw; timestamps, tożsamość użytkownika i bieżące pytanie na końcu. Anthropic pokazuje hierarchię wprost — cache podąża za tools → system → messages, a zmiana na dowolnym poziomie unieważnia ten poziom i wszystko po nim, więc edycja jednego opisu toola unieważnia cały cache.⁵

Dwie konsekwencje często podcinają nogi. Zmiana tego, które tools są włączone, zmienia definicje tooli, więc feature flag dodający tool dla części użytkowników dzieli cache na dwa. A w Anthropic przełączenie web search albo citations modyfikuje system prompt, co unieważnia cache systemu i wiadomości bez dotykania choćby jednej linijki twojego tekstu.

Oczywistą odpowiedzią na kwadratowy rachunek jest przestać wysyłać całą historię: zachować ostatni tuzin wiadomości i wyrzucić resztę. To obniża rachunek, zwykle jest złym ruchem, a pomiar pokazuje dlaczego.

Ucięcie do okna dwunastu wiadomości jest o 57 % tańsze niż wysyłanie wszystkiego bez cache — to porównanie robią wszyscy i dlatego ta technika jest popularna. Ale jest o 39 % droższe niż wysyłanie wszystkiego z działającym cache, a włączenie caching razem z truncation pogarsza wynik zamiast go poprawić.

Mechanizmem znów jest prefiks. Sliding window wyrzuca najstarszą wiadomość w każdej turze, więc prompt nie zaczyna się już tam, gdzie zaczynał się poprzednio, i każda tura prezentuje nowy prefiks. Wskazówka OpenAI mówi dokładnie to: „summarisation, compaction, or context truncation can change the prefix and reset cache reuse”.⁶ W turze 40 prompt okienkowy ma 813 tokenów, poniżej minimum 1 024 tokenów, więc w ogóle nie może zostać zcacheowany.

A pieniądze są tańszą połową kosztu. To, co wyrzuciłeś, to instrukcja, którą użytkownik dał w turze 2 i której model potrzebował w turze 40. Truncation zamienia widoczny rachunek na niewidoczną awarię, a robienie tego dobrze — compaction, structured notes trzymane poza oknem, pobieranie historii na żądanie — jest tematem rozdziału 24.

Długie contexts są droższe nie tylko dlatego, że są dłuższe. Po przekroczeniu progu są droższe per token, a próg działa wstecznie na cały prompt.

Strona modelu OpenAI dla gpt-5.6-terra mówi to jednym zdaniem: „Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request”.⁷ Nie za nadwyżkę. Za całość.

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

Jeden token, pięćdziesiąt pięć centów. Jeśli twój serwis buduje prompty z pobranych dokumentów, których rozmiaru nie kontrolujesz, masz w modelu kosztowym klif na granicy, której nikt w zespole nie zapisał.

Pricing Google działa tak samo z progiem 200 000 tokenów: Gemini 2.5 Pro kosztuje $1.25 za milion input tokens dla promptów do 200K i $2.50 powyżej, przy output rosnącym z $10.00 do $15.00.⁸ Anthropic poszedł w drugą stronę — według dokumentacji z 6 września 2026 Claude 4.6 i późniejsze obejmują pełne jednomilionowe context window w standardowej cenie, więc „a 900k-token request is billed at the same per-token rate as a 9k-token request”.⁹ Wcześniejsze modele utrzymywały dopłatę.

Dlatego cena nie jest liczbą. Cena jest tabelą tier indeksowanych długością promptu — po to w funkcji kosztu jest Tier[] — i dlatego computeCost wybiera tier przy użyciu całego promptu, a nie każdego koszyka osobno.

Pięć koszyków mapuje się na dwie fazy z rozdziału 13, a gdy zobaczysz mapowanie, relacje cen przestają wyglądać arbitralnie.

Input tokens to prefill. Cały prompt przechodzi przez model w jednym przebiegu, przetwarzany równolegle — duże mnożenia macierzy, compute-bound. Koszt per token jest niski i to ta faza ustala time to first token: prompt o długości 4 947 tokenów ma 4 947 tokenów prefill do wykonania, zanim pojawi się pierwsze słowo.

Output tokens to decode. Są produkowane po jednym, każdy jako pełny forward pass czytający cały KV cache, z GPU głównie czekającym na pamięć zamiast liczyć. To ta faza ustala tokens per second, nie da się jej zrównoleglić wewnątrz jednej odpowiedzi i dlatego output kosztuje około sześć razy więcej niż input w modelu wycenianym tutaj: $12.00 wobec $2.00 za milion tokenów.

Z tego wynikają trzy bezpośrednie konsekwencje. Cache read zastępuje pracę prefill, więc kupuje naraz latency i pieniądze — ten sam rabat widać jako niższy rachunek i krótsze czekanie na pierwszy token. Reasoning tokens to decode, którego nigdy nie widzisz, dlatego reasoning model przez kilka sekund nic nie streamuje, a potem szybko odpowiada: rozdział 12 ostrzegał przed konsekwencją w interfejsie, a to jest konsekwencja na fakturze. I przerwanie streamu nie zatrzymuje generowania — rozdział 14 zbudował cancellation i zostawił cenę temu rozdziałowi, a ceną jest pełna liczba output, bo tokeny są produkowane i rozliczane niezależnie od tego, czy ktokolwiek słucha. To samo dotyczy odpowiedzi, której nikt nie zachowuje: pięć regeneracji odpowiedzi w turze 40 kosztuje $0.057990 za tę jedną pozostawioną na ekranie.

Tokenizer z rozdziału 7 był w Pythonie i tam został. Budżetowanie dzieje się na serwerze, który buduje request, więc musi dziać się tutaj, i istnieją dokładnie trzy poziomy dokładności.

Poziom pierwszy: licz lokalnie. js-tiktoken dostarcza te same tabele BPE merge co pythonowy tiktoken, więc dostajesz byte-for-byte identyczne liczenie dla OpenAI encodings, bez wywołania sieciowego:

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);
}

Dwie stałe mają znaczenie i to w nich lokalne liczenia odpływają. Twój tekst nie jest tym, co trafia do tokenizacji — chat template z rozdziału 11 najpierw owija każdą wiadomość markerami ról, a to są tokeny, za które płacisz. Cztery na wiadomość i trzy na reply priming to zwyczajowe przybliżenie dla modeli chat OpenAI; dla osiemdziesięciu jeden wiadomości z powyższej rozmowy daje to 324 tokeny, 6,4 % jej długości. Liczenia tutaj zostały sprawdzone względem pythonowego tiktoken z rozdziału 7 na wszystkich osiemdziesięciu jeden stringach i są identyczne.

Poziom drugi: zapytaj providera. Anthropic udostępnia /v1/messages/count_tokens, a Google count_tokens; oba przyjmują ten sam kształt requestu co realne wywołanie i zwracają liczbę input tokens za darmo. Używaj ich, gdy nie możesz liczyć lokalnie — a dla Anthropic nie możesz, bo jego tokenizer nie jest opublikowany. Dokumentacja Anthropic ostrożnie mówi, co daje: count „is an estimate” i „may include tokens added automatically by Anthropic for system optimizations”, za które „you are not billed”.¹⁰

Poziom trzeci: czytaj usage w odpowiedzi. To jest prawda i przychodzi po wydaniu pieniędzy. Właśnie dlatego istnieją dwa pierwsze poziomy — żeby zdecydować, czy wysłać request, a nie żeby go rozliczyć.

Cztery pozycje, które nie pojawiają się jako pozycje.

System prompt, opłacany przy każdym wywołaniu. Ten powyżej ma 192 tokeny z narzutem template. Przez czterdzieści wywołań daje to 7 680 tokenów — 5,6 % całego rachunku tej rozmowy, za osiem linii napisanych raz. To także najlepszy możliwy kandydat do cache, bo jest stabilny i pierwszy.

Definicje tooli. Nazwa, opis i JSON schema każdego toola wychodzą w każdym requeście, a providerzy dodają na to scaffolding. Anthropic publikuje liczbę: samo włączenie tools dodaje ukryty system prompt o długości 496 tokenów w Claude Sonnet 4.5 z tool_choice ustawionym na auto albo 588 z any lub named tool.⁹ To jeszcze przed twoimi schema. Rozdział 18 buduje katalog; rozdział 24 mierzy, ile on zjada.

Każde generowanie, także te odrzucone. Pięć regeneracji kosztuje pięć razy. Chat pokazuje jedną.

Myśli, których ci nie pokazano. Rozliczenie opiera się na pełnych thought tokens, choć zwracane jest tylko summary, a twoja księgowość nie może zaudytować tej liczby.

Jedno ostrzeżenie na koniec, bo to naturalna kolejna myśl, a odpowiedź nie jest oczywista.

Milionowe context window nie oznacza miliona użytecznych tokenów. Dokładność retrieval pogarsza się wraz z pozycją: Liu i wsp. odkryli, że modele niezawodnie lokalizują informacje na początku i na końcu długiego inputu, a znacznie gorzej w środku.¹¹ Większe okno kupuje możliwość wysłania więcej, nie pewność, że zostanie to przeczytane.

To zjawisko jest mierzone w tym kursie raz — retrieval rate w dziewięciu pozycjach tego samego promptu o długości 853 tokenów — i należy do rozdziału 24, gdzie zmienia to, co robi agent. Jest cytowane tutaj, bo zmienia to, co powinieneś kupować: najtańszy token to ten, którego nie wysłałeś.

Umiesz już przewidzieć koszt wywołania przed jego wykonaniem, odczytać rzeczywisty koszt po fakcie i odróżnić jedno od drugiego. To obejmuje wszystko w requeście poza częścią, której jeszcze nie dotknąłeś: pokrętłami.

Rozdział 17 to sampling — temperature, top-p, top-k, penalties i determinizm, którego nie masz. Zaczyna od rozbrojenia najbardziej rozpowszechnionego błędu w branży: że temperature jest pokrętłem kreatywności. Nie jest: temperature dzieli logits z rozdziału 4 przed softmax, a jego podniesienie nie sprawia, że model staje się pomysłowy; podnosi prawdopodobieństwo tokenów, które sam model ocenił jako gorsze. Dalej: dlaczego greedy decoding daje mierzalnie gorszy tekst niż sampling, dlaczego top-k i top-p zawodzą na przeciwnych kształtach rozkładu, oraz eksperyment kończący rozdział: dwadzieścia identycznych forward passes przy temperature 0 wraca bit w bit identycznych, gdy model działa sam, a włożenie tego samego promptu do batch obok requestów kogoś innego przesuwa 97 % jego logits.

Nie wszystkie się zgadzają. Powód zaczyna się od ramki o floating-point z rozdziału 2.

Wszystkie ceny, progi i mnożniki w tym rozdziale zostały odczytane z własnych stron providerów 6 września 2026 i podane z tą datą, ponieważ się zmienią. Metoda jest ważniejsza niż liczby: koszyki, reguła prefiksu i arytmetyka tier są stabilne od dwóch lat, podczas gdy każda liczba w nich się poruszyła.

Stanford CS336 lecture 2, Resource accounting, jest najbliższym akademickim omówieniem tego materiału i właściwą kolejną lekturą: wykonuje tę samą arytmetykę po stronie trainingu, którą ten rozdział wykonuje po stronie inference. Liczby tokenów tutaj wyprodukowano z js-tiktoken 1.0.21 przy użyciu encodings o200k_base i cl100k_base, na czterdziestoturowej rozmowie o długości 5 090 tokenów; narzut template per message to konwencjonalne przybliżenie cztery-plus-trzy i jest wskazany wszędzie tam, gdzie został uwzględniony. Dane cache, tier i truncation to udokumentowane reguły pricing zastosowane do tych zmierzonych liczby tokenów, nie obserwacje z live API responses — nie wykonano żadnego płatnego wywołania, aby przygotować ten rozdział, co jest też uczciwym powodem, dla którego twierdzenia o latency są jakościowe, a twierdzenia o kosztach nie.