O cálculo míope do custo por token e a realidade da inferência própria

A conta de padaria que apareceu nos últimos dias é sedutora. Uma instituição financeira decide sair da dependência de provedores externos de modelos de linguagem, compra dezenas de aceleradores de última geração, adota um modelo aberto como o GLM e calcula que o custo por milhão de tokens caiu para cerca de trinta centavos de dólar. Isso representa quase um décimo do que cobram as APIs proprietárias líderes.

Quem olha apenas para a fatura mensal comemora. Mas essa matemática ignora quase toda a complexidade de manter infraestrutura de inferência em produção.

O debate gerado por esse movimento revelou duas leituras opostas. De um lado, estão os defensores da soberania imediata e do fim do racionamento. O argumento aqui é prático: quando você paga por token consumido em uma API externa, as lideranças criam políticas de contenção de despesas. O desenvolvedor passa a ter medo de usar ferramentas de apoio no dia a dia, temendo ser cobrado pelo volume de contexto enviado, o que estrangula a exploração técnica. Para esse grupo, internalizar a execução zera a barreira marginal e devolve a liberdade para os times automatizarem tarefas sem restrições contratuais ou fiscais.

Do outro lado, engenheiros mais céticos apontam que um investimento inicial de três milhões de dólares em hardware, somado a despesas de energia, refrigeração e depreciação acelerada, só fecha a conta se a empresa já queimava rios de dinheiro em chamadas externas. Além disso, existe o risco óbvio de obsolescência: se daqui a seis meses surgir uma arquitetura incompatível com o conjunto de instruções atual, o ativo vira peso morto antes do prazo de retorno.

Eu concordo com o primeiro grupo em um aspecto que quase ninguém que olha planilhas percebe: o estrago comportamental do racionamento de tokens. Quando uma equipe precisa justificar cada prompt ou teme ultrapassar cotas corporativas em ferramentas externas, o uso prático morre. Ninguém aprende a integrar modelos em pipelines internos sob vigilância contínua de custos variáveis. No setor financeiro, a situação piora, pois o receio de vazar dados regulados para servidores de terceiros frequentemente paralisa qualquer iniciativa antes mesmo de chegar à homologação. Executar modelos dentro do próprio perímetro resolve essa barreira de conformidade de uma vez.

Porém, acho que a maioria erra feio ao tratar inferência de modelos abertos como se fosse hospedar uma aplicação web tradicional com proxy reverso e banco relacional.

Operar servidores de aplicação em VPS ou bare metal, como fazemos com clusters de bancos e nós de execução de tarefas, envolve dinâmicas conhecidas de CPU, memória e disco. Inferência de modelos gigantescos em paralelo exige uma pilha completamente diferente. Você não está apenas subindo um container com um script em Python. Você precisa lidar com alocação estrita de memória de vídeo através de dezenas de nós interconectados por malhas de altíssima velocidade, onde qualquer variação de latência em um cabo quebra o paralelismo tensorial.

Existe também a gestão da cache de chaves e valores durante picos de concorrência. Em uma aplicação típica, o aumento de tráfego eleva o uso de conexões de banco e consumo de memória RAM, algo que se resolve com enfileiramento ou réplicas horizontais baratas. Em clusters de GPU dedicados à inferência, se o volume de contexto concorrente esgota a memória de vídeo, o throughput desaba imediatamente ou as requisições sofrem cancelamentos forçados. Para manter tempos de resposta aceitáveis no primeiro token emitido, a equipe precisa dominar motores de execução de baixo nível, estratégias de quantização que não degradem a precisão lógica e políticas agressivas de agendamento contínuo de lotes.

Isso significa que você não substituiu um custo de API por uma máquina que roda sozinha. Você substituiu uma linha de despesa operacional na nuvem por salários de especialistas em infraestrutura de aprendizado de máquina, engenheiros de redes de baixa latência e técnicos de datacenter. Se a sua empresa não tem esse perfil técnico dentro de casa, o cluster vai passar metade do tempo subutilizado ou fora do ar enquanto alguém tenta entender uma falha de driver após uma atualização do sistema operacional.

Outro ponto que o entusiasmo esquece é o comportamento do próprio modelo aberto. Modelos como o GLM ou equivalentes de pesos abertos atingiram um patamar impressionante de utilidade para tarefas estruturadas de código, análise de documentos e fluxos bem delimitados. Eles são perfeitamente capazes de substituir modelos proprietários caros quando as instruções são estritas e os formatos de entrada e saída são rígidos.

No entanto, a tolerância deles a instruções ambíguas é visivelmente menor. Modelos de fronteira hospedados por grandes laboratórios possuem camadas imensas de alinhamento e técnicas proprietárias de raciocínio que compensam comandos mal formulados por equipes inexperientes. Ao adotar pesos abertos na sua infraestrutura, o ônus da precisão volta integralmente para a engenharia de software da sua empresa: torna-se obrigatório implementar validação semântica de esquemas, validação rigorosa de saídas com ferramentas locais e filtros determinísticos antes de devolver a resposta ao usuário final.

Se você está avaliando esse caminho, o primeiro passo não é pedir cotação de servidores nem sonhar com custos de centavos por milhão de tokens. O primeiro passo é auditar o consumo real e a natureza das suas cargas de trabalho. Se a sua demanda é esporádica e depende de capacidades analíticas de ponta para prompts genéricos, o provedor externo ainda é a opção mais racional, mesmo que doa no bolso a cada fatura.

Internalizar faz sentido quando existem duas condições simultâneas: volume de chamadas previsível o suficiente para saturar os nós adquiridos sem ociosidade crônica, e restrições regulatórias ou de privacidade que impeçam dados bancários e cadastrais de saírem da sua rede privada. Fora desse cenário, você não estará construindo soberania tecnológica; estará apenas criando um datacenter caro e complexo que vai desviar o foco da engenharia do produto principal da sua empresa.

Fontes

• https://twitter.com/guilleflorvs/status/2117379073785696395