Model Deployment

El despliegue de modelos es el proceso de poner en producción un modelo de aprendizaje automático, donde las aplicaciones le envían datos nuevos y actúan según sus predicciones. Abarca elegir dónde se ejecuta el modelo, convertirlo a un formato que ejecute el entorno de ejecución de destino, conectarlo a las entradas y salidas mediante una API o una aplicación, publicar nuevas versiones de forma segura y observar su comportamiento cuando ya dependen de él usuarios reales. Un modelo que obtiene buenas puntuaciones en un cuaderno de trabajo no es más que un experimento hasta que se despliega, y el despliegue es la etapa de las operaciones de aprendizaje automático (MLOps) en la que la ciencia de datos se encuentra con las limitaciones de la ingeniería de software, como la latencia, el coste, el tiempo de actividad y la seguridad.

Dónde se despliegan los modelos#

• Despliegue en la nube: el modelo se ejecuta en servidores detrás de un endpoint REST o gRPC, normalmente mediante un sistema de servicio de modelos que agrupa solicitudes en lotes y escala las réplicas según la demanda. Es adecuado para modelos grandes y tráfico variable, y cada solicitud tiene el coste de un viaje de ida y vuelta por la red.
• Despliegue en el borde: el modelo se ejecuta en el dispositivo que captura los datos, como un teléfono, una cámara, un robot o un módulo NVIDIA Jetson. Las entradas nunca salen del dispositivo, lo que protege la privacidad, y el modelo sigue funcionando sin conexión; sin embargo, la memoria y la potencia limitadas suelen exigir un modelo comprimido.
• Despliegue sin servidor: la plataforma inicia instancias bajo demanda y las escala a cero cuando están inactivas; a cambio de no pagar nada mientras no llegan solicitudes, hay que asumir un retraso de arranque en frío en la primera solicitud.
• Despliegue por lotes: un trabajo programado puntúa de una vez un conjunto de datos grande, por ejemplo, para generar recomendaciones de productos cada noche, cuando el rendimiento es más importante que la velocidad de cada solicitud.

Ultralytics Platform despliega un modelo YOLO entrenado en un punto de conexión dedicado en cualquiera de las 42 regiones, cada una con su propia URL y supervisión; los puntos de conexión con el tamaño de recurso predeterminado se escalan a cero cuando están inactivos. La elección del destino depende de algunas preguntas sobre la aplicación, que la lección de Ultralytics Academy Elige un destino de despliegue analiza en detalle:

Preparar un modelo para producción#

Los marcos de entrenamiento están diseñados para ofrecer flexibilidad, por lo que los modelos de producción suelen exportarse a un formato que un motor de inferencia pueda ejecutar de forma eficiente, como ONNX para la portabilidad, TensorRT para GPU NVIDIA, OpenVINO para hardware Intel, o LiteRT y Core ML para teléfonos. La cuantización de modelos y la poda de modelos reducen aún más el tamaño del modelo cuando el dispositivo de destino es pequeño. Después, el modelo exportado y su código de preprocesamiento se empaquetan con dependencias fijadas, normalmente en un contenedor Docker que funciona igual en un portátil, un servidor o un clúster de Kubernetes. Así se exporta un detector entrenado y se carga el archivo exportado para hacer una comprobación rápida antes de publicarlo:

from ultralytics import YOLO

# Load a trained model (replace with your own best.pt)
model = YOLO("yolo26n.pt")

# Export to ONNX, a portable format that many inference engines run
path = model.export(format="onnx")
print(f"Deployable model: {path}")

# Smoke-test the exported file with the same API before shipping it
onnx_model = YOLO(path)
results = onnx_model("https://ultralytics.com/images/bus.jpg")
results[0].save(filename="bus_onnx.jpg")

La llamada de exportación devuelve la ruta del nuevo archivo yolo26n.onnx, y la imagen guardada confirma que el archivo exportado se carga y detecta objetos. Los equipos también comparan la precisión y la velocidad del modelo exportado con las del original en un conjunto de validación, porque la conversión de formato y una menor precisión numérica pueden alterar ligeramente los resultados.

Publicar nuevas versiones de modelos#

Una nueva versión del modelo se almacena en un registro de modelos y se publica gradualmente, ya que las métricas sin conexión no reflejan todas las condiciones de producción. En un despliegue en sombra, el modelo nuevo recibe una copia del tráfico en directo mientras el modelo actual sigue respondiendo a los usuarios, de modo que se pueden comparar ambos sin riesgo. A continuación, una publicación canario dirige una pequeña parte del tráfico real a la nueva versión y la amplía solo mientras los índices de error, la latencia y la calidad de las predicciones se mantengan en niveles adecuados; las pruebas A/B miden el efecto en los resultados del negocio. Mantener la versión anterior lista para el despliegue permite revertir el cambio modificando la configuración en lugar de reconstruir el sistema de urgencia:

Despliegue de modelos y términos relacionados#

• Entrenamiento de modelos: aprende los pesos del modelo a partir de un conjunto de datos. El despliegue parte de los pesos ya entrenados.
• Servicio de modelos: la capa de ejecución que responde a las solicitudes de predicción. Es una parte del despliegue, que también incluye el empaquetado, la publicación y la monitorización.
• Latencia de inferencia: el tiempo que tarda el modelo desplegado en calcular cada predicción individual; es uno de los principales requisitos que debe cumplir un despliegue.

Monitorización tras el despliegue#

Un modelo desplegado se degrada sin que nadie lo note cuando cambia el entorno. La monitorización del modelo sigue señales operativas como la latencia, el rendimiento, los índices de error y el uso del hardware, a menudo con herramientas como Prometheus y Grafana, además de las estadísticas de las entradas y las predicciones. Cuando la monitorización detecta un problema, los equipos etiquetan los nuevos casos de error, vuelven a entrenar el modelo y someten la nueva versión al mismo proceso de publicación. Las estadísticas de entrada son el primer aviso: la deriva de datos, un cambio en la distribución de las entradas como el desplazamiento de una cámara a un nuevo ángulo o el cambio a la iluminación invernal, aparece días o semanas antes de que lleguen las etiquetas de referencia de los datos de producción para medir la precisión.