A GPU falhou. O treinamento continuou: treinamento com autorrecuperação em escala — Crusoe

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: GPU Died. Training Didn’t: Self-Healing Training at Scale — Crusoe · Canal: AI Engineer · 16:12 · Assistir no YouTube

Tópicos: Infraestrutura e hardware de IA

Resumo

A Crusoe combina Slurm e Kubernetes para oferecer uma plataforma de treinamento de IA que automatiza a resposta a falhas críticas de hardware. A arquitetura mantém a experiência familiar para equipes de machine learning e, ao mesmo tempo, aproveita os recursos de resiliência e observabilidade do Kubernetes. Quando uma GPU falha, o sistema interrompe o nó afetado, substitui-o por outro saudável e reinicia o job a partir do checkpoint, sem exigir intervenção do usuário. Na demonstração, a substituição do nó levou cerca de cinco minutos, e o tempo total de indisponibilidade foi inferior a 15 minutos.

Pontos-chave

• Falhas de GPU são inevitáveis em workloads de treinamento distribuídos por milhares de GPUs, tornando a correção manual insustentável.
• Slurm oferece recursos importantes para treinamento, como agendamento de jobs em grupo, consciência de topologia e comunicação coletiva entre nós.
• A execução de Slurm sobre Kubernetes combina o agendamento de alto desempenho do Slurm com a resiliência, a observabilidade e o ecossistema do Kubernetes.
• O serviço gerenciado da Crusoe integra Slurm à infraestrutura existente, sem exigir que equipes de machine learning alterem seus fluxos de trabalho.
• O Autoclusters detecta falhas críticas, drena e remove o nó afetado e o substitui por um nó saudável.
• Antes da substituição, processos recebem um sinal SIGTERM e têm até dois minutos para salvar checkpoints ou descarregar logs.
• Após a substituição do nó, o job é executado novamente e pode retomar o treinamento a partir do checkpoint.
• O uso de uma única infraestrutura permite realocar GPUs entre treinamento e inferência conforme a demanda.

Capítulos

Início	Capítulo	Resumo
00:01	Contexto e arquitetura da Crusoe	Os apresentadores introduzem o desafio das falhas de GPU em larga escala e explicam a combinação de Slurm, Kubernetes e Autoclusters.
03:11	Pontos fortes e limitações do Slurm tradicional	A apresentação aborda os recursos do Slurm para treinamento e os desafios de operação, flexibilidade e observabilidade em workloads modernos.
06:20	Slurm gerenciado sobre Kubernetes	A Crusoe explica como integra Slurm ao Kubernetes para reduzir a complexidade operacional e compartilhar recursos entre treinamento e inferência.
10:03	Fluxo de autorrecuperação e demonstração	O Autoclusters detecta um erro XID79, substitui o nó afetado e permite que o job retome o treinamento a partir do checkpoint.
13:08	Provisionamento simplificado e principais conclusões	Os apresentadores mostram o provisionamento com um comando e resumem como a arquitetura mantém a operação familiar enquanto automatiza a recuperação.

Citações

Em escala, a correção manual é completamente insustentável. — 00:31

Não é necessária nenhuma ação do usuário. — 10:03

O job do Slurm será reiniciado, carregará o checkpoint e continuará o treinamento de onde parou. — 12:37

As falhas são inevitáveis. — 15:42

Conceitos e entidades

• Crusoe (empresa): Empresa que fornece infraestrutura de computação e serviços gerenciados de Kubernetes e Slurm para workloads de IA.
• Slurm (ferramenta): Sistema de gerenciamento e agendamento de jobs usado em computação de alto desempenho e treinamento distribuído.
• Kubernetes (ferramenta): Plataforma de orquestração de workloads que oferece recursos como observabilidade, escalabilidade e recuperação de serviços.
• Slinky (repo): Projeto open source oficial da SchedMD para executar Slurm sobre Kubernetes.
• Autoclusters (ferramenta): Sistema da Crusoe que detecta erros críticos de hardware e substitui automaticamente nós de GPU com falha.
• CMK (ferramenta): Serviço gerenciado de Kubernetes da Crusoe, sobre o qual é construído o serviço gerenciado de Slurm.
• PyTorch (ferramenta): Framework usado na demonstração para executar um script de treinamento.
• XID79 (conceito): Erro crítico de GPU apresentado na demonstração, que aciona o processo de substituição do nó.
• Connor (pessoa): Developer advocate da Crusoe que apresenta a conversa e demonstra o fluxo de autorrecuperação.
• Nikil (pessoa): Colega de Connor na Crusoe que apresenta o serviço gerenciado de Slurm.
• Young (pessoa): Colega de Connor na Crusoe que explica os pontos fortes e as limitações do Slurm tradicional.

Tradução completa (pt-BR)

00:01 [música] Certo. Olá a todos. Meu nome é Connor. Sou defensor de desenvolvedores na Crusoe e estou aqui com meus colegas Nikil e Young. Hoje vamos falar sobre a infraestrutura que construímos na Crusoe e como ela lida com erros críticos de hardware. Quando nossos clientes executam cargas de trabalho de treinamento em escala extremamente grande, distribuídas por milhares de GPUs…

00:31 …as falhas de GPU são inevitáveis. Em grande escala, a correção manual é completamente insustentável. Hoje vamos explicar como, usando Slurm e Kubernetes, podemos oferecer uma plataforma robusta com correção automatizada, que seja fácil de usar tanto para engenheiros de machine learning que executam jobs quanto para as equipes de plataforma que gerenciam os clusters subjacentes. Para dar um pouco mais de contexto sobre o que é a Crusoe Cloud, para quem ainda não nos conhece…

01:02 …oferecemos infraestrutura como serviço, composta por computação, armazenamento, rede e as GPUs de última geração da Nvidia e da AMD. Mas o foco desta palestra será nas ferramentas que construímos sobre essa infraestrutura para orquestrar grandes frotas de GPUs, incluindo nosso serviço gerenciado de Kubernetes, chamado CMK, e nosso serviço gerenciado de Slurm, construído sobre o CMK e baseado no Slinky, projeto oficial open source da SchedMD para executar…

01:35 …Slurm sobre Kubernetes. Isso nos permite combinar o agendamento de jobs de alto desempenho do Slurm com os recursos de resiliência da infraestrutura e de observabilidade do Kubernetes, incluindo um dos sistemas que desenvolvemos, chamado Autoclusters, que detecta e substitui automaticamente nós com falhas de GPU quando uma falha é detectada. Para explicar como e por que chegamos a essa arquitetura, é útil entender em que o Slurm tradicional se destaca e…

02:07 …em que deixa a desejar, assunto que Young vai abordar agora. >> Obrigado, Connor. Tradicionalmente, quer dizer, olhando pela perspectiva tra… >> Desculpem, conseguem me ouvir agora? Certo, ótimo. Vou fazer assim. Basicamente, o Slurm foi criado por pesquisadores, para pesquisadores, em universidades e laboratórios, há mais de 20 anos. Foi desenvolvido para computação de alto desempenho, que, como…

02:38 …observamos com nossos clientes e outras pessoas que usam Slurm hoje, se traduz muito bem para a IA moderna, especificamente para cargas de trabalho de treinamento. A ideia é que, ao executar um job de treinamento com vários nós, é preciso ter uma comunicação coletiva estreita entre os ranks que estão sendo usados. Isso inclui redes específicas para cargas de trabalho de treinamento. Conceitos como agendamento em grupo, consciência da topologia, prologue e epilog para…

03:11 …validações de cluster. Todos esses recursos estão prontamente disponíveis no Slurm hoje e ajudam pesquisadores a executar seus jobs, essencialmente usando ferramentas que já conhecem: scripts, especialmente… no cluster. Agora, onde achamos que ele deixa um pouco a desejar no treinamento moderno são os aspectos que vocês veem na tela neste momento. As cargas de trabalho de treinamento de IA…

03:44 …de hoje são muito dinâmicas, e não se limitam ao treinamento. Há muitos outros aspectos das cargas de trabalho de IA que seus laboratórios de IA e outras empresas executam, incluindo treinamento, pós-treinamento, evals e inference. Algumas dessas tarefas talvez nem sejam executadas no seu cluster Slurm hoje. Mas, devido ao que observamos em termos de restrições de capacidade de GPU e outros fatores, vocês acabam limitados na capacidade de adaptar dinamicamente os recursos disponíveis. O Slurm…

04:14 …tradicionalmente é bastante estático, tanto no particionamento quanto em outras funcionalidades. Outra coisa que quero mencionar é a questão das verificações de integridade e da manutenção dos nós. É possível verificar se os nós estão saudáveis. As GPUs falham; como lidar com isso? O Slurm obviamente oferece recursos para isso, como recolocar os jobs na fila e detectar nós defeituosos, usando coisas como prologue e outras ferramentas open source que agora estão…

04:44 …disponíveis para fazer isso. Mas isso acrescenta uma carga operacional, como temos visto com os clientes. É preciso detectar se há nós com problemas, drená-los quando isso acontece e encontrar maneiras de contornar a situação. Isso pode ser feito manualmente ou exige algum tipo de automação ou script para dar conta de tudo. O último ponto é a observabilidade. Os jobs podem falhar. Também podem apresentar desempenho degradado por vários motivos. Uma falha de GPU é apenas um…

05:16 …deles. Há também problemas como instabilidade de rede e outros problemas nos switches que podem causar degradação ou falha de desempenho. O Slurm sabe quando um job falha, mas não necessariamente consegue dizer tudo sobre o motivo da falha. É aí que a observabilidade tem um papel fundamental. Tudo isso explica por que construímos o produto que Nikil vai apresentar e sobre o qual vai explicar alguns detalhes do Slurm gerenciado.

05:49 Certo, obrigado, Young. Vou falar sobre nosso produto Crusoe Managed Slurm. Como mencionamos, o Slurm oferece muitos benefícios às equipes de treinamento e aos pesquisadores que estão criando os próximos melhores modelos. Mas há alguns problemas para configurar o Slurm, gerenciá-lo e mantê-lo confiável. Por outro lado, vocês…

06:20 …têm o Kubernetes, que é o sistema operacional da nuvem, amplamente usado e conhecido. É um ecossistema muito maduro, com muitas ferramentas, extensões e plugins para tudo que vocês precisarem adicionar, seja observabilidade, rede ou segurança. Ele ajuda a manter os serviços com autorrecuperação integrada, balanceamento de carga e escalonamento automático, que mantêm tudo funcionando sem problemas. Por isso, muitas vezes vemos clientes que chegam até nós começando, por exemplo, com…

06:51 …inference no Kubernetes e depois querem expandir para treinamento, ou vice-versa. Talvez uma equipe familiarizada com Kubernetes tenha dificuldade para implantar e gerenciar um cluster Slurm. Ou a equipe de treinamento que já conhece Slurm não esteja familiarizada com os frameworks de Kubernetes existentes, o que cria atritos adicionais e acaba atrasando a equipe, especialmente com todo mundo tentando chegar o mais rápido possível ao próximo melhor modelo e ao próximo melhor produto.

07:23 As equipes configuram suas ferramentas conhecidas, e vocês acabam com duas pilhas de infraestrutura separadas, o que traz uma série de encargos operacionais adicionais e custos extras. Então, decidimos criar nosso Crusoe Managed Slurm sobre o Kubernetes. Temos nosso operador Slurm da Crusoe, que se coordena com nossa plataforma gerenciada de Kubernetes da Crusoe e com a Crusoe Cloud em geral, incluindo armazenamento, rede etc. E a Crusoe gerencia…

07:54 …os usuários do Slurm, as partições do Slurm, as configurações e o armazenamento. Assim, vocês não precisam fazer tudo peça por peça. Com um único comando, criam o cluster Slurm e pronto: ele está funcionando dentro do cluster Kubernetes. Para quem usa Slurm, o benefício é que se trata apenas de mais um cluster Slurm. Só precisam de um endereço IP para acessar por SSH com seu usuário e, para eles, é um cluster Slurm com todos os recursos de que precisam. Nem precisam saber que o Kubernetes está rodando por baixo. Para a equipe de plataforma e a equipe de infraestrutura, o…

08:26 …benefício é que o Slurm passa a ser apenas mais um serviço conectado à infraestrutura existente. Não é preciso configurar uma pilha de infraestrutura totalmente nova, novas ferramentas de observabilidade, novas equipes de plantão, novos runbooks, nada disso. Tudo está integrado ao mesmo ambiente. Ele funciona junto com todos os outros serviços e recursos do Slurm. Os jobs usam o agendamento com consciência da topologia integrado, e a equipe de plataforma o vê apenas como mais um serviço. E, agora que todas as GPUs e…

08:58 …o hardware estão em um único cluster, podem ser movidos sem dificuldade. Isso permite ferramentas mais interessantes e disponibilidade dinâmica. Por exemplo, quando for necessário aumentar a capacidade do serviço de inference devido ao aumento do número de usuários, vocês podem retirar parte do hardware do cluster de treinamento ou até realocá-lo para o serviço de inference, ou vice-versa. Quando a carga de usuários diminui, todas essas GPUs ficam ociosas. Esse é o momento perfeito para aumentar…

09:30 job de treinamento ou fazer uma execução maior, de ponta a ponta, em mais GPUs. Isso só é possível quando tudo está em uma única pilha de infraestrutura, como o Crusoe Managed Slurm. Um benefício adicional é que agora o Crusoe Managed Slurm pode usar nosso produto AutoClusters, que faz a remediação automática de erros adicionais de hardware. Então Connor vai explicar isso e mostrar uma demonstração de como funciona.

10:03 Esta é uma visão geral do que acontece exatamente quando o AutoClusters detecta um erro crítico de hardware. Neste caso, um erro XID79, em que uma das GPUs fica completamente inutilizável. A primeira coisa que acontece é que o usuário recebe uma notificação, embora não precise tomar nenhuma providência. Em seguida, o operador do Slurm define aquele nó específico como indisponível e cancela todos os jobs em execução. Então, o processo recebe um sinal SIGTERM antes de ser

10:33 encerrado, e você tem até dois minutos para lidar com esse SIGTERM e salvar seus checkpoints ou descarregar seus logs antes que aquele nó seja substituído. O job cancelado é colocado automaticamente na fila novamente, e então o AutoClusters é iniciado. Primeiro, ele verifica se há algum pod no nó com um rótulo que desative a substituição automática. Se o nó puder ser substituído, o nó do Kubernetes é então isolado e drenado. Em seguida, o nó não saudável é

11:04 removido do pool de nós e substituído por um novo nó saudável, vindo da capacidade de reserva. Depois, um registro do alerta e da remediação é criado para consulta do usuário. Mas o usuário ainda não precisa tomar nenhuma providência. Quando esse nó saudável volta a ficar online, o job do Slurm é iniciado. O código da aplicação é executado para carregar o modelo e o checkpoint e retomar o treinamento. E é assim que isso fica

11:35 em uma demonstração. À esquerda, estou usando o sbatch para iniciar um script de treinamento em PyTorch. À direita está o console da nuvem da Crusoe, onde tenho um pool de nós de GPU com dois nós A100. Vou iniciar isso normalmente. Em seguida, vou executar um script para informar ao nosso sistema interno de monitoramento do backend que ocorreu um erro XID79 em uma das GPUs. Isso vai acionar o AutoClusters. E então podemos

12:07 ver que a utilização da GPU cai imediatamente. Assim, sabemos que aquela GPU ficou offline, e a substituição do nó pelo AutoClusters começa na mesma hora. Com o AutoClusters, o processo completo, desde a detecção de um erro crítico de hardware até a volta de um nó saudável ao pool de nós, leva cerca de cinco minutos. O restante do tempo é principalmente gasto com código no nível da aplicação. Neste exemplo, o processo leva um pouco menos de 15 minutos

12:37 de ponta a ponta. Aqui, estou mostrando alguns dos alertas que o usuário recebe quando ocorre um erro crítico de hardware como esse. Como vocês vão ver, o usuário não precisa tomar nenhuma providência. O job do Slurm será reiniciado. Ele carregará o checkpoint e continuará o treinamento de onde parou. E podemos ver que a utilização da GPU volta ao normal. O tempo total de inatividade é inferior a 15 minutos. Isso é muito melhor do que um engenheiro ter que fazer login no meio da

13:08 noite e passar horas depurando algum problema. Tudo isso é tratado automaticamente na nossa plataforma. Historicamente, porém, tem sido difícil criar esse tipo de ambiente combinando Slurm e Kubernetes. Por isso, estamos muito animados para anunciar o que chamamos de Slurm com um clique, em que tudo o que abordamos nesta apresentação, todo esse ambiente, pode ser provisionado com apenas um comando. E esse comando inclui

13:39 o provisionamento do cluster Kubernetes subjacente, do controlador do Slurm, dos nós de login e do armazenamento. Depois disso, adicionar um pool de nós de GPU exige apenas mais um comando. Isso significa que os engenheiros podem simplesmente se conectar por SSH e começar a executar jobs imediatamente, com o AutoClusters ativado por padrão. Para recapitular o que abordamos, começamos pelas limitações do Slurm tradicional: ele oferece agendamento de jobs de alto desempenho, mas não a

14:10 recuperação automática que a infraestrutura moderna de IA exige. Ao criar o Slurm sobre o Kubernetes, podemos habilitar esses recursos avançados sem que nenhuma das equipes precise mudar seus workflows. Depois, abordamos todo o fluxo de remediação do nó, desde a detecção de um erro até a retomada do job do Slurm, do checkpoint e do treinamento. As principais conclusões são: primeiro, tradicionalmente, o Slurm e a infraestrutura em que ele é executado são dois

14:41 sistemas separados. Mas, com o Kubernetes, os dois sistemas permanecem sincronizados. Assim, um nó de GPU com falha pode ser isolado automaticamente, e esse sinal será propagado diretamente para o operador do Slurm. Além disso, como mencionei antes, nem as equipes de plataforma nem as equipes de machine learning precisam mudar seus workloads. Os pesquisadores ainda podem usar os mesmos comandos para iniciar o Slurm. E, embora o Kubernetes esteja sendo executado

15:12 por baixo, os pesquisadores nunca precisam se conectar por SSH a um pod nem se preocupar com contêineres, enquanto a equipe de Kubernetes continua tendo acesso ao mesmo nível de telemetria e observabilidade a que está acostumada. Por fim, como Nicole mencionou, os nós de GPU são, antes de tudo, nós do Kubernetes. Isso significa que o Slurm é apenas um workload em execução sobre eles. Quando um job do Slurm termina, esses nós de GPU não precisam ficar ociosos esperando por

15:42 outro job. Você pode agendar pods de inference neles imediatamente por meio do Kubernetes, porque, do ponto de vista da plataforma, eles continuam sendo apenas nós de um pool. A ideia central é que as falhas são inevitáveis. No cenário atual da IA, a arquitetura da infraestrutura deve ser projetada de modo que, quando ocorrer um erro crítico, todas as ações necessárias sejam realizadas de forma autônoma e os

16:12 engenheiros possam se concentrar em desenvolver suas aplicações, sem se preocupar com a infraestrutura. Espero que esta apresentação tenha sido informativa. Se tiverem alguma pergunta, fiquem à vontade para falar conosco no estande UG12 ou nas redes sociais, em crusadev. Obrigado por ouvirem, e fiquem à vontade para fazer perguntas. Obrigado.

Transcrição original

[00:01] [music] All right. Hello everyone. Uh, my name is Connor. I’m a developer advocate at Crusoe and I’m joined by my colleagues Nikil and Young. And we’re going to be talking today about the infrastructure we’ve built at Crusoe and how it handles critical hardware errors. And so our customers when they’re running extremely largecale training workloads across

[00:31] thousands of GPUs, GPU failures are inevitable. And so at scale, manual remediation is completely unsustainable. And so what we’ll cover today is how by using both Slurm and Kubernetes, we can provide a robust platform with automated remediation that maintains ease of use for both machine learning engineers running jobs and the platform teams managing the underlying clusters. So to provide a little bit more context on what Cruso cloud is for those of you

[01:02] who haven’t heard of us um we provide infrastructure as a service consisting of compute storage networking and the latest gen GPUs from Nvidia and AMD but the focus of this talk will be on the tooling that we’ve built on top of that to orchestrate these large fleets of GPUs including our managed Kubernetes service called CMK and our manage slurm service which is built on top of CMK and built off of Slinky which is SCADMD’s official open source project for running

[01:35] slurm on top of Kubernetes and this allows us to get the high performance job scheduling of slurm with the infrastructure resilience features and observability of Kubernetes including one of the systems we’ve developed called autoclusters which is our system for automatically detecting and replacing failed GPU nodes when a GPU failure has been detected. And so to explain how and why we landed on this architecture, it’s helpful to understand where traditional slurm both excels and

[02:07] falls short, which Young will get into now. >> Thanks, Connor. Um, traditionally, I mean, looking at it from the tra traditional perspective, >> sorry, can can you hear me now? Okay, cool. I I’ll just do it like this. But basically, traditionally, slurm was built slurm was built by the researchers for the researchers, universities, labs over 20 years ago. Uh built for high performance computing uh which as we’ve

[02:38] observed with our customers and others that are using slurm today translates very well to modern AI specifically around training workloads. this idea that when you’re running a multi-node training job, you need this idea of tight collective communication across the ranks that that you’re using. Uh including, you know, specific network built for training workloads today. Um concepts like gang scheduling, topology awareness, uh prologue and epilog for

[03:11] cluster validations. These are all the features that are readily available with slurm today that helps researchers run their jobs. Uh essentially running their jobs with tools that are already familiar to them. Scripts, especi cluster today. Now, where we feel like this is a bit of a shortcoming or short falls a little bit short around the modern training is the things that you see on the screen right now. Um AI training workloads

[03:44] today are very dynamic and it doesn’t just include training. Uh there’s a lot of other aspects that your AI labs and other companies are running as part of your your AI workloads including training post-training eval inferences some of which may or may not even land on your slurm cluster today. But because of of what we’ve observed as as a GPU capacity constraints and other things kind of limits you to how you need to be able to be more dynamic around the resources that you have. Uh slurm

[04:14] traditionally is pretty static and it’s partitioning and other other uh functionalities. The other thing I want to mention is this idea of health checks and maintaining your nodes. Uh you know you can make sure your nodes are healthy or not healthy. GPUs do fail, how do you manage that? Uh, SlurpM obviously has features around it to be able to, you know, reue the jobs, uh, detect bad nodes, uh, using things like prologue and other open source tools that are now

[04:44] available to be able to do this. It just adds an operational burden, uh, that we’ve seen from customers today. you know, this idea that you have to detect if nodes are bad, you have to drain the nodes when they’re bad, you have to kind of work around that. That could either be manual or you need some sort of an automation or scripting to be able to do all of this. And the last thing is observability. Um, you know, jobs can fail. Jobs could also come with degraded performances for any number of reasons. I mean, GPU failure is just one

[05:16] of them. there’s other things like network flaps and other things within your your switches that may be causing degraded or failed performance. Uh slurm knows when a job fails. It doesn’t necessarily be able to tell you everything about why it failed. And that’s where the observability comes into key uh key play. So all of this kind of encompasses the reason why we we built this product that Nikil is going to go over and sort of describe some of the specifics around manage slur.

[05:49] Um all right uh thanks young. So yeah, I’m going to be talking about our Cruso manage slurm product and uh like like we’ve mentioned before um there’s a lot of benefits uh that slurm can bring to the uh training teams and uh researchers that are building the next best models but there are some issues with you know setting up slurm managing it keeping it reliable uh and on the other hand you

[06:20] have kubernetes which is the OS of the cloud It’s widespread use and familiarity. It’s a very mature ecosystem with lots of tools, extensions, and plugins for whatever you need to add, whether it be observability, networking, security. It helps uh maintain services with there, you know, built-in safe healing, uh load balancing and autoscaling that keeps everything running smoothly. And so we often see that uh customers will uh come with us starting with say

[06:51] inference running on Kubernetes and then they want to expand to training uh or vice versa. And so maybe a Kubernetes familiar team struggles with deploying and managing a slurm cluster. Um or uh the incoming slurm native training team is unfamiliar with the existing Kubernetes frameworks uh and adds you know additional friction that just slows down your team and with you know how fast everyone’s trying to get to uh the next best model and next best product.

[07:23] um teams get set up with the tools they’re familiar with and you end up with two separate infrastructure stacks which has its own host of extra operational burdens uh and extra costs. So we decided to build out our Cruso managed slurm uh on top of Kubernetes. So we have our Cruso slurm operator uh which coordinates with our Cruso managed Kubernetes platform and the broader Cruso cloud. So including storage, networking etc. And uh cso manages uh

[07:54] slurm users, slurm partitions, configurations and storage. So you don’t have to do it peacemeal. You just you know one one command you create your slurm cluster and there it is existing in your kubernetes cluster. So the benefit is for the slurm users um it’s just another slurm cluster. They just need uh an IP address they can SSH with their uh user and now to them it’s a slurm cluster with all the bells and whistles that they need. They don’t even need to know that Kubernetes is running underneath. For your platform team and your uh infrastructure team, uh the

[08:26] benefit is slurm is now just another service that plugs into your existing infrastructure. You don’t need to set up an entirely new infrastructure stack, new observability tools, new you know on call teams, new runbooks, nothing like that. It’s all built into the same thing. It runs alongside all your other services and um resources in slurps. any jobs make use of the uh built-in topology aware scheduling um and the platform team just sees it as another service um and now since all your GPUs and

[08:58] hardware are in one cluster they can move around seamlessly uh it enables uh more interesting uh tooling and dynamic availability like when you need to burst your uh inference service when you’re reaching uh high uh users high number of users you can take away some some of your or even reallocate some of your hardware from your training cluster to your inference service or vice versa. You know, when your user uh load goes down, you have all these GPUs sitting idle. That’s the perfect time to up your

[09:30] training job or do a a larger hero run across more GPUs. Um this is something that’s only possible when you have everything in a single uh infrastructure stack like uh cru managed slurm. Um an additional benefit is uh now crucial managetorm can make use of our autoclusters product which is our auto remediation for additional hardware errors. So Connor is uh going to walk through that and show a demo of uh of how that works.

[10:03] So this is an overview of what exactly happens when autoclusters detects a critical hardware error. in this case an XID79 error where one of the GPUs is completely unusable. And so the first thing that happens is that the user is notified although there’s no action required from them. Then the slurm operator sets that that specific node to down and cancels any running jobs. There’s then a uh the process re receives a sig term signal before being

[10:33] terminated and you have up to two minutes to handle that sig term to either save your checkpoints or flush your logs before that node is eventually replaced. The cancel job is automatically reued and then autoclusters start. So first it verifies that no pods on the node have a label that disables automatic replacement. Assuming that node can be replaced, the Kubernetes node is then cordoned and drained. And then the unhealthy node is

[11:04] removed from the node pool and replaced with a new healthy node from spare capacity. And then a record of the alert and the remediation is logged for the user’s reference. Uh but there’s still no action required from them. And then once that healthy node comes back online, then the slurm job starts. Your application code runs to load your model and load your checkpoint and resume training. And so here’s what that looks like um

[11:35] in a demo. And so here on the left, I’m just using sbatch to launch a PyTorch training script. On the right is the Cruso cloud console where I have a GPU node pool of two A100 nodes. And I’m going to launch this as normal. Um, and then what I’m going to do is run a script in to tell our backend internal monitoring system that there’s been an XID79 error on one of the GPUs. And this will trigger autoclusters. And so we can

[12:07] see immediately the GPU utilization drops. And so we know that that that GPU has gone offline and autocluster’s node replacement starts immediately. And the full process from detecting a critical hardware error to getting a healthy node back into the node pool takes roughly five minutes with autoclusters. The rest of the time is mainly application level code. And so in this example, it’s a little under 15 minutes

[12:37] um from end to end. And here I’m just showing some of the alerts that uh the user receives when there’s a critical hardware error like this. So as you’ll see um there’s no action required from the user. The slurm job will restart. It’ll load the checkpoint and continue training where it left off. And we can see the GPU utilization returns back to normal. And the total downtime is less than 15 minutes. And this is um much better than having an engineer have to log on in the middle of

[13:08] the night and spend hours debugging something. All of this is handled automatically on our platform. Now, historically, creating this type of environment has been challenging to merge both Slurm and Kubernetes. And so we’re really excited to announce what we call one-click slurm where everything that we’ve talked about in this presentation, this entire environment can be provisioned with with just a single command. And so this one command includes

[13:39] provisioning the underlying Kubernetes cluster, the slurm controller, login nodes and storage. And then adding a GPU node pool is only one command beyond that. And so this means that engineers can simply SSH in and start running jobs immediately and autoclusters is enabled by default. So wrapping up what we covered um starting with the limitations of traditional slurm it gives you the high performance job scheduling but not the

[14:10] automated the automated healing that modern AI infrastructure requires. And so by building slurm on top of Kubernetes, we can enable these advanced advanced features without having either team change uh their workflows. Then we covered the full node remediation flow from an error being detected to the slurm job resuming and the checkpoint and the training resuming. And so the key takeaways here first is that traditionally slurm and the infrastructure that it runs on are two

[14:41] separate systems. But together with Kubernetes, both systems stay in sync and so a failed GPU node can get cord in automatically and that signal will propagate directly to the slurm operator. Also, like I mentioned earlier, neither the platform teams nor the machine learning teams have to change their workloads. Researchers can still use the same commands to launch slurm. And although Kubernetes is running

[15:12] underneath, researchers never have to SSH into a pod or worry about containers, but the Kubernetes team still get access to the same level of telemetry and observability that they’re used to. And then lastly, like Nicole mentioned, the GPU nodes are Kubernetes nodes first. And that means that slurm is just a workload running on top. And when a slurm job finishes, those GPU nodes don’t have to sit idle waiting for

[15:42] another job. You can schedule inference pods on those immediately through Kubernetes because from the platform’s perspective, they’re still just nodes in a pool. And so the core idea here is that failures are inevitable. Um and so in today’s AI landscape, the architecture of infrastructure should be designed in a way so that when there is a critical error, all the right actions are handled autonomously and

[16:12] engineers can focus on building their application and not worrying about their infrastructure. So hopefully this was an informative talk. Um, if you have any questions, feel free to um, connect with us at booth ug12 or on social at crusadev. And uh, thank you for listening and feel free to ask any questions. Thanks.