AWS ajoute le partitionnement des GPU NVIDIA aux points de terminaison d’inférence SageMaker

Le 6 novembre 2026, Amazon Web Services (AWS) a annoncé la prise en charge des GPU NVIDIA Multi-Instance dans Amazon SageMaker Inference, permettant à plusieurs modèles isolés matériellement de partager un même accélérateur sur des points de terminaison en temps réel, au lieu d’attribuer un GPU entier à chaque déploiement.

Cette fonctionnalité répond à deux limites de l’allocation d’un GPU entier. Le nombre d’accélérateurs plafonne le nombre de modèles qu’une instance peut héberger, quelle que soit la faible quantité de mémoire ou de puissance de calcul utilisée par chaque modèle ; de plus, les clients qui envisagent un GPU plus récent doivent allouer l’appareil entier. Multi-Instance GPU (MIG) attribue plutôt à chaque partition une part fixe des unités de calcul et un bloc de mémoire dédié, l’isolation étant assurée par le matériel. Comme chaque modèle reste chargé en mémoire, cette configuration évite également le délai occasionné lorsqu’un point de terminaison mult modèle charge un modèle sur son appareil partagé pour la première utilisation.

Le partitionnement est limité aux points de terminaison en temps réel qui utilisent des composants d’inférence, le mécanisme de SageMaker permettant de déployer plusieurs modèles sur un seul point de terminaison et de définir la puissance de calcul attribuée à chacun. Les points de terminaison à modèle unique, les points de terminaison sans serveur et les groupes d’instances hétérogènes ne peuvent pas être partitionnés. Les charges de travail asynchrones ne sont pas non plus prises en charge, car les appels asynchrones ne peuvent pas cibler un composant d’inférence.

Salesforce a contribué à définir les exigences et à valider la première mise en œuvre. Richard Chang, architecte en ingénierie logicielle chez Salesforce, a indiqué que l’entreprise s’attendait à ce que MIG permette de regrouper les charges de travail en toute sécurité, d’améliorer l’utilisation des GPU et de réduire les coûts d’inférence, tout en préservant des performances prévisibles et l’isolation. Salesforce se prépare à valider le logiciel avec des charges de travail représentatives de la production ; ces avantages restent donc des attentes et ne correspondent pas à des résultats de production rapportés.

Deux champs d’API contrôlent le partitionnement

La documentation destinée aux développeurs SageMaker AI définit deux champs facultatifs : AcceleratorPartitionLayouts déclare le découpage sur une variante de production, et AcceleratorPartitionType sélectionne le profil utilisé par un composant d’inférence. Aucune nouvelle opération d’API, aucun nouveau type de ressource ni aucune nouvelle action AWS Identity and Access Management ne sont nécessaires, et l’omission des deux champs préserve le comportement actuel des points de terminaison.

La configuration sélectionnée s’applique uniformément à chaque accélérateur de chaque instance de la variante. Dans son exemple, AWS répartit chacun des huit A100 d’une ml.p4d.24xlarge en mig-4g.20gb, mig-2g.10gb et mig-1g.5gb partitions, soit 24 partitions sur l’ensemble du point de terminaison. Chaque copie d’un composant d’inférence occupe une partition demandée, tandis que InvokeEndpoint continue de cibler les modèles par nom de composant, sans identifiant de partition. Lors de ses essais, AWS a indiqué que le découpage des accélérateurs ajoutait environ 17 secondes au provisionnement.

L’isolation concerne la puissance de calcul et la mémoire du GPU, et non l’hôte dans son ensemble. Les modèles d’une même instance partagent toujours le processeur de l’hôte, sa mémoire, le stockage, le réseau et le routage du point de terminaison. Un composant qui demande un profil absent de la configuration est rejeté au lieu de se voir attribuer un GPU entier. Pour modifier la configuration d’un point de terminaison en cours d’exécution, il faut créer un nouveau point de terminaison et migrer le trafic ; pour déplacer un composant vers un autre profil, il faut créer un nouveau composant.

AWS teste une partition H100 à un A100 entier

AWS a comparé une mig-3g.40gb partition H100 à un A100-40GB entier, en utilisant Llama-3.1-8B-Instruct sur des points de terminaison SageMaker en temps réel de production. Les deux configurations utilisaient une seule réplique du modèle, des conteneurs, des tokeniseurs et des configurations client identiques, tandis que genai-bench exécutait cinq profils de trafic avec des niveaux de concurrence allant de 2 à 512. Le guide des profils de NVIDIA attribue au profil H100 testé trois des sept parts de multiprocesseur de flux et quatre des huit unités de mémoire. Les deux configurations offrent une capacité mémoire comparable, mais des ressources de calcul différentes.

Sur l’ensemble des essais, AWS a indiqué que la partition H100 produisait de 53 % à 89 % de jetons de sortie supplémentaires par seconde, au niveau de charge où le gain de coût était le plus important pour chaque scénario. La latence entre les jetons était inférieure de 8,9 % à 42,1 %, et le délai avant le premier jeton, de 5,6 % à 47,5 %. Au niveau de concurrence le plus élevé, pour les charges de travail de 6 000 et 8 000 jetons, l’A100 n’a pas respecté le délai de traitement pour un tiers à la moitié des requêtes, tandis que la partition n’en a échoué aucune.

L’analyse des coûts d’AWS, présentée comme une comparaison au cas par cas plutôt que comme une conclusion universelle, a révélé un coût par million de jetons de sortie inférieur de 18 % à 34 % dès que le trafic dépassait le seuil de rentabilité propre à la charge de travail. Ce seuil était atteint avec une concurrence de 64 pour les invites de 100 jetons et de 4 pour celles de 8 000 jetons. En deçà, l’A100 entier restait moins cher ; l’ancien GPU entier pourrait donc mieux convenir aux charges de travail comportant des entrées courtes ou une faible concurrence. La comparaison du coût unitaire divisait le prix des instances à la demande par le nombre d’unités testées sur chaque instance.

Matériel pris en charge et limites d’exploitation

Le lancement couvre quatre familles d’instances, le nombre de partitions et les profils dépendant de l’accélérateur :

Le partitionnement des GPU est disponible dans les régions USA Est (Virginie du Nord), USA Est (Ohio), USA Ouest (Oregon), Asie-Pacifique (Singapour), Asie-Pacifique (Tokyo), Europe (Francfort) et Europe (Irlande), sous réserve de la disponibilité régionale des instances et du quota des points de terminaison. Aucune partition ne couvre plusieurs accélérateurs : les modèles qui nécessitent un GPU entier ou plusieurs GPU doivent donc toujours utiliser des appareils complets.

Les clients continuent de payer le prix de l’instance GPU complète ; le partitionnement peut augmenter la capacité utilisable, mais ne réduit pas son tarif horaire. Les points de terminaison partitionnés et leurs composants d’inférence ne publient pas non plus dans CloudWatch de métriques d’utilisation du GPU, du CPU ou de la mémoire, même si les métriques d’invocation et de latence restent disponibles. Sur P4d, le mig-1g.10gb profil nécessite le pilote R525 de NVIDIA ou une version ultérieure, et AWS recommande aux clients d’utiliser une AMI d’inférence plus récente, car l’image par défaut ne le fournit pas.

Pour planifier la capacité, le lancement transforme chaque accélérateur pris en charge en plusieurs tailles de GPU fixes, mais un déploiement plus dense avec isolation matérielle implique une facturation au prix de l’instance complète, des configurations impossibles à modifier sur place et une télémétrie d’utilisation réduite. Le benchmark d’AWS montre l’intérêt de mesurer le trafic réel : lors de ces tests, le partitionnement du H100 a offert des avantages en matière de performances et de coûts dans des conditions de contextes longs plus exigeantes, tandis que les résultats au seuil de rentabilité montraient qu’un A100 entier coûtait moins cher pour les charges de travail plus légères.