O próximo corte no custo de inferência de IA pode vir abaixo do modelo. O llm-d 1.0 mostra onde

Um agente trabalhando em uma mudança de código pode chamar o modelo quarenta vezes em uma tarefa. Cada chamada carrega quase o mesmo contexto da anterior: os mesmos arquivos do repositório, as mesmas instruções, as mesmas definições de ferramentas, além de algumas linhas novas. Se a camada de serving envia a chamada 23 para uma GPU diferente da chamada 22, o trabalho de ler aquele contexto é feito de novo do zero. Multiplique por milhares de agentes e a maior linha na conta de inferência não é o modelo. É recomputação.

Esse é o argumento econômico por trás do llm-d 1.0, lançado em 20 de outubro. O llm-d é um projeto de inferência distribuída open source fundado em 2025 pela Red Hat, pela IBM, pelo Google Cloud, pela CoreWeave e pela NVIDIA, agora governado pela Cloud Native Computing Foundation, com mais de 500 contribuidores de mais de 25 organizações. Ele roda em Kubernetes acima de engines de inferência como vLLM e SGLang.

O que o 1.0 adiciona

Versões anteriores já ofereciam roteamento ciente do cache de prefixo e da carga, offload de KV cache, separação das fases de prefill e decode em réplicas diferentes e suporte a hardware misto. A versão 1.0 adiciona o que uma frota de produção compartilhada precisa:

• Qualidade de serviço multi-tenant. Controle de fluxo com consciência de prioridade e fairness, para que requisições sensíveis à latência e o tráfego em rajadas de agentes compartilhem uma mesma frota. Engenheiros da Mistral descrevem o uso de faixas de prioridade para proteger o tráfego pago sob carga.
• Operações sem tempo de inatividade. Um roteador de alta disponibilidade com hot standby, atualizações graduais e réplicas de prefill e decode gerenciadas e atualizadas como uma única unidade.
• Serving ciente de agentes. Roteamento ciente da sessão, agendamento que prioriza turnos dentro de uma conversa e suporte nativo ao estado da Responses API, para que menos seja recalculado entre os turnos de um agente.
• Uma base estável: uma API de configuração v1 e um caminho de requisição reforçado, validado em nuvens e aceleradores.

1. A requisição chega com tenant e prioridade
2. Controle de fluxo: qual faixa, qual parcela
3. Roteamento ciente da sessão para a réplica que detém o contexto
4. Prefill: apenas tokens novos se houver acerto no cache
5. Decode e streaming da resposta

• Decidido antes de o modelo fazer qualquer trabalho: Controle de fluxo: qual faixa, qual parcela · Roteamento ciente da sessão para a réplica que detém o contexto · Prefill: apenas tokens novos se houver acerto no cache

Requisição do agenteDecisões de serving que o llm-d toma

Como ler as alegações de custo

A IBM cita custo de 5 a 10 vezes menor para cargas agênticas com muito contexto. O exemplo mais bem documentado é uma demonstração com o GLM 5.2, um modelo de pesos abertos de cerca de 753 bilhões de parâmetros, em GPUs NVIDIA amplamente implantadas: mais de 6,6 milhões de tokens de saída por minuto no pico, até 3.000 agentes de código simultâneos sem preempções e, nas taxas atuais de aluguel de nuvem, cerca de 5 a 10 vezes menos por token do que preços equivalentes de APIs comerciais, com as maiores economias em tráfego com muito input. Um estudo da IBM Research relata uma taxa de acerto de prefix cache de aproximadamente 98% e um custo combinado de cerca de US$ 0,11 por milhão de tokens.

Esses são resultados específicos de carga. Uma taxa de acerto de cache de 98% é uma propriedade de uma carga em que a maior parte de cada requisição se repete, o que loops de agentes muitas vezes são e muitas outras cargas não são. A comparação é contra preços de tabela de APIs, e deixa de fora os engenheiros que operam a frota. A declaração da JetBrains de que roda o llm-d em produção por trás do seu plano Junie Lite é a evidência mais útil no lançamento, porque é uma alegação de produção, não um benchmark.

O que muda para uma empresa

A alavanca de custo desce a stack. Para times que hospedam modelos de pesos abertos por conta própria, como muitos começaram a considerar quando a Reflection liberou os pesos do Beam, a arquitetura de serving agora molda o custo tanto quanto a escolha do modelo. As perguntas a fazer para um time de plataforma são novas: qual é a nossa taxa de acerto de prefix cache por carga e as sessões de agentes permanecem nas réplicas que detêm o seu contexto?

Prioridade vira política. QoS multi-tenant significa que alguém decide quais requisições esperam quando a frota está cheia. Essa é uma decisão de negócio, próxima das decisões de orçamento que agentes já exigem, e deveria ter um responsável em vez de um padrão.

Upgrades viram rotina em vez de incidentes. Upgrades coordenados de réplicas de prefill e decode endereçam um risco operacional real: uma frota metade em uma versão de engine e metade em outra.

Ainda é infraestrutura que você opera. O llm-d é open source, não um serviço gerenciado disponível em todo lugar. O Google Cloud diz que está integrando o llm-d 1.0 ao GKE, e clientes da CoreWeave podem rodá-lo no serviço Kubernetes dela, mas um deploy autogerenciado exige habilidades de Kubernetes e de serving de inferência que a maioria das empresas não tem em profundidade. Como em rodar pesos abertos por conta própria, a economia só é real para organizações que conseguem carregar o dever operacional. Serving mais rápido também não diz nada sobre se as respostas estão corretas; essa medição continua onde estava.