Entrenar y servir modelos en Ollama para uso interno seguro y eficiente

La irrupción de la inteligencia artificial generativa ha cambiado por completo la forma en la que empresas y desarrolladores trabajan con el software, los datos y la automatización. Cada semana aparecen nuevos modelos y herramientas, pero al mismo tiempo seguimos dependiendo en gran medida de unas pocas grandes plataformas de nube que controlan precios, privacidad y funcionalidades. En ese contexto, cobra mucha fuerza la idea de ejecutar y entrenar modelos en local, con soluciones como Ollama que permiten trabajar con LLMs en tu propia infraestructura, sin exponer los datos a terceros.

Frente al enfoque más centralizado de los grandes proveedores, ha ido creciendo con fuerza un ecosistema de modelos y herramientas open source que cualquiera puede descargar, ajustar y desplegar en sus equipos. Ollama se ha consolidado como una de las piezas clave de este movimiento: simplifica al máximo la puesta en marcha de LLMs en local, hace de puente con interfaces web como Open WebUI o n8n, y permite servir modelos por API de forma muy parecida a OpenAI, pero con privacidad total, costes controlados y una flexibilidad brutal para personalizar y afinar cada modelo.

Por qué entrenar y servir modelos en Ollama para uso interno

Cuando usamos un chatbot en una web o una API en la nube, cada petición implica costes, latencia y posibles riesgos de privacidad. Para un usuario individual puede no ser dramático, pero en una empresa que procesa contratos, historiales médicos o documentación financiera, enviar todo eso a un proveedor externo es, como mínimo, delicado.

Al entrenar (o afinar) y servir modelos en Ollama dentro de la propia red o equipo, todo el ciclo de vida del dato se queda bajo tu control: prompts, documentos que subes al modelo, respuestas generadas, metadatos, históricos… nada sale de tus máquinas. Esto encaja como un guante en organizaciones con requisitos estrictos de confidencialidad, cumplimiento normativo o simplemente aversión a depender de terceros para algo tan estratégico como la IA.

Además, el coste por uso deja de ser un quebradero de cabeza. En vez de pagar por cada millón de tokens a una API comercial, haces una inversión en hardware (o en un servidor dedicado / VPS con GPU) y, a partir de ahí, la inferencia es esencialmente gratuita. Para flujos de automatización intensivos, como integraciones con n8n o sistemas internos de asistencia, la diferencia económica es enorme.

Otro punto clave es la flexibilidad para elegir y personalizar modelos. Con Ollama puedes combinar modelos pequeños muy rápidos (Phi, TinyLlama, Orca Mini) para tareas simples, con otros más pesados y potentes (Llama 3, Mistral, Gemma, Qwen, DeepSeek, etc.) para razonamientos complejos o generación de código. Y si necesitas algo todavía más específico, siempre puedes hacer fine-tuning con técnicas como LoRA y servir ese modelo afinado desde el propio Ollama.

Conceptos clave: LLMs, Transformers y cuantización para uso local

Antes de meternos hasta el fondo en Ollama merece la pena aclarar, sin demasiada teoría densa, qué hay debajo de los LLMs modernos y por qué conceptos como la cuantización son tan importantes cuando quieres ejecutarlos en tu propio hardware.

Los Large Language Models son redes neuronales de gran tamaño entrenadas con aprendizaje automático auto-supervisado sobre cantidades brutales de texto y otros datos. Su misión es predecir la siguiente palabra (token) más probable dadas las anteriores, y a partir de ahí generan texto, código, resúmenes, traducciones o análisis.

La mayoría de LLMs actuales se basan en la arquitectura Transformer, que convierte las palabras de entrada en vectores numéricos (embeddings) y, usando mecanismos de atención, calcula qué partes del contexto son más relevantes para producir cada palabra de salida. A nivel muy alto, hay dos bloques fundamentales: un encoder que “entiende” la entrada y un decoder que genera la respuesta, aunque en la práctica muchos modelos de chat son solo decoder.

Para generar texto, el modelo procesa los tokens en paralelo, calcula probabilidades para la siguiente palabra y elige una de ellas (aplicando técnicas de muestreo como temperature, top_p o top_k). Esa palabra se añade al contexto y se repite el ciclo hasta completar la respuesta. Cambiar estos parámetros influye directamente en si el modelo es más creativo o más conservador.

El gran problema práctico de estos modelos es que, en su versión “pura”, usan pesos en coma flotante de 16 o 32 bits y eso se traduce en archivos gigantescos y un consumo de RAM y VRAM tremendo. Aquí entra en juego la cuantización, que reduce la precisión de los pesos (por ejemplo, a 4 u 8 bits enteros) para recortar el tamaño del modelo y hacerlo más manejable en hardware normal.

Requisitos de hardware para entrenar y servir modelos con Ollama

Una duda recurrente cuando se plantea ejecutar modelos en local es qué hace falta a nivel de hardware. La respuesta corta es que no necesitas un superordenador, pero tampoco puedes ir con un PC de hace 15 años y esperar milagros.

• Memoria. Para un uso razonable de Ollama se recomienda al menos 16 GB de RAM. Con 8 GB puedes tirar con modelos pequeños (1B, 3B, 7B cuantizados), sabiendo que puede haber tirones.
• CPU. Lo ideal es disponer de procesadores modernos con conjuntos de instrucciones avanzadas (AVX2, AVX-512) y mínimo 4 núcleos, siendo 8 o más lo recomendable.
• GPU. No es estrictamente obligatoria, pero si quieres respuestas ágiles marca la diferencia de forma brutal. Una GPU NVIDIA con CUDA, una AMD con ROCm o una GPU integrada de Apple (Metal) pueden acelerar 5-10 veces la inferencia frente a CPU pura.
• Almacenamiento. Ollama como software pesa poco, pero los modelos no. Reserva al menos 50 GB si piensas descargar varios modelos de 7B y 13B; si vas a tocar bestias de 70B o múltiples variantes cuantizadas, no es raro acabar en decenas o cientos de gigas.
• Sistema operativo. Ollama funciona sin problemas en Linux, macOS y Windows (este último a menudo apoyándose en WSL o Docker).

Instalación de Ollama y configuración básica para entornos internos

Una de las grandes ventajas de Ollama es que la instalación se hace en un comando en la mayoría de sistemas y deja un servicio listo para usar tanto desde la terminal como desde aplicaciones externas vía API.

En Linux, el método más extendido es lanzar en una terminal:

curl -fsSL https://ollama.com/install.sh | sh

En Windows y macOS, descargas el instalador desde la web oficial de Ollama, lo ejecutas y el sistema se encarga de dejar el servicio corriendo en segundo plano. Puedes comprobar que todo está en orden con un simple ollama –version en la consola.

Por defecto, Ollama levanta un servidor local en 127.0.0.1:11434 y guarda los modelos descargados en una ruta específica según el sistema. En Linux, con la instalación típica, suelen quedar en /usr/share/ollama/.ollama/models. Esta carpeta es crítica porque ahí se acumularán todos los modelos y conviene tenerla controlada para temas de espacio, copias de seguridad y migraciones.

Para adaptar Ollama a un uso interno más avanzado (por ejemplo, servir modelos a otros equipos de la red o a contenedores Docker), se usan variables de entorno que el servicio lee al arrancar. Algunas de las más importantes son:

• OLLAMA_HOST: interfaz y puerto en el que escucha la API (por ejemplo, 0.0.0.0:11434 para aceptar conexiones externas).
• OLLAMA_MODELS: ruta personalizada donde se almacenan los modelos.
• OLLAMA_ORIGINS: control de CORS para permitir o restringir orígenes que llaman a la API.
• OLLAMA_KEEP_ALIVE: tiempo que un modelo permanece cargado en memoria tras la última petición.
• OLLAMA_DEBUG: activa el modo depuración para ver más detalles en los logs.

En distribuciones Linux que usan systemd, lo típico es editar la configuración del servicio con sudo systemctl edit ollama.service, añadir las líneas bajo [Service] con las variables deseadas (Environment=»OLLAMA_HOST=0.0.0.0:11434″, etc.), guardar, y luego ejecutar sudo systemctl daemon-reload y sudo systemctl restart ollama.

Gestión de modelos en Ollama: descarga, ejecución y administración

Una vez está el servicio en marcha, el flujo básico con Ollama es muy directo: descargar modelos, ejecutarlos, consultarlos por API y, si hace falta, eliminarlos o clonarlos para personalizarlos.

Descargar modelos

Para descargar un modelo desde el registro de Ollama se utiliza el comando ollama pull, por ejemplo:

ollama pull llama3.2:1b

Si solo pones el nombre sin tag, se baja la variante marcada como latest, que suele ser una combinación equilibrada de tamaño y precisión. En la web de Ollama puedes filtrar modelos por temática (chat, code, vision, thinking, etc.) y dentro de cada uno verás varias etiquetas importantes:

• Tamaño (1B, 3B, 7B, 13B, 32B, 70B…): número de parámetros del modelo, que influye tanto en la calidad como en los recursos que necesita.
• Cuantización (q2_K, q4_K_M, q8_0, fp16…): indica el esquema de compresión; a menor bit y más agresiva la cuantización, menos memoria necesita y algo de precisión se pierde.
• Variante funcional: instruct, chat, code, vision, etc., que marca el tipo de tarea para el que está afinado.

Iniciar una sesión

Para arrancar una sesión interactiva con un modelo, usas ollama run modelo. Si el modelo no estaba descargado, lo bajará primero y después te aparecerá un prompt en la terminal donde puedes escribir tus preguntas. Dentro de este modo hay comandos especiales como /help, /set parameter, /show (para ver plantilla, parámetros, licencia), /save y /load de sesiones, o /bye para salir.

Ollama también permite pasar el prompt como argumento directo sin entrar al modo interactivo, algo muy cómodo para scripts o integraciones rápidas, por ejemplo:

ollama run llama3.2:1b «Resume este archivo: $(cat README.md)»

Verificar modelos instalados

Para ver qué modelos tienes instalados en la máquina puedes usar ollama list, que muestra nombre, ID, tamaño y fecha de modificación. Si necesitas detalle fino de un modelo (metadatos, plantilla completa, parámetros por defecto), el comando es ollama show nombre_modelo.

Cuando un modelo ya no te hace falta o necesitas liberar espacio en disco, puedes eliminarlo con ollama rm nombre_modelo. Y si quieres crear una variante propia a partir de otro (por ejemplo, para cambiar prompts de sistema, plantillas o parámetros), tienes ollama cp, que copia el manifiesto del modelo sin duplicar físicamente el archivo de pesos, ahorrando mucho espacio.

Para entornos internos es muy útil también ollama ps, que muestra qué modelos están cargados en memoria, cuánto ocupan y si se están ejecutando en CPU o GPU. Desde ahí puedes controlar qué hay activo en cada momento y pararlo con ollama stop nombre_modelo cuando no lo necesites.

Modelos libres recomendados y criterios de elección

La gracia de usar Ollama es que puedes trabajar con una colección enorme de modelos abiertos de alta calidad, muchos de ellos publicados con licencias libres que permiten su uso, modificación y redistribución sin demasiadas trabas.

Para que un modelo se considere verdaderamente libre se suele pedir que sus pesos sean descargables sin restricciones, que el código fuente esté disponible, que use licencias de software libre (MIT, Apache 2.0, GPL…) y que no imponga limitaciones de uso demasiado agresivas. Algunos ejemplos muy interesantes dentro del ecosistema Ollama son:

• DeepSeek-R1: con pesos bajo licencia MIT, permite uso comercial y derivar nuevos modelos (incluyendo distilación) sin problemas.
• Phi-4: modelo de Microsoft de 14B parámetros, entrenado con datos sintéticos y fuentes públicas, también bajo MIT, muy apañado para tareas generales.
• Mistral 7B: distribuye bajo Apache 2.0, con variantes instruct y completion, rápido y muy equilibrado calidad/rendimiento.
• Qwen2.5: familia con tamaños desde 0.5B hasta 72B, la mayoría bajo Apache 2.0 salvo algunos tamaños con licencia Qwen.

Cuando te planteas qué modelo usar o afinar para tu empresa, no solo importa el tamaño o la licencia: también debes fijarte en la tarea concreta. Para chat general y asistentes corporativos, Llama 3, Mistral, Gemma o Qwen suelen ir muy bien; para generación de código destacan variantes como CodeLlama o DeepSeek-Coder; para análisis o resumen de textos suelen rendir mejor los modelos etiquetados como instruct; y si necesitas trabajar con imágenes (multimodal), te tocará tirar de modelos específicos como Llava, Moondream o Bakllava.

A partir de ahí, lo que manda es la prueba: medir en tu propio dataset y tus propios casos de uso cómo se comporta cada modelo, en tiempo de respuesta y en calidad de salida, para quedarte con el que mejor encaje.

Entrenamiento y ajuste fino de modelos para uso interno

Servir modelos tal cual salen del registro de Ollama está muy bien para empezar, pero en cuanto quieres que la IA hable tu idioma de negocio, maneje tus procesos o adopte cierto tono, entra en juego el fine-tuning. No se trata de entrenar un LLM desde cero (eso es otra liga), sino de ajustar un modelo base con tus propios datos.

La forma más habitual de hacerlo de forma asequible es usar LoRA (Low Rank Adaptation), que añade capas adicionales ligeras sobre el modelo original. Estas capas aprenden las “diferencias” que quieres introducir, sin tocar los pesos base, lo que reduce muchísimo el coste de entrenamiento y permite aplicar los cambios sin perder el conocimiento general del modelo.

Para orquestar este proceso se suelen usar librerías como Axolotl, que simplifica la preparación de datasets y el lanzamiento del fine-tuning sobre modelos como Mistral-7B. La idea es preparar un conjunto de ejemplos con el formato adecuado (normalmente JSONL con campos role y content, siguiendo el esquema system/user/assistant) que representen las conversaciones o respuestas ideales para tu caso de uso.

En el archivo de configuración (por ejemplo, config.yaml) defines cosas como:

• adapter: lora para indicar que usarás LoRA.
• base_model: mistralai/Mistral-7B-v0.1 u otro modelo compatible.
• load_in_8bit: true para ahorrar memoria durante el entrenamiento.
• datasets con la ruta al conjunto de datos y el mapeo de columnas role/content.

En cuanto a hardware, afinar un modelo de este tamaño suele necesitar GPU decente. Si no tienes en casa una A100 o similar, soluciones como RunPod, Colab, Kaggle o máquinas virtuales con GPU en la nube te permiten alquilar potencia por horas. Con unos cuantos euros puedes entrenar varias variantes LoRA si el dataset no es gigantesco.

Del modelo afinado a GGUF y despliegue en Ollama

Con el modelo fusionado en formato Hugging Face en tu poder, el siguiente paso para servirlo en Ollama es convertirlo al formato GGUF, que es el que usan llama.cpp y, por extensión, Ollama, para hacer inferencia eficiente en CPUs y GPUs de consumo.

Para la conversión se usa el script convert_hf_to_gguf.py, indicando la carpeta del modelo fusionado, el tipo de cuantización (por ejemplo, q8_0) y el nombre de salida del archivo GGUF. Algo del estilo:

python3 convert_hf_to_gguf.py merged/ –outfile model_q8_0.gguf –outtype q8_0

Este archivo resultante, cuantizado y compacto, es el que copiarás a la carpeta de modelos de Ollama. Si estás usando Ollama dentro de un contenedor Docker con GPU, lo más cómodo es montar un volumen entre tu sistema y el contenedor, de forma que el archivo GGUF esté disponible dentro de /root/.ollama/models o la ruta que hayas configurado.

La orquestación con Docker suele hacerse con un docker-compose.yml que levante el contenedor de Ollama, exponga el puerto 11434, monte la carpeta de modelos y, en su caso, declare el uso de la GPU. A partir de ahí, el contenedor se comporta igual que una instalación nativa: responde en la API HTTP y carga modelos desde la ruta compartida.

Para que Ollama “vea” tu modelo personalizado, necesitas crear un Modelfile (muy parecido a un Dockerfile) donde defines qué archivo GGUF usar, qué parámetros por defecto tendrá y qué plantilla de prompt se aplicará. Un Modelfile simple podría ser:

FROM model_q8_0.gguf
PARAMETER temperature 0.7
PARAMETER top_p 0.9
PARAMETER top_k 40
PARAMETER num_ctx 4096

Una vez creado el Modelfile en la carpeta adecuada, registras el modelo en Ollama con ollama create nombre_modelo -f ruta/Modelfile. Desde ese momento puedes usarlo como cualquier otro, tanto en la terminal (ollama run nombre_modelo) como por API o desde interfaces gráficas como Open WebUI.

Servir modelos de forma segura: API local, Open WebUI, n8n y más

Con el modelo entrenado, cuantizado y registrado en Ollama, llega la parte divertida: ponerlo al servicio de tus aplicaciones internas. Ollama expone una API HTTP en el puerto 11434, con endpoints para generación de texto y otras funciones, y además ofrece un modo de compatibilidad con la API de OpenAI, lo que facilita integrar modelos locales en apps que originalmente hablaban con la nube.

Si quieres una interfaz gráfica tipo ChatGPT para tu equipo, Open WebUI es una opción muy popular. Se despliega fácilmente con Docker, apuntando al backend de Ollama mediante la URL del servidor (por ejemplo, http://localhost:11434 o http://host.docker.internal:11434 si está dentro de otro contenedor), y permite a los usuarios elegir el modelo, gestionar historiales, configurar parámetros y chatear sin tocar la terminal.

Para automatizaciones más avanzadas, n8n entra en escena como un orquestador de flujos. Gracias al nodo nativo de Ollama, puedes invocar modelos locales dentro de workflows que leen correos, procesan PDFs, consultan APIs externas o actualizan bases de datos, todo ello manteniendo los datos sensibles dentro de tu infraestructura.

La clave para conectar n8n con Ollama es configurar correctamente la variable OLLAMA_HOST en el servidor de IA (por ejemplo, 0.0.0.0:11434) y, en las credenciales de n8n, apuntar a la dirección correcta (localhost si comparten host, o host.docker.internal si n8n está en Docker). A partir de ahí solo te queda seleccionar el modelo en cada nodo y construir los prompts a partir de la información que fluye por el workflow.