Fine-tune, retrieve eller prompt? Beslutningen er økonomisk

„Bør vi fine-tune?“ bliver stillet, som om det var et spørgsmål om en model. Det er et spørgsmål om et budget, med en form som ingen benchmark besvarer: hvad betales én gang, hvad betales pr. spørgsmål, og hvad betales igen, hver gang verden flytter sig.

De tre ruter er heller ikke tre måder at gøre én ting på, og leverandørerne siger det tydeligere end de fleste blogindlæg. OpenAI's egen tabel over, hvad supervised fine-tuning er bedst til, oplister fire anvendelser: klassifikation, nuanceret oversættelse, generering af indhold i et specifikt format og rettelse af fejl i instruction-following.¹ Ingen af dem er „at lære modellen noget, den ikke ved“. Dens opsummering af fordelen er, at „du kan bruge kortere prompts med færre eksempler og context data, hvilket sparer token-omkostninger i stor skala og kan give lavere latency“ — et argument om fakturaen fra virksomheden, der sælger funktionen.

Altså:

• Fine-tuning lærer form og adfærd. Tone, format, formen på et svar, en grænse du kan demonstrere, men ikke beskrive. Den stærkeste publicerede version er LIMAs Superficial Alignment Hypothesis: viden kommer fra pretraining, alignment lærer mest, hvilken sub-distribution af formater modellen skal tale i — og derfor var tusind kuraterede eksempler nok dér.²
• Retrieval leverer fakta, der ændrer sig. Det er den eneste af de tre, hvor en redigering i din dokumentation når svaret uden at røre modellen.
• Prompting dækker de fleste virkelige tilfælde og er den ærlige baseline. In-context learning har været standarden siden Language Models are Few-Shot Learners: opgaven demonstreres inde i prompt, og ingen vægt flytter sig.³

To målte papers lukker døren for fejlen i midten. Ovadia og kolleger sammenlignede at injicere viden via unsupervised fine-tuning med at injicere den via retrieval, og retrieval vandt konsekvent, også på fakta som base model allerede havde set i pretraining.⁴ Gekhman og kolleger målte skaden: eksempler, der introducerer ny viden, fitters langsomt, og når modellen endelig fitter dem, stiger dens hallucination rate på andre spørgsmål.⁵ At lære fakta gennem fine-tuning fejler ikke bare; det forringer svar, du ikke trænede på.

Den halvdel er afgjort. Den økonomiske halvdel er ikke, og den er resten af kapitlet.

Én case, kørt på tre måder: teknisk support på din egen dokumentation, som ændrer sig hver uge.

Korpusset er ægte og ligger på denne disk: de 23 Markdown-dokumenter, som et softwarerepository i daglig brug har som intern dokumentation — build-guiden, brandreglerne, oversættelsesbriefen, ti servicemanualer, performance- og sikkerhedsnoterne. Målt med o200k_base, encoding fra Kapitel 7:

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

Treogfyrre tusind tokens er en behagelig størrelse for denne beslutning: det passer i ethvert moderne window, så alle tre ruter er reelt tilgængelige. Ved ti millioner er beslutningen taget for dig, og den er retrieval.

Nu arbejdet, som ordet „ugentlig“ gør. Dokumentations-churn hævdes normalt; her tælles det fra repositoriets versionshistorik:

Dokumenterne flytter sig omtrent hver anden uge. De brugersynlige strings — som er det, en supportdesk faktisk bliver spurgt om — flyttede sig hver uge, de har eksisteret, med cirka tyve commits om ugen. Den rute, vi vælger, skal overleve det, og „hvor ofte ændrer det, du trænede på, sig?“ viser sig at have et tal i dit eget repository snarere end en mening.

Tyve realistiske supportspørgsmål blev skrevet mod dette korpus, ét pr. emne, og hvert tal nedenfor er beregnet over de tyve.

Det simpleste, der virker: læg hele korpusset i system prompt, spørgsmålet til sidst, og lad modellen finde det.

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

Hvert tal dér blev talt undtagen det sidste: 150 output tokens er en antagelse, valgt inden for intervallet af assistant-turns, som Kapitel 16 fakturerede. Det er det eneste tal her, der ikke blev eksekveret, det anvendes identisk på alle tre ruter, og break-even-afsnittet viser præcis, hvor meget konklusionen flytter sig, når du ændrer det.

Ved priserne læst fra leverandørens side den 7. september 2026 — $1.50 pr. million input tokens, $9.00 pr. million output⁶ — er det $0.066317 pr. spørgsmål. Du betaler for at genlæse treogfyrre tusind tokens for at besvare tretten.

Kapitel 16's fix gælder direkte: korpusset er stabilt og ligger forrest, så det er et perfekt cache prefix, og at læse det tilbage koster en tiendedel — $0.007864 pr. spørgsmål, et fald på 88 %. Kapitel 16's advarsel gælder også, i den form kapitlet markerede, men ikke prissatte. Denne leverandør opkræver ingen write premium; den opkræver leje. En eksplicit cache koster $0.000001 pr. stored token pr. time,⁶ så at holde 43,298 tokens varme koster

uanset om nogen spørger om noget. Det er $189.78 over seks måneder for et tomt lokale. Divider lejen med besparelsen pr. spørgsmål, og betingelsen kommer ud på én linje: caching af dette korpus betaler sig over 0.74 spørgsmål i timen — 546 om måneden, når den ugentlige cache rebuild også tælles med. Under det taber den funktion, du slog til for at spare penge, dem.

Samme rute, samme kode, ét flag, fem gange regningen. Kapitel 16 fandt en version af dette forårsaget af et timestamp det forkerte sted; her er intet forkert undtagen trafikken. En cache er et væddemål på volume, og hos denne leverandør placerer du det pr. time.

Kapitel 19's retriever, uændret: skær ved sektionsgrænser med en contextual header, indexér, læg de fire bedste uddrag i prompt. Målt over de tyve spørgsmål:

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

Toogfyrre gange færre prompt tokens end rute ét, til $0.002906 pr. spørgsmål. Indexet koster $0.0070 at bygge ved $0.15 pr. million embedding tokens⁶ — mindre end tre spørgsmåls værdi — og de samme $0.0070 at rebuild fra bunden, hver gang dokumentationen ændrer sig. At rebuild hele indexet hver uge i seks måneder koster atten cent.

Én ting er værd at stoppe ved. Retrieval ødelægger prompt caching. Det stabile prefix er nu systeminstruktionen på 140 tokens; fra token 141 er prompt forskellig ved hvert call, fordi uddragene vælges pr. spørgsmål. Og 140 tokens ligger under alle cache-minima, Kapitel 16 citerede. Så rute to kan slet ikke caches, hvilket lyder dårligt og ikke er det: ikke at cache 1,037 tokens er billigere end at cache 43,298.

Det er en generel regel at tage med: de to store token-besparende teknikker udelukker hinanden på det samme indhold, og den, der vinder, er den, der fjerner flest tokens. Retrieval fjerner 97,6 % af dem.

Træn på to hundrede eksempler i house style, og stil derefter spørgsmål uden nogen dokumentation vedhæftet.

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

Træning koster 24,389 × 3 × $10.00 pr. million = $0.7317. Det er hele konstruktionsomkostningen, mindre end en kop kaffe, hvilket præcis er grunden til, at så mange teams betaler den, før de tjekker, om det hjælper.

Nu fælden, og den er grunden til, at dette kapitel findes. En fine-tuned model koster ikke det samme som dens base model at køre. Prissiden siger det i én sætning: „for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.“⁶ Ikke træningen. Inference, på hver token, så længe modellen lever.

Så læg det i en formel. Lad $p_i$ og $p_o$ være base input- og output-priserne, $m$ den tuned multiplier, $L_R$ prompt-længden på den rute, du erstatter, $L_F$ prompt-længden efter fine-tuning, og $O$ svarlængden. Fine-tuning er kun billigere pr. spørgsmål, når

Det første led er indlysende: din nye korte prompt med markup. Det andet er det ikke, og det er dér, pengene går hen — tillægget på svaret, som intet har med din prompt at gøre, og som træning ikke kan forkorte. Med de målte tal — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — er tærsklen

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

Ved den målte svarlængde, 492 tokens — hvoraf 450 er svartillægget, ikke prompt. At erstatte en kortere prompt end det er dyrere pr. spørgsmål, for altid, ved enhver volume; og tærsklen vokser lineært med, hvor meget din assistant siger, så en der skriver lange svar, kan aldrig fine-tune sig til en billigere token, uanset hvor meget prompt den sletter.

Samme faktum fra den anden ende er sætningen, du skal huske. Af den fine-tuned rutes $0.002088 pr. spørgsmål er 97.0 % svaret. Fine-tuning optimerer de resterende tre procent.

Fire tal beskriver enhver af disse ruter: hvad du betaler én gang, hvad du betaler når dokumentationen ændrer sig, hvad du betaler pr. time uanset hvad, og hvad du betaler pr. spørgsmål. Det udvider Kapitel 16's computeCost uden at ændre den.

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

Den tuned model er ikke en anden prisliste, det er den samme ganget op:

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

Den ene fremhævede linje er hele argumentet fra forrige afsnit skrevet som kode: multiplier rammer også output.

Seks måneder, med dokumentationen opdateret ugentligt:

Og crossovers, som er de fire tal, et budget faktisk har brug for:

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

Læs de første to sammen, for de er pointen med kapitlet. Et stationært korpus får fine-tuning til at betale sig ved hundrede og halvtreds spørgsmål; et korpus, der ændrer sig ugentligt, flytter samme crossover med en faktor syvogtyve, og intet ved modellen ændrede sig — kun hvor ofte du betaler for den igen. Konstruktionsomkostning er en fodnote; vedligeholdelsesomkostning er beslutningen.

Hvis du nu konkluderer, at en travl supportdesk bør fine-tune, er aritmetikken enig med dig. Det er stadig forkert, og næste afsnit forklarer hvorfor.

Cost sheet har én kolonne, det ikke kan beregne, så dette afsnit kører fine-tune: lokalt, på en lille open model, med adapteren skrevet i hånden i stedet for hentet fra et library. Kapitel 11 byggede LoRA; her er den, på q_proj og v_proj i alle 24 lag af Qwen2.5-0.5B-Instruct ved 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

De to hundrede træningseksempler kommer mekanisk fra korpusset, så de kan reproduceres: spørgsmålet er en sektionsoverskrift lavet om til et spørgsmål, svaret er sektionens egen tekst i en rigid house style — én linje der begynder Short answer:, én linje der begynder Source: med filstien. Formatet er formen, der læres; stien er faktummet. Derefter to tal over tyve hold-out-spørgsmål: kommer svaret ud i house style, og navngiver det filen, der faktisk besvarer spørgsmålet?

To baselines gør tabellen læsbar, og begge er Kapitel 4's insisteren snarere end en eftertanke. Ti af de tyve rigtige svar er den samme fil, så en model, der ignorerer spørgsmålet og altid svarer CLAUDE.md, scorer 10/20. Og retrieveren har sit eget loft: på tværs af disse tyve spørgsmål indeholder dens fire uddrag den rigtige fil 14 gange og rangerer den først 7, så 14/20 er det højeste, nogen reader kunne score med den.

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

Formen blev lært, fuldstændigt og hurtigt. Nul til nitten ud af tyve, fra en adapter på 540,672 parametre — 0.109 % af modellen — på fem minutters træning på en processor uden grafikkort i sigte.

Fakta blev ikke. Otte ud af tyve kan ikke skelnes fra de ti, du får ved at ignorere spørgsmålet helt, og Kapitel 4's interval på tyve samples siger det højt. De filstier var i træningsdata tre gange; det, der kom ud, var vanen med at slutte med en plausibelt udseende Source:-linje. På spørgsmålet øverst i dette kapitel svarede den fine-tuned model Short answer: 10.x . . . og citerede CLAUDE.md. Det rigtige svar, som ligger i CLAUDE.md, er 18.17.0.

Og så brød formen sammen, hvilket er rækken der retfærdiggør eksperimentet. Giv den fine-tuned model tusind tokens med retrieved uddrag — en prompt-form, den aldrig havde set, eftersom hver træningsprompt var otteogtyve tokens — og house style falder fra 19/20 til 1/20. På spørgsmålet øverst i dette kapitel svarer den 18.17.0 — korrekt, og uden noget af det format, den blev trænet til. Så fine-tuning lærte ikke et format; den lærte et format betinget af prompts i træningssættet, og den første prompt, der så anderledes ud, tog formatet med sig. Det, du fine-tuner på, bliver den ene input-distribution, din model er god til, og ingen sætter det i regnearket.

En sidste note om metrikken, direkte mod Kapitel 29: „korrekt kilde“ scorer form og fakta sammen, og derfor ser begge retrieval-rækker forfærdelige ud, selvom begge modeller fik faktummet i det spørgsmål rigtigt. Ét end to end-tal skjulte tre ting — en retriever med 14/20 recall, en 0.5B reader og et citation-format — og at vælge, hvad der skal fixes, betyder at adskille dem før du måler, ikke efter.

Nu kolonnen, leverandørerne udfylder for dig. En fine-tuned model er ikke et aktiv, du ejer; det er en lejekontrakt på en andens base model, med en slutdato trykt på. Den 7. september 2026 havde fine-tuning-afsnittet på OpenAI's prisside denne meddelelse i fuld længde:

OpenAI afvikler fine-tuning-platformen. Platformen er ikke længere tilgængelig for nye brugere, men eksisterende brugere af fine-tuning-platformen vil kunne oprette træningsjobs i de kommende måneder. Alle fine-tuned models forbliver tilgængelige for inference, indtil deres base models udfases.⁷

Tidslinjen er dateret til dagen: 7. maj 2026, lukket for organisationer der aldrig havde fine-tuned; 2. juli 2026, lukket for dem der ikke havde kørt inference på en fine-tuned model i tres dage; 6. januar 2027, slet ingen nye jobs.⁸ Den samme side planlægger nedlukningen af selve de fine-tuned models — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — den 23. oktober 2026, hver med en anbefalet replacement base model, hvilket er en høflig måde at sige: træn den igen.

Den anden frontier-leverandør solgte dig aldrig lejekontrakten. Anthropic's dokumentationsindeks oplister 699 sider, og ikke én handler om fine-tuning; model-customisation-afsnittene på Bedrocks prisside dækker Amazon Nova, Amazon Titan, Cohere, Meta og OpenAI open-weight models, og ingen Claude.⁹¹⁰ Hvis din arkitektur afhænger af en fine-tune, er én af de tre frontier-familier simpelthen utilgængelig for dig ved ethvert budget.

Self-hosting erstatter lejekontrakten på en model med en lejekontrakt på en maskine, og AWS laver den aritmetik på sin egen side: én model unit af provisioned throughput for en customised model, én måneds binding, er „1 model unit × $21.18 × 24 timer × 31 dage = $15,757.92“ om måneden.¹⁰ At leje metallet direkte er billigere og ikke gratis — $3.99 pr. GPU-time on demand for en H100, $1.99 preemptible¹¹ — omtrent $2,900 om måneden for ét kort, der skal være oppe, uanset om nogen spørger om noget. Hele retrieval-ruten ved ti tusind spørgsmål om måneden er $174.52 for seks måneder.

Her fortjener LoRA sin plads, som et budgetargument snarere end et teknisk. Målt på samme model er en rank-16 adapter over attention og feed-forward-lagene 8,798,208 parametre — 1.781 % af modellen, 17.6 MB i bfloat16 — mod 0.988 GB base weights, og dens optimiser- og gradient state er 140.77 MB, hvor full fine-tuning kræver 7.90 GB, en faktor 56. Konsekvensen er ikke billigere træning, men at én loaded base model kan serve mange adapters, hvilket er den eneste måde en GPU's faste omkostning bliver delt med noget. Managed training afspejler det: $0.48 pr. million tokens low-rank op til 16B mod $0.54 full, med et minimum på $4.00 pr. job.¹¹ Det floor er detaljen. Ved 24,389 tokens i tre epochs faktureres hver retraining på dette korpus $4.00 i stedet for de $0.04, den beregnes til — $104 i minimums på tværs af seksogtyve ugentlige kørsler, for enoghalvfems cents aritmetik.

To kolonner mere, der kun optræder på fakturaen.

Data residency koster cirka ti procent, og to leverandører er enige om tallet. OpenAI opkræver „a 10 % uplift“ på data-residency endpoints for modeller udgivet den 5. marts 2026 eller senere;⁷ Vertex prissætter sine non-global endpoints til $1.65 mod $1.50, de samme ti procent.⁶ Sæt det op mod de halvtreds procent, et tuned endpoint koster, og folklore vender på hovedet: residency er billigt, og fine-tuning er det ikke — og fine-tuning er alligevel ikke den private mulighed, eftersom korpusset når leverandøren uanset hvad, én gang ved træning i stedet for én gang pr. call.

Den mest eksplicitte pris, der nogensinde er sat på dine data, står på samme side, som oplister én fine-tuned model to gange: med data sharing slået til er inference præcis halv pris — $2.00 mod $4.00 input, $8.00 mod $16.00 output.⁷ At lade leverandøren beholde det, du sendte, er en rabat på 50 % værd, hvilket fortæller dig, hvad det er værd for dem.

Distillation — at træne en lille model af din egen på en stor models svar — tilbydes typisk som en vej ud af begge. Pris det, og det er det ikke, fordi læreren er det system, du forsøgte at erstatte: at producere to hundrede træningseksempler ved at stille retrieval-ruten to hundrede spørgsmål koster 200 × $0.002906 = $0.58, oven i de $0.73 for at træne på dem. Distillation er noget, du gør efter retrieval-pipelinen virker, for at gøre den billigere, og den arver hvert faktum, retrieveren fik forkert.

Penge er den synlige halvdel. Den anden ankommer som ventetid, med samme årsag som regningen: modellen læser hele prompt, før den siger et ord. Kapitel 13 målte prefill mod decode på en model, du kunne røre; her er den samme måling, én kørsel, én maskine, mod prompt-længde:

De absolutte tal tilhører en 0.5B model på seksten CPU-tråde og siger intet om en hosted frontier model. Formen overføres præcist: prefill vokser med prompt-længde, og prisen pr. token kryber op, når Kapitel 9's kvadratiske led begynder at vise sig — 4.79 ms ved tusind tokens mod 6.04 ms ved otte tusind, en straf på 26 % for blot at være længere.

Konsekvensen for de tre ruter er direkte. Rute ét prefiller treogfyrre tusind tokens pr. spørgsmål, og et cache hit er det, der gør det tåleligt — Kapitel 16 forklarede hvorfor: en cache read erstatter prefill-arbejde, så den køber latency og penge i én transaktion. Rute to prefiller tusind og lægger først en round trip til indexet oveni. Rute tre prefiller otteogtyve og lægger intet til, hvilket gør den målbart hurtigst af de tre til at svare. Den svarer bare på det forkerte.

Tre fejl, der ligner modelproblemer og ikke er det — ti minutter her sparer en måned senere:

Og kravet hen over det hele: denne beslutning kan ikke træffes uden et evalueringssæt, og leverandøren, der sælger fine-tune, siger det selv. OpenAI's guide åbner med „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“, og tilføjer, at hvis halvtreds gode eksempler ikke ændrer noget, er problemet opgaven eller prompt, ikke datamængden.¹ Tyve spørgsmål, som dette kapitel brugte, viser en mekanisme og kan ikke vælge en leverandør — Kapitel 4 målte hvorfor, og hvad du gør, når tyve cases er alt, du har — gentag dem, par dem, og mål spredningen mellem kørsler — er Kapitel 29.

Fire kolonner, og kun den sidste afgør:

Reglen, der falder ud af det, og den er kort nok til at beholde: start med prompt; tilføj retrieval når fakta flytter sig; fine-tune kun når du har målt, at det du stadig mangler, er en form, ikke et faktum — og pris svaret, ikke prompt, før du gør det.

Den ubehagelige version, for enhver der ankom efter allerede at have besluttet sig: i den målte case i dette kapitel er fine-tuning den billigste rute over fire tusind spørgsmål om måneden, og på fakta kan den stadig ikke slå at svare CLAUDE.md på alt.

Hver pris her har været pr. token, og hver rute en anden måde at arrangere tokens på. Det holder snart op med at være sandt.

Kapitel 21 forlader tekst. Et billede, der går ind i en model, er ikke en string, men et grid af patches med et token count, du ikke valgte; et talt minut faktureres pr. sekund hos én leverandør og pr. audio token hos en anden; synthetic speech sælges pr. character, transcription pr. minut, raw compute pr. GPU-second. Spørgsmålet, dette kapitel besvarede med én cost function — hvad er billigst? — kan ikke engang stilles, før enhederne matcher, og ingen calculator på internettet normaliserer dem.

Det er også dér, træning dukker op igen: en image adapter med et trigger word og en voice klonet fra et sample. Hvilket rejser spørgsmålet, næste kapitel åbner med, og det er ikke retorisk: hvis fine-tuning af en language model næsten altid er det forkerte køb, hvorfor er fine-tuning af en image model næsten altid det rigtige?

Hver pris, tærskel og multiplier i dette kapitel blev læst fra leverandørens egen side den 7. september 2026 og citeres med den dato, fordi alle vil flytte sig. De målte tal — token counts, chunk-størrelser, retrieval-størrelser, training loss, scores, latencies og version-history counts — blev produceret på én maskine samme dag og kan reproduceres fra korpusset beskrevet ovenfor.

De lokale eksperimenter brugte Qwen/Qwen2.5-0.5B-Instruct med greedy decoding, så de reproduceres præcist; adapteren er den tolvlinjede class trykt ovenfor, ved rank 8 over q_proj og v_proj. Korpusset er den tracked Markdown-dokumentation fra ét softwarerepository i daglig brug, eksklusive to append-only logs, og dets ændringsrate blev talt fra repositoriets versionshistorik.