Tu equipo de ciencia de datos entrenó un modelo que funciona en sus portátiles. Ahora un product manager lo quiere en producción dentro de la app antes de que termine el trimestre, y las dos partes no se ponen de acuerdo sobre cómo llevarlo a producción. Esa brecha, entre un modelo que corre en un notebook y otro que sirve a usuarios reales, es donde se estancan la mayoría de las funciones de IA.
Para desplegar modelos de IA con Docker, empaquetas el modelo, su runtime y cada dependencia en una única imagen de contenedor, lo expones detrás de una API de inferencia y ejecutas esa imagen en una plataforma de contenedores como Kubernetes o un servicio de contenedores gestionado. Docker hace que el modelo sea reproducible y portable, de modo que se comporta igual en un portátil, en staging y en producción, sin importar la versión de Python o CUDA del host.
Esta guía explica cómo funciona paso a paso, cuánto cuesta en tiempo de ingeniería, cuándo un contenedor es la herramienta equivocada y los errores concretos que vemos cometer a los equipos la primera vez que ponen un modelo en producción.
¿Qué significa desplegar un modelo de IA con Docker?
Un contenedor Docker es un entorno ligero y aislado que agrupa tu modelo junto con todo lo que necesita para ejecutarse: el intérprete de Python, el framework de ML como PyTorch, TensorFlow u ONNX Runtime, las librerías del sistema y los propios pesos del modelo. Describes ese entorno una sola vez en un archivo de texto llamado Dockerfile, lo construyes en una imagen y ejecutas copias de esa imagen como contenedores.
Desplegar un modelo de IA con Docker significa convertir tu modelo entrenado en una de estas imágenes y ejecutarla como un servicio al que llaman otros sistemas. En lugar de exigir que cada servidor tenga instalada la versión correcta de Python y los drivers CUDA, entregas un artefacto autocontenido que ya los incluye. El host solo necesita Docker.
El resultado es un servicio de inferencia: una pequeña API que recibe una entrada (una cadena de texto, una imagen, una fila de features), la pasa por el modelo y devuelve una predicción. Todo lo que el modelo necesita viaja dentro de la imagen.
¿Por qué desplegar modelos de IA con Docker en lugar de un servidor sin contenedores?
Cuatro razones aparecen en casi todos los proyectos.
Reproducibilidad. Un modelo de ML es sensible a las versiones de las librerías. Un modelo entrenado con PyTorch 2.1 puede comportarse de forma distinta, o no cargar, bajo 2.3. La imagen fija cada versión, así que el modelo que probaste es el modelo que se ejecuta.
Aislamiento de dependencias. Las cargas de trabajo de IA arrastran dependencias pesadas y en conflicto: CUDA, cuDNN, builds concretos de NumPy. Los contenedores mantienen separado el stack de cada modelo, de modo que dos modelos con requisitos distintos conviven en el mismo host sin pelearse.
Paridad entre entornos. El clásico problema de «funciona en mi máquina» desaparece. La misma imagen se ejecuta en el portátil de un desarrollador, en un clúster de staging y en producción, lo que hace que los errores sean reproducibles y los rollbacks, instantáneos.
Escalado y recuperación. Cuando el tráfico sube, la plataforma arranca más copias de la imagen. Cuando un contenedor se cae, se reemplaza en segundos a partir del mismo artefacto conocido y fiable.
¿Cómo se despliega un modelo de IA con Docker, paso a paso?
El camino de un modelo entrenado a un servicio en marcha son seis pasos. El diagrama de abajo muestra toda la secuencia, y las secciones que le siguen explican las partes que hacen tropezar a los equipos.
1. Empaqueta el modelo. Exporta los pesos entrenados a un formato portable como un archivo .pt u .onnx y escribe un pequeño script de inferencia que cargue los pesos y exponga una función de predicción.
2. Escribe el Dockerfile. Elige una imagen base. Para inferencia por CPU, una imagen slim de Python mantiene el tamaño bajo. Para inferencia por GPU, parte de una imagen base oficial de NVIDIA CUDA para que los drivers encajen. Instala solo las librerías que el modelo necesita en inferencia, no todo el stack de entrenamiento.
3. Construye la imagen. Ejecuta el build, que aplica el Dockerfile y hornea el modelo, el runtime y las dependencias en un único artefacto versionado.
4. Súbela a un registro. Guarda la imagen en un registro de contenedores privado como Amazon ECR, Google Artifact Registry o Azure Container Registry del que tu plataforma de producción pueda tirar.
5. Sírvela detrás de una API. Envuelve el modelo en un servidor web como FastAPI o TorchServe para que otros servicios puedan enviar peticiones y recibir predicciones por HTTP.
6. Monitoriza y escala. Vigila la latencia, la tasa de errores y, en cargas de GPU, la memoria. Añade réplicas a medida que crece el tráfico y haz rollback a la etiqueta de imagen anterior si un modelo nuevo se comporta mal.
# Imagen de inferencia CPU para un modelo PyTorch servido con FastAPI
FROM python:3.11-slim
WORKDIR /app
# Instala solo las dependencias de inferencia, no el stack de entrenamiento
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Copia los pesos del modelo y el código de inferencia
COPY model/ ./model/
COPY app.py .
# Una petición entra, una predicción sale
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]
Para un modelo de GPU, el único cambio relevante es la imagen base. Cambia python:3.11-slim por una imagen nvidia/cuda e instala el build para GPU de tu framework. El código de la aplicación no cambia.
Contenedores CPU o GPU: ¿cuál necesita tu modelo?
No todos los modelos necesitan una GPU en producción, y las GPU son el mayor coste individual en la mayoría de los despliegues de IA. La regla práctica es ajustar el contenedor al presupuesto de latencia real del modelo, no al hardware con el que entrenaste.
Ideal para
Modelos más pequeños, clasificación de texto, modelos tabulares, bajo volumen de peticiones
Grandes modelos de lenguaje, modelos de imagen o vídeo, alto throughput
Imagen base
python:slim, unos 150 MB
nvidia/cuda, de 1 a 3 GB
Coste
Bajo, corre en cómputo estándar
Alto, necesita instancias GPU facturadas por hora
Esfuerzo de configuración
Mínimo
NVIDIA Container Toolkit más el emparejamiento de drivers
Encaje típico
Modelos donde la latencia en CPU es aceptable
Cuando la inferencia por CPU es demasiado lenta para el usuario
Docker frente a serverless frente a endpoints de modelos gestionados
Docker no es la única forma de entregar un modelo, y no siempre es la más barata. Así comparan las tres opciones habituales, y el diagrama que sigue a la tabla lo convierte en una decisión rápida.
Control
Total
Medio
Bajo
Esfuerzo de operación
El mayor
Medio
El menor
Modelo de coste
Pagas por instancias en marcha
Pagas por petición, escala a cero
Pagas por llamada o por hora
Arranques en frío
Ninguno una vez en marcha
Pueden ser segundos con imágenes grandes
Raros
Mejor cuando
Tráfico estable, modelos personalizados o de GPU
Tráfico irregular u ocasional
Usas un modelo fundacional alojado
¿Cuándo es Docker la elección equivocada para el despliegue de IA?
Los contenedores son la opción por defecto para modelos personalizados, pero no son gratis, y hay casos en los que recurrir a Docker de entrada es un error.
Solo estás llamando a un modelo alojado. Si tu función es un envoltorio alrededor de la API de un modelo fundacional alojado, no hay modelo que contenerizar. Llama a la API desde tu backend actual y sáltate la capa extra.
El tráfico es escaso e impredecible. Un modelo que atiende un puñado de peticiones al día no justifica un contenedor siempre encendido ni su coste en reposo. Un contenedor serverless o un endpoint gestionado que escala a cero suele salir más barato, siempre que puedas tolerar un arranque en frío.
La imagen es enorme y la latencia es crítica. Las imágenes de GPU con stacks CUDA completos pueden ocupar varios gigabytes. Si un pull en frío añade segundos que no puedes permitirte, necesitas pools calientes e imágenes pre-descargadas, lo que suma coste y complejidad.
Nadie es dueño de la plataforma. Docker más Kubernetes es infraestructura de verdad. Si no tienes a nadie que se encargue del escalado, los parches de seguridad y el control de costes, un servicio gestionado te servirá mejor hasta que lo tengas. Ser honesto con esto desde el principio ahorra mucho dinero.
Cómo despliega Redwerk modelos de IA para equipos del mercado medio
La mayoría de los equipos que acuden a nosotros no carecen del modelo. Tienen un prototipo que funciona y un camino a producción atascado, normalmente porque quienes entrenaron el modelo no son quienes operan la infraestructura. Esa brecha es exactamente lo que cubrimos.
Redwerk aporta ingenieros que ya conocen el stack concreto, ya sea PyTorch sobre CUDA, ONNX Runtime o un servicio de inferencia en Python detrás de Kubernetes, así que somos productivos en días en lugar de pasar semanas poniéndonos al día con tus herramientas. En un proyecto de desarrollo de IA asumimos una plataforma de optimización con IA a mitad de construcción y la llevamos hasta el lanzamiento en producción, ocupándonos de la contenerización, la API de inferencia y la monitorización que el equipo original aún no había alcanzado.
También lo hacemos sin exigir una especificación cerrada. Si conoces el resultado que necesitas pero no la arquitectura exacta, lo resolvemos contigo y te mantenemos informado en todo momento, algo que importa cuando quienes aprueban el trabajo no son quienes leen el Dockerfile.
Si tu stack es .NET, consulta .NET Core frente a .NET Framework para contenedores Docker para la elección del runtime. Cuando quieras un equipo senior que ya sepa cómo llevar modelos a producción, así es como Redwerk construye y despliega IA en productos SaaS.
Preguntas frecuentes: desplegar modelos de IA con Docker
¿Cuánto se tarda en contenerizar un modelo de IA?
Para un solo modelo con un camino de inferencia claro, un servicio contenerizado listo para producción suele llevarle a un ingeniero senior de dos a cuatro semanas, incluyendo la API, la configuración del registro y una monitorización básica. Una prueba de concepto aproximada puede funcionar en un día o dos, pero la distancia entre «corre en un contenedor» y «seguro en producción» es donde se va la mayor parte del tiempo.
¿Necesito Kubernetes para ejecutar modelos de IA en Docker?
No. Kubernetes merece la pena cuando ejecutas muchos modelos o necesitas escalado automático y auto-recuperación. Para empezar, un único contenedor en un servicio de contenedores gestionado como AWS App Runner, Google Cloud Run o Azure Container Apps es más sencillo y a menudo suficiente. Puedes migrar a Kubernetes más adelante sin cambiar la imagen.
¿Cómo de grande es una imagen Docker típica de un modelo de IA?
Las imágenes de CPU construidas sobre una base slim de Python suelen ocupar de 200 MB a 1 GB. Las imágenes de GPU que incluyen el toolkit de CUDA rondan habitualmente entre 3 y 8 GB, y los pesos del modelo se suman por encima de eso. Los builds multietapa y las imágenes base slim son las principales palancas para mantener el tamaño bajo.
¿Puedo ejecutar inferencia por GPU dentro de un contenedor Docker?
Sí. Con el NVIDIA Container Toolkit instalado en el host, los contenedores pueden acceder a la GPU directamente. Partes de una imagen base de NVIDIA CUDA, instalas el build para GPU de tu framework y ejecutas el contenedor con el acceso a GPU habilitado. El código del modelo no cambia entre CPU y GPU.
Descubre cómo Redwerk asumió el desarrollo central de una plataforma de optimización con IA y lo llevó hasta el lanzamiento exitoso del producto