Por que agentes de IA precisam de um stack de inferência aberta

"Todos os laboratórios de IA estão perdendo dinheiro atendendo à sua empresa no momento. Eles sabem disso. E fazem isso deliberadamente."

Essa foi a frase de abertura de um artigo que recebi na mesma semana em que três números se consolidaram para deixar claro por que a inferência aberta não é mais opcional.

Um desenvolvedor criou uma aplicação de notas simples em um fim de semana utilizando um agente de codificação open source com uma chave de API direta. Uma página, uma funcionalidade. Custo: US$ 50. No dia seguinte, uma subscrição de US$ 20/mês fornecia 50 vezes mais tokens.

Um engenheiro da nossa equipe de inferência consumiu 300 milhões de tokens por meio de modelos open-weight em dois dias, realizando o mesmo trabalho que teria custado milhares de dólares com APIs proprietárias.

Os dois primeiros números revelam o subsídio. O terceiro revela a saída. E o motivo de precisarmos dessa solução são os agentes.

O modelo de preços está em transição

Os provedores de modelos de fronteira fizeram algo notável. Eles tornaram a IA de excelência acessível a milhões de desenvolvedores por preços impensáveis há dois anos. Essa acessibilidade gerou uma explosão de adoção. Também criou uma estrutura econômica que pode não ser sustentável nos níveis atuais.

O site Is AI profitable yet? acompanha o panorama financeiro geral do setor de IA. Atualmente, as empresas de IA gastam cerca de 195% da receita. Um colaborador da discussão calculou que, em dólares equivalentes a 2024, o gasto de capital total em IA em 10 anos foi cerca de três vezes o custo de todo o Sistema de Rodovias Interestaduais dos EUA. Esses tipos de investimentos acabarão sendo refletidos na precificação dos serviços.

Os sinais dessa transição já estão surgindo. Relatos indicam que algumas empresas de grande porte estão reconsiderando as licenças de ferramentas de codificação de IA à medida que a cobrança baseada em tokens substitui as subscrições de taxa fixa, com custos por engenheiro chegando a US$ 500 a US$ 2.000 por mês. Os modelos mais recentes oferecem melhorias modestas de benchmark e consomem de 10% a 25% mais tokens por tarefa. O fornecimento de GPU já está reservado para os próximos três a quatro anos, e vários provedores de nuvem de GPU já esgotaram a capacidade.

Nada disso é uma crítica aos provedores. Eles estão construindo o futuro e definindo preços agressivos para acelerar a adoção. Os custos unitários por token provavelmente continuarão caindo, e o Gartner projeta uma redução de 90% até 2030. No entanto, a mesma análise observa que as cargas de trabalho de agentes de IA consomem tantos tokens a mais por tarefa que o gasto total com inferência empresarial deve aumentar, apesar das unidades mais baratas. O Goldman Sachs prevê um aumento de 24 vezes no consumo de tokens até 2030. As empresas que planejam os próximos três a cinco anos devem se preparar para custos agregados maiores, e não menores. Os modelos open source executados em infraestrutura autogerenciada são a válvula de escape que ajudará a manter a acessibilidade da IA à medida que o consumo aumenta.

Figura 1: O paradoxo do custo da inferência de agentes de IA. Os custos por token caem 90% (Gartner), mas o consumo total aumenta 24 vezes (Goldman Sachs), resultando em um gasto empresarial agregado mais alto, apesar das unidades mais baratas.

Os agentes mudaram a equação

A precificação de subscrição foi projetada para pessoas digitando na velocidade humana. Os agentes geram ordens de magnitude a mais de chamadas de API, e nenhum modelo de precificação existente foi criado para isso.

Um colaborador do OpenClaw consumiu US$ 1,3 milhão em tokens da API da OpenAI em um único mês. Isso representa 603 bilhões de tokens em 7,6 milhões de solicitações de cerca de 100 instâncias do Codex operadas por três pessoas. Em um único dia, essa conta registrou US$ 19.985,84 em gastos.

Jensen Huang afirmou que o consumo de tokens de agentes aumentou cerca de 1.000 vezes em comparação com o uso de modelos tradicionais. No podcast Latent Space, Marc Andreessen disse que seu círculo gasta US$ 1.000 por dia em tokens do Claude executando agentes, com uma demanda latente de US$ 5.000 a US$ 10.000 por dia por agente pessoal totalmente implantado. Mesmo com uma melhoria de 10 vezes no preço, o custo ainda é de US$ 100 por dia. "Ainda muito além do que as pessoas podem pagar."

Alguns provedores já tiveram que restringir a execução de frameworks de agentes de terceiros em subscrições de taxa fixa, pois as demandas de computação excediam o que o modelo de precificação poderia sustentar. A precificação de taxa fixa e as cargas de trabalho de agentes autônomos são estruturalmente incompatíveis.

O custo é apenas parte do problema. As cargas de trabalho de agentes de IA têm requisitos técnicos que as APIs proprietárias nunca foram projetadas para expor.

Fragmentação de API. O cenário de APIs de agentes de IA possui vários padrões concorrentes. Chat Completions (formato stateless original da OpenAI), Responses API (formato stateful mais recente da OpenAI com ferramentas integradas e integração com o Model Context Protocol), Messages API (formato da Anthropic) e Interactions API (protocolo de agentes de IA do Google). Cada uma lida com chamadas de ferramentas, gerenciamento de estado e raciocínio de forma diferente. Cada harness escolhe um padrão diferente.

Cada família de modelos também envolve a mesma chamada de ferramenta em tags completamente diferentes. O envio de get_weather(city="Seattle") para cinco modelos produz cinco formatos diferentes: O Llama usa a sintaxe Python com <|python_tag|>, o Mistral usa [TOOL_CALLS] com arrays JSON, o Gemma usa tags <tool_code> e o Hermes usa XML <tool_call>. O engine de inferência precisa de um parser separado para cada família de modelos.

Chamada de ferramenta. Com uma API proprietária, você recebe o parser que o provedor oferecer. Você não pode personalizá-lo. Você não pode corrigir um modelo que gera sintaxe Pythonic em vez do formato treinado. Você é apenas um passageiro.

Roteamento de modelos. Uma única execução de agente gera subtarefas heterogêneas: algumas exigem raciocínio profundo, outras classificação rápida e outras geração de código. O roteamento dessas tarefas para modelos diferentes exige controle sobre a camada de disponibilização. Com a API de um único provedor, todas as tarefas são enviadas para o mesmo modelo pelo mesmo preço.

Engenharia de contexto. Gerenciar o que chega ao modelo em muitos turnos é a otimização de maior impacto disponível. Um pipeline de contexto bem ajustado pode reduzir o uso de tokens de 60% a 80%, melhorando a qualidade da saída. Mas a engenharia de contexto eficaz requer acesso ao comportamento do modelo no nível de inferência. É necessário medir o que o modelo realmente processa, identificar quais tokens de contexto contribuem para a qualidade da saída e ajustar as estratégias de resumo e recuperação com base em padrões de atenção reais, em vez de suposições.

Circuit breakers. Sem controle sobre a camada de inferência, você não pode implementar orçamentos por agente, detecção de anomalias ou desligamento automático no nível do servidor do modelo. Como alguém que já sofreu as consequências de um loop descontrolado, posso afirmar que o provedor não salvará você.

Os economistas chamam isso de Paradoxo de Jevons. William Stanley Jevons notou esse padrão em 1865. À medida que os motores a carvão se tornavam mais eficientes, o consumo total de carvão aumentava. Os tokens de IA estão na mesma trajetória. Cada ganho de eficiência desbloqueia novos casos de uso que consomem mais do que a economia gerada. As empresas que alcançarem resultados por token utilizarão mais IA, e não menos.

Os modelos abertos estão prontos para o trabalho com agentes de IA

Como mencionado acima, nossa equipe de inferência processou 300 milhões de tokens usando modelos open-weight em dois dias. Nemotron 3 Super, Gemma 4 e Qwen 3.6, todos executados no stack de inferência do Red Hat AI. O resultado foi robusto o suficiente para revisões de pull requests, implementações de primeira fase e investigações direcionadas, aliviando o trabalho que, de outra forma, seria destinado aos modelos de fronteira e acumularia custos de tokens.

A diferença de custo não é marginal. Benchmarks em GPUs Blackwell para consumidores mostram que uma GPU de US$ 500 executando modelos open-weight pode processar 30 milhões de tokens por dia. Nesse volume, o custo do hardware é recuperado em três meses, em comparação com o custo da mesma carga de trabalho em provedores de API de baixo custo (~US$ 0.20 por milhão de tokens). Em comparação com os preços das APIs de fronteira, o período de retorno do investimento cai para dias.

Um pesquisador criou um agente de codificação que atingiu 87% nos benchmarks usando um modelo que ativa apenas quatro bilhões de parâmetros por token. Agentes que usam modelos de 14 bilhões de parâmetros pontuaram 75%. A diferença não era o modelo, mas sim as ferramentas compostas e um loop de feedback de erro. O harness realizou o trabalho pesado, não o tamanho do modelo.

Fazer com que os modelos abertos funcionem bem em cenários de agentes de IA exige engenharia real, e é exatamente essa engenharia que o open source possibilita. Uma demonstração recente do Gemma 4 com OpenCode e Claude Code mostra como isso funciona na prática. Ela inclui ajustes personalizados de chat templates, sintonia do parser de chamada de ferramentas para cada família de modelos e formatação de prompts em vários padrões de API. O modelo de quatro bilhões de parâmetros exigiu um tratamento diferente da versão quantizada de 26 bilhões, que, por sua vez, precisou de um tratamento diferente do modelo de 31 bilhões de parâmetros.

Esse é o tipo de trabalho que reduz a lacuna entre o desempenho de benchmark e o desempenho real dos agentes de IA. Isso envolve a tradução entre APIs de chat completion, mensagens e respostas, além da análise da saída do modelo com lógica difusa. Os modelos às vezes perdem seus tokens de início de chamada de ferramenta ou geram sintaxe inesperada influenciada pelos prompts de sistema do harness.

Esse trabalho está ocorrendo upstream no vLLM, nos chat templates de fornecedores de modelos e em relatórios de bugs de harnesses. E isso só pode acontecer abertamente. Com um servidor de inferência proprietário, você não pode enviar uma correção de chat template, ajustar um parser de chamada de ferramenta ou observar por que a saída do seu agente está falhando. Com o open source, toda correção beneficia todos os usuários e todo upgrade de parser é permanente. Esse trabalho de integração upstream, que torna os modelos open-weight confiáveis para cargas de trabalho de agentes de IA em todo o stack de disponibilização, é o foco principal do Red Hat AI.

O stack de inferência de agentes de IA

Há oito camadas que devem trabalhar juntas para a inferência de agentes de IA em escala empresarial. Cada camada interage com todas as outras.

Figura 2: O stack de inferência de agentes de IA: do agente e harness no topo até a conversão de API, gateway, guardrails, disponibilização desagregada, configuração de servidor de modelos, engine de inferência e hardware na base. As bordas vermelhas destacam ambas as camadas, onde reside a maior parte do trabalho de compatibilidade de agentes de IA. O limite tracejado do sandbox envolve a camada do agente, onde a execução de código e os controles de segurança são mais rigorosos.

Montar essas camadas a partir de projetos open source individuais é possível, mas operacionalmente caro. O valor de uma plataforma de inferência autogerenciada como o Red Hat AI é a integração em um stack testado e com suporte que roda na sua infraestrutura. Seus dados nunca saem do seu limite de segurança e você controla o ciclo de upgrade, a seleção de modelos e a política de roteamento.

A camada de API de agentes de IA

O problema da diversidade de APIs é real. Os harnesses utilizam Chat Completions, Responses, Messages ou Interactions APIs, e o servidor de modelos subjacente não necessariamente suporta todos eles. A camada de API de agentes de IA fica entre o harness e a infraestrutura para preencher essa lacuna. Projetos como o OGX (anteriormente Llama Stack) fornecem implementações abertas das próprias APIs de agentes de IA: Chat Completions, Responses, Messages e Interactions APIs, além de recursos complementares como vector stores, gerenciamento de arquivos e execução de ferramentas, tudo sobre qualquer camada de disponibilização de modelos que você utilize.

Nenhum padrão de API deve vencer a corrida isoladamente agora, apesar da vantagem pioneira de algumas delas. O importante é ter implementações open source de todos eles, para que você possa combinar qualquer harness com qualquer modelo sempre que precisar. Quando a camada de tradução é aberta, ela preserva todo o contrato de tool calling e você pode ver exatamente o que acontece com sua solicitação. Quando um provedor proprietário cuida da tradução, você nunca sabe o que é perdido.

llm-d: Escalabilidade da inferência de agentes de IA

O vLLM de instância única funciona para um engenheiro executando agentes, mas não para 100 engenheiros acessando os mesmos modelos simultaneamente. O llm-d é a camada de disponibilização desagregada que divide a inferência em fases separadas de prefill e decode, permitindo que escalem de forma independente em hardwares diferentes. Para cargas de trabalho de agentes de IA, em que muitas solicitações curtas se intercalam com longas cadeias de raciocínio, essa arquitetura é cada vez mais essencial.

Guardrails e sandboxing

A segurança de conteúdo também faz parte desse stack e precisa estar ciente dos agentes. Frameworks de guardrails que operam como proxies precisam preservar o contrato completo da API de agentes de IA, incluindo definições de ferramentas, escolha de ferramentas e parâmetros de raciocínio, ou correm o risco de degradar silenciosamente o comportamento do agente.

Guardrails eficazes para agentes de IA também exigem acesso a dados de nível de inferência que a simples filtragem de texto de entrada/saída não fornece. Isso inclui rastreamentos de raciocínio para avaliar se o chain-of-thought do modelo contém etapas inseguras, parâmetros de chamada de ferramenta para validar argumentos e logprobs para detectar riscos de alucinação. Esse é outro motivo pelo qual a camada de inferência deve ser aberta. Guardrails que apenas veem o texto de entrada e saída são insuficientes para cargas de trabalho de agentes de IA. 

Se o seu proxy de guardrails for uma caixa preta que remove parâmetros de tool calling, você não conseguirá diagnosticar por que seus agentes falharam. Guardrails open source (como o endpoint /v1/guardrails/checks do NVIDIA NeMo Guardrails) aplicam a segurança de conteúdo sem quebrar o contrato da API de agentes de IA.

O sandboxing é outro fator. Os agentes executam código, gravam arquivos e invocam ferramentas. A defesa em profundidade exige isolamento em camadas, incluindo confinamento no nível do container, política de rede, restrições do sistema de arquivos e imposição de runtime. Colocar um agente em um container não é suficiente. O limite do sandbox no diagrama do stack envolve o agente e o harness, por ser onde a execução de código arbitrário pode ocorrer e onde os controles de segurança devem ser mais rigorosos.

Por que o open source vence

Você não pode testar um stack de oito camadas quando não consegue ver o que metade das camadas está fazendo. Você não pode depurar chamadas de ferramenta com falha quando não consegue ver o parser. Você não pode reforçar a segurança quando o proxy de guardrails remove silenciosamente os parâmetros necessários para os agentes. O stack é muito acoplado para qualquer camada ser opaca. Integrar e consolidar essas camadas para que as empresas não precisem montar o stack sozinhas é o problema que o Red Hat AI resolve.

Além do argumento técnico, a inferência aberta é inevitável por motivos estruturais que vão além do custo.

Figura 3: Inferência aberta vs. APIs proprietárias para cargas de trabalho de agentes de IA. As APIs proprietárias lideram em facilidade de configuração e qualidade dos modelos de fronteira. A inferência aberta lidera nos sete recursos dos quais as cargas de trabalho de agentes de IA dependem em produção: roteamento de modelos, depuração de tool calls, personalização de domínio, orçamentos por agente, residência de dados, independência de provedor e guardrails em nível de inferência.

A educação acelera todo o setor. O open source oferece duas coisas: software gratuito e conhecimento gratuito. O DeepSeek R1 mostrou isso claramente. As capacidades de raciocínio existiram em modelos proprietários por meses antes que a comunidade pudesse replicá-las. Após a DeepSeek publicar o código e o artigo, todos os grandes laboratórios desenvolveram capacidades de raciocínio em três meses. O efeito de difusão do conhecimento é mais valioso do que o próprio modelo. Aplicados à inferência de agentes de IA, cada correção de parser de tool call, cada melhoria de chat template e cada patch de harness tornam-se infraestrutura compartilhada que beneficia todo o ecossistema.

Confiança exige transparência. Nem toda organização está disposta a rotear todos os seus dados e fluxos de trabalho por meio de poucos provedores de modelos em nuvem. Para alguns, é uma questão de conformidade rigorosa. Setores como saúde e finanças enfrentam requisitos regulatórios rígidos de privacidade e residência de dados. Para outras, é uma escolha estratégica para evitar o vendor lock-in e manter a propriedade total da sua propriedade intelectual.

O open source oferece às organizações a opção de executar modelos em seus próprios termos, sob seus próprios limites de segurança, com visibilidade total do funcionamento do sistema. Para setores regulamentados, governos e cargas de trabalho sensíveis à segurança, isso é um requisito. A regulamentação segue na mesma direção: as obrigações de transparência do EU AI Act, aplicáveis a partir de agosto de 2026, exigem documentação técnica sobre arquitetura de modelos, procedimentos de treinamento e características de desempenho. Modelos open source que já publicam essas informações qualificam-se para isenções que modelos fechados não possuem.

A personalização exige pesos (weights) próprios. Com uma API fechada, todas as organizações executam o mesmo modelo. Quando você detém os pesos em sua própria infraestrutura, pode realizar o fine-tuning para seu domínio, ferramentas internas e convenções de base de código sem enviar dados proprietários externamente. Organizações de saúde realizam o fine-tuning para terminologia clínica e formatos de registros de pacientes. Equipes jurídicas adaptam modelos a linguagens e estruturas contratuais específicas de cada jurisdição. Instituições financeiras realizam o treinamento com seus próprios modelos de risco e frameworks de conformidade. Para cargas de trabalho de agentes de IA, essa é a diferença entre um agente de uso geral e um que já entende como seus sistemas funcionam.

O open source cria gravidade no ecossistema. Quando fornecedores de hardware investem em software de inferência open source, modelos mais acessíveis impulsionam uma adoção mais ampla de hardware. Investimentos em otimizações de vLLM (o runtime de inferência) e melhorias no stack de disponibilização open source tornam cada GPU mais capaz de processar cargas de trabalho de agentes de IA e permitem a reutilização de hardware. O resultado é um ciclo virtuoso no qual melhorias de software open source se somam em todo o ecossistema.

A próxima fase favorece modelos distribuídos. O padrão emergente é "centrado no contexto compartilhado", com muitos modelos trabalhando em knowledge graphs e context stores compartilhados. Isso muda o foco de um único modelo massivo para um ecossistema de modelos especializados coordenados por um harness inteligente. Você não precisa necessariamente de um modelo que faça tudo. Na maioria das vezes, você precisará de vários modelos especializados, cada um executando bem sua função, trabalhando juntos como um sistema composto. Essa arquitetura é inerentemente mais aberta e distribuída.

Arquiteturas de agentes emergentes, como Pi e OpenClaw, entre outras, já são construídas dessa forma. O design é minimalista e geralmente inclui um Large Language Model (LLM), um shell bash, um sistema de arquivos, arquivos de estado em markdown e um cron loop. O estado reside em arquivos, não em pesos, permitindo trocar o LLM sem perder a memória do agente. Esses agentes funcionam com qualquer modelo, fechado ou aberto. Mas, quando o stack completo é aberto — dos pesos dos modelos à infraestrutura de disponibilização —, todas as vantagens estruturais se somam: você realiza o fine-tuning para seu domínio, faz o roteamento entre modelos que controla, observa com ferramentas próprias e troca qualquer camada sem interromper o restante. É isso que torna a inferência aberta a base natural para agentes de IA e o Red Hat AI a plataforma que a impulsiona. 

Como se preparar

Três coisas para fazer agora, antes que as mudanças de preços cheguem.

Figura 4: Três ações para se preparar para a inferência aberta de agentes de IA, cada uma com ferramentas específicas do stack do Red Hat AI. A linha do tempo mostra uma rampa de 12 meses, da portabilidade de APIs até a infraestrutura de agentes de IA totalmente autogerenciada.

Crie harnesses agnósticos. A forma como você projeta seu harness e seus agentes de IA é tão importante quanto o modelo executado, se não mais. Se seus agentes forem codificados para a API de um único provedor, você estará preso antes que as mudanças de preços cheguem. Desenvolva visando a portabilidade de modelos e APIs. É aqui que projetos como o OGX, disponível pelo Red Hat AI, se encaixam. Eles fornecem a camada de tradução aberta entre as APIs de Chat Completions, Responses, Messages e Interactions, para que seus agentes permaneçam portáteis, independentemente do modelo ou provedor subjacente.

Hospede o volume em infraestrutura autogerenciada. Uma única GPU executando um modelo Gemma 4 ou Qwen quantizado já pode lidar com revisões de pull requests, documentação e sumarização de código. Use subscrições de API para cargas de trabalho que realmente exijam raciocínio de fronteira, ou onde esses modelos ainda tenham uma vantagem clara de qualidade, e hospede o restante em infraestrutura própria. Uma plataforma de inferência autogerenciada lida com a complexidade operacional de disponibilização, escalabilidade, roteamento e observabilidade de modelos. Assim, sua equipe foca na criação de agentes em vez de manter o stack de disponibilização. 

À medida que os modelos open source continuam a reduzir a lacuna em relação às capacidades de fronteira, as cargas de trabalho que você pode hospedar por conta própria apenas crescerão. Começar agora cria a prontidão operacional necessária para quando os modelos open source cobrirem todo o stack. Pesquisas sobre roteamento de modelos evidenciam que direcionar a maioria das solicitações para modelos menores ou auto-hospedados, escalonando apenas tarefas complexas para APIs de fronteira, pode reduzir custos de 60% a 85% com perda mínima de qualidade.

Teste de ponta a ponta em todo o stack de agentes de IA. Um modelo aprovado em benchmarks ainda pode falhar se o harness o solicitar incorretamente, se o parser de ferramentas ler a saída erradamente ou se o gateway rotear as tarefas incorretamente. Testar o trio modelo-harness-configuração é a abordagem correta.

Incorpore também o orçamento de tokens ao seu processo. Limites por agente. Atribuição por funcionalidade. Detecção de anomalias. O MLflow Tracing, integrante do stack do Red Hat AI, captura prompts, etapas de raciocínio, invocações de ferramentas e custos de tokens com compatibilidade total com o OpenTelemetry. Você vai querer os alertas de orçamento antes de precisar deles.

Prepare-se para o que vem a seguir

Normalmente, o hardware deprecia. As GPUs para inferência aberta fazem o oposto. Os chips não mudam, mas o software executado neles continua melhorando. Melhores kernels de atenção e batching no vLLM processam mais tokens por segundo no mesmo silício. Avanços na quantização fazem modelos que antes exigiam 80 GB caberem em 20 GB com qualidade comparável. A disponibilização desagregada divide as cargas de trabalho para que o mesmo cluster suporte mais agentes simultâneos. Uma GPU corporativa comprada há três anos produz inferências mais úteis hoje do que no dia da instalação, pois o stack open source melhorou ao seu redor.

Essa composição é o fio condutor de todo este argumento. Analisadores de chamadas de ferramentas abertas tornam-se melhores para todos. Os templates de chat abertos corrigem a compatibilidade definitivamente. Guardrails abertos que preservam o contrato da API de agentes de IA protegem todas as implantações, não apenas os clientes de um único fornecedor. A disponibilização desagregada aberta escala no hardware que você já possui.

É para isso que serve uma plataforma de IA open source. Não se trata apenas de disponibilizar modelos, mas de deter todo o stack de inferência de agentes de IA em sua própria infraestrutura: da camada de API que traduz entre o harness e o modelo, passando pelo gateway de roteamento e medição, até o engine de disponibilização e o hardware. É o que chamamos de "do metal aos agentes". Seus dados permanecem dentro do seu limite de segurança. Seus modelos rodam onde você escolher. Seus custos são previsíveis porque você controla todas as camadas. Todas as camadas são abertas. Todas as camadas são depuráveis. Toda melhoria é compartilhada.

Os modelos são bons o suficiente (e melhoram a cada dia). O stack está tomando forma. A economia é clara. A questão não é se a inferência aberta de agentes de IA acontecerá (ela já aconteceu), mas se você estará preparado quando a conta chegar.