Los contenedores de aprendizaje profundo AWS Ray Serve toman el relevo donde termina el soporte de TorchServe

AWS ha publicado una ruta de migración de una sola GPU mediante AWS Ray Serve Deep Learning Containers, mientras TorchServe entra en una congelación de mantenimiento indefinida. El cambio es relevante porque los usuarios de TorchServe ya no cuentan con un framework de serving mantenido activamente bajo sus modelos PyTorch de producción. AWS ofrece en su lugar una pila de contenedores probada, aunque los equipos todavía deben reescribir sus aplicaciones de serving y operar la infraestructura circundante.

La nueva guía de migración despliega el modelo de visión y lenguaje Qwen3-VL-2B en Amazon Elastic Kubernetes Service, o Amazon EKS. Se ejecuta dentro de un pod en una instancia g5.xlarge, con una GPU NVIDIA A10G y 24 GB de memoria GPU. El ejemplo expone el modelo mediante un endpoint HTTP en el puerto 8000.

Este despliegue modesto revela un conflicto mayor. TorchServe antes reunía el archivado de modelos, los handlers, la configuración y el serving en un flujo de trabajo centrado en PyTorch. AWS Ray Serve Deep Learning Containers sustituyen ese framework por una imagen mantenida, código de aplicación Ray Serve y recursos estándar de Kubernetes. La responsabilidad operativa cambia de forma, en vez de desaparecer.

AWS convierte una brecha de soporte de TorchServe en una ruta de migración basada en contenedores

AWS responde a la congelación de mantenimiento de TorchServe con una pila de inferencia probada, no con un reemplazo directo.

La documentación oficial de TorchServe muestra ahora un aviso de mantenimiento limitado. Indica que el proyecto ya no recibe mantenimiento activo. Las versiones existentes siguen disponibles, pero no hay actualizaciones, correcciones de errores, funciones ni parches de seguridad previstos.

Esta advertencia modifica el cálculo de riesgos para los usuarios de producción. Una aplicación estable puede continuar funcionando con una versión existente de TorchServe. Sin embargo, cada nuevo requisito de framework, sistema operativo, CUDA o seguridad crea otra decisión de compatibilidad para el propietario de la aplicación.

La seguridad es lo más difícil de aplazar. El aviso de TorchServe advierte explícitamente que las vulnerabilidades podrían no ser corregidas. Las organizaciones pueden aislar los despliegues y parchear las capas circundantes, pero no pueden depender de futuras correcciones upstream para el framework de serving.

AWS presenta su Ray Serve Deep Learning Container, comúnmente llamado DLC, como una base compatible para estas cargas de trabajo. Un DLC es una imagen de contenedor con un framework seleccionado y dependencias relacionadas instaladas y probadas en conjunto. AWS publica imágenes Ray Serve separadas para Amazon EC2 y EKS, así como para Amazon SageMaker.

La imagen para GPU parte de una base NVIDIA Amazon Linux 2023. Esta base incluye el sistema operativo y las bibliotecas de tiempo de ejecución CUDA. AWS incorpora después PyTorch, Ray Serve, FastAPI, Uvicorn, Hugging Face Transformers y utilidades para procesamiento visual, de audio y multimodal.

La imagen también incluye una compilación de FFmpeg con aceleración de hardware NVIDIA para el preprocesamiento de vídeo. Este detalle importa a los equipos que sirven modelos que combinan fotogramas de vídeo, imágenes, audio y texto. Estas cargas de trabajo suelen requerir más que un framework de modelos y un servidor HTTP.

AWS afirma que valida conjuntamente los componentes incluidos antes de cada lanzamiento de imagen. Los parches de seguridad se aplican al crear la imagen. Este enfoque reduce la deriva de versiones entre el tiempo de ejecución CUDA, PyTorch, Ray Serve y la capa de serving web.

Esta promesa tiene un límite definido. AWS respalda y prueba la combinación del contenedor, mientras que los usuarios siguen siendo responsables de su código de modelo, configuración del clúster, controles de red, políticas de escalado y proceso de actualización. Una imagen mantenida reduce la superficie que los equipos deben ensamblar por sí mismos.

El ejemplo también evita presentar Ray Serve como un modo de compatibilidad transparente con TorchServe. Los ingenieros escriben una nueva clase de serving en Python y la despliegan mediante Ray Serve. No importan un archivo de TorchServe ni reutilizan toda su interfaz de gestión.

Esta distinción mantiene el anuncio en terreno firme. AWS Ray Serve Deep Learning Containers ofrecen un destino compatible para las cargas de trabajo afectadas. No automatizan una migración de producción ni eliminan la necesidad de realizar pruebas de despliegue.

Por qué los equipos de TorchServe ahora asumen una mayor parte de la pila GPU

El fin del mantenimiento activo de TorchServe transfiere la incertidumbre upstream directamente a los equipos de ingeniería de plataforma y aprendizaje automático.

Un servicio de inferencia con GPU depende de varias capas que evolucionan de forma independiente. Entre ellas se encuentran el sistema operativo, el tiempo de ejecución NVIDIA, las bibliotecas CUDA, PyTorch, las dependencias del modelo, el servidor de solicitudes y el entorno de orquestación. Los fallos de compatibilidad pueden aparecer incluso cuando el código del modelo no cambia.

TorchServe ofrecía anteriormente a los equipos de PyTorch una vía reconocible de empaquetado y serving. Los desarrolladores podían crear un archivo de modelo con torch-model-archiver, proporcionar un handler personalizado y controlar el comportamiento mediante config.properties. Ese flujo de trabajo generaba su propia complejidad, pero también aportaba una convención operativa compartida.

La congelación de mantenimiento elimina la confianza en que esta convención pueda seguir el ritmo del software adyacente. Los equipos pueden fijar todas las dependencias, pero fijarlas solo retrasa la siguiente decisión. Un parche del sistema operativo, un cambio de GPU o una actualización de framework acaba forzando la validación de toda la pila.

Seguir ejecutando TorchServe continúa siendo posible. El proyecto no ha desaparecido y sus versiones existentes todavía funcionan para muchos despliegues. El problema es que permanecer en él se convierte en una decisión deliberada de propiedad interna, en vez de una opción predeterminada con soporte.

Las organizaciones que adopten esa vía necesitan un proceso de seguridad claro. Deben supervisar las dependencias pertinentes, evaluar las interfaces expuestas, reconstruir imágenes y probar correcciones sin esperar nuevas versiones de TorchServe. También necesitan un plan para las vulnerabilidades dentro de TorchServe.

La alternativa es la migración, que genera trabajo de ingeniería inmediato. Los handlers y archivos de modelos de TorchServe no se convierten automáticamente en despliegues de Ray Serve. El análisis de solicitudes, el comportamiento de salud, las métricas, la carga de modelos, el procesamiento por lotes y la gestión de errores requieren comparación.

Ray Serve cambia el modelo de programación principal. Un desarrollador marca una clase de Python con @serve.deployment, inicializa el modelo dentro de esa clase y gestiona las solicitudes HTTP entrantes mediante __call__. Llamar a .bind() registra la aplicación para Ray Serve.

Este modelo puede parecer más simple que la estructura de archivos y handlers de TorchServe. También ofrece a los desarrolladores composición Python convencional y acceso directo a las declaraciones de recursos de Ray. Por ejemplo, el despliegue de AWS solicita una GPU mediante ray_actor_options={"num_gpus": 1}.

Sin embargo, un código de aplicación más simple no equivale a operaciones de producción más simples. Los equipos todavía necesitan comprobaciones de preparación, autenticación, gestión de tráfico, telemetría, controles de despliegue y procedimientos de reversión. Deben decidir cómo entran los pesos del modelo en el entorno y cómo se comportan las réplicas durante las actualizaciones.

El contenedor de AWS desplaza varias decisiones de compatibilidad upstream. AWS selecciona y prueba el sistema operativo base, el tiempo de ejecución CUDA, el framework y las dependencias de serving. Esto puede reducir el trabajo repetido de integración necesario para una imagen ensamblada internamente.

También crea una nueva dependencia de los lanzamientos de imágenes de AWS. Los equipos de plataforma deben seguir las etiquetas de imagen, revisar cambios, analizar las capas añadidas y cualificar las nuevas versiones en sus propios entornos. Una base probada es evidencia útil, pero no una certificación a nivel de aplicación.

Los equipos con requisitos de cumplimiento necesitan todavía más validación. Deben confirmar que el contenido de la imagen cumple las políticas internas y que las actualizaciones llegan dentro de los plazos requeridos. También necesitan listas de materiales de software y registros de gestión de vulnerabilidades para su imagen completa.

Por ello, la presión recae con mayor fuerza sobre los equipos con entornos TorchServe maduros. Han acumulado handlers, pasos de empaquetado, paneles y conocimiento operativo en torno a un framework. Pasar a Ray Serve implica invertir esa experiencia mientras el sistema anterior aún puede parecer estable.

Los despliegues más pequeños enfrentan un cálculo distinto. Si un servicio tiene un modelo y tráfico predecible, una pila completa de Ray y Kubernetes puede introducir maquinaria innecesaria. El valor depende de si la organización ya opera EKS y espera necesidades de escalado más amplias.

Cómo AWS Ray Serve Deep Learning Containers cambia el modelo de serving

El mecanismo central es la preintegración: AWS fija la pila base mientras Ray Serve sustituye el empaquetado y el ciclo de vida de solicitudes de TorchServe.

El ejemplo de AWS sirve Qwen/Qwen3-VL-2B-Instruct, un modelo de visión y lenguaje que procesa imágenes y texto. Acepta una URL de imagen y un prompt, y después devuelve una descripción o respuesta generada. El modelo encaja en el ejemplo porque pone a prueba tanto la inferencia con GPU como el preprocesamiento multimodal.

AWS carga el modelo mediante Hugging Face Transformers. Un AutoProcessor prepara la entrada multimodal, mientras AutoModelForImageTextToText carga el modelo con pesos de media precisión. A continuación, la aplicación mueve esos pesos al dispositivo CUDA.

La clase de serving recibe directamente la solicitud HTTP. Extrae la URL de la imagen y el prompt del JSON, prepara las entradas del modelo, ejecuta la generación y devuelve el resultado. FastAPI y Uvicorn proporcionan la base de serving web incluida en el DLC.

Este diseño elimina tres artefactos conocidos de TorchServe. No hay archivo de modelo TorchServe, jerarquía de handlers TorchServe ni archivo config.properties. El contrato de serving reside en la aplicación Ray Serve y su configuración de despliegue.

AWS inyecta esa aplicación Python mediante un ConfigMap de Kubernetes. Un ConfigMap almacena configuración no secreta o archivos que un pod puede montar en tiempo de ejecución. Esto permite a los ingenieros modificar el código de demostración sin reconstruir la imagen del contenedor.

Esta flexibilidad resulta útil durante la evaluación. Separa la lógica de serving de la imagen base probada y acorta el ciclo de editar-desplegar-probar. Sin embargo, los equipos de producción deben decidir si la configuración mutable se ajusta a sus requisitos de lanzamiento y auditoría.

Algunas organizaciones incorporarán la aplicación en una imagen derivada. Ese enfoque crea un artefacto inmutable que contiene tanto la base de AWS como el código de serving aprobado. Puede mejorar la reproducibilidad, aunque cada cambio de aplicación requiere una nueva compilación.

El despliegue reserva una GPU mediante el recurso Kubernetes nvidia.com/gpu. También selecciona el nodo GPU mediante la etiqueta role=gpu-worker. Estos ajustes ayudan a Kubernetes a ubicar el pod de inferencia en la instancia prevista.

Ray recibe la asignación de GPU mediante el entorno del contenedor y la declaración de la aplicación. La clase de modelo solicita una GPU, coincidiendo con la única GPU expuesta al pod. En configuraciones mayores, Ray puede programar despliegues a través de un conjunto de recursos declarados.

AWS proporciona tres scripts para el ejemplo. El primero crea el clúster EKS con eksctl, configuración de red, un proveedor OpenID Connect y complementos principales. El segundo añade el grupo de nodos GPU gestionado.

El tercer script aplica el ConfigMap y el despliegue de Kubernetes. Programa el pod Ray Serve en el nodo GPU e inicia el servicio en el puerto 8000. El repositorio de ejemplo adjunto pone estos artefactos de despliegue a disposición para su inspección.

Después del despliegue, los usuarios pueden inspeccionar el pod y verificar su asignación de GPU. Luego pueden redirigir el puerto local 8000 al despliegue en ejecución y enviar una solicitud HTTP que contenga una URL de imagen y un prompt. Ejecutar nvidia-smi dentro del pod confirma el uso de la GPU.

La secuencia de inicio expone un detalle operativo que los diseños de producción deben abordar. AWS señala que Kubernetes puede informar que el pod está listo antes de que Ray Serve responda solicitudes. Es posible que el modelo siga cargándose después de que el pod alcance ese estado.

Que se rechace la primera solicitud puede ser aceptable en una demostración, pero resulta peligroso detrás de tráfico de producción. Los equipos deben vincular la preparación con la disponibilidad de la aplicación, no solo con el estado del contenedor. La sonda debe seguir siendo fallida hasta que el modelo y el endpoint puedan atender solicitudes reales.

Las descargas de modelos añaden otra variable. La demostración obtiene el modelo cuando se inicializa la aplicación, lo que depende de la disponibilidad externa y del rendimiento de la red. Los equipos de producción pueden usar almacenamiento local, almacenamiento de objetos o una capa de imagen para controlar el comportamiento de inicio.

Los secretos también requieren un manejo independiente. Un ConfigMap no debe contener tokens de acceso ni credenciales privadas. Kubernetes Secrets, EKS Pod Identity u otro sistema de secretos aprobado deben proporcionar la autenticación necesaria.

Estas decisiones muestran qué es lo que realmente simplifica el DLC. Estandariza la base de software y proporciona un entorno de ejecución probado. No decide cómo una organización gestiona los modelos, los secretos, los artefactos de lanzamiento o la exposición del servicio.

La demostración de una sola GPU es un punto de partida, no un veredicto de producción

Un pod en una GPU demuestra la ruta de despliegue, pero no establece fiabilidad, eficiencia ni escalabilidad en producción.

AWS mantiene deliberadamente pequeña la arquitectura de referencia. El clúster EKS tiene un nodo GPU administrado basado en una instancia g5.xlarge. Un pod consume la GPU NVIDIA A10G del nodo y un proceso de Ray Serve expone el endpoint del modelo.

Esta disposición resulta útil para probar la migración. Un equipo puede traducir un handler, comprobar el comportamiento de las respuestas, comparar resultados y confirmar el acceso a la GPU sin diseñar primero un clúster distribuido. También facilita el aislamiento de fallos.

La misma simplicidad limita las conclusiones que los lectores deberían extraer. El ejemplo no muestra réplicas redundantes, paralelismo de modelos multinodo, escalado automático impulsado por el tráfico ni recuperación ante fallos entre zonas de disponibilidad. Tampoco publica resultados comparativos de latencia o rendimiento.

Sin esas mediciones, la publicación no puede establecer que Ray Serve superará a un despliegue concreto de TorchServe. El rendimiento depende del modelo, la forma de entrada, la concurrencia, el batching, la GPU, la ruta de preprocesamiento y los ajustes de generación. Los equipos de migración necesitan sus propias pruebas representativas.

La arquitectura también contiene un único punto de fallo del servicio. Si el pod se reinicia o el nodo GPU deja de estar disponible, el endpoint deja de responder hasta que Kubernetes lo restaure. Un servicio de producción suele necesitar réplicas adicionales o un objetivo de recuperación definido.

Escalar el diseño incorpora KubeRay, el operador de Kubernetes recomendado para gestionar clústeres Ray. La guía de despliegue de Kubernetes de Ray describe un recurso personalizado RayService que combina una configuración de clúster Ray con una aplicación Serve.

KubeRay puede gestionar pods de cabecera y workers, actualizaciones de aplicaciones y el ciclo de vida del clúster. También admite recursos de computación heterogéneos y escalado automático. Estas funciones hacen que Ray Serve sea más relevante para canalizaciones multimodelo o servicios que deben expandirse entre nodos.

También añaden conceptos operativos. Los equipos deben comprender la cabecera de Ray, los workers, el controlador Serve, las declaraciones de recursos, los recursos personalizados de Kubernetes y múltiples capas de registros. La resolución de problemas puede abarcar tanto los planos de control de Kubernetes como de Ray.

Ese equilibrio importa al comparar alternativas. Un equipo que sirve un único modelo transformer podría evaluar un endpoint independiente de vLLM. Una organización con múltiples formatos de modelo podría considerar NVIDIA Triton Inference Server. Los equipos centrados en Kubernetes podrían evaluar KServe para recursos de inferencia estandarizados.

Estas opciones resuelven problemas solapados, pero sus prioridades difieren. Ray Serve pone el énfasis en la composición de aplicaciones Python, la ejecución distribuida, las réplicas, el enrutamiento y el escalado. TorchServe centró su experiencia en el empaquetado y la publicación de modelos PyTorch.

AWS documenta por sí misma otras rutas de serving. Su actual guía de inferencia de EKS utiliza un Deep Learning Container de vLLM para un despliegue de LLM. Esto confirma que el DLC de Ray Serve es un patrón compatible, no un reemplazo universal.

La elección correcta depende de la carga de trabajo. Un servicio de visión y lenguaje con preprocesamiento personalizado puede beneficiarse de la composición nativa de Python de Ray Serve. Un endpoint estandarizado de generación de texto podría preferir un motor optimizado específicamente para modelos de lenguaje grandes.

La evaluación de migración debe comenzar con la paridad de interfaz. Los equipos necesitan comparar esquemas de solicitudes, respuestas de error, endpoints de salud, autenticación y tiempos de espera de los clientes. Después deben validar las salidas del modelo con un conjunto de pruebas controlado.

A continuación deben realizarse pruebas de carga. Los ingenieros deben medir el tiempo de arranque en frío, el tiempo hasta la primera respuesta, la latencia en estado estable, el rendimiento, la memoria de GPU y el comportamiento ante picos de tráfico. Las pruebas deben incluir la misma configuración de preprocesamiento y generación utilizada en producción.

Las pruebas de fallos son igualmente importantes. Los equipos deben terminar el pod, drenar el nodo, interrumpir el acceso al modelo y desplegar una revisión de aplicación no válida. Estas pruebas revelan si el reemplazo cumple las expectativas de recuperación y reversión.

La observabilidad necesita una correspondencia directa. Las métricas y paneles existentes de TorchServe no se transferirán sin cambios. Los operadores deben decidir qué métricas de Ray, la aplicación, Kubernetes y la GPU definen la salud, la saturación y la degradación percibida por el usuario.

Por último, los equipos necesitan un experimento de actualización. Deben pasar entre dos versiones de DLC en un entorno de staging y registrar los cambios de código, configuración y modelo necesarios. El soporte tiene un valor limitado si las actualizaciones rutinarias siguen siendo demasiado arriesgadas de desplegar.

Lo que los usuarios de TorchServe deberían vigilar a continuación

La siguiente prueba es determinar si AWS puede convertir un ejemplo de migración claro en una ruta fiable de lanzamiento y escalado.

La primera señal es la cadencia de lanzamientos del DLC de Ray Serve. Los equipos deben vigilar las etiquetas de imagen documentadas, las versiones de frameworks, las combinaciones de CUDA, las actualizaciones de seguridad y las políticas de retirada. Lanzamientos predecibles reforzarían el argumento de AWS de que la imagen reduce el trabajo de mantenimiento a largo plazo.

Las notas de lanzamiento importan tanto como la frecuencia de los lanzamientos. Los operadores necesitan saber qué dependencias cambiaron y si una actualización incluye comportamientos incompatibles. También necesitan suficiente solapamiento entre etiquetas compatibles para realizar pruebas antes de adoptar una nueva imagen.

La segunda señal es una guía de producción para la preparación, la carga de modelos y la recuperación ante fallos. El ejemplo actual reconoce que el pod puede parecer listo antes de que Ray Serve responda. Una referencia más sólida debería alinear la preparación de Kubernetes con un modelo cargado y un endpoint que responda.

Esa guía también debería cubrir el almacenamiento de modelos y el comportamiento de inicio. Descargar pesos durante la inicialización funciona para una demostración pequeña. Los despliegues más grandes necesitan cargas repetibles, credenciales controladas, almacenamiento adecuado y sondas de inicio dimensionadas para el calentamiento real del modelo.

La tercera señal es una ruta compatible desde una GPU hasta múltiples réplicas o nodos. AWS dirige a los lectores hacia KubeRay para el serving distribuido y el escalado horizontal. Los ejemplos futuros deberían mostrar cómo se comporta el DLC dentro de un despliegue RayService.

Una referencia con múltiples réplicas debería documentar el enrutamiento del tráfico, las actualizaciones graduales, las señales de escalado automático y la recuperación cuando desaparece un worker de GPU. También debería separar las cargas de trabajo de la cabecera de Ray de los workers de inferencia GPU, preservando la costosa capacidad de aceleración para los modelos.

Los equipos no deben esperar a que exista cada referencia antes de comenzar una evaluación. Pueden inventariar ahora los servicios de TorchServe y clasificarlos según exposición, importancia para el negocio y dificultad de migración. Los endpoints expuestos a internet merecen atención antes que los sistemas batch aislados.

Para cada servicio, los ingenieros pueden enumerar las funciones de TorchServe que se usan actualmente. Esto incluye archivos de modelos, handlers personalizados, workflows, batching, métricas, API de gestión y archivos de configuración. El inventario se convierte en una lista de verificación concreta para la migración a Ray Serve.

Una pequeña prueba de concepto debe preservar el contrato existente de solicitud y respuesta. Mantener los clientes sin cambios aísla la migración de la capa de serving de una reescritura más amplia de la aplicación. También permite una comparación controlada de tráfico entre los endpoints antiguo y nuevo.

La evaluación debe utilizar los mismos pesos del modelo y entradas representativas. Los equipos pueden comparar la consistencia de las salidas, la latencia, el rendimiento, la utilización de GPU y el comportamiento ante errores. También deben registrar cuánto tarda cada servicio en recuperarse después de un reinicio.

Los equipos de seguridad deben revisar la imagen resultante como un artefacto completo. La base de AWS puede recibir dependencias probadas y parches en tiempo de compilación, pero los paquetes añadidos localmente pueden reintroducir vulnerabilidades. El análisis debe continuar después de la personalización.

Los responsables de plataforma también deben definir la propiedad antes de la migración. AWS mantiene el DLC, Ray mantiene Ray Serve y la organización es propietaria de su aplicación y su despliegue EKS. Los límites claros evitan que un componente compatible se confunda con un servicio integral compatible.

La lección más amplia no es que todos los usuarios de TorchServe deban adoptar Ray Serve. Es que una capa de serving sin mantenimiento ahora exige una decisión explícita. Permanecer donde se está, migrar a Ray Serve o elegir otro servidor crea en cada caso un modelo de soporte diferente.

Los Deep Learning Containers de AWS Ray Serve hacen más concreta una de esas opciones. El nuevo ejemplo proporciona una base probada, un modelo de programación directo y un despliegue funcional de EKS con una sola GPU. También hace visibles las responsabilidades restantes.

Comience con un servicio representativo de TorchServe y pruebe la migración bajo patrones de tráfico reales. Si el DLC reduce el trabajo con dependencias sin debilitar la disponibilidad, merece un despliegue más amplio. Si la capa operativa de Ray supera ese beneficio, la prueba lo revelará pronto.