Ollama Modelfile-Parameter im Detail: Leitfaden für eigene Modelle

Aktualisiert am 2026-06-08: Gegen die offizielle Ollama-Modelfile-Doku geprüft — es gibt 7 Anweisungen (FROM / PARAMETER / TEMPLATE / SYSTEM / ADAPTER / LICENSE / MESSAGE; kein REQUIRES). Einstiegslink korrigiert und Weiterlesen-Links derselben Serie ergänzt.

Im letzten Artikel ging es darum, Modelle zum Laufen zu bringen – aber eine Sache blieb nervig: die Antworten schwanken stark.

Mal frage ich llama3.2 eine einfache Code-Frage und bekomme drei knappe Zeilen, mal einen ganzen Aufsatz. Bei temperature 0,8 wird es „kreativ“; bei 0,1 klingt es wie auswendig Gelerntes. Am ärgerlichsten: Bei jedem Gespräch den System-Prompt neu setzen – Copy-Paste bis zum Erbrechen.

Dann entdeckte ich das Ollama-Modelfile. Kurz gesagt: ein „Persönlichkeits-Lebenslauf“ für das Modell – einmal konfigurieren, dauerhaft wirksam. In diesem Artikel fasse ich meine Stolpersteine und Tuning-Erfahrungen zusammen: Empfehlungen zu zehn Kernparametern und vier Vorlagen, die Sie direkt nutzen können.

Wenn Ollama noch nicht installiert ist, lesen Sie zuerst den Einstiegsartikel der Serie. Dieser Text ist fortgeschritten und setzt voraus, dass ollama run bereits funktioniert.

1. Was ist ein Modelfile – und warum brauchen Sie es?

Ein Modelfile ist der „Konfigurationsplan“ Ihres Modells – ähnlich wie ein Dockerfile: Sie nennen das Basismodell, setzen Parameter, definieren den System-Prompt und vergeben einen Namen. Jeder Aufruf unter diesem Namen lädt die gesamte Konfiguration automatisch.

Kurz gesagt löst es drei typische Probleme:

Problem 1: Immer wieder dieselbe Einrichtung

Terminal öffnen, ollama run llama3.2, System-Prompt tippen. Am nächsten Tag von vorn. Am übernächsten Tag wieder. Das Modelfile hält diese Einstellungen fest – einmal konfiguriert, dauerhaft gültig.

Problem 2: Instabiler Ausgabestil

Dasselbe Modell liefert je nach Parametern völlig unterschiedliche Texte. Code-Hilfe braucht Stabilität, kreatives Schreiben Vielfalt. Sie können sich nicht merken: „Diese Aufgabe temperature 0,3, jene 0,8“ – das Modelfile speichert Ihre Presets.

Problem 3: Varianten verwalten

Sie wollen eine „Code-Review-llama3.2“, eine „Schreib-llama3.2“, eine „JSON-llama3.2“. Drei Modellkopien? Unnötig. Mit dem Modelfile legen Sie drei benannte Varianten an – unten liegt dieselbe Modell-Datei, nur die Konfiguration unterscheidet sich.

Der Ablauf in drei Schritten:

# 1. Modelfile anlegen
echo 'FROM llama3.2
SYSTEM "Sie sind ein Code-Review-Experte"' > Modelfile

# 2. Neues Modell erzeugen
ollama create my-coder -f Modelfile

# 3. Direkt ausführen
ollama run my-coder

So einfach. Als Nächstes: Was im Modelfile stehen kann.

2. Modelfile-Struktur und die 7 Anweisungen

Die Syntax ist schlank: Kommentare mit #, Anweisungen mit Großbuchstaben am Anfang. Beispiel:

# Dies ist ein Kommentar
FROM llama3.2
PARAMETER temperature 0.8
SYSTEM "Sie sind ein freundlicher Assistent"

Zwei Elemente: Kommentare und Anweisungen. Es gibt sieben Anweisungstypen – zuerst die Übersicht:

Anweisung	Funktion	Pflicht?	Wann nutzen
FROM	Basismodell	Ja	In jeder Datei
PARAMETER	Inferenzparameter	Optional	Temperatur, Kontext usw.
TEMPLATE	Prompt-Vorlage	Optional	Eigenes Dialogformat
SYSTEM	Systemnachricht	Optional	Rolle und Verhalten
ADAPTER	LoRA-Adapter	Optional	Beim Fine-Tuning
LICENSE	Lizenztext	Optional	Beim Veröffentlichen
MESSAGE	Vorgegebener Dialog	Optional	Few-Shot-Beispiele

Im Alltag reichen in etwa 90 % der Fälle FROM, PARAMETER und SYSTEM. Den Rest schauen Sie bei Bedarf an.

FROM – drei Varianten

FROM ist die einzige Pflichtanweisung:

Variante 1: Modellname (häufigste)

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

Modellname wie in Ollama; nach dem Doppelpunkt ein Tag, ohne Angabe latest.

Variante 2: lokale GGUF-Datei

FROM ./my-model.gguf

Für von außen geladene GGUF-Dateien.

Variante 3: Safetensors-Verzeichnis

FROM ./my-safetensors-dir

Seltener – oft Hugging-Face-Originalformat.

Struktur erledigt – jetzt die PARAMETER.

3. PARAMETER im Detail

Der praxisreichste Teil: Stolpersteine aus dem Tuning und eine Tabelle zum Abgreifen.

Parameter	Standard	Typ	Wirkung	Tuning-Tipp
temperature	0.8	float	Zufälligkeit – höher = „freier“	Code 0,3, kreativ 1,0
num_ctx	2048	int	Kontextfenster	lange Texte 4096–8192
top_k	40	int	nur Top-K-Tokens	meist Standard lassen
top_p	0.9	float	Nucleus-Sampling	mit temperature kombinieren
min_p	0.0	float	filtert unwahrscheinliche Tokens	Qualität: 0,05
seed	0	int	fester Zufall für Reproduzierbarkeit	Tests: 42
stop	keine	string	Stopp bei Sequenz	mehrere stop möglich
num_predict	-1	int	max. Ausgabelänge, -1 = unbegrenzt	z. B. 100–500
repeat_penalty	1.1	float	bestraft Wiederholungen	lange Texte: 1,5
repeat_last_n	64	int	Fenster für Wiederholungserkennung	mit repeat_penalty

Die wichtigsten im Detail.

temperature: Kreativität vs. Stabilität

Hoch (z. B. 1,0): das Modell wählt auch weniger wahrscheinliche, kreativere Tokens. Niedrig (z. B. 0,1): konservativ, nur die wahrscheinlichsten – stabilere Ausgabe.

Frage: Wie liest man in Python eine Datei?

• temperature 0,1: Lehrbuchantwort, nur Standardlösung
• 0,5: praktische Hinweise, z. B. Encoding
• 0,8: mehrere Methoden, Beispiele
• 1,0: stark variierend, manchmal themenfremd

Erfahrung:

• Code, technische Q&A: ca. 0,3
• Kreativ, Brainstorming: 0,8–1,0
• JSON, festes Format: 0,1–0,2

num_ctx: Kontextfenster

Legt fest, wie viel das Modell „im Kopf“ behält. Standard 2048 Tokens – grob 1500–2000 chinesische Zeichen bzw. entsprechend weniger bei langen deutschen Texten.

Langer Artikel zum Zusammenfassen? 2048 reicht oft nicht. Vergisst das Modell frühere Turns? Oft zu kleines num_ctx.

Wichtig: Größeres num_ctx braucht mehr RAM. Bei llama3.2 stieg der Verbrauch von 2048 auf 8192 mehr als verdoppelt. Mit 8 GB RAM: eher bis 4096.

Erfahrung:

• kurze Chats: 2048 Standard
• Code-Review, Technik: 4096 angenehm
• lange Dokumente: 8192 (wenn RAM reicht)

stop: Stopp-Sequenzen

Sagt dem Modell: „Bei dieser Sequenz aufhören.“

JSON-Ausgabe ohne Zusatztext:

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

Mehrere stop-Zeilen sind erlaubt – das wissen viele nicht.

repeat_penalty: gegen Leerläufe

Modelle wiederholen gern Phrasen. repeat_penalty bestraft das. Standard 1,1 reicht mir oft nicht; bei langen Texten setze ich 1,3–1,5 – weniger „wie bereits erwähnt“ und „zusammenfassend“.

Parameter nach Szenario

Szenario	temperature	num_ctx	Weitere Tipps
Code-Assistent	0.3	4096	stop ”```”, seed 42
Kreatives Schreiben	1.0	2048	top_p 0.95, repeat_penalty 1.5
Technische Q&A	0.5	4096	min_p 0.05
JSON-Ausgabe	0.1	2048	stop “\n\n”, stop ”```”

Damit haben Sie ein Gefühl für die Parameter. Als Nächstes: vier fertige Modelfiles.

4. Praxis: vier vollständige Modelfiles

Theorie reicht – hier Vorlagen, die ich getestet habe. Kopieren, anpassen, ollama create.

Beispiel 1: Rollenspiel – Zhu-Bajie-Assistent

Ein spaßiges Modell im Stil von Zhu Bajie aus „Die Reise in den Westen“:

# Zhu-Bajie-Assistent Modelfile
FROM llama3.2

SYSTEM """Du bist Zhu Bajie aus „Die Reise in den Westen“. Sprich humorvoll und bodenständig.
Bei Antworten:
- Beschwere dich gelegentlich, dass der Meister zu nörgelig ist
- Werde begeistert, wenn Essen erwähnt wird
- Sage von dir „Ich, der alte Zhu“
- Bei Schwierigkeiten: „Lasst uns auflösen und getrennte Wege gehen"""

PARAMETER temperature 0.8
PARAMETER num_ctx 2048

Warum so:

temperature 0,8 gibt der Figur Charakter ohne Starre. Im SYSTEM stehen konkrete Regeln – Essen, Selbstbezeichnung – das macht die Rolle lebendig.

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

Fragen Sie z. B.: „Wie lerne ich gut programmieren?“

Beispiel 2: Python-Code-Review

Meine Alltags-Konfiguration für Code-Review:

# Python Code-Review Modelfile
FROM llama3.2:3b

SYSTEM """Sie sind ein erfahrener Python-Entwickler. Beim Review achten Sie auf:
1. Typsicherheit – potenzielle Typfehler
2. Exception Handling – Randfälle abgedeckt?
3. Performance – unnötige Schleifen oder Redundanz
4. Sicherheit – sensible Daten exponiert?

Antwortformat:
Problem → Auswirkung → Empfehlung → Codebeispiel"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER seed 42

Warum so:

temperature 0,3 für stabile Reviews ohne „Kreativität“. num_ctx 8192 für lange Dateien. seed 42 für reproduzierbare Vergleiche.

Hunderte Zeilen Python rein – Ausgabe im Format Problem → Auswirkung → Empfehlung → Beispiel.

Beispiel 3: strukturierte JSON-Ausgabe

Für Downstream-Programme ist JSON praktisch:

# JSON-Ausgabe Modelfile
FROM llama3.2

SYSTEM """Ihre Ausgabe muss gültiges JSON sein.
Format:
{"result": "Analyseinhalt", "confidence": 0-100, "tags": ["Tag1", "Tag2"]}

Kein anderer Text, keine Codeblock-Markierungen."""

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

MESSAGE user Analysiere die Sicherheitsrisiken dieses Codes
MESSAGE assistant {"result": "SQL-Injection-Risiko, Nutzereingabe ungefiltert", "confidence": 85, "tags": ["Sicherheit", "SQL"]}

Warum so:

temperature 0,1 für stabiles JSON. stop filtert Leerzeilen und ```. MESSAGE als Few-Shot-Vorlage.

In Automatisierung: Logs rein, strukturierte Analyse raus.

Beispiel 4: langer Kontext – Dokumentenzusammenfassung

Für lange Artikel braucht es ein großes Fenster:

# Dokumentenzusammenfassung Modelfile
FROM llama3.2

SYSTEM """Sie sind Experte für Zusammenfassungen. Anforderungen:
- maximal 5 Kernpunkte
- jeder Punkt unter 50 Wörtern
- zuerst Kernaussage, dann Details
- Ausgabe auf Deutsch"""

PARAMETER temperature 0.5
PARAMETER num_ctx 8192
PARAMETER num_predict 300

Warum so:

temperature 0,5 – stabil, aber nicht zu starr (sonst Chronik statt Summary). num_ctx 8192 für lange Texte. num_predict 300 begrenzt die Länge.

3000-Wörter-Artikel rein, fünf kurze Punkte raus – deutlich effizienter lesbar.

Kurzfassung

Vier typische Szenarien abgedeckt. SYSTEM und Parameter anpassen, ollama create erneut ausführen – geringe Debug-Kosten.

5. TEMPLATE und MESSAGE – Fortgeschritten

In den Beispielen fehlte TEMPLATE – das ist Fortgeschrittenes, wenn Sie das Dialogformat fein steuern wollen.

TEMPLATE – Go-Template-Syntax

Ollama nutzt Go-Templates. Drei Variablen:

• {{ .System }} – Inhalt von SYSTEM
• {{ .Prompt }} – Nutzereingabe
• {{ .Response }} – Modellausgabe (Formatdefinition)

Einfaches Beispiel:

FROM llama3.2

TEMPLATE """{{ .System }}

Nutzerfrage: {{ .Prompt }}

Antwort: {{ .Response }}"""

SYSTEM "Sie sind Technik-Experte"

Struktur: SYSTEM, dann Frage, dann Antwortplatz.

Meist reicht Ollamas Standard-Template. Anpassen lohnt sich, wenn:

Szenario 1: Integration in andere Tools

Ein Chat-System verlangt ein spezielles Eingabeformat – TEMPLATE als Adapter.

Szenario 2: spezielles Dialogformat

Präfixe wie [AI] / [USER] pro Zeile – über TEMPLATE abbildbar.

MESSAGE: vorgegebener Dialog

MESSAGE zeigt dem Modell Beispiele – wie im JSON-Fall:

MESSAGE user Analysiere die Sicherheitsrisiken dieses Codes
MESSAGE assistant {"result": "SQL-Injection-Risiko", "confidence": 85}

Few-Shot: „Bei solchen Fragen antworten Sie so.“

Mehrere Turns möglich:

MESSAGE user Hallo
MESSAGE assistant Hallo, womit kann ich helfen?
MESSAGE user Wie ist das Wetter?
MESSAGE assistant Ich kenne kein Live-Wetter – nutzen Sie eine Wetter-App.

Beim Start „erinnert“ sich das Modell an diesen Stil.

Modelfile eines Modells anzeigen

ollama show --modelfile llama3.2

Lange Ausgabe mit allen Defaults – kopieren, anpassen, eigenes Custom-Modell bauen. Praktisch, wenn eine Community-Variante gut wirkt: exportieren und von der Konfiguration lernen.

6. FAQ und typische Fallen

Parameter-Tuning bedeutet Stolpersteine. Die häufigsten – und wie Sie sie vermeiden.

Fall 1: temperature zu niedrig – wie auswendig gelernt

„Niedriger = stabiler“ – ich dachte das auch und setzte den Code-Assistenten auf 0,05.

Ergebnis: Antworten wie aus dem Lehrbuch, ohne Praxishinweise. „Python-Datei lesen?“ – drei Standardmethoden, null Tipps.

Lesson: Nicht immer tiefer. Code-Review: 0,3 reicht. Unter 0,2 wird es starr. JSON braucht niedrige Werte; normaler Chat nicht.

Fall 2: num_ctx zu groß – RAM voll

Einmal auf 16384 gesetzt – lange Dokumente! Minuten später Swap, System eingefroren.

16 GB RAM, llama3.2:3b ~2 GB, num_ctx 2048 → 16384: Speicher sprang auf über 8 GB plus andere Apps.

Lesson:

• 8 GB: num_ctx max. 4096
• 16 GB: bis 8192
• 32 GB+: 16384 testbar

Fall 3: SYSTEM und MESSAGE verwechseln

• SYSTEM: dauerhafte Rolle, jedes Gespräch
• MESSAGE: Few-Shot-Beispiele im Dialogverlauf

Code-Review: Rolle in SYSTEM, Antwortstil in MESSAGE. Nur SYSTEM – das Modell „weiß“, wer es ist, aber nicht, wie es antworten soll. Ein paar MESSAGE-Beispiele verbessern die Qualität spürbar.

Fall 4: Konfiguration nach Erstellung ändern

Einfach Modelfile bearbeiten und erneut erstellen:

# Erstes Mal
ollama create my-coder -f Modelfile

# Geändert? Nochmal – überschreibt
ollama create my-coder -f Modelfile

Anderen Namen, wenn Sie die alte Version behalten wollen:

ollama create my-coder-v2 -f Modelfile

Fall 5: fremdes Modelfile nachbauen

Gutes Community-Modell gesehen?

ollama pull someone-elses-model
ollama show --modelfile someone-elses-model > learned-modelfile
cat learned-modelfile

Damit habe ich viel über Parameter-Tuning gelernt.

Weiterführend

• Ollama-Einstieg: lokale LLMs schnell starten
• Ollama-API in der Praxis: OpenAI-kompatible Aufrufe
• Ollama GGUF-Quantisierung: der vollständige Leitfaden

Zusammenfassung

Kernbotschaft: Konfiguration festhalten, kein manuelles Nachstellen bei jedem Lauf.

Drei Dinge zum Sofort-Ausprobieren:

1. Rollenspiel-Modell

Zhu-Bajie-Vorlage oder eine andere Figur (Doraemon, Iron Man …). Ein paar Runden chatten und den Effekt von temperature spüren.

2. Parameter vergleichen

Dieselbe Frage mit temperature 0,3 und 0,8 – Unterschiede beobachten. Ich mache das oft; es lohnt sich.

3. Ihr Alltagsszenario

Code-Review, Zusammenfassung, kreatives Schreiben – eine Vorlage anpassen, ein paar Iterationen, dann ein persönliches Custom-Modell.

Als Nächstes in der Serie: Ollama-API-Integration – lokales Modell in Ihre Anwendung, OpenAI-kompatible Schnittstelle. Mit fertigem Modelfile wird der API-Aufruf stabiler: Parameter nicht mehr im Code, sondern im Custom-Modell.

Fragen gerne in die Kommentare – vielleicht erspare ich Ihnen ein paar der Fehler, die ich gemacht habe.