Faça valer cada hora de GPU: Acompanhamento de progresso no Red Hat OpenShift AI

É noite de sexta-feira. Priya, engenheira de machine learning (ML) em uma empresa de serviços financeiros, coloca em fila uma tarefa de ajuste fino para detecção de fraudes em um cluster de GPU que custa US$ 55 por hora. A execução deve levar cerca de 40 horas, com aproximadamente US$ 2.200 de custos em computação. Ela revisa os hiperparâmetros, envia a tarefa e vai para casa para o fim de semana.

Na manhã de segunda-feira, ela abre o laptop. O modelo parou de aprender em algum momento na noite de sexta-feira, mas a tarefa continuou em execução, consumindo dois dias inteiros de tempo de GPU em um treinamento sem resultados. Isso representa mais de US$ 1.500 em computação desperdiçada, e ela precisa recomeçar.

Se isso soa familiar, você não está sozinho. Todo profissional que já executou uma tarefa de treinamento de vários dias conhece estas perguntas desconfortáveis:

• O modelo está realmente aprendendo algo?
• Devo interromper antecipadamente e tentar hiperparâmetros diferentes?
• Será concluído antes da revisão com os stakeholders na terça-feira?

O custo de não saber é real. Clusters de GPU sob demanda podem custar mais de US$ 50 por hora. Um único treinamento de vários dias pode custar milhares de dólares, e uma configuração incorreta pode desperdiçar um fim de semana inteiro de computação antes que alguém perceba. Em clusters compartilhados, o impacto se multiplica: uma tarefa interrompida não desperdiça apenas o orçamento de uma equipe, mas impede que outras equipes acessem as GPUs necessárias. A execução às escuras de uma equipe gera o atraso de outra. O problema não é o descuido das equipes. É que elas estão operando às escuras. Cada hora de GPU é importante. Sem visibilidade em tempo real do progresso do treinamento, muitas delas são desperdiçadas.

A lacuna de observabilidade

A verdade desconfortável é esta: do ponto de vista da plataforma, uma tarefa de treinamento com ótima convergência e outra completamente estagnada parecem idênticas. Ambos são pods no estado running, consumindo os mesmos recursos e exibindo o mesmo indicador de status verde. O Kubernetes não identifica se o modelo está aprendendo.

Atualmente, o monitoramento do progresso de treinamento é possível, mas é mais difícil do que deveria ser.

• Os logs são dispersos e difíceis de usar: em tarefas de treinamento distribuído, os logs ficam espalhados por vários pods. Encontrar a saída relevante exige saber qual pod consultar, como acessá-lo e como interpretar formatos de log específicos de cada framework. Isso exige conhecimento em Kubernetes, uma habilidade extra que a maioria de cientistas de dados e engenharia de IA não deveria precisar adquirir apenas para monitorar treinamentos. Logs inválidos e não estruturados não são lidos facilmente por máquinas e não podem impulsionar a automação.
• Ferramentas externas resolvem a observabilidade, mas aumentam a carga de gerenciamento: plataformas de rastreamento de experimentos como MLflow e Weights & Biases são excelentes no que fazem. No entanto, elas exigem infraestrutura adicional para implantação e manutenção, além de chaves de API e controles de acesso. Elas também operam acima da camada da plataforma. Elas também são desconectadas da API do Kubernetes, dificultando a integração com fluxos de trabalho nativos e operadores personalizados. Essas ferramentas informam o que ocorreu no loop de treinamento, mas não comunicam à plataforma o que está acontecendo no momento.
• Cada framework opera de maneira diferente: PyTorch DDP, FSDP, DeepSpeed e JAX: cada um tem convenções de log, formatos de métricas e maneiras de relatar o progresso próprios. A falta de consistência entre os frameworks impede uma visão unificada para as equipes de plataforma que gerenciam ambientes de treinamento heterogêneos.
• Não existe uma API padrão: até o momento, as tarefas de treinamento não tinham uma forma padronizada de relatar o progresso à plataforma. Como resultado, a gestão da plataforma em clusters de GPU compartilhados precisa adivinhar quais tarefas progridem, quais pararam e quais estão próximas do fim. Sem essa visibilidade, o planejamento de capacidade e a resolução de problemas baseiam-se em suposições.

Desafio superado: acompanhamento de progresso no Red Hat OpenShift AI

O Red Hat OpenShift AI agora inclui rastreamento de progresso pronto para produção para tarefas de treinamento distribuído, integrado ao Kubeflow Trainer v2 e disponível a partir da versão 3.4. Acompanhe o que está acontecendo em tempo real e aja antes que seja tarde demais. Este recurso aborda a lacuna de observabilidade, oferecendo a cientistas de dados, engenharia de ML e gestão de plataforma visibilidade em tempo real do desempenho dos treinamentos.

Esta visibilidade baseia-se em três pilares:

1. Visualização no dashboard: as métricas de progresso em tempo real estão visíveis diretamente no dashboard do Red Hat OpenShift AI. Veja rapidamente a porcentagem de progresso, etapa atual e total, época atual, tempo restante estimado, perda de treinamento e métricas de avaliação para seus TrainJobs. Sem ferramentas separadas ou configurações adicionais.
2. Integração de SDK: os mesmos dados de progresso estão disponíveis programaticamente pelo SDK do Kubeflow. Isso permite criar pipelines automatizados que reagem ao progresso do treinamento, acionando a interrupção antecipada, enviando notificações ou realocando recursos com base em métricas em tempo real.
3. Consistência entre frameworks: o rastreamento de progresso funciona da mesma forma com PyTorch DDP, FSDP, DeepSpeed ou JAX. A solução também oferece suporte a código de treinamento personalizado pela API CustomTrainer. Isso proporciona uma experiência única e unificada entre os frameworks.

Visualize seu treinamento em movimento

A melhor maneira de entender o rastreamento de progresso é demonstrar seu funcionamento na prática. Três etapas são fundamentais.

1. Inicie a tarefa de treinamento: Envie uma tarefa de treinamento de um notebook usando o SDK do Kubeflow, como de costume. Ao usar o HuggingFace Transformers, o rastreamento de progresso é automático, sem necessidade de alterar o código. A integração detecta o ambiente Kubeflow e começa a relatar as métricas do loop de treinamento.
2. Acompanhe o progresso: durante a execução, métricas em tempo real aparecem no dashboard do Red Hat OpenShift AI: porcentagem de progresso, tempo restante estimado, etapas concluídas, épocas, norma de gradiente, perda de treinamento e taxa de aprendizado. Sem monitoramento de logs, acesso via SSH aos pods ou configuração de ferramentas externas.

Figura 1: O dashboard do Red Hat OpenShift AI exibe uma lista de tarefas com uma barra de progresso indicando 40% de conclusão de um TrainJob em execução.

Figura 2:  Painel lateral detalhado com o progresso da tarefa e métricas em tempo real.

3. Aja com base nos dados: é aqui que o rastreamento de progresso economiza tempo e computação. A perda não está melhorando? Interrompa a tarefa antecipadamente e economize horas de GPU. A execução está convergindo mais rápido do que o esperado? Libere recursos para sua equipe. Saiba exatamente quando uma tarefa terminará para se planejar. Chega de dúvidas se os resultados estarão prontos para a revisão com stakeholders na terça-feira.

Principais características práticas:

• Configuração zero: sem infraestrutura adicional, dependências externas ou configurações extras. O rastreamento de progresso funciona instantaneamente.
• Sobrecarga mínima: as métricas são relatadas em checkpoints naturais, sem afetar o desempenho do treinamento.
• Compatibilidade entre frameworks: a experiência é a mesma com PyTorch DDP, FSDP, DeepSpeed, JAX ou código personalizado.

Quem se beneficia

Cientistas de dados e engenharia de ML/IA visualizam perda de treinamento, porcentagem de progresso e ETA em tempo real, sem SSH ou monitoramento de logs. Detectar divergências ou interrupções precocemente economiza horas de GPU, como ao identificar uma tarefa travada no sábado de manhã em vez de na segunda-feira. Compare treinamentos rapidamente no dashboard para identificar a melhor configuração de hiperparâmetros.

A gestão da plataforma tem uma visão unificada de todas as tarefas de treinamento no cluster. Visualize métricas consistentes, independentemente do uso de DDP, FSDP ou DeepSpeed, e tome decisões de planejamento de capacidade mais precisas.

Em ambientes de GPU multitenant com compartilhamento de cluster, essa visibilidade melhora o uso de recursos e o ROI. Para organizações que criam um modelo de GPU-as-a-Service, o rastreamento de progresso resolve uma lacuna crítica, tornando a "caixa-preta de uso da GPU" um sistema observável. Isso capacita as equipes de plataforma a remover gargalos de infraestrutura e fornecer os recursos necessários para acelerar a inovação em IA.

Além do monitoramento: crie uma base para treinamentos mais inteligentes

O rastreamento de progresso é mais do que um recurso de monitoramento: é uma base. Após a plataforma acessar dados de progresso em tempo real, diversos comportamentos inteligentes tornam-se possíveis. Embora estes recursos avançados ainda não sejam compromissos de produtos Red Hat, a base está estabelecida. A comunidade upstream do Kubeflow Trainer explora ativamente diversas direções:

• Ajuste de hiperparâmetros mais inteligente: atualmente, mecanismos de otimização como o Katib dependem da análise de logs com padrões regex frágeis para avaliar o desempenho. Com métricas na API do Kubernetes, o Katib pode ler o status do treinamento nativamente, permitindo maior integração e eficiência. Este é o KEP em discussão na comunidade upstream.
• Escalabilidade elástica: dados de velocidade de convergência e ETA podem orientar decisões de escalonamento. Modelos com convergência rápida podem liberar GPUs, enquanto modelos estagnados podem solicitar workers adicionais. A comunidade upstream explora o suporte a PyTorch elástico no TrainJob para viabilizar essa funcionalidade.
• Visibilidade de progresso via CLI: o comando kubectl get trainjob com a coluna PROGRESS % traria o progresso do treinamento para a linha de comando, oferecendo visibilidade instantânea.
• Checkpoints mais inteligentes: Embora o OpenShift AI ofereça suporte a checkpoints de modelos periódicos e just-in-time, a plataforma poderia salvar estados automaticamente com base no ETA da tarefa. A comunidade upstream explora o checkpoint transparente de GPU com CRIU para aumentar a tolerância a falhas e a resiliência do TrainJob.

Estas são áreas de exploração no projeto Kubeflow, não compromissos de produtos. Elas ilustram a importância do rastreamento de progresso como a camada de dados para toda a stack de treinamento.

O rastreamento de progresso para treinamento distribuído está disponível no Red Hat OpenShift AI 3.4. Para mais informações, leia a documentação do Red Hat OpenShift AI. Ou experimente o Red Hat OpenShift AI testando a solução por 60 dias.