Fine-tuning, retrieval ou prompt? A decisão é económica

«Devemos fazer fine-tuning?» é perguntado como se fosse uma questão sobre um modelo. É uma questão sobre um orçamento, com uma forma a que nenhum benchmark responde: o que é pago uma vez, o que é pago por pergunta, e o que volta a ser pago sempre que o mundo muda.

As três rotas também não são três formas de fazer a mesma coisa, e os fornecedores dizem-no de forma mais clara do que a maioria dos blog posts. A própria tabela da OpenAI sobre aquilo para que o supervised fine-tuning é melhor lista quatro usos: classificação, tradução matizada, geração de conteúdo num formato específico e correção de falhas no seguimento de instruções.¹ Nenhum deles é «ensinar ao modelo algo que ele não sabe». O resumo do benefício é que «pode usar prompts mais curtos, com menos exemplos e dados de contexto, o que poupa custos de tokens em escala e pode reduzir a latência» — um argumento sobre a fatura, vindo da empresa que vende a funcionalidade.

Portanto:

• Fine-tuning ensina forma e comportamento. Tom, formato, a estrutura de uma resposta, um limite que consegue demonstrar mas não descrever. A versão publicada mais forte é a Hipótese de Alinhamento Superficial do LIMA: o conhecimento vem do pretraining, o alinhamento ensina sobretudo em que subdistribuição de formatos falar — razão pela qual mil exemplos curados foram suficientes nesse caso.²
• Retrieval fornece factos que mudam. É a única das três em que uma edição à documentação chega à resposta sem tocar no modelo.
• Prompting cobre a maioria dos casos reais, e é a baseline honesta. In-context learning tem sido o padrão desde Language Models are Few-Shot Learners: a tarefa é demonstrada dentro do prompt e nenhum peso se move.³

Dois artigos medidos fecham a porta ao erro no meio. Ovadia e colegas compararam injetar conhecimento por fine-tuning não supervisionado com injetá-lo por retrieval, e retrieval venceu de forma consistente, incluindo em factos que o modelo base já tinha visto no pretraining.⁴ Gekhman e colegas mediram os danos: exemplos que introduzem novo conhecimento são ajustados lentamente, e quando o modelo finalmente os ajusta, a taxa de alucinação em outras perguntas aumenta.⁵ Ensinar factos por fine-tuning não só falha; degrada respostas nas quais nem estava a treinar.

Essa metade está resolvida. A metade económica não, e ocupa o resto do capítulo.

Um caso, executado de três formas: suporte técnico sobre a sua própria documentação, que muda todas as semanas.

O corpus é real e está neste disco: os 23 documentos Markdown que um repositório de software em uso mantém como documentação interna — o guia de build, as regras de marca, o briefing de tradução, dez manuais de serviço, as notas de desempenho e segurança. Medido com o200k_base, a codificação do Capítulo 7:

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

Quarenta e três mil tokens é um tamanho confortável para esta decisão: cabe em qualquer context window moderna, por isso as três rotas estão genuinamente disponíveis. Aos dez milhões, a decisão está tomada por si, e é retrieval.

Agora, o trabalho que a palavra «semanalmente» está a fazer. A rotatividade da documentação costuma ser afirmada; aqui é contada, a partir do histórico de versões desse repositório:

Os documentos mexem-se mais ou menos de duas em duas semanas. As strings visíveis para o utilizador — que são aquilo sobre que uma equipa de suporte é realmente interrogada — mexeram-se em todas as semanas em que existiram, a cerca de vinte commits por semana. Qualquer rota que escolhamos tem de sobreviver a isso, e «com que frequência muda a coisa em que treinou?» afinal tem um número no seu próprio repositório, não uma opinião.

Foram escritas vinte perguntas realistas de suporte contra este corpus, uma por tema, e todos os valores abaixo são calculados sobre essas vinte.

A coisa mais simples que funciona: pôr o corpus inteiro no system prompt, a pergunta no fim, e deixar o modelo encontrá-la.

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 aí foram contados, exceto o último: 150 output tokens é uma suposição, escolhida dentro do intervalo de turnos de assistente faturados no Capítulo 16. É o único valor aqui que não foi executado, é aplicado de forma idêntica às três rotas, e a secção de break-even mostra exatamente quanto a conclusão se move quando o altera.

Às tarifas lidas na página do fornecedor em 7 de setembro de 2026 — $1,50 por milhão de input tokens, $9,00 por milhão de output⁶ — isto dá $0,066317 por pergunta. Está a pagar para reler quarenta e três mil tokens a fim de responder a treze.

A correção do Capítulo 16 aplica-se diretamente: o corpus é estável e está à frente, por isso é um prefixo de cache perfeito, e relê-lo custa um décimo — $0,007864 por pergunta, um corte de 88 %. O aviso do Capítulo 16 também se aplica, na forma que esse capítulo assinalou e não orçamentou. Este fornecedor não cobra prémio de escrita; cobra renda. Uma cache explícita custa $0,000001 por token armazenado por hora,⁶ por isso manter 43.298 tokens quentes custa

quer alguém faça perguntas, quer não. São $189,78 ao longo de seis meses, por uma sala vazia. Divida a renda pela poupança por pergunta e a condição sai numa linha: guardar este corpus em cache paga-se acima de 0,74 perguntas por hora — 546 por mês depois de contar também a reconstrução semanal da cache. Abaixo disso, a funcionalidade que ativou para poupar dinheiro fá-lo perder dinheiro.

Mesma rota, mesmo código, uma flag, cinco vezes a fatura. O Capítulo 16 encontrou uma versão disto causada por um timestamp no sítio errado; aqui nada está errado exceto o tráfego. Uma cache é uma aposta no volume, e neste fornecedor essa aposta é feita à hora.

O retriever do Capítulo 19, sem alterações: cortar por limites de secção com um cabeçalho contextual, indexar, pôr os quatro melhores excertos no prompt. Medido sobre as vinte perguntas:

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

Quarenta e duas vezes menos prompt tokens do que a rota um, a $0,002906 por pergunta. O índice custa $0,0070 a construir, a $0,15 por milhão de embedding tokens⁶ — menos do que três perguntas — e os mesmos $0,0070 a reconstruir de raiz sempre que a documentação muda. Reconstruir o índice inteiro todas as semanas durante seis meses custa dezoito cêntimos.

Vale a pena parar num ponto. Retrieval destrói prompt caching. O prefixo estável é agora a instrução de sistema de 140 tokens; a partir do token 141, o prompt difere em cada chamada, porque os excertos são escolhidos por pergunta. E 140 tokens está abaixo de todos os mínimos de cache citados no Capítulo 16. Portanto, a rota dois não pode ser posta em cache de todo, o que soa mal e não é: não guardar 1.037 tokens em cache é mais barato do que guardar 43.298.

É uma regra geral que vale a pena levar consigo: as duas grandes técnicas de poupança de tokens são mutuamente exclusivas sobre o mesmo conteúdo, e ganha a que remove mais tokens. Retrieval remove 97,6 % deles.

Treinar em duzentos exemplos no estilo da casa, depois fazer perguntas sem anexar documentação nenhuma.

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

O treino custa 24.389 × 3 × $10,00 por milhão = $0,7317. Esse é todo o custo de construção, menos do que um café, que é exatamente a razão pela qual tantas equipas o pagam antes de verificar se ajuda.

Agora a armadilha, e é por isso que este capítulo existe. Um modelo com fine-tuning não custa o mesmo a executar que o seu modelo base. A página de preços diz isso numa frase: «for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.»⁶ Não é o treino. É a inferência, em cada token, enquanto o modelo existir.

Portanto, ponha-o numa fórmula. Sejam $p_i$ e $p_o$ os preços base de input e output, $m$ o multiplicador do modelo tuned, $L_R$ o comprimento do prompt da rota que está a substituir, $L_F$ o comprimento do prompt depois do fine-tuning, e $O$ o comprimento da resposta. Fine-tuning só é mais barato por pergunta quando

O primeiro termo é óbvio: o novo prompt curto, com majoração. O segundo não é, e é onde o dinheiro vai parar — a sobretaxa sobre a resposta, que não tem nada que ver com o seu prompt e que o treino não consegue encurtar. Com os 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

Com o comprimento de resposta medido, 492 tokens — dos quais 450 são a sobretaxa da resposta, não o prompt. Substituir um prompt mais curto do que isso fica mais caro por pergunta, para sempre, a qualquer volume; e o limiar cresce linearmente com o quanto o assistente diz, por isso um assistente que escreve respostas longas nunca conseguirá, através de fine-tuning, chegar a um token mais barato, por mais prompt que elimine.

O mesmo facto visto do outro lado é a frase a reter. Dos $0,002088 por pergunta da rota com fine-tuning, 97,0 % é a resposta. Fine-tuning otimiza os restantes três por cento.

Quatro números descrevem qualquer uma destas rotas: o que paga uma vez, o que paga quando a documentação muda, o que paga à hora independentemente de tudo, e o que paga por pergunta. Isto estende o computeCost do Capítulo 16 sem o modificar.

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 não é uma tabela de preços diferente, é 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 })),   
});

Essa linha destacada é todo o argumento da secção anterior escrito como código: o multiplicador também cai sobre output.

Seis meses, com a documentação atualizada semanalmente:

E os pontos de crossover, que são os quatro números de que um orçamento realmente precisa:

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

Leia os dois primeiros em conjunto, porque são o ponto do capítulo. Um corpus estacionário faz o fine-tuning pagar-se em cento e cinquenta perguntas; um corpus que muda semanalmente desloca o mesmo crossover por um fator de vinte e sete, e nada no modelo mudou — só a frequência com que paga por ele outra vez. O custo de construção é uma nota de rodapé; o custo de manutenção é a decisão.

Se agora concluir que uma equipa de suporte movimentada deve fazer fine-tuning, a aritmética concorda consigo. Continua a estar errado, e a secção seguinte explica porquê.

A folha de custos tem uma coluna que não consegue calcular, por isso esta secção executa o fine-tune: localmente, num pequeno modelo aberto, com o adaptador escrito à mão em vez de importado de uma biblioteca. O Capítulo 11 construiu LoRA; aqui está, nos q_proj e v_proj de todas as 24 camadas de Qwen2.5-0.5B-Instruct com 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

Os duzentos exemplos de treino vêm mecanicamente do corpus, por isso reproduzem-se: a pergunta é um título de secção transformado em pergunta, a resposta é o próprio texto dessa secção num estilo de casa rígido — uma linha a começar por Short answer:, uma linha a começar por Source: com o caminho do ficheiro. O formato é a forma que está a ser ensinada; o caminho é o facto. Depois, dois números sobre vinte perguntas held-out: a resposta sai no estilo da casa, e nomeia o ficheiro que responde realmente à pergunta?

Duas baselines tornam a tabela legível, e ambas vêm da insistência do Capítulo 4, não de uma reflexão tardia. Dez das vinte respostas certas estão no mesmo ficheiro, por isso um modelo que ignora a pergunta e responde sempre CLAUDE.md pontua 10/20. E o retriever tem o seu próprio teto: nestas vinte perguntas, os seus quatro excertos contêm o ficheiro certo 14 vezes e classificam-no em primeiro 7, por isso 14/20 é o máximo que qualquer reader conseguiria pontuar usando-o.

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 foi aprendida, completa e rapidamente. De zero para dezanove em vinte, com um adaptador de 540.672 parâmetros — 0,109 % do modelo — em cinco minutos de treino num processador sem placa gráfica à vista.

Os factos não. Oito em vinte não se distingue dos dez que obtém ao ignorar totalmente a pergunta, e o intervalo do Capítulo 4 sobre vinte amostras di-lo em voz alta. Esses caminhos de ficheiro estavam nos dados de treino três vezes; o que saiu foi o hábito de terminar com uma linha Source: de aspeto plausível. Quando lhe foi feita a pergunta do topo deste capítulo, o modelo com fine-tuning respondeu Short answer: 10.x . . . e citou CLAUDE.md. A resposta certa, que está em CLAUDE.md, é 18.17.0.

E depois a forma quebrou, que é a linha que justifica a experiência. Entregue ao modelo com fine-tuning mil tokens de excertos obtidos por retrieval — uma forma de prompt que nunca viu, visto que todos os training prompts tinham vinte e oito tokens — e o estilo da casa colapsa de 19/20 para 1/20. Na pergunta do topo deste capítulo, responde 18.17.0 — correto, e sem nenhum do formato para o qual foi treinado. Portanto, fine-tuning não ensinou um formato; ensinou um formato condicionado aos prompts no conjunto de treino, e o primeiro prompt que pareceu diferente levou o formato consigo. Aquilo em que fizer fine-tuning torna-se a única distribuição de input em que o seu modelo é bom, e ninguém põe isso na folha de cálculo.

Uma última nota sobre a métrica, apontando diretamente ao Capítulo 29: «fonte correta» pontua forma e facto em conjunto, razão pela qual ambas as linhas de retrieval parecem péssimas, embora ambos os modelos tenham acertado no facto dessa pergunta. Um único número end-to-end estava a esconder três coisas — um retriever com 14/20 de recall, um reader de 0,5B e um formato de citação — e escolher o que corrigir implica separá-las antes de medir, não depois.

Agora a coluna que os fornecedores preenchem por si. Um modelo com fine-tuning não é um ativo que possui; é um aluguer sobre o modelo base de outra pessoa, com uma data de fim impressa. Em 7 de setembro de 2026, a secção de fine-tuning da página de preços da OpenAI trazia este aviso na íntegra:

A OpenAI está a descontinuar a plataforma de fine-tuning. A plataforma já não está acessível a novos utilizadores, mas os utilizadores existentes da plataforma de fine-tuning poderão criar jobs de treino nos próximos meses. Todos os modelos com fine-tuning continuarão disponíveis para inferência até os respetivos modelos base serem descontinuados.⁷

A cronologia está datada ao dia: 7 de maio de 2026, fechada a organizações que nunca tinham feito fine-tuning; 2 de julho de 2026, fechada às que não tinham executado inferência num modelo com fine-tuning em sessenta dias; 6 de janeiro de 2027, sem novos jobs de todo.⁸ A mesma página agenda o encerramento dos próprios modelos com fine-tuning — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — em 23 de outubro de 2026, cada um com um modelo base de substituição recomendado, que é uma forma educada de dizer: treine-o outra vez.

O outro fornecedor de fronteira nunca lhe vendeu esse aluguer. O índice da documentação da Anthropic lista 699 páginas e nem uma é sobre fine-tuning; as secções de personalização de modelos da página de preços do Bedrock cobrem Amazon Nova, Amazon Titan, Cohere, Meta e modelos OpenAI open-weight, e nenhum Claude.⁹¹⁰ Se a sua arquitetura depende de um fine-tune, uma das três famílias de fronteira está simplesmente indisponível para si, a qualquer orçamento.

Self-hosting substitui o aluguer de um modelo pelo aluguer de uma máquina, e a AWS faz essa aritmética na sua própria página: uma model unit de provisioned throughput para um modelo personalizado, compromisso de um mês, é «1 model unit × $21,18 × 24 horas × 31 dias = $15.757,92» por mês.¹⁰ Alugar o metal diretamente é mais barato e não é grátis — $3,99 por GPU-hora on demand para uma H100, $1,99 preemptible¹¹ — cerca de $2.900 por mês por uma placa que tem de estar ligada quer alguém faça perguntas, quer não. Toda a rota de retrieval a dez mil perguntas por mês custa $174,52 por seis meses.

É aqui que LoRA conquista o seu lugar, como argumento orçamental e não técnico. Medido no mesmo modelo, um adaptador de rank 16 sobre attention e as camadas feed-forward tem 8.798.208 parâmetros — 1,781 % do modelo, 17,6 MB em bfloat16 — contra 0,988 GB de pesos base, e o seu estado de otimizador e gradient é 140,77 MB, enquanto o full fine-tuning precisa de 7,90 GB, um fator de 56. A consequência não é treino mais barato, mas o facto de um único modelo base carregado poder servir muitos adaptadores, que é a única forma de dividir o custo fixo de uma GPU por alguma coisa. O treino gerido reflete isso: $0,48 por milhão de tokens low-rank até 16B contra $0,54 full, com um mínimo de $4,00 por job.¹¹ Esse piso é o detalhe. Com 24.389 tokens por três epochs, cada novo treino neste corpus fatura $4,00 em vez dos $0,04 que a aritmética daria — $104 de mínimos em vinte e seis execuções semanais, por noventa e um cêntimos de aritmética.

Mais duas colunas que só aparecem na fatura.

A residência dos dados custa cerca de dez por cento, e dois fornecedores concordam no valor. A OpenAI cobra «a 10 % uplift» em endpoints de residência de dados para modelos lançados em ou após 5 de março de 2026;⁷ a Vertex precifica os seus endpoints não globais a $1,65 contra $1,50, os mesmos dez por cento.⁶ Compare isto com os cinquenta por cento que um endpoint tuned custa e o folclore inverte-se: residência é barata e fine-tuning não é — e fine-tuning não é a opção privada de qualquer forma, pois o corpus chega ao fornecedor na mesma, uma vez no treino em vez de uma vez por chamada.

O preço mais explícito alguma vez atribuído aos seus dados está na mesma página, que lista duas vezes um modelo com fine-tuning: com partilha de dados ativada, a inferência custa exatamente metade — $2,00 contra $4,00 input, $8,00 contra $16,00 output.⁷ Deixar o fornecedor guardar o que enviou vale um desconto de 50 %, o que lhe diz quanto isso vale para ele.

Distillation — treinar um modelo pequeno seu com as respostas de um grande — é normalmente apresentado como uma saída para ambos. Ponha-lhe preço e não é, porque o professor é o sistema que estava a tentar substituir: produzir duzentos exemplos de treino perguntando duzentas vezes à rota de retrieval custa 200 × $0,002906 = $0,58, além dos $0,73 para treinar com eles. Distillation é algo que faz depois de a pipeline de retrieval funcionar, para a tornar mais barata, e herda todos os factos em que o retriever se enganou.

O dinheiro é a metade visível. A outra chega como espera, com a mesma causa da fatura: o modelo lê o prompt inteiro antes de dizer uma palavra. O Capítulo 13 mediu prefill contra decode num modelo em que se podia tocar; aqui está a mesma medição, uma execução, uma máquina, contra o comprimento do prompt:

Os números absolutos pertencem a um modelo de 0,5B em dezasseis threads de CPU e nada dizem sobre um modelo de fronteira hospedado. A forma transfere-se exatamente: prefill cresce com o comprimento do prompt, e o custo por token sobe lentamente à medida que o termo quadrático do Capítulo 9 começa a aparecer — 4,79 ms a mil tokens contra 6,04 ms a oito mil, uma penalização de 26 % apenas por ser mais longo.

A consequência para as três rotas é direta. A rota um faz prefill de quarenta e três mil tokens por pergunta, e um cache hit é o que torna isso suportável — o Capítulo 16 explicou porquê: uma leitura de cache substitui trabalho de prefill, por isso compra latência e dinheiro numa só transação. A rota dois faz prefill de mil e acrescenta primeiro uma ida e volta ao índice. A rota três faz prefill de vinte e oito e não acrescenta nada, o que a torna mensuravelmente a mais rápida das três a responder. Só está a responder à coisa errada.

Três falhas que parecem problemas de modelo e não são — dez minutos aqui poupam um mês mais tarde:

E o requisito sobre tudo isto: esta decisão não pode ser tomada sem um conjunto de avaliação, e o fornecedor que vende o fine-tune di-lo. O guia da OpenAI abre com «Só invista em fine-tuning depois de configurar evals. Precisa de uma forma fiável de determinar se o seu modelo com fine-tuning tem melhor desempenho do que um modelo base», e acrescenta que, se cinquenta bons exemplos não mudarem nada, o problema é a tarefa ou o prompt, não o volume de dados.¹ Vinte perguntas, que foi o que este capítulo usou, mostram um mecanismo e não conseguem escolher um fornecedor — o Capítulo 4 mediu porquê, e o que fazer quando vinte casos são tudo o que tem — repeti-los, emparelhá-los e medir a dispersão entre execuções — é o Capítulo 29.

Quatro colunas, e só a última decide:

A regra que sai daqui, e é curta o suficiente para guardar: comece pelo prompt; acrescente retrieval quando os factos se mexem; faça fine-tuning apenas quando tiver medido que aquilo que ainda lhe falta é uma forma, não um facto — e dê preço à resposta, não ao prompt, antes de o fazer.

A versão desconfortável, para quem chegou com a decisão já tomada: no caso medido neste capítulo, fine-tuning é a rota mais barata acima de quatro mil perguntas por mês, e nos factos continua a não conseguir bater responder CLAUDE.md a tudo.

Todos os preços aqui foram por token, e cada rota foi uma forma diferente de organizar tokens. Isso está prestes a deixar de ser verdade.

O Capítulo 21 sai do texto. Uma imagem que entra num modelo não é uma string, mas uma grelha de patches com uma contagem de tokens que não escolheu; um minuto falado é faturado ao segundo num fornecedor e por audio token noutro; fala sintética é vendida por caráter, transcrição por minuto, compute bruto por GPU-segundo. A pergunta a que este capítulo respondeu com uma função de custo — qual é mais barato? — nem sequer pode ser feita até as unidades coincidirem, e nenhuma calculadora na internet as normaliza.

É também aí que o treino volta a surgir: um adaptador de imagem com uma trigger word, e uma voz clonada a partir de uma amostra. O que levanta a pergunta com que o próximo capítulo abre, e não é retórica: se fazer fine-tuning de um modelo de linguagem é quase sempre a compra errada, porque é que fazer fine-tuning de um modelo de imagem é quase sempre a compra certa?

Todos os preços, limiares e multiplicadores neste capítulo foram lidos na própria página do fornecedor em 7 de setembro de 2026 e são citados com essa data, porque todos se vão mexer. Os valores medidos — contagens de tokens, tamanhos de chunks, tamanhos de retrieval, training loss, pontuações, latências e contagens do histórico de versões — foram produzidos numa máquina no mesmo dia e são reproduzíveis a partir do corpus descrito acima.

As experiências locais usaram Qwen/Qwen2.5-0.5B-Instruct com greedy decoding, por isso reproduzem exatamente; o adaptador é a classe de doze linhas impressa acima, com rank 8 sobre q_proj e v_proj. O corpus é a documentação Markdown seguida por um repositório de software em uso, excluindo dois logs append-only, e a sua taxa de alteração foi contada a partir do histórico de versões desse repositório.