Correr modelos de lenguaje grandes (LLMs) en hardware limitado, como un clúster de Single-Board Computers (SBCs), no es un ejercicio teórico de diseño; es una prueba de fuego en optimización bruta. La realidad es que estás forzando gigabytes de parámetros en memorias que no superan los 16GB. Este desafío es complejo y requiere valentía técnica. La única ruta viable es la contenedorización estricta junto con la cuantización del modelo.

Nuestra estrategia es simple: usar Docker Compose para orquestar la inferencia con Ollama, el motor que mejor maneja la arquitectura ARM64 y los modelos GGUF cuantizados. Esto nos permite un control granular del uso de recursos, que es vital cuando cada megabyte de RAM cuenta. La eficiencia es una métrica, no una promesa vacía.

Requisitos Previos de Ingeniería

Antes de tocar la terminal, valida tu plataforma. Necesitas un SBC con arquitectura ARM64 (Raspberry Pi 4/5, Jetson Orin/Nano, u otros) con un mínimo de 8GB de RAM. En el software, la distribución Linux debe estar actualizada y lista para la gestión de contenedores. No te molestes con menos memoria; la inferencia simplemente morirá por OOM Kill (Out Of Memory).

Paso 1: Instalación de la Plataforma de Contenedores

La base de toda la operación es Docker. La instalación debe ser rápida y eficiente para añadir la capa de aislamiento necesaria. Asegúrate de añadir tu usuario al grupo `docker` para evitar la fricción constante del `sudo`.

# Actualizar el sistema e instalar Docker y Docker Compose sudo apt update && sudo apt upgrade -y sudo apt install docker.io docker-compose -y  # Añadir el usuario al grupo 'docker' para operar sin sudo sudo usermod -aG docker $USER  # Verificar la arquitectura. Debe ser 'aarch64' para un SBC moderno. echo "Verificando arquitectura de CPU:" uname -m

Si la salida de `uname -m` no es `aarch64` (o similar a ARM), detente. No desperdicies tu tiempo intentando forzar binarios x86. Cipher Vance no acepta excusas de compatibilidad.

Paso 2: Configuración del Contenedor de Inferencia (Ollama)

Vamos a definir nuestro stack. Creamos un directorio de trabajo y un archivo `docker-compose.yaml`. Este archivo es nuestro plano de batalla para la gestión de recursos. La clave aquí es el mapeo del volumen para que los modelos persistan entre reinicios y la restricción de memoria para evitar la saturación del SBC.

# Crear directorio y entrar en él mkdir ollama-inference && cd ollama-inference  # Crear el archivo de configuración nano docker-compose.yaml

Ingresa la siguiente configuración. Nota la sección `deploy: resources`. Es tu fusible de seguridad para evitar que Ollama consuma toda la RAM, dejando espacio para el sistema operativo.

version: '3.8' services:   ollama:     image: ollama/ollama:latest     container_name: ollama-inference-server     restart: always     ports:       - "11434:11434"     volumes:       - ./ollama_data:/root/.ollama     # Restricción de recursos OBLIGATORIA para SBCs ARM64     deploy:       resources:         limits:           memory: 6g # EJEMPLO: Limitar a 6GB de los 8GB totales de un SBC

Paso 3: Despliegue y Elección del Modelo Cuantizado

Con el plano listo, levantamos el servicio. En SBCs, no se trabaja con modelos completos; se trabaja con modelos cuantizados. La cuantización (por ejemplo, Q4_K_M) reduce drásticamente el requisito de VRAM/RAM con una pérdida mínima de precisión. Elige un modelo pequeño y eficiente, como Mistral 7B.

# Desplegar el servicio en modo demonio docker compose up -d  # Esperar unos segundos a que el contenedor se inicie sleep 10  # Descargar un modelo cuantizado (Mistral 7B en formato Q4_K_M) # Es un equilibrio decente entre rendimiento y tamaño de memoria. echo "Iniciando descarga de modelo cuantizado (esto puede tardar)..." docker exec -it ollama-inference-server ollama pull mistral:7b-instruct-q4_K_M

Una vez descargado el modelo, el contenedor de Ollama ya está listo para la inferencia. El control del tamaño del modelo es la métrica más crítica en esta fase. Si el modelo es demasiado grande para tu limitación de memoria, la operación fallará silenciosamente o con latencias insoportables.

Paso 4: Pruebas de Latencia y Monitoreo (TTFT y TPS)

El rendimiento se mide en Time To First Token (TTFT) y Tokens Per Second (TPS). Ignora cualquier otra métrica. Una latencia alta en TTFT significa que el modelo está siendo swappeado a disco, lo que en un SBC es una sentencia de muerte para la usabilidad.

Para verificar que el servicio está activo y que la latencia inicial es aceptable, ejecuta una consulta de prueba.

curl -X POST http://localhost:11434/api/generate -d '{   "model": "mistral:7b-instruct-q4_K_M",   "prompt": "Explica la contenedorización en una frase.",   "stream": false }'

El resultado debe mostrar el texto de respuesta y, al final del JSON, métricas como `load_duration` y `eval_count`. Esos números son tu realidad.

Para el monitoreo en tiempo real, que es donde se distingue un SysAdmin de un teórico, usa `docker stats`.

# Comando de monitoreo en vivo para CPU y RAM (Presiona Ctrl+C para salir) watch -n 1 'docker stats --no-stream --format "table {{.Name}}t{{.CPUPerc}}t{{.MemUsage}}t{{.MemPerc}}t{{.CPUPerc}}"'

Esta vista cruda de porcentajes de CPU y RAM te dirá la verdad sobre si el hardware está claudicando o si tu estrategia de limitación de recursos está funcionando. Si el porcentaje de RAM supera consistentemente el 85% de tu límite (6g en el ejemplo), tienes un problema de tamaño de modelo que debe ser corregido con una cuantización más agresiva (e.g., Q2_K) o un modelo más pequeño.