Crear y usar modelos personalizados con ollama create

De Modelfile a modelo: ollama create

Una vez tienes un Modelfile (por ejemplo con FROM, SYSTEM y PARAMETER), el siguiente paso es construir el modelo con la CLI. El comando es ollama create: le indicas el nombre que quieres dar al modelo y, opcionalmente, el archivo Modelfile con -f o --file.

Desde el directorio donde está el Modelfile:

ollama create mi-asistente -f Modelfile

Si el archivo tiene otro nombre (por ejemplo Modelfile.mario):

ollama create mario -f Modelfile.mario

Ollama lee el Modelfile, resuelve el FROM (descargando el modelo base si hace falta), aplica SYSTEM, PARAMETER, TEMPLATE y ADAPTER si los has definido, y escribe el nuevo modelo en su almacenamiento local. Al terminar, el modelo queda registrado y puedes usarlo con ollama run mi-asistente o desde la API como cualquier otro modelo.

El nombre del modelo debe ser un único identificador. Si quieres algo parecido a versionado, usa un tag en el nombre (por ejemplo mi-asistente:v1). Así puedes tener varias variantes sin sobrescribir.

flowchart LR
    A["Modelfile<br/>FROM, SYSTEM,<br/>PARAMETER"] --> B["ollama create<br/>nombre -f Modelfile"]
    B --> C["Modelo registrado<br/>en catálogo local"]
    C --> D["ollama run nombre<br/>Probar en chat"]
    C --> E["API /api/chat<br/>Usar desde código"]
    C --> F["ollama show --modelfile<br/>Inspeccionar configuración"]

Comprobar que el modelo se creó bien

Tras ollama create, comprueba que el modelo aparece en la lista:

ollama list

Deberías ver tu modelo (por ejemplo mi-asistente) con su tamaño y fecha. Para probarlo en modo chat interactivo:

ollama run mi-asistente

Si en el Modelfile definiste un SYSTEM, verás que las respuestas siguen ese rol o estilo. También puedes llamar al modelo desde la API (POST /api/chat o /api/generate) usando ese mismo nombre.

Para inspeccionar el Modelfile que Ollama ha asociado al modelo (útil para depurar o reutilizar):

ollama show --modelfile mi-asistente

La salida muestra el Modelfile efectivo, con la base resuelta y los parámetros por defecto.

Buenas prácticas al crear modelos personalizados

Nombre y tags. Usa nombres descriptivos y evita espacios o caracteres raros. Para variantes (por ejemplo por temperatura o system prompt distinto) usa el mismo nombre base y distinto tag: mi-asistente:conservador, mi-asistente:creativo. Así mantienes un catálogo ordenado y evitas colisiones.

Modelfile versionado. Guarda el Modelfile en tu proyecto (por ejemplo en un repositorio) con un nombre que indique el propósito (Modelfile.asistente-tecnico). Así puedes recrear el mismo modelo en otra máquina o compartir la definición sin depender solo del binario.

Probar antes de compartir. Después de ollama create, haz unas preguntas de prueba con ollama run o con la API. Comprueba que el system prompt y los parámetros se comportan como esperas. Si usas MESSAGE para few-shot, verifica que las respuestas se alinean con los ejemplos.

Parámetros por defecto. No abuses de parámetros fijos en el Modelfile. Valores como temperature o num_ctx pueden dejarse por defecto y ajustarse en cada petición desde la API. Define en el Modelfile solo lo que quieras que sea la configuración por defecto del modelo (por ejemplo un SYSTEM fijo o un num_ctx mayor si tu caso lo requiere).

FROM estable. Si usas un modelo de la librería (por ejemplo llama3.2), ten en cuenta que sin tag se usará la variante por defecto (suele ser latest). Para reproducibilidad, conviene fijar el tag en el Modelfile (por ejemplo FROM llama3.2:3b) para que futuras ejecuciones de ollama create usen la misma base.

Cuantización al crear (--quantize)

Si el FROM apunta a un modelo en FP16 o FP32 (por ejemplo un GGUF sin cuantizar o un directorio Safetensors), puedes cuantizar en el momento de crear con la opción --quantize (o -q):

ollama create -f Modelfile --quantize q4_K_M mi-modelo

Así el modelo resultante ocupa menos espacio y puede ejecutarse con menos memoria, a cambio de una ligera pérdida de calidad. Las opciones típicas incluyen q4_K_M, q4_K_S y q8_0. Solo aplica cuando la base no está ya cuantizada.

Cuando el FROM es un modelo que ya está en Ollama (por ejemplo llama3.2), ese modelo ya viene cuantizado desde la librería, por lo que --quantize no suele usarse en ese flujo. Se usa sobre todo al importar modelos desde GGUF o Safetensors, como se verá en la lección de importación.

Ejemplo completo: asistente técnico en español

A continuación se muestra un flujo completo, desde la redacción del Modelfile hasta la prueba del modelo creado. Este ejemplo define un asistente técnico que siempre responde en español, con temperatura baja para respuestas precisas y un contexto amplio:

Modelfile.asistente-tecnico:

FROM llama3.2:3b
SYSTEM """Eres un asistente técnico especializado en desarrollo de software.
Responde siempre en español, de forma clara y concisa.
Si no sabes algo, indícalo en lugar de inventar."""
PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER num_predict 1024

Crear, verificar y probar:

# Crear el modelo
ollama create asistente-tecnico -f Modelfile.asistente-tecnico

# Verificar que aparece en la lista
ollama list

# Inspeccionar el Modelfile efectivo
ollama show --modelfile asistente-tecnico

# Probar con un prompt
ollama run asistente-tecnico "¿Qué es una API REST?"

Si el resultado no es el esperado (por ejemplo, respuestas demasiado largas, idioma incorrecto o tono inadecuado), ajusta el Modelfile y vuelve a ejecutar ollama create con el mismo nombre: el modelo se sobrescribirá con la nueva configuración. Este ciclo de editar, crear y probar es la forma habitual de iterar sobre modelos personalizados.

Eliminar un modelo personalizado

Los modelos creados con ollama create se eliminan de la misma forma que cualquier otro modelo:

ollama rm asistente-tecnico

Si tienes varias versiones con tags distintos (por ejemplo asistente-tecnico:v1, asistente-tecnico:v2), debes eliminar cada una por separado indicando el tag exacto. Los Modelfiles que hayas guardado en disco no se ven afectados: puedes recrear el modelo en cualquier momento.

Opciones y argumentos del comando ollama create

Aunque el uso típico solo emplea -f y un nombre, el comando admite más parámetros que conviene conocer para automatizar flujos:

| Opción | Descripción | Ejemplo | |--------|-------------|---------| | -f, --file | Ruta al Modelfile. Si se omite, se busca Modelfile en el directorio actual | ollama create mi-modelo -f Modelfile.prod | | -q, --quantize | Cuantiza el modelo al crearlo (solo si la base está en FP16/FP32) | ollama create mi-modelo -q q4_K_M | | nombre[:tag] | Nombre del modelo resultante, con tag opcional para versionar | ollama create mi-asistente:v2 |

Si el comando falla, revisa el mensaje con atención: Ollama suele indicar la línea del Modelfile que no ha podido interpretar. Los errores más habituales son un FROM apuntando a un modelo inexistente o un bloque SYSTEM sin comillas triples cuando ocupa varias líneas.

Ciclo iterativo recomendado

Crear un modelo personalizado suele ser un proceso iterativo: editas el Modelfile, construyes, pruebas y ajustas. Estructurar este ciclo ahorra mucho tiempo:

1. Redacta un Modelfile mínimo con FROM y un SYSTEM sencillo. No añadas todavía parámetros avanzados.
2. Construye con un tag :draft (ollama create mi-asistente:draft -f Modelfile) para no contaminar la versión estable.
3. Prueba con un set de prompts fijos que representen los casos reales de uso. Guarda las respuestas en un archivo para comparar después.
4. Afina los parámetros (temperature, num_ctx, top_p, repeat_penalty) uno a uno, manteniendo fijo el resto para identificar el impacto de cada cambio.
5. Sube de versión cuando estés satisfecho: ollama create mi-asistente:v1 -f Modelfile.
6. Archiva el Modelfile en el repositorio junto al tag para poder reproducirlo más adelante.

Este flujo es muy parecido al ciclo de desarrollo de un prompt engineer: tratas el Modelfile como código, lo versionas y usas tags como etiquetas de release.

Integración en pipelines y CI/CD

Para equipos que mantienen varios modelos personalizados, automatizar ollama create en un pipeline es muy sencillo. Un Makefile básico puede reducir la operación a un único comando:

MODEL_NAME ?= asistente-tecnico
MODEL_TAG  ?= v1
MODELFILE  ?= Modelfile.$(MODEL_NAME)

.PHONY: build test clean

build:
	ollama create $(MODEL_NAME):$(MODEL_TAG) -f $(MODELFILE)

test:
	@echo "Probando $(MODEL_NAME):$(MODEL_TAG)"
	@ollama run $(MODEL_NAME):$(MODEL_TAG) "Di hola en una frase" | tee /tmp/test.txt

clean:
	ollama rm $(MODEL_NAME):$(MODEL_TAG)

Con make build MODEL_TAG=v2 construyes una nueva versión sin tocar la v1. El mismo patrón vale en GitHub Actions, GitLab CI u otros orquestadores: la clave es que el Modelfile esté versionado y que el comando ollama create se ejecute de forma reproducible.

Errores comunes al usar ollama create

• «model not found» al hacer FROM: el modelo base no existe en el catálogo local. Ejecuta antes ollama pull con ese nombre o deja que Ollama lo descargue automáticamente.
• El Modelfile no se interpreta correctamente por un SYSTEM multilinea sin comillas triples. Usa siempre SYSTEM """...""" cuando el prompt ocupe más de una línea.
• Cambios no se reflejan: has olvidado volver a ejecutar ollama create. Editar el Modelfile no actualiza el modelo en el catálogo de forma automática.
• Sobrescritura accidental de una versión estable: si ejecutas ollama create mi-asistente -f Modelfile sin tag, pisas la versión anterior. Usa siempre tags para versiones públicas.
• Parámetros ignorados: algunos PARAMETER solo se aplican si el backend lo soporta (por ejemplo num_gpu requiere GPU). Verifica con ollama show --modelfile que el parámetro llegó al modelo final.
• --quantize sobre un modelo ya cuantizado: produce errores o resultados impredecibles. Solo úsalo con modelos en FP16 o FP32 importados desde GGUF/Safetensors.

Mejores prácticas

• Un Modelfile por propósito: no metas ramas condicionales ni varios SYSTEM alternativos. Si necesitas dos comportamientos, crea dos modelos.
• Documenta el Modelfile con comentarios # que expliquen por qué cada PARAMETER tiene el valor elegido.
• Apóyate en ollama show para confirmar que el modelo ha recogido tus cambios. Lo que ves ahí es lo que realmente usa el servidor.
• Pondera la latencia: un num_ctx muy alto aumenta el consumo de RAM y ralentiza la inferencia. Usa solo lo que realmente necesitas.
• Comparte solo Modelfiles, no los binarios resultantes. Es mucho más ligero distribuir el archivo de texto y dejar que cada máquina construya el modelo con ollama create.
• Vincula el tag con la commit del repositorio: un esquema como asistente-tecnico:2024-11-15-a1b2c3d hace trivial saber qué versión del Modelfile produjo cada modelo.

Con un flujo disciplinado de create, run y show, los modelos personalizados dejan de ser experimentos sueltos para convertirse en artefactos reproducibles que tu equipo puede mantener, compartir y evolucionar como cualquier otro componente del stack.