Ollama en producción: Docker, privacidad, API compatible y límites que sí importan

Ollama hace fácil ejecutar un modelo local; llevarlo a producción consiste en decidir qué puede alcanzar la red, quién llama a la API, cómo se versionan modelos y cuándo dejar de fingir que local equivale a seguro.

Ollama en producción es un runtime para servir modelos abiertos localmente mediante una API HTTP. No es un producto de privacidad ni una plataforma de agentes completa: es la capa de inferencia que debes encerrar detrás de autenticación, límites, red y observabilidad propias.

TL;DR

La keyword principal es Ollama en producción. La intención es práctica: desplegar Ollama con Docker, usar su API (o la compatibilidad con OpenAI), decidir dónde guardar modelos y evitar exponer el puerto 11434 a una red que no controlas.

Mi postura: úsalo primero para un caso interno, acotado y medible —clasificar tickets, resumir documentación permitida o un copiloto de bajo riesgo—. Si empiezas exponiendo un endpoint sin identidad, presupuesto ni trazas porque «el modelo está en tu máquina», has trasladado el riesgo; no lo has reducido.

Qué es Ollama y qué no resuelve

Ollama descarga y ejecuta modelos en una máquina y expone una API local. Su valor para un equipo es reducir fricción entre una aplicación y modelos abiertos: puedes hacer pull, servir chat, embeddings o tools y conservar un contrato HTTP estable cerca de tus datos o de tu entorno de desarrollo.

No sustituye un gateway de identidad, una política de datos, un sistema de secretos, un evaluador, un vector store ni un control de acceso por tenant. Tampoco hace seguro un prompt hostil: un modelo local puede seguir filtrar datos que le des, obedecer instrucciones inadecuadas o generar una acción errónea si tu aplicación se lo permite.

Piensa en Ollama como piensas en Postgres: un componente importante, no la arquitectura completa. La pregunta sana no es «¿puedo correr un LLM en local?», sino «¿qué petición autenticada puede usar qué modelo, sobre qué datos, con qué límite y cómo demostraré qué pasó?».

Una arquitectura mínima separa al consumidor del runtime: el gateway aplica identidad y cuotas; Ollama sirve inferencia; el volumen conserva modelos; y la telemetría permite operar sin registrar prompts completos por defecto.

Arquitectura mínima que sí desplegaría

La versión pequeña tiene cuatro piezas. La aplicación llama a un backend o gateway propio; ese borde autentica al usuario o servicio, limita tasa y tamaño, decide el modelo permitido y crea una traza. Solo entonces llama a Ollama en una red privada. El volumen de modelos es persistente y el sistema de métricas recibe duración, tokens o campos de uso disponibles, modelo, estado y errores, no necesariamente el prompt literal.

El puerto de Ollama debe quedar en loopback o en una red de contenedores no enrutable desde Internet. Si necesitas acceso remoto, publica el gateway con TLS y autenticación; no conviertas 11434 en tu API pública. Esta separación también te deja cambiar de runtime, enrutar una parte del tráfico a un proveedor externo o apagar un modelo problemático sin editar cada cliente.

Para varios tenants, el aislamiento no sale gratis por ejecutar local. Mantén la identidad y la autorización fuera del prompt: filtra documentos antes de construir contexto, utiliza credenciales de servicio de mínimo privilegio y no aceptes que el cliente elija libremente modelo, URL de herramientas o parámetros que multiplican coste.

Despliegue Docker seguro por defecto

Este compose.yaml no intenta resolver alta disponibilidad. Sí evita el error más común: publicar Ollama en todas las interfaces. El binding explícito a 127.0.0.1 hace que el host local pueda inspeccionarlo, pero no lo anuncia a la LAN. Conserva los modelos en un volumen para que una recreación del contenedor no obligue a descargarlos de nuevo.

compose.yaml

services:
  ollama:
    image: ollama/ollama:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama-models:/root/.ollama
    healthcheck:
      test: ["CMD-SHELL", "ollama list >/dev/null 2>&1"]
      interval: 30s
      timeout: 10s
      retries: 5

volumes:
  ollama-models:

Arranca con docker compose up -d, descarga un modelo desde una sesión administrativa con docker exec -it <contenedor> ollama pull llama3.2 y prueba curl http://127.0.0.1:11434/api/tags. En hardware acelerado, sigue la sección de GPU de la documentación oficial y verifica en logs qué backend se cargó: asumir que hay GPU es una forma cara de descubrir que todo está sirviendo por CPU.

API: úsala directa o mantén compatibilidad OpenAI

La API nativa de Ollama es la mejor elección cuando controlas el cliente y quieres sus conceptos tal cual. La compatibilidad parcial con OpenAI es útil para migrar un SDK existente o para que tu gateway tenga una interfaz uniforme, pero no debe llevarte a asumir paridad total de endpoints, estado o campos. Lee la tabla de compatibilidad de la versión que despliegues y prueba los casos que consumes.

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Lo que conviene comprobar

Un cliente Python mínimo puede hablar por la ruta compatible sin poner una clave secreta local. La cadena api_key existe porque el SDK la exige; no equivale a autenticar tu servidor. La autenticación real debe estar en el gateway delante de ese endpoint.

client.py

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:11434/v1/",
    api_key="ollama",  # requerido por el SDK; no autentica Ollama
)

reply = client.chat.completions.create(
    model="llama3.2",
    messages=[
        {"role": "system", "content": "Responde solo con JSON valido."},
        {"role": "user", "content": "{\"ticket\": \"T-42\"}"},
    ],
    response_format={"type": "json_object"},
)
print(reply.choices[0].message.content)

La validación continúa después del modelo. Parsea el JSON con un schema real, rechaza campos inesperados y no conviertas una respuesta del LLM directamente en SQL, shell, HTTP o una llamada mutante. Ese límite importa igual con modelo local, cloud o híbrido.

Modelos y Modelfile: versiona el contrato, no solo el nombre

Un nombre de modelo flotante no es una garantía de comportamiento. Para un workflow serio, fija versión de imagen, modelo y configuración que realmente evaluaste. Guarda también el hash de tu prompt, la plantilla, el tamaño de contexto, parámetros relevantes y el dataset de evaluación. Si cualquiera cambia, tienes una nueva variante de producción.

Un Modelfile permite partir de un modelo y declarar parámetros o instrucciones. Es útil para una política de salida estable o un contexto concreto, pero no es una frontera de seguridad: un usuario todavía puede intentar desviar la tarea y tu aplicación sigue teniendo que validar resultados y permisos.

Modelfile

FROM llama3.2
PARAMETER temperature 0.1
PARAMETER num_ctx 8192
SYSTEM """
Eres un clasificador de tickets internos.
Devuelve JSON con categoria, prioridad y evidencia breve.
No inventes datos que no aparezcan en la entrada.
"""

Crea una etiqueta evaluable con ollama create soporte-v1 -f Modelfile, ejecuta tu conjunto de casos y promociona esa etiqueta solo si pasa los gates de precisión, rechazo, latencia y coste de infraestructura. Una modificación de num_ctx puede cambiar memoria y latencia de forma material; no es un ajuste cosmético.

Privacidad: qué mejora y qué sigue siendo tu problema

Ejecutar inferencia dentro de tu red puede reducir la exposición a un proveedor externo, pero solo si el input, los logs, el almacenamiento de modelos, los backups, los proxies y la observabilidad respetan el mismo límite. Una traza con prompt completo en un SaaS externo invalida una parte importante de la decisión, aunque el token se haya calculado en local.

Define una clasificación de datos antes de permitirlos: público interno, confidencial, datos personales, secretos y datos prohibidos. Para cada clase, decide si puede entrar al prompt, cuánto tiempo se conserva, quién puede ver logs y qué hacer ante borrado o incidente. Si no puedes contestar esas preguntas, usa datos sintéticos hasta poder hacerlo.

Y no confundas ausencia de tráfico externo con seguridad. Prompt injection indirecta, documentos maliciosos, exfiltración mediante herramientas y una respuesta alucinada siguen siendo riesgos de la aplicación. Mantén tools con allowlist, separa lectura de escritura y exige aprobación humana para efectos externos.

Coste y capacidad: local no significa gratis

El coste se mueve de una factura por token a hardware, electricidad, VRAM o RAM, tiempo de operación, disco y capacidad ociosa. Por eso conviene medir por workload: tokens por segundo, latencia p50/p95, cola, memoria, modelo cargado, errores de carga y porcentaje de requests abandonadas. El número que importa no es solo «cuánto tarda una respuesta», sino cuánto tarda una petición útil bajo concurrencia real.

Empieza con una concurrencia pequeña y un modelo que quepa con margen en tu máquina. Aumentar contexto, paralelismo o modelos residentes puede deteriorar latencia o provocar presión de memoria. Pon timeout en el gateway, backpressure para la cola y un error claro cuando no hay capacidad, en lugar de dejar peticiones colgadas hasta que el caller reintente en cascada.

Si un caso requiere gran contexto, razonamiento fuerte o SLA estricto, un runtime local puede no ser la mejor capa principal. Diseña una ruta explícita: modelo local para clasificación y extracción barata; proveedor remoto aprobado para los casos que justifiquen coste y datos permitidos; y un fallback humano cuando el resultado no es seguro.

Observabilidad y evaluación antes de ampliar tráfico

Registra un ID de petición, usuario o servicio pseudonimizado, modelo, versión de prompt, latencia, cola, resultado de schema, tool calls y motivo de denegación. Evita convertir el tracing en un segundo repositorio de secretos: usa redacción, hashes o muestras aprobadas para el contenido sensible.

Antes de cambiar modelo, cuantización, contexto o Modelfile, ejecuta un dataset fijo con casos normales, ambiguos y hostiles. Mide tarea correcta, formato válido, evidencia, rechazo apropiado, coste de infraestructura y latencia. Haz un canary pequeño y compara contra la versión anterior; una demo manual no detecta regresiones silenciosas.

El enlace con la guía de evaluación RAG es deliberado: aunque no haya retrieval, necesitas una disciplina de dataset, baseline y gates. Sin ese contrato, cada actualización de modelo se convierte en una apuesta sobre usuarios reales.

Errores que veo al desplegar Ollama

Publicar 0.0.0.0:11434 y confiar en que la red corporativa ya es un control de acceso.

Permitir que el frontend elija cualquier modelo, tamaño de contexto o tool sin pasar por backend.

Descargar modelos sin inventario, licencia revisada, versión fijada ni prueba de comportamiento.

Guardar prompts completos, credenciales y documentos sensibles en logs por defecto.

Tratar el system prompt o el Modelfile como si fueran autorización de seguridad.

Medir una respuesta aislada en un portátil y declarar que hay capacidad de producción.

Cambiar modelo y prompt a la vez; cuando baja la calidad, nadie sabe qué regresó.

Checklist de salida a producción

• Ollama queda en loopback o red privada; no hay puerto de inferencia abierto a Internet.
• Un gateway autentica clientes, aplica cuotas, timeouts y un allowlist de modelos.
• Los modelos, Modelfiles y parámetros usados están versionados y evaluados.
• Los datos que entran al prompt tienen clasificación, retención y redacción definida.
• Las respuestas pasan schema validation antes de llegar a sistemas internos.
• Las tools tienen permisos mínimos; las acciones mutantes requieren confirmación y auditoría.
• Hay métricas de latencia, capacidad, errores y resultado de evaluación sin registrar secretos por defecto.
• Un canary y un rollback permiten volver a la variante anterior sin editar todos los clientes.

Conclusión

Ollama es muy útil cuando necesitas iterar con modelos abiertos cerca de tus sistemas y no quieres que cada equipo invente su propio launcher. Pero su ventaja se diluye si lo expones como una API anónima, no sabes qué modelo responde o registras indiscriminadamente todo el contexto.

Lo que conviene comprobar

Mi recomendación es aburrida y eficaz: un modelo, una tarea interna de lectura, un gateway, un dataset de evaluación, una red privada y telemetría mínima. Cuando puedas explicar latencia, datos, permisos y rollback con la misma claridad que explicas ollama run, entonces ya tienes una base para ampliar.

Preguntas frecuentes

¿Qué es Ollama en producción?

Es usar Ollama como runtime de inferencia para una aplicación real, con despliegue, red, identidad, límites, observabilidad, evaluación y rollback; no solo ejecutar un chat en local.

¿Ollama es privado por defecto?

Ejecutar un modelo en tu infraestructura puede reducir exposición externa, pero no garantiza privacidad. Siguen importando los prompts, logs, backups, proxies, permisos, modelos descargados y herramientas conectadas.

¿Puedo exponer Ollama directamente a Internet?

No es una buena arquitectura. Mantén el runtime en red privada y expón un gateway con TLS, autenticación, cuotas y validación de requests.

¿La compatibilidad OpenAI de Ollama es completa?

No. Facilita reutilizar parte de clientes y endpoints, pero debes comprobar las funciones y límites que necesita tu aplicación en la documentación y en tests de integración.

¿Cómo reduzco el coste de Ollama?

Mide tokens por segundo, latencia, cola, memoria y utilización; elige modelos que encajen en tu hardware, limita contexto y concurrencia, y enruta solo tareas justificadas al modelo más caro.

¿Un Modelfile protege contra prompt injection?

No. Sirve para configurar un modelo, pero la defensa requiere tratar contenido externo como datos, validar salidas, limitar tools y aplicar permisos en el servidor.

Cómo desplegar Ollama para un primer workflow interno

1. Acotar la tarea. Empieza con una operación de lectura y bajo riesgo, como clasificación o extracción de documentos permitidos.
2. Preparar red privada. Ejecuta el contenedor con puerto en loopback o una red interna; no publiques el puerto de inferencia.
3. Persistir y descargar. Monta volumen de modelos, descarga una versión elegida y anota imagen, modelo y parámetros.
4. Interponer gateway. Autentica al consumidor, limita tasa, fija modelos admitidos, define timeout y crea una traza por request.
5. Versionar contrato. Crea Modelfile si hace falta, guarda prompt y schema de salida, y etiqueta la variante evaluada.
6. Validar resultados. Parsea la salida con schema y separa cualquier tool o efecto externo de la respuesta del modelo.
7. Medir baseline. Ejecuta dataset de casos normales, ambiguos y hostiles; guarda calidad, latencia, capacidad y fallos.
8. Desplegar canary. Envía una fracción pequeña de tráfico, compara con baseline y conserva rollback a la variante previa.

Fuentes y referencias

• Ollama Quickstart
• Ollama API introduction
• Ollama OpenAI compatibility
• Ollama Modelfile reference
• Ollama FAQ: server, proxy and Docker
• Ollama official repository
• Docker: run containers
• OWASP Top 10 for LLM Applications

También te puede interesar

• LiteLLM Proxy: gateway IA, costes y modelos
• Prompt injection en agentes de IA
• OpenTelemetry GenAI para agentes
• Evaluación RAG en producción
• MCP en producción: seguridad y permisos

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis