SageMaker sait désormais diviser un GPU en 7 : davantage de modèles sur le même matériel

Une situation bien connue : vous disposez d'un classificateur, d'un reranker, d'un modèle d'embeddings et de quelques modèles affinés. Chacun requiert 10 à 20 Go, mais SageMaker leur attribue un GPU entier. Le reste de la mémoire demeure inutilisé tandis que la facture grimpe. AWS a enfin corrigé le problème.

Ce qui change

SageMaker Inference prend désormais en charge le partitionnement des GPU fondé sur NVIDIA Multi-Instance GPU (MIG). Le GPU physique est divisé en partitions indépendantes, chacune disposant de sa propre part d'unités de calcul, de cache, de mémoire et de bande passante mémoire. L'isolation est matérielle, et non logicielle.

Auparavant, pour bénéficier de MIG, il fallait déployer son propre Kubernetes : pilotes, device plugin, configuration des partitions et ordonnancement. Les multi-model endpoints ne réglaient pas le problème : les modèles partageaient le périphérique sans isolation, avec en outre un démarrage à froid lors du premier chargement. Désormais, vous choisissez un profil de partition et SageMaker s'occupe du reste.

À quoi cela ressemble en pratique

Deux champs facultatifs sont ajoutés. AcceleratorPartitionLayouts est renseigné dans le production variant lors de la création de la configuration de l'endpoint et décrit la manière dont chaque GPU est partitionné. Sur une instance p4d.24xlarge, par exemple, la topologie mig-4g.20gb + mig-2g.10gb + mig-1g.5gb utilise les sept tranches d'un A100. Avec huit GPU, on obtient 24 partitions, soit huit de chaque type.

AcceleratorPartitionType est renseigné dans l'inference component et détermine le type de partition sur lequel réside le modèle. Aucune nouvelle opération d'API ni action IAM n'est nécessaire, et InvokeEndpoint reste inchangé. En augmentant CopyCount, il est possible de placer des copies supplémentaires d'un petit modèle sur les partitions disponibles. La création du partitionnement ajoute environ 17 secondes au déploiement de l'endpoint.

Les profils disponibles dépendent du GPU. Les A100 et H100 sont divisés en septièmes pour le calcul et en huitièmes pour la mémoire. Le G7 (RTX PRO 4500 Blackwell) est divisé en deux, tandis que le G7e (RTX PRO 6000 Blackwell) est divisé en quatre. Le profil 3g est particulier : il utilise 3 des 7 blocs de calcul, mais 4 des 8 blocs de mémoire. Deux partitions de ce type remplissent donc entièrement un GPU.

Comment choisir un profil

Les blocs de calcul sont nécessaires au prefill, c'est-à-dire au traitement du prompt : plus l'entrée est longue et plus le nombre de requêtes parallèles est élevé, plus ils sont importants. La mémoire est nécessaire au decode et à la capacité : poids, cache KV et 1 à 2 Go de surcharge pour le contexte CUDA. Un modèle 8B en FP16 pèse environ 16 Go et peut confortablement gérer un contexte de 8 000 tokens sur une partition de 40 Go. Si vous ne tenez compte que des poids, le modèle se chargera, mais il échouera sous charge ou réduira silencieusement le contexte.

Dans quels cas est-ce rentable ?

• Un ensemble de modèles petits et moyens : variantes affinées, modèles d'embeddings et rerankers.
• La multitenance : une frontière matérielle sépare les clients, mais l'hôte, le réseau et le routage restent partagés. Il ne s'agit donc pas d'une isolation complète.
• Des pipelines sur une même instance : transcription, diarisation et LLM sans sauts réseau.
• Un modèle de guardrail avec une latence prévisible.
• Des déploiements canary : le candidat s'exécute sur une petite partition aux côtés de la version de production.

Limites

La topologie doit être choisie lors de la création de l'endpoint et ne peut pas être modifiée à chaud. La fonction n'est compatible qu'avec les inference components : les endpoints autonomes, serverless et hétérogènes ne sont pas pris en charge. Un modèle qui nécessite plus d'un GPU continue d'exiger des périphériques entiers. Sur P4d, le profil mig-1g.10gb requiert le pilote R525 ou une version ultérieure, tandis que l'image par défaut est fournie avec la version 470. Il faut donc spécifier InferenceAmiVersion al2023-ami-sagemaker-inference-gpu-4-1. Sinon, le partitionnement échouera sans message d'erreur explicite.

Que faire ?

Si plusieurs petits modèles s'exécutent chacun sur un GPU distinct dans SageMaker, calculez leur consommation mémoire selon la formule « poids + cache KV + surcharge », puis essayez de les regrouper sur un même GPU. Profitez-en pour effectuer des tests de charge : les performances d'une partition ne dépendent pas de ses voisines, ce qui permet de transposer les résultats en production.