Fine-tuning, retrieval o prompt? La decisió és econòmica

«Hem de fer fine-tuning?» es pregunta com si fos una pregunta sobre un model. És una pregunta sobre un pressupost, amb una forma que cap benchmark respon: què es paga una vegada, què es paga per pregunta i què es torna a pagar cada cop que el món es mou.

Les tres rutes tampoc no són tres maneres de fer una mateixa cosa, i els proveïdors ho diuen més clarament que la majoria de blogs. La pròpia taula d’OpenAI sobre per a què és millor el supervised fine-tuning enumera quatre usos: classificació, traducció matisada, generació de contingut en un format concret i correcció de fallades en el seguiment d’instruccions.¹ Cap d’ells és «ensenyar al model una cosa que no sap». El seu resum del benefici és que «pots utilitzar prompts més curts amb menys exemples i dades de context, cosa que estalvia costos de token a escala i pot reduir la latència» — un argument sobre la factura, de l’empresa que ven la funcionalitat.

Per tant:

• El fine-tuning ensenya forma i comportament. To, format, l’estructura d’una resposta, un límit que pots demostrar però no descriure. La versió publicada més forta és la Hipòtesi d’Alineació Superficial de LIMA: el coneixement ve del pretraining, l’alineació sobretot ensenya en quina subdistribució de formats cal parlar — i per això allà n’hi va haver prou amb mil exemples curats.²
• El retrieval aporta fets que canvien. És l’única de les tres on una edició de la teva documentació arriba a la resposta sense tocar el model.
• El prompting cobreix la majoria de casos reals, i és la línia base honesta. L’in-context learning ha estat el valor per defecte des de Language Models are Few-Shot Learners: la tasca es demostra dins del prompt i no es mou cap pes.³

Dos articles mesurats tanquen la porta a l’error del mig. Ovadia i col·laboradors van comparar injectar coneixement mitjançant fine-tuning no supervisat amb injectar-lo mitjançant retrieval, i el retrieval va guanyar de manera consistent, incloent-hi fets que el model base ja havia vist durant el pretraining.⁴ Gekhman i col·laboradors van mesurar-ne el dany: els exemples que introdueixen coneixement nou s’ajusten lentament, i quan el model finalment els ajusta, la seva taxa d’al·lucinació en altres preguntes puja.⁵ Ensenyar fets amb fine-tuning no només falla; degrada respostes sobre les quals no estaves entrenant.

Aquesta meitat queda resolta. La meitat econòmica no, i és la resta del capítol.

Un cas, executat de tres maneres: suport tècnic sobre la teva pròpia documentació, que canvia cada setmana.

El corpus és real i és en aquest disc: els 23 documents Markdown que un repositori de programari en actiu conserva com a documentació interna — la guia de build, les regles de marca, el brief de traducció, deu manuals de servei, les notes de rendiment i seguretat. Mesurat amb o200k_base, l’encoding del Capítol 7:

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

Quaranta-tres mil tokens és una mida còmoda per a aquesta decisió: cap en qualsevol context window moderna, de manera que les tres rutes són realment disponibles. Amb deu milions, la decisió ja està presa per tu, i és retrieval.

Ara la feina que fa la paraula «setmanal». Normalment s’afirma que la documentació canvia; aquí es compta, a partir de l’historial de versions d’aquest repositori:

Els documents es mouen més o menys cada dues setmanes. Les cadenes visibles per a l’usuari — que són allò sobre què realment pregunta un servei de suport — es van moure cada setmana des que existeixen, a uns vint commits per setmana. La ruta que triem ha de sobreviure a això, i «amb quina freqüència canvia allò sobre què has entrenat?» resulta tenir un número al teu propi repositori, no una opinió.

Es van escriure vint preguntes de suport realistes contra aquest corpus, una per tema, i totes les xifres de sota es calculen sobre aquestes vint.

El més simple que funciona: posa tot el corpus al system prompt, la pregunta al final, i deixa que el model ho trobi.

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

Tots aquests números es van comptar excepte l’últim: 150 output tokens és una suposició, triada dins del rang de torns d’assistent que el Capítol 16 va facturar. És l’única xifra aquí que no es va executar, s’aplica de manera idèntica a les tres rutes, i la secció de punt d’equilibri mostra exactament quant es mou la conclusió quan la canvies.

Amb les tarifes llegides de la pàgina del proveïdor el 7 de setembre de 2026 — $1.50 per milió d’input tokens, $9.00 per milió d’output⁶ — això són $0.066317 per pregunta. Estàs pagant per rellegir quaranta-tres mil tokens per respondre’n tretze.

La solució del Capítol 16 s’aplica directament: el corpus és estable i és al principi, així que és un prefix perfecte per a cache, i rellegir-lo costa una desena part — $0.007864 per pregunta, una retallada del 88 %. L’advertiment del Capítol 16 també s’aplica, en la forma que aquell capítol va assenyalar però no va costar. Aquest proveïdor no cobra cap prima d’escriptura; cobra lloguer. Una cache explícita costa $0.000001 per token emmagatzemat per hora,⁶ així que mantenir 43.298 tokens calents costa

tant si algú pregunta alguna cosa com si no. Això són $189.78 en sis mesos, per una sala buida. Divideix el lloguer per l’estalvi per pregunta i la condició surt en una línia: fer cache d’aquest corpus surt a compte per sobre de 0,74 preguntes per hora — 546 al mes un cop també es compta la reconstrucció setmanal de la cache. Per sota d’això, la funcionalitat que has activat per estalviar diners els perd.

Mateixa ruta, mateix codi, una bandera, cinc vegades la factura. El Capítol 16 en va trobar una versió causada per un timestamp al lloc equivocat; aquí no hi ha res malament excepte el trànsit. Una cache és una aposta pel volum, i en aquest proveïdor l’apostes per hores.

El retriever del Capítol 19, sense canvis: talla per límits de secció amb una capçalera contextual, indexa, posa els quatre millors extractes al prompt. Mesurat sobre les vint preguntes:

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

Quaranta-dues vegades menys prompt tokens que la ruta u, a $0.002906 per pregunta. L’índex costa $0.0070 de construir a $0.15 per milió d’embedding tokens⁶ — menys que tres preguntes — i els mateixos $0.0070 per reconstruir-lo des de zero cada cop que canvia la documentació. Reconstruir tot l’índex cada setmana durant sis mesos costa divuit cèntims.

Val la pena aturar-se en una cosa. El retrieval destrueix el prompt caching. El prefix estable ara és la instrucció de sistema de 140 tokens; a partir del token 141 el prompt és diferent en cada crida, perquè els extractes es trien per pregunta. I 140 tokens és per sota de tots els mínims de cache que el Capítol 16 citava. Per tant, la ruta dos no es pot cachejar gens, cosa que sona malament i no ho és: no fer cache de 1.037 tokens és més barat que fer cache de 43.298.

Aquesta és una regla general que val la pena endur-se: les dues grans tècniques d’estalvi de tokens són mútuament excloents sobre el mateix contingut, i guanya la que elimina més tokens. El retrieval n’elimina el 97,6 %.

Entrena amb dos-cents exemples en l’estil de la casa, després fes preguntes sense cap documentació adjunta.

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

L’entrenament costa 24.389 × 3 × $10.00 per milió = $0.7317. Aquest és tot el cost de construcció, menys que una tassa de cafè, i és exactament per això que tants equips el paguen abans de comprovar si ajuda.

Ara el parany, i és el motiu pel qual existeix aquest capítol. Un model amb fine-tuning no costa el mateix d’executar que el seu model base. La pàgina de preus ho diu en una frase: «for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.»⁶ No l’entrenament. La inferència, en cada token, mentre visqui el model.

Posem-ho, doncs, en una fórmula. Siguin $p_i$ i $p_o$ els preus base d’input i output, $m$ el multiplicador del model ajustat, $L_R$ la longitud del prompt de la ruta que substitueixes, $L_F$ la longitud del prompt després del fine-tuning, i $O$ la longitud de la resposta. El fine-tuning només és més barat per pregunta quan

El primer terme és obvi: el teu nou prompt curt, amb recàrrec. El segon no ho és, i és on van els diners — el recàrrec sobre la resposta, que no té res a veure amb el teu prompt i que l’entrenament no pot escurçar. Amb els números mesurats — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — el llindar és

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

Amb la longitud de resposta mesurada, 492 tokens — dels quals 450 són el recàrrec de la resposta, no el prompt. Substituir un prompt més curt que això és més car per pregunta, per sempre, a qualsevol volum; i el llindar creix linealment amb com de molt parla el teu assistent, així que un assistent que escriu respostes llargues mai no podrà fer fine-tuning per arribar a un token més barat, per molt prompt que esborri.

El mateix fet vist des de l’altre extrem és la frase que cal recordar. Dels $0.002088 per pregunta de la ruta amb fine-tuning, el 97,0 % és la resposta. El fine-tuning optimitza el tres per cent restant.

Quatre números descriuen qualsevol d’aquestes rutes: què pagues una vegada, què pagues quan canvia la documentació, què pagues per hora passi el que passi, i què pagues per pregunta. Això amplia el computeCost del Capítol 16 sense modificar-lo.

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

El model ajustat no és una llista de preus diferent, és la mateixa multiplicada:

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

Aquesta línia destacada és tot l’argument de la secció anterior escrit com a codi: el multiplicador també cau sobre output.

Sis mesos, amb la documentació actualitzada setmanalment:

I els punts d’encreuament, que són els quatre números que un pressupost realment necessita:

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

Llegeix els dos primers junts, perquè són el punt del capítol. Un corpus estacionari fa que el fine-tuning es pagui sol en cent cinquanta preguntes; un corpus que canvia setmanalment mou el mateix encreuament per un factor de vint-i-set, i res del model ha canviat — només la freqüència amb què el tornes a pagar. El cost de construcció és una nota a peu de pàgina; el cost de manteniment és la decisió.

Si ara conclous que un servei de suport amb molt trànsit hauria de fer fine-tuning, l’aritmètica et dona la raó. Encara és equivocat, i la secció següent explica per què.

El full de costos té una columna que no pot calcular, així que aquesta secció executa el fine-tune: localment, sobre un petit model obert, amb l’adaptador escrit a mà en lloc de treure’l d’una biblioteca. El Capítol 11 va construir LoRA; aquí el tens, sobre els q_proj i v_proj de totes les 24 capes de Qwen2.5-0.5B-Instruct amb rang 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

Els dos-cents exemples d’entrenament surten mecànicament del corpus, així que es poden reproduir: la pregunta és un encapçalament de secció convertit en pregunta, la resposta és el text d’aquella mateixa secció en un estil de casa rígid — una línia que comença amb Short answer:, una línia que comença amb Source: amb la ruta del fitxer. El format és la forma que s’ensenya; la ruta és el fet. Després, dos números sobre vint preguntes reservades: la resposta surt en l’estil de la casa, i anomena el fitxer que realment respon la pregunta?

Dues línies base fan llegible la taula, i totes dues són la insistència del Capítol 4, no una idea posterior. De les vint respostes correctes, deu són el mateix fitxer, així que un model que ignora la pregunta i sempre respon CLAUDE.md puntua 10/20. I el retriever té el seu propi sostre: entre aquestes vint preguntes, els seus quatre extractes contenen el fitxer correcte 14 vegades i el classifiquen primer 7, així que 14/20 és el màxim que qualsevol lector podria puntuar utilitzant-lo.

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

La forma es va aprendre, completament i ràpid. De zero a dinou de vint, amb un adaptador de 540.672 paràmetres — el 0,109 % del model — en cinc minuts d’entrenament en un processador sense cap targeta gràfica a la vista.

Els fets, no. Vuit de vint no es distingeix dels deu que obtens ignorant completament la pregunta, i l’interval del Capítol 4 sobre vint mostres ho diu en veu alta. Aquelles rutes de fitxer eren a les dades d’entrenament tres vegades; el que en va sortir va ser l’hàbit d’acabar amb una línia Source: d’aspecte plausible. Preguntat per la qüestió del principi d’aquest capítol, el model amb fine-tuning va respondre Short answer: 10.x . . . i va citar CLAUDE.md. La resposta correcta, que és a CLAUDE.md, és 18.17.0.

I després la forma es va trencar, que és la fila que justifica l’experiment. Dona al model amb fine-tuning mil tokens d’extractes recuperats — una forma de prompt que no havia vist mai, ja que tots els prompts d’entrenament eren de vint-i-vuit tokens — i l’estil de la casa cau de 19/20 a 1/20. Sobre la pregunta del principi d’aquest capítol respon 18.17.0 — correcte, i sense cap dels formats per als quals havia estat entrenat. Per tant, el fine-tuning no va ensenyar un format; va ensenyar un format condicionat als prompts del conjunt d’entrenament, i el primer prompt que semblava diferent se’n va endur el format. Allò sobre què fas fine-tuning es converteix en l’única distribució d’entrada on el teu model és bo, i ningú no posa això al full de càlcul.

Una última nota sobre la mètrica, apuntant directament al Capítol 29: «font correcta» puntua forma i fet alhora, i per això totes dues files de retrieval semblen terribles encara que tots dos models encertessin el fet d’aquella pregunta. Un sol número de punta a punta amagava tres coses — un retriever amb recall 14/20, un lector de 0.5B i un format de citació — i triar què arreglar vol dir separar-les abans de mesurar, no després.

Ara la columna que els proveïdors omplen per tu. Un model amb fine-tuning no és un actiu que posseeixis; és un lloguer sobre el model base d’algú altre, amb una data de caducitat impresa. El 7 de setembre de 2026, la secció de fine-tuning de la pàgina de preus d’OpenAI portava aquest avís sencer:

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.⁷

La cronologia està datada al dia: 7 de maig de 2026, tancada a organitzacions que mai no havien fet fine-tuning; 2 de juliol de 2026, tancada a les que no havien executat inferència sobre un model amb fine-tuning en seixanta dies; 6 de gener de 2027, cap job nou.⁸ La mateixa pàgina programa l’aturada dels mateixos models amb fine-tuning — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — el 23 d’octubre de 2026, cadascun amb un model base de substitució recomanat, que és una manera educada de dir: entrena’l de nou.

L’altre proveïdor de frontera mai no et va vendre el lloguer. L’índex de documentació d’Anthropic enumera 699 pàgines i cap no tracta sobre fine-tuning; les seccions de personalització de models de la pàgina de preus de Bedrock cobreixen Amazon Nova, Amazon Titan, Cohere, Meta i models open-weight d’OpenAI, i cap Claude.⁹¹⁰ Si la teva arquitectura depèn d’un fine-tune, una de les tres famílies de frontera simplement no està disponible per a tu amb cap pressupost.

L’autohostatge substitueix el lloguer d’un model pel lloguer d’una màquina, i AWS fa aquesta aritmètica a la seva pròpia pàgina: una unitat de model de throughput provisionat per a un model personalitzat, compromís d’un mes, és «1 model unit × $21.18 × 24 hours × 31 days = $15,757.92» al mes.¹⁰ Llogar directament el metall és més barat i no és gratis — $3.99 per GPU-hora sota demanda per a un H100, $1.99 preemptible¹¹ — aproximadament $2,900 al mes per una targeta que ha d’estar encesa tant si algú pregunta alguna cosa com si no. Tota la ruta de retrieval amb deu mil preguntes al mes és $174.52 per sis mesos.

Aquí és on LoRA es guanya el lloc, com a argument pressupostari més que no pas tècnic. Mesurat sobre el mateix model, un adaptador de rang 16 sobre attention i les capes feed-forward té 8.798.208 paràmetres — l’1,781 % del model, 17,6 MB en bfloat16 — contra 0,988 GB de pesos base, i el seu estat d’optimitzador i gradient és de 140,77 MB mentre que el fine-tuning complet en necessita 7,90 GB, un factor de 56. La conseqüència no és un entrenament més barat, sinó que un únic model base carregat pot servir molts adaptadors, que és l’única manera de dividir el cost fix d’una GPU entre alguna cosa. L’entrenament gestionat ho reflecteix: $0.48 per milió de tokens low-rank fins a 16B contra $0.54 complet, amb un mínim de $4.00 per job.¹¹ Aquest sòl és el detall. Amb 24.389 tokens durant tres epochs, cada reentrenament sobre aquest corpus factura $4.00 en lloc dels $0.04 que calcula — $104 de mínims en vint-i-sis execucions setmanals, per noranta-un cèntims d’aritmètica.

Dues columnes més que només apareixen a la factura.

La residència de dades costa aproximadament un deu per cent, i dos proveïdors coincideixen en la xifra. OpenAI cobra «a 10 % uplift» als endpoints amb residència de dades per als models publicats el 5 de març de 2026 o després;⁷ Vertex preua els seus endpoints no globals a $1.65 contra $1.50, el mateix deu per cent.⁶ Compara-ho amb el cinquanta per cent que costa de més un endpoint ajustat i el folklore s’inverteix: la residència és barata i el fine-tuning no — i el fine-tuning tampoc no és l’opció privada, perquè el corpus arriba igualment al proveïdor, una vegada en el moment d’entrenar en lloc d’una vegada per crida.

El preu més explícit que s’ha posat mai a les teves dades és a la mateixa pàgina, que enumera un model amb fine-tuning dues vegades: amb compartició de dades activada, la inferència és exactament la meitat — $2.00 contra $4.00 d’input, $8.00 contra $16.00 d’output.⁷ Deixar que el proveïdor conservi el que has enviat val un descompte del 50 %, cosa que et diu quant val per a ells.

La destil·lació — entrenar un model petit propi sobre les respostes d’un de gran — se sol oferir com una sortida de totes dues coses. Posa-li preu i no ho és, perquè el professor és el sistema que intentaves substituir: produir dos-cents exemples d’entrenament preguntant dues-centes vegades a la ruta de retrieval costa 200 × $0.002906 = $0.58, a més dels $0.73 per entrenar-hi. La destil·lació és una cosa que fas després que el pipeline de retrieval funcioni, per abaratir-lo, i hereta cada fet que el retriever s’ha equivocat.

Els diners són la meitat visible. L’altra arriba com una espera, amb la mateixa causa que la factura: el model llegeix tot el prompt abans de dir una paraula. El Capítol 13 va mesurar prefill contra decode en un model que podies tocar; aquí tens la mateixa mesura, una execució, una màquina, contra la longitud del prompt:

Els números absoluts pertanyen a un model de 0.5B sobre setze fils de CPU i no diuen res sobre un model de frontera allotjat. La forma es transfereix exactament: el prefill creix amb la longitud del prompt, i el cost per token s’enfila a mesura que el terme quadràtic del Capítol 9 comença a aparèixer — 4,79 ms a mil tokens contra 6,04 ms a vuit mil, una penalització del 26 % pel simple fet de ser més llarg.

La conseqüència per a les tres rutes és directa. La ruta u fa prefill de quaranta-tres mil tokens per pregunta, i un encert de cache és el que ho fa suportable — el Capítol 16 explicava per què: una lectura de cache substitueix feina de prefill, així que compra latència i diners en una sola transacció. La ruta dos fa prefill de mil i afegeix abans una anada i tornada a l’índex. La ruta tres fa prefill de vint-i-vuit i no afegeix res, cosa que la fa mesurablement la més ràpida de les tres responent. Simplement respon la cosa equivocada.

Tres fallades que semblen problemes de model i no ho són — deu minuts aquí estalvien un mes més tard:

I el requisit per sobre de tot: aquesta decisió no es pot prendre sense un conjunt d’avaluació, i el proveïdor que ven el fine-tune ho diu. La guia d’OpenAI obre amb «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 afegeix que si cinquanta bons exemples no canvien res, el problema és la tasca o el prompt, no el volum de dades.¹ Vint preguntes, que és el que ha fet servir aquest capítol, mostren un mecanisme i no poden triar un proveïdor — el Capítol 4 va mesurar per què, i què fer quan vint casos són tot el que tens — repetir-los, aparellar-los i mesurar la dispersió entre execucions — és el Capítol 29.

Quatre columnes, i només l’última decideix:

La regla que en surt, i és prou curta per recordar-la: comença amb el prompt; afegeix retrieval quan els fets es moguin; fes fine-tuning només quan hagis mesurat que el que encara et falta és una forma, no un fet — i abans de fer-ho posa preu a la resposta, no al prompt.

La versió incòmoda, per a qui hagi arribat havent-ho decidit ja: en el cas mesurat d’aquest capítol, el fine-tuning és la ruta més barata per sobre de quatre mil preguntes al mes, i en els fets encara no pot superar respondre CLAUDE.md a tot.

Fins aquí, cada preu ha estat per token, i cada ruta una manera diferent d’ordenar tokens. Això està a punt de deixar de ser cert.

El Capítol 21 abandona el text. Una imatge que entra en un model no és una string sinó una graella de patches amb un recompte de tokens que no has triat; un minut parlat es factura per segon en un proveïdor i per audio token en un altre; la veu sintètica es ven per caràcter, la transcripció per minut, el compute brut per GPU-segon. La pregunta que aquest capítol responia amb una sola funció de cost — què és més barat? — ni tan sols es pot fer fins que les unitats coincideixen, i cap calculadora d’internet les normalitza.

També és on torna a aparèixer l’entrenament: un adaptador d’imatge amb una trigger word, i una veu clonada a partir d’una mostra. Això planteja la pregunta amb què obre el capítol següent, i no és retòrica: si fer fine-tuning d’un model de llenguatge gairebé sempre és la compra equivocada, per què fer fine-tuning d’un model d’imatge gairebé sempre és la correcta?

Cada preu, llindar i multiplicador d’aquest capítol es va llegir de la pàgina pròpia del proveïdor el 7 de setembre de 2026 i se cita amb aquesta data, perquè tots es mouran. Les xifres mesurades — recomptes de tokens, mides de chunks, mides de retrieval, training loss, puntuacions, latències i recomptes de l’historial de versions — es van produir en una màquina el mateix dia i es poden reproduir a partir del corpus descrit més amunt.

Els experiments locals van utilitzar Qwen/Qwen2.5-0.5B-Instruct amb greedy decoding, així que es reprodueixen exactament; l’adaptador és la classe de dotze línies impresa més amunt, amb rang 8 sobre q_proj i v_proj. El corpus és la documentació Markdown versionada d’un repositori de programari en actiu, excloent-ne dos logs només d’annexió, i la seva taxa de canvi es va comptar a partir de l’historial de versions d’aquest repositori.