Después de construir, entrenar, evaluar, optimizar e interpretar modelos, llega una etapa decisiva: ponerlos a funcionar en un entorno real. Esa etapa es el deployment.
En visión por computadora, hacer deployment no significa solo “guardar un archivo y ejecutarlo”. Implica decidir dónde correrá el modelo, cómo recibirá imágenes o video, cómo devolverá resultados, cómo mediremos su comportamiento y cómo mantendremos el sistema operativo con el tiempo.
En este tema veremos la lógica general del deployment de modelos de visión artificial, qué formas de despliegue existen, qué componentes suelen intervenir y qué riesgos aparecen cuando un modelo pasa del laboratorio a producción.
Hacer deployment significa tomar un modelo entrenado y convertirlo en un sistema utilizable por otras personas o por otros programas.
Eso puede tomar formas distintas:
La idea central es la misma: el modelo deja de ser un experimento aislado y pasa a ser parte de un flujo operativo.
En desarrollo solemos probar el modelo desde notebooks o scripts locales. Eso es útil para investigar, depurar y aprender. Pero un sistema real necesita algo más robusto.
Un usuario final no debería depender de abrir un notebook para clasificar una imagen. Normalmente necesita una interfaz, un endpoint o un proceso automático con entradas y salidas claras.
En muchos despliegues de visión por computadora aparecen componentes como:
Si alguno de estos elementos queda mal resuelto, el deployment puede fallar aunque el modelo sea bueno.
Una de las fuentes más comunes de errores en deployment es no respetar el mismo preprocesamiento usado durante entrenamiento o validación.
Si el modelo fue entrenado con cierto tamaño de entrada, normalización o espacio de color, el entorno desplegado debe reproducir esa lógica de forma consistente.
Un deployment incorrecto puede degradar fuertemente el desempeño sin que el modelo en sí esté mal.
No alcanza con ejecutar la red. Muchas veces también hay que transformar la salida bruta en algo útil para el consumidor del sistema.
Por ejemplo:
Ese postprocesamiento también forma parte del deployment, no es un detalle accesorio.
No existe un único tipo de deployment. En visión por computadora suelen aparecer al menos tres escenarios frecuentes:
Cada uno cambia las decisiones técnicas sobre latencia, throughput, escalado y arquitectura de sistema.
En un esquema batch, el sistema procesa archivos acumulados: carpetas con imágenes, lotes de videos o trabajos programados.
Este modo es muy útil cuando no necesitamos respuesta inmediata. Por ejemplo, análisis nocturno de imágenes médicas, clasificación masiva de catálogos o procesamiento offline de video.
Aquí suele importar más el throughput total que la latencia individual de cada predicción.
Otra forma muy común es exponer el modelo mediante una API. Un cliente envía una imagen o una referencia a un archivo, y el servidor responde con la predicción.
Esto permite integrar el modelo con aplicaciones web, móviles, paneles de control o sistemas empresariales.
En este caso, el diseño de la interfaz del servicio es tan importante como el modelo: qué recibe, qué devuelve, cómo reporta errores y cómo autentica solicitudes.
Cuando el sistema trabaja con cámaras o video continuo, la situación cambia bastante. Ya no se trata solo de procesar imágenes sueltas, sino de sostener un flujo constante.
En estos contextos importan especialmente:
Un modelo puede rendir bien sobre imágenes sueltas y no alcanzar la exigencia del tiempo real.
Una decisión central de deployment es dónde correrá la inferencia:
El edge reduce dependencia de red y puede mejorar privacidad o latencia. La nube facilita escalado y administración centralizada. La elección depende del caso de uso real.
Desplegar en edge puede ser muy conveniente cuando:
Claro que esto exige modelos más livianos y una ingeniería más ajustada al hardware disponible.
La nube ofrece ventajas operativas importantes:
En muchos proyectos, la nube simplifica la administración general, aunque también agrega costos de infraestructura y dependencia de red.
Para desplegar, el modelo debe guardarse de una forma que el sistema pueda cargar de manera confiable. En PyTorch, una opción habitual es:
torch.save(model.state_dict(), "modelo.pth")Después, en el entorno de deployment, se reconstruye la arquitectura y se cargan los pesos.
Una estructura muy típica del lado de inferencia es:
model = MiModelo()
state_dict = torch.load("modelo.pth", map_location=device)
model.load_state_dict(state_dict)
model.to(device)
model.eval()Esta secuencia deja el modelo listo para recibir entradas en producción, siempre que el preprocesamiento coincida con el usado durante el desarrollo.
En algunos entornos conviene exportar el modelo a un formato más portable o más fácil de ejecutar fuera del código PyTorch original.
Dos nombres frecuentes son:
No siempre son obligatorios, pero forman parte del panorama real de deployment.
Una práctica muy común es empaquetar el servicio de inferencia dentro de un contenedor Docker. Esto ayuda a que el entorno sea reproducible.
El contenedor suele incluir:
Esto reduce el clásico problema de “en mi máquina funciona, en producción no”.
Conceptualmente, una API de inferencia hace algo como esto:
La lógica del modelo es solo una parte. También importan mucho la validación de entrada y el contrato de salida.
Un ejemplo mínimo de endpoint de inferencia podría verse así:
from fastapi import FastAPI
app = FastAPI()
@app.post("/predict")
def predict():
return {"clase": "gato", "score": 0.98}Obviamente, en un sistema real aquí habría que recibir la imagen, preprocesarla, ejecutar el modelo y devolver una respuesta más rica. Pero este ejemplo ya muestra la idea de exponer inferencia como servicio.
Un buen deployment no solo “predice”, sino que devuelve información utilizable. En una respuesta JSON suelen incluirse elementos como:
Esto facilita depuración, integración y trazabilidad.
En producción no debemos asumir que toda entrada será válida. Puede llegar un archivo corrupto, una imagen vacía, un formato inesperado o incluso una solicitud maliciosa.
Por eso el deployment debe contemplar:
Con el tiempo, un sistema real suele tener más de una versión del modelo. Tal vez entrenamos una variante mejor, o una más rápida, o una adaptada a otra población de datos.
Por eso conviene versionar explícitamente:
Sin versionado, es difícil saber qué modelo generó cierta predicción o reproducir comportamientos pasados.
Una vez desplegado, el trabajo no termina. El modelo debe observarse en operación. Algunas señales importantes son:
Esto ayuda a detectar caídas de servicio, degradaciones de rendimiento o comportamientos anómalos.
Un modelo puede funcionar muy bien al principio y degradarse luego porque cambian las condiciones reales: cámaras nuevas, distinta iluminación, nuevos tipos de imágenes o cambios en la población de datos.
A eso se lo suele relacionar con drift. El deployment serio debe contemplar que el entorno real no es estático y que puede exigir reentrenamiento o recalibración.
En visión por computadora muchas veces se manejan imágenes sensibles: personas, documentos, vehículos, placas, estudios médicos o escenas internas de una empresa.
Por eso el deployment debe considerar también:
Un modelo útil pero inseguro puede convertirse en un problema mayor que el que intenta resolver.
Una estructura local muy básica de deployment podría verse así:
from PIL import Image
import torch
model.eval()
imagen = Image.open("entrada.jpg").convert("RGB")
tensor = preprocess(imagen).unsqueeze(0).to(device)
with torch.no_grad():
salida = model(tensor)
pred = salida.argmax(dim=1).item()
print("Predicción:", pred)Este ejemplo es simple, pero muestra el esqueleto central del deployment: cargar, preprocesar, inferir y devolver un resultado.
Algunos errores muy frecuentes son:
El deployment es la etapa donde un modelo de visión artificial deja de ser una pieza académica y pasa a formar parte de un sistema real. Ahí importan tanto la precisión como la confiabilidad operacional, la latencia, la seguridad y la capacidad de mantenimiento.
Comprender esta etapa es fundamental para hacer ingeniería útil con modelos de visión por computadora. Muchas veces, el verdadero valor de un proyecto no está solo en entrenar un buen modelo, sino en conseguir que ese modelo funcione de manera estable, medible y sostenible en el mundo real.
En el próximo tema construiremos un caso práctico completo de clasificación de imágenes, integrando de punta a punta varios de los conceptos que ya desarrollamos a lo largo del curso.