Les conteneurs AWS Ray Serve Deep Learning prennent le relais à la fin du support de TorchServe

AWS a publié une voie de migration mono-GPU utilisant les conteneurs AWS Ray Serve Deep Learning, alors que TorchServe entre dans une phase de maintenance indéfinie. Ce changement est important, car les utilisateurs de TorchServe ne disposent plus d’un framework de serving activement maintenu sous leurs modèles PyTorch de production. AWS propose à la place une pile de conteneurs éprouvée, mais les équipes doivent toujours réécrire leurs applications de serving et exploiter l’infrastructure environnante.

Le nouveau guide de migration déploie le modèle vision-langage Qwen3-VL-2B sur Amazon Elastic Kubernetes Service, ou Amazon EKS. Il s’exécute dans un pod sur une instance g5.xlarge équipée d’un GPU NVIDIA A10G et de 24 Go de mémoire GPU. L’exemple expose le modèle via un point de terminaison HTTP sur le port 8000.

Ce déploiement modeste révèle un enjeu plus large. TorchServe regroupait autrefois l’archivage des modèles, les handlers, la configuration et le serving dans un flux de travail centré sur PyTorch. Les conteneurs AWS Ray Serve Deep Learning remplacent ce framework par une image maintenue, du code d’application Ray Serve et des ressources Kubernetes standard. La responsabilité opérationnelle change de forme plutôt que de disparaître.

AWS transforme le manque de support de TorchServe en voie de migration par conteneur

AWS répond au gel de maintenance de TorchServe avec une pile d’inférence éprouvée, et non avec un remplacement direct.

La documentation officielle de TorchServe affiche désormais un avis de maintenance limitée. Il indique que le projet n’est plus activement maintenu. Les versions existantes restent disponibles, mais aucune mise à jour, correction de bug, fonctionnalité ou mise à jour de sécurité n’est prévue.

Cet avertissement modifie le calcul du risque pour les utilisateurs en production. Une application stable peut continuer à fonctionner sur une version existante de TorchServe. Toutefois, chaque nouvelle exigence liée au framework, au système d’exploitation, à CUDA ou à la sécurité crée une nouvelle décision de compatibilité pour le propriétaire de l’application.

La sécurité est la partie la plus difficile à différer. L’avis TorchServe prévient explicitement que les vulnérabilités pourraient ne pas être corrigées. Les organisations peuvent isoler les déploiements et corriger les couches environnantes, mais elles ne peuvent pas compter sur de futures corrections amont du framework de serving.

AWS positionne son conteneur Ray Serve Deep Learning, couramment appelé DLC, comme une base prise en charge pour ces charges de travail. Un DLC est une image de conteneur intégrant un framework sélectionné et les dépendances associées, installés et testés ensemble. AWS publie des images Ray Serve distinctes pour Amazon EC2 et EKS, ainsi que pour Amazon SageMaker.

L’image GPU démarre avec une base NVIDIA Amazon Linux 2023. Cette base inclut le système d’exploitation et les bibliothèques d’exécution CUDA. AWS y ajoute ensuite PyTorch, Ray Serve, FastAPI, Uvicorn, Hugging Face Transformers et des utilitaires pour le traitement de la vision, de l’audio et du multimodal.

L’image comprend également une version de FFmpeg avec accélération matérielle NVIDIA pour le prétraitement vidéo. Ce détail est important pour les équipes servant des modèles combinant images vidéo, images fixes, audio et texte. Ces charges de travail exigent souvent davantage qu’un framework de modèle et un serveur HTTP.

AWS indique valider ensemble les composants inclus avant chaque publication d’image. Les correctifs de sécurité sont appliqués lors de la construction de l’image. Cette approche réduit la dérive de versions entre le runtime CUDA, PyTorch, Ray Serve et la couche de serving web.

Cette promesse a une limite bien définie. AWS prend en charge et teste la combinaison de conteneurs, tandis que les utilisateurs restent responsables de leur code modèle, de la configuration du cluster, des contrôles réseau, des politiques de mise à l’échelle et du processus de mise à niveau. Une image maintenue réduit la surface que les équipes doivent assembler elles-mêmes.

L’exemple évite également de présenter Ray Serve comme un mode de compatibilité TorchServe transparent. Les ingénieurs écrivent une nouvelle classe Python de serving et la déploient via Ray Serve. Ils n’importent pas d’archive TorchServe et ne réutilisent pas l’ensemble de son interface de gestion.

Cette distinction maintient l’annonce dans un cadre réaliste. Les conteneurs AWS Ray Serve Deep Learning offrent une destination prise en charge pour les charges de travail concernées. Ils ne rendent pas une migration de production automatique et ne suppriment pas le besoin de tests de déploiement.

Pourquoi les équipes TorchServe possèdent désormais une plus grande part de la pile GPU

La fin de la maintenance active de TorchServe transfère directement l’incertitude amont aux équipes d’ingénierie des plateformes et du machine learning.

Un service d’inférence GPU dépend de plusieurs couches qui évoluent indépendamment. Elles comprennent le système d’exploitation, le runtime NVIDIA, les bibliothèques CUDA, PyTorch, les dépendances du modèle, le serveur de requêtes et l’environnement d’orchestration. Des échecs de compatibilité peuvent survenir même lorsque le code du modèle ne change pas.

TorchServe offrait auparavant aux équipes PyTorch une voie reconnaissable de packaging et de serving. Les développeurs pouvaient créer une archive de modèle avec torch-model-archiver, fournir un handler personnalisé et contrôler le comportement via config.properties. Ce flux de travail créait sa propre complexité, mais il apportait aussi une convention opérationnelle partagée.

Le gel de maintenance retire la certitude que cette convention suivra le rythme des logiciels adjacents. Les équipes peuvent figer chaque dépendance, mais ce gel ne fait que repousser la prochaine décision. Un correctif de système d’exploitation, un changement de GPU ou une mise à niveau de framework finit par imposer une validation sur l’ensemble de la pile.

Continuer à exécuter TorchServe reste possible. Le projet n’a pas disparu et ses versions existantes fonctionnent encore pour de nombreux déploiements. Le problème est que le maintien de cette solution devient un choix délibéré de propriété interne plutôt qu’une option prise en charge par défaut.

Les organisations qui suivent cette voie ont besoin d’un processus de sécurité clair. Elles doivent surveiller les dépendances pertinentes, évaluer les interfaces exposées, reconstruire les images et tester les correctifs sans attendre de nouvelles versions de TorchServe. Elles ont également besoin d’un plan pour les vulnérabilités au sein même de TorchServe.

L’alternative est la migration, qui crée immédiatement du travail d’ingénierie. Les handlers et archives de modèles TorchServe ne deviennent pas automatiquement des déploiements Ray Serve. L’analyse des requêtes, le comportement de santé, les métriques, le chargement des modèles, le batching et la gestion des erreurs doivent tous être comparés.

Ray Serve modifie le modèle de programmation principal. Un développeur marque une classe Python avec @serve.deployment, initialise le modèle dans cette classe et traite les requêtes HTTP entrantes via __call__. L’appel à .bind() enregistre l’application pour Ray Serve.

Ce modèle peut sembler plus simple que la structure d’archives et de handlers de TorchServe. Il donne aussi aux développeurs une composition Python ordinaire et un accès direct aux déclarations de ressources de Ray. Par exemple, le déploiement AWS demande un GPU via ray_actor_options={"num_gpus": 1}.

Pourtant, un code applicatif plus simple ne signifie pas des opérations de production plus simples. Les équipes ont toujours besoin de contrôles de disponibilité, d’authentification, de gestion du trafic, de télémétrie, de contrôles de déploiement et de procédures de restauration. Elles doivent décider comment les poids du modèle entrent dans l’environnement et comment les réplicas se comportent lors des mises à jour.

Le conteneur AWS déplace plusieurs choix de compatibilité vers l’amont. AWS sélectionne et teste le système d’exploitation de base, le runtime CUDA, le framework et les dépendances de serving. Cela peut réduire le travail d’intégration répété requis pour une image assemblée en interne.

Il crée également une nouvelle dépendance aux publications d’images AWS. Les équipes de plateforme doivent suivre les balises d’image, examiner les changements, analyser les couches qu’elles ajoutent et qualifier les nouvelles versions dans leurs propres environnements. Une base testée constitue une preuve utile, mais pas une certification au niveau de l’application.

Les équipes soumises à des exigences de conformité ont besoin de validations encore plus poussées. Elles doivent confirmer que le contenu de l’image respecte les politiques internes et que les mises à jour arrivent dans les délais requis. Elles ont également besoin de nomenclatures logicielles et d’enregistrements de gestion des vulnérabilités pour leur image complète.

La pression pèse donc le plus lourdement sur les équipes disposant d’environnements TorchServe matures. Elles ont accumulé des handlers, des étapes de packaging, des tableaux de bord et des connaissances opérationnelles autour d’un framework. Passer à Ray Serve signifie mobiliser cette expertise alors que l’ancien système peut encore sembler stable.

Les déploiements plus modestes font face à un calcul différent. Si un service ne comporte qu’un modèle et un trafic prévisible, une pile Ray et Kubernetes complète peut introduire une complexité inutile. La valeur dépend de la question de savoir si l’organisation exploite déjà EKS et prévoit des besoins de montée en charge plus larges.

Comment les conteneurs AWS Ray Serve Deep Learning modifient le modèle de serving

Le mécanisme central est la préintégration : AWS fixe la pile de base tandis que Ray Serve remplace le packaging et le cycle de vie des requêtes de TorchServe.

L’exemple AWS sert Qwen/Qwen3-VL-2B-Instruct, un modèle vision-langage qui traite les images et le texte. Il accepte une URL d’image et un prompt, puis renvoie une description ou une réponse générée. Le modèle convient à l’exemple, car il sollicite à la fois l’inférence GPU et le prétraitement multimodal.

AWS charge le modèle via Hugging Face Transformers. Un AutoProcessor prépare l’entrée multimodale, tandis que AutoModelForImageTextToText charge le modèle avec des poids en demi-précision. L’application déplace ensuite ces poids vers le périphérique CUDA.

La classe de serving reçoit directement la requête HTTP. Elle extrait l’URL de l’image et le prompt du JSON, prépare les entrées du modèle, exécute la génération et renvoie le résultat. FastAPI et Uvicorn fournissent la base de serving web incluse dans le DLC.

Cette conception supprime trois artefacts TorchServe familiers. Il n’y a pas d’archive de modèle TorchServe, pas de hiérarchie de handlers TorchServe et pas de fichier config.properties. Le contrat de serving réside dans l’application Ray Serve et sa configuration de déploiement.

AWS injecte cette application Python via une ConfigMap Kubernetes. Une ConfigMap stocke une configuration ou des fichiers non secrets qu’un pod peut monter au moment de l’exécution. Cela permet aux ingénieurs de modifier le code de démonstration sans reconstruire l’image de conteneur.

Cette flexibilité est utile lors de l’évaluation. Elle sépare la logique de serving de l’image de base testée et raccourcit la boucle modification-déploiement-test. Toutefois, les équipes de production doivent décider si une configuration mutable correspond à leurs exigences de publication et d’audit.

Certaines organisations intégreront plutôt l’application dans une image dérivée. Cette approche crée un artefact immuable contenant à la fois la base AWS et le code de serving approuvé. Elle peut améliorer la reproductibilité, bien que chaque modification de l’application exige une nouvelle construction.

Le déploiement réserve un GPU avec la ressource Kubernetes nvidia.com/gpu. Il sélectionne également le nœud GPU à l’aide du label role=gpu-worker. Ces paramètres aident Kubernetes à placer le pod d’inférence sur l’instance prévue.

Ray reçoit l’allocation GPU via l’environnement du conteneur et la déclaration de l’application. La classe de modèle demande un GPU, correspondant au GPU unique exposé au pod. Dans des configurations plus importantes, Ray peut planifier les déploiements sur un pool de ressources déclarées.

AWS fournit trois scripts autour de l’exemple. Le premier crée le cluster EKS avec eksctl, la configuration réseau, un fournisseur OpenID Connect et des modules complémentaires essentiels. Le second ajoute le groupe de nœuds GPU géré.

Le troisième script applique la ConfigMap et le déploiement Kubernetes. Il planifie le pod Ray Serve sur le nœud GPU et démarre le service sur le port 8000. Le dépôt d’exemple associé met ces artefacts de déploiement à disposition pour inspection.

Après le déploiement, les utilisateurs peuvent inspecter le pod et vérifier son allocation GPU. Ils peuvent ensuite rediriger le port local 8000 vers le déploiement en cours d’exécution et envoyer une requête HTTP contenant une URL d’image et une invite. L’exécution de nvidia-smi dans le pod confirme l’utilisation du GPU.

La séquence de démarrage révèle un détail opérationnel que les architectures de production doivent prendre en compte. AWS indique que Kubernetes peut signaler que le pod est prêt avant que Ray Serve ne réponde aux requêtes. Le modèle peut encore être en cours de chargement après que le pod a atteint cet état.

Le refus d’une première requête est acceptable dans une démonstration, mais dangereux face à du trafic de production. Les équipes doivent relier l’état de préparation à la disponibilité de l’application, et non au seul état du conteneur. La sonde doit rester en échec tant que le modèle et le point de terminaison ne peuvent pas traiter de véritables requêtes.

Les téléchargements de modèles ajoutent une autre variable. La démonstration récupère le modèle lors de l’initialisation de l’application, ce qui dépend de la disponibilité externe et du débit réseau. Les équipes de production peuvent utiliser un stockage local, un stockage objet ou une couche d’image pour maîtriser le comportement au démarrage.

Les secrets exigent également une gestion distincte. Une ConfigMap ne doit pas contenir de jetons d’accès ni d’identifiants privés. Kubernetes Secrets, EKS Pod Identity ou un autre système de gestion des secrets approuvé doivent fournir l’authentification requise.

Ces décisions montrent ce que le DLC simplifie réellement. Il standardise la base logicielle et fournit un environnement d’exécution testé. Il ne décide pas de la manière dont une organisation gère les modèles, les secrets, les artefacts de publication ou l’exposition du service.

La démo sur un seul GPU est un point de départ, pas une validation de production

Un pod sur un GPU prouve le chemin de déploiement, mais n’établit ni la fiabilité, ni l’efficacité, ni la capacité de mise à l’échelle en production.

AWS maintient délibérément une architecture de référence réduite. Le cluster EKS dispose d’un nœud GPU géré fondé sur une instance g5.xlarge. Un pod consomme le GPU NVIDIA A10G du nœud, et un processus Ray Serve expose le point de terminaison du modèle.

Cette configuration est utile pour les tests de migration. Une équipe peut traduire un gestionnaire, vérifier le comportement des réponses, comparer les sorties et confirmer l’accès au GPU sans devoir d’abord concevoir un cluster distribué. Elle facilite également l’isolement des défaillances.

Cette même simplicité limite les conclusions que les lecteurs peuvent en tirer. L’exemple ne montre ni réplicas redondants, ni parallélisme de modèle multi-nœuds, ni autoscaling piloté par le trafic, ni reprise après défaillance entre zones de disponibilité. Il ne publie pas non plus de résultats comparatifs de latence ou de débit.

Sans ces mesures, l’article ne peut pas établir que Ray Serve surpassera un déploiement TorchServe donné. Les performances dépendent du modèle, de la forme des entrées, de la concurrence, du traitement par lots, du GPU, de la chaîne de prétraitement et des paramètres de génération. Les équipes de migration doivent mener leurs propres tests représentatifs.

L’architecture comporte également un point unique de défaillance du service. Si le pod redémarre ou que le nœud GPU devient indisponible, le point de terminaison cesse de répondre jusqu’à ce que Kubernetes le restaure. Un service de production nécessite généralement des réplicas supplémentaires ou un objectif de récupération défini.

Le passage à l’échelle de cette conception introduit KubeRay, l’opérateur Kubernetes recommandé pour gérer les clusters Ray. Le guide de déploiement Kubernetes de Ray décrit une ressource personnalisée RayService qui associe une configuration de cluster Ray à une application Serve.

KubeRay peut gérer les pods head et worker, les mises à jour des applications et le cycle de vie du cluster. Il prend également en charge des ressources de calcul hétérogènes et l’autoscaling. Ces fonctionnalités rendent Ray Serve plus pertinent pour les pipelines multi-modèles ou les services devant s’étendre sur plusieurs nœuds.

Elles ajoutent également des concepts opérationnels. Les équipes doivent comprendre le head Ray, les workers, le contrôleur Serve, les déclarations de ressources, les ressources personnalisées Kubernetes et plusieurs couches de journaux. Le dépannage peut couvrir à la fois les plans de contrôle Kubernetes et Ray.

Ce compromis est important lors de la comparaison des alternatives. Une équipe servant un unique modèle transformer pourrait évaluer un point de terminaison vLLM autonome. Une organisation utilisant plusieurs formats de modèles pourrait envisager NVIDIA Triton Inference Server. Les équipes centrées sur Kubernetes pourraient évaluer KServe pour des ressources d’inférence standardisées.

Ces options résolvent des problèmes qui se recoupent, mais leurs priorités diffèrent. Ray Serve met l’accent sur la composition d’applications Python, l’exécution distribuée, les réplicas, le routage et la mise à l’échelle. TorchServe fondait son expérience sur le packaging et le service de modèles PyTorch.

AWS documente elle-même d’autres voies de serving. Son actuel guide d’inférence EKS utilise un Deep Learning Container vLLM pour un déploiement LLM. Cela confirme que le DLC Ray Serve constitue un modèle pris en charge parmi d’autres, plutôt qu’un remplacement universel.

Le bon choix dépend de la charge de travail. Un service vision-langage avec un prétraitement personnalisé peut bénéficier de la composition native Python de Ray Serve. Un point de terminaison standardisé de génération de texte pourrait privilégier un moteur optimisé spécifiquement pour les grands modèles de langage.

L’évaluation de la migration doit commencer par la parité des interfaces. Les équipes doivent comparer les schémas de requêtes, les réponses d’erreur, les points de terminaison de santé, l’authentification et les délais d’expiration côté client. Elles doivent ensuite valider les sorties du modèle sur un jeu de tests contrôlé.

Des tests de charge doivent suivre. Les ingénieurs doivent mesurer le temps de démarrage à froid, le délai avant la première réponse, la latence en régime établi, le débit, la mémoire GPU et le comportement lors de pics de charge. Les tests doivent inclure la même configuration de prétraitement et de génération que celle utilisée en production.

Les tests de défaillance sont tout aussi importants. Les équipes doivent arrêter le pod, évacuer le nœud, interrompre l’accès au modèle et déployer une révision d’application invalide. Ces tests révèlent si le remplacement répond aux attentes en matière de récupération et de retour en arrière.

L’observabilité nécessite une correspondance directe. Les métriques et tableaux de bord TorchServe existants ne seront pas transférés tels quels. Les opérateurs doivent décider quelles métriques Ray, applicatives, Kubernetes et GPU définissent la santé, la saturation et la dégradation visible par les utilisateurs.

Enfin, les équipes ont besoin d’une expérience de mise à niveau. Elles doivent passer d’une version de DLC à une autre dans un environnement de préproduction et consigner les changements nécessaires au niveau du code, de la configuration et des modèles. Le support a une valeur limitée si les mises à niveau courantes restent trop risquées à déployer.

Ce que les utilisateurs de TorchServe doivent surveiller ensuite

Le prochain test sera de savoir si AWS peut transformer un exemple de migration clair en un parcours de publication et de mise à l’échelle fiable.

Le premier signal est la cadence de publication du DLC Ray Serve. Les équipes doivent surveiller les balises d’image documentées, les versions de frameworks, les combinaisons CUDA, les mises à jour de sécurité et les politiques de retrait. Des publications prévisibles renforceraient l’argument d’AWS selon lequel l’image réduit le travail de maintenance à long terme.

Les notes de version comptent autant que la fréquence des publications. Les opérateurs doivent savoir quelles dépendances ont changé et si une mise à jour introduit des comportements incompatibles. Ils ont également besoin d’un chevauchement suffisant entre les balises prises en charge pour tester avant d’adopter une nouvelle image.

Le deuxième signal concerne les recommandations de production pour l’état de préparation, le chargement des modèles et la récupération après défaillance. L’exemple actuel reconnaît que le pod peut sembler prêt avant que Ray Serve ne réponde. Une référence plus solide devrait aligner l’état de préparation Kubernetes sur un modèle chargé et un point de terminaison réactif.

Ces recommandations doivent également couvrir le stockage des modèles et le comportement au démarrage. Télécharger les poids pendant l’initialisation convient à une petite démonstration. Les déploiements plus importants nécessitent un chargement reproductible, des identifiants contrôlés, un stockage adapté et des sondes de démarrage dimensionnées pour le véritable préchauffage du modèle.

Le troisième signal est un chemin pris en charge passant d’un GPU à plusieurs réplicas ou nœuds. AWS oriente les lecteurs vers KubeRay pour le serving distribué et la mise à l’échelle horizontale. Les futurs exemples devraient montrer comment le DLC se comporte dans un déploiement RayService.

Une référence multi-réplicas devrait documenter le routage du trafic, les mises à jour progressives, les signaux d’autoscaling et la récupération lorsqu’un worker GPU disparaît. Elle devrait également séparer les charges de travail du head Ray des workers d’inférence GPU, afin de préserver la capacité coûteuse des accélérateurs pour les modèles.

Les équipes ne doivent pas attendre chaque référence avant de commencer une évaluation. Elles peuvent dès maintenant inventorier les services TorchServe et les classer selon leur exposition, leur importance métier et leur difficulté de migration. Les points de terminaison exposés à Internet méritent une attention plus précoce que les systèmes de traitement par lots isolés.

Pour chaque service, les ingénieurs peuvent répertorier les fonctionnalités TorchServe actuellement utilisées. Cela inclut les archives de modèles, les gestionnaires personnalisés, les workflows, le traitement par lots, les métriques, les API de gestion et les fichiers de configuration. Cet inventaire devient une liste de contrôle concrète pour la migration vers Ray Serve.

Une petite preuve de concept devrait préserver le contrat de requête et de réponse existant. Conserver les clients inchangés isole la migration de la couche de serving d’une réécriture plus large de l’application. Cela permet également une comparaison contrôlée du trafic entre les anciens et les nouveaux points de terminaison.

L’évaluation doit utiliser les mêmes poids de modèle et des entrées représentatives. Les équipes peuvent comparer la cohérence des sorties, la latence, le débit, l’utilisation du GPU et le comportement des erreurs. Elles doivent également enregistrer le temps nécessaire à chaque service pour se rétablir après un redémarrage.

Les équipes de sécurité doivent examiner l’image obtenue comme un artefact complet. La base AWS peut recevoir des dépendances testées et des correctifs appliqués lors de la compilation, mais les packages ajoutés localement peuvent réintroduire des vulnérabilités. L’analyse doit se poursuivre après la personnalisation.

Les propriétaires de plateforme doivent également définir les responsabilités avant la migration. AWS maintient le DLC, Ray maintient Ray Serve, et l’organisation est responsable de son application et de son déploiement EKS. Des frontières claires évitent de confondre un composant pris en charge avec un service de bout en bout pris en charge.

La leçon générale n’est pas que chaque utilisateur de TorchServe doit adopter Ray Serve. C’est qu’une couche de serving non maintenue exige désormais une décision explicite. Rester en place, migrer vers Ray Serve ou choisir un autre serveur crée dans chaque cas un modèle de support différent.

Les Deep Learning Containers Ray Serve d’AWS rendent l’un de ces choix plus concret. Le nouvel exemple fournit une base testée, un modèle de programmation direct et un déploiement EKS fonctionnel sur un seul GPU. Il rend également visibles les responsabilités restantes.

Commencez par un service TorchServe représentatif et testez la migration selon des schémas de trafic réels. Si le DLC réduit le travail lié aux dépendances sans affaiblir la disponibilité, il mérite un déploiement plus large. Si la couche opérationnelle de Ray l’emporte sur ce bénéfice, le test le révélera rapidement.