Parámetros de Ollama Modelfile explicados: guía completa para crear modelos personalizados

Actualización 2026-06-08: revisado con la documentación oficial de Modelfile de Ollama — hay 7 instrucciones (FROM / PARAMETER / TEMPLATE / SYSTEM / ADAPTER / LICENSE / MESSAGE; no existe REQUIRES). Se corrigió el enlace de introducción y se añadieron lecturas relacionadas de la misma serie.

En el artículo anterior vimos cómo poner en marcha un modelo. Pero un problema me persigue: las respuestas son demasiado inconsistentes.

Cuando le hago a llama3.2 una pregunta sencilla de código, a veces me da tres líneas claras y otras veces un ensayo entero. Si subo temperature a 0.8, empieza a «creativizar»; si la bajo a 0.1, se vuelve rígido, como si recitara de memoria. Peor aún: en cada conversación hay que volver a configurar el system prompt, copiando y pegando hasta hartarse.

Luego descubrí el Modelfile de Ollama. En pocas palabras, es el «currículum de personalidad» del modelo: lo configuras una vez y queda fijo para siempre. En este artículo reúno los errores que he cometido y la experiencia de ajuste, incluidos consejos sobre 10 parámetros clave y 4 plantillas listas para usar.

Si aún no has instalado Ollama, conviene leer antes la guía de introducción a Ollama. Este es contenido avanzado; asumimos que ya sabes usar ollama run.

1. Qué es Modelfile y por qué lo necesitas

Modelfile es el «plano de configuración» del modelo, parecido al concepto de Dockerfile: le dices a Ollama qué modelo usar como base, qué parámetros aplicar, qué system prompt escribir y qué nombre darle. Después, cada vez que invocas ese nombre, toda la configuración se aplica sola.

En resumen, resuelve tres dolores habituales:

Dolor uno: repetir la configuración cada vez

Seguro que te ha pasado: abres la terminal, ollama run llama3.2, escribes un system prompt. Al día siguiente, otra vez. Al tercero, igual… ¿No cansa? Modelfile deja fija esa configuración: una vez y para siempre.

Dolor dos: estilo de salida inestable

El mismo modelo, con parámetros distintos, puede dar resultados muy diferentes. Un asistente de código necesita salida estable; la escritura creativa necesita variedad. No puedes recordar siempre «ah, esta tarea va con temperature 0.3 y aquella con 0.8» — Modelfile guarda los presets por ti.

Dolor tres: gestionar variantes del modelo

Quieres un «llama3.2 para revisión de código», uno «asistente de escritura» y otro «salida JSON». ¿Copiar el modelo tres veces? No hace falta. Con Modelfile creas tres variantes con nombre distinto; el archivo base sigue siendo el mismo, solo cambia la configuración.

El flujo básico son tres pasos:

# 1. Crear un archivo Modelfile
echo 'FROM llama3.2
SYSTEM "Eres un experto en revisión de código"' > Modelfile

# 2. Generar el nuevo modelo con ollama create
ollama create my-coder -f Modelfile

# 3. Ejecutarlo directamente
ollama run my-coder

Así de simple. A continuación, qué puedes escribir dentro del Modelfile.

2. Estructura del Modelfile y 7 instrucciones

La sintaxis es sencilla: comentarios con #, instrucciones en mayúsculas. Por ejemplo:

# Esto es un comentario
FROM llama3.2
PARAMETER temperature 0.8
SYSTEM "Eres un asistente amable"

El archivo solo tiene dos tipos de contenido: comentarios e instrucciones. Hay 7 instrucciones; aquí va el mapa general:

Instrucción	Función	¿Obligatoria?	Cuándo usarla
FROM	Especifica el modelo base	Sí	En todo Modelfile
PARAMETER	Ajusta parámetros de inferencia	No	Temperatura, contexto, etc.
TEMPLATE	Plantilla de prompts	No	Formato de conversación personalizado
SYSTEM	Mensaje de sistema	No	Rol y comportamiento
ADAPTER	Carga adaptador LoRA	No	Tras fine-tuning
LICENSE	Declaración de licencia	No	Al publicar un modelo
MESSAGE	Historial de conversación predefinido	No	Ejemplos few-shot

En la práctica, el 90 % del tiempo bastan FROM, PARAMETER y SYSTEM. El resto, cuando haga falta.

Tres formas de usar FROM

FROM es la única instrucción obligatoria. Tiene tres variantes:

Forma uno: nombre del modelo (la más habitual)

FROM llama3.2
FROM llama3.2:3b
FROM mistral:latest

Usa el nombre de un modelo soportado por Ollama. Tras los dos puntos va la etiqueta de versión; sin ella, latest.

Forma dos: archivo GGUF local

FROM ./my-model.gguf

Si descargaste un modelo en formato GGUF, puedes apuntar directamente al archivo.

Forma tres: directorio Safetensors

FROM ./my-safetensors-dir

Menos frecuente; suele ser el formato original descargado de Hugging Face.

Con la estructura básica clara, lo importante: los parámetros PARAMETER.

3. Parámetros PARAMETER al detalle

Esta es la parte más útil del artículo. Reúno los errores que cometí al ajustar parámetros y una tabla que puedes copiar.

Lista completa de parámetros:

Parámetro	Valor predeterminado	Tipo	Para qué sirve	Cómo ajustarlo
temperature	0.8	float	Controla la aleatoriedad; más alto = más «libertad»	Código 0.3, creativo 1.0
num_ctx	2048	int	Tamaño de la ventana de contexto	Documentos largos 4096-8192
top_k	40	int	Solo elige entre las K palabras más probables	Normalmente no tocar
top_p	0.9	float	Muestreo nucleus, controla diversidad	Combinar con temperature
min_p	0.0	float	Filtra palabras de probabilidad muy baja	Salida de calidad: 0.05
seed	0	int	Semilla fija para reproducir salida	Pruebas: 42 u otro valor fijo
stop	ninguno	string	Detiene al ver esta secuencia	Varios stop se pueden acumular
num_predict	-1	int	Longitud máxima de salida; -1 = sin límite	Limitar: 100-500
repeat_penalty	1.1	float	Penaliza contenido repetido	Textos largos: 1.5
repeat_last_n	64	int	Revisa repetición en las últimas N palabras	Junto con repeat_penalty

A continuación, los más importantes.

temperature: creatividad frente a estabilidad

Es el parámetro más intuitivo. Con temperature alta (p. ej. 1.0), el modelo «se suelta» y elige palabras menos probables pero más creativas; con temperature baja (p. ej. 0.1), se vuelve conservador y elige las más probables, con salida más estable.

Probé llama3.2 con distintos valores de temperature ante la misma pregunta:

Pregunta: ¿Cómo leer un archivo en Python?

• temperature 0.1: respuesta de manual, solo la respuesta estándar
• temperature 0.5: añade consejos prácticos, p. ej. «cuidado con la codificación»
• temperature 0.8: puede cubrir distintos escenarios y dar ejemplos
• temperature 1.0: respuestas muy variadas; a veces se desvía del tema

Mi experiencia:

• Código y preguntas técnicas: ~0.3, estabilidad
• Escritura creativa e ideación: 0.8-1.0, sorpresa
• Salida JSON o formato fijo: 0.1-0.2, precisión

num_ctx: ventana de contexto

Define cuánto contenido puede «recordar» el modelo. El predeterminado es 2048 tokens, unos 1500-2000 caracteres en chino o equivalente en español.

¿Quieres que lea un artículo largo y lo resuma? 2048 puede quedarse corto. ¿Llevas mucho rato conversando y olvida lo anterior? Probablemente num_ctx es demasiado pequeño.

Importante: subir num_ctx consume más memoria. Con llama3.2, pasar de 2048 a 8192 más que duplicó el uso de RAM. Con 8 GB de memoria, 4096 suele ser un techo razonable.

Mi experiencia:

• Conversaciones cortas: 2048 basta
• Revisión de código o debate técnico: 4096 cómodo
• Documentos largos o novelas: 8192 (si hay memoria)

stop: secuencias de parada

Muy útil: le dices al modelo «para aquí».

Por ejemplo, pides JSON y temes texto de más:

PARAMETER stop "\n\n"
PARAMETER stop "```"

Al ver dos saltos de línea o el cierre de un bloque de código, deja de generar; la salida queda más limpia.

Puedes apilar varios stop; mucha gente no lo sabe.

repeat_penalty: evitar relleno

Los modelos repiten frases. repeat_penalty penaliza la repetición.

El valor por defecto 1.1 a veces me parece poco. En textos largos suelo usar 1.3-1.5 y reduce frases del tipo «como se dijo antes» o «en conclusión».

Tabla de parámetros por escenario

Cuatro escenarios habituales con configuración recomendada:

Escenario	temperature	num_ctx	Otros parámetros
Asistente de código	0.3	4096	stop ”```”, seed 42 (reproducibilidad)
Escritura creativa	1.0	2048	top_p 0.95, repeat_penalty 1.5
Preguntas técnicas	0.5	4096	min_p 0.05 (filtrar palabras pobres)
Salida JSON	0.1	2048	stop “\n\n”, stop ”```”

Con esto deberías tener una idea clara de cada parámetro. Siguiente paso: cuatro plantillas Modelfile listas para usar.

4. Casos prácticos: 4 Modelfiles completos

Teoría hecha; código directo. Las cuatro plantillas las he probado; copia, pega y ejecuta.

Caso 1: Role-play — asistente Pigsy (Zhu Bajie)

Un modelo divertido que imita el estilo de Zhu Bajie (Pigsy):

# Asistente Pigsy Modelfile
FROM llama3.2

SYSTEM """Eres Zhu Bajie (Pigsy) de Viaje al Oeste. Habla con humor y tono cercano.
Al responder:
- Quejarte a veces de que el maestro es muy pesado
- Emocionarte cuando se menciona comida
- Referirte a ti como 'este cerdo viejo'
- Ante dificultades, decir 'mejor nos separamos'"""

PARAMETER temperature 0.8
PARAMETER num_ctx 2048

Por qué esta configuración:

temperature 0.8 da más «personalidad» al personaje, sin rigidez. El SYSTEM fija reglas concretas — emoción con la comida, autoreferencia como «este cerdo viejo» — que hacen el rol más vivo.

Uso:

ollama create pig-bajie -f Modelfile
ollama run pig-bajie

Prueba: «¿Cómo aprender bien a programar?» y mira cómo responde.

Caso 2: Asistente profesional — revisión de código Python

La configuración que uso a diario para revisar código:

# Asistente de revisión de código Python Modelfile
FROM llama3.2:3b

SYSTEM """Eres un desarrollador Python senior. Al revisar código, prioriza:
1. Seguridad de tipos — errores de tipo potenciales
2. Manejo de excepciones — casos límite cubiertos
3. Cuellos de botella — bucles innecesarios o cálculos redundantes
4. Riesgos de seguridad — exposición de datos sensibles

Formato de respuesta:
Problema → Impacto → Sugerencia → Ejemplo de código"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER seed 42

Por qué esta configuración:

temperature 0.3 mantiene la salida estable; revisar código no pide «creatividad». num_ctx 8192 porque los archivos pueden ser largos. seed 42 para reproducibilidad: la misma pregunta, la misma sugerencia, útil para comparar.

En la práctica: le paso un script de cientos de líneas y devuelve un informe claro en formato Problema → Impacto → Sugerencia → Ejemplo.

Caso 3: Salida estructurada — formato JSON

Si la salida va a otro programa, JSON es lo más cómodo:

# Asistente de salida JSON Modelfile
FROM llama3.2

SYSTEM """Tu salida debe ser JSON válido.
Formato del análisis:
{"result": "contenido del análisis", "confidence": 0-100, "tags": ["etiqueta1", "etiqueta2"]}

No escribas nada más. No uses marcadores de bloque de código."""

PARAMETER temperature 0.1
PARAMETER num_ctx 2048
PARAMETER stop "\n\n"
PARAMETER stop "```"

MESSAGE user Analiza los riesgos de seguridad de este código
MESSAGE assistant {"result": "Riesgo de inyección SQL, entrada de usuario sin filtrar", "confidence": 85, "tags": ["seguridad", "SQL"]}

Por qué esta configuración:

temperature 0.1 para máxima estabilidad; el JSON no admite desviaciones. stop filtra saltos de línea y bloques de código. MESSAGE es un ejemplo few-shot: «la salida debe verse así».

Lo uso en flujos automatizados: logs de error al modelo, análisis estructurado, el programa procesa el resto.

Caso 4: Contexto largo — resumen de documentos

Para artículos largos hace falta ventana amplia:

# Asistente de resumen de documentos Modelfile
FROM llama3.2

SYSTEM """Eres experto en resúmenes. Requisitos de salida:
- No más de 5 puntos clave
- Cada punto no más de 50 palabras
- Primero la idea central, luego detalles
- Responde en español"""

PARAMETER temperature 0.5
PARAMETER num_ctx 8192
PARAMETER num_predict 300

Por qué esta configuración:

temperature 0.5 — estable pero no plano (muy bajo vuelve el resumen una lista seca). num_ctx 8192 para documentos largos. num_predict 300 limita la longitud; un resumen no debe superar al original.

Con esto resumo artículos técnicos: un texto de unas 3000 palabras → 5 puntos breves, lectura más eficiente.

Resumen

Estas cuatro plantillas cubren necesidades habituales. Ajusta SYSTEM o parámetros a tu gusto; tras editar el Modelfile, vuelve a ollama create — el coste de prueba es bajo.

5. TEMPLATE y MESSAGE avanzados

En los casos anteriores no usamos TEMPLATE; es función «avanzada», para cuando necesitas control fino del formato de conversación.

Sintaxis Go template de TEMPLATE

Ollama usa la sintaxis de plantillas de Go. Tres variables clave:

• {{ .System }} — contenido de SYSTEM
• {{ .Prompt }} — entrada del usuario
• {{ .Response }} — salida del modelo (define el formato de respuesta)

Ejemplo sencillo:

FROM llama3.2

TEMPLATE """{{ .System }}

Pregunta del usuario: {{ .Prompt }}

Respuesta: {{ .Response }}"""

SYSTEM "Eres un experto técnico"

El TEMPLATE fija la estructura: SYSTEM, pregunta, respuesta.

En la mayoría de casos no hace falta personalizar TEMPLATE; el predeterminado de Ollama basta. ¿Cuándo sí?

Escenario uno: integrar con otras herramientas

Conectas Ollama a un chat con formato de entrada propio; TEMPLATE adapta el formato.

Escenario dos: formato de conversación especial

Prefijos como [AI] o [USER] en cada turno; TEMPLATE lo implementa.

MESSAGE: historial predefinido

MESSAGE «muestra ejemplos» al modelo. El caso JSON ya lo usaba:

MESSAGE user Analiza los riesgos de seguridad de este código
MESSAGE assistant {"result": "Riesgo de inyección SQL", "confidence": 85}

Equivale a decir: «cuando pregunten esto, responde así» — aprendizaje few-shot.

Puedes encadenar varios turnos:

MESSAGE user Hola
MESSAGE assistant Hola, ¿en qué puedo ayudarte?
MESSAGE user ¿Qué tiempo hace?
MESSAGE assistant No tengo datos en tiempo real; consulta una app del tiempo.

Al arrancar, el modelo «recuerda» ese historial y el tono se mantiene.

Cómo ver el Modelfile de un modelo

Para inspeccionar la configuración de un modelo:

ollama show --modelfile llama3.2

La salida es larga e incluye toda la configuración predeterminada. Cópiala, modifica y crea tu variante.

Muy útil cuando alguien comparte un modelo que funciona bien: ollama show, exportar Modelfile y aprender de su configuración.

6. Problemas frecuentes y cómo evitarlos

Ajustar parámetros implica tropezar. Estos son los errores típicos que he visto.

Problema uno: temperature demasiado baja, salida de manual

Algunos creen que cuanto más baja, mejor — salida estable. Yo también lo pensé y puse 0.05 en un asistente de código.

Resultado: respuestas como de libro de texto, sin flexibilidad. «¿Cómo leer un archivo en Python?» — tres métodos correctos pero sin ningún consejo práctico.

Lección: temperature no es «cuanto más bajo, mejor». Revisión de código: 0.3 basta; por debajo de 0.2 se vuelve rígido. JSON sí pide valores bajos; conversación normal, no tanto.

Problema dos: num_ctx demasiado alto, memoria agotada

Una vez puse num_ctx en 16384 para documentos enormes. Tras unos minutos, swap a tope y el equipo casi inutilizable.

Tenía 16 GB de RAM. llama3.2:3b ocupa ~2 GB; de 2048 a 16384 la memoria se fue a más de 8 GB solo por contexto, más el resto de programas…

Lección: num_ctx no se sube a ciegas. Orientación:

• 8 GB RAM: num_ctx máximo ~4096
• 16 GB RAM: hasta ~8192
• 32 GB o más: puedes probar 16384

Problema tres: confundir SYSTEM y MESSAGE

Funciones distintas, fácil mezclarlas:

• SYSTEM: rol permanente, activo en cada conversación
• MESSAGE: historial de ejemplo, few-shot

Quieres un revisor de código: SYSTEM define el rol, MESSAGE da ejemplos de pregunta-respuesta.

Muchos solo ponen SYSTEM; el modelo «sabe» que es revisor pero no cómo responder casos concretos. Con unos MESSAGE, la calidad mejora notablemente.

Problema cuatro: actualizar tras crear

¿Cambiar configuración de un modelo ya creado?

Vuelve a ollama create con el mismo nombre:

# Primera creación
ollama create my-coder -f Modelfile

# ¿Cambios? Edita Modelfile y repite
ollama create my-coder -f Modelfile

Ollama sobrescribe el modelo con el mismo nombre; no hace falta borrarlo. Para conservar la versión anterior, otro nombre:

ollama create my-coder-v2 -f Modelfile

Problema cinco: replicar el Modelfile de otro

Ves un modelo compartido que rinde bien y quieres estudiar su configuración:

# Descargar el modelo
ollama pull someone-elses-model

# Exportar su Modelfile
ollama show --modelfile someone-elses-model > learned-modelfile

# Revisar y adaptar
cat learned-modelfile

Lo uso a menudo; de modelos de la comunidad he aprendido mucho sobre ajuste de parámetros.

Lectura relacionada

• Primeros pasos con Ollama: LLM locales en minutos
• API de Ollama en la práctica: llamadas compatibles con OpenAI
• Cuantización GGUF en Ollama: la guía completa

Conclusión

En una frase: Modelfile fija la configuración para no repetir ajustes manuales en cada sesión.

Tres acciones inmediatas:

1. Crea un modelo de role-play

Prueba la plantilla de Pigsy o cámbiala por un personaje que te guste (Doraemon, Iron Man, etc.). Conversa un rato y nota cómo temperature cambia el estilo.

2. Compara salidas con distintos parámetros

La misma pregunta con temperature 0.3 y 0.8. Lo he hecho muchas veces; siempre enseña algo nuevo.

3. Elige un escenario que uses de verdad

Revisión de código, resumen, escritura creativa — adapta una plantilla. Tras unas iteraciones tendrás un modelo a tu medida.

En el siguiente artículo veremos la API de Ollama: conectar el modelo local a tu aplicación con la interfaz compatible con OpenAI. Con el Modelfile listo, las llamadas API son más estables — los parámetros ya van en el modelo, no en el código.

Si tienes dudas, déjalas en comentarios; quizá algún error que ya cometí te ahorre tiempo.