Ray 2.55 Adiciona Tolerância a Falhas para Implementações de Modelos de IA em Grande Escala

Joerg Hiller 02 de abr de 2026 18:35

A atualização Ray Serve LLM da Anyscale permite tolerância a falhas de grupo DP para implementações vLLM WideEP, reduzindo o risco de tempo de inatividade para sistemas de inferência de IA distribuídos.

A Anyscale lançou uma atualização significativa para a sua estrutura Ray Serve LLM que aborda um desafio operacional crítico para organizações que executam cargas de trabalho de inferência de IA em grande escala. O Ray 2.55 introduz tolerância a falhas de grupo paralelo de dados (DP) para implementações vLLM Wide Expert Parallelism—uma funcionalidade que evita que falhas de GPU individuais derrubem clusters inteiros de serviço de modelos.

A atualização visa um ponto problemático específico no serviço de modelos Mixture of Experts (MoE). Ao contrário das implementações de modelos tradicionais onde cada réplica opera independentemente, as arquiteturas MoE como o DeepSeek-V3 fragmentam camadas de especialistas em grupos de GPUs que devem trabalhar coletivamente. Quando uma GPU nestas configurações falha, o grupo inteiro—potencialmente abrangendo 16 a 128 GPUs—torna-se não operacional.

O Problema Técnico

Os modelos MoE distribuem redes neurais especializadas "especialistas" por múltiplas GPUs. O DeepSeek-V3, por exemplo, contém 256 especialistas por camada mas ativa apenas 8 por token. Os tokens são encaminhados para quaisquer GPUs que contenham os especialistas necessários através de operações de despacho e combinação que requerem que todos os ranks participantes estejam saudáveis.

Anteriormente, uma falha de rank único quebraria estas operações coletivas. As consultas continuariam a ser encaminhadas para réplicas sobreviventes no grupo afetado, mas todos os pedidos falhariam. A recuperação exigia reiniciar todo o sistema.

Como o Ray Resolve

O Ray Serve LLM agora trata cada grupo DP como uma unidade atómica através de agendamento em grupo. Quando um rank falha, o sistema marca o grupo inteiro como não saudável, interrompe o encaminhamento de tráfego para ele, destrói o grupo falhado e reconstrói-o como uma unidade. Outros grupos saudáveis continuam a servir pedidos durante todo o processo.

A funcionalidade é enviada ativada por predefinição no Ray 2.55. As implementações DP existentes não requerem alterações de código—a estrutura trata verificações de saúde ao nível do grupo, agendamento e recuperação automaticamente.

O escalonamento automático também respeita estes limites. As operações de aumento e diminuição de escala acontecem em incrementos do tamanho do grupo em vez de réplicas individuais, evitando a criação de grupos parciais que não podem servir tráfego.

Implicações Operacionais

A atualização cria uma consideração de design importante: largura do grupo versus número de grupos. De acordo com benchmarks vLLM citados pela Anyscale, o throughput por GPU permanece relativamente estável em tamanhos paralelos de especialistas de 32, 72 e 96. Isto significa que os operadores podem ajustar para grupos menores sem sacrificar eficiência—e grupos menores significam raios de explosão menores quando ocorrem falhas.

A Anyscale observa que esta resiliência ao nível de orquestração complementa o trabalho de elasticidade ao nível do motor que está a acontecer na comunidade vLLM. O RFC vLLM Elastic Expert Parallelism aborda como o runtime pode ajustar dinamicamente a topologia dentro de um grupo, enquanto o Ray Serve LLM gere quais grupos existem e recebem tráfego.

Para organizações que implementam modelos estilo DeepSeek em escala, o benefício prático é direto: falhas de GPU tornam-se incidentes localizados em vez de interrupções em todo o sistema. Exemplos de código e passos de reprodução estão disponíveis no repositório GitHub da Anyscale.

• ray
• vllm
• infraestrutura de ia
• machine learning
• computação nuvem