Хабр: Машинное обучение→ original

Avito analisa seis palestras da KubeCon Japan 2026 sobre compartilhamento de GPU

Anton Alekseev, engenheiro de ML Ops da Avito, esteve na KubeCon + CloudNativeCon Japan 2026, em Yokohama, e analisou seis palestras sobre GPU e inferência de LLM. No segundo dia, ele percebeu que os slides se repetiam: espectro de isolamento de tenants, cotas, bin packing e a tese de que "GPUs são caras, então vamos compartilhar". A Avito resolve o mesmo problema e conta o que já testou e o que pretende fazer. • Seis palestras sobre GPU e inferência de LLM. • Motivo comum: aceleradores são caros, portanto é preciso compartilhá-los. • A Avito confronta a própria experiência com o que foi apresentado na conferência.

Processado por IA de Хабр: Машинное обучение; editado por Hamidun News
Avito analisa seis palestras da KubeCon Japan 2026 sobre compartilhamento de GPU
Fonte: Хабр: Машинное обучение. Colagem: Hamidun News.
◐ Ouvir artigo

Anton Alekseev, engenheiro de ML Ops da Avito, viajou a Yokohama para a KubeCon + CloudNativeCon Japan 2026 e reuniu seis palestras sobre GPU e inferência de LLM em uma única análise. No segundo dia da conferência, ele notou que os slides de palestrantes diferentes se pareciam: espectro de isolamento de tenants, cotas, bin packing e o refrão "GPUs são caras, vamos compartilhar". A Avito resolve o mesmo problema, então a comparação ficou prática: o que a empresa já testou e o que apenas pretende fazer.

O material no Habr, por enquanto, consiste só na parte introdutória. Por isso, o texto abaixo trata do contexto, e não de um resumo de cada palestra.

Um mesmo motivo em seis palestras

O fato de equipes diferentes chegarem de forma independente aos mesmos esquemas mostra que o tema amadureceu. Dois anos atrás, as GPUs no Kubernetes costumavam ser entregues inteiras: uma placa, um pod. Hoje, os aceleradores ocupam uma parte significativa do orçamento de infraestrutura, e a carga sobre eles é irregular. Treinamento e tarefas em lote ocupam a placa de forma intensa. A inferência online muitas vezes a deixa meio vazia. Daí vêm os quatro temas recorrentes:

  • isolamento de tenants: quão rígida deve ser a separação entre vizinhos na mesma placa;
  • cotas: quantos aceleradores uma equipe ou um projeto pode ocupar;
  • bin packing: como empacotar os pods nos nós de forma densa, para não criar placas parcialmente ocupadas;
  • inferência de LLM como principal consumidora, em que a memória para pesos e KV-cache esbarra no tamanho da placa.

O espectro de isolamento

Esse espectro é descrito em uma única escala: quanto mais rígida a fronteira entre os tenants, menor a utilização e maior a previsibilidade. Os pontos típicos dessa escala são conhecidos há tempos.

  • Placa inteira para um único pod: isolamento máximo, densidade mais baixa.
  • MIG em placas NVIDIA compatíveis: divisão por hardware em várias instâncias independentes, até sete por placa, com memória dedicada.
  • MPS: vários processos dividem os recursos de computação, mas o isolamento é mais fraco.
  • Time-slicing: os pods se revezam no uso da placa, e ninguém garante memória dedicada nem isolamento de falhas.

A escolha depende da carga. Para um serviço online crítico, com requisitos rígidos de latência, é mais sensato usar uma fronteira por hardware. Para experimentos internos, uma divisão mais branda costuma bastar.

Cotas e empacotamento

O isolamento define quem fica ao lado de quem. Cotas e o scheduler decidem quem recebe a placa. Na prática, é aí que se encontram filas para tarefas em lote, prioridades e preempção. O bin packing importa porque pedidos fracionados fragmentam o cluster rapidamente: sobram muitas frações livres, mas não há onde colocar um pod que precisa de uma placa inteira ou de um perfil MIG grande. Um scheduler que leva a topologia em conta e busca preencher os nós de forma densa devolve essas frações à circulação.

Segundo o autor, ele vai analisar o que, do que foi apresentado, a Avito já testou e o que está nos planos. Para o leitor, essa é a parte mais valiosa: as palestras em conferências costumam mostrar um esquema que funciona, mas raramente contam onde ele quebra com a carga de outra empresa. O relato de um engenheiro que confronta os slides com a própria produção preenche justamente essa lacuna. No fim do texto, o autor promete falar sobre o próprio Japão, então o formato fica mais próximo de um diário de viagem com um núcleo técnico.

Por onde começar numa equipe com cluster de GPU

Se você está apenas pensando em compartilhar placas, a ordem das ações decorre das próprias palestras. Primeiro, meça a utilização real: a carga das unidades de computação e a memória ocupada por serviço, e não apenas o fato de a placa ter sido alocada. Depois, separe as cargas por requisito de isolamento: inferência online, tarefas em lote, experimentos.

Para cada classe, escolha o seu ponto no espectro, sem tentar impor um regime único. Em seguida, introduza cotas por equipe e filas para tarefas em lote, e deixe a configuração do empacotamento para o fim, quando a estrutura dos pedidos já estiver clara. Por último, decida de antemão o que fazer com vizinhos barulhentos: sem métricas de latência, dividir a placa rapidamente vira fonte de degradações inexplicáveis.

A análise completa das seis palestras e a experiência da Avito estão publicadas no Habr, no artigo de Anton Alekseev.

ZK
Hamidun News
Notícias de AI sem ruído. Seleção editorial diária de mais de 50 fontes. Produto de Zhemal Khamidun, Head of AI na Alpina Digital.
✦ Unified AI Workspace

Access Frontier LLMs & Multimodal AI in One Workspace

Discover NomadNet AI (nomadnet.ai) — unified access to frontier language models, research synthesis, and multimodal workflows.

Try NomadNet AI →Launch NomadNet Agent
O que você acha?
Carregando comentários…