Fine-Tune, retrieval o prompt? La decisione è economica

"Dovremmo fare fine-tuning?" viene chiesto come se fosse una domanda su un model. È una domanda su un budget, con una forma a cui nessun benchmark risponde: cosa si paga una volta, cosa si paga per domanda e cosa si ripaga ogni volta che il mondo si muove.

Le tre route inoltre non sono tre modi di fare una sola cosa, e i vendor lo dicono più chiaramente della maggior parte dei blog post. La tabella di OpenAI su ciò per cui il supervised fine-tuning è più adatto elenca quattro usi: classificazione, traduzione sfumata, generazione di contenuti in un formato specifico e correzione di fallimenti nel seguire le istruzioni.¹ Nessuno è "insegnare al model qualcosa che non sa". Il suo riassunto del beneficio è che "puoi usare prompt più brevi con meno esempi e dati di context, il che fa risparmiare sui costi dei token su scala e può ridurre la latency" — un argomento sulla fattura, dall’azienda che vende la feature.

Quindi:

• Il fine-tuning insegna forma e comportamento. Tono, formato, la struttura di una risposta, un confine che puoi dimostrare ma non descrivere. La versione pubblicata più forte è la Superficial Alignment Hypothesis di LIMA: la knowledge viene dal pretraining, l’alignment insegna soprattutto in quale sotto-distribuzione di formati parlare — ed è per questo che lì sono bastati mille esempi curati.²
• Il retrieval fornisce fatti che cambiano. È l’unica delle tre route in cui una modifica alla tua documentazione raggiunge la risposta senza toccare il model.
• Il prompting copre la maggior parte dei casi reali, ed è la baseline onesta. L’in-context learning è il default da Language Models are Few-Shot Learners: il task viene dimostrato dentro il prompt e nessun weight si muove.³

Due paper misurati chiudono la porta sull’errore al centro. Ovadia e colleghi hanno confrontato l’iniezione di knowledge tramite unsupervised fine-tuning con l’iniezione tramite retrieval, e il retrieval ha vinto con costanza, anche su fatti che il base model aveva già visto in pretraining.⁴ Gekhman e colleghi hanno misurato il danno: gli esempi che introducono nuova knowledge vengono appresi lentamente, e quando il model finalmente li apprende il suo tasso di hallucination su altre domande aumenta.⁵ Insegnare fatti tramite fine-tuning non si limita a fallire; degrada risposte su cui non stavi facendo training.

Quella metà è chiusa. La metà economica no, ed è il resto del capitolo.

Un caso, eseguito in tre modi: supporto tecnico sulla tua documentazione, che cambia ogni settimana.

Il corpus è reale e su questo disco: i 23 documenti Markdown che un repository software in uso conserva come documentazione interna — la guida di build, le regole di brand, il translation brief, dieci manuali di servizio, le note su performance e sicurezza. Misurato con o200k_base, l’encoding del Capitolo 7:

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

Quarantatremila token sono una dimensione comoda per questa decisione: stanno in qualsiasi context window moderna, quindi tutte e tre le route sono davvero disponibili. A dieci milioni la decisione è già presa per te, ed è retrieval.

Ora il lavoro che fa la parola "settimanale". Il churn della documentazione di solito viene affermato; qui viene contato, dalla cronologia versioni di quel repository:

I documenti si muovono circa una settimana sì e una no. Le stringhe visibili agli utenti — che sono ciò su cui un support desk riceve davvero domande — si sono mosse in ogni settimana in cui sono esistite, a circa venti commit a settimana. Qualunque route scegliamo deve sopravvivere a questo, e "quanto spesso cambia la cosa su cui hai fatto training?" risulta avere un numero nel tuo repository, non un’opinione.

Venti domande di supporto realistiche sono state scritte contro questo corpus, una per topic, e ogni cifra qui sotto è calcolata su quelle venti.

La cosa più semplice che funziona: mettere l’intero corpus nel system prompt, la domanda alla fine, e lasciare che il model la trovi.

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

Ogni numero lì è stato contato tranne l’ultimo: 150 output token sono un’assunzione, scelta dentro l’intervallo dei turni assistant fatturati nel Capitolo 16. È l’unica cifra qui che non è stata eseguita, viene applicata in modo identico a tutte e tre le route, e la sezione sul break-even mostra esattamente quanto si muove la conclusione quando la cambi.

Alle tariffe lette dalla pagina del provider il 7 settembre 2026 — $1,50 per milione di input token, $9,00 per milione di output⁶ — sono $0,066317 a domanda. Stai pagando per rileggere quarantatremila token per rispondere a tredici.

La correzione del Capitolo 16 si applica direttamente: il corpus è stabile ed è all’inizio, quindi è un prefix di cache perfetto, e rileggerlo costa un decimo — $0,007864 a domanda, un taglio dell’88 %. Si applica anche l’avvertimento del Capitolo 16, nella forma che quel capitolo aveva segnalato ma non prezzato. Questo provider non addebita un premium di scrittura; addebita affitto. Una cache esplicita costa $0,000001 per token memorizzato per ora,⁶ quindi tenere caldi 43.298 token costa

che qualcuno faccia domande oppure no. Sono $189,78 in sei mesi, per una stanza vuota. Dividi l’affitto per il risparmio per domanda e la condizione esce in una riga: cachare questo corpus si ripaga sopra 0,74 domande l’ora — 546 al mese una volta contato anche il rebuild settimanale della cache. Sotto, la feature che hai abilitato per risparmiare denaro lo perde.

Stessa route, stesso codice, un flag, cinque volte la fattura. Il Capitolo 16 ha trovato una versione di questo causata da un timestamp nel posto sbagliato; qui non c’è nulla di sbagliato tranne il traffico. Una cache è una scommessa sul volume, e su questo provider la piazzi a ore.

Il retriever del Capitolo 19, invariato: taglia sui confini di sezione con un header contestuale, indicizza, mette nel prompt i quattro estratti migliori. Misurato sulle venti domande:

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

Quarantadue volte meno prompt token della route uno, a $0,002906 a domanda. L’indice costa $0,0070 da costruire a $0,15 per milione di embedding token⁶ — meno del valore di tre domande — e gli stessi $0,0070 per ricostruirlo da zero ogni volta che la documentazione cambia. Ricostruire l’intero indice ogni settimana per sei mesi costa diciotto centesimi.

Una cosa merita una pausa. Il retrieval distrugge il prompt caching. Il prefix stabile ora è l’istruzione di sistema da 140 token; dal token 141 il prompt cambia a ogni call, perché gli estratti sono scelti per domanda. E 140 token sono sotto ogni minimo di cache citato dal Capitolo 16. Quindi la route due non può essere cached affatto, il che suona male e non lo è: non cachare 1.037 token è più economico che cacharne 43.298.

Questa è una regola generale da portare con sé: le due grandi tecniche di risparmio token si escludono a vicenda sullo stesso contenuto, e vince quella che rimuove più token. Il retrieval ne rimuove il 97,6 %.

Fai training su duecento esempi nello house style, poi poni domande senza allegare alcuna documentazione.

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

Il training costa 24.389 × 3 × $10,00 per milione = $0,7317. È l’intero costo di costruzione, meno di un caffè, ed è esattamente per questo che tanti team lo pagano prima di verificare se aiuta.

Ora la trappola, ed è il motivo per cui questo capitolo esiste. Un model fine-tuned non costa quanto il suo base model in esecuzione. La pagina prezzi lo dice in una frase: "for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model."⁶ Non il training. L’inference, su ogni token, finché il model vive.

Quindi mettilo in una formula. Siano $p_i$ e $p_o$ i prezzi base di input e output, $m$ il moltiplicatore tuned, $L_R$ la lunghezza del prompt della route che stai sostituendo, $L_F$ la lunghezza del prompt dopo il fine-tuning e $O$ la lunghezza della risposta. Il fine-tuning è più economico per domanda solo quando

Il primo termine è ovvio: il tuo nuovo prompt corto, maggiorato. Il secondo no, ed è dove finiscono i soldi — il surcharge sulla risposta, che non ha nulla a che fare con il tuo prompt e che il training non può accorciare. Con i numeri misurati — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — la soglia è

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

Alla lunghezza di risposta misurata, 492 token — di cui 450 sono il surcharge sulla risposta, non il prompt. Sostituire un prompt più corto di così è più costoso per domanda, per sempre, a qualsiasi volume; e la soglia cresce linearmente con quanto parla il tuo assistant, quindi uno che scrive risposte lunghe non potrà mai fine-tune la strada verso un token più economico, per quanto prompt elimini.

Lo stesso fatto visto dall’altro lato è la frase da ricordare. Dei $0,002088 per domanda della route fine-tuned, il 97,0 % è la risposta. Il fine-tuning ottimizza il restante tre per cento.

Quattro numeri descrivono ognuna di queste route: cosa paghi una volta, cosa paghi quando la documentazione cambia, cosa paghi ogni ora a prescindere, e cosa paghi per domanda. Questo estende computeCost del Capitolo 16 senza modificarlo.

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

Il tuned model non è un listino diverso, è lo stesso moltiplicato:

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

Quella riga evidenziata è l’intero argomento della sezione precedente scritto come codice: il moltiplicatore arriva anche su output.

Sei mesi, con la documentazione aggiornata settimanalmente:

E i crossover, che sono i quattro numeri di cui un budget ha davvero bisogno:

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

Leggi i primi due insieme, perché sono il punto del capitolo. Un corpus stazionario fa ripagare il fine-tuning in centocinquanta domande; un corpus che cambia ogni settimana sposta lo stesso crossover di un fattore ventisette, e nulla del model è cambiato — solo quanto spesso lo ripaghi. Il costo di costruzione è una nota a piè di pagina; il costo di manutenzione è la decisione.

Se ora concludi che un support desk affollato dovrebbe fare fine-tuning, l’aritmetica è d’accordo con te. È comunque sbagliato, e la prossima sezione spiega perché.

Il foglio costi ha una colonna che non può calcolare, quindi questa sezione esegue il fine-tune: localmente, su un piccolo open model, con l’adapter scritto a mano invece che preso da una library. Il Capitolo 11 ha costruito LoRA; eccolo qui, su q_proj e v_proj di tutti i 24 layer di Qwen2.5-0.5B-Instruct a 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

I duecento esempi di training vengono meccanicamente dal corpus, quindi sono riproducibili: la domanda è un heading di sezione trasformato in domanda, la risposta è il testo di quella sezione nello house style rigido — una riga che inizia con Short answer:, una riga che inizia con Source: con il percorso del file. Il formato è la forma insegnata; il percorso è il fatto. Poi due numeri su venti domande held-out: la risposta esce nello house style, e nomina il file che risponde davvero alla domanda?

Due baseline rendono la tabella leggibile, ed entrambe sono un’insistenza del Capitolo 4, non un’aggiunta tardiva. Dieci delle venti risposte giuste sono lo stesso file, quindi un model che ignora la domanda e risponde sempre CLAUDE.md segna 10/20. E il retriever ha il suo ceiling: su queste venti domande i suoi quattro estratti contengono il file giusto 14 volte e lo posizionano primo 7, quindi 14/20 è il massimo che qualsiasi reader potrebbe ottenere usandolo.

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 è stata appresa, completamente e in fretta. Da zero a diciannove su venti, con un adapter da 540.672 parametri — lo 0,109 % del model — in cinque minuti di training su un processore senza scheda grafica in vista.

I fatti no. Otto su venti non è distinguibile dai dieci che ottieni ignorando del tutto la domanda, e l’intervallo del Capitolo 4 su venti campioni lo dice a voce alta. Quei percorsi file erano nei dati di training tre volte; ciò che è uscito è stata l’abitudine di finire con una riga Source: dall’aria plausibile. Alla domanda in cima a questo capitolo, il model fine-tuned ha risposto Short answer: 10.x . . . e citato CLAUDE.md. La risposta giusta, che si trova in CLAUDE.md, è 18.17.0.

E poi la forma si è rotta, ed è la riga che giustifica l’esperimento. Dai al model fine-tuned mille token di estratti retrieved — una forma di prompt che non ha mai visto, dato che ogni training prompt era di ventotto token — e lo house style crolla da 19/20 a 1/20. Sulla domanda in cima a questo capitolo risponde 18.17.0 — corretto, e senza nessuno del formato per cui era stato addestrato. Quindi il fine-tuning non ha insegnato un formato; ha insegnato un formato condizionato ai prompt nel training set, e il primo prompt con un aspetto diverso si è portato via il formato. Qualunque cosa tu usi per il fine-tuning diventa l’unica distribuzione di input in cui il tuo model è bravo, e nessuno lo mette nel foglio di calcolo.

Un’ultima nota sulla metrica, puntando dritto al Capitolo 29: "fonte corretta" valuta forma e fatto insieme, motivo per cui entrambe le righe di retrieval sembrano pessime anche se entrambi i model hanno azzeccato il fatto di quella domanda. Un solo numero end-to-end stava nascondendo tre cose — un retriever a 14/20 recall, un reader da 0,5B e un formato di citazione — e scegliere cosa correggere significa separarle prima di misurare, non dopo.

Ora la colonna che i vendor compilano per te. Un model fine-tuned non è un asset che possiedi; è un lease sul base model di qualcun altro, con una data di scadenza stampata sopra. Il 7 settembre 2026 la sezione fine-tuning della pagina prezzi di OpenAI riportava per intero questo avviso:

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 timeline è datata al giorno: 7 maggio 2026, chiusa alle organizzazioni che non avevano mai fatto fine-tuning; 2 luglio 2026, chiusa a quelle che non avevano eseguito inference su un model fine-tuned nei sessanta giorni precedenti; 6 gennaio 2027, nessun nuovo job.⁸ La stessa pagina programma lo shutdown dei model fine-tuned stessi — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — il 23 ottobre 2026, ciascuno con un recommended replacement base model, che è un modo educato per dire: addestralo di nuovo.

L’altro frontier vendor non ti ha mai venduto il lease. L’indice della documentazione Anthropic elenca 699 pagine e nessuna riguarda il fine-tuning; le sezioni di model customization della pagina prezzi Bedrock coprono Amazon Nova, Amazon Titan, Cohere, Meta e model open-weight OpenAI, e nessun Claude.⁹¹⁰ Se la tua architettura dipende da un fine-tune, una delle tre famiglie frontier ti è semplicemente indisponibile, a qualsiasi budget.

Il self-hosting sostituisce il lease su un model con un lease su una macchina, e AWS fa quell’aritmetica sulla propria pagina: una model unit di provisioned throughput per un model custom, impegno di un mese, è "1 model unit × $21.18 × 24 hours × 31 days = $15,757.92" al mese.¹⁰ Affittare direttamente il metal è più economico e non gratuito — $3,99 per GPU-hour on demand per un H100, $1,99 preemptible¹¹ — circa $2.900 al mese per una scheda che deve restare accesa che qualcuno faccia domande oppure no. L’intera route di retrieval a diecimila domande al mese costa $174,52 per sei mesi.

Qui LoRA si guadagna il suo posto, come argomento di budget più che tecnico. Misurato sullo stesso model, un adapter rank-16 su attention e layer feed-forward è 8.798.208 parametri — l’1,781 % del model, 17,6 MB in bfloat16 — contro 0,988 GB di base weights, e il suo stato di optimizer e gradient è 140,77 MB dove il full fine-tuning richiede 7,90 GB, un fattore 56. La conseguenza non è training più economico, ma che un base model caricato può servire molti adapter, che è l’unico modo in cui il costo fisso di una GPU viene diviso per qualcosa. Il training managed lo riflette: $0,48 per milione di token low-rank fino a 16B contro $0,54 full, con un minimo di $4,00 per job.¹¹ Quel floor è il dettaglio. A 24.389 token per tre epoch, ogni retraining su questo corpus fattura $4,00 invece dei $0,04 a cui arriva il calcolo — $104 di minimi su ventisei run settimanali, per novantuno centesimi di aritmetica.

Altre due colonne che compaiono solo in fattura.

La data residency costa circa il dieci per cento, e due provider concordano sulla cifra. OpenAI addebita "a 10 % uplift" sugli endpoint di data-residency per i model rilasciati dal 5 marzo 2026 in poi;⁷ Vertex prezza i suoi endpoint non globali a $1,65 contro $1,50, lo stesso dieci per cento.⁶ Mettilo contro il cinquanta per cento che costa un endpoint tuned e il folklore si ribalta: la residency è economica e il fine-tuning no — e il fine-tuning non è comunque l’opzione privata, dato che il corpus raggiunge il provider in ogni caso, una volta al momento del training invece che una volta per call.

Il prezzo più esplicito mai messo sui tuoi dati è sulla stessa pagina, che elenca due volte un model fine-tuned: con data sharing abilitato, l’inference costa esattamente la metà — $2,00 contro $4,00 input, $8,00 contro $16,00 output.⁷ Lasciare che il provider conservi ciò che hai inviato vale uno sconto del 50 %, il che ti dice quanto vale per loro.

Distillation — addestrare un tuo piccolo model sulle risposte di uno grande — viene spesso proposta come via d’uscita da entrambe. Prezzala e non lo è, perché il teacher è il sistema che stavi cercando di sostituire: produrre duecento esempi di training chiedendo alla route di retrieval duecento domande costa 200 × $0,002906 = $0,58, oltre ai $0,73 per addestrarci sopra. La distillation è qualcosa che fai dopo che la pipeline di retrieval funziona, per renderla più economica, ed eredita ogni fatto che il retriever ha sbagliato.

Il denaro è la metà visibile. L’altra arriva come attesa, con la stessa causa della fattura: il model legge tutto il prompt prima di dire una parola. Il Capitolo 13 ha misurato il prefill contro il decode su un model che potevi toccare; qui c’è la stessa misurazione, una run, una macchina, contro la lunghezza del prompt:

I numeri assoluti appartengono a un model da 0,5B su sedici thread CPU e non dicono nulla su un frontier model hosted. La forma si trasferisce esattamente: il prefill cresce con la lunghezza del prompt, e il costo per token aumenta lentamente quando il termine quadratico del Capitolo 9 inizia a mostrarsi — 4,79 ms a mille token contro 6,04 ms a ottomila, una penalità del 26 % solo per essere più lungo.

La conseguenza per le tre route è diretta. La route uno fa prefill di quarantatremila token per domanda, e un cache hit è ciò che lo rende sopportabile — il Capitolo 16 ha spiegato perché: una lettura da cache sostituisce lavoro di prefill, quindi compra latency e denaro in una sola transazione. La route due fa prefill di mille e aggiunge prima un round trip all’indice. La route tre fa prefill di ventotto e non aggiunge nulla, il che la rende misurabilmente la più veloce delle tre nel rispondere. Sta solo rispondendo alla cosa sbagliata.

Tre failure che sembrano problemi di model e non lo sono — dieci minuti qui risparmiano un mese dopo:

E il requisito su tutto questo: questa decisione non può essere presa senza un evaluation set, e lo dice il vendor che vende il fine-tune. La guida di OpenAI apre con "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", e aggiunge che se cinquanta buoni esempi non cambiano nulla, il problema è il task o il prompt, non il volume di dati.¹ Venti domande, che è ciò che questo capitolo ha usato, mostrano un meccanismo e non possono scegliere un fornitore — il Capitolo 4 ha misurato perché, e cosa fare quando venti casi sono tutto ciò che hai — ripeterli, accoppiarli e misurare lo spread tra run — è il Capitolo 29.

Quattro colonne, e solo l’ultima decide:

La regola che ne esce, ed è abbastanza breve da tenere a mente: inizia con il prompt; aggiungi retrieval quando i fatti si muovono; fai fine-tuning solo quando hai misurato che ciò che ti manca ancora è una forma, non un fatto — e prezza la risposta, non il prompt, prima di farlo.

La versione scomoda, per chi è arrivato avendo già deciso: nel caso misurato in questo capitolo il fine-tuning è la route più economica sopra quattromila domande al mese, e sui fatti non riesce comunque a battere il rispondere CLAUDE.md a tutto.

Ogni prezzo qui è stato per token, e ogni route un modo diverso di disporre token. Questo sta per smettere di essere vero.

Il Capitolo 21 lascia il testo. Un’immagine che entra in un model non è una string ma una griglia di patch con un conteggio di token che non hai scelto; un minuto parlato viene fatturato al secondo da un provider e ad audio token da un altro; il parlato sintetico viene venduto a carattere, la transcription a minuto, il compute grezzo a GPU-second. La domanda a cui questo capitolo ha risposto con una funzione di costo — qual è più economico? — non può nemmeno essere posta finché le unità non coincidono, e nessun calcolatore su internet le normalizza.

È anche il punto in cui il training ricompare: un image adapter con una trigger word, e una voce clonata da un sample. Il che solleva la domanda con cui apre il prossimo capitolo, e non è retorica: se il fine-tuning di un language model è quasi sempre l’acquisto sbagliato, perché il fine-tuning di un image model è quasi sempre quello giusto?

Ogni prezzo, soglia e moltiplicatore in questo capitolo è stato letto dalla pagina del provider il 7 settembre 2026 ed è citato con quella data, perché tutti si muoveranno. Le cifre misurate — conteggi di token, dimensioni dei chunk, dimensioni del retrieval, training loss, punteggi, latency e conteggi della cronologia versioni — sono state prodotte su una macchina lo stesso giorno e sono riproducibili dal corpus descritto sopra.

Gli esperimenti locali hanno usato Qwen/Qwen2.5-0.5B-Instruct con greedy decoding, quindi si riproducono esattamente; l’adapter è la classe di dodici righe stampata sopra, a rank 8 su q_proj e v_proj. Il corpus è la documentazione Markdown tracciata di un repository software in uso, esclusi due log append-only, e il suo tasso di modifica è stato contato dalla cronologia versioni di quel repository.