Avito cria o Aviflow: plataforma de ML para treinamento distribuído de LLMs em HGX

A Avito saiu de máquinas dedicadas com acesso por SSH e chegou ao Aviflow, plataforma cloud-native própria na qual treina grandes modelos de linguagem. Pavel, desenvolvedor sênior da plataforma de ML, trabalha com MLOps há um ano e meio. Ele apresentou uma palestra na Kuber Conf e a reescreveu como artigo no Habr. O título promete «treinamento de LLM com um clique» em servidores HGX. A parte visível do material termina na história da plataforma, então ainda não há números concretos sobre a quantidade de nós e GPUs. Em compensação, o texto descreve bem a evolução pela qual passam muitas empresas com uma equipe de ML em crescimento.

Como tudo começou: DevBox e SSH

Quando a Avito tinha poucos cientistas de dados, cada um trabalhava com seu próprio conjunto de ferramentas. A principal era o DevBox, uma máquina dedicada. O especialista entrava nela por SSH, montava datasets, treinava modelos e fazia o resto do trabalho na mão. Enquanto há poucas pessoas, o esquema é tolerável. A máquina fica atrelada a um profissional, não há conflito por recursos, e um único administrador resolve qualquer problema.

Depois, o número de especialistas e de áreas cresceu. Os colegas passaram a bloquear máquinas inteiras e a executar tarefas manualmente. As GPUs ficavam ociosas entre os treinamentos, e a fila virou uma troca de mensagens em chats.

As LLMs trouxeram mais caos

Sobre essa base, a empresa passou a trabalhar também com LLMs. Segundo o autor, a LLM tem ferramental próprio e não facilitou a vida de ninguém. O motivo fica claro pela natureza da tarefa. O modelo não cabe em uma única placa ou leva tempo demais para treinar, então são necessárias várias GPUs, muitas vezes em vários nós. Nesse cenário, o DevBox deixa de funcionar como unidade de recurso. É preciso ter um escalonador, isolamento de ambientes, execuções reproduzíveis e relatórios claros de utilização.

A resposta da Avito se chama Aviflow. É uma plataforma cloud-native em que o treinamento é descrito como uma tarefa, e não como um conjunto de ações manuais em uma máquina específica.

Por que HGX e Kubernetes

HGX é a plataforma de servidor de referência da NVIDIA, normalmente com oito GPUs conectadas por um barramento de alta velocidade NVLink via NVSwitch. Para o treinamento distribuído, a conectividade é o ponto central. Os gradientes precisam ser sincronizados rapidamente, senão as GPUs ficam esperando umas pelas outras. A palestra aconteceu na Kuber Conf, o que indica que a orquestração é construída em torno do Kubernetes e que os servidores HGX viram um pool de recursos, e não máquinas pessoais.

Principais fatos da parte disponível do material:

• Autor: Pavel, desenvolvedor sênior da plataforma de ML da Avito, há um ano e meio em MLOps.
• Plataforma: Aviflow, cloud-native.
• Antecessor: DevBox, máquinas dedicadas com acesso por SSH.
• Hardware: servidores HGX.
• Objetivo: treinamento distribuído de LLMs.
• Formato: palestra na Kuber Conf e análise no Habr, com gravação em vídeo disponível.

O que você pode aproveitar

A história da Avito mostra uma trajetória típica, e dá para usá-la para comparar com a sua própria equipe. Se os especialistas combinam o uso de GPUs por mensageiro, a plataforma já é necessária. Se é preciso SSH para iniciar um treinamento, é hora de migrar para a descrição declarativa de tarefas. Se a LLM surgiu na equipe como uma ilha separada, vale decidir desde já como as tarefas dela vão conviver no cluster compartilhado.

A ordem prática de ação é esta: primeiro um pool comum de GPUs e uma fila, depois ambientes padronizados e, por fim, execução distribuída e monitoramento. Começar pelo «botão» não faz sentido se não houver contabilização de recursos por trás dele.

Para os detalhes, incluindo a arquitetura do Aviflow, o esquema de escalonamento e os resultados, é preciso ler o texto completo no Habr ou assistir à gravação da palestra. É ali que devem estar os números de utilização e de velocidade de execução, que não aparecem na parte de divulgação.