Planification de jobs GPU à partir d’un pool de GPU d’inférence inactifs

Planification de jobs GPU à partir d’un pool de GPU d’inférence inactifs : cas d’optimisation de l’infrastructure du LG AI Research

Cet article publié par la Platform&Infra Team de LG AI Research explique comment des ressources GPU inactives, générées lors de l’exploitation de services de grands modèles de langage (LLM), ont été réutilisées pour des tâches de recherche et d’expérimentation. Les entreprises qui exploitent des services d’IA réservent généralement des GPU à l’avance en se basant sur les pics de trafic ; lorsque le trafic baisse, ces GPU coûteux restent inutilisés en occupant seulement de la mémoire. L’institut a mis en place un pipeline qui assigne automatiquement ces GPU disponibles à des tâches d’entraînement et d’évaluation, obtenant ainsi des ressources de calcul supplémentaires sans achat d’équipement additionnel.

Problème central

• Limites de l’auto-scaling pour les services LLM : contrairement aux services web classiques, pour les LLM la consommation GPU par requête varie fortement selon la longueur des tokens en entrée et en sortie ainsi que selon l’architecture du modèle. Il est donc difficile de mesurer la charge réelle avec des indicateurs traditionnels comme l’utilisation CPU ou l’occupation mémoire.
• Amplitude des ressources inactives : dans un environnement où un replica (copie d’instance de service) utilise 4 GPU, on observait en moyenne 52 GPU inactifs pendant environ 12 heures par jour sur les plages nocturnes hors pointe (de 20 h à 8 h le lendemain).

Méthode de résolution

• Utilisation des métriques internes de vLLM : au lieu d’indicateurs système génériques, les métriques fournies par le moteur d’inférence LLM vLLM, comme le débit en temps réel ou l’état d’attente de la file, ont été utilisées comme base d’auto-scaling afin d’obtenir un ajustement des ressources plus précis, adapté aux caractéristiques des LLM.
• Exécution des tâches en mode best-effort : des jobs de recherche sont lancés sur les GPU inactifs de nuit, mais la conception permet de les interrompre à tout moment si le trafic repart à la hausse, afin de réallouer les GPU au service sans compromettre sa stabilité.
• Pipeline basé sur Argo Workflows : les tâches sont définies au niveau d’images Docker, et le prétraitement des données, le pré-entraînement, le fine-tuning supervisé, l’apprentissage par renforcement et l’évaluation sont découpés en étapes pouvant être exécutées en séquence ou en parallèle.

Atouts des principes de conception

• Polyvalence : qu’il s’agisse d’entraînement ou d’inférence, n’importe quel framework peut être exécuté tel quel s’il est encapsulé dans une image Docker.
• Extensibilité et flexibilité : même si de nouveaux types de tâches sont ajoutés, ils peuvent être pris en charge sans modifier le code du pipeline.
• Reproductibilité : tous les paramètres sont injectés de l’extérieur plutôt que codés en dur, et les entrées/sorties sont gérées dans un cloud storage, ce qui garantit les mêmes résultats à conditions identiques. Le fait que le pipeline adopte en plus une architecture stateless, sans conservation d’état, contribue également à la stabilité opérationnelle.

Résultats en production

• Utilisation cumulée : entre novembre 2025 et janvier 2026, environ 85 jobs ont été exécutés sur près de 3 mois, pour une consommation cumulée atteignant 95 000 GPU-heures.
• Tendance à la hausse : en janvier, l’utilisation GPU a augmenté d’environ 70 % par rapport à novembre, soit un effet équivalent à l’ajout de 55 GPU supplémentaires en fonctionnement 24 h/24.
• Réduction des coûts : en convertissant le même volume de calcul sur la base d’un engagement de 3 ans en cloud public, l’économie réalisée s’élève à environ 75 millions de wons pour le seul mois de janvier, et à environ 185 millions de wons cumulés sur 3 mois.

Plans à venir

• Amélioration des métriques de scaling : il est prévu d’affiner davantage la logique d’allocation des ressources en segmentant plus finement les usages selon les services.
• Extension vers une planification continue : en s’appuyant sur Kubernetes et sur le modèle propriétaire EXAONE, l’objectif est d’étendre le système au-delà de la nuit pour lancer les tâches dès que des ressources se libèrent.
• Amélioration de l’UX : une interface doit être mise en place pour permettre aux chercheurs de gérer intuitivement l’ensemble du cycle, de la demande de job au monitoring.

Ce cas illustre une tentative intéressante de résoudre un problème commun au secteur — la pénurie de GPU — non pas par l’extension matérielle, mais par l’amélioration de l’organisation opérationnelle. L’approche se distingue notamment par le fait qu’elle contourne la difficulté propre aux services LLM de mesurer la charge via les métriques internes de vLLM, tout en adoptant des jobs de recherche en mode best-effort afin de concilier deux objectifs souvent contradictoires : la stabilité du service et le taux d’utilisation des ressources. Le résultat quantifié, avec environ 180 millions de wons d’économies sans investissement supplémentaire, propose un modèle d’exploitation suffisamment concret pour inspirer d’autres organisations gérant une infrastructure GPU.