Construir, comprar ou ajustar são três decisões, e a maioria dos debates as mistura
Em março de 2023, a Bloomberg publicou um artigo descrevendo o BloombergGPT, um modelo de linguagem com 50 bilhões de parâmetros. Seu corpus de treino combinava 363 bilhões de tokens extraídos dos dados financeiros da própria Bloomberg, coletados ao longo de décadas, com 345 bilhões de tokens de texto de uso geral. Os autores relataram que ele superava modelos existentes de porte semelhante em tarefas financeiras sem perder desempenho em benchmarks gerais. A Bloomberg é uma empresa para a qual a decisão de construir fazia sentido à primeira vista: tem um acervo que quase ninguém mais tem, seus clientes pagam para que a linguagem financeira seja entendida corretamente e tem os engenheiros para tocar uma campanha de treino.
No outro extremo do espectro, uma equipe chama a API de um modelo hospedado com um prompt e entrega em uma semana. Entre os dois ficam a recuperação sobre os documentos da empresa, o ajuste fino de um modelo com seus exemplos e a hospedagem de modelos de pesos abertos em servidores próprios. Um debate formulado como "construir ou comprar" costuma misturar tudo isso numa escolha só e termina com as pessoas falando sem se ouvir, já que um lado está pensando em treinar do zero e o outro em chamar uma API.
A pergunta se desfaz em três decisões. Uma é de onde vem o modelo: a API de um fornecedor, pesos abertos que você hospeda ou um modelo que você treina. Outra é como o modelo é adaptado à sua tarefa: um prompt, recuperação ou ajuste fino. Uma terceira é quem é dono do sistema em volta do modelo, isto é, a avaliação, os pipelines de dados, o monitoramento e a governança. Cada uma pode ser respondida separadamente. Uma empresa pode comprar seu modelo, adaptá-lo com recuperação e construir tudo em volta. Outra pode hospedar pesos abertos, ajustá-los e comprar as ferramentas de avaliação. Vou tratar as três em sequência, porque cada uma tem sua própria economia.
De onde vem o modelo é, sobretudo, uma questão de utilização
O custo de servir um modelo por conta própria é o preço do hardware dividido pelo número de tokens que ele produz. O segundo número é o que varia, porque uma GPU custa o mesmo por hora esteja atendendo requisições ou parada. Tome um nó ilustrativo de oito GPUs alugadas a US$ 3 por GPU-hora, portanto US$ 24 por hora, servindo um modelo de 70 bilhões de parâmetros com uma vazão agregada de 2.500 tokens por segundo, ou seja, 9 milhões de tokens por hora. São números de exemplo, e as suas próprias medições devem substituí-los. Com utilização plena, o custo é 24 / 9 = US$ 2,67 por milhão de tokens.
A utilização é a história inteira. Com carga plena, o custo é US$ 2,67 por milhão de tokens. Com meia carga, US$ 5,33; com um quarto da carga, US$ 10,67; com um décimo da capacidade, US$ 26,67. A conta do hardware é a mesma em todos os casos, e a única coisa que muda é quanto trabalho se faz com ela.
Ponha isso ao lado das tabelas de preços de um fornecedor hospedado. Em outubro de 2026, a Anthropic lista o Claude Haiku 5.5 a US$ 0,10 por milhão de tokens de entrada e US$ 0,50 por milhão de tokens de saída para prompts de até 100.000 tokens, o Sonnet 5.5 a US$ 2 e US$ 10, e o Opus 5.5 a US$ 4 e US$ 20. Um modelo de 70B auto-hospedado só fica abaixo do preço de saída de US$ 10 da API de faixa média enquanto a utilização se mantém acima de cerca de um quarto, e não fica abaixo da faixa mais barata em nenhuma utilização. Com 10% de utilização, o que não é incomum para uma ferramenta interna usada em horário comercial, o custo auto-hospedado fica acima até da faixa mais cara. A comparação deixa de fora as pessoas: um engenheiro que mantém uma pilha de serviço saudável custa mais do que as GPUs em pequena escala.
Some as pessoas e o quadro muda de forma. Suponha que a opção auto-hospedada exija dois engenheiros para operar, a US$ 15.000 por mês cada um, custo total assumido, e compare com a API de faixa média a uma média ponderada de US$ 3,6 por milhão de tokens (uma mistura de 4 para 1 entre entrada e saída a US$ 2 e US$ 10). Trate todos os tokens do mesmo modo, o que subestima o que um nó consegue fazer em trabalho com muita entrada. Um nó custa US$ 17.280 por mês e consegue movimentar cerca de 6,5 bilhões de tokens nesse tempo.
| Volume mensal | Nós auto-hospedados e utilização | Total auto-hospedado, com equipe | Total da API |
|---|---|---|---|
| 3 bilhões de tokens | 1 nó, 46% | US$ 47.300 | US$ 10.800 |
| 10 bilhões | 2 nós, 77% | US$ 64.600 | US$ 36.000 |
| 30 bilhões | 5 nós, 93% | US$ 116.400 | US$ 108.000 |
| 60 bilhões | 10 nós, 93% | US$ 202.800 | US$ 216.000 |
Com essas premissas, a hospedagem se paga em algum ponto entre 30 e 60 bilhões de tokens por mês, ou de um a dois bilhões por dia. Abaixo disso, a API é bem mais barata, e a diferença é maior nos volumes em que vivem muitos pilotos. Os números serão diferentes para os seus preços, a sua vazão e a sua equipe, e o método é montar esta tabela com as suas cifras antes de se comprometer com uma equipe de plataforma.
Assim, a economia da hospedagem favorece um conjunto estreito de casos: volume muito alto e estável que mantém o hardware ocupado, dados que não podem sair do ambiente da empresa por razões legais ou contratuais, requisitos de latência que uma API remota não atende ou a necessidade de modificar o modelo de maneiras que o fornecedor não permite. Fora desses casos, comprar acesso é mais barato e anda mais rápido. Muitas empresas acabam com uma mistura: um modelo de fronteira hospedado para o trabalho difícil e de baixo volume, e um modelo menor para as tarefas de alto volume em que a resposta é rotineira. Um roteador que envia cada requisição ao modelo mais barato capaz de tratá-la mantém as duas opções abertas. Os termos contratuais importam tanto quanto o preço. Acordos de tratamento de dados, limites de retenção, indenizações e os direitos do fornecedor sobre seus prompts e saídas fazem parte do que está sendo comprado, e a revisão jurídica deles pertence à comparação e não ao depois. A decisão de comprar também traz o risco de depender de um provedor, e a resposta a esse risco é portabilidade e um plano reserva testado, não a auto-hospedagem por padrão.
Treinar um modelo do zero fica mais longe. Faz sentido para uma empresa com um ativo de dados raro e um negócio que depende de uma linguagem que os modelos gerais tratam mal, o que descreve a Bloomberg e poucas outras. Para a maioria das organizações, o dinheiro rende mais nas partes do sistema que ninguém mais vai construir para elas.
Como adaptá-lo: prompt, recuperação, ajuste fino
A adaptação é uma escada, e as equipes tendem a pular para o degrau de cima porque ele parece engenharia de verdade. A ordem de menor custo e maior reversibilidade é prompt, depois recuperação, depois ajuste fino. Comece por baixo e suba apenas quando a avaliação disser que o degrau inferior se esgotou.
O prompt, com alguns exemplos bem escolhidos no contexto, resolve uma parcela surpreendente de tarefas e pode ser alterado em minutos. A recuperação traz o conhecimento próprio da empresa buscando documentos relevantes na hora da pergunta. O ajuste fino muda os pesos do modelo usando exemplos do comportamento que você quer.
A evidência sobre para que serve o ajuste fino é consistente. Oded Ovadia e colegas compararam o ajuste fino não supervisionado com a recuperação como formas de injetar conhecimento num modelo e constataram que o ajuste fino dava ganhos modestos enquanto a recuperação se saía consistentemente melhor, tanto para fatos que o modelo vira no treino quanto para fatos inteiramente novos. Zorik Gekhman e colegas, no EMNLP 2024, constataram que exemplos que introduzem fatos novos são aprendidos muito mais devagar do que exemplos coerentes com o que o modelo já sabe, e que, uma vez aprendidos, aumentam a tendência do modelo a alucinar mais ou menos na mesma proporção. A conclusão deles é que um modelo adquire a maior parte do conhecimento factual no pré-treinamento e que o ajuste fino ensina principalmente a usar melhor esse conhecimento.
A leitura prática é que o ajuste fino serve para comportamento e não para fatos. Combina com um formato de saída consistente, um estilo da casa, um esquema de classificação com muitos rótulos, o vocabulário de uma área especializada e o encolhimento de uma tarefa para um modelo menor e mais barato. Se o objetivo é que o modelo conheça o conteúdo dos contratos ou dos manuais da empresa, a recuperação é a ferramenta, e ajustar com esses documentos tende a decepcionar.
A computação do ajuste fino já não é o obstáculo. O LoRA, de Edward Hu e colegas, reduziu o número de parâmetros treináveis em cerca de 10.000 vezes e a memória de GPU em cerca de 3 vezes em comparação com o ajuste fino completo do GPT-3 175B, sem latência adicional na inferência. O QLoRA, de Tim Dettmers e colegas, tornou possível ajustar um modelo de 65 bilhões de parâmetros numa única GPU de 48 GB, e os modelos Guanaco deles levaram 24 horas de treino numa GPU para chegar a 99,3% do nível do ChatGPT num benchmark. O que continua caro são os dados rotulados, a avaliação e a disciplina de refazer ambos sempre que o modelo base mudar.
A faixa importa mais que a técnica
Uma decisão que muitas vezes economiza mais do que qualquer projeto de ajuste fino é escolher a faixa certa de modelo. Tome um trabalho de classificação sobre 20 milhões de documentos por mês, cada um com cerca de 1.000 tokens e uma resposta de 50 tokens. Com os preços acima, um modelo de faixa média custa US$ 0,0025 por documento, o que dá US$ 50.000 por mês. A faixa mais barata custa US$ 0,000125 por documento, ou US$ 2.500 por mês, um vigésimo. Saber se o modelo barato é preciso o bastante é uma questão empírica para a suíte de avaliação, e a resposta às vezes é sim com um bom prompt e às vezes sim só depois de um ajuste fino. Uma equipe que ajusta um modelo de faixa média por meses sem testar antes a faixa mais barata pulou o passo de maior efeito.
A lição geral é precificar a escada inteira antes de subir. Rode a avaliação em três ou quatro modelos de custos diferentes, com e sem recuperação, e desenhe a acurácia contra o custo por tarefa. A fronteira desse gráfico é o cardápio, e o ajuste fino é um jeito de mover um modelo mais barato para perto de um mais caro.
A terceira decisão é sempre sua
Comprar um modelo não significa comprar um sistema. Seja qual for o caminho nas duas primeiras decisões, a empresa é dona da suíte de avaliação que define o comportamento aceitável, dos pipelines que trazem e limpam seus dados, do monitoramento que percebe a deriva, dos controles de acesso que decidem quem vê o quê e da governança que responde a reguladores e clientes. Isso não são extras. É onde está a maior parte do custo de longo prazo, e é igual quer o modelo seja alugado, quer seja treinado.
É também onde se acumula a vantagem que sobrevive às mudanças de fornecedor. O modelo de um fornecedor pode ser trocado pelo seguinte, mas o conjunto de avaliação, os dados limpos e a integração ao fluxo de trabalho são específicos da empresa e não passam para um concorrente. Quando as pessoas dizem que querem ser donas da sua capacidade de IA, é essa a parte que vale a pena possuir.
Uma regra de decisão que pode ser auditada
Um procedimento curto mantém as três decisões separadas. Para cada caso de uso de IA, faça quatro perguntas. Essa capacidade nos diferencia aos olhos dos clientes ou é uma função de commodity? Temos dados que outros não têm, e eles melhoram os resultados? Quão estável é a tarefa, isto é, a solução de hoje ainda será adequada daqui a um ano? Que restrições se aplicam à localização dos dados, à latência ou à regulação?
| Situação | Padrão | Reveja quando |
|---|---|---|
| Função de commodity, sem dados especiais | Comprar acesso à API, usar prompt | Uma faixa mais barata passar na sua avaliação |
| Precisa dos documentos ou registros da empresa | Comprar, acrescentar recuperação | A qualidade da recuperação estagnar apesar dos ajustes |
| Alto volume de uma tarefa estável e estreita | Ajustar um modelo menor | O modelo base mudar ou a tarefa se deslocar |
| Os dados não podem sair do seu ambiente, ou o volume é alto e estável | Hospedar pesos abertos | A utilização cair abaixo do ponto de equilíbrio ou um fornecedor oferecer implantação privada |
| Ativo de dados raro, linguagem que os modelos gerais tratam mal | Considerar treinar | Quase nunca, e só com um caso em nível de conselho |
Escreva e marque uma data
Cada caso de uso deve ter um registro de decisão de uma página que declare a escolha feita em cada uma das três decisões, as evidências por trás dela e os gatilhos que a reabririam. A seção de evidências é a que costuma ser pulada. Deve conter as notas de avaliação das opções testadas, com seu custo por tarefa, a premissa de volume por trás da comparação de custo e o nome da pessoa responsável pelo conjunto de avaliação. Os gatilhos devem ser números concretos: uma faixa concorrente que pontua a dois pontos de distância por metade do preço, um volume mensal que cruza o ponto de equilíbrio da hospedagem, uma regulação que muda onde os dados podem ser processados. O registro deve ter uma data de revisão ligada ao ciclo de lançamento de modelos, já que a resposta certa tem prazo de validade medido em meses. Uma decisão de que ninguém se lembra de ter tomado, e que ninguém vai rever, é a que silenciosamente vira a linha mais cara do orçamento.
Fontes
- Wu, S., Irsoy, O., Lu, S., et al. (2023). BloombergGPT: A Large Language Model for Finance. arXiv:2303.17564.
- Anthropic. Pricing, documentação para desenvolvedores do Claude (preços de tabela em outubro de 2026). platform.claude.com/docs/en/about-claude/pricing.
- Ovadia, O., Brief, M., Mishaeli, M., Elisha, O. (2023). Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs. arXiv:2312.05934.
- Gekhman, Z., Yona, G., Aharoni, R., et al. (2024). Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations? EMNLP 2024. arXiv:2405.05904.
- Hu, E. J., Shen, Y., Wallis, P., et al. (2021). LoRA: Low-Rank Adaptation of Large Language Models. arXiv:2106.09685.
- Dettmers, T., Pagnoni, A., Holtzman, A., Zettlemoyer, L. (2023). QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023. arXiv:2305.14314.
- Modelo ilustrativo de custo de serviço: preço do nó de US$ 24 por hora (oito GPUs a US$ 3) e vazão agregada de 2.500 tokens por segundo, premissas declaradas no texto.