Ollama (Plataforma de Ejecución Local de Modelos)

1. Visión general del concepto y problema sistémico

Antes de la llegada de Ollama, ejecutar un modelo de lenguaje abierto localmente era un desafío de ingeniería complicado: el desarrollador tenía que clonar manualmente el repositorio llama.cpp, configurar los flags del compilador para la arquitectura de su GPU (CUDA, Metal o ROCm), buscar archivos de cuantización dispersos en Hugging Face, convertir pesos, calcular el uso de memoria para las capas y configurar manualmente las etiquetas de control de las plantillas de chat (<|im_start|>, [INST]). Un error en un solo símbolo especial convertía la generación en un conjunto sin sentido de palabras.

Ollama transformó radicalmente este proceso, convirtiéndose en el "Docker para la inteligencia artificial". La plataforma empaquetó pesos, parámetros de cuantización, instrucciones del sistema y plantillas de diálogo en un único artefacto estandarizado: Modelfile. El ingeniero puede gestionar modelos locales a través de una interfaz CLI concisa (run, pull, list, rm) y conectarlos instantáneamente a cualquier aplicación externa.

2. Taxonomía arquitectónica y modelo mental

El marco arquitectónico de Ollama se basa en un ligero demonio en Go y un núcleo de alto rendimiento en C++:

┌─────────────────────────────────────────────────────────────┐
│                     OLLAMA SYSTEM ARCHITECTURE              │
├─────────────────────────────────────────────────────────────┤
│ 1. Host Daemon & API Server (Escrito en Go):                │
│    • API REST local (localhost:11434)                       │
│    • Capa de compatibilidad con OpenAI (/v1/chat/completions)│
│    • Controlador de intercambio dinámico de modelos (Keep-Alive Manager) │
├─────────────────────────────────────────────────────────────┤
│ 2. Capa de artefactos unificada (Modelfile & OCI Registry): │
│    FROM base_model ➔ PARAMETER temperature ➔ SYSTEM prompt  │
├─────────────────────────────────────────────────────────────┤
│ 3. Motor de cálculo central (llama.cpp bajo el capó):       │
│    • Despachador de hardware: Apple Metal / NVIDIA CUDA / ROCm  │
│    • Divisor de capas automático: VRAM vs RAM del sistema    │
├─────────────────────────────────────────────────────────────┤
│ 4. Subsistema de almacenamiento (~/.ollama/models/blobs)     │
└─────────────────────────────────────────────────────────────┘

1. Demonio del servidor (Capa del demonio Go):
   • Proceso en segundo plano que gestiona la cola de solicitudes, controla la carga y descarga de modelos en memoria (parámetro keep_alive, por defecto 5 minutos de inactividad).
2. Plantillador Modelfile:
   • Archivo de configuración declarativo similar a un Dockerfile. Permite fijar el modelo base, modificar parámetros de muestreo (temperature, top_p, num_ctx) y establecer reglas de comportamiento inmutables para el agente.
3. Backend de cálculo (llama.cpp):
   • Utiliza aceleradores de hardware específicos de la máquina. Determina automáticamente la cantidad de memoria de video disponible y descarga las capas en el GPU de la manera más eficiente.
4. Almacenamiento de contenido (Blobs Storage):
   • Almacena las capas de los modelos en el directorio ~/.ollama/models. Las capas compartidas entre diferentes versiones de modelos se deduplican, ahorrando espacio en disco.

3. Pipeline técnico y mecánica interna

Ciclo de vida de ejecución de un comando en el entorno de Ollama:

1. Solicitud para ejecutar un modelo: El ingeniero ejecuta: ollama run deepseek-r1:14b.
2. Descarga del manifiesto y pesos: Si el modelo no está presente localmente, el cliente se conecta al registro registry.ollama.ai, descargando en paralelo las capas cuantizadas GGUF y verificando sus sumas de verificación.
3. Introspección de hardware y asignación de memoria: El backend escanea el sistema:
   • Lee la cantidad de VRAM disponible en el GPU.
   • Calcula el tamaño del modelo teniendo en cuenta la ventana de contexto asignada (por ejemplo, num_ctx: 32768).
   • Distribuye los cálculos entre GPU y CPU sin intervención manual del usuario.
4. Inicio de sesión y apertura de sockets: El modelo se inicializa en memoria. Se abre una sesión TUI interactiva en la consola y el puerto en segundo plano 11434 comienza a aceptar solicitudes HTTP.
5. Generación en streaming y manejo de herramientas: Al recibir un prompt, Ollama envía tokens a llama.cpp, soportando tanto un simple streaming de texto como llamadas estructuradas a herramientas (Tool Calling) en formato JSON.

4. Escenarios prácticos de ingeniería en producción

01. Despliegue de un asistente privado para VS Code / Cline

El ingeniero configura el trabajo en un proyecto confidencial:

• Comando en la terminal: ollama run qwen2.5-coder:32b.
• En el plugin de Cline se especifica el proveedor "OpenAI Compatible", URL http://localhost:11434/v1 y el nombre del modelo qwen2.5-coder:32b.
• El desarrollador obtiene un entorno de agente completo con edición de código autónoma, que funciona 100% offline.

02. Creación de un Modelfile personalizado para la empresa

Creación de un modelo especializado para cumplir con estrictas normas del equipo:

• El ingeniero escribe el archivo Modelfile:

  FROM llama3.3:70b
  PARAMETER temperature 0.2
  PARAMETER num_ctx 32768
  SYSTEM """Eres un arquitecto de sistemas senior. Escribe código exclusivamente en Go. Usa solo la biblioteca estándar y el logger de Uber Zap. Cualquier comentario escríbelo en ucraniano."""
  

• Ejecuta el comando ollama create senior-go -f ./Modelfile.
• Obtiene un nuevo modelo personalizado senior-go, listo para ser utilizado por todo el equipo.

03. Automatización de la verificación de prompts en CI/CD local

El ingeniero prueba la fiabilidad de la extracción de JSON de texto no estructurado:

• En el script de prueba se llama al endpoint http://localhost:11434/api/generate con el flag format: "json".
• El conjunto de pruebas se ejecuta localmente en segundos sin gastar dinero en tokens en la nube.

5. Errores comunes, trampas y seguridad

• Limitación de la ventana de contexto por defecto: Por defecto, muchos modelos de Ollama establecen una pequeña ventana de contexto (2048 tokens) para ahorrar memoria. Para trabajar con código extenso, asegúrate de aumentar este parámetro a través del Modelfile o el parámetro API (num_ctx: 16384 o 32768).
• Riesgo de abrir el puerto 0.0.0.0 sin autenticación: Por defecto, Ollama escucha en 127.0.0.1. Si el desarrollador cambia la variable a OLLAMA_HOST=0.0.0.0 para acceder desde otra PC, el servidor local se vuelve accesible a toda la red local sin ninguna contraseña.
• Cola secuencial de solicitudes (Concurrency Throttling): Si varios desarrolladores acceden simultáneamente a un servidor Ollama, las solicitudes se ejecutarán en secuencia a menos que se aumente explícitamente el parámetro OLLAMA_NUM_PARALLEL.
• Acumulación de gigabytes de modelos antiguos en disco: Cada modelo de 70B en cuantización de 4 bits ocupa alrededor de 40 GB en SSD. Descargar decenas de modelos diferentes rápidamente agota el espacio en disco del portátil. Ejecuta regularmente ollama rm.