MPS NVIDIA sur EC2 : diviser l'infra GPU d'inférence par 4

NVIDIA MPS peut diviser par quatre le nombre de GPU nécessaires pour servir un modèle d'inférence, sans changer une ligne de code applicatif. Un GPU d'inférence qui tourne à 20 % de sa capacité pendant que 80 % de ses unités de calcul restent inactives : c'est le quotidien de la plupart des déploiements de reconnaissance vocale (ASR) en production. Un billet technique publié le 27 août 2026 par AWS et NVIDIA, coécrit avec Heidi Health, détaille comment NVIDIA MPS (Multi-Process Service) rend ce gain concret en production.

Heidi Health traite 2,4 millions de consultations cliniques par semaine dans 190 pays. À cette échelle, une baisse de 75 % du nombre de GPU n'est pas un détail d'optimisation : c'est un changement de coût d'infrastructure structurel.

Le contexte

Une requête d'inférence ASR individuelle n'utilise en général que 15 à 20 % des unités de calcul (streaming multiprocessors, ou SM) d'un GPU comme le NVIDIA L40S, qui en compte 142. Par défaut, CUDA gère le partage d'un GPU entre plusieurs processus par time-slicing : chaque processus obtient un accès exclusif et séquentiel au GPU, à tour de rôle. Résultat : le GPU passe le plus clair de son temps à attendre, et le coût du changement de contexte (context-switching) s'ajoute à l'inefficacité.

NVIDIA CUDA MPS est une implémentation alternative, binairement compatible avec l'API CUDA, qui permet à plusieurs processus de partager un GPU en exécution réellement concurrente — sur des SM différents du même GPU, en parallèle — plutôt qu'en alternance. Contrairement au MIG (Multi-Instance GPU), qui partitionne physiquement le matériel, MPS reste logiciel et configurable dynamiquement.

MPS NVIDIA : comment ça marche sous le capot

Le mécanisme central : MPS fait transiter tout le travail CUDA par un contexte GPU unique, géré par un processus démon MPS. Cela élimine l'essentiel du coût de changement de contexte et autorise l'exécution simultanée de kernels issus de processus différents sur les SM disponibles. La protection mémoire reste assurée : chaque processus conserve son propre espace d'adressage.

La taille de la partition allouée à chaque instance se règle via la variable d'environnement CUDA_MPS_ACTIVE_THREAD_PERCENTAGE. Dans le déploiement Heidi Health, la transcription utilise 4 instances MPS concurrentes à 25 % des SM chacune (environ 2,5 Go de VRAM par instance), tandis que la diarisation (identification des locuteurs) tourne sur 8 instances à 12 % chacune (environ 1,8 Go de VRAM). Les deux tâches sont volontairement séparées sur des partitions MPS distinctes pour éviter toute contention.

L'architecture complète

Le pipeline s'articule autour de trois composants : une passerelle FastAPI compatible avec l'API OpenAI Whisper (décodage audio via torchcodec, port 8002, 4 workers uvicorn), qui transmet les requêtes en gRPC à un NVIDIA Triton Inference Server. Triton gère le batching dynamique pour la transcription et le batching séquentiel pour la diarisation, avec des tailles de lot préférées de 4, 8 et 16 et un délai de mise en file d'attente maximal de 50 ms. Le démon CUDA MPS partitionne le GPU avant même l'initialisation de Triton.

Le modèle utilisé est NVIDIA Parakeet TDT 0.6B V2, affiné pour la reconnaissance vocale clinique (encodeur Conformer 24 couches, décodeur RNN-T). Deux optimisations complémentaires réduisent encore la latence : un chemin ONNX Runtime + TensorRT qui applique fusion de kernels et calibration de précision (FP16/INT8), et un appel direct à model.forward() — plutôt qu'à model.transcribe() via NeMo — qui élimine environ 50 ms de surcharge de framework par requête.

Le cas Heidi Health : les résultats chiffrés

Les benchmarks publiés comparent plusieurs configurations sur des instances g6e.4xlarge et g7e.4xlarge (GPU NVIDIA L40S, 48 Go de VRAM), avec un seuil de SLA fixé à une latence moyenne inférieure à 650 ms et un p99 inférieur à 1 000 ms :

• Triton + MPS sur g6e.4xlarge : 60,8 requêtes/seconde (RPS) par GPU, latence moyenne 470 ms, p99 947 ms — réduction d'infrastructure de 75 % (16 GPU ramenés à 4).
• Triton + MPS sur g7e.4xlarge (chemin retenu en production) : 92,1 RPS par GPU, latence moyenne 352 ms, p99 769 ms — même réduction de 75 %, avec un débit 51 % supérieur et une latence 25 % inférieure à la configuration g6e.
• TensorRT + ONNX + MPS sur g7e.4xlarge : 111,6 RPS par GPU, latence moyenne 590 ms, p99 896 ms — réduction d'infrastructure de 88 % (16 GPU ramenés à seulement 2).

Sans MPS, un GPU L40S en time-slicing plafonne autour de 62 RPS avec 80 % de ses SM inactifs pendant chaque passe avant.

Sur la diarisation, l'ajout d'un warmup TensorRT réduit la latence moyenne de 309 ms à 239 ms (-23 %), et le p99 de 499 ms à 389 ms (-22 %). Un enregistrement de 60 secondes, découpé en quatre segments de 15 secondes, est traité avec un facteur temps réel de 0,016x.

MPS ou MIG : comment choisir

NVIDIA propose deux mécanismes de partage GPU, et ils ne répondent pas au même besoin. MIG (Multi-Instance GPU) partitionne physiquement un GPU compatible (A100, H100, et les générations récentes) en plusieurs instances totalement isolées, avec leur propre mémoire et leurs propres unités de calcul dédiées — l'isolation est maximale, mais la granularité est fixe et le nombre de partitions limité par le matériel. MPS, à l'inverse, reste une couche logicielle : la partition en pourcentage de SM est configurable dynamiquement via une variable d'environnement, sans redémarrage matériel, et fonctionne sur une gamme de GPU plus large — y compris les L40S utilisés par Heidi Health, qui ne supportent pas MIG.

Le compromis : MPS partage un contexte GPU unique entre processus, ce qui expose (en théorie) à des scénarios de corruption croisée en cas de crash d'un processus voisin — d'où l'importance des mécanismes de sécurisation des CUDA Graph et de la sentinelle de santé décrits plus haut. Pour un service ASR interne où tous les processus tournent le même modèle sous contrôle de l'équipe, ce compromis est généralement acceptable. Pour du multi-tenant strict avec des workloads non fiables, MIG reste la solution plus prudente.

Les pièges techniques de NVIDIA MPS à connaître

Les auteurs sont transparents sur les difficultés d'ingénierie que ce gain ne dissimule pas :

• Chargement de modèle sérialisé : un verrou fichier empêche le chargement simultané de plusieurs instances d'un modèle de 600 millions de paramètres, qui dépasserait sinon la mémoire GPU disponible.
• Enveloppe de warmup CUDA Graph : les formes de production attendues (5, 15, 30, 45, 60 secondes en batch de 1, plus batch de 2 à 61 secondes) sont pré-chauffées pour rejouer des graphes en cache à environ 165 ms. Toute forme hors de cette enveloppe retombe en exécution eager, à environ 500 ms — une pénalité de latence par 3.
• Fallback CUDA Graph compatible MPS : sans précaution, une fenêtre de recapture de 1,5 à 2,5 secondes peut voir des instances MPS voisines corrompre la capture (cudaErrorIllegalAddress).
• Surveillance par sentinelle : un mécanisme dédié détecte les erreurs CUDA irrécupérables sur une instance MPS via une sonde du flux CUDA, et écrit un fichier sentinelle sur tmpfs pour déclencher le remplacement de l'instance.

Les auteurs précisent que l'architecture — MPS, appel direct au forward pass, sécurisation des CUDA Graph, sentinelle de santé — est agnostique au modèle : elle a été validée sur Parakeet TDT, Canary et OpenAI Whisper large-v3, et s'applique en principe à tout modèle encodeur-décodeur servi via Triton dès lors que chaque requête n'utilise qu'une fraction du GPU disponible.

Ce que ça change pour les équipes IA

Ce billet illustre un problème que beaucoup d'équipes MLOps sous-estiment : le sous-provisionnement par sur-dimensionnement. Quand une requête d'inférence n'utilise que 15-20 % d'un GPU, ajouter des GPU pour absorber la charge revient à payer pour du silicium inactif. MPS n'est pas une astuce marginale — c'est un changement d'architecture de service qui peut diviser la facture d'infrastructure GPU par quatre, voire par huit avec l'optimisation ONNX/TensorRT, sans toucher au code métier du modèle.

Le vrai coût n'est pas dans l'activation de MPS elle-même (une variable d'environnement), mais dans l'ingénierie de fiabilité qui l'entoure : gestion du chargement concurrent, enveloppes de warmup, détection de corruption CUDA Graph, health-checks dédiés. C'est exactement le type de travail — profiler la charge réelle d'un GPU, redimensionner l'infrastructure d'inférence en conséquence, et industrialiser la fiabilité qui va avec — que couvre un audit d'infrastructure IA en production.

Pour toute équipe qui sert des modèles d'inférence à volume (ASR, mais le pattern s'applique aussi à l'embedding, à la classification, ou à des modèles de vision légers), la question à se poser dès maintenant : quel pourcentage de vos GPU de production est réellement utilisé pendant une passe avant ? Si la réponse est proche de 20 %, NVIDIA MPS est probablement le levier de coût le plus sous-exploité de votre stack.

Concrètement, une démarche raisonnable pour évaluer si ce pattern s'applique chez vous tient en trois étapes : mesurer l'utilisation SM réelle par requête sur votre charge de production actuelle (via nvidia-smi ou les métriques CloudWatch/Prometheus déjà en place) ; identifier si vos workloads tournent le même modèle sous contrôle d'une seule équipe (cas favorable à MPS) ou des tenants hétérogènes non fiables (cas plutôt favorable à MIG) ; et enfin prototyper la configuration MPS sur un sous-ensemble de trafic avant un déploiement complet, en gardant le SLA de latence comme garde-fou plutôt que le seul débit brut. C'est un chantier de quelques semaines, pas un simple changement de configuration d'un après-midi — mais le retour, à la lumière du cas Heidi Health, se mesure directement en facture d'infrastructure divisée par quatre.

En bref

• NVIDIA MPS permet l'exécution GPU réellement concurrente entre processus, contrairement au time-slicing par défaut de CUDA.
• Heidi Health réduit son infrastructure GPU d'inférence ASR de 75 % (16 → 4 GPU) tout en tenant un SLA de latence sub-seconde.
• La combinaison TensorRT + ONNX + MPS pousse la réduction à 88 % (16 → 2 GPU).
• Le gain a un prix en ingénierie : chargement sérialisé, warmup CUDA Graph, détection de corruption, monitoring dédié.
• Le pattern est agnostique au modèle et s'applique à tout workload d'inférence sous-utilisant le GPU par requête.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by Kevin Ache on Unsplash.