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.

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ó?».

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.

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.

<div style="margin:28px 0;border:1px solid #dbe3ef;border-radius:12px;overflow:hidden;background:#0f172a;"> <div style="padding:10px 14px;background:#111827;color:#cbd5e1;font:13px Consolas,monospace;">Modelfile</div> <pre style="margin:0;padding:18px;overflow:auto;color:#e5e7eb;font:13px/1.55 Consolas,monospace;"><code>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. """</code></pre> </div>

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.

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.

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.