Fine-tuning, visszakeresés vagy prompt? A döntés gazdasági

„Fine-tune-oljunk?” — ezt úgy kérdezik, mintha modellkérdés lenne. Valójában költségkeret-kérdés, olyan formával, amelyre egy benchmark sem válaszol: mit fizetsz egyszer, mit fizetsz kérdésenként, és mit fizetsz újra minden alkalommal, amikor a világ megmozdul.

A három útvonal ráadásul nem ugyanannak a dolognak három változata, és a szállítók ezt világosabban mondják ki, mint a legtöbb blogposzt. Az OpenAI saját táblázata arról, mire a legjobb a supervised fine-tuning, négy használatot sorol: osztályozás, árnyalt fordítás, tartalom generálása meghatározott formátumban, és instruction-following hibák javítása.¹ Egyik sem az, hogy „megtanítunk a modellnek valamit, amit nem tud”. Az előny összefoglalása szerint „rövidebb prompt-okat használhatsz kevesebb példával és context data-val, ami skálán token-költséget takarít meg és alacsonyabb latency-t adhat” — ez számlaérv, attól a cégtől, amelyik eladja a funkciót.

Tehát:

• A fine-tuning formát és viselkedést tanít. Hangnemet, formátumot, a válasz alakját, olyan határt, amelyet demonstrálni tudsz, de leírni nem. A legerősebb publikált változat a LIMA Superficial Alignment Hypothesis-e: a tudás a pretraining-ből jön, az alignment főleg azt tanítja, melyik formátum-aleloszlásban beszéljen a modell — ezért volt ott elég ezer gondosan válogatott példa.²
• A visszakeresés változó tényeket szolgáltat. A három közül csak ennél jut el egy dokumentációs szerkesztés a válaszba anélkül, hogy a modellhez nyúlnál.
• A prompting lefedi a legtöbb valós esetet, és ez a tisztességes baseline. Az in-context learning a Language Models are Few-Shot Learners óta alapértelmezett: a feladat a prompt-on belül van bemutatva, és egyetlen súly sem mozdul.³

Két mért tanulmány zárja be a középső tévedés ajtaját. Ovadia és kollégái az ismeret injektálását unsupervised fine-tuning-gal hasonlították össze azzal, amikor retrieval-lel injektálják, és a retrieval következetesen nyert, olyan tényeken is, amelyeket az alapmodell már látott pretraining-ben.⁴ Gekhman és kollégái a kárt mérték: az új tudást bevezető példák lassan illeszkednek, és amikor a modell végre illeszti őket, a hallucinációs ráta más kérdéseken nő.⁵ Tények fine-tuning-gal tanítása nem pusztán kudarc; rontja azokat a válaszokat is, amelyeken nem tréningeztél.

Ez a fele eldőlt. A gazdasági fele nem, és a fejezet többi része erről szól.

Egy eset, háromféleképpen futtatva: technikai support a saját dokumentációd felett, amely minden héten változik.

A korpusz valós és ezen a lemezen van: az a 23 Markdown-dokumentum, amelyet egy működő szoftver-repository belső dokumentációként tart — build guide, brand szabályok, fordítási brief, tíz service manual, performance- és security-jegyzetek. A o200k_base-gyel mérve, a 7. fejezet encoding-jával:

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

Negyvenháromezer token kényelmes méret ehhez a döntéshez: bármely modern window-ba belefér, tehát mindhárom útvonal tényleg elérhető. Tízmilliónál a döntés helyetted megszületik, és az retrieval.

Most nézzük, mit dolgozik a „heti” szó. A dokumentációs churn-t általában csak állítják; itt megszámoljuk, a repository verziótörténetéből:

A dokumentumok körülbelül kéthetente mozdulnak. A felhasználó által látható sztringek — amelyekről egy supportpultot ténylegesen kérdeznek — minden létező hetükön mozdultak, heti nagyjából húsz committal. Bármelyik útvonalat választjuk, ezt túl kell élnie, és a „milyen gyakran változik az, amin tréningeztél?” kérdésre a saját repository-dban van szám, nem vélemény.

Húsz realisztikus supportkérdés készült a korpuszhoz, témánként egy, és minden alábbi érték ezeknek a húsznak az alapján számolódik.

A legegyszerűbb működő megoldás: tedd a teljes korpuszt a system prompt-ba, a kérdést a végére, és hagyd, hogy a modell megtalálja.

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

Ott minden szám meg lett számolva, kivéve az utolsót: 150 output token feltételezés, a 16. fejezetben számlázott assistant-válaszok tartományán belül választva. Ez az egyetlen szám itt, amely nem futott le, mindhárom útvonalra azonosan alkalmazzuk, és a break-even szakasz pontosan megmutatja, mennyit mozdul a következtetés, ha megváltoztatod.

A szolgáltató 2026. szeptember 7-én olvasott díjai mellett — $1.50 millió input token-enként, $9.00 millió output token-enként⁶ — ez $0.066317 kérdésenként. Azért fizetsz, hogy újraolvastass negyvenháromezer token-t tizenhárom megválaszolásához.

A 16. fejezet javítása közvetlenül alkalmazható: a korpusz stabil és az elején van, tehát tökéletes cache prefix, és visszaolvasni tizedannyiba kerül — $0.007864 kérdésenként, 88%-os vágás. A 16. fejezet figyelmeztetése is alkalmazható, abban a formában, amelyet az a fejezet jelzett, de nem árazott be. Ez a szolgáltató nem számít fel írási prémiumot; bérleti díjat számít fel. Egy explicit cache $0.000001-be kerül tárolt token-enként óránként,⁶ tehát 43,298 token melegen tartása ennyibe kerül:

akkor is, ha senki sem kérdez semmit. Ez $189.78 hat hónap alatt, egy üres szobáért. Oszd el a bérleti díjat a kérdésenkénti megtakarítással, és a feltétel egy sorban kijön: ennek a korpusznak a cache-elése 0,74 kérdés/óra felett térül meg — havi 546, ha a heti cache-újraépítést is beleszámoljuk. Ez alatt a pénzspórolásra bekapcsolt funkció pénzt veszít.

Ugyanaz az útvonal, ugyanaz a kód, egy flag, ötszörös számla. A 16. fejezet talált ennek egy változatát egy rossz helyen lévő timestamp miatt; itt semmi sincs rosszul, csak a forgalom. A cache fogadás a volumenre, és ennél a szolgáltatónál óránként teszed meg.

A 19. fejezet visszakeresője, változatlanul: vágás szakaszhatárokon kontextuális fejléccel, indexelés, a négy legjobb kivonat prompt-ba tétele. A húsz kérdésen mérve:

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

Negyvenkétszer kevesebb prompt token, mint az első útvonalon, $0.002906 kérdésenként. Az index felépítése $0.0070-be kerül $0.15/millió embedding token áron⁶ — kevesebb, mint három kérdés ára — és ugyanennyi $0.0070 nulláról újraépíteni, valahányszor a dokumentáció változik. A teljes index heti újraépítése hat hónapon át tizennyolc cent.

Egy dolognál érdemes megállni. A retrieval elpusztítja a prompt caching-et. A stabil prefix most a 140 token-es system instruction; a 141. token-től a prompt minden hívásnál eltér, mert a kivonatok kérdésenként választódnak. A 140 token pedig minden cache-minimum alatt van, amelyet a 16. fejezet idézett. A második útvonal tehát egyáltalán nem cache-elhető, ami rosszul hangzik, de nem az: 1,037 token nem cache-elése olcsóbb, mint 43,298 cache-elése.

Ez általános szabály, amelyet érdemes továbbvinni: a két nagy token-spóroló technika ugyanazon tartalmon kölcsönösen kizárja egymást, és az nyer, amelyik több token-t távolít el. A retrieval 97,6%-ukat eltávolítja.

Tréningezz kétszáz példán a házi stílusban, majd tegyél fel kérdéseket dokumentáció csatolása nélkül.

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

A tréning ára 24,389 × 3 × $10.00/millió = $0.7317. Ez a teljes építési költség, kevesebb, mint egy kávé, pontosan ezért fizeti ki sok csapat, mielőtt megnézné, segít-e.

Most jön a csapda, és ezért létezik ez a fejezet. Egy fine-tuned modell futtatása nem ugyanannyiba kerül, mint az alapmodellé. Az árlista egy mondatban mondja ki: „for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.”⁶ Nem a tréning. Az inference, minden token-re, amíg a modell él.

Tegyük képletbe. Legyen $p_i$ és $p_o$ az alap input- és outputár, $m$ a tuned szorzó, $L_R$ a lecserélt útvonal prompt-hossza, $L_F$ a fine-tuning utáni prompt-hossz, és $O$ a válaszhossz. A fine-tuning csak akkor olcsóbb kérdésenként, ha

Az első tag nyilvánvaló: az új rövid prompt, felárazva. A második nem az, és oda megy a pénz — a válasz felára, amelynek semmi köze a prompt-odhoz, és amelyet a tréning nem tud lerövidíteni. A mért számokkal — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — a küszöb:

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

A mért válaszhossznál 492 token — ebből 450 a válasz felára, nem a prompt. Ennél rövidebb prompt kiváltása drágább kérdésenként, örökre, bármilyen volumen mellett; és a küszöb lineárisan nő azzal, mennyit beszél az assistant, így egy hosszú válaszokat író rendszer sosem fine-tune-olhatja magát olcsóbb token-hez, bármennyi prompt-ot töröl.

Ugyanez a tény a másik végéről az a mondat, amelyet érdemes megjegyezni. A fine-tuned útvonal kérdésenkénti $0.002088-jából 97,0% a válasz. A fine-tuning a maradék három százalékot optimalizálja.

Négy szám ír le bármely útvonalat: mit fizetsz egyszer, mit fizetsz, amikor a dokumentáció változik, mit fizetsz óránként bármitől függetlenül, és mit fizetsz kérdésenként. Ez kiterjeszti a 16. fejezet computeCost-jét anélkül, hogy módosítaná.

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

A tuned modell nem másik árlista, hanem ugyanaz megszorozva:

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

Az az egy kiemelt sor az előző szakasz teljes érve kódként: a szorzó a output-ra is rákerül.

Hat hónap, heti dokumentációfrissítéssel:

És a metszéspontok, vagyis az a négy szám, amelyre egy költségkeretnek tényleg szüksége van:

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

Az első kettőt együtt olvasd, mert ez a fejezet lényege. Egy állandó korpusznál a fine-tuning százötven kérdés alatt megtérül; egy hetente változó korpusz ugyanezt a metszéspontot huszonhétszeresére tolja, és a modellben semmi sem változott — csak az, milyen gyakran fizetsz érte újra. Az építési költség lábjegyzet; a karbantartási költség maga a döntés.

Ha most arra jutsz, hogy egy forgalmas supportpultnak fine-tune-olnia kellene, a számtan egyetért veled. Még mindig rossz, és a következő szakasz megmutatja, miért.

A költséglapnak van egy oszlopa, amelyet nem tud kiszámolni, ezért ez a szakasz lefuttatja a fine-tune-t: lokálisan, egy kis open modellen, kézzel írt adapterrel, nem könyvtárból behúzva. A 11. fejezet felépítette a LoRA-t; itt van, a q_proj és v_proj pontokon, a Qwen2.5-0.5B-Instruct mind a 24 rétegében, rank 8-cal:

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

A kétszáz tréningpélda mechanikusan jön a korpuszból, ezért reprodukálható: a kérdés egy szakaszcímből lett kérdéssé alakítva, a válasz pedig ugyanannak a szakasznak a szövege merev házi stílusban — egy sor Short answer: kezdetű, egy sor Source: kezdetű, a fájlútvonallal. A formátum az a forma, amit tanítunk; az útvonal a tény. Ezután két szám húsz held-out kérdésen: kijön-e a válasz házi stílusban, és megnevezi-e azt a fájlt, amely tényleg megválaszolja a kérdést?

Két baseline teszi olvashatóvá a táblát, és mindkettő a 4. fejezet ragaszkodása, nem utólagos gondolat. A húsz helyes válaszból tíz ugyanaz a fájl, tehát egy modell, amely figyelmen kívül hagyja a kérdést, és mindig CLAUDE.md választ ad, 10/20-at ér el. A visszakeresőnek is van saját plafonja: ezen a húsz kérdésen a négy kivonata 14-szer tartalmazza a helyes fájlt, és 7-szer rangsorolja elsőnek, tehát 14/20 a maximum, amit bármely reader elérhet vele.

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

A forma teljesen és gyorsan megtanult. Nulláról tizenkilenc a húszból, egy 540,672 paraméteres adapterrel — a modell 0,109%-ával — öt perc tréning alatt, grafikus kártyát hírből sem látó processzoron.

A tények nem. A nyolc a húszból nem különböztethető meg attól a tíztől, amit úgy kapsz, hogy teljesen figyelmen kívül hagyod a kérdést, és a 4. fejezet húsz mintára adott intervalluma ezt hangosan kimondja. Azok a fájlútvonalak három epoch-on át benne voltak a tréningadatban; ami kijött, az egy hihetőnek látszó Source: sorral zárás szokása volt. A fejezet elején szereplő kérdésre a fine-tuned modell Short answer: 10.x . . . választ adott, és CLAUDE.md-re hivatkozott. A helyes válasz, amely a CLAUDE.md-ben van, 18.17.0.

Aztán a forma is eltört, és ez az a sor, amely igazolja a kísérletet. Adj a fine-tuned modellnek ezer token-nyi visszakeresett kivonatot — olyan prompt-alakot, amelyet sosem látott, hiszen minden tréning prompt huszonnyolc token volt —, és a házi stílus 19/20-ról 1/20-ra omlik. A fejezet eleji kérdésre 18.17.0 választ ad — helyesen, de semmi abból a formátumból, amelyre tréningeztük. A fine-tuning tehát nem formátumot tanított; a tréninghalmaz prompt-jaira feltételes formátumot tanított, és az első másképp kinéző prompt magával vitte a formátumot. Amire fine-tune-olsz, az lesz az egyetlen inputeloszlás, amelyben a modelled jó, és ezt senki sem teszi bele a táblázatba.

Egy utolsó megjegyzés a metrikáról, egyenesen a 29. fejezetre mutatva: a „correct source” egyszerre pontoz formát és tényt, ezért tűnik mindkét retrieval-sor borzalmasnak, noha mindkét modell helyesen adta meg annak a kérdésnek a tényét. Egy end-to-end szám három dolgot rejtett el — egy 14/20 recallú visszakeresőt, egy 0.5B readert és egy hivatkozási formátumot —, és annak eldöntése, melyiket javítsd, azt jelenti, hogy mérés előtt választod szét őket, nem utána.

Most az oszlop, amelyet a szállítók töltenek ki helyetted. Egy fine-tuned modell nem a tulajdonodban lévő eszköz; bérlet valaki más alapmodelljén, ráírt lejárati dátummal. 2026. szeptember 7-én az OpenAI árlistaoldalának fine-tuning szakasza teljes egészében ezt az értesítést tartalmazta:

OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months. All fine-tuned models will remain available for inference until their base models are deprecated.⁷

Az idővonal napra pontos: 2026. május 7., lezárva azoknak a szervezeteknek, amelyek még sosem fine-tune-oltak; 2026. július 2., lezárva azoknak, amelyek hatvan napja nem futtattak inference-t fine-tuned modellen; 2027. január 6., egyáltalán nincs új job.⁸ Ugyanez az oldal ütemezi maguknak a fine-tuned modelleknek a leállítását — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — 2026. október 23-ra, mindegyikhez recommended replacement base model megjelöléssel, ami udvarias megfogalmazása annak: tréningezd újra.

A másik frontier szállító sosem adta el neked ezt a bérletet. Az Anthropic dokumentációs indexe 699 oldalt sorol, és egyik sem szól fine-tuning-ról; a Bedrock árlistaoldalának model-customisation szakaszai Amazon Nova, Amazon Titan, Cohere, Meta és OpenAI open-weight modelleket fednek le, Claude-ot nem.⁹¹⁰ Ha az architektúrád fine-tune-tól függ, a három frontier család egyike bármilyen költségkeret mellett egyszerűen elérhetetlen számodra.

A self-hosting a modellbérletet gépbérletre cseréli, és az AWS ezt a számtant a saját oldalán végzi el: egy customised modellhez egy model unit provisioned throughput, egy hónapos kötelezettséggel: „1 model unit × $21.18 × 24 hours × 31 days = $15,757.92” havonta.¹⁰ A fém közvetlen bérlése olcsóbb, de nem ingyenes — $3.99 GPU-óránként on demand H100-ért, $1.99 preemptible¹¹ — nagyjából havi $2,900 egy kártyáért, amelynek akkor is fent kell lennie, ha senki sem kérdez. A teljes retrieval-útvonal tízezer kérdés/hónap mellett hat hónapra $174.52.

Itt érdemli ki a LoRA a helyét költségvetési érvként, nem technikaiként. Ugyanazon a modellen mérve egy rank-16 adapter az attention és feed-forward rétegeken 8,798,208 paraméter — a modell 1,781%-a, 17,6 MB bfloat16-ban — szemben 0,988 GB alap-súllyal, az optimiser- és gradient-állapota pedig 140,77 MB, ahol a full fine-tuning 7,90 GB-ot igényel, 56-os faktorral. A következmény nem az olcsóbb tréning, hanem az, hogy egy betöltött alapmodell sok adaptert tud kiszolgálni, és csak így oszlik meg egy GPU fix költsége bármin. A managed tréning ezt tükrözi: $0.48 millió token-enként low-rank 16B-ig, szemben $0.54 full-lal, $4.00 minimum per job.¹¹ A floor a lényeg. 24,389 token-nél három epoch-ra minden retraining ezen a korpuszon $4.00-ba kerül a kiszámolt $0.04 helyett — $104 minimum huszonhat heti futásra, kilencvenegy centnyi számtan helyett.

Két további oszlop, amely csak a számlán jelenik meg.

A data residency körülbelül tíz százalékba kerül, és két szolgáltató ugyanebben ért egyet. Az OpenAI „10% uplift”-et számít fel a 2026. március 5-én vagy később kiadott modellek data-residency endpoint-jain;⁷ a Vertex non-global endpoint-jai $1.65-be kerülnek $1.50 helyett, ugyanaz a tíz százalék.⁶ Tedd ezt szembe azzal az ötven százalékkal, amennyivel egy tuned endpoint kerül többe, és a folklór megfordul: a residency olcsó, a fine-tuning nem — és a fine-tuning amúgy sem a privát opció, hiszen a korpusz így is, úgy is eljut a szolgáltatóhoz, csak egyszer tréningidőben, nem hívásonként.

Az adatodra valaha kiírt legexplicitabb ár ugyanazon az oldalon van: egy fine-tuned modellt kétszer listáz, data sharing engedélyezésével az inference pontosan fele — $2.00 kontra $4.00 input, $8.00 kontra $16.00 output.⁷ Ha engeded, hogy a szolgáltató megtartsa, amit küldtél, 50%-os kedvezményt kapsz, ami megmutatja, mennyit ér nekik.

Distillation — saját kis modell tréningezése egy nagy modell válaszain — gyakran menekülőútként jelenik meg mindkettőből. Beárazva nem az, mert a teacher épp az a rendszer, amelyet le akartál cserélni: kétszáz tréningpélda előállítása úgy, hogy a retrieval-útvonalnak kétszáz kérdést teszel fel, 200 × $0.002906 = $0.58, a rajtuk végzett $0.73 tréning tetején. A distillation olyasmi, amit azután csinálsz, hogy a retrieval pipeline működik, hogy olcsóbbá tedd, és örökli a retriever minden rossz tényét.

A pénz a látható fele. A másik várakozásként érkezik, ugyanazzal az okkal, mint a számla: a modell az egész prompt-ot elolvassa, mielőtt egy szót mondana. A 13. fejezet prefillt mért decode-dal szemben egy megérinthető modellen; itt ugyanez a mérés, egy futás, egy gép, prompt-hossz szerint:

Az abszolút számok egy 0.5B modellhez tartoznak tizenhat CPU threaden, és semmit sem mondanak egy hosted frontier modellről. Az alak pontosan átvihető: a prefill a prompt-hosszal nő, és a token-enkénti költség kúszik felfelé, ahogy a 9. fejezet kvadratikus tagja látszani kezd — 4.79 ms ezer token-nél, szemben 6.04 ms-sal nyolcezernél, 26%-os büntetés pusztán azért, mert hosszabb.

A következmény a három útvonalra közvetlen. Az első útvonal kérdésenként negyvenháromezer token-t prefill-el, és egy cache hit teszi elviselhetővé — a 16. fejezet elmagyarázta, miért: a cache read kiváltja a prefill munkát, tehát latency-t és pénzt vesz egy tranzakcióban. A második útvonal ezret prefill-el, és előbb egy round tripet ad az indexhez. A harmadik huszonnyolcat prefill-el, és semmit sem ad hozzá, ezért mérhetően ez válaszol a leggyorsabban a három közül. Csak éppen rossz dologra válaszol.

Három hiba, amely modellproblémának néz ki, de nem az — tíz perc itt egy hónapot spórol később:

És az egész fölötti követelmény: ezt a döntést nem lehet evaluation set nélkül meghozni, és ezt maga a fine-tune-t áruló szállító mondja. Az OpenAI útmutatója így nyit: „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”, és hozzáteszi, hogy ha ötven jó példa sem változtat semmin, a probléma a feladat vagy a prompt, nem az adatmennyiség.¹ Húsz kérdés, amennyit ez a fejezet használt, mechanizmust mutat, de nem tud beszállítót választani — a 4. fejezet mérte, miért, és az, hogy mit tegyél, ha húsz eset az összes, amid van — ismételd őket, párosítsd őket, és mérd a futások közötti szórást — a 29. fejezet témája.

Négy oszlop, és csak az utolsó dönt:

A szabály, amely ebből kiesik, elég rövid ahhoz, hogy megtartsd: kezdd a prompt-tal; adj hozzá retrieval-t, amikor a tények mozognak; csak akkor fine-tune-olj, ha megmérted, hogy ami még hiányzik, az forma, nem tény — és előtte árazd be a választ, ne a prompt-ot.

A kényelmetlen verzió azoknak, akik már eldöntve érkeztek: ebben a fejezetben a mért esetben a fine-tuning tényleg a legolcsóbb útvonal havi négyezer kérdés felett, és tényekben még mindig nem tudja legyőzni azt, hogy mindenre CLAUDE.md választ adsz.

Eddig minden ár token-alapú volt, és minden útvonal a token-ek más elrendezése. Ez hamarosan megszűnik igaznak lenni.

A 21. fejezet elhagyja a szöveget. Egy modellbe belépő kép nem string, hanem patch-ek rácsa olyan token-számmal, amelyet nem te választottál; egy beszélt percet az egyik szolgáltató másodpercenként, a másik audio token-enként számláz; a szintetikus beszéd karakterenként, a transcription percenként, a raw compute GPU-másodpercenként kapható. A kérdést, amelyet ez a fejezet egyetlen költségfüggvénnyel megválaszolt — melyik az olcsóbb? — fel sem lehet tenni, amíg az egységek nem egyeznek, és az interneten nincs kalkulátor, amely normalizálná őket.

Itt bukkan fel ismét a tréning is: image adapter trigger worddel, és mintából cloned voice. Ez felveti a kérdést, amellyel a következő fejezet nyit, és nem költői: ha egy language model fine-tuning-ja szinte mindig rossz vásárlás, miért szinte mindig jó az image model fine-tuning-ja?

Ebben a fejezetben minden ár, küszöb és szorzó a szolgáltató saját oldaláról lett leolvasva 2026. szeptember 7-én, és ezzel a dátummal van idézve, mert mind mozogni fognak. A mért értékek — token-számok, chunkméretek, retrieval-méretek, tréningveszteség, pontszámok, latency-k és verziótörténeti számok — ugyanazon a napon, egy gépen készültek, és a fent leírt korpuszból reprodukálhatók.

A lokális kísérletek Qwen/Qwen2.5-0.5B-Instruct-t használtak greedy decoding-gal, ezért pontosan reprodukálhatók; az adapter a fent nyomtatott tizenkét soros class, rank 8-cal q_proj és v_proj felett. A korpusz egy működő szoftver-repository követett Markdown-dokumentációja, két append-only logot kizárva; a változási rátát ugyanennek a repository-nak a verziótörténetéből számoltuk.