O custo oculto da nuvem

Capítulo 5 — O custo oculto da nuvem

A narrativa dominante dos últimos cinco anos diz que a nuvem é econômica, escalável e simples. Para muitas cargas de trabalho, isso é perfeitamente verdade. Para os RAG empresariais, cada vez mais frequentemente, não é. E o momento em que você percebe isso geralmente é no final do primeiro trimestre, quando a fatura chega.

Vamos considerar o item mais subestimado da conta: as APIs dos modelos de visão. Quando uma empresa ingere seu arquivo fotográfico em um RAG moderno, cada foto deve ser "descrita" por um modelo multimodal que extrai conteúdo, objetos, contexto, eventuais textos sobrepostos, humor, composição. Um grande provedor europeu de modelos — ainda sem nome — oferecia, em 2025, um excelente modelo da família Qwen com 32 bilhões de parâmetros, a um preço por imagem interessante. O problema, descoberto apenas no campo e após meses de produção: sob carga, o provedor truncava as respostas. Não sempre, não de forma previsível, não quando havia a equipe de teste presente: aleatoriamente. Uma foto a cada dez, às vezes uma a cada cinco, retornava com um JSON cortado ao meio, mal analisado, com metadados parciais ou nulos. Os tempos disparavam de dez segundos para duzentos segundos por imagem, sem padrão. A conta do retry — porque os retries são pagos, cada chamada, até mesmo aquela que o servidor trunca — era mais alta do que o previsto. O banco de dados era heterogêneo: algumas fotos riquíssimas em metadados, outras truncadas. E a equipe não conseguia reproduzir o problema em ambientes de teste, porque em teste a carga era baixa e tudo funcionava.

A solução chegou em três partes: um prompt mais compacto (respostas mais curtas truncam menos), uma lógica de retry inteligente (se a resposta demorar mais de cinquenta segundos e retornar vazia, tente novamente imediatamente) e — quando o volume justificar — a possibilidade de pular completamente a nuvem e executar o modelo de visão em uma GPU local, mais lenta, mas determinística. A arquitetura certa, a partir desta experiência, não é "nuvem sempre" nem "local sempre". É "escolha para cada chamada, com base no que é necessário naquele momento".

Depois, há o capítulo das consultas. Cada pesquisa do usuário, em um RAG nativo da nuvem clássico, desencadeia uma cascata de chamadas de API pagas. Uma para o embedding da pergunta. Uma para a classificação intencional (que tipo de pergunta é?). Uma para o reranking dos documentos. Uma para a geração da resposta final. Cada uma custa uma fração de centavo. Para um serviço interno com cinquenta usuários e dez mil consultas por dia — que não são poucas, mas também não são um número enorme para uma empresa média — a conta mensal chega a cifras que fariam até mesmo um CFO indulgente franzir a testa. E o crescimento é linear: dobre os usuários, dobre a conta. Não há economias de escala nos tokens consumidos, não para você.

Há também um problema que em 2025 estava em segundo plano e que em 2026 se tornou central: cada consulta individual envia fragmentos de documentos corporativos — às vezes confidenciais, às vezes cobertos por NDA, às vezes sujeitos a regulamentações do setor — para os servidores de um fornecedor externo, em jurisdições que nem sempre coincidem com a sua, com políticas de retenção de logs nem sempre claras. Mais de uma empresa europeia, nos últimos dezoito meses, descobriu apenas durante uma auditoria — geralmente motivada por um cliente preocupado ou por uma verificação ISO — que seus contratos, tabelas de preços e especificações técnicas foram processados (e potencialmente registrados para fins de "melhoria do serviço") por infraestruturas fora da UE. A surpresa, geralmente, custou mais do que a economia em hardware local que se pretendia evitar.

A alternativa não é o dogma oposto. "Sem nuvem, apenas local" está errado tanto quanto "sempre nuvem". A alternativa é uma arquitetura que permita escolher, para cada peça do pipeline — embedding, classificação, reranking, visão, geração final — se usar um modelo em nuvem ou um local, e mudar de ideia em um dia, não em um trimestre. Isso requer um design onde os fornecedores sejam intercambiáveis, onde nenhuma peça esteja presa ao nome de uma empresa específica, onde a transição de Regolo para Ollama (ou vice-versa) seja uma linha de configuração, não uma reescrita. E isso, até pouco tempo atrás, era raro. Os frameworks populares, apesar da fachada de "agnóstico de provedor", eram na verdade muito comprometidos com alguém.