TorchServe ya no recibe mantenimiento activo. El aviso oficial del proyecto indica que no hay actualizaciones planificadas, correcciones de errores, nuevas funciones o parches de seguridad, y que es posible que no se aborden las vulnerabilidades. Para los equipos que ejecutan inferencia de modelos en TorchServe hoy en día, esto significa que se detienen los parches de seguridad y las actualizaciones de compatibilidad con versiones más recientes de PyTorch y CUDA. Los ingenieros son dueños de toda la cadena de dependencia: eligen versiones compatibles en toda la pila de GPU, parchean vulnerabilidades en cada capa y depuran fallas sutiles cuando algún componente se desalinea. Se trata de un trabajo indiferenciado que ralentiza la entrega del modelo sin añadir valor al producto final.
Los contenedores de aprendizaje profundo (DLC) de AWS han abordado durante mucho tiempo este tipo de problema para las cargas de trabajo de capacitación. Los DLC son imágenes de Docker prediseñadas y de rendimiento optimizado que agrupan un marco, sus dependencias y la pila de GPU en una combinación probada y parcheada que puede extraer y usar de inmediato. Con el lanzamiento del DLC Ray Serve, ese mismo enfoque ahora se extiende a la inferencia. Obtiene un contenedor diseñado específicamente para servir modelos detrás de un punto final HTTP, mantenido y probado por AWS, con la pila de inferencia completa ya ensamblada.
Esta publicación presenta el DLC Ray Serve y explica la implementación de un modelo de lenguaje de visión en Amazon Elastic Kubernetes Service (Amazon EKS) utilizando esta nueva imagen. Cubrimos la ejecución de un modelo con el DLC Ray Serve, la ejecución de la aplicación de servicio con Ray Serve y su implementación en un único nodo GPU. El código completo está disponible en el repositorio adjunto.
Requisitos previos
Para seguir esta publicación, necesita:
Una cuenta de AWS con facturación habilitada. Cuotas de servicio suficientes para instancias g5.xlarge en su región de destino. La interfaz de línea de comandos de AWS (AWS CLI), eksctl y kubectl instalados y configurados.
Redactar la aplicación Ray Serve
El DLC Ray Serve para CPU se basa en la imagen base de Amazon Linux 2023. La variante de GPU se basa en la imagen oficial de NVIDIA Amazon Linux 2023, que incluye tanto la capa del sistema operativo como las bibliotecas de tiempo de ejecución CUDA. Además de esta base, el DLC agrega un marco de aprendizaje profundo (PyTorch), la capa de servicio Ray Serve con FastAPI y Uvicorn, y utilidades comunes para cargas de trabajo multimodales, de audio y de visión. Estas utilidades incluyen FFmpeg compilado con aceleración de hardware NVIDIA para el preprocesamiento de video. Todos los componentes se validan y prueban juntos antes de cada lanzamiento, por lo que no hay variación de versiones entre el tiempo de ejecución de CUDA, el marco y la capa de servicio. Los parches de seguridad se aplican en el momento de la compilación.
El DLC Ray Serve se publica como imágenes independientes para Amazon EKS y Amazon Elastic Compute Cloud (Amazon EC2) y para Amazon SageMaker, cada uno con un punto de entrada dedicado adecuado al contrato de servicio de ese entorno. Ambos comparten la misma pila y dependencias subyacentes. Para obtener la lista actual de etiquetas de imágenes disponibles, consulte la página de imágenes disponibles del DLC de Ray.
El DLC incluye la pila de inferencia común, por lo que muchos modelos, incluido el modelo Qwen3-VL, se ejecutan en ella sin una imagen personalizada. Para los modelos que necesitan bibliotecas adicionales, los ingenieros pueden superponerlas en la misma base probada.
En esta publicación, utilizamos la versión GPU del DLC Ray Serve para servir el modelo de lenguaje de visión Qwen3-VL-2B. La aplicación se inyecta en el contenedor a través de ConfigMap, lo que mantiene la implementación flexible para que pueda cambiar el código de servicio sin reconstruir la imagen. DLC ya proporciona la pila de GPU, PyTorch, Ray Serve y Transformers.
Escribe la aplicación de entrega.
Con Ray Serve, un punto final modelo es una clase de Python decorada con @servir.despliegue. Implementas __call__ para manejar solicitudes HTTP y llamas a .bind() para registrarlo. No hay un archivador de modelos, ni una jerarquía de clases de controlador, ni un archivo de configuración de propiedades. Si viene de TorchServe, esto reemplaza el controlador personalizado, el paso torch-model-archiver y el archivo config.properties.
El siguiente ejemplo carga el modelo de lenguaje de visión Qwen3-VL-2B en la GPU y lo expone como un punto final HTTP. Cuando llega una solicitud con la URL de una imagen y un mensaje de texto, el modelo genera una respuesta en lenguaje natural que describe o responde preguntas sobre la imagen:
Toda la lógica de publicación en qwen_serve.py se agrega a un ConfigMap de código qwen-serve. El decorador @serve.deployment con ray_actor_options={“num_gpus”: 1} le dice a Ray que programe esta implementación en un trabajador con una GPU disponible. El modelo se carga en float16 para caber dentro de los 24 GB de VRAM disponibles en la GPU A10G utilizada en la siguiente sección.
Implementar en Amazon EKS
Implemente el DLC Ray Serve junto con el ConfigMap qwen-serve-code creado anteriormente. El siguiente diagrama muestra la arquitectura de destino: un clúster de Amazon EKS con un único nodo de GPU que ejecuta un pod que sirve el modelo a través de HTTP en el puerto 8000.
Figura 1: Arquitectura de inferencia de un solo nodo en Amazon EKS, con un pod de GPU que atiende el modelo a través de HTTP en el puerto 8000
Esta implementación utiliza una única instancia g5.xlarge (una GPU NVIDIA A10G, 24 GB de VRAM). Es una configuración de inferencia de un solo nodo: un pod, una GPU, una máquina. Para el servicio distribuido de múltiples nodos (paralelismo de modelos entre máquinas o escalado automático horizontal con múltiples réplicas), se construiría sobre esta base utilizando KubeRay para orquestar los trabajadores de Ray en todos los nodos.
El repositorio adjunto incluye scripts que automatizan la configuración de la infraestructura:
implementar_cluster.sh aprovisiona un clúster EKS mediante eksctl, con redes de nube privada virtual (VPC), un proveedor de OIDC para la autenticación de pods basada en AWS Identity and Access Management (IAM) y complementos del clúster principal. implementar_node_group.sh agrega un grupo de nodos de GPU administrado con una única instancia g5.xlarge etiquetada role=gpu-worker. implementar_ray_cluster.sh aplica un ConfigMap con qwen_serve.py, implementa un manifiesto de implementación de Kubernetes que programa el pod en el nodo GPU e inicia Ray Serve en el puerto 8000. Después de ejecutar los tres scripts, verifique que el pod se esté ejecutando y que la GPU esté asignada:
Con el informe del pod listo, reenvíe el puerto para que podamos probarlo.
En una terminal nueva, envíe una solicitud que solicite al modelo de lenguaje de visión Qwen3-VL-2B que describa una imagen:
Debería recibir una respuesta JSON con la descripción de la imagen del modelo. Para confirmar que la inferencia se está ejecutando en la GPU:
Nota: El pod informa Listo uno o dos minutos antes de que Ray Serve comience a responder, porque el modelo aún se está cargando. Si se rechaza la primera solicitud, espere un minuto e intente realizar la solicitud nuevamente.
Limpiar
Para evitar cargos continuos, elimine los recursos en orden inverso:
Conclusión y próximos pasos
En este punto, tiene un punto final de inferencia funcional y llegó allí sin mantener la compatibilidad con CUDA, sin escribir el texto estándar del controlador TorchServe y sin ensamblar un Dockerfile de varias etapas que une la pila de GPU. Para eso está diseñado el DLC Ray Serve: proporcionar un contenedor compatible y probado previamente para que pueda concentrarse en el código del modelo en lugar del mantenimiento de la infraestructura.
Para los equipos que actualmente están en TorchServe, este es un camino de migración sólido. El DLC elimina la variación de versiones, simplifica las actualizaciones a un intercambio de etiquetas y proporciona parches de seguridad periódicos administrados por AWS. Para cargas de trabajo que necesitan escalar más allá de un solo nodo, KubeRay extiende esta misma base al servicio distribuido de múltiples nodos.
Para comenzar, pruebe el ejemplo de código adjunto para una implementación completa de un extremo a otro. Para explorar todas las imágenes DLC disponibles, incluidas las variantes de CPU y otros marcos, visite la referencia de contenedores de aprendizaje profundo de AWS.
Sobre los autores
Ananth Raghavendra
Jinyan Li