Desplegad modelos de ML en producción con escalado automático

La brecha de despliegue en producción: por qué la mayoría de los modelos de ML nunca salen del cuaderno

Un modelo entrenado en un cuaderno y un modelo que responde a solicitudes en vivo son problemas de ingeniería diferentes. El segundo es un entorno de despliegue con requisitos de disponibilidad, latencia y escalado, y es donde se estancan la mayoría de los modelos de aprendizaje automático en producción.

Lo que se necesita para servir un modelo a escala (clúster, entrada, escalado automático, monitorización)

La selección y el entrenamiento del modelo son problemas previos. El camino clásico para servir modelos en producción es un proceso separado, un proceso que requiere un clúster, un controlador de entrada, una política de escalado, una pila de monitorización y una tubería de lanzamiento. Cada uno es una decisión que necesita un responsable. Un científico de datos que ha terminado el desarrollo del modelo ahora necesita redes de clúster, reglas de equilibrio de carga y un backend de métricas antes de que un usuario vea una predicción.

La lista de verificación: un tiempo de ejecución de contenedores, reglas de entrada, políticas de escalado, gestión de secretos y datos, envío de registros, tuberías de lanzamiento, además de una cadena de herramientas para mantener cada uno. Cada elemento es esencial, requiere propiedad técnica y ninguna de estas herramientas mejora el modelo.

Para un equipo pequeño, eso supone semanas de trabajo antes de que aparezca cualquier valor comercial, y no se detiene en el lanzamiento. El resultado es familiar: el desarrollo del modelo tiene éxito, el despliegue se estanca y el artefacto espera una infraestructura que nadie tiene tiempo de construir.

Por qué una VM propia + Flask + nginx falla con tráfico real

El atajo es una máquina virtual ejecutando una aplicación Flask detrás de nginx. Funciona en pruebas y falla en producción. Un servidor es un punto único de fallo. La ausencia de escalado automático significa que un pico de carga pone en cola las solicitudes hasta que la latencia es inaceptable. Al no ser una versión continua, cada nueva versión implica tiempo de inactividad.

También oculta un problema de costes: la instancia se ejecuta continuamente tanto si el endpoint atiende mil solicitudes al día como si no atiende ninguna, y alguien sigue parcheando el SO y renovando los certificados. Eficiente de configurar, caro de mantener.

El coste oculto de las instancias de GPU inactivas en los endpoints de los hiperescaladores

Los endpoints de inferencia gestionados en los grandes hiperescaladores resuelven la disponibilidad, pero mantienen la instancia de computación funcionando las 24 horas. Un endpoint de GPU dimensionado para un pico diurno se sigue facturando a las 3 de la madrugada sin nada que atender, y el tiempo de inactividad ocupa la mayor parte del día.

La utilización es la métrica que importa. Un endpoint que atiende unos pocos miles de solicitudes al día en una GPU dimensionada para el pico puede utilizar una pequeña fracción de lo que paga, cada día, durante meses. Las instancias de GPU en la nube tienen sentido cuando la carga es constante, pero una instancia por hora es la unidad incorrecta para una demanda que llega en ráfagas.

Facturación por réplica y por minuto en lugar de instancias siempre activas

La facturación es por réplica y por minuto. Un despliegue que mantiene una réplica durante la noche y ocho al mediodía cuesta la suma de los minutos que cada réplica estuvo en funcionamiento, no ocho instancias durante 24 horas. La facturación del escalado automático se calcula según el número mínimo de réplicas que defináis, aumentando la capacidad solo mientras se ejecuta. La previsión es sencilla: vuestro suelo es el mínimo multiplicado por el tiempo, todo lo que supere eso sigue la demanda y la factura del software mantiene la forma de la curva de carga.

Tarifas indicativas: Solo CPU desde 0,04 € por núcleo y hora para modelos clásicos como scikit-learn o XGBoost; GPU L4 desde 0,91 € por réplica y hora para inferencia, visión y clasificación de 7B; GPU A100 alrededor de 1,52 € a 1,85 € para 7B a 30B; GPU H100 PCIe desde 3,10 € para modelos más grandes y ventanas de contexto largas. Confirmad las tarifas actuales en la página de precios.

Escalado a cero cuando el tráfico cae, escalado hacia arriba ante picos reales

El escalado a cero está generalmente disponible: un despliegue cae automáticamente a cero réplicas cuando nada lo llama, y el coste en reposo se vuelve cero. Esa es la diferencia económica clave entre un endpoint gestionado escalable y una instancia fija que gestionáis vosotros mismos. Tiene un compromiso honesto. Volver desde cero significa un arranque en frío mientras el contenedor arranca y carga los pesos, por lo que la primera solicitud después del reposo es lenta. Para un trabajo por lotes o una herramienta interna eso es aceptable. Para una aplicación orientada al usuario con un presupuesto de latencia, mantened un mínimo de una réplica y aceptad el coste base.

Escalado estático frente a escalado automático (CPU/RAM) frente a escalado automático de métricas personalizadas

Tres estrategias de escalado, y la elección sigue la forma de vuestro tráfico.

Sondeos de preparación y actualizaciones continuas sin tiempo de inactividad

Una sonda de preparación es una ruta HTTP que la plataforma sondea antes de enviar tráfico a una réplica. Es la forma en que os aseguráis de que el modelo esté listo: apuntadla a vuestra ruta /health y el punto de conexión no enrutará ninguna solicitud hasta que el modelo se haya cargado. Sin ella, una réplica acepta una solicitud mientras se cargan los pesos y devuelve un error que vuestro cliente ve como una solicitud fallida.

Las actualizaciones graduales utilizan la misma comprobación. Desplegad una nueva versión y aplicad la actualización, y las nuevas réplicas superarán la comprobación de preparación antes de que las antiguas se retiren. Los usuarios no ven ninguna solicitud fallida, y una versión que falla su sondeo nunca recibe tráfico. Cada versión es direccionable, por lo que las versiones diarias y una reversión de emergencia comparten un mismo mecanismo.

Monitorización en tiempo real de GPU, CPU y red por réplica

El panel de control expone un conjunto de métricas en tiempo real por réplica: una métrica de GPU, una métrica de memoria y una métrica de red, cada una limitada a una réplica en lugar de promediada, junto con los registros de la aplicación en el Panel de Control.

Ese conjunto responde si el despliegue es saludable, si la métrica de escalado se está activando y dónde se sitúa la latencia. No responde si las predicciones siguen siendo correctas. Para eso necesitáis una métrica de aplicación que defináis, siendo la precisión en una muestra etiquetada la elección habitual. Los equipos que mantienen modelos en producción suelen compartir un panel de control entre la ciencia de datos y la ingeniería de plataformas, para que ambos vean los mismos números. Esta función de monitorización es estándar en todas las aplicaciones.

Paso 1: Empaquetad el modelo en una imagen de Docker (o utilizad una preconstruida)

La contenedorización es un requisito previo, no un extra opcional. La imagen de contenedor puede provenir de Docker Hub, de Managed Private Registry, o de GitHub Packages. Tres requisitos son importantes: crear el directorio de trabajo en el Dockerfile, apuntar a linux/amd64 y servir en el puerto 8080 a menos que declaréis otro explícitamente, como hace vLLM en el 8000.

Los equipos sin experiencia en contenedores pueden empezar desde el catálogo de OVHcloud de imágenes preconstruidas con PyTorch, TensorFlow, HuggingFace o FastAI ya instalados. Eso reduce el trabajo; no elimina el requisito. Desplegar aprendizaje automático de esta manera es un valor predeterminado eficiente para la mayoría de las aplicaciones, y desplegar modelos de ML directamente desde una imagen de catálogo es aún más rápido, y la experiencia de mantener vuestra propia capa base rara vez merece la pena al principio.

Paso 2 Configurad los recursos, el escalado y el acceso a través del Panel de control, la API o la CLI de ovhai

Cread el despliegue desde el Panel de Control, la API o la CLI de ovhai. Elegid vuestros recursos de computación, configurad la estrategia de escalado, apuntad el sondeo de preparación a vuestra ruta y puerto de salud, y luego configurad cómo se accede al endpoint.

En cuanto al acceso, una regla: un endpoint público es solo para pruebas. Los despliegues en producción utilizan acceso restringido, con credenciales de usuario de AI Platform o un token, y políticas de acceso que vosotros mismos mantenéis. Cada endpoint también se encuentra detrás de una protección DDoS nativa, y cada endpoint mantiene sus propias credenciales.

ovhai app run --gpu 1 --default-http-port 8080 \
  --probe-path /health \
  --unsecure-http false \
  my-registry/my-model-server:v2

Paso 3 Elegid la estrategia de escalado adecuada para vuestro patrón de tráfico

Adaptad la política a la carga de trabajo. Puntuación interna constante: estática, una o dos réplicas, un valor predeterminado eficiente para aplicaciones internas y herramientas de bajo volumen. Una API orientada al cliente con picos diarios: escalado automático basado en una métrica de utilización, mínimo una réplica para evitar arranques en frío. Puntuación por lotes ocasional: escalado automático con escalado a cero. El trabajo por lotes es donde esa decisión es más fácil, porque nadie mira una barra de progreso. Cada ejecución por lotes es un coste que ya habéis calculado.

Estableced el máximo deliberadamente. Limita el rendimiento y la factura al mismo tiempo, y el límite es de 10 réplicas por aplicación.

Paso 4: Supervisad la inferencia con el panel de control y la arquitectura de referencia de MKS

Empezad con el panel integrado para métricas de recursos y registros. Para percentiles de latencia, rendimiento o precisión a nivel de modelo, añadid una pila externa: Servicio de Kubernetes gestionado que ejecuta Prometheus y Grafana, analizando vuestro endpoint. OVHcloud publica esto como una arquitectura de referencia.

Dos cosas que debéis supervisar continuamente: las señales de infraestructura que os indican si el escalado funciona, y el rendimiento del modelo en producción, que os indica si el modelo sigue haciendo su trabajo. La supervisión del rendimiento en el segundo es lo que detecta una regresión silenciosa, y las métricas de rendimiento de un conjunto de datos de entrenamiento no os avisarán de ello. La deriva aparece en el segundo mucho antes que en el primero. Exportad una semana de métricas en línea a un archivo antes de optimizar un umbral, asegurando que el cambio siga la carga observada. Configurad una alerta en cada uno para asegurar que una regresión surja de vuestras propias observaciones en lugar de las de un cliente, aseguraos de que el umbral se base en una línea base real y aseguraos de que tenga un propietario.

Paso 5: Desplegad una nueva versión con una actualización progresiva sin tiempo de inactividad

Construid y enviad la nueva versión, luego ejecutad ovhai app update o aplicad el cambio desde el Panel de Control. La plataforma inicia nuevas réplicas, espera a que estén listas, cambia el tráfico y retira las antiguas. Sin tiempo de inactividad, sin ventana de mantenimiento.

El Dockerfile es código: mantenedlo en el control de versiones y la base actualizada, ya que una capa base obsoleta es una causa común de un despliegue fallido. Mantened las etiquetas versionadas en lugar de reutilizar latest. El control de versiones en cada versión es lo que hace que una reversión sea una operación de un solo comando en lugar de una investigación.

Por qué la CPU/RAM es un indicador deficiente para la carga de LLM

La inferencia de aprendizaje profundo es una carga de trabajo computacional con una cola, no un bucle limitado por la CPU, por lo que la práctica estándar de escalar según el hardware falla. Un servidor LLM procesa por lotes las solicitudes simultáneas en la GPU. La utilización de la CPU permanece baja mientras la cola crece, por lo que ese umbral se activa tarde o nunca. La señal que os interesa es cuántas solicitudes están en curso, y una métrica de hardware no puede verla.

Escalado basado en vllm:num_requests_running con Prometheus y Grafana en MKS

vLLM expone vllm:num_requests_running en su punto de conexión de métricas. Recopiladlo con Prometheus y escalad automáticamente según ese valor en lugar de usar un proxy de hardware. Las réplicas llegan cuando aumenta la concurrencia real y se eliminan cuando la cola se vacía, manteniendo la latencia dentro del presupuesto sin sobreaprovisionar.

Generalmente disponible y documentado como arquitectura de referencia. Necesita Prometheus y Grafana junto a vuestro despliegue, así que tratadlo como el enfoque avanzado, no como el predeterminado.

Tiempo de configuración, coste por inactividad y experiencia operativa

Autogestionar la inferencia implica aprovisionar el clúster, los grupos de nodos, un controlador de ingress y un autoscaler horizontal, lo que suele llevar de una a dos semanas, además de experiencia en DevOps y MLOps para mantenerlo en funcionamiento. Vosotros poseéis las políticas de escalado, las canalizaciones de despliegue, los archivos de manifiesto y las estrategias de monitorización, y seguís poseyéndolos después del lanzamiento. Las mejores prácticas en el campo están documentadas y las herramientas son maduras, pero en este ámbito una práctica documentada no es un sistema en funcionamiento robusto. El nodo de GPU suele ejecutarse de forma continua, incluso sin tráfico.

AI Deploy necesita una imagen y un comando. La configuración lleva menos de una hora, basta con conocimientos de MLOps y el escalado a cero elimina por completo los costes por inactividad.

Los precios y las cifras son orientativos. Confirmad las tarifas vigentes en la página de precios de OVHcloud antes de publicar.

Sin exposición a la CLOUD Act en los datos de inferencia

Los datos de entrenamiento no son la única entrada sensible. Cada solicitud a un endpoint de producción conlleva datos de usuario o de negocio, cada solicitud se registra en algún lugar, cada solicitud es una entrada que no habéis elegido y el tráfico del endpoint es continuo en lugar de una transferencia puntual. Si el endpoint se ejecuta en un proveedor con sede en EE. UU., esos datos quedan bajo la jurisdicción de EE. UU. independientemente de la región que los aloje.

OVHcloud es europea, sin empresa matriz estadounidense y sin exposición estructural a la CLOUD Act. Los datos de inferencia permanecen en la jurisdicción de la UE bajo la legislación de la UE.

RGPD, HDS e ISO 27701 para cargas de trabajo reguladas

OVHcloud posee las certificaciones ISO 27001, ISO 27017, ISO 27018 e ISO 27701, cuenta con la certificación SOC 2 y posee la certificación HDS para datos de salud en Francia, relevante para la inferencia médica. El procesamiento dentro de la UE simplifica una Evaluación de Impacto relativa a la Protección de Datos, y los compromisos de privacidad de datos que habéis adquirido con vuestros propios usuarios resultan más sencillos de demostrar. El soporte puede responder a una pregunta sobre privacidad sin necesidad de escalar.

Un límite que hay que establecer claramente: AI Deploy proporciona una infraestructura de servicio soberana. Las obligaciones a nivel de modelo de la Ley de IA de la UE, las fichas de modelo, los registros de auditoría y la detección de sesgos siguen siendo vuestra responsabilidad como desarrolladores del sistema. La infraestructura soberana facilita el cumplimiento; no lo garantiza.