La batalla por la eficiencia en el edge no admite filosofías; solo métricas. Cuando desplegamos modelos GGUF optimizados para CPU en hardware limitado, cada megabyte de RAM y cada ciclo de CPU que se consume por el container runtime es una pérdida de rendimiento en la inferencia. Nuestro objetivo es claro: medir el overhead de contenerización (latencia y uso de memoria) que imponen Docker y Podman sobre una baseline en Linux bare metal. El trabajo de optimizar es una lucha dura, y el coraje no se mide en manifiestos, sino en la capacidad de reducir el VmRSS del sistema.

Requisitos Previos e Instalación de la Baseline

Antes de meter contenedores en el camino, necesitamos una base de referencia inmutable. Para este análisis, usaremos Ollama como runtime de GGUF, ya que simplifica la gestión de modelos y permite una comparación directa de la inferencia. El sistema debe ser Linux (Debian/Ubuntu/RHEL) limpio, bare metal (sin virtualización de hipervisor).

Verificación de Sistema Base

El primer paso es asegurar que estamos trabajando en metal puro y que tenemos las herramientas para medir. Es imposible optimizar lo que no se puede medir.

# Verificación de sistema Bare Metal uname -a lscpu | grep "Model name" # Instalación de herramientas de diagnóstico y dependencias sudo apt update && sudo apt install -y git build-essential htop sysstat jq curl

Establecimiento de la Baseline (Host Nativo)

Instalaremos Ollama directamente en el host para obtener nuestro rendimiento de cero overhead. Este es el punto de partida técnico. Mediremos el consumo de VmRSS (Resident Set Size de Memoria Virtual) y la latencia de la inferencia.

# Instalar Ollama directamente en el host (BASELINE) curl -fsSL https://ollama.com/install.sh | sh # Descargar el modelo para el test. Usamos Llama 3 como ejemplo GGUF. ollama pull llama3:8b

Paso 1: Medición de Overhead de Baseline

Una vez instalado, ejecutamos una prueba de inferencia sencilla. El tiempo que tarda el comando en completarse y el VmRSS del proceso `ollama` son nuestras métricas clave.

# Ejecutar prueba de inferencia (Time-to-First-Token y Tokens/s) time ollama run llama3:8b "dime una palabra" --verbose # Medir uso de memoria de la baseline (VmRSS - Sin overhead) pidof ollama | xargs -I {} cat /proc/{}/status | grep VmRSS

El valor de VmRSS que obtengas aquí es el mínimo teórico. Cualquier valor superior en los contenedores es el overhead que estamos combatiendo. Anota este número; es tu némesis.

: Macro shot of a single, powerful CPU die connected by glowing blue traces to dedicated memory modules, representing the raw, measured performance baseline on bare metal. Technical schematics style, sharp focus on silicon texture.

Paso 2: Análisis de Overhead con Docker

Docker, con su arquitectura daemon centralizada, introduce un costo fijo de ejecución. Este daemon (dockerd) es persistente y consume recursos incluso cuando no hay contenedores activos, lo que inmediatamente aumenta el overhead de memoria en sistemas de recursos limitados.

Instalación y Despliegue de Docker

Necesitamos el runtime de Docker y luego desplegar el mismo modelo y configuración.

# Instalación de Docker CE sudo apt update && sudo apt install -y docker.io sudo usermod -aG docker $USER # REINICIA LA SESIÓN para aplicar el grupo 'docker' antes de continuar # Despliegue de Ollama en Docker docker run -d --name ollama-docker    -v /root/.ollama:/root/.ollama    -p 11434:11434    ollama/ollama

Medición de Overhead de Docker

La medición aquí debe ser doble: la inferencia (latencia) y el uso de recursos reportado por el daemon de Docker (que incluye el costo del runtime más el proceso del contenedor).

# Ejecutar prueba de inferencia via API para asegurar paridad de la prueba curl -s -X POST http://localhost:11434/api/generate -d '{"model": "llama3:8b", "prompt": "dime una palabra"}' | jq -r .response # Medir Overhead de Docker (Memoria y CPU del cgroup/runtime) docker stats --no-stream --format "{{.Name}}: {{.MemUsage}} / {{.CPUPerc}}" ollama-docker

Paso 3: Análisis de Overhead con Podman (Rootless)

Podman se ejecuta sin un daemon central persistente; es decir, el proceso del contenedor es el proceso padre. Esto, en teoría, elimina el costo fijo del daemon y debería resultar en un overhead de memoria significativamente menor, crucial para GGUF en bare metal.

Instalación y Despliegue de Podman

El enfoque es rootless para maximizar la seguridad y la eficiencia, utilizando Podman para simular el entorno de Ollama.

# Instalación de Podman (Alternativa Daemonless) sudo apt install -y podman # Configurar para rootless. Esto requiere que el usuario exista en /etc/subuid y /etc/subgid podman system migrate # Despliegue de Ollama en Podman (Rootless es clave para el overhead bajo) podman run -d --name ollama-podman    -v ${HOME}/.ollama:/root/.ollama:Z    -p 11434:11434    --security-opt label=disable    ollama/ollama

Medición de Overhead de Podman

Ejecutamos la misma prueba de inferencia, y luego comparamos el uso de memoria a través de las herramientas nativas de Podman.

# Ejecutar prueba de inferencia (mismo comando API) curl -s -X POST http://localhost:11434/api/generate -d '{"model": "llama3:8b", "prompt": "dime una palabra"}' | jq -r .response # Medir Overhead de Podman (Memoria y CPU) podman stats --no-stream --format "{{.ContainerName}}: {{.MemUsage}} / {{.CPU}}%" ollama-podman

Conclusiones Técnicas del Overhead

La comparación final es cruda: se trata de una resta. Compara el VmRSS de la Baseline con el MemUsage reportado por `docker stats` y `podman stats`. El delta más pequeño es el ganador de la eficiencia. Normalmente, en configuraciones bare metal con hardware limitado, la ausencia de un daemon persistente en Podman se traduce en un menor overhead de memoria base y, por lo tanto, en un mejor uso de los recursos para cargar el modelo GGUF en RAM. En la práctica, esto significa que Podman permite cargar un modelo marginalmente más grande o mantener más margen de maniobra en el sistema operativo host.

Si los números muestran que Docker utiliza, por ejemplo, 50MB extra solo para el daemon y el runtime base, esos 50MB son recursos robados directamente de la capacidad de su LLM GGUF. En la optimización de IA en el edge, no podemos permitirnos esa pérdida. La lucha por la eficiencia de recursos es una batalla constante; esta guía es el mapa táctico para ganarla.