Ollama Modelfile Generator

A local assistant can use the same language model for code review, summarization, or writing while following different instructions and sampling settings. An Ollama Modelfile records those choices in a text file, together with the base model. Creating a named model from that file makes the configuration reusable across sessions.

The base model supplies the learned weights that determine its underlying capabilities. An existing Ollama model may also bring a conversation template, stop sequences, and parameter settings. Keeping those inherited settings is useful when the goal is a small change, such as asking for shorter explanations. Importing separate model weights requires more attention to the formatting and architecture that Ollama supports.

Two kinds of instructions are easy to confuse. A system prompt describes the intended behavior, such as explaining a code finding before suggesting a correction. A prompt template arranges system text, user messages, and assistant replies into the format expected by the model, including any special tokens. Changing the assistant's role usually belongs in the system prompt. Replacing its template can change how the whole conversation is understood.

Response length and context length solve different problems. The context window is the amount of text the model can work with at a time, measured in tokens, the text units it processes. Instructions, conversation history, supplied documents, and the developing answer all consume context. An output limit caps generated tokens. A larger context can accommodate more material, but it also requires more memory and must remain within what the model and runtime can handle.

Sampling controls which candidate token is chosen next. Lower temperature generally concentrates choices on more likely candidates, while higher temperature permits more variation. Top-k limits candidates by rank, top-p by cumulative probability, and min-p by probability relative to the leading candidate. These settings can make a summarizer more consistent or a writing assistant more varied, but none establishes whether an answer is factually correct.

System prompts and example conversations guide generation without training new weights. A trained adapter is a separate way to alter learned behavior, where the Ollama version supports loading it. This distinction matters when a model lacks the knowledge or capability a task requires. Rewording a prompt cannot establish that the missing capability has been learned.

The file becomes a usable model configuration through ollama create, which assigns it a model name. ollama run then runs that named model. Editing the text file afterward requires creating the model again to apply the changes. A useful configuration therefore needs both a readable recipe and a trial with representative prompts on the machine that will run it.

How to Use This Tool:

Start with the displayed example or import an existing supported Modelfile. The generated text updates as you edit.

1. Choose an existing file under Import Modelfile if you want to revise it. A successful import replaces the configuration fields and keeps the current custom model name; an import error preserves your existing settings.
   File import and generation run in your browser. Entered and imported settings, including prompts and local paths, also become part of the page URL and may appear in browser history or shared links. Keep credentials and confidential text out.
2. Enter the model tag or local weights location in Base model / FROM. For split GGUF weights, use a matching wildcard or one shard path per line.
3. Choose a distinct Custom model name, such as review-assistant:v1. This is the name used by the create and run commands.
4. Write the System prompt and set the context and sampling values you intend to override. Clear an optional field to omit its instruction and retain inherited behavior.
5. Open Advanced when you need an output token limit, seed, template, or another optional instruction. Those fields start blank; opening the section alone changes nothing.
6. Review the generated Modelfile, the Parameter ledger, and any warnings before saving.
   If the summary says Configuration needs attention, correct the named field. For example, a Min-p value of 2 must be changed to a value from 0 to 1, or cleared to inherit. The results return when all fields pass their checks.
7. Download the file as Modelfile and run the matching Ollama commands from its directory with Ollama installed and available. Run the create command before the run command, then test the resulting model with a representative prompt.

Interpreting Results:

Configuration ready to review means the supported fields pass local syntax and value checks. It does not confirm that the base model or weights exist, a custom template is correct, an adapter is compatible, or the requested context fits available memory. Creating and running the model can reveal loading and capacity errors. Template behavior and adapter compatibility still need separate verification.

The Parameter ledger lists explicit numeric settings and stop sequences written into the file. Its Reference default column is a comparison aid, not a reading of your installed Ollama or the base model. An omitted setting remains inherited, and its effective value can depend on the model, runtime, and settings supplied when it is run.

Sampling thresholds illustrates only the min-p cutoff for hypothetical leading-token probabilities from 10% to 100%. It does not sample a model, predict answer quality, or measure speed or memory. With Min-p blank, the chart uses a reference value of zero and labels the inherited value as unknown. Entering zero explicitly produces the same curve but also writes an instruction that disables this probability floor. The calculations retain floating-point precision; chart tooltips display up to six decimal places.

After creation, ollama show --modelfile review-assistant:v1 can help inspect the saved configuration; replace the example name with yours. While the model is loaded, ollama ps helps check allocated context and memory placement. Test the answer format and stopping behavior as well as whether the model starts.

Technical Details:

A Modelfile combines a base-model reference with instructions that supply text, set generation parameters, or declare model requirements. Each instruction has a name and arguments. Omitting an optional setting leaves the corresponding inherited or runtime behavior in place; omission is different from an explicit zero or an explicit neutral value.

Transformation Core

The instruction names below describe the generated file's meaning. The custom model name belongs to the create command and is not stored as an instruction in the file.

A minimal configuration can contain only the base and a system message. With no numeric overrides and the system text Be brief., the file is:

FROM "llama3.2:3b"
SYSTEM "Be brief."

No parameter instruction is added for a blank field. Giving this configuration the custom name brief-assistant produces the following commands to run after saving it as Modelfile:

ollama create brief-assistant -f ./Modelfile
ollama run brief-assistant

Context, output, and memory

num_ctx requests the context window, while num_predict limits newly generated tokens. A request with long instructions or message history leaves less context available for other text. Setting a large output cap does not provide additional context or prove that the model can finish a long answer.

Longer contexts increase memory demand for stored attention information, commonly called the key-value or KV cache, in addition to model weights. The model architecture, cache precision, and number of simultaneous requests affect that cost. A context value is therefore a requested token allowance, not a memory measurement. The initial 4,096-token setting is an editable example, not a capacity recommendation for every model or computer.

Parameter meanings and accepted values

The ranges below are inclusive editor limits. They describe accepted entries, not recommended settings or a promise that every Ollama version and model supports the entire range. Any numeric field may be left blank to inherit.

A fixed seed helps compare generations under the same conditions. Keep the model weights, full conversation, template, sampling settings, and runtime consistent when comparing runs. Neither a seed nor temperature zero guarantees identical answers across changed hardware or software.

Speculative drafting requires an available draft model or compatible embedded multi-token-prediction, or MTP, weights. A positive draft-token limit does not supply those weights or establish a speed improvement.

Accepted decimal values are normalized numerically before being written. Trailing decimal zeros can disappear, and scientific notation may become ordinary decimal notation. Invalid or out-of-range edits are rejected instead of being clipped. The displayed initial settings are explicit overrides, so clearing a field changes the file even if a reference default happens to look similar.

Formula Core: the min-p probability floor

Min-p scales its cutoff with the leading candidate's probability at a particular sampling step. The cutoff is the selected min-p fraction multiplied by that probability.

Here, m is Min-p from 0 to 1, p_max is the most likely token's probability, and p_cut is the minimum candidate probability. Both probabilities must use the same scale. Multiplying a percentage by m gives a percentage cutoff.

For a hypothetical leading-token probability of 60% and min-p of 0.05, the cutoff is exactly 3%:

In this illustration, a candidate meets the min-p floor when its probability is at or above the cutoff:

Passing this illustrated floor does not guarantee selection. Other filters can remove a candidate, and finite precision or the sampling backend can affect behavior at an exact tie. At min-p zero, this floor excludes no positive-probability candidate. At min-p one, only candidates tied for the highest probability meet the floor.

Applying the same rule with min-p 0.05 gives a 0.5% cutoff when the leading token has 10% probability and a 5% cutoff when it has 100% probability. The selected fraction stays fixed while the absolute cutoff changes with the probability distribution.

Literal text, stop sequences, and messages

Generated text arguments use quotes, with triple quotes for content containing quotation marks or line breaks. Ordinary backslashes remain literal. Each nonempty line in Stop sequences becomes one separate PARAMETER stop instruction, preserving spaces and backslashes. A typed \n in that field remains a backslash and the letter n; it is not a newline escape.

The Example messages / MESSAGE field uses one role and one nonempty JSON string per line. The accepted roles are system, user, and assistant. For example:

user "First line\nSecond line"

Here, the JSON escape becomes a real line break before the message is written as a quoted Modelfile instruction. This differs from the literal backslash behavior of stop sequences.

Stop sequences are literal stopping text rather than regular expressions. A sequence that also occurs in an ordinary answer can end generation sooner than intended. Preserve any model-specific conversation boundaries needed by its template when changing the stopping rules.

Import and Compatibility Limits:

Import supports a defined subset of Modelfile syntax. It reconstructs editable settings rather than preserving the original file byte for byte. Keep the original if its comments or exact formatting matter.

• Import accepts one text file up to 100 KiB. Individual text fields are limited to 16,000 characters. Literal NUL characters and embedded triple-quote delimiters are not supported.
• Up to 64 FROM entries are accepted. Multiple entries must each end in .gguf. There may be up to 64 nonempty, single-line stop sequences and 100 example messages.
• Full-line comments are removed and instruction order is normalized. Repeated license blocks are combined. Unknown instructions, unsupported parameters, duplicate numeric parameters, and duplicate single-value instructions are rejected. Quoted values followed by trailing comments are not supported.
• The custom model name allows up to 128 characters using lowercase letters a to z, digits, periods, underscores, and hyphens, with one optional colon-separated tag. Both name and tag must begin with a letter or digit. Names containing slashes are outside this editor's supported format.
• Version declarations accept forms such as 0.14.0 and 0.14.0-rc.1. Template semantics, model support, and required feature versions still need verification in Ollama.

The Adapter / ADAPTER field accepts one path. Ollama has marked LoRA adapter support as deprecated, so confirm support in your installed version before relying on that instruction. The generator cannot establish that a file can be loaded or that its trained base matches your chosen model.

Worked Examples:

References:

• Modelfile Reference, Ollama.
• Context length, Ollama.
• FAQ: context memory and parallel requests, Ollama.
• Modelfile parsing rules, Ollama.
• Generation limits and adapter support, Ollama.
• Token sampling rules, ggml-org.
• How to create a custom Ollama model, Simplified Guide.