Workflow:Ollama Ollama Custom Model Creation
| Knowledge Sources | |
|---|---|
| Domains | LLMs, Model_Management, Model_Customization |
| Last Updated | 2026-02-14 22:00 GMT |
Overview
End-to-end process for creating a custom Ollama model by authoring a Modelfile that defines a base model, system prompt, parameters, adapters, and template overrides.
Description
This workflow covers the creation of custom models using Ollama's Modelfile format, which is analogous to a Dockerfile for LLMs. A Modelfile specifies a base model (FROM), optional LoRA adapters (ADAPTER), a system prompt (SYSTEM), generation parameters (PARAMETER), a chat template (TEMPLATE), and licensing metadata (LICENSE). The creation pipeline parses the Modelfile, resolves the base model layers, applies any adapters, merges configuration, and produces a new model manifest in the local store.
Usage
Execute this workflow when you want to customize an existing model's behavior without retraining. Common use cases include setting a persistent system prompt for a domain-specific assistant, adjusting default generation parameters (temperature, context length), applying a LoRA adapter for fine-tuned behavior, or creating a model variant with a custom chat template.
Execution Steps
Step 1: Modelfile Authoring
Write a Modelfile that declaratively defines the custom model configuration. The Modelfile uses a directive-based syntax where each line specifies a property of the model. The parser supports multi-line values, heredoc syntax, and file path references. All directives are case-insensitive.
Key directives:
- FROM: Base model name or path to a GGUF file (required)
- SYSTEM: Default system prompt text
- PARAMETER: Key-value pairs for generation defaults (temperature, num_ctx, top_k, etc.)
- TEMPLATE: Go template string for chat prompt formatting
- ADAPTER: Path to a LoRA adapter file
- LICENSE: Model license text
Step 2: Modelfile Parsing
The parser reads the Modelfile and produces a structured representation of all directives. It handles quoting styles (single, double, heredoc), resolves relative file paths, and validates directive syntax. The parsed result includes the base model reference, all parameter overrides, system prompt, template, adapter paths, and license text.
Key considerations:
- File paths in FROM and ADAPTER are resolved relative to the Modelfile location
- The parser supports both local file paths and model name references for FROM
- Parameters are validated against the known set of generation options
- Multiple PARAMETER directives can set different options
Step 3: Base Model Resolution
Resolve the FROM reference to obtain the base model's layers. If FROM references an existing local model, its manifest layers are used as the starting point. If FROM references a remote model, it is pulled from the registry first. If FROM points to a GGUF file on disk, the file is imported as a new blob. The base model provides the weight layers, tokenizer, and default configuration.
Key considerations:
- The base model's configuration (capabilities, renderer, parser) is inherited by the new model
- Multiple levels of model inheritance are supported (model based on model based on model)
- GGUF file imports validate the file format before creating the blob
Step 4: Adapter Integration
If an ADAPTER directive is present, load and integrate the LoRA adapter weights. The adapter file (in GGUF format) is added as an additional layer in the model manifest. At inference time, the adapter weights are applied to the base model's attention and feedforward layers, modifying behavior without changing the original weights.
Key considerations:
- Adapters must be in GGUF format (SafeTensors adapters need conversion first)
- The adapter architecture must match the base model architecture
- Multiple adapters are not supported simultaneously
Step 5: Configuration Assembly and Manifest Creation
Assemble the final model configuration by merging the base model's defaults with the Modelfile overrides. Create new blob layers for the system prompt, template, parameters, and license text. Build a manifest that references all layers (base weights, adapter, tokenizer, system, template, parameters, license) and write it to the local content-addressable store under the specified model name.
Key considerations:
- Each configuration element (system, template, params) becomes a separate content-addressable blob
- The manifest links to blobs by their SHA-256 digest
- Creating a model with an existing name overwrites the previous manifest
- The model's capabilities are re-detected from the assembled configuration