Fine-tuning, recuperación ou prompt? A decisión é económica

"Debemos facer fine-tuning?" pregúntase como se fose unha cuestión sobre un modelo. É unha cuestión sobre un orzamento, cunha forma que ningún benchmark responde: que se paga unha vez, que se paga por pregunta e que se volve pagar cada vez que o mundo se move.

As tres rutas tampouco son tres maneiras de facer unha soa cousa, e os provedores díxeno máis claro ca a maioría dos posts de blog. A propia táboa de OpenAI sobre para que é mellor o fine-tuning supervisado enumera catro usos: clasificación, tradución matizada, xeración de contido nun formato específico e corrección de fallos ao seguir instrucións.¹ Ningún deles é "ensinarlle ao modelo algo que non sabe". O seu resumo do beneficio é que "podes usar prompts máis curtos con menos exemplos e datos de contexto, o que aforra custos de token a escala e pode reducir a latencia" — un argumento sobre a factura, da empresa que vende a función.

Así que:

• O fine-tuning ensina forma e comportamento. Ton, formato, a forma dunha resposta, un límite que podes demostrar pero non describir. A versión publicada máis forte é a Hipótese de aliñamento superficial de LIMA: o coñecemento vén do pretraining, o aliñamento ensina sobre todo en que subdistribución de formatos falar — por iso alí abondaron mil exemplos curados.²
• A recuperación achega feitos que cambian. É a única das tres na que unha edición na túa documentación chega á resposta sen tocar o modelo.
• O prompting cobre a maioría dos casos reais, e é a liña base honesta. A aprendizaxe en contexto é o estándar desde Language Models are Few-Shot Learners: a tarefa demóstrase dentro do prompt e non se move ningún peso.³

Dous artigos medidos pechan a porta ao erro do medio. Ovadia e colegas compararon inxectar coñecemento mediante fine-tuning non supervisado fronte a inxectalo mediante recuperación, e a recuperación gañou de forma consistente, incluídos feitos que o modelo base xa vira no pretraining.⁴ Gekhman e colegas mediron o dano: os exemplos que introducen coñecemento novo axústanse lentamente, e cando o modelo finalmente os axusta, a súa taxa de alucinación noutras preguntas sobe.⁵ Ensinar feitos con fine-tuning non só falla; degrada respostas sobre as que nin sequera estabas adestrando.

Esa metade queda resolta. A metade económica non, e é o resto do capítulo.

Un caso, executado de tres maneiras: soporte técnico sobre a túa propia documentación, que cambia cada semana.

O corpus é real e está neste disco: os 23 documentos Markdown que un repositorio de software en activo conserva como documentación interna — a guía de compilación, as regras de marca, o resumo de tradución, dez manuais de servizo, as notas de rendemento e seguridade. Medido con o200k_base, a codificación do capítulo 7:

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

Corenta e tres mil tokens é un tamaño cómodo para esta decisión: cabe en calquera context window moderna, así que as tres rutas están realmente dispoñibles. Con dez millóns, a decisión xa está tomada por ti, e é recuperación.

Agora o traballo que está facendo a palabra "semanal". O movemento da documentación adoita afirmarse; aquí cóntase, desde o historial de versións dese repositorio:

Os documentos móvense aproximadamente cada dúas semanas. As cadeas visibles para usuarios — que son o que realmente lle preguntan a unha mesa de soporte — movéronse todas as semanas desde que existen, a uns vinte commits por semana. A ruta que escollamos ten que sobrevivir a iso, e "con que frecuencia cambia o que adestraches?" resulta ter un número no teu propio repositorio, non unha opinión.

Escribíronse vinte preguntas de soporte realistas contra este corpus, unha por tema, e todas as cifras de abaixo calcúlanse sobre esas vinte.

O máis simple que funciona: mete todo o corpus no system prompt, a pregunta ao final, e deixa que o modelo o atope.

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

Todos os números de aí foron contados agás o último: 150 tokens de saída é unha suposición, escollida dentro do intervalo de quendas de assistant facturadas no capítulo 16. É a única cifra aquí que non se executou, aplícase de forma idéntica ás tres rutas, e a sección de punto de equilibrio mostra exactamente canto se move a conclusión cando a cambias.

Coas tarifas lidas da páxina do provedor o 7 de setembro de 2026 — $1.50 por millón de tokens de entrada, $9.00 por millón de saída⁶ — iso son $0.066317 por pregunta. Estás pagando por reler corenta e tres mil tokens para responder trece.

A corrección do capítulo 16 aplícase directamente: o corpus é estable e está ao principio, así que é un prefixo de cache perfecto, e lelo de volta custa unha décima parte — $0.007864 por pregunta, un recorte do 88 %. Tamén se aplica a advertencia do capítulo 16, na forma que aquel capítulo sinalou e non puxo en prezo. Este provedor non cobra prima por escritura; cobra alugueiro. Unha cache explícita custa $0.000001 por token almacenado por hora,⁶ así que manter 43,298 tokens quentes custa

pregunte alguén ou non. Iso son $189.78 en seis meses, por unha sala baleira. Divide o alugueiro polo aforro por pregunta e a condición sae nunha soa liña: poñer en cache este corpus compensa por riba de 0.74 preguntas por hora — 546 ao mes unha vez contado tamén o rebuild semanal da cache. Por baixo diso, a función que activaches para aforrar cartos pérdeos.

Mesma ruta, mesmo código, unha bandeira, cinco veces a factura. O capítulo 16 atopou unha versión disto causada por unha marca de tempo no lugar equivocado; aquí non hai nada mal agás o tráfico. Unha cache é unha aposta polo volume, e neste provedor faina por hora.

O recuperador do capítulo 19, sen cambios: cortar nos límites de sección cunha cabeceira contextual, indexar, poñer os catro mellores extractos no prompt. Medido sobre as vinte preguntas:

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

Corenta e dúas veces menos tokens de prompt ca na ruta un, a $0.002906 por pregunta. O índice custa $0.0070 construílo a $0.15 por millón de embedding tokens⁶ — menos ca tres preguntas — e os mesmos $0.0070 reconstruílo desde cero cada vez que cambia a documentación. Reconstruír o índice completo cada semana durante seis meses custa dezaoito centavos.

Hai unha cousa na que paga a pena deterse. A recuperación destrúe o prompt caching. O prefixo estable é agora a instrución de sistema de 140 tokens; desde o token 141 o prompt difire en cada chamada, porque os extractos escóllense por pregunta. E 140 tokens queda por baixo de todos os mínimos de cache que citou o capítulo 16. Así que a ruta dous non se pode poñer en cache en absoluto, o que soa mal e non o é: non poñer en cache 1,037 tokens é máis barato ca poñer en cache 43,298.

Esa é unha regra xeral que convén levar contigo: as dúas grandes técnicas de aforro de tokens son mutuamente excluíntes sobre o mesmo contido, e gaña a que elimina máis tokens. A recuperación elimina o 97.6 % deles.

Adestra con douscentos exemplos no estilo da casa, e logo fai preguntas sen documentación anexada.

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

O adestramento custa 24,389 × 3 × $10.00 por millón = $0.7317. Ese é todo o custo de construción, menos ca un café, que é exactamente por que tantos equipos o pagan antes de comprobar se axuda.

Agora a trampa, e é a razón pola que existe este capítulo. Un modelo con fine-tuning non custa o mesmo ca o seu modelo base ao executalo. A páxina de prezos dio nunha frase: "for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model."⁶ Non o adestramento. A inferencia, en cada token, mentres viva o modelo.

Así que méteo nunha fórmula. Sexan $p_i$ e $p_o$ os prezos base de entrada e saída, $m$ o multiplicador do tuned, $L_R$ a lonxitude do prompt da ruta que estás substituíndo, $L_F$ a lonxitude do prompt despois do fine-tuning, e $O$ a lonxitude da resposta. O fine-tuning é máis barato por pregunta só cando

O primeiro termo é obvio: o teu novo prompt curto, con recarga. O segundo non o é, e é onde vai o diñeiro — o sobrecusto da resposta, que non ten nada que ver co teu prompt e que o adestramento non pode acurtar. Cos números medidos — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — o limiar é

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

Coa lonxitude de resposta medida, 492 tokens — dos cales 450 son o sobrecusto da resposta, non o prompt. Substituír un prompt máis curto ca iso é máis caro por pregunta, para sempre, a calquera volume; e o limiar medra linealmente co moito que fale o teu assistant, así que un que escribe respostas longas nunca poderá facer fine-tuning ata acadar un token máis barato por moito prompt que elimine.

O mesmo feito visto desde o outro extremo é a frase que debes lembrar. Dos $0.002088 por pregunta da ruta con fine-tuning, o 97.0 % é a resposta. O fine-tuning optimiza o tres por cento restante.

Catro números describen calquera destas rutas: que pagas unha vez, que pagas cando cambia a documentación, que pagas por hora independentemente de todo, e que pagas por pregunta. Iso amplía o computeCost do capítulo 16 sen modificalo.

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

O modelo tuned non é unha lista de prezos distinta, é a mesma 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 })),   
});

Esa única liña resaltada é todo o argumento da sección anterior escrito como código: o multiplicador tamén cae sobre output.

Seis meses, coa documentación actualizada semanalmente:

E os cruces, que son os catro números que un orzamento necesita de verdade:

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

Le os dous primeiros xuntos, porque son o punto do capítulo. Un corpus estacionario fai que o fine-tuning se pague só en cento cincuenta preguntas; un corpus que cambia semanalmente move o mesmo cruce por un factor de vinte e sete, e nada cambiou no modelo — só a frecuencia coa que volves pagar por el. O custo de construción é unha nota ao pé; o custo de mantemento é a decisión.

Se agora conclúes que unha mesa de soporte ocupada debería facer fine-tuning, a aritmética dáche a razón. Aínda así é incorrecto, e a seguinte sección explica por que.

A folla de custos ten unha columna que non pode calcular, así que esta sección executa o fine-tune: en local, nun modelo aberto pequeno, co adaptador escrito á man no canto de tirado dunha biblioteca. O capítulo 11 construíu LoRA; aquí está, sobre os q_proj e v_proj das 24 capas de Qwen2.5-0.5B-Instruct con rango 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

Os douscentos exemplos de adestramento saen mecanicamente do corpus, así que se reproducen: a pregunta é unha cabeceira de sección convertida en pregunta, a resposta é o propio texto desa sección nun estilo de casa ríxido — unha liña que comeza con Short answer:, unha liña que comeza con Source: coa ruta do ficheiro. O formato é a forma que se ensina; a ruta é o feito. Logo dous números sobre vinte preguntas reservadas: sae a resposta no estilo da casa, e nomea o ficheiro que realmente responde a pregunta?

Dúas liñas base fan lexible a táboa, e ambas son a insistencia do capítulo 4, non unha reflexión posterior. Dez das vinte respostas correctas son o mesmo ficheiro, así que un modelo que ignora a pregunta e responde sempre CLAUDE.md puntúa 10/20. E o recuperador ten o seu propio teito: entre estas vinte preguntas, os seus catro extractos conteñen o ficheiro correcto 14 veces e sitúano primeiro 7, así que 14/20 é o máximo que podería puntuar calquera lector que o use.

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

A forma aprendeuse, por completo e rápido. De cero a dezanove de vinte, cun adaptador de 540,672 parámetros — o 0.109 % do modelo — en cinco minutos de adestramento nun procesador sen tarxeta gráfica á vista.

Os feitos non. Oito de vinte non se distingue dos dez que obtés ignorando a pregunta por completo, e o intervalo do capítulo 4 sobre vinte mostras dio en voz alta. Esas rutas de ficheiro estaban nos datos de adestramento tres veces; o que saíu foi o hábito de rematar cunha liña Source: de aspecto plausible. Preguntado pola cuestión do comezo deste capítulo, o modelo con fine-tuning respondeu Short answer: 10.x . . . e citou CLAUDE.md. A resposta correcta, que está en CLAUDE.md, é 18.17.0.

E despois rompeu a forma, que é a fila que xustifica o experimento. Dálle ao modelo con fine-tuning mil tokens de extractos recuperados — unha forma de prompt que nunca viu, xa que todos os prompts de adestramento tiñan vinte e oito tokens — e o estilo da casa cae de 19/20 a 1/20. Na pregunta do comezo deste capítulo responde 18.17.0 — correcto, e sen nada do formato para o que fora adestrado. Así que o fine-tuning non ensinou un formato; ensinou un formato condicionado polos prompts do conxunto de adestramento, e o primeiro prompt que parecía diferente levou o formato consigo. Aquilo sobre o que fas fine-tuning convértese na única distribución de entrada na que o teu modelo é bo, e ninguén mete iso na folla de cálculo.

Unha última nota sobre a métrica, apuntando directamente ao capítulo 29: "fonte correcta" puntúa forma e feito xuntos, por iso ambas filas de recuperación parecen terribles aínda que ambos modelos acertaron o feito desa pregunta. Un único número end-to-end estaba agochando tres cousas — un recuperador con recall 14/20, un lector de 0.5B e un formato de cita — e escoller que arranxar significa separalas antes de medir, non despois.

Agora a columna que os provedores enchen por ti. Un modelo con fine-tuning non é un activo que posúes; é un alugueiro sobre o modelo base doutra persoa, cunha data de fin impresa. O 7 de setembro de 2026, a sección de fine-tuning da páxina de prezos de OpenAI levaba este aviso completo:

OpenAI está pechando gradualmente a plataforma de fine-tuning. A plataforma xa non é accesible para usuarios novos, pero os usuarios existentes da plataforma de fine-tuning poderán crear traballos de adestramento durante os próximos meses. Todos os modelos con fine-tuning seguirán dispoñibles para inferencia ata que os seus modelos base sexan retirados.⁷

A cronoloxía está datada ao día: 7 de maio de 2026, pechada a organizacións que nunca fixeran fine-tuning; 2 de xullo de 2026, pechada ás que non executaran inferencia nun modelo con fine-tuning en sesenta días; 6 de xaneiro de 2027, sen traballos novos en absoluto.⁸ A mesma páxina programa o apagado dos propios modelos con fine-tuning — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — o 23 de outubro de 2026, cada un cun modelo base substituto recomendado, que é unha forma educada de dicir: adéstrao outra vez.

O outro provedor frontier nunca che vendeu o alugueiro. O índice da documentación de Anthropic lista 699 páxinas e nin unha soa trata de fine-tuning; as seccións de personalización de modelos da páxina de prezos de Bedrock cobren Amazon Nova, Amazon Titan, Cohere, Meta e modelos open-weight de OpenAI, e ningún Claude.⁹¹⁰ Se a túa arquitectura depende dun fine-tune, unha das tres familias frontier simplemente non está dispoñible para ti con ningún orzamento.

O self-hosting substitúe o alugueiro dun modelo polo alugueiro dunha máquina, e AWS fai esa aritmética na súa propia páxina: unha unidade de modelo de throughput aprovisionado para un modelo personalizado, compromiso dun mes, é "1 model unit × $21.18 × 24 hours × 31 days = $15,757.92" ao mes.¹⁰ Alugar o metal directamente é máis barato e non é gratis — $3.99 por hora de GPU baixo demanda para unha H100, $1.99 preemptible¹¹ — arredor de $2,900 ao mes por unha tarxeta que ten que estar levantada pregunte alguén ou non. Toda a ruta de recuperación con dez mil preguntas ao mes custa $174.52 por seis meses.

Aquí é onde LoRA gaña o seu lugar, como argumento de orzamento máis ca técnico. Medido no mesmo modelo, un adaptador de rango 16 sobre attention e as capas feed-forward son 8,798,208 parámetros — o 1.781 % do modelo, 17.6 MB en bfloat16 — fronte a 0.988 GB de pesos base, e o seu estado de optimizador e gradient é 140.77 MB onde o fine-tuning completo necesita 7.90 GB, un factor de 56. A consecuencia non é un adestramento máis barato, senón que un modelo base cargado pode servir moitos adaptadores, que é a única maneira de dividir o custo fixo dunha GPU por algo. O adestramento xestionado reflícteo: $0.48 por millón de tokens low-rank ata 16B fronte a $0.54 completo, cun mínimo de $4.00 por traballo.¹¹ Ese chan é o detalle. Con 24,389 tokens por tres épocas, cada readestramento neste corpus factura $4.00 no canto dos $0.04 que dá a aritmética — $104 de mínimos ao longo de vinte e seis execucións semanais, por noventa e un centavos de aritmética.

Dúas columnas máis que só aparecen na factura.

A residencia de datos custa arredor dun dez por cento, e dous provedores coinciden na cifra. OpenAI cobra "a 10 % uplift" nos endpoints con residencia de datos para modelos lanzados o 5 de marzo de 2026 ou despois;⁷ Vertex pon os seus endpoints non globais a $1.65 fronte a $1.50, o mesmo dez por cento.⁶ Comparado co cincuenta por cento que custa un endpoint tuned, o folclore invértese: a residencia é barata e o fine-tuning non — e o fine-tuning tampouco é a opción privada, xa que o corpus chega ao provedor igualmente, unha vez no adestramento en vez de unha vez por chamada.

O prezo máis explícito que se lle puxo nunca aos teus datos está na mesma páxina, que lista o mesmo modelo con fine-tuning dúas veces: co intercambio de datos activado, a inferencia custa exactamente a metade — $2.00 fronte a $4.00 de entrada, $8.00 fronte a $16.00 de saída.⁷ Deixar que o provedor garde o que enviaches vale un desconto do 50 %, o que che di canto vale para eles.

Destilación — adestrar un modelo pequeno teu coas respostas dun grande — adoita ofrecerse como unha saída de ambas cousas. Ponlle prezo e non o é, porque o profesor é o sistema que estabas tentando substituír: producir douscentos exemplos de adestramento preguntándolle á ruta de recuperación duascentas preguntas custa 200 × $0.002906 = $0.58, ademais dos $0.73 de adestralos. A destilación é algo que fas despois de que o pipeline de recuperación funcione, para facelo máis barato, e herda todos os feitos que o recuperador sacou mal.

O diñeiro é a metade visible. A outra chega como espera, coa mesma causa ca a factura: o modelo le todo o prompt antes de dicir unha palabra. O capítulo 13 mediu prefill fronte a decode nun modelo que podías tocar; aquí está a mesma medida, unha execución, unha máquina, contra a lonxitude do prompt:

Os números absolutos pertencen a un modelo de 0.5B en dezaseis fíos de CPU e non din nada sobre un modelo frontier hospedado. A forma transfírese exactamente: o prefill medra coa lonxitude do prompt, e o custo por token sobe pouco a pouco cando empeza a aparecer o termo cuadrático do capítulo 9 — 4.79 ms a mil tokens fronte a 6.04 ms a oito mil, unha penalización do 26 % só por ser máis longo.

A consecuencia para as tres rutas é directa. A ruta un fai prefill de corenta e tres mil tokens por pregunta, e un acerto de cache é o que o fai soportable — o capítulo 16 explicou por que: unha lectura de cache substitúe traballo de prefill, así que compra latencia e diñeiro nunha soa transacción. A ruta dous fai prefill de mil e engade primeiro unha viaxe de ida e volta ao índice. A ruta tres fai prefill de vinte e oito e non engade nada, o que a fai mediblemente a máis rápida das tres respondendo. Simplemente responde o incorrecto.

Tres fallos que parecen problemas de modelo e non o son — dez minutos aquí aforran un mes despois:

E o requisito sobre todo isto: esta decisión non se pode tomar sen un conxunto de avaliación, e o provedor que vende o fine-tune tamén o di. A guía de OpenAI abre 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 engade que se cincuenta bos exemplos non cambian nada, o problema é a tarefa ou o prompt, non o volume de datos.¹ Vinte preguntas, que é o que usou este capítulo, mostran un mecanismo e non poden escoller un provedor — o capítulo 4 mediu por que, e que facer cando vinte casos son todo o que tes — repetilos, emparellalos e medir a dispersión entre execucións — é o capítulo 29.

Catro columnas, e só a última decide:

A regra que sae disto, e é curta abondo para gardala: comeza co prompt; engade recuperación cando os feitos se movan; fai fine-tuning só cando mediches que o que aínda che falta é unha forma, non un feito — e pon prezo á resposta, non ao prompt, antes de facelo.

A versión incómoda, para quen chegou con todo decidido: no caso medido neste capítulo o fine-tuning é a ruta máis barata por riba de catro mil preguntas ao mes, e nos feitos segue sen poder superar responder CLAUDE.md a todo.

Cada prezo aquí foi por token, e cada ruta unha maneira distinta de organizar tokens. Iso está a piques de deixar de ser certo.

O capítulo 21 sae do texto. Unha imaxe que entra nun modelo non é unha string senón unha grella de parches cun reconto de tokens que non escolliches; un minuto falado factúrase por segundo nun provedor e por audio token noutro; a fala sintética véndese por carácter, a transcrición por minuto, o cómputo bruto por GPU-segundo. A pregunta que este capítulo respondeu cunha función de custo — que é máis barato? — nin sequera se pode formular ata que as unidades coinciden, e ningunha calculadora de internet as normaliza.

Tamén é onde volve aparecer o adestramento: un adaptador de imaxe cunha trigger word, e unha voz clonada dunha mostra. O que levanta a pregunta coa que abre o seguinte capítulo, e non é retórica: se facer fine-tuning dun modelo de linguaxe é case sempre a compra equivocada, por que facer fine-tuning dun modelo de imaxe é case sempre a correcta?

Cada prezo, limiar e multiplicador deste capítulo leuse da páxina propia do provedor o 7 de setembro de 2026 e cítase con esa data, porque todos se van mover. As cifras medidas — recontos de tokens, tamaños de chunk, tamaños de recuperación, perda de adestramento, puntuacións, latencias e recontos de historial de versións — producíronse nunha máquina o mesmo día e son reproducibles desde o corpus descrito arriba.

Os experimentos locais usaron Qwen/Qwen2.5-0.5B-Instruct con greedy decoding, así que se reproducen exactamente; o adaptador é a clase de doce liñas impresa arriba, con rango 8 sobre q_proj e v_proj. O corpus é a documentación Markdown rastrexada dun repositorio de software en activo, excluíndo dous rexistros append-only, e a súa taxa de cambio contouse a partir do historial de versións dese repositorio.