API de IA ou modelo próprio: a conta que decide

A pergunta chega quase sempre no mesmo formato: "sai mais barato rodar o modelo na nossa própria máquina do que pagar a API?". E a resposta que costuma ser dada — comparar o preço por milhão de tokens com o preço mensal de uma VPS — leva à decisão errada com frequência.

O erro está em comparar duas coisas com estruturas de custo diferentes. API é custo variável puro: zero de uso, zero de fatura. Máquina própria é custo fixo: ela cobra igual processando dez requisições ou dez mil. Comparar os dois exige saber qual é o seu volume, e principalmente como ele se distribui ao longo do dia.

Onde fica o ponto de equilíbrio

A conta de verdade tem três variáveis: volume mensal de tokens, preço por token da API, e custo total da alternativa própria.

O passo que quase todo mundo pula é medir o volume. Antes de qualquer projeção, instrumente o que você já gasta:

# Se você já usa a API, o provedor informa o consumo.
# Se está estimando, meça o tamanho médio das suas chamadas:
wc -w prompt-exemplo.txt

Uma regra útil: em português, um token equivale grosseiramente a 0,75 palavra. Multiplique por chamada, por dia, por trinta.

Com o volume em mãos, a comparação fica direta. Suponha uma máquina capaz de rodar o modelo que você precisa custando um valor fixo mensal. Divida esse valor pelo preço por token da API: o resultado é quantos tokens você precisaria consumir para que os dois se igualassem.

Se o seu volume real está muito abaixo desse número, a API é mais barata — e provavelmente por uma margem grande. Se está muito acima, a máquina própria começa a fazer sentido. Se está perto, decida por outro critério, porque a diferença não justifica o esforço.

A variável que muda o resultado: o formato da carga

Volume total é só metade da história. A distribuição importa tanto quanto.

Carga constante — processamento em lote, classificação de documento que chega o dia inteiro, indexação contínua — aproveita bem uma máquina dedicada. Ela fica ocupada, e ocupação alta é o que amortiza custo fixo.

Carga em picos é o oposto. Um assistente usado em horário comercial deixa a máquina ociosa dezesseis horas por dia e nos fins de semana. Você paga por 720 horas mensais e usa 200. Nesse cenário a API vence quase sempre, mesmo com volume alto no pico — porque no pico você paga só o pico.

A pergunta que resume: a sua máquina ficaria ocupada? Se a resposta é não por boa parte do tempo, o custo fixo está trabalhando contra você.

Os custos que não entram na planilha

A comparação ingênua conta a mensalidade da máquina e para por aí. Faltam pelo menos quatro linhas:

• Tempo de engenharia para colocar de pé. Escolher o modelo, quantizar, dimensionar, configurar o servidor de inferência, testar qualidade. Não é proibitivo, mas não é zero.
• Manutenção contínua. Atualização de modelo, correção de dependência, acompanhamento de desempenho. A API entrega isso embutido.
• Redundância. Uma máquina é um ponto único de falha. Se a funcionalidade é crítica, você precisa de duas — e o custo fixo dobra antes de a conta começar.
• Custo de oportunidade do modelo. Modelos abertos que rodam em hardware modesto entregam menos que os modelos maiores das APIs. Se a qualidade menor gera retrabalho humano, esse retrabalho tem custo.

Do outro lado, a API também tem custos que costumam ser esquecidos: latência de rede em cada chamada, dependência de disponibilidade de terceiro, limite de requisição, e a variação de preço e de comportamento quando o fornecedor atualiza o modelo.

Quando o critério não é custo

Em boa parte dos casos que valem a pena, a decisão não é financeira.

Dado que não pode sair. Se o conteúdo processado é sensível — prontuário, documento jurídico, dado de cliente sob contrato restritivo —, o modelo local pode ser a única opção viável. Vale ler antes o que realmente expõe dado em integrações com IA: nem sempre o risco está onde se imagina.

Latência previsível. Chamada externa depende da internet e da fila do fornecedor. Modelo local responde com latência estável, o que importa em fluxo interativo.

Independência. Modelo próprio não muda de comportamento porque o fornecedor atualizou a versão. Para quem construiu prompt afinado, essa estabilidade tem valor.

Volume muito alto e tarefa simples. Classificar, extrair campo, resumir texto curto — tarefas em que um modelo pequeno resolve bem — em escala grande é exatamente o cenário em que a máquina própria ganha com folga.

O caminho intermediário que costuma vencer

A decisão raramente precisa ser exclusiva, e a arquitetura híbrida costuma dar o melhor resultado por real gasto.

A ideia é rotear por tarefa. As tarefas de alto volume e baixa dificuldade vão para o modelo local; as poucas que exigem raciocínio mais elaborado vão para a API. Como a distribuição costuma ser desbalanceada — muitas chamadas simples, poucas complexas —, isso corta a maior parte do custo variável mantendo a qualidade onde ela importa.

Some a isso duas medidas que reduzem custo independentemente da escolha:

• Cache de resposta. Pergunta repetida não precisa de inferência nova. Em base de conhecimento e suporte, a taxa de repetição costuma ser alta.
• Prompt enxuto. Contexto que não é usado é token pago. Revisar o que vai em cada chamada frequentemente corta um terço do consumo.

Dimensionar a máquina, se for esse o caminho

Sem GPU, a variável que manda é memória — o modelo precisa caber na RAM, e o que sobra vira cache. O artigo sobre rodar um LLM na sua VPS detalha quantização, RAM necessária e a velocidade realista em CPU.

Duas recomendações práticas para não errar o tamanho:

• Comece menor do que você acha. Um modelo menor que atende é melhor que um maior que atende de sobra e custa o dobro. O upgrade de CPU e RAM é aplicado em janela curta, o que torna barato começar modesto e crescer com dado real.
• Meça throughput, não tamanho. O número que importa é quantas requisições por minuto a máquina entrega com qualidade aceitável. Compare esse número com o seu pico real.

Instrumentar antes de escalar

Independentemente do caminho, há um erro que custa caro nos dois: não medir o consumo por funcionalidade.

Uma fatura de IA costuma chegar como número único. Sem quebrar esse número, não há como saber que 70% dele vem de uma funcionalidade secundária que ninguém usa, ou de um prompt que cresceu sem que alguém percebesse.

O mínimo a registrar em cada chamada:

• Qual funcionalidade disparou.
• Tokens de entrada e de saída, separados — o preço é diferente e a alavanca de otimização também.
• Latência, para saber se a experiência está degradando.
• Se veio do cache, para medir a taxa de acerto.

Com esses quatro campos em uma tabela, perguntas caras viram consultas simples: qual funcionalidade consome mais, qual usuário concentra uso, o prompt novo aumentou o gasto.

SELECT funcionalidade,
       count(*) AS chamadas,
       sum(tokens_entrada + tokens_saida) AS tokens,
       avg(latencia_ms)::int AS latencia_media
FROM chamadas_ia
WHERE criado_em > now() - interval '30 days'
GROUP BY 1 ORDER BY tokens DESC;

Esse registro também é o que torna a migração possível depois. Trocar de API para modelo próprio sem histórico de consumo é dimensionar no escuro — e é a causa mais comum de comprar máquina errada. Com trinta dias de dados, o cálculo do ponto de equilíbrio deixa de ser estimativa.

Um roteiro de decisão

• Meça o volume atual em tokens por mês, com dado e não com estimativa.
• Calcule o ponto de equilíbrio dividindo o custo fixo pelo preço por token.
• Olhe o formato da carga. Constante favorece máquina própria; em picos, favorece API.
• Verifique se há restrição de dado — se houver, ela decide antes do custo.
• Comece pela API se ainda não há volume. Ela permite validar o produto sem investimento inicial, e a migração para modelo próprio depois é bem mais fácil que o contrário.

Esse último ponto costuma ser o conselho mais útil. A maior parte dos projetos de IA que nascem com infraestrutura própria descobre semanas depois que o produto precisava de outra coisa — e a máquina dimensionada para a ideia original vira custo fixo sem uso.

Vale reavaliar a decisão a cada semestre, e não tratá-la como definitiva. Preço de API cai com regularidade, modelos abertos melhoram, e o seu volume muda. A escolha certa no ano passado pode ser a errada agora, nas duas direções — e quem instrumentou o consumo consegue refazer a conta em uma tarde.