Ollama Modelfile Guide: Parameters, System Prompts and Templates

A Modelfile is a simple configuration file that tells Ollama how to run a model — setting the system prompt, adjusting generation parameters like temperature and context window, and creating a named model variant you can reuse. If you have ever wanted to give a model a persistent persona, lower its temperature for coding tasks, or increase the context window beyond the default, a Modelfile is the right tool. This guide covers the full Modelfile syntax with practical examples for the most common use cases.

What a Modelfile Does

When you run ollama run llama3.2, Ollama uses the base model’s default settings. A Modelfile lets you extend any base model with your own configuration and save it as a named model. The named model behaves identically to the base model at inference time but with your parameters baked in — so ollama run my-coding-assistant always starts with low temperature, a coding-focused system prompt, and a 16k context window without you having to specify any of that in each API call.

Modelfile Syntax Overview

A Modelfile is a plain text file with a series of instructions, one per line. The FROM instruction is the only required one — it specifies the base model. All other instructions are optional. The most commonly used instructions are FROM, SYSTEM, PARAMETER, and TEMPLATE.

The FROM Instruction

FROM specifies the base model. Use any model name that appears in ollama list — for example FROM qwen2.5-coder:7b or FROM llama3.2. You can also point FROM at a local GGUF file path: FROM ./my-model.gguf. This is how you import models that are not in the Ollama model library. When building on top of an existing Ollama model, FROM pulls in all its existing parameters and template, which your Modelfile instructions then override or extend.

The SYSTEM Instruction

SYSTEM sets a persistent system prompt that is prepended to every conversation with your model. This is the most commonly used Modelfile instruction — it lets you give the model a specific persona, set behavioural constraints, or prime it for a particular task without repeating the instructions in every API call. Write the system prompt as a multi-line string between triple quotes. Keep it specific and directive — vague system prompts produce inconsistent results. For a coding assistant, specify the programming language, response style, and whether to include explanations alongside code. For a document summariser, specify the output format, length, and any domain-specific terminology to use.

Key PARAMETER Settings

The PARAMETER instruction sets generation parameters. The most useful ones for everyday customisation:

• temperature — Controls randomness. 0.0 is fully deterministic, 1.0 is the default, values above 1.0 are more creative but less coherent. For coding and factual tasks, use 0.1–0.3. For creative writing, 0.7–0.9.
• num_ctx — The context window size in tokens. Default is typically 2,048. Increase to 8,192 or 16,384 for long documents or extended conversations. Uses proportionally more RAM at larger sizes.
• top_p — Nucleus sampling threshold. Default 0.9. Lower values make output more focused; raise toward 1.0 for more diverse text.
• repeat_penalty — Penalises repeating the same tokens. Default 1.1. Increase to 1.2–1.3 if the model gets stuck in repetitive loops.
• num_gpu — Number of GPU layers. Set to 99 to use all available GPU layers (Ollama handles fitting what it can). Set to 0 to force CPU-only inference.
• keep_alive — Override the default model unload timeout for this specific model. Set to -1 to keep it loaded permanently.

Creating and Using a Modelfile

Save your Modelfile as a plain text file (the filename does not need a specific extension, though “Modelfile” is conventional). Then run ollama create my-model-name -f ./Modelfile to build the named model. Ollama processes the file, applies your configuration on top of the base model, and registers the new model name locally. Run it with ollama run my-model-name. List all your models including custom ones with ollama list. To inspect the Modelfile of any model (including ones downloaded from the library), run ollama show model-name --modelfile.

Practical Modelfile Examples

A coding assistant: set FROM to your preferred coding model, add a SYSTEM prompt specifying the language and output format, and set temperature to 0.1 and num_ctx to 16384 for long file context. A general assistant with a larger context: take any base model, set num_ctx to 32768, and optionally add a SYSTEM prompt with your preferred response style. A model with few-shot examples: use MESSAGE instructions to pre-populate the conversation with example user-assistant exchanges that demonstrate the response format you want, then new conversations automatically see those examples as context. A GGUF import: point FROM at a local GGUF file path, add your preferred SYSTEM and PARAMETER instructions, and create a named Ollama model from any GGUF file you have downloaded directly — useful for models not yet in the Ollama library.

Modelfile vs Per-Request Parameters

Anything you set in a Modelfile can also be overridden per-request by passing options in the API call body. The Modelfile sets the default for all requests to that model; per-request options override those defaults for a single call. This layering means you can use a Modelfile to set sensible defaults for your deployment and still allow individual API calls to adjust temperature or context size dynamically for specific requests without rebuilding the model. For applications that always need a specific system prompt and parameters, the Modelfile is more efficient than repeating them in every API call.

Frequently Asked Questions

Do I need to rebuild the model if I change the Modelfile?

Yes. Modelfile changes only take effect after running ollama create again with the updated file. The create command is fast — it does not re-download the base model, only applies the new configuration layer.

Can I share a Modelfile with others?

Yes. A Modelfile is just a text file. Share it like any configuration file. The recipient needs the same base model downloaded locally. Modelfiles can also be pushed to the Ollama model registry alongside the model weights.

How do I set the context window larger than the default?

Add PARAMETER num_ctx 16384 (or your desired value) to your Modelfile and recreate the model. Alternatively, pass "options": {"num_ctx": 16384} in the API request body to override for a single call without rebuilding.

Last updated: October 2026

Viewing and Managing Your Custom Models

Once you have created custom models with Modelfiles, a few commands help you manage them. ollama list shows all models including your custom ones alongside their size and creation date. ollama show model-name --modelfile prints the Modelfile of any model — useful for inspecting what parameters were set, checking the system prompt of a downloaded model, or copying a configuration to modify. ollama rm model-name removes a custom model, freeing its storage (the base model it was derived from stays unless you remove that separately). Custom models are stored alongside base models in your Ollama models directory and behave identically in the API — you can use them as the base in another FROM instruction to create layered configurations, though keeping Modelfiles simple and flat is generally cleaner.

Modelfile for Local GGUF Models

One of the most practical Modelfile use cases is importing GGUF files that are not in the Ollama model library. Download any GGUF file — from Hugging Face, a custom fine-tune, or a converted model — and create a Modelfile with FROM /path/to/model.gguf. Add your SYSTEM prompt and PARAMETER settings, then run ollama create my-custom-model -f Modelfile. Ollama imports the GGUF, applies your configuration, and registers it as a named model. This is particularly useful for newly released models that have not yet appeared in the Ollama library, experimental fine-tunes, and quantisation variants you have created yourself with llama.cpp. Once imported, the model behaves identically to any library model — you can run it, use it via the API, and access it from Open WebUI or Continue.dev.

Modelfiles are one of Ollama’s most underused features. Most users stick with default model settings when a few lines of configuration would eliminate repeated system prompt copying, improve output consistency, and tailor generation parameters to their specific task. Start with a simple Modelfile that sets your preferred system prompt and temperature, create a named model, and you will immediately notice the difference in how reliably the model behaves across sessions. From there, experimenting with context window size and repeat penalty unlocks further improvements for your specific workflow.

Organising a Library of Modelfiles

Once you start creating custom models, naming discipline keeps things manageable. Give each model a name that reflects its purpose and a version suffix, store every Modelfile in a Git repository, and use ollama show with the modelfile flag to inspect what a model is actually configured to do. Remove models you no longer use, because each one takes disk space, and document the base model and key parameters in a short README so teammates can reproduce your setup.

Revisit your Modelfiles whenever you switch base models, since a system prompt and parameters tuned for one model rarely transfer perfectly to another, and re-test before replacing a configuration you depend on daily.