Llm-d 1.0 chega como stack open source de inferência distribuída para Kubernetes

O llm-d 1.0 foi lançado na PyTorch Conference como stack open source e nativo de Kubernetes para inferência distribuída de LLMs. O projeto é do CNCF Sandbox, co-fundado pelo Google com Red Hat, IBM e outros, e reúne mais de 500 contribuidores de mais de 25 organizações. A proposta é transformar um cluster de servidores de modelo em um pool coordenado, com um endpoint, um roteador, um índice de KV cache e uma política de flow control na frente de toda a frota.

O Google justifica o lançamento pela mudança no perfil de tráfego: de chat simples para agentes multi-etapa e rollouts de RL, que compartilham prefixos longos e chegam em rajadas. Um balanceador round-robin genérico faz réplicas recomputarem os mesmos prompts e enche a memória dos aceleradores com estado duplicado. Na versão 1.0 entram APIs v1, alta disponibilidade do roteador, atualizações sem downtime, o DisaggregatedSet para updates de prefill e decode em conjunto e o llm-d-async-processor, que consome filas como Pub/Sub e Redis. Os números de desempenho citados vêm do próprio Google. Em um workload de coding agent em TPU Ironwood, o TTFT mediano caiu mais de 85% e a vazão subiu 2,4 vezes. Em um benchmark em A3 Mega com offload de KV cache para Managed Lustre, a necessidade de GPU-hora caiu quase 60%. O Snap relata taxas de acerto de prefix cache de até 75 a 80%.

Em 4 de abril de 2026, o CEVIU noticiou, em "Kubernetes como Infraestrutura para IA: Google Cloud, llm-d e a CNCF", a aceitação do llm-d como projeto Sandbox da CNCF. Agora o projeto chega à versão 1.0, com APIs v1 e um caminho de requisição validado em várias nuvens e tipos de acelerador. Em 17 de junho de 2026, o CEVIU cobriu, em "GKE Inference Gateway corta até 92% da latência em inferência de IA com cache de prefixo inteligente", o roteamento por prefixo no GKE. Agora o GKE Inference Gateway aparece como a forma gerenciada de rodar o roteador do llm-d. Em 21 de outubro de 2026, o CEVIU noticiou, em "Google abre o código do TorchTPU e leva PyTorch nativo para as TPUs", a abertura do TorchTPU, que o llm-d 1.0 integra para servir modelos PyTorch em TPUs.

Para quem opera inferência própria em Kubernetes, o llm-d reduz o risco de construir um scheduler sob medida. A arquitetura é composável: dá para começar com roteamento por prefixo na frente de um vLLM existente e adicionar flow control, offload e disaggregation depois. Do ponto de vista de custo, o ganho depende de cache hit e de uso de acelerador, então vale validar com carga real antes de projetar economia. O vínculo com GKE é forte nos recursos gerenciados (Inference Gateway, Managed Lustre), o que pede atenção a lock-in, embora a base seja aberta.