Fine-tuning, retrieval eller prompt? Beslutet är ekonomiskt

”Bör vi fine-tune?” ställs som om det vore en fråga om en model. Det är en fråga om en budget, med en form som inget benchmark besvarar: vad betalas en gång, vad betalas per fråga, och vad betalas igen varje gång världen rör sig.

De tre vägarna är inte heller tre sätt att göra en sak, och leverantörerna säger det tydligare än de flesta blogginlägg. OpenAI:s egen tabell över vad supervised fine-tuning är bäst för listar fyra användningar: klassificering, nyanserad översättning, att generera innehåll i ett specifikt format och att korrigera misslyckanden i instruktionsefterlevnad.¹ Ingen av dem är ”att lära modellen något den inte kan”. Dess sammanfattning av nyttan är att ”du kan använda kortare prompts med färre exempel och context data, vilket sparar token-kostnader i skala och kan ge lägre latency” — ett argument om fakturan, från företaget som säljer funktionen.

Alltså:

• Fine-tuning lär ut form och beteende. Ton, format, ett svars form, en gräns du kan demonstrera men inte beskriva. Den starkaste publicerade versionen är LIMA:s Superficial Alignment Hypothesis: kunskap kommer från pretraining, alignment lär mest vilken sub-distribution av format modellen ska tala i — vilket är varför tusen kurerade exempel räckte där.²
• Retrieval tillför fakta som förändras. Det är den enda av de tre där en ändring i din dokumentation når svaret utan att röra modellen.
• Prompting täcker de flesta verkliga fall, och är den ärliga baslinjen. In-context learning har varit standard sedan Language Models are Few-Shot Learners: uppgiften demonstreras inne i prompt och ingen vikt rör sig.³

Två uppmätta artiklar stänger dörren för misstaget i mitten. Ovadia och kollegor jämförde att injicera kunskap genom unsupervised fine-tuning med att injicera den genom retrieval, och retrieval vann konsekvent, även på fakta som basmodellen redan hade sett i pretraining.⁴ Gekhman och kollegor mätte skadan: exempel som introducerar ny kunskap anpassas långsamt, och när modellen till slut anpassar sig till dem stiger dess hallucinationsgrad på andra frågor.⁵ Att lära ut fakta med fine-tuning misslyckas inte bara; det försämrar svar du inte tränade på.

Den halvan är avgjord. Den ekonomiska halvan är det inte, och den är resten av kapitlet.

Ett fall, kört på tre sätt: teknisk support över din egen dokumentation, som ändras varje vecka.

Korpusen är verklig och finns på den här disken: de 23 Markdown-dokument som ett fungerande mjukvaru-repository håller som intern dokumentation — byggguiden, varumärkesreglerna, översättningsbriefen, tio servicemanualer, prestanda- och säkerhetsnoteringarna. Mätt med o200k_base, encoding från Kapitel 7:

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

Fyrtiotretusen tokens är en bekväm storlek för det här beslutet: den ryms i vilket modernt window som helst, så alla tre vägar är faktiskt tillgängliga. Vid tio miljoner är beslutet fattat åt dig, och det är retrieval.

Nu arbetet som ordet ”weekly” gör. Dokumentationsförändring brukar påstås; här räknas den, från det repositorys versionshistorik:

Dokumenten rör sig ungefär varannan vecka. De användarsynliga strängarna — vilket är vad en supportdesk faktiskt får frågor om — rörde sig varje vecka de har funnits, med ungefär tjugo commits i veckan. Vilken väg vi än väljer måste överleva det, och ”hur ofta ändras det du tränade på?” visar sig ha en siffra i ditt eget repository snarare än en åsikt.

Tjugo realistiska supportfrågor skrevs mot denna corpus, en per ämne, och varje siffra nedan beräknas över dessa tjugo.

Det enklaste som fungerar: lägg hela korpusen i system prompt, frågan på slutet, och låt modellen hitta den.

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

Varje siffra där räknades utom den sista: 150 output tokens är ett antagande, valt inom spannet av assistant-turer som Kapitel 16 fakturerade. Det är den enda siffran här som inte kördes, den tillämpas identiskt på alla tre vägar, och break-even-avsnittet visar exakt hur mycket slutsatsen rör sig när du ändrar den.

Med de priser som lästes från leverantörens sida den 7 september 2026 — $1.50 per miljon input tokens, $9.00 per miljon output⁶ — blir det $0.066317 per fråga. Du betalar för att läsa om fyrtiotretusen tokens för att svara på tretton.

Kapitel 16:s lösning gäller direkt: korpusen är stabil och den ligger längst fram, så den är ett perfekt cache-prefix, och att läsa tillbaka den kostar en tiondel — $0.007864 per fråga, en sänkning på 88 %. Kapitel 16:s varning gäller också, i den form som kapitlet flaggade och inte prissatte. Den här leverantören tar ingen write-premie; den tar hyra. En explicit cache kostar $0.000001 per lagrad token per timme,⁶ så att hålla 43,298 tokens varma kostar

oavsett om någon frågar något. Det är $189.78 över sex månader, för ett tomt rum. Dela hyran med besparingen per fråga så kommer villkoret ut på en rad: caching av den här korpusen betalar sig över 0.74 frågor i timmen — 546 i månaden när den veckovisa cache-ombyggnaden också räknas. Under det förlorar funktionen du slog på för att spara pengar dem.

Samma väg, samma kod, en flagga, fem gånger fakturan. Kapitel 16 hittade en version av detta orsakad av en timestamp på fel plats; här är inget fel utom trafiken. En cache är ett vad på volym, och hos den här leverantören lägger du det per timme.

Kapitel 19:s retriever, oförändrad: klipp på sektionsgränser med en kontextuell header, indexera, lägg de fyra bästa utdragen i prompt. Mätt över de tjugo frågorna:

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

Fyrtiotvå gånger färre prompt tokens än väg ett, till $0.002906 per fråga. Indexet kostar $0.0070 att bygga vid $0.15 per miljon embedding tokens⁶ — mindre än tre frågors värde — och samma $0.0070 att bygga om från noll varje gång dokumentationen ändras. Att bygga om hela indexet varje vecka i sex månader kostar arton cent.

En sak är värd att stanna vid. Retrieval förstör prompt caching. Det stabila prefixet är nu systeminstruktionen på 140 tokens; från token 141 skiljer sig prompt vid varje anrop, eftersom utdragen väljs per fråga. Och 140 tokens ligger under varje cache-minimum Kapitel 16 citerade. Så väg två kan inte cached alls, vilket låter dåligt och inte är det: att inte cached 1,037 tokens är billigare än att cached 43,298.

Det är en generell regel att bära med sig: de två stora teknikerna för token-besparing är ömsesidigt uteslutande på samma innehåll, och den som vinner är den som tar bort flest tokens. Retrieval tar bort 97,6 % av dem.

Träna på tvåhundra exempel i den egna stilen, och ställ sedan frågor utan någon dokumentation bifogad alls.

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

Träning kostar 24,389 × 3 × $10.00 per miljon = $0.7317. Det är hela byggkostnaden, mindre än en kopp kaffe, vilket är exakt varför så många team betalar den innan de kontrollerar om det hjälper.

Nu fällan, och den är skälet till att det här kapitlet finns. En fine-tuned model kostar inte samma som sin basmodell att köra. Prissidan säger det i en mening: ”for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.”⁶ Inte träningen. Inference, på varje token, så länge modellen lever.

Sätt det alltså i en formel. Låt $p_i$ och $p_o$ vara priserna för base input och output, $m$ tuned-multiplikatorn, $L_R$ prompt-längden för vägen du ersätter, $L_F$ prompt-längden efter fine-tuning och $O$ svarslängden. Fine-tuning är billigare per fråga bara när

Den första termen är uppenbar: din nya korta prompt, med påslag. Den andra är det inte, och det är där pengarna hamnar — påslaget på svaret, som inte har något med din prompt att göra och som träning inte kan korta. Med de uppmätta siffrorna — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — är tröskeln

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

Vid den uppmätta svarslängden, 492 tokens — varav 450 är svarspåslaget, inte prompt. Att ersätta en kortare prompt än så är dyrare per fråga, för alltid, vid vilken volym som helst; och tröskeln växer linjärt med hur mycket din assistant säger, så en som skriver långa svar kan aldrig fine-tune sig fram till en billigare token oavsett hur mycket prompt den tar bort.

Samma faktum från andra hållet är meningen att minnas. Av den fine-tuned vägens $0.002088 per fråga är 97.0 % svaret. Fine-tuning optimerar de återstående tre procenten.

Fyra siffror beskriver vilken som helst av dessa vägar: vad du betalar en gång, vad du betalar när dokumentationen ändras, vad du betalar per timme oavsett, och vad du betalar per fråga. Det utökar Kapitel 16:s computeCost utan att ändra 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 är inte en annan prislista, det är samma multiplicerad:

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 där markerade raden är hela föregående avsnitts argument skrivet som kod: multiplikatorn landar på output också.

Sex månader, med dokumentationen uppdaterad varje vecka:

Och skärningspunkterna, som är de fyra siffror en budget faktiskt behöver:

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örsta två tillsammans, eftersom de är kapitlets poäng. En stationär corpus gör att fine-tuning betalar sig på hundrafemtio frågor; en corpus som ändras varje vecka flyttar samma skärningspunkt med en faktor tjugosju, och inget med modellen ändrades — bara hur ofta du betalar för den igen. Byggkostnad är en fotnot; underhållskostnad är beslutet.

Om du nu drar slutsatsen att en upptagen supportdesk bör fine-tune, håller aritmetiken med dig. Det är fortfarande fel, och nästa avsnitt visar varför.

Kostnadsbladet har en kolumn det inte kan beräkna, så det här avsnittet kör fine-tune: lokalt, på en liten öppen model, med adaptern skriven för hand snarare än hämtad från ett bibliotek. Kapitel 11 byggde LoRA; här är den, på q_proj och v_proj i alla 24 lager av Qwen2.5-0.5B-Instruct vid 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 tvåhundra träningsexemplen kommer mekaniskt från korpusen, så de går att reproducera: frågan är en sektionsrubrik omgjord till en fråga, svaret är sektionens egen text i en rigid intern stil — en rad som börjar med Short answer:, en rad som börjar med Source: med filvägen. Formatet är formen som lärs ut; vägen är faktumet. Sedan två siffror över tjugo undanhållna frågor: kommer svaret ut i den interna stilen, och namnger det filen som faktiskt besvarar frågan?

Två baslinjer gör tabellen läsbar, och båda är Kapitel 4:s insisterande snarare än en eftertanke. Tio av de tjugo rätta svaren är samma fil, så en model som ignorerar frågan och alltid svarar CLAUDE.md får 10/20. Och retrievern har sitt eget tak: över dessa tjugo frågor innehåller dess fyra utdrag rätt fil 14 gånger och rankar den först 7, så 14/20 är det mesta någon reader skulle kunna få 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 lärdes in, fullständigt och snabbt. Noll till nitton av tjugo, från en adapter med 540,672 parametrar — 0.109 % av modellen — på fem minuters träning på en processor utan grafikkort i sikte.

Fakta gjorde det inte. Åtta av tjugo går inte att skilja från de tio du får genom att ignorera frågan helt, och Kapitel 4:s intervall på tjugo samples säger det högt. De där filvägarna fanns i träningsdata tre gånger om; det som kom ut var vanan att sluta med en plausibel Source:-rad. På frågan överst i det här kapitlet svarade den fine-tuned model Short answer: 10.x . . . och citerade CLAUDE.md. Rätt svar, som finns i CLAUDE.md, är 18.17.0.

Och sedan gick formen sönder, vilket är raden som motiverar experimentet. Ge den fine-tuned model tusen tokens med hämtade utdrag — en prompt-form den aldrig sett, eftersom varje träningsprompt var tjugoåtta tokens — och den interna stilen kollapsar från 19/20 till 1/20. På frågan överst i det här kapitlet svarar den 18.17.0 — korrekt, och utan något av formatet den tränades för. Fine-tuning lärde alltså inte ut ett format; den lärde ut ett format villkorat på prompts i träningsmängden, och den första prompt som såg annorlunda ut tog formatet med sig. Det du fine-tunar på blir den enda input distribution din model är bra på, och ingen lägger in det i kalkylbladet.

En sista notering om mätetalet, som pekar rakt på Kapitel 29: ”korrekt källa” poängsätter form och fakta tillsammans, vilket är varför båda retrieval-raderna ser usla ut trots att båda modeller fick just den frågans fakta rätt. Ett end-to-end-tal dolde tre saker — en retriever på 14/20 recall, en 0.5B reader och ett källhänvisningsformat — och att välja vad som ska fixas betyder att separera dem innan du mäter, inte efter.

Nu kolumnen leverantörerna fyller i åt dig. En fine-tuned model är inte en tillgång du äger; den är ett hyresavtal på någon annans basmodell, med ett slutdatum tryckt på det. Den 7 september 2026 hade fine-tuning-avsnittet på OpenAI:s prissida detta meddelande i sin helhet:

OpenAI avvecklar fine-tuning-plattformen. Plattformen är inte längre tillgänglig för nya användare, men befintliga användare av fine-tuning-plattformen kommer att kunna skapa träningsjobb under de kommande månaderna. Alla fine-tuned models kommer att förbli tillgängliga för inference tills deras basmodeller avvecklas.⁷

Tidslinjen är daterad på dagen: 7 maj 2026, stängd för organisationer som aldrig hade fine-tuned; 2 juli 2026, stängd för dem som inte hade kört inference på en fine-tuned model på sextio dagar; 6 januari 2027, inga nya jobb alls.⁸ Samma sida schemalägger nedstängningen av de fine-tuned models själva — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — den 23 oktober 2026, var och en med en rekommenderad ersättande basmodell, vilket är ett artigt sätt att säga: träna den igen.

Den andra frontier-leverantören sålde aldrig hyresavtalet till dig. Anthropic:s dokumentationsindex listar 699 sidor och inte en enda handlar om fine-tuning; model-customisation-avsnitten på Bedrock:s prissida täcker Amazon Nova, Amazon Titan, Cohere, Meta och OpenAI open-weight models, och ingen Claude.⁹¹⁰ Om din arkitektur beror på en fine-tune är en av de tre frontier-familjerna helt enkelt otillgänglig för dig oavsett budget.

Self-hosting ersätter hyresavtalet på en model med ett hyresavtal på en maskin, och AWS gör den aritmetiken på sin egen sida: en model unit av provisioned throughput för en customized model, en månads bindning, är ”1 model unit × $21.18 × 24 hours × 31 days = $15,757.92” i månaden.¹⁰ Att hyra metallen direkt är billigare och inte gratis — $3.99 per GPU-timme on demand för en H100, $1.99 preemptible¹¹ — ungefär $2,900 i månaden för ett kort som måste vara uppe oavsett om någon frågar något. Hela retrieval-vägen vid tiotusen frågor i månaden är $174.52 för sex månader.

Det är här LoRA förtjänar sin plats, som ett budgetargument snarare än ett tekniskt. Mätt på samma model är en rank-16 adapter över attention och feed-forward-lagren 8,798,208 parametrar — 1.781 % av modellen, 17.6 MB i bfloat16 — mot 0.988 GB basvikter, och dess optimiser och gradient state är 140.77 MB där full fine-tuning behöver 7.90 GB, en faktor 56. Konsekvensen är inte billigare träning utan att en laddad basmodell kan tjäna många adapters, vilket är det enda sättet en GPU:s fasta kostnad delas med något. Managed training speglar det: $0.48 per miljon tokens low-rank upp till 16B mot $0.54 full, med ett minimum på $4.00 per jobb.¹¹ Det golvet är detaljen. Vid 24,389 tokens i tre epochs faktureras varje omträning på denna corpus $4.00 snarare än de $0.04 den beräknas till — $104 i minimikostnader över tjugosex veckokörningar, för nittioen cents aritmetik.

Två kolumner till som bara syns på fakturan.

Data residency kostar ungefär tio procent, och två leverantörer är överens om siffran. OpenAI tar ut ”a 10 % uplift” på data-residency-endpoints för modeller släppta den 5 mars 2026 eller senare;⁷ Vertex prissätter sina icke-globala endpoints till $1.65 mot $1.50, samma tio procent.⁶ Ställ det mot de femtio procent en tuned endpoint kostar och folkloren vänds: residency är billigt och fine-tuning är det inte — och fine-tuning är ändå inte det privata alternativet, eftersom korpusen når leverantören oavsett, en gång vid träning i stället för en gång per anrop.

Det mest explicita priset som någonsin satts på dina data finns på samma sida, som listar en fine-tuned model två gånger: med data sharing aktiverat är inference exakt hälften — $2.00 mot $4.00 input, $8.00 mot $16.00 output.⁷ Att låta leverantören behålla det du skickade är värt 50 % rabatt, vilket säger vad det är värt för dem.

Distillation — att träna en liten egen model på en stor models svar — erbjuds ofta som en väg ut ur båda. Prissätt det och det är det inte, eftersom läraren är systemet du försökte ersätta: att producera tvåhundra träningsexempel genom att ställa tvåhundra frågor till retrieval-vägen kostar 200 × $0.002906 = $0.58, utöver $0.73 för att träna på dem. Distillation är något du gör efter att retrieval-pipelinen fungerar, för att göra den billigare, och den ärver varje faktum som retrievern fick fel.

Pengar är den synliga halvan. Den andra kommer som väntan, med samma orsak som fakturan: modellen läser hela prompt innan den säger ett ord. Kapitel 13 mätte prefill mot decode på en model du kunde röra; här är samma mätning, en körning, en maskin, mot prompt-längd:

De absoluta siffrorna hör till en 0.5B model på sexton CPU-trådar och säger inget om en hosted frontier model. Formen överförs exakt: prefill växer med prompt-längd, och kostnaden per token kryper upp när Kapitel 9:s kvadratiska term börjar synas — 4.79 ms vid tusen tokens mot 6.04 ms vid åttatusen, en 26 % straffkostnad för att bara vara längre.

Konsekvensen för de tre vägarna är direkt. Väg ett prefillar fyrtiotretusen tokens per fråga, och en cache hit är det som gör det uthärdligt — Kapitel 16 förklarade varför: en cache-läsning ersätter prefill-arbete, så den köper latency och pengar i en transaktion. Väg två prefillar tusen och lägger först till en round trip till indexet. Väg tre prefillar tjugoåtta och lägger inte till något, vilket gör den mätbart snabbast av de tre på att svara. Den svarar bara på fel sak.

Tre misslyckanden som ser ut som model-problem och inte är det — tio minuter här sparar en månad senare:

Och kravet över alltihop: det här beslutet kan inte fattas utan en evaluation set, och leverantören som säljer fine-tune säger det själv. OpenAI:s guide öppnar 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”, och lägger till att om femtio bra exempel inte ändrar något är problemet uppgiften eller prompt, inte datavolymen.¹ Tjugo frågor, vilket är vad det här kapitlet använde, visar en mekanism och kan inte välja en leverantör — Kapitel 4 mätte varför, och vad du ska göra när tjugo fall är allt du har — upprepa dem, para ihop dem och mät spridningen mellan körningar — är Kapitel 29.

Fyra kolumner, och bara den sista avgör:

Regeln som faller ut ur det, och den är kort nog att behålla: börja med prompt; lägg till retrieval när fakta rör sig; fine-tune bara när du har mätt att det du fortfarande saknar är en form, inte ett faktum — och prissätt svaret, inte prompt, innan du gör det.

Den obekväma versionen, för alla som kom hit efter att redan ha bestämt sig: i det uppmätta fallet i det här kapitlet är fine-tuning den billigaste vägen över fyratusen frågor i månaden, och på fakta kan den fortfarande inte slå att svara CLAUDE.md på allt.

Varje pris här har varit per token, och varje väg ett annat sätt att arrangera tokens. Det är på väg att sluta vara sant.

Kapitel 21 lämnar text. En bild som går in i en model är inte en string utan ett rutnät av patches med ett token-antal du inte valde; en talad minut faktureras per sekund hos en leverantör och per audio token hos en annan; syntetiskt tal säljs per tecken, transkribering per minut, rå compute per GPU-sekund. Frågan det här kapitlet besvarade med en kostnadsfunktion — vilket är billigare? — kan inte ens ställas förrän enheterna matchar, och ingen kalkylator på internet normaliserar dem.

Det är också där träning dyker upp igen: en image adapter med ett trigger word, och en röst klonad från ett sample. Vilket väcker frågan nästa kapitel öppnar med, och den är inte retorisk: om fine-tuning av en language model nästan alltid är fel köp, varför är fine-tuning av en image model nästan alltid rätt?

Varje pris, tröskel och multiplikator i det här kapitlet lästes från leverantörens egen sida den 7 september 2026 och citeras med det datumet, eftersom alla kommer att röra sig. De uppmätta siffrorna — token-räkningar, chunk-storlekar, retrieval-storlekar, training loss, poäng, latencies och versionshistorikräkningar — producerades på en maskin samma dag och kan reproduceras från korpusen som beskrivs ovan.

De lokala experimenten använde Qwen/Qwen2.5-0.5B-Instruct med greedy decoding, så de reproduceras exakt; adaptern är tolvradersklassen som trycktes ovan, vid rank 8 över q_proj och v_proj. Korpusen är den spårade Markdown-dokumentationen i ett fungerande mjukvaru-repository, exklusive två append-only-loggar, och dess förändringstakt räknades från det repositoryts versionshistorik.