Agendamento de jobs de GPU usando um pool de GPUs de inferência ociosas

Agendamento de jobs de GPU usando um pool de GPUs de inferência ociosas: o caso de eficiência de infraestrutura do LG AI Research

Este texto publicado pela equipe Platform&Infra do LG AI Research aborda como recursos de GPU ociosos gerados durante a operação de serviços de grandes modelos de linguagem (LLM) foram reaproveitados em tarefas de pesquisa e experimentação. Como empresas que operam serviços de IA normalmente reservam GPUs com antecedência com base no pico de tráfego, em horários de menor movimento essas GPUs caras acabam ficando paradas, ocupando apenas memória. O instituto construiu um pipeline que aloca automaticamente essas GPUs livres em tarefas de treinamento e avaliação, obtendo recursos computacionais sem precisar comprar equipamentos adicionais.

Problema central

• Limites do auto scaling em serviços de LLM: ao contrário de serviços web comuns, em LLMs o consumo de GPU por requisição varia bastante conforme o tamanho dos tokens de entrada e saída e a estrutura do modelo. Por isso, indicadores tradicionais como uso de CPU ou ocupação de memória não conseguem medir bem a carga real.
• Escala dos recursos ociosos: em um ambiente onde uma réplica (cópia de instância de serviço) usa 4 GPUs, durante o período noturno de baixa demanda (das 20h até as 8h do dia seguinte), uma média de 52 GPUs por dia ficava ociosa por cerca de 12 horas.

Forma de resolução

• Uso de métricas internas do vLLM: em vez de métricas gerais do sistema, foram adotadas como critério de auto scaling métricas fornecidas pelo mecanismo de inferência de LLM vLLM, como throughput em tempo real e estado de espera na fila, implementando assim um ajuste de recursos mais preciso e adequado às características dos LLMs.
• Execução de tarefas no modo best-effort: tarefas de pesquisa são executadas nas GPUs ociosas à noite, mas, quando o tráfego volta a subir, essas tarefas podem ser interrompidas a qualquer momento e as GPUs retornam ao serviço, preservando a estabilidade operacional.
• Pipeline baseado em Argo Workflows: os jobs são definidos em unidades de imagem Docker, e etapas como pré-processamento de dados, pré-treinamento, ajuste fino supervisionado, aprendizado por reforço e avaliação podem ser executadas em sequência ou em paralelo.

Pontos fortes dos princípios de projeto

• Generalidade: tanto treinamento quanto inferência, em qualquer framework, podem ser executados desde que encapsulados em uma imagem Docker.
• Escalabilidade e flexibilidade: mesmo com a adição de novos tipos de tarefa, é possível absorvê-los sem alterar o código do pipeline.
• Reprodutibilidade: todas as configurações são injetadas como parâmetros externos, e entradas e saídas são gerenciadas em cloud storage, garantindo os mesmos resultados nas mesmas condições. O fato de o pipeline ter uma estrutura stateless, sem preservação de estado, também contribui para a estabilidade operacional.

Resultados operacionais

• Uso acumulado: de novembro de 2025 a janeiro de 2026, em cerca de 3 meses, foram executados 85 jobs, e o uso acumulado chegou a 95.000 GPU-horas.
• Tendência de crescimento: o uso de GPU em janeiro aumentou cerca de 70% em relação a novembro e, quando convertido para operação 24 horas, teve efeito equivalente à obtenção de 55 novas GPUs.
• Redução de custos: convertendo o mesmo volume computacional com base em um compromisso de 3 anos em nuvem pública, a economia foi de cerca de 75 milhões de won em janeiro e de aproximadamente 185 milhões de won acumulados ao longo de 3 meses.

Planos futuros

• Aprimoramento das métricas de scaling: está previsto refinar a lógica de alocação de recursos com uma segmentação mais detalhada dos padrões de uso por serviço.
• Expansão para agendamento contínuo: com Kubernetes e o modelo próprio EXAONE, a ideia é expandir para um sistema contínuo que execute tarefas não apenas à noite, mas sempre que houver recursos livres.
• Melhoria de UX: há planos de criar uma interface para que pesquisadores possam solicitar e monitorar tarefas de forma intuitiva.

Este caso traz implicações relevantes por mostrar uma tentativa de resolver um desafio comum do setor — a escassez de GPUs — não com expansão de hardware, mas com melhorias na estrutura operacional. Chama atenção especialmente a forma como a dificuldade de medir carga em serviços de LLM foi contornada com métricas internas do vLLM, enquanto as tarefas de pesquisa foram tratadas em modo best-effort para equilibrar, ao mesmo tempo, estabilidade do serviço e aproveitamento de recursos. O resultado quantitativo, com economia de cerca de 180 milhões de won sem investimento adicional, apresenta um modelo operacional que pode servir de referência para outras organizações que operam infraestrutura de GPU.