Fine-tune, retrieval czy prompt? Decyzja jest ekonomiczna

„Czy powinniśmy zrobić fine-tuning?” brzmi tak, jakby było pytaniem o model. Jest pytaniem o budżet, w kształcie, na który nie odpowiada żaden benchmark: za co płaci się raz, za co płaci się przy każdym pytaniu i za co płaci się ponownie za każdym razem, gdy świat się zmienia.

Te trzy ścieżki nie są też trzema sposobami robienia tej samej rzeczy, a dostawcy mówią to jaśniej niż większość wpisów blogowych. Własna tabela OpenAI pokazująca, do czego supervised fine-tuning jest najlepszy, wymienia cztery zastosowania: klasyfikację, niuansowane tłumaczenie, generowanie treści w określonym formacie i korygowanie porażek w podążaniu za instrukcjami.¹ Żadne z nich nie brzmi „nauczyć model czegoś, czego nie wie”. Podsumowanie korzyści mówi, że „możesz używać krótszych promptów z mniejszą liczbą przykładów i danych kontekstowych, co oszczędza koszty tokenów w skali i może obniżyć opóźnienie” — argument o fakturze, od firmy sprzedającej tę funkcję.

A więc:

• Fine-tuning uczy formy i zachowania. Tonu, formatu, kształtu odpowiedzi, granicy, którą da się pokazać, ale nie opisać. Najmocniejszą opublikowaną wersją jest hipoteza Superficial Alignment z LIMA: wiedza pochodzi z pretrainingu, alignment uczy głównie, w której poddystrybucji formatów mówić — dlatego tysiąc starannie dobranych przykładów tam wystarczył.²
• Retrieval dostarcza fakty, które się zmieniają. To jedyna z tych trzech ścieżek, w której edycja dokumentacji dociera do odpowiedzi bez dotykania modelu.
• Prompting obejmuje większość prawdziwych przypadków i jest uczciwym punktem odniesienia. In-context learning jest domyślny od Language Models are Few-Shot Learners: zadanie jest demonstrowane wewnątrz promptu i żadna waga się nie rusza.³

Dwa mierzone artykuły zamykają drzwi przed błędem pośrodku. Ovadia i współpracownicy porównali wstrzykiwanie wiedzy przez unsupervised fine-tuning ze wstrzykiwaniem jej przez retrieval, a retrieval wygrywał konsekwentnie, także na faktach, które model bazowy widział już w pretrainingu.⁴ Gekhman i współpracownicy zmierzyli szkody: przykłady wprowadzające nową wiedzę są dopasowywane powoli, a gdy model w końcu je dopasowuje, jego poziom halucynacji przy innych pytaniach rośnie.⁵ Uczenie faktów przez fine-tuning nie tylko nie działa; pogarsza odpowiedzi, na których nie trenowałeś.

Ta połowa jest rozstrzygnięta. Ekonomiczna połowa nie jest, i to ona zajmuje resztę rozdziału.

Jeden przypadek, uruchomiony trzema sposobami: support techniczny na własnej dokumentacji, która zmienia się co tydzień.

Korpus jest prawdziwy i leży na tym dysku: 23 dokumenty Markdown, które pewne działające repozytorium oprogramowania trzyma jako dokumentację wewnętrzną — przewodnik build, reguły marki, brief tłumaczeniowy, dziesięć instrukcji usług, notatki o wydajności i bezpieczeństwie. Zmierzone za pomocą o200k_base, encodingu z Rozdziału 7:

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

Czterdzieści trzy tysiące tokenów to wygodny rozmiar dla tej decyzji: mieści się w każdym nowoczesnym oknie, więc wszystkie trzy ścieżki są naprawdę dostępne. Przy dziesięciu milionach decyzja jest podjęta za ciebie, i jest nią retrieval.

Teraz praca, którą wykonuje słowo „co tydzień”. Rotacja dokumentacji jest zwykle deklarowana; tutaj została policzona z historii wersji tego repozytorium:

Dokumenty ruszają się mniej więcej co drugi tydzień. Teksty widoczne dla użytkowników — czyli to, o co naprawdę pyta support — zmieniały się w każdym tygodniu swojego istnienia, przy około dwudziestu commitach tygodniowo. Jakąkolwiek ścieżkę wybierzemy, musi to przetrwać, a „jak często zmienia się rzecz, na której trenowałeś?” okazuje się mieć liczbę w twoim własnym repozytorium, a nie opinię.

Dwadzieścia realistycznych pytań supportowych napisano przeciwko temu korpusowi, po jednym na temat, a każda liczba poniżej jest liczona na tych dwudziestu.

Najprostsze rozwiązanie, które działa: włóż cały korpus do system promptu, pytanie na koniec i pozwól modelowi je znaleźć.

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

Każda liczba została tam policzona poza ostatnią: 150 tokenów wyjściowych to założenie, wybrane w zakresie tur asystenta rozliczanych w Rozdziale 16. To jedyna liczba tutaj, która nie została wykonana, jest stosowana identycznie do wszystkich trzech ścieżek, a sekcja break-even pokazuje dokładnie, jak bardzo wniosek przesuwa się, gdy ją zmieniasz.

Przy stawkach odczytanych ze strony dostawcy 7 września 2026 — $1.50 za milion tokenów wejściowych, $9.00 za milion wyjściowych⁶ — to $0.066317 za pytanie. Płacisz za ponowne przeczytanie czterdziestu trzech tysięcy tokenów, żeby odpowiedzieć na trzynaście.

Poprawka z Rozdziału 16 stosuje się bezpośrednio: korpus jest stabilny i jest na początku, więc jest idealnym prefiksem cache, a jego ponowny odczyt kosztuje jedną dziesiątą — $0.007864 za pytanie, cięcie o 88 %. Ostrzeżenie z Rozdziału 16 też się stosuje, w formie, którą tamten rozdział wskazał, ale nie wycenił. Ten dostawca nie nalicza premii za zapis; nalicza czynsz. Jawny cache kosztuje $0.000001 za przechowany token za godzinę,⁶ więc trzymanie 43,298 tokenów w gotowości kosztuje

niezależnie od tego, czy ktokolwiek o cokolwiek pyta. To $189.78 przez sześć miesięcy, za pusty pokój. Podziel czynsz przez oszczędność na pytaniu, a warunek wychodzi w jednej linijce: caching tego korpusu zwraca się powyżej 0.74 pytania na godzinę — 546 miesięcznie, gdy policzyć też cotygodniową odbudowę cache. Poniżej tego funkcja włączona dla oszczędności traci pieniądze.

Ta sama ścieżka, ten sam kod, jedna flaga, pięć razy większy rachunek. Rozdział 16 znalazł wersję tego problemu wywołaną znacznikiem czasu w złym miejscu; tutaj nic nie jest źle poza ruchem. Cache to zakład o wolumen, a u tego dostawcy stawiasz go na godzinę.

Retriever z Rozdziału 19, bez zmian: tnij na granicach sekcji z nagłówkiem kontekstowym, indeksuj, włóż cztery najlepsze fragmenty do promptu. Zmierzone na dwudziestu pytaniach:

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

Czterdzieści dwa razy mniej tokenów promptu niż w ścieżce pierwszej, przy $0.002906 za pytanie. Indeks kosztuje $0.0070 do zbudowania przy $0.15 za milion tokenów embedding⁶ — mniej niż równowartość trzech pytań — i tyle samo $0.0070 do pełnej odbudowy za każdym razem, gdy dokumentacja się zmienia. Odbudowywanie całego indeksu co tydzień przez sześć miesięcy kosztuje osiemnaście centów.

Na jednej rzeczy warto się zatrzymać. Retrieval niszczy prompt caching. Stabilnym prefiksem jest teraz 140-tokenowa instrukcja systemowa; od tokena 141 prompt różni się przy każdym wywołaniu, bo fragmenty są wybierane per pytanie. A 140 tokenów leży poniżej każdego minimum cache cytowanego w Rozdziale 16. Ścieżki drugiej nie da się więc cache’ować wcale, co brzmi źle, ale nie jest: brak cache dla 1,037 tokenów jest tańszy niż cache dla 43,298.

To ogólna reguła, którą warto zabrać dalej: dwie duże techniki oszczędzania tokenów wzajemnie się wykluczają na tej samej treści, a wygrywa ta, która usuwa więcej tokenów. Retrieval usuwa 97.6 % z nich.

Wytrenuj na dwustu przykładach w stylu firmowym, potem zadawaj pytania bez żadnej dołączonej dokumentacji.

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

Trening kosztuje 24,389 × 3 × $10.00 za milion = $0.7317. To cały koszt konstrukcji, mniej niż filiżanka kawy, i właśnie dlatego tak wiele zespołów płaci go, zanim sprawdzi, czy pomaga.

Teraz pułapka, i powód istnienia tego rozdziału. Model po fine-tuning nie kosztuje w uruchomieniu tyle samo co model bazowy. Strona z cenami mówi to jednym zdaniem: „for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.”⁶ Nie trening. Inference, na każdym tokenie, tak długo, jak model żyje.

Włóżmy to więc do wzoru. Niech $p_i$ i $p_o$ będą bazowymi cenami wejścia i wyjścia, $m$ mnożnikiem modelu tuned, $L_R$ długością promptu ścieżki, którą zastępujesz, $L_F$ długością promptu po fine-tuning, a $O$ długością odpowiedzi. Fine-tuning jest tańszy per pytanie tylko wtedy, gdy

Pierwszy składnik jest oczywisty: twój nowy krótki prompt, z narzutem. Drugi nie jest, i właśnie tam idą pieniądze — dopłata do odpowiedzi, która nie ma nic wspólnego z twoim promptem i której trening nie może skrócić. Przy zmierzonych liczbach — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — próg wynosi

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

Przy zmierzonej długości odpowiedzi: 492 tokeny — z czego 450 to dopłata do odpowiedzi, nie prompt. Zastąpienie krótszego promptu niż ten jest droższe per pytanie, na zawsze, przy dowolnym wolumenie; a próg rośnie liniowo z tym, ile mówi asystent, więc taki, który pisze długie odpowiedzi, nigdy nie zrobi fine-tuningiem tańszego tokena, choćby usunął dowolnie dużo promptu.

To samo z drugiej strony jest zdaniem do zapamiętania. Z $0.002088 kosztu ścieżki fine-tuned na pytanie 97.0 % stanowi odpowiedź. Fine-tuning optymalizuje pozostałe trzy procent.

Cztery liczby opisują każdą z tych ścieżek: ile płacisz raz, ile płacisz, gdy dokumentacja się zmienia, ile płacisz co godzinę niezależnie od ruchu i ile płacisz za pytanie. To rozszerza computeCost z Rozdziału 16 bez modyfikowania jej.

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

Model tuned nie jest innym cennikiem, tylko tym samym pomnożonym:

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

Ta jedna podświetlona linia to cały argument poprzedniej sekcji zapisany jako kod: mnożnik trafia też na output.

Sześć miesięcy, z dokumentacją odświeżaną co tydzień:

I punkty przecięcia, czyli cztery liczby, których budżet naprawdę potrzebuje:

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

Czytaj pierwsze dwie razem, bo są sednem rozdziału. Stacjonarny korpus sprawia, że fine-tuning zwraca się po stu pięćdziesięciu pytaniach; korpus zmieniający się co tydzień przesuwa ten sam punkt przecięcia o współczynnik dwudziestu siedmiu, a w modelu nie zmieniło się nic — tylko to, jak często płacisz za niego ponownie. Koszt konstrukcji to przypis; koszt utrzymania to decyzja.

Jeśli teraz wnioskujesz, że zapracowany support powinien zrobić fine-tuning, arytmetyka się z tobą zgadza. To wciąż błędne, a następna sekcja wyjaśnia dlaczego.

Arkusz kosztów ma jedną kolumnę, której nie potrafi policzyć, więc ta sekcja uruchamia fine-tune: lokalnie, na małym otwartym modelu, z adapterem napisanym ręcznie zamiast pobranym z biblioteki. Rozdział 11 zbudował LoRA; tutaj jest na q_proj i v_proj wszystkich 24 warstw Qwen2.5-0.5B-Instruct przy rank 8:

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

Dwieście przykładów treningowych powstaje mechanicznie z korpusu, więc da się je odtworzyć: pytanie to nagłówek sekcji zamieniony w pytanie, odpowiedź to własny tekst tej sekcji w sztywnym stylu firmowym — jedna linia zaczynająca się od Short answer:, jedna linia zaczynająca się od Source: ze ścieżką pliku. Format jest formą, której uczymy; ścieżka jest faktem. Potem dwie liczby na dwudziestu pytaniach held-out: czy odpowiedź wychodzi w stylu firmowym i czy nazywa plik, który naprawdę odpowiada na pytanie?

Dwa baseline’y czynią tabelę czytelną, a oba wynikają z uporu Rozdziału 4, nie z późniejszej refleksji. Dziesięć z dwudziestu poprawnych odpowiedzi to ten sam plik, więc model, który ignoruje pytanie i zawsze odpowiada CLAUDE.md, zdobywa 10/20. Retriever ma też własny sufit: w tych dwudziestu pytaniach jego cztery fragmenty zawierają właściwy plik 14 razy i ustawiają go na pierwszym miejscu 7 razy, więc 14/20 to maksimum, jakie mógłby osiągnąć dowolny czytelnik używający go.

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

Forma została nauczona, całkowicie i szybko. Od zera do dziewiętnastu na dwadzieścia, adapterem o 540,672 parametrach — 0.109 % modelu — w pięć minut treningu na procesorze bez karty graficznej w zasięgu wzroku.

Fakty nie zostały nauczone. Osiem na dwadzieścia jest nieodróżnialne od dziesięciu, które dostajesz, ignorując pytanie całkowicie, a przedział z Rozdziału 4 na dwudziestu próbkach mówi to głośno. Te ścieżki plików były w danych treningowych trzykrotnie; z modelu wyszedł nawyk kończenia wiarygodnie wyglądającą linią Source:. Zapytany o pytanie z początku tego rozdziału, model po fine-tuning odpowiedział Short answer: 10.x . . . i zacytował CLAUDE.md. Poprawna odpowiedź, która jest w CLAUDE.md, to 18.17.0.

A potem forma się rozpadła, co jest wierszem uzasadniającym eksperyment. Daj modelowi po fine-tuning tysiąc tokenów retrieved extracts — kształt promptu, którego nigdy nie widział, bo każdy prompt treningowy miał dwadzieścia osiem tokenów — a styl firmowy spada z 19/20 do 1/20. Na pytanie z początku tego rozdziału odpowiada 18.17.0 — poprawnie i bez żadnego formatu, dla którego był trenowany. Fine-tuning nie nauczył więc formatu; nauczył formatu warunkowego względem promptów w zbiorze treningowym, a pierwszy prompt, który wyglądał inaczej, zabrał format ze sobą. To, na czym robisz fine-tuning, staje się jedyną dystrybucją wejść, w której model jest dobry, i nikt nie wpisuje tego do arkusza kalkulacyjnego.

Ostatnia uwaga o metryce, prosto w stronę Rozdziału 29: „correct source” ocenia formę i fakt razem, dlatego oba wiersze retrieval wyglądają fatalnie, mimo że oba modele trafiły fakt dla tego pytania. Jedna liczba end-to-end ukrywała trzy rzeczy — retriever z recall 14/20, czytnik 0.5B i format cytowania — a wybór, co naprawić, wymaga ich rozdzielenia przed pomiarem, nie po.

Teraz kolumna, którą dostawcy wypełniają za ciebie. Model po fine-tuning nie jest aktywem, które posiadasz; jest dzierżawą cudzej bazy, z datą końcową wydrukowaną na umowie. 7 września 2026 sekcja fine-tuning na stronie cen OpenAI zawierała pełne ogłoszenie:

OpenAI wygasza platformę fine-tuning. Platforma nie jest już dostępna dla nowych użytkowników, ale dotychczasowi użytkownicy platformy fine-tuning będą mogli tworzyć zadania treningowe przez najbliższe miesiące. Wszystkie modele po fine-tuning pozostaną dostępne do inference, dopóki ich modele bazowe nie zostaną wycofane.⁷

Oś czasu jest rozpisana co do dnia: 7 maja 2026, zamknięcie dla organizacji, które nigdy nie robiły fine-tuning; 2 lipca 2026, zamknięcie dla tych, które nie uruchamiały inference na modelu po fine-tuning przez sześćdziesiąt dni; 6 stycznia 2027, brak nowych zadań w ogóle.⁸ Ta sama strona planuje zamknięcie samych modeli po fine-tuning — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — 23 października 2026, każdego z zalecanym zastępczym modelem bazowym, co jest grzecznym sposobem powiedzenia: wytrenuj to jeszcze raz.

Drugi frontier dostawca nigdy nie sprzedał ci tej dzierżawy. Indeks dokumentacji Anthropic wymienia 699 stron i ani jedna nie dotyczy fine-tuning; sekcje customizacji modeli na stronie cen Bedrock obejmują Amazon Nova, Amazon Titan, Cohere, Meta i modele OpenAI open-weight, ale nie Claude.⁹¹⁰ Jeśli twoja architektura zależy od fine-tune, jedna z trzech rodzin frontier jest po prostu niedostępna w dowolnym budżecie.

Self-hosting zastępuje dzierżawę modelu dzierżawą maszyny, a AWS robi tę arytmetykę na własnej stronie: jedna jednostka modelu provisioned throughput dla modelu custom, zobowiązanie miesięczne, to „1 model unit × $21.18 × 24 hours × 31 days = $15,757.92” miesięcznie.¹⁰ Wynajem metalu bezpośrednio jest tańszy i nie jest darmowy — $3.99 za GPU-hour na żądanie dla H100, $1.99 preemptible¹¹ — około $2,900 miesięcznie za jedną kartę, która musi działać niezależnie od tego, czy ktokolwiek pyta. Cała ścieżka retrieval przy dziesięciu tysiącach pytań miesięcznie kosztuje $174.52 za sześć miesięcy.

Tu LoRA zasługuje na miejsce jako argument budżetowy, a nie techniczny. Zmierzony na tym samym modelu adapter rank-16 na attention i warstwach feed-forward ma 8,798,208 parametrów — 1.781 % modelu, 17.6 MB w bfloat16 — wobec 0.988 GB wag bazowych, a jego optimizer i gradient state mają 140.77 MB tam, gdzie pełny fine-tuning potrzebuje 7.90 GB, czyli 56 razy więcej. Konsekwencją nie jest tańszy trening, tylko to, że jeden załadowany model bazowy może obsługiwać wiele adapterów, co jest jedynym sposobem, aby stały koszt GPU podzielił się przez cokolwiek. Managed training to odzwierciedla: $0.48 za milion tokenów low-rank do 16B wobec $0.54 full, z minimum $4.00 za zadanie.¹¹ Ten próg jest szczegółem. Przy 24,389 tokenach przez trzy epoki każde ponowne trenowanie na tym korpusie rozlicza się za $4.00, a nie za $0.04, które wychodzą z rachunku — $104 minimów przez dwadzieścia sześć tygodniowych uruchomień, za dziewięćdziesiąt jeden centów arytmetyki.

Dwie kolejne kolumny, które pojawiają się tylko na fakturze.

Data residency kosztuje około dziesięć procent i dwóch dostawców zgadza się co do tej liczby. OpenAI nalicza „a 10 % uplift” na endpointach data-residency dla modeli wydanych 5 marca 2026 lub później;⁷ Vertex wycenia swoje endpointy non-global na $1.65 wobec $1.50, te same dziesięć procent.⁶ Zestaw to z pięćdziesięcioma procentami, które kosztuje endpoint tuned, a folklor się odwraca: residency jest tanie, a fine-tuning nie — i fine-tuning nie jest też opcją prywatną, bo korpus dociera do dostawcy tak czy inaczej, raz podczas treningu zamiast raz przy każdym wywołaniu.

Najbardziej jawna cena kiedykolwiek przypisana twoim danym jest na tej samej stronie, która wymienia jeden model fine-tuned dwa razy: z włączonym data sharing inference kosztuje dokładnie połowę — $2.00 wobec $4.00 wejścia, $8.00 wobec $16.00 wyjścia.⁷ Pozwolenie dostawcy na zatrzymanie tego, co wysłałeś, jest warte 50 % rabatu, co mówi, ile jest warte dla niego.

Distillation — trenowanie własnego małego modelu na odpowiedziach dużego — zwykle przedstawia się jako wyjście z obu problemów. Wycena pokazuje, że nim nie jest, bo nauczyciel to system, który próbowałeś zastąpić: wyprodukowanie dwustu przykładów treningowych przez zadanie ścieżce retrieval dwustu pytań kosztuje 200 × $0.002906 = $0.58, oprócz $0.73 za trening na nich. Distillation robi się po tym, jak pipeline retrieval działa, żeby go potanić, i dziedziczy każdy fakt, który retriever źle znalazł.

Pieniądze są widoczną połową. Druga przychodzi jako czekanie, z tej samej przyczyny co rachunek: model czyta cały prompt, zanim wypowie słowo. Rozdział 13 zmierzył prefill względem decode na modelu, którego dało się dotknąć; tutaj jest ten sam pomiar, jedno uruchomienie, jedna maszyna, względem długości promptu:

Wartości bezwzględne należą do modelu 0.5B na szesnastu wątkach CPU i nic nie mówią o hostowanym frontier modelu. Kształt przenosi się dokładnie: prefill rośnie z długością promptu, a koszt per token powoli rośnie, gdy zaczyna się ujawniać składnik kwadratowy z Rozdziału 9 — 4.79 ms przy tysiącu tokenów wobec 6.04 ms przy ośmiu tysiącach, kara 26 % za samą większą długość.

Konsekwencja dla trzech ścieżek jest bezpośrednia. Ścieżka pierwsza robi prefill czterdziestu trzech tysięcy tokenów per pytanie, a cache hit sprawia, że da się to znieść — Rozdział 16 wyjaśnił dlaczego: odczyt cache zastępuje pracę prefill, więc kupuje opóźnienie i pieniądze w jednej transakcji. Ścieżka druga robi prefill tysiąca i najpierw dodaje round trip do indeksu. Ścieżka trzecia robi prefill dwudziestu ośmiu i nie dodaje nic, co czyni ją mierzalnie najszybszą z trzech w odpowiadaniu. Tylko odpowiada na złą rzecz.

Trzy porażki, które wyglądają jak problemy z modelem, a nimi nie są — dziesięć minut tutaj oszczędza miesiąc później:

I wymaganie ponad tym wszystkim: tej decyzji nie da się podjąć bez zbioru ewaluacyjnego, i mówi to dostawca sprzedający fine-tune. Przewodnik OpenAI zaczyna od „Only invest in fine-tuning after setting up evals. You need a reliable way to determine whether your fine-tuned model is performing better than a base model” i dodaje, że jeśli pięćdziesiąt dobrych przykładów nic nie zmienia, problemem jest zadanie albo prompt, nie wolumen danych.¹ Dwadzieścia pytań, których użył ten rozdział, pokazuje mechanizm i nie może wybrać dostawcy — Rozdział 4 zmierzył dlaczego, a to, co robić, gdy dwadzieścia przypadków to wszystko, co masz — powtarzać je, parować i mierzyć rozrzut między uruchomieniami — jest Rozdziałem 29.

Cztery kolumny, a decyduje tylko ostatnia:

Reguła, która z tego wynika, jest dość krótka, by ją zapamiętać: zacznij od promptu; dodaj retrieval, gdy fakty się ruszają; rób fine-tuning tylko wtedy, gdy zmierzyłeś, że nadal brakuje ci kształtu, a nie faktu — i zanim to zrobisz, wyceń odpowiedź, nie prompt.

Niewygodna wersja dla każdego, kto przyszedł już zdecydowany: w mierzonym przypadku z tego rozdziału fine-tuning jest najtańszą ścieżką powyżej czterech tysięcy pytań miesięcznie, a na faktach nadal nie potrafi pobić odpowiadania CLAUDE.md na wszystko.

Każda cena tutaj była per token, a każda ścieżka innym sposobem układania tokenów. To zaraz przestanie być prawdą.

Rozdział 21 wychodzi poza tekst. Obraz wchodzący do modelu nie jest stringiem, tylko siatką patchy z liczbą tokenów, której nie wybrałeś; minuta mowy jest rozliczana za sekundę u jednego dostawcy i za audio token u innego; mowa syntetyczna jest sprzedawana za znak, transkrypcja za minutę, surowe compute za GPU-second. Pytania, na które ten rozdział odpowiadał jedną funkcją kosztu — co jest tańsze? — nie da się nawet zadać, dopóki jednostki się nie zgadzają, a żaden kalkulator w internecie ich nie normalizuje.

To również miejsce, w którym znów pojawia się trening: adapter obrazu z trigger word i głos sklonowany z próbki. Co podnosi pytanie, którym otwiera się następny rozdział, i nie jest ono retoryczne: jeśli fine-tuning modelu językowego jest prawie zawsze złym zakupem, dlaczego fine-tuning modelu obrazu jest prawie zawsze właściwy?

Każda cena, próg i mnożnik w tym rozdziale zostały odczytane ze strony własnej dostawcy 7 września 2026 i są cytowane z tą datą, bo wszystkie się zmienią. Zmierzone liczby — liczby tokenów, rozmiary chunk, rozmiary retrieval, training loss, wyniki, opóźnienia i liczby z historii wersji — zostały wyprodukowane na jednej maszynie tego samego dnia i da się je odtworzyć z korpusu opisanego wyżej.

Lokalne eksperymenty użyły Qwen/Qwen2.5-0.5B-Instruct z greedy decoding, więc odtwarzają się dokładnie; adapter to dwunastolinijkowa klasa wydrukowana wyżej, przy rank 8 na q_proj i v_proj. Korpus to śledzona dokumentacja Markdown jednego działającego repozytorium oprogramowania, z wyłączeniem dwóch logów append-only, a tempo zmian policzono z historii wersji tego repozytorium.