La pénurie de GPU au sein de votre propre infrastructure : pourquoi les charges de travail d'IA s'accumulent alors que la capacité est inutilisée
ainews ·
Cet article explique pourquoi les charges de travail d'IA s'accumulent en file d'attente malgré des systèmes de surveillance indiquant une faible utilisation des GPU, précisant que les métriques d'activité de calcul ne reflètent pas la capacité disponible. Par défaut, Kubernetes utilise une allocation exclusive, ce qui signifie qu'une seule charge de travail occupant un dispositif bloque toutes les autres, indépendamment de la quantité minimale de silicium effectivement utilisée. Le texte identifie quatre causes principales à ce phénomène : l'occupation exclusive du dispositif, l'occupation de la VRAM par les modèles chargés, les contraintes liées aux règles de placement et les goulots d'étranglement au niveau de l'application, tels que les délais CPU ou E/S. Il compare trois méthodes de partage des GPU — le time-slicing, Multi-Instance GPU (MIG) et Multi-Process Service (MPS) — en soulignant leurs compromis respectifs en matière d'isolation mémoire, de exigences matérielles et d'observabilité. Une séquence diagnostique est proposée pour aider les équipes à déterminer si le problème provient de l'allocation, de la mémoire, du placement ou de dépendances externes avant tout achat de nouveau matériel. L'article cite un rapport de Cast AI indiquant une utilisation moyenne des GPU à l'échelle du parc de seulement 5 %, soulignant que la plupart des capacités semblant inactives sont en réalité allouées plutôt que libres. Enfin, il présente une étude de cas où ALLEN Digital a réduit ses coûts de 71 % en passant d'instances dédiées à des configurations de GPU partagées grâce à des outils d'automatisation.
ainews