Fine-Tune, Retrieve ou Prompt? A decisão é econômica

“Devemos fazer fine-tuning?” é perguntado como se fosse uma questão sobre um model. É uma questão sobre orçamento, com um formato que nenhum benchmark responde: o que é pago uma vez, o que é pago por pergunta e o que é pago de novo toda vez 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 isso de modo mais claro do que a maioria dos posts de blog. A própria tabela da OpenAI sobre para que o fine-tuning supervisionado é melhor lista quatro usos: classificação, tradução com nuances, geração de conteúdo em um formato específico e correção de falhas ao seguir instruções.¹ Nenhum deles é “ensinar ao model algo que ele não sabe”. O resumo do benefício diz que “você pode usar prompts mais curtos, com menos exemplos e dados de contexto, o que economiza custos de token em escala e pode ter menor latência” — um argumento sobre a fatura, feito pela empresa que vende o recurso.

Então:

• Fine-tuning ensina forma e comportamento. Tom, formato, a estrutura de uma resposta, um limite que você consegue demonstrar mas não descrever. A versão publicada mais forte é a Hipótese de Alinhamento Superficial do LIMA: conhecimento vem do pretraining, alinhamento ensina principalmente em qual subdistribuição de formatos falar — e é por isso que mil exemplos curados bastaram ali.²
• Retrieval fornece fatos que mudam. É a única das três em que uma edição na sua documentação chega à resposta sem tocar no model.
• Prompting cobre a maioria dos casos reais, e é a linha de base honesta. In-context learning é 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 para o 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, inclusive em fatos que o model base já tinha visto no pretraining.⁴ Gekhman e colegas mediram o dano: exemplos que introduzem novo conhecimento são ajustados lentamente, e quando o model finalmente os ajusta sua taxa de alucinação em outras perguntas aumenta.⁵ Ensinar fatos por fine-tuning não apenas falha; degrada respostas nas quais você não estava treinando.

Essa metade está resolvida. A metade econômica, não, e ela é o restante do capítulo.

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

O corpus é real e está neste disco: os 23 documentos Markdown que um repositório de software em atividade mantém como documentação interna — o guia de build, as regras de marca, o brief de tradução, dez manuais de serviço, as notas de performance 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, então as três rotas estão genuinamente disponíveis. Com dez milhões, a decisão é tomada por você, e é retrieval.

Agora o trabalho que a palavra “semanalmente” faz. Rotatividade de documentação costuma ser afirmada; aqui ela é contada, a partir do histórico de versões daquele repositório:

Os documentos mudam mais ou menos a cada duas semanas. As strings visíveis ao usuário — que são aquilo sobre o que um suporte é realmente questionado — mudaram em todas as semanas em que existiram, a cerca de vinte commits por semana. Qualquer rota que escolhermos precisa sobreviver a isso, e “com que frequência aquilo em que você treinou muda?” acaba tendo um número no seu próprio repositório, não uma opinião.

Vinte perguntas realistas de suporte foram escritas contra esse corpus, uma por tópico, e todos os números abaixo são computados sobre essas vinte.

A coisa mais simples que funciona: colocar o corpus inteiro no system prompt, a pergunta no fim e deixar o model 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 ali foram contados, exceto o último: 150 output tokens é uma suposição, escolhida dentro do intervalo de turnos de assistant faturados no Capítulo 16. É o único número aqui que não foi executado, é aplicado de forma idêntica às três rotas, e a seção de break-even mostra exatamente quanto a conclusão se move quando você o muda.

Nas 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⁶ — isso dá $0,066317 por pergunta. Você está pagando para reler quarenta e três mil tokens para responder treze.

A correção do Capítulo 16 se aplica diretamente: o corpus é estável e está na frente, então é 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 aquele capítulo sinalizou e não precificou. Este fornecedor não cobra prêmio de escrita; ele cobra aluguel. Um cache explícito custa $0,000001 por token armazenado por hora,⁶ então manter 43.298 tokens aquecidos custa

quer alguém pergunte alguma coisa ou não. Isso dá $189,78 em seis meses, por uma sala vazia. Divida o aluguel pela economia por pergunta e a condição sai em uma linha: fazer cache deste corpus se paga acima de 0,74 pergunta por hora — 546 por mês quando a reconstrução semanal do cache também é contada. Abaixo disso, o recurso que você ativou para economizar dinheiro perde dinheiro.

Mesma rota, mesmo código, uma flag, cinco vezes a fatura. O Capítulo 16 encontrou uma versão disso causada por um timestamp no lugar errado; aqui nada está errado além do tráfego. Um cache é uma aposta em volume, e neste fornecedor você a faz por hora.

O retriever do Capítulo 19, sem mudanças: cortar em limites de seção com um cabeçalho contextual, indexar, colocar os quatro melhores trechos 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 na rota um, a $0,002906 por pergunta. O índice custa $0,0070 para construir a $0,15 por milhão de embedding tokens⁶ — menos do que três perguntas — e os mesmos $0,0070 para reconstruir do zero toda vez que a documentação muda. Reconstruir o índice inteiro toda semana por seis meses custa dezoito centavos.

Vale a pena parar em uma coisa. 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 toda chamada, porque os trechos são escolhidos por pergunta. E 140 tokens está abaixo de todos os mínimos de cache citados no Capítulo 16. Então a rota dois não pode ser cacheada de forma alguma, o que parece ruim e não é: não fazer cache de 1.037 tokens é mais barato do que fazer cache de 43.298.

Essa é uma regra geral que vale levar adiante: as duas grandes técnicas de economia de token são mutuamente exclusivas no mesmo conteúdo, e vence a que remove mais tokens. Retrieval remove 97,6% deles.

Treine com duzentos exemplos no estilo da casa e depois faça perguntas sem nenhuma documentação anexada.

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

O treinamento custa 24.389 × 3 × $10,00 por milhão = $0,7317. Esse é todo o custo de construção, menos do que uma xícara de café, exatamente por isso tantas equipes pagam antes de verificar se ajuda.

Agora a armadilha, e ela é a razão deste capítulo existir. Um model com fine-tuning não custa o mesmo que seu model base para executar. A página de preços diz isso em uma frase: “para inferência de model a partir do Gemini 3, o preço de predição do endpoint de model ajustado será 1,5 vez o do model base.”⁶ Não o treinamento. A inferência, em todo token, enquanto o model viver.

Então coloque isso em uma fórmula. Se $p_i$ e $p_o$ são os preços base de input e output, $m$ é o multiplicador do tuned model, $L_R$ é o tamanho do prompt da rota que você está substituindo, $L_F$ é o tamanho do prompt após o fine-tuning e $O$ é o tamanho da resposta. Fine-tuning só é mais barato por pergunta quando

O primeiro termo é óbvio: seu novo prompt curto, com acréscimo. O segundo não é, e é onde o dinheiro vai — o adicional sobre a resposta, que não tem nada a ver com o seu prompt e que o treinamento não consegue encurtar. Com os números medidos — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — o limite é

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

No tamanho de resposta medido, 492 tokens — dos quais 450 são o adicional da resposta, não o prompt. Substituir um prompt mais curto do que isso é mais caro por pergunta, para sempre, em qualquer volume; e o limite cresce linearmente com o quanto seu assistant fala, então um que escreve respostas longas nunca consegue usar fine-tuning para chegar a um token mais barato, por mais prompt que remova.

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

Quatro números descrevem qualquer uma dessas rotas: o que você paga uma vez, o que paga quando a documentação muda, o que paga por hora independentemente de uso e o que paga por pergunta. Isso estende o computeCost do Capítulo 16 sem modificá-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);
}

O tuned model não é uma lista 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 é o argumento inteiro da seção anterior escrito como código: o multiplicador cai sobre output também.

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

E os crossovers, 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 juntos, porque eles são o ponto do capítulo. Um corpus estacionário faz o fine-tuning se pagar em cento e cinquenta perguntas; um corpus que muda toda semana desloca o mesmo crossover por um fator de vinte e sete, e nada no model mudou — só a frequência com que você paga por ele de novo. Custo de construção é nota de rodapé; custo de manutenção é a decisão.

Se agora você concluir que um suporte movimentado deveria fazer fine-tuning, a aritmética concorda com você. Ainda está errado, e a próxima seção explica por quê.

A planilha de custos tem uma coluna que não consegue computar, então esta seção executa o fine-tune: localmente, em um model aberto pequeno, com o adaptador escrito à mão em vez de puxado de uma biblioteca. O Capítulo 11 construiu LoRA; aqui está ele, no q_proj e v_proj de todas as 24 camadas de Qwen2.5-0.5B-Instruct em 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 treinamento vêm mecanicamente do corpus, então são reprodutíveis: a pergunta é um título de seção transformado em pergunta, a resposta é o próprio texto daquela seção em um estilo rígido da casa — uma linha começando com Short answer:, uma linha começando com Source: com o caminho do arquivo. O formato é a forma sendo ensinada; o caminho é o fato. Depois, dois números em vinte perguntas hold-out: a resposta sai no estilo da casa, e ela nomeia o arquivo que realmente responde à pergunta?

Duas linhas de base tornam a tabela legível, e ambas são uma insistência do Capítulo 4, não um adendo. Dez das vinte respostas certas são o mesmo arquivo, então um model que ignora a pergunta e sempre responde CLAUDE.md faz 10/20. E o retriever tem seu próprio teto: nessas vinte perguntas, seus quatro trechos contêm o arquivo certo 14 vezes e o ranqueiam em primeiro 7 vezes, então 14/20 é o máximo que qualquer leitor poderia 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 a dezenove de vinte, com um adaptador de 540.672 parâmetros — 0,109% do model — em cinco minutos de treinamento em um processador sem nenhuma placa de vídeo à vista.

Os fatos, não. Oito de vinte não se distingue dos dez que você obtém ignorando a pergunta completamente, e o intervalo do Capítulo 4 em vinte amostras diz isso em voz alta. Esses caminhos de arquivo estavam nos dados de treinamento três vezes; o que saiu foi o hábito de terminar com uma linha Source: de aparência plausível. Ao receber a pergunta do topo deste capítulo, o model com fine-tuning respondeu Short answer: 10.x . . . e citou CLAUDE.md. A resposta certa, que está em CLAUDE.md, é 18.17.0.

E então a forma quebrou, que é a linha que justifica o experimento. Entregue ao model com fine-tuning mil tokens de trechos recuperados — um formato de prompt que ele nunca viu, já que todo prompt de treinamento tinha vinte e oito tokens — e o estilo da casa cai de 19/20 para 1/20. Na pergunta do topo deste capítulo, ele responde 18.17.0 — correto, e sem nada do formato para o qual foi treinado. Então o fine-tuning não ensinou um formato; ensinou um formato condicionado aos prompts do conjunto de treinamento, e o primeiro prompt que parecia diferente levou o formato junto. Tudo aquilo em que você faz fine-tuning se torna a única distribuição de input em que seu model é bom, e ninguém coloca isso na planilha.

Uma última nota sobre a métrica, apontando direto para o Capítulo 29: “fonte correta” pontua forma e fato juntos, e é por isso que as duas linhas de retrieval parecem terríveis, mesmo que os dois models tenham acertado o fato daquela pergunta. Um único número de ponta a ponta escondia três coisas — um retriever com 14/20 de recall, um leitor de 0,5B e um formato de citação — e escolher o que corrigir significa separá-las antes de medir, não depois.

Agora a coluna que os fornecedores preenchem por você. Um model com fine-tuning não é um ativo que você possui; é um aluguel sobre o model base de outra pessoa, com uma data de fim impressa. Em 7 de setembro de 2026, a seção de fine-tuning da página de preços da OpenAI trazia este aviso completo:

A OpenAI está encerrando gradualmente a plataforma de fine-tuning. A plataforma não está mais acessível a novos usuários, mas usuários existentes da plataforma de fine-tuning poderão criar jobs de treinamento nos próximos meses. Todos os models com fine-tuning continuarão disponíveis para inferência até que seus models base sejam descontinuados.⁷

A linha do tempo tem data até o dia: 7 de maio de 2026, fechada para organizações que nunca tinham feito fine-tuning; 2 de julho de 2026, fechada para aquelas que não tinham executado inferência em um model com fine-tuning em sessenta dias; 6 de janeiro de 2027, sem novos jobs de qualquer tipo.⁸ A mesma página agenda o desligamento dos próprios models com fine-tuning — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — para 23 de outubro de 2026, cada um com um model base substituto recomendado, que é uma forma educada de dizer: treine de novo.

O outro fornecedor de frontier model nunca vendeu o aluguel. O índice da documentação da Anthropic lista 699 páginas e nenhuma é sobre fine-tuning; as seções de customização de model da página de preços do Bedrock cobrem Amazon Nova, Amazon Titan, Cohere, Meta e models OpenAI de pesos abertos, e nenhum Claude.⁹¹⁰ Se sua arquitetura depende de um fine-tune, uma das três famílias de frontier models simplesmente não está disponível para você a nenhum orçamento.

Self-hosting substitui o aluguel de um model pelo aluguel de uma máquina, e a AWS faz essa aritmética em sua própria página: uma unidade de model de throughput provisionado para um model customizado, compromisso de um mês, é “1 unidade de model × $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 sob demanda para uma H100, $1,99 preemptible¹¹ — cerca de $2.900 por mês por uma placa que precisa ficar ligada quer alguém pergunte alguma coisa ou não. A rota inteira de retrieval com dez mil perguntas por mês custa $174,52 por seis meses.

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

Mais duas colunas que só aparecem na fatura.

Residência de dados custa cerca de dez por cento, e dois fornecedores concordam no número. A OpenAI cobra “um acréscimo de 10%” em endpoints de residência de dados para models lançados em ou depois de 5 de março de 2026;⁷ a Vertex precifica seus endpoints não globais a $1,65 contra $1,50, os mesmos dez por cento.⁶ Compare isso com os cinquenta por cento que um endpoint ajustado custa e o folclore se inverte: residência é barata e fine-tuning não é — e fine-tuning também não é a opção privada, já que o corpus chega ao fornecedor de qualquer forma, uma vez no treinamento em vez de uma vez por chamada.

O preço mais explícito já colocado nos seus dados está na mesma página, que lista um model com fine-tuning duas vezes: com compartilhamento de dados habilitado, a inferência custa exatamente metade — $2,00 contra $4,00 de input, $8,00 contra $16,00 de output.⁷ Deixar o fornecedor ficar com o que você enviou vale um desconto de 50%, o que diz quanto isso vale para ele.

Distillation — treinar um model pequeno seu nas respostas de um grande — costuma ser oferecida como saída para ambos. Precifique e ela não é, porque o teacher é o sistema que você estava tentando substituir: produzir duzentos exemplos de treinamento perguntando duzentas vezes à rota de retrieval custa 200 × $0,002906 = $0,58, além dos $0,73 para treinar neles. Distillation é algo que você faz depois que o pipeline de retrieval funciona, para torná-lo mais barato, e herda todo fato que o retriever errou.

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

Os números absolutos pertencem a um model de 0,5B em dezesseis threads de CPU e não dizem nada sobre um frontier model hospedado. O formato se transfere exatamente: prefill cresce com o tamanho do prompt, e o custo por token aumenta aos poucos quando 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 penalidade de 26% por apenas 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 por quê: uma leitura de cache substitui trabalho de prefill, então compra latência e dinheiro em uma só transação. A rota dois faz prefill de mil e adiciona antes uma ida e volta ao índice. A rota três faz prefill de vinte e oito e não adiciona nada, o que a torna mensuravelmente a mais rápida das três para responder. Ela só está respondendo a coisa errada.

Três falhas que parecem problemas de model e não são — dez minutos aqui economizam um mês depois:

E a exigência acima de tudo isso: esta decisão não pode ser tomada sem um conjunto de avaliação, e o fornecedor que vende o fine-tune diz isso. O guia da OpenAI abre com “Só invista em fine-tuning depois de configurar evals. Você precisa de uma forma confiável de determinar se seu model com fine-tuning está performando melhor do que um model base”, e acrescenta que, se cinquenta bons exemplos não mudam nada, o problema é a tarefa ou o prompt, não o volume de dados.¹ Vinte perguntas, que é o que este capítulo usou, mostram um mecanismo e não conseguem escolher um fornecedor — o Capítulo 4 mediu por quê, e o que fazer quando vinte casos são tudo que você tem — repeti-los, pareá-los e medir a dispersão entre execuções — é o Capítulo 29.

Quatro colunas, e só a última decide:

A regra que sai disso, curta o suficiente para guardar: comece com o prompt; adicione retrieval quando os fatos se movem; faça fine-tuning só quando você mediu que o que ainda falta é uma forma, não um fato — e precifique a resposta, não o prompt, antes de fazer isso.

A versão desconfortável, para quem chegou já decidido: no caso medido neste capítulo, fine-tuning é a rota mais barata acima de quatro mil perguntas por mês, e nos fatos ainda não consegue vencer responder CLAUDE.md para tudo.

Todo preço aqui foi por token, e toda rota uma forma diferente de organizar tokens. Isso está prestes a deixar de ser verdade.

O Capítulo 21 sai do texto. Uma imagem entrando em um model não é uma string, mas uma grade de patches com uma contagem de token que você não escolheu; um minuto falado é faturado por segundo em um fornecedor e por audio token em outro; fala sintética é vendida por caractere, transcrição por minuto, computação bruta por GPU-segundo. A pergunta que este capítulo respondeu com uma função de custo — qual é mais barato? — nem sequer pode ser feita até que as unidades coincidam, e nenhuma calculadora na internet as normaliza.

É também onde o treinamento volta a aparecer: 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 ela não é retórica: se fazer fine-tuning de um language model quase sempre é a compra errada, por que fazer fine-tuning de um image model quase sempre é a certa?

Todo preço, limite e multiplicador neste capítulo foi lido na página do próprio fornecedor em 7 de setembro de 2026 e é citado com essa data, porque todos vão mudar. Os números medidos — contagens de token, tamanhos de chunk, tamanhos de retrieval, training loss, pontuações, latências e contagens de histórico de versão — foram produzidos em uma máquina no mesmo dia e são reprodutíveis a partir do corpus descrito acima.

Os experimentos locais usaram Qwen/Qwen2.5-0.5B-Instruct com greedy decoding, então se reproduzem exatamente; o adaptador é a classe de doze linhas impressa acima, em rank 8 sobre q_proj e v_proj. O corpus é a documentação Markdown rastreada de um repositório de software em atividade, excluindo dois logs append-only, e sua taxa de mudança foi contada a partir do histórico de versões desse repositório.