Avito décortique six talks de la KubeCon Japan 2026 sur le partage des GPU

Anton Alekseïev, ingénieur ML Ops chez Avito, est allé à Yokohama pour la KubeCon + CloudNativeCon Japan 2026 et a réuni six talks sur les GPU et l'inférence LLM dans un seul compte rendu. Dès le deuxième jour de la conférence, il a constaté que les slides de différents intervenants se ressemblaient : spectre d'isolation des tenants, quotas, bin packing et refrain « les GPU coûtent cher, partageons-les ». Avito traite le même problème ; la comparaison est donc très concrète : ce que l'entreprise a déjà essayé, et ce qu'elle s'apprête seulement à tester.

Pour l'instant, l'article publié sur Habr se limite à une partie introductive. Ce qui suit porte donc sur le contexte, et non sur un résumé de chaque talk.

Un seul motif pour six talks

Le fait que des équipes différentes arrivent indépendamment aux mêmes schémas témoigne de la maturité du sujet. Il y a deux ans, on attribuait généralement les GPU dans Kubernetes en entier : une carte, un pod. Aujourd'hui, les accélérateurs pèsent une part notable du budget d'infrastructure, et leur charge est irrégulière. L'entraînement et les tâches batch sollicitent la carte à fond. L'inférence en ligne la laisse souvent à moitié vide. D'où quatre thèmes récurrents :

• isolation des tenants : jusqu'où séparer strictement les voisins sur une même carte ;
• quotas : combien d'accélérateurs une équipe ou un projet peut occuper ;
• bin packing : comment empiler les pods sur les nœuds le plus densément possible, pour éviter de multiplier les cartes partiellement occupées ;
• inférence LLM comme principal consommateur, où la mémoire nécessaire aux poids et au KV-cache se heurte à la taille de la carte.

Le spectre d'isolation

Ce spectre se décrit sur une seule échelle : plus la frontière entre tenants est étanche, plus l'utilisation baisse et plus la prévisibilité augmente. Les points typiques de cette échelle sont connus de longue date.

• Carte entière pour un seul pod : isolation maximale, densité la plus faible.
• MIG sur les cartes NVIDIA compatibles : partitionnement matériel en plusieurs instances indépendantes, jusqu'à sept par carte, avec mémoire dédiée.
• MPS : plusieurs processus se partagent les ressources de calcul, mais l'isolation est plus faible.
• Time-slicing : les pods se relaient sur la carte ; personne ne garantit ni la mémoire ni l'absence d'erreurs d'isolation.

Le choix dépend de la charge. Pour un service en ligne critique, soumis à des exigences strictes de latence, une frontière matérielle est plus raisonnable. Pour des expérimentations internes, un partage souple suffit généralement.

Quotas et packing

L'isolation détermine qui cohabite avec qui. Les quotas et le scheduler décident, eux, qui obtient une carte. En pratique, on y retrouve des files d'attente pour les tâches batch, des priorités et la préemption. Le bin packing compte parce que les demandes fractionnaires fragmentent vite le cluster : les fractions libres abondent, mais il n'y a nulle part où placer un pod qui a besoin d'une carte entière ou d'un gros profil MIG. Un scheduler qui tient compte de la topologie et cherche à remplir les nœuds densément remet ces fractions en circulation.

Selon l'auteur, il détaillera ce qu'Avito a déjà expérimenté parmi les approches présentées et ce qui figure dans ses plans. Pour le lecteur, c'est la partie la plus précieuse : les talks de conférence montrent généralement un schéma qui fonctionne, mais disent rarement où il casse face à la charge de quelqu'un d'autre. Le retour d'un ingénieur qui confronte les slides à sa propre production comble précisément ce manque. À la fin du texte, l'auteur promet un récit sur le Japon lui-même ; le format se rapproche donc d'un carnet de voyage avec un noyau technique.

Par où commencer avec un cluster GPU

Si vous n'en êtes qu'à réfléchir au partage des cartes, l'ordre des opérations découle des talks eux-mêmes. Commencez par mesurer l'utilisation réelle : charge des unités de calcul et mémoire occupée pour chaque service, et pas seulement le fait qu'une carte soit allouée. Séparez ensuite les charges selon leurs exigences d'isolation : inférence en ligne, tâches batch, expérimentations.

Pour chaque classe, choisissez son propre point sur le spectre, sans chercher à imposer un régime unique. Introduisez après cela des quotas par équipe et des files d'attente pour les tâches batch, et réglez le packing en dernier, quand la structure des demandes est claire. Enfin, décidez à l'avance ce que vous ferez des voisins bruyants : sans métriques de latence, le partage d'une carte devient vite une source de dégradations inexplicables.

L'analyse complète des six talks et le retour d'expérience d'Avito sont publiés sur Habr, dans l'article d'Anton Alekseïev.