Concevoir l'accès GPU sans serveur : un guide pratique pour AWS, GCP, Azure et NVIDIA

L'IA n'est pas seulement un logiciel, c'est une réalité physique avec des plafonds de ressources stricts. J'ai parcouru des centres de données où les tours de refroidissement évaporatif consomment plus d'eau qu'un petit quartier ; une réalité que de nombreux ingénieurs logiciels peuvent se permettre d'ignorer. Mes clients, cependant, ne le peuvent pas. Ils viennent me voir avec une contrainte spécifique : ils ont besoin de la puissance GPU pour l'inférence ou l'ajustement fin, mais sans le fardeau opérationnel du provisionnement de matériel dédié. La voie traditionnelle — acquérir des instances GPU coûteuses, gérer les pilotes, construire des groupes de mise à l'échelle automatique complexes — conduit à des ressources sous-utilisées ou à une course effrénée en période de forte demande.

Ce guide est la couche de décision. Il compare la manière dont AWS, GCP et Azure abordent l'accès GPU sans serveur, met en lumière les compromis importants en production et vous offre un cadre clair pour choisir la bonne plateforme pour votre charge de travail. Chaque plateforme fait l'objet d'un article d'approfondissement dédié dans cette série ; les liens sont fournis à la fin de chaque section.

Le terme est surchargé. Chez les fournisseurs, il couvre au moins trois schémas distincts :

• Points d'accès d'inférence à mise à l'échelle jusqu'à zéro — vous déployez un modèle ; le fournisseur met à l'échelle les instances (y compris les instances GPU) entre zéro et N en fonction du trafic. Vous payez par invocation ou par seconde de calcul actif. Les démarrages à froid sont le coût principal.
• Jobs de traitement par lots / d'ajustement fin sans serveur — vous soumettez un job ; le fournisseur alloue des ressources GPU pour la durée, puis les libère. Aucun point d'accès à gérer, aucun nombre de répliques à ajuster.
• API de modèles gérées — le fournisseur exécute entièrement le modèle (par exemple, Amazon Bedrock, Azure OpenAI). Vous appelez une API ; vous ne touchez jamais du tout à l'abstraction GPU.

Toutes les plateformes ne prennent pas en charge ces trois schémas de manière égale. Cette asymétrie est la première chose à comprendre avant de faire un choix.

AWS vous offre deux points d'entrée sans serveur distincts. Pour les modèles personnalisés, SageMaker Serverless Inference vous permet de déployer votre propre conteneur sans gérer les instances. Pour les modèles de fondation, Amazon Bedrock offre un accès API entièrement géré et payant par jeton à Anthropic, Cohere, Amazon Titan et d'autres — sans aucune gestion GPU.

Les principaux leviers de configuration sont MemorySizeInMB (1024–6144 Mo) et MaxConcurrency. Le plafond de mémoire de 6 Go est la limite dure la plus importante en pratique : les modèles de plus de 3-4 milliards de paramètres en FP16 ne tiendront pas. Pour les modèles plus grands, la solution est SageMaker Endpoints avec des instances GPU dédiées (ml.g5 ou ml.inf2) ou Bedrock.

ProvisionedConcurrency est le réglage des démarrages à froid. Le configurer à 0 maximise les économies de coûts mais introduit des démarrages à froid de 10 à 30 secondes. Le configurer à 1-2 maintient les instances actives à un coût fixe modeste. Je conseille aux clients de commencer à zéro pour établir une base de référence, puis d'ajouter la concurrence provisionnée uniquement si les SLO de latence sont violés.

Quand choisir AWS : Votre équipe opère déjà dans l'écosystème AWS, votre modèle tient dans 6 Go de mémoire, et vous souhaitez le modèle IAM et d'observabilité le plus familier. La visibilité des dépenses par point d'accès d'AWS Cost Explorer est également la plus mature des trois plateformes.

→ Voir le guide d'implémentation complet : Inférence GPU sans serveur sur AWS SageMaker

Les points d'accès Vertex AI offrent l'intégration la plus étroite avec la plateforme Vertex plus large — le registre de modèles, les expériences, les pipelines et la surveillance partagent tous le même modèle de ressources. Vous définissez un type de machine avec un accélérateur GPU attaché (T4, A100, H100), définissez les limites de mise à l'échelle automatique, et Vertex gère le reste.

Le paramètre critique est min_replica_count. Le définir à 0 offre un véritable comportement de coût de mise à l'échelle jusqu'à zéro mais introduit des démarrages à froid qui dépassent régulièrement 60 secondes pour les instances GPU. Pour tout service面向utilisateur, min_replica_count=1 est la valeur par défaut correcte — le coût d'une réplique inactive n1-standard-4 + T4 (~0,95 $/heure) est presque toujours moins cher que l'effort d'ingénierie pour déboguer les violations de SLO.

Pour la marge de mémoire, Vertex AI est le plus flexible des trois : vous pouvez attacher un A100 (40 Go HBM2) ou un H100 (80 Go HBM3) à un type de machine personnalisé, en contournant le plafond de 6 Go qui contraint AWS SageMaker Serverless.

Quand choisir GCP : Vous construisez au sein de la plateforme Vertex AI et souhaitez des outils MLOps (pipelines, gestion de versions de modèles, expériences) en un seul endroit. C'est également le bon choix si votre modèle est trop grand pour SageMaker Serverless mais que vous souhaitez rester proche du sans serveur avec la mise à l'échelle automatique.

→ Voir le guide d'implémentation complet : Inférence GPU sans serveur sur GCP Vertex AI

L'approche GPU sans serveur d'Azure se divise clairement par cas d'utilisation.

Pour l'ajustement fin, Azure propose le modèle sans serveur le plus solide des trois plateformes. Vous vous connectez à votre projet Azure AI via AIProjectClient, obtenez un client OpenAI, téléchargez les données d'entraînement et soumettez un job d'ajustement fin. Azure alloue le calcul GPU pour la durée, le job se termine, et vous ne payez que pour ce qui a été exécuté. Il n'y a pas de point d'accès à gérer, pas de nombre de répliques à ajuster, et aucune préoccupation de démarrage à froid. Pour le cas d'utilisation de l'ajustement fin spécifiquement, c'est le modèle sans serveur le plus propre que j'aie rencontré sur n'importe quel cloud.

Pour l'inférence en temps réel sur des modèles personnalisés, Azure est le plus faible des trois. Les points d'accès en ligne gérés d'Azure Machine Learning prennent en charge les types d'instances GPU et la mise à l'échelle automatique, mais ils ne se mettent pas à l'échelle jusqu'à zéro — un minimum d'une instance doit rester en cours d'exécution. Cela les rend opérationnellement similaires à une instance dédiée gérée plutôt qu'à un véritable sans serveur. L'exception sont les points d'accès Azure OpenAI : ceux-ci sont entièrement gérés, se mettent à l'échelle de manière transparente et constituent le bon choix si votre charge de travail d'inférence concerne un modèle OpenAI pris en charge.

Quand choisir Azure : Vous effectuez un ajustement fin de modèles Azure OpenAI, votre organisation fonctionne déjà sur Azure, ou vous avez besoin des garanties de conformité et de résidence des données des régions européennes d'Azure. Ne choisissez pas Azure pour l'inférence sans serveur de modèles personnalisés si une mise à l'échelle jusqu'à zéro sans démarrage à froid est une exigence stricte.

→ Voir le guide d'implémentation complet : GPU sans serveur sur Azure — Ajustement fin et inférence avec AIProjectClient

NVIDIA n'est pas un concurrent cloud des trois cités ci-dessus — c'est le substrat sur lequel les trois fonctionnent. Le SKU GPU utilisé par votre fournisseur détermine directement la mémoire disponible, le débit de calcul et la tarification :

Les Microservices d'Inférence NVIDIA (NIMs) méritent une mention : ce sont des conteneurs optimisés et pré-construits pour des modèles populaires (LLaMA, Mistral, Stable Diffusion) qui s'exécutent de manière identique sur site ou dans n'importe quel GPU cloud compatible. Si la portabilité matérielle est une exigence — exécuter la même charge de travail sur GCP aujourd'hui et sur site le trimestre prochain — les NIMs sont la bonne couche d'abstraction à évaluer.

Commencez par la forme de votre charge de travail :

1. Modèle de fondation géré (pas de poids personnalisés) ? → Utilisez Bedrock (AWS), Vertex AI Model Garden (GCP) ou Azure OpenAI. Aucune gestion GPU nécessaire.
2. Modèle personnalisé, trafic sporadique, ≤ 6 Go de mémoire ? → AWS SageMaker Serverless Inference. Le modèle opérationnel le plus simple dans l'écosystème AWS.
3. Modèle personnalisé, trafic variable, besoin d'une grande mémoire GPU ou d'une intégration MLOps étroite ? → GCP Vertex AI avec min_replica_count=1.
4. Ajustement fin d'un modèle OpenAI ou exécution sur Azure OpenAI ? → Azure AIProjectClient. La meilleure expérience d'ajustement fin sans serveur des trois.
5. Inférence de modèle personnalisé sur Azure ? → Points d'accès en ligne gérés d'Azure ML, mais prévoyez un budget pour un minimum d'une instance en cours d'exécution.

L'accès GPU sans serveur a suffisamment mûri pour être le point de départ par défaut pour toute nouvelle charge de travail d'IA. Mais « sans serveur » signifie quelque chose de différent sur chaque plateforme, et le choix entre elles n'est pas principalement technique — il est opérationnel et organisationnel.

Choisissez AWS si votre équipe est déjà dans l'écosystème AWS et que vos modèles tiennent dans le plafond de mémoire de 6 Go. Choisissez GCP Vertex AI si vous avez besoin de la plateforme MLOps complète ou d'une grande marge GPU sans instances dédiées. Choisissez Azure si vous ajustez finement des modèles Azure OpenAI ou opérez dans une organisation axée sur Azure.

Les trois articles d'approfondissement de cette série décrivent pas à pas le déploiement sur chaque plateforme — des appels Terraform aux appels SDK et à l'instrumentation des coûts. Commencez par la plateforme la plus proche de votre infrastructure existante, mesurez pendant 30 jours et considérez la gouvernance FinOps comme une exigence de première classe dès le premier jour.