llm-d 1.0 estreia na conferência PyTorch com uma pilha de inferência pronta para produção

Os colaboradores do projeto llm-d anunciaram o llm-d 1.0, uma pilha distribuída de serviço de inferência nativa do Kubernetes, em 20 de outubro de 2026, na PyTorch Conference North America, segundo um anúncio da IBM Research. A IBM afirmou que o lançamento leva o llm-d além da demonstração de técnicas individuais de desempenho e busca ajudar as organizações a internalizar a implantação de modelos à medida que os custos de inferência aumentam.

O llm-d foi desenvolvido para implantar pilhas de inferência para qualquer modelo, em qualquer acelerador e em qualquer nuvem. Red Hat, IBM e Google são os principais mantenedores do projeto e fundaram o llm-d junto com CoreWeave e NVIDIA; AMD, Cisco, Hugging Face, Intel, Lambda e Mistral AI ingressaram como colaboradores. A Cloud Native Computing Foundation (CNCF) hospeda o llm-d como projeto sandbox. A IBM descreve o resultado como uma alternativa independente de fornecedores para organizações que buscam o que ela chama de desempenho de inferência de ponta, sem depender totalmente de um único provedor de modelos proprietários, serviço de nuvem ou plataforma de hardware.

Carlos Costa, engenheiro ilustre da IBM Research e cofundador e principal mantenedor do llm-d, afirmou que a versão 1.0 acrescenta a maturidade necessária para operar o llm-d como qualquer outro serviço crítico. Ele destacou uma API estável, o compartilhamento da mesma infraestrutura por vários locatários com prioridades concorrentes e atualizações que não interrompem as operações.

O que a versão 1.0 acrescenta

As notas de lançamento da v1.0.0 do projeto, publicadas no GitHub em 20 de outubro de 2026 com tags assinadas e verificadas, destacam a qualidade de serviço para vários locatários: controle de fluxo que leva em conta prioridades e equidade, com redução controlada da carga, incluindo um mecanismo probabilístico de admissão, equidade com reconhecimento de programas e pontuação de prioridade por turno. Assim, solicitações sensíveis à latência e cargas de trabalho de agentes com picos de atividade podem compartilhar uma frota sem que uma prejudique a outra quando há sobrecarga. A configuração do controle de fluxo foi consolidada em um único campo, flowControl.

Para permitir operações sem tempo de inatividade, o roteador passa a oferecer alta disponibilidade com espera ativa e atualizações contínuas seguras, enquanto um controlador DisaggregatedSet gerencia as réplicas de prefill e decode como uma única unidade lógica, com implementações coordenadas, atualizações sincronizadas, prontidão condicionada ao snapshot do Pod e roteamento nativo por revisão. A API de configuração do roteador passa à v1, a Responses API passa a aceitar previous_response_id e o caminho de solicitação do seletor de endpoint foi reforçado para oferecer confiabilidade, desempenho e escalabilidade. O lançamento também inclui um guia de aceleradores com reconhecimento da topologia para DRA e DRANET.

O serviço com reconhecimento de agentes acrescenta um plugin produtor de estado de sessão e afinidade de sessão dinâmica para manter conversas com várias interações próximas de seu contexto em cache, além de agendamento por prioridade de turno e estado da Responses API para ajudar os agentes a reutilizar o contexto entre turnos. O lançamento alinha os componentes do projeto na v1.0.0 e acrescenta elementos ao ecossistema, incluindo uma integração com ai-dynamo/modelexpress para carregar pesos de modelos ponto a ponto, o pacote llm-d-api-extensions e as ferramentas de diagnóstico llm-d-pd-utils. Também descontinua as compilações próprias de imagens de contêiner llm-d-rocm do projeto. As imagens dos servidores de modelos incluem compilações de vLLM e SGLang para diferentes alvos de aceleradores, e o guia de desagregação de prefill e decode agora exige o LeaderWorkerSet v0.11.1 ou posterior, com a API DisaggregatedSet habilitada.

Técnicas centrais e controle de fluxo

Desde o lançamento, o projeto se concentra em cinco abordagens para melhorar a inferência: roteamento com reconhecimento do cache de prefixos, que direciona uma solicitação para uma infraestrutura que talvez já contenha o contexto compartilhado; descarregamento do cache KV, que transfere informações em cache entre recursos de GPU, CPU e armazenamento; otimização da inferência em lote; desagregação de prefill e decode, que separa a leitura de um prompt da geração de uma resposta; e paralelismo amplo de especialistas, que distribui grandes modelos de mistura de especialistas por muitos aceleradores. Essas técnicas são anteriores à versão 1.0; segundo a IBM, a novidade está na integração e na maturidade operacional que as acompanham, além da disciplina operacional do segundo dia, que consiste em manter o desempenho quando o tráfego muda, o hardware falha, o software é atualizado ou diferentes usuários disputam os mesmos recursos.

Na versão 1.0, o controle de fluxo, a equidade e a priorização buscam impedir que cargas de trabalho com picos de atividade sobrecarreguem serviços sensíveis à latência, quer compartilhem o mesmo hardware, quer abranjam uma combinação de aceleradores. As solicitações também podem permanecer vinculadas à infraestrutura adequada ao longo de vários turnos, mantendo aquecidos os caches de prefixos. O llm-d funciona com mecanismos de inferência como vLLM e SGLang, acrescentando recursos de roteamento distribuído e operação. Stephen Watt, vice-presidente do gabinete do diretor de tecnologia da Red Hat, afirmou que o llm-d unifica os ecossistemas PyTorch e CNCF ao levar a orquestração nativa do Kubernetes diretamente ao vLLM e aos mecanismos modernos de inferência.

Resultados demonstrados e custos informados

Em uma publicação sobre benchmarks publicada em 22 de julho de 2026, o projeto mediu o serviço de inferência agêntica do GLM-5.2, descrito ali como um modelo de mistura de especialistas com 744 bilhões de parâmetros, 39 bilhões de parâmetros ativos e 78 camadas. A análise da carga de trabalho baseou-se em 219 sessões de produção do Claude Code, nas quais a solicitação mediana do agente principal continha 195 mil tokens de entrada e gerava 317 tokens de saída, e 96% dos turnos do agente principal reutilizavam pelo menos 90% dos dados de entrada. A publicação informa que o roteamento sensível a prefixos aproveitou 96–97% da reutilização de cache disponível na carga de trabalho. Considerando uma tarifa de locação presumida de H200 de US$ 2,71 por GPU-hora, estima-se que o serviço de inferência auto-hospedado em duas configurações de 64 GPUs custe de US$ 0,05 a US$ 0,08 por milhão de tokens de entrada e de US$ 1,92 a US$ 3,55 por milhão de tokens de saída. Segundo os autores, esses valores cobrem apenas a locação de GPUs e pressupõem carga sustentada.

Em uma demonstração separada, a IBM e a Red Hat implantaram o GLM-5.2 — descrito na publicação da IBM Research como um modelo de pesos abertos com aproximadamente 753 bilhões de parâmetros, dos quais cerca de 39 bilhões são ativos — em 544 GPUs NVIDIA H100. A IBM informa que, no pico, a implantação gerou mais de 6,6 milhões de tokens de saída por minuto enquanto atendia até 3.000 agentes de programação simultâneos sem preempções, e que, com 2.500 agentes, manteve 7.612 solicitações por minuto. A IBM afirma que, às tarifas atuais de locação na nuvem, hospedar o GLM-5.2 por conta própria em GPUs H100 com o llm-d custa de 5 a 10 vezes menos por token do que os preços de APIs comerciais equivalentes. “Atender milhares de agentes simultâneos sem preempções oferece aos operadores um caminho confiável dos resultados de benchmark à implantação em produção”, afirmou Maroon Ayoub, engenheiro sênior principal de aprendizado de máquina da equipe de engenharia de inferência da Red Hat.

Segundo a mesma publicação, na base desses resultados, o plano de dados desagregado concluiu 6,2 milhões de transferências de cache KV, com média de 2,71 GiB por transferência e nenhuma falha. Todos os benchmarks foram concluídos sem erros de atendimento.