ECS fractionne le GPU en huitièmes et abaisse le ticket d’entrée du ML inférence
AWS lance le GPU fractionné sur ECS avec les instances G6f le 7 août 2026, permettant d’acheter la capacité GPU par huitième plutôt qu’à l’unité. La contrainte réelle n’est pas le calcul mais la mémoire GPU : 3 Go par fraction.
Le 7 août 2026, AWS a introduit le GPU scheduling fractionné sur Amazon ECS avec les instances G6f, modifiant la plus petite unité d’achat de calcul GPU dans le cloud. Désormais, une tâche ECS peut réserver un huitième de GPU au lieu d’un GPU entier. La tarification suit la fraction réservée, pas le GPU complet.
Cette annonce est passée relativement inaperçue au milieu des 66 changements publiés par AWS la même semaine (3-7 août). Elle mérite pourtant une attention particulière : elle s’attaque au problème structurel qui rend l’inférence GPU inaccessible pour les charges de travail intermittentes ou à faible volume.
Le problème que le GPU fractionné résout
Jusqu’à cette annonce, déployer une charge de travail GPU sur ECS imposait de réserver un GPU entier par tâche. Pour une inférence qui consomme 15 à 20 % d’un GPU NVIDIA L40S (la carte équipant les instances G6f), cela signifiait payer 100 % du calcul pour 20 % de l’utilisation — un gaspillage qui excluait de fait les charges légères du calcul GPU managé.
Le GPU fractionné change l’équation. Une tâche ECS peut déclarer gpus=1 avec une valeur fractionnaire — typiquement 0.125 pour un huitième — et le scheduler réserve exactement cette fraction sur l’instance. Le reste du GPU reste disponible pour d’autres tâches, sur la même instance physique.
Le mécanisme repose sur la Multi-Instance GPU (MIG) de NVIDIA, qui partitionne un GPU physique en instances isolées avec des garanties de mémoire et de cache dédiées. AWS l’expose via ECS sans que l’utilisateur ait à configurer MIG manuellement.
La vraie contrainte n’est pas le calcul
L’élément le plus important de cette annonce n’est pas dans le communiqué officiel. La fraction GPU est exprimée en unités de calcul arbitraires, mais la ressource qui bloque réellement est la mémoire GPU, pas le calcul.
Chaque huitième d’un L40S correspond à environ 3 Go de mémoire GPU. Pour un modèle de langage en inférence, 3 Go suffisent pour charger un modèle de ~1,5 à 2 milliards de paramètres en précision FP16, ou un modèle de ~7 milliards de paramètres en quantification 4 bits. Au-delà, la mémoire ne suit plus — quel que soit le calcul disponible.
Le tableau ci-dessous donne les seuils pratiques par fraction :
| Fraction GPU | Calcul relatif | Mémoire GPU | Taille de modèle viable (FP16) | Taille de modèle viable (INT4) |
|---|---|---|---|---|
| 1/8 | 12,5 % | ~3 Go | ~1,5 Md paramètres | ~7 Md paramètres |
| 1/4 | 25 % | ~6 Go | ~3 Md paramètres | ~13 Md paramètres |
| 1/2 | 50 % | ~12 Go | ~7 Md paramètres | ~28 Md paramètres |
| 1 | 100 % | ~24 Go | ~13 Md paramètres | ~50 Md paramètres |
Le message est clair : pour l’inférence de petits modèles spécialisés — classification de texte, extraction d’entités, résumé, RAG léger — le huitième de GPU est amplement suffisant. Pour un LLaMA 3 8B ou équivalent, un demi-GPU est le minimum viable en FP16.
Ce que ça change pour les architectures
Le GPU fractionné n’est pas juste une optimisation tarifaire. C’est un changement architectural qui modifie la manière de concevoir les pipelines d’inférence sur AWS.
Avant le 7 août, trois options existaient pour l’inférence GPU sur AWS :
- SageMaker endpoints : gérés, élastiques, mais coûteux pour les charges intermittentes (coût fixe à l’heure même sans trafic)
- ECS avec GPU entier : flexible mais imposant un GPU complet par tâche — surdimensionné pour l’inférence légère
- Lambda avec inférence CPU : économique mais lent, inadapté aux modèles dépassant quelques centaines de millions de paramètres
Après le 7 août, une quatrième option apparaît : ECS avec GPU fractionné, qui combine la flexibilité d’ECS avec un ticket d’entrée divisé par huit. Pour une tâche d’inférence qui tourne quelques heures par jour, le coût GPU devient proportionnel à l’usage réel plutôt qu’à l’unité indivisible de la carte physique.
L’impact est particulièrement fort pour :
- Les pipelines RAG avec un petit modèle de re-ranking ou de classification
- Les microservices d’inférence qui traitent des pics à faible volume
- Les environnements de développement et de staging où le GPU complet est un luxe injustifié
- Les architectures multi-modèles sur une même instance : un modèle de classification sur un huitième, un générateur de résumé sur un quart, etc.
Le piège de la concurrence mémoire
Le GPU fractionné introduit une nouvelle classe de problèmes opérationnels : la concurrence mémoire entre fractions. Deux tâches sur le même GPU physique partagent la bande passante mémoire et les caches L2, même si MIG garantit l’isolation de la mémoire de travail (framebuffer).
En pratique, cela signifie qu’une tâche avec une fraction de 0.125 sur un GPU où tournent sept autres tâches verra sa latence d’inférence varier en fonction de l’activité mémoire des voisines — un phénomène absent avec un GPU dédié. Le scheduler ECS ne tient pas compte de cette contention mémoire croisée dans sa logique de placement actuelle.
La recommandation conservatoire est de ne pas dépasser quatre à cinq fractions par GPU physique si la latence est critique, et de réserver le remplissage complet (huit fractions) aux charges où la variabilité de latence est acceptable — traitement par lots nocturnes, inférence asynchrone, ou modèles où le P99 n’est pas contractuel.
Faut-il migrer les inférences Serverless vers ECS fractionné ?
La question se pose pour les organisations qui utilisent aujourd’hui SageMaker Serverless Inference ou des endpoints Bedrock pour de petits modèles. Le GPU fractionné sur ECS est structurellement moins cher au volume — pas de frais de gestion par endpoint, pas de coût fixe à l’heure inactive — mais il transfère la charge opérationnelle à l’équipe qui le déploie.
Le seuil de rentabilité dépend du volume. Pour moins de ~50 000 inférences par mois, le surcoût opérationnel d’ECS (gestion des instances, mise à l’échelle, monitoring) dépasse probablement l’économie GPU. Au-delà de ~200 000 inférences par mois, le GPU fractionné devient économiquement indiscutable, à condition que l’équipe maîtrise déjà ECS.
Voici le verdict conditionnel : si vous avez déjà une infrastructure ECS et que vos modèles tiennent dans 3 à 6 Go de mémoire GPU, commencez à migrer les inférences légères vers le GPU fractionné cette semaine — L’économie est immédiate et le risque opérationnel est faible. Si vous n’avez pas d’infrastructure ECS et que votre volume est inférieur à 50 000 requêtes par mois, restez sur un service managé et réévaluez dans six mois.