O projeto de código aberto llm-d publicou a versão 1.0 na terça-feira, 20 de outubro de 2026, que os responsáveis consideram a mais importante desde o arranque. O llm-d é uma camada nativa de Kubernetes que fica à frente de servidores de modelos como vLLM e SGLang e decide onde deve correr cada pedido de inferência. Nasceu em 2025 por iniciativa da Red Hat, IBM, Google Cloud, CoreWeave e NVIDIA, é hoje um projeto Sandbox da Cloud Native Computing Foundation e reúne mais de 500 contribuidores de mais de 25 organizações.
As versões anteriores concentraram-se no desempenho: encaminhar pedidos para réplicas que já têm em cache o prefixo do prompt, descarregar a cache chave-valor para memória mais barata, separar a fase de prefill, exigente em cálculo, da fase de decode, exigente em memória, e distribuir grandes modelos de mistura de especialistas por muitos aceleradores. A versão 1.0 dirige-se ao que o projeto chama operações do segundo dia, ou seja, manter um serviço de inferência partilhado estável para muitos clientes ao longo do tempo.
As novidades são sobretudo operacionais. Um novo sistema de controlo de fluxo agrupa o tráfego por cliente e prioridade, protege as cargas premium em picos enquanto os trabalhos em lote esperam, e reduz a carga de forma gradual em vez de falhar. O router passa a ter uma instância de reserva ativa, e um componente chamado DisaggregatedSet trata as réplicas de prefill e decode como uma só unidade, permitindo atualizá-las no local sem perder pedidos. A API de configuração passou a v1 estável. Para agentes, o encaminhamento por sessão mantém uma conversa de várias voltas na réplica que guarda a sua cache, e o suporte ao estado da Responses API evita que o agente reenvie todo o histórico.
A Google, que publicou um texto próprio no mesmo dia, acrescentou um processador assíncrono que recolhe tarefas tolerantes a latência de filas como Pub/Sub ou Redis, além de partilha de tempo em TPUs e GPUs para aproveitar pausas durante a aprendizagem por reforço. Segundo a Google, isso fez subir a ocupação dos aceleradores de cerca de 40% para mais de 70%. A empresa indica também que, numa carga de programação com agentes em TPUs Ironwood, o encaminhamento sensível à cache com descarga para memória do anfitrião reduziu em mais de 85% a mediana do tempo até ao primeiro token e multiplicou o débito por 2,4 face a um simples Kubernetes Service, e que a sua plataforma Gemini duplicou a taxa de acerto na cache de prefixos, de 35% para 70%.
O projeto enumera utilizadores em produção de vários fornecedores. Segundo a equipa do llm-d, a AWS regista até mais 70% de tokens por segundo no SageMaker HyperPod, a Tesla e a Red Hat mediram o triplo do débito de saída com Llama 3.1 70B em GPUs AMD MI300X, e a IBM Research serve até 3000 agentes de programação em simultâneo com 544 GPUs NVIDIA H100. DigitalOcean, Oracle Cloud Infrastructure, Mistral AI e JetBrains também são referidas. A plataforma funciona em GPUs NVIDIA, AMD e Intel e em TPUs Google, e a Red Hat distribui-a no Red Hat AI.
O lançamento é relevante porque a inferência, e não o treino, está a tornar-se a maior fatia da despesa em computação para IA, e os agentes reutilizam enormes quantidades de contexto. Um escalonador partilhado e neutro pode reduzir a dependência de um único fabricante de chips ou de uma plataforma proprietária.
Todos os números de desempenho vêm dos fundadores e utilizadores do llm-d, medidos nas suas próprias cargas, e nenhum foi validado por terceiros. O rótulo 1.0 indica estabilidade das APIs, mas os operadores terão de avaliar a maturidade de cada tipo de hardware, e o suporte para a futura plataforma Vera Rubin da NVIDIA ainda está em curso.