HowdoyouwriteanOllamaModelfile?

What is an Ollama Modelfile?

An Ollama Modelfile is a plain-text recipe, similar in spirit to a Dockerfile, that ollama create compiles into a named model you can run, serve over the API and push to ollama.com. Each line is INSTRUCTION arguments, instructions are case-insensitive, and only FROM is required (Ollama docs). Anything you don’t set is inherited from the base model, so most useful Modelfiles are five lines long.

Here is a complete ollama modelfile example for a coding assistant built on a library model:

FROM qwen2.5-coder:7b
PARAMETER temperature 0.2
PARAMETER num_ctx 16384
SYSTEM """You are a senior Go reviewer. Answer with a diff or a short list of issues."""

ollama create go-reviewer -f ./Modelfile
ollama run go-reviewer

The -f flag defaults to a file named Modelfile in the current directory (per the ollama create --help text in v0.40.12). The model is stored as layers under Ollama’s model directory, not as a Modelfile on disk, so “where is the Modelfile?” has no file answer: you regenerate it with ollama show --modelfile.

Which instructions and parameters does a Modelfile support?

The documentation lists eight instructions; the parser in Ollama v0.40.12 (released October 27, 2026) accepts twelve. The four undocumented ones matter mostly when you import new architectures.

Sources: Modelfile reference for the first eight; parser.go and create.go for the rest.

The ollama modelfile parameters the docs define, with their documented defaults:

• num_ctx: context window. The Modelfile page still says 2048, but the context length page now sets the default by VRAM: 4k tokens under 24 GiB, 32k at 24 to 48 GiB, 256k at 48 GiB or more. Trust the newer page, and see the Ollama context length guide for sizing.
• temperature (0.8), top_k (40), top_p (0.9), min_p (0.0): sampling.
• repeat_penalty (1.0, disabled) and repeat_last_n (64): repetition control.
• seed (0): fix it for reproducible output.
• stop: a stop sequence; add one line per sequence.
• num_predict (-1, unlimited): max tokens per response.
• draft_num_predict: speculative draft tokens per step; 0 disables drafting.

penalize_newline, low_vram and f16_kv are deprecated and only print a warning.

How do you create a model from a GGUF file?

Point FROM at the file and run ollama create; Ollama copies the weights into its store and does not re-quantize them (import docs). For ollama create from gguf:

# Modelfile
FROM ./Qwen2.5-Coder-7B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 16384

ollama create qwen-coder-7b -f Modelfile
ollama show --modelfile qwen-coder-7b

Paths are absolute or relative to the Modelfile. For split GGUFs, keep the original shard names and use a wildcard such as FROM ./model-*.gguf. For a safetensors model, point FROM at the directory (FROM . if the Modelfile sits next to the weights); ollama create -q can quantize safetensors during import. Choosing the quant itself is covered in GGUF quantization explained.

You can often skip the Modelfile entirely. ollama run hf.co/{user}/{repo}:{quant} pulls a GGUF straight from Hugging Face, defaults to Q4_K_M when present, and picks a template from the GGUF’s tokenizer.chat_template metadata. Repo owners can override it with template, system and params files (Hugging Face docs). Then layer your own Modelfile on top with FROM hf.co/....

How do you view or copy an existing model’s Modelfile?

ollama show --modelfile <model> prints the effective Modelfile, including the TEMPLATE and stop parameters Ollama resolved:

ollama show --modelfile llama3.2 > Modelfile
ollama show --template llama3.2
ollama show --parameters llama3.2

The generated file’s FROM points at a blob path; its header comment tells you to replace that line with FROM llama3.2:latest to build a variant (docs). Other show flags print just --system, --license, or -v for verbose metadata. Since v0.40.7, ollama show also reports which renderer and parser a model uses. That is the first thing to check when a model behaves differently from the same weights elsewhere.

The ollama modelfile location question has a related answer: the built layers live in the model store, which the FAQ puts at ~/.ollama/models on macOS, /usr/share/ollama/.ollama/models for the Linux service, and C:\Users\%username%\.ollama\models on Windows, overridable with OLLAMA_MODELS.

How do you set a system prompt in a Modelfile?

Use SYSTEM with triple quotes for multi-line text; it fills {{ .System }} in the template.

FROM qwen2.5-coder:7b
SYSTEM """
You review pull requests. Flag bugs first, style last.
Never invent APIs that are not in the diff.
"""
MESSAGE user Review: func add(a, b int) int { return a - b }
MESSAGE assistant Bug: add returns a - b. Use a + b.

MESSAGE turns act as few-shot examples. Keep them short; they cost context on every request.

Why do TEMPLATE mistakes break chat and tool calling?

Because Ollama derives the model’s capabilities from its template. A wrong template doesn’t raise an error at create time; the model just behaves badly or loses features. The Template docs say an imported model without a template defaults to {{ .Prompt }}, which sends user text raw with no chat markers. That is fine for completion models and wrong for instruct models.

The v0.40.12 source shows how tool support is decided (images.go):

• A Go TEMPLATE gains the tools capability only if it references .Tools. It gains insert (fill-in-the-middle) only if it references .Suffix, which matters for local code completion.
• A GGUF Jinja chat template counts as tool-capable if it contains the string tools or tool_call.
• A built-in PARSER with tool support adds the capability regardless of the template.
• If none applies, a request with a tools array fails with “does not support tools”.

So the common silent breakages are:

The fix is to start from ollama show --modelfile of a library build of the same family, keep its TEMPLATE, PARSER and stop lines, and change only FROM and the parameters. Debugging tool calls end to end is covered in Ollama tool calling.

What do developers report in practice?

Developers report that template mismatches, not weights, cause most “this GGUF is worse in Ollama” complaints. The reports below are community accounts, not our tests.

• Simplified templates from hf.co pulls. A Hugging Face forum user in May 2026 traced odd behavior of a Gemma 4 26B-A4B GGUF to the template Ollama received through Hugging Face’s registry. It was a short .System/.Prompt template, while the GGUF carried the full chat template, and Ollama’s official build uses a built-in renderer (thread).
• Garbage until a template exists. On Hacker News, a commenter running GLM-4.7-Flash via ollama run hf.co/...:Q4_K_M in January 2026 said it was fast but output garbage “because there is no (good) template” (comment). An earlier commenter said almost every GGUF they had imported gave garbage until they solved the chat template (comment).
• RENDERER and PARSER as the fix. On the unsloth GLM-4.7-Flash GGUF repo, a user posted a Modelfile with RENDERER glm-4.7 and PARSER glm-4.7 that got tool calls working from coding-agent clients (discussion).
• Layer, don’t edit. A Hacker News commenter recommends putting your parameters in a new Modelfile whose FROM references the pulled model, noting that Modelfile parameters override sometimes-buggy values baked into the GGUF (comment).
• Not every tool failure is the template. In an r/LocalLLM thread, tool calls failed locally but worked through a cloud route. A commenter blamed the bundled qwen3.6 template and suggested checking the rendered prompt with OLLAMA_DEBUG=1. The poster later traced it to the ROCm backend on an AMD Strix Halo APU corrupting long-context attention, and switching to Vulkan fixed it (thread). Confirm the rendered prompt before rewriting a template.

FAQ