Desarrollo IADevOps

Docker GPU en 2026: Desplegá Apps de IA con Compose

25 de agosto de 2026
10 min de lectura
Contenedores de carga con núcleos GPU brillantes, grúa al atardecer
Compartir:

Tu modelo corre perfecto en la GPU de tu laptop y muere en cuanto lo contenerizás. CUDA no encontrado, driver incompatible, una imagen de 9GB que tarda veinte minutos en subirse — me pasó todo, y todo tiene la misma raíz: el host, el runtime y la imagen nunca se configuraron como un solo sistema.

En este deep-dive te muestro el setup completo 2026: instalar el NVIDIA Container Toolkit, reservar GPUs en Compose con la sintaxis verificada, elegir la imagen base CUDA correcta y achicar tu app de IA en Python con un build multi-stage.

1. El Problema: Anda en Mi GPU (y en Ningún Otro Lado)

Desplegar una app de IA con GPU tiene tres piezas móviles que deben coincidir: el driver de NVIDIA en el host, el runtime que expone la GPU y las librerías CUDA dentro de la imagen. Cuando alguna se desvía — un tutorial con flags viejos de nvidia-docker2, un Compose con claves de runtime de 2021, un Dockerfile que lleva devel a producción — aparecen errores crípticos a las 2am e imágenes de varios gigabytes.

El Error Más Común

Instalar el CUDA Toolkit completo en el host. No lo necesitás ahí. El contenedor lleva sus propias librerías CUDA; el host solo necesita el driver de NVIDIA más el NVIDIA Container Toolkit, que expone el driver dentro de los contenedores en runtime.

El objetivo de esta guía es un stack reproducible que puedas commitear: un setup de host verificado, un compose.yaml con reservas GPU explícitas y un Dockerfile multi-stage que compila en devel y despliega en runtime. Cada comando fue verificado contra la documentación oficial de NVIDIA y Docker.

2. Conceptos Mínimos que Realmente Necesitás

Solo importan cuatro ideas. Entendelas y cada mensaje de error de GPU empieza a tener sentido.

🖥️

Driver vs Toolkit vs Runtime

Setup del host · docs de NVIDIA

El host conserva el driver de NVIDIA — nada más. El NVIDIA Container Toolkit (nvidia-ctk) configura tu runtime para inyectar el driver en los contenedores bajo demanda. Nunca instales CUDA en el host.

📦

Sabores CUDA: base, runtime, devel

nvidia/cuda · Docker Hub / NGC

Los tags siguen {versión}-{sabor}-{os}, ej. 12.8.0-runtime-ubuntu22.04. base (~300MB) corre binarios precompilados, runtime (~2GB) corre frameworks, devel (~6GB) compila. Desplegá runtime, compilá en devel.

🎫

Reservas de Dispositivos en Compose

deploy.resources · docs de Docker

Las GPUs se reservan por servicio en deploy.resources.reservations.devices con driver: nvidia, capabilities: [gpu] y count o device_ids — nunca ambos. capabilities es obligatorio.

🔍

nvidia-smi Es la Fuente de la Verdad

Verificá todo con él

Corré nvidia-smi en el host primero. Si el host no ve la GPU, ningún contenedor la verá jamás. Después repetilo dentro del contenedor para probar la cadena completa.

La Regla de Oro de las Imágenes CUDA

Casi seguro querés runtime, no devel. Si instalás PyTorch con pip y corrés un script, nvcc nunca se invoca — llevar devel a producción es llevar un compilador que nadie usa. Compilá en devel, desplegá en runtime.

3. Tutorial: App de IA con GPU en Compose, Paso a Paso

Vamos de un host Linux pelado con GPU NVIDIA a una API de inferencia en Python con acceso a GPU, en seis pasos. Flujo probado, solo comandos oficiales.

Paso 1

Confirmá que el host ve la GPU

Antes de tocar Docker, probá que el driver funciona. Esto debe listar tus GPUs — si falla, arreglá el driver primero; nada de lo que sigue puede ayudar.

nvidia-smi

Paso 2

Instalá el NVIDIA Container Toolkit

Estos son los pasos actuales del repositorio según la guía oficial (mostrado Ubuntu/Debian; en familia RHEL se usa el repo dnf equivalente). El paquete del toolkit más la configuración con nvidia-ctk es todo lo que un host Docker necesita.

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Paso 3

Prueba de humo con una imagen CUDA oficial

Corré nvidia-smi dentro de un contenedor descartable. Esto prueba driver → toolkit → runtime → imagen en una línea. Pineá un tag explícito — nunca uno flotante.

docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu22.04 nvidia-smi

Paso 4

Reservá la GPU en compose.yaml

Esta es la sintaxis verificada de los docs de Docker: una entrada con driver nvidia, capabilities [gpu] y count 1. Usá count: all para todas las GPUs, o device_ids como [“0”] para fijar específicas — pero nunca combines count y device_ids en la misma entrada.

services:
  api:
    build: .
    ports:
      - "8000:8000"
    volumes:
      - model-cache:/models
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

volumes:
  model-cache:

Paso 5

Dockerfile multi-stage: compilá grande, desplegá chico

Para apps Python puras alcanza con runtime; si compilás extensiones nativas, hacelo en devel y copiá solo los artefactos a runtime. Este patrón suele convertir 6GB en unos cientos de megabytes.

# Etapa 1: compilar extensiones nativas (solo si compilás algo)
FROM nvidia/cuda:12.8.0-devel-ubuntu22.04 AS builder
WORKDIR /build
COPY requirements.txt .
RUN apt-get update && apt-get install -y --no-install-recommends python3 python3-pip \
    && rm -rf /var/lib/apt/lists/* \
    && pip3 install --no-cache-dir --prefix=/install -r requirements.txt

# Etapa 2: runtime liviano para producción
FROM nvidia/cuda:12.8.0-runtime-ubuntu22.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends python3 python3-pip \
    && rm -rf /var/lib/apt/lists/*
COPY --from=builder /install /usr/local
COPY . /app
WORKDIR /app
CMD ["python3", "main.py"]

Paso 6

Levantá y probá que la GPU es visible

Buildeá, levantá y verificá desde dentro del servicio corriendo. El one-liner de torch es el verdadero test de aceptación para una app PyTorch.

docker compose up --build -d
docker compose exec api nvidia-smi
docker compose exec api python3 -c "import torch; print(torch.cuda.is_available())"

✅ Checklist de aceptación

nvidia-smi funciona en el host, en docker run y en docker compose exec — y torch.cuda.is_available() devuelve True. Si los tres pasan, tu stack es reproducible en cualquier host idéntico con un solo compose up.

4. Errores Comunes (y el Fix Exacto)

Estas cinco fallas cubren más o menos el 90% del dolor con Docker y GPU. Cada una tiene un fix determinístico — sin reinstalar el mundo.

“could not select device driver nvidia”

Falta el toolkit o no reiniciaste Docker tras configurarlo. Fix: instalá nvidia-container-toolkit, corré sudo nvidia-ctk runtime configure --runtime=docker y después sudo systemctl restart docker.

🧩

Compose falla en el bloque devices

Omitiste capabilities: [gpu] (obligatorio — el deploy falla sin él) o combinaste count con device_ids (mutuamente excluyentes). Quedate con exactamente uno por entrada.

🔢

Versión CUDA vs driver incompatibles

Los drivers son compatibles hacia atrás, no hacia adelante: un driver viejo no corre un contenedor CUDA nuevo. Fix: actualizá el driver del host o pineá la imagen a un CUDA que tu driver soporte.

🐘

La imagen de producción pesa 6–8GB

Desplegaste un tag devel o cudnn-devel. Fix: build multi-stage — compilá en devel y copiá los artefactos a base o runtime. Para apps de puro pip, partí directo de FROM runtime.

🏷️

“manifest not found” en un tag que andaba

Docker Hub retira tags CUDA viejos con el tiempo. Fix: pineá tags explícitos y preferí nvcr.io (el registry de NVIDIA) para builds reproducibles de larga vida.

Regla de oro

Debugueá por capas, siempre en este orden: nvidia-smi en host → docker run --gpus all nvidia-smi → compose exec nvidia-smi → check a nivel app. La primera capa que falla te dice exactamente qué componente arreglar.

Conclusión

Los contenedores con GPU solo se sienten frágiles cuando las tres capas se improvisan por separado. Con el sistema de esta guía — driver más toolkit en el host, reservas explícitas en Compose, sabores CUDA pineados, imágenes multi-stage — tu app de IA se vuelve infraestructura aburrida: un repo, un compose up, mismo comportamiento de GPU en todos lados.

Empezá por el checklist de aceptación en tu propia máquina, después pineá tus tags y commiteá. Si lo próximo es desplegar modelos abiertos sobre ese stack, mis guías de GPT-OSS y Qwen3 muestran exactamente qué correr encima.

El Stack, de un Vistazo

Host

  • • Driver NVIDIA + nvidia-smi
  • • nvidia-container-toolkit
  • • nvidia-ctk + restart docker

Compose

  • • deploy.resources.reservations
  • • driver nvidia + [gpu]
  • • count XOR device_ids

Imagen

  • • Tag nvidia/cuda pineado
  • • devel compila, runtime shippea
  • • nvcr.io para pins duraderos

Fuentes

Diego Rodriguez

Diego Rodriguez

Ingeniero Senior Full-Stack & AI

Diego tiene mas de 9 anos de experiencia construyendo aplicaciones potenciadas por IA de produccion, desde orquestacion de LLMs y pipelines RAG hasta deteccion de riesgos con ML y sistemas de trading algoritmico.

Conoce mas sobre Diego