Modell-Guide

Dieser Guide erklärt, wie man aus den Messdaten die richtigen Modelle für die eigenen Aufgaben auswählt und in der Config abbildet. Er nutzt die drei eingebauten Tests (probe, probe deep) als Entscheidungsgrundlage — die konkreten Zahlen stammen aus dem Lab-Setup (RTX 3080 Ti / 12 GB VRAM + 64 GB RAM), auf eigener Hardware bitte selbst messen.

1. Die drei Achsen jeder Aufgabe

Kein Modell ist überall das beste. Jede Aufgabe liegt irgendwo auf drei Achsen:

Achse	Frage	Gemessen von
Kontextgröße	Wie viel Text muss das Modell gleichzeitig im Kopf haben?	`probe` (Needle-Leiter) + `probe deep` (echte Nutzung)
Schwierigkeit	Nur abrufen, oder verknüpfen, schließen, aggregieren?	`probe` (Stufen 1–5) + `probe deep` (Tiers)
Tempo	Muss die Antwort in Sekunden da sein, oder darf sie dauern?	`probe` (Tok/s, Warm-Zeit)

Die entscheidende Erkenntnis aus den Tests: „unterstützt 256k Kontext” heißt nicht „nutzt 256k Kontext”. Fast alle Modelle bestehen den Needle-Test (einen Fakt finden), aber beim echten Verständnis (probe deep) brechen die meisten ein — besonders bei der Aggregation über das ganze Dokument. Deshalb braucht es beide Tests.

2. Was die Tests liefern

ollama-agent probe run --endpoint <name>        # Fähigkeit (Stufe 1–5), Needle-Kontext, Tok/s, Warm-Zeit, GPU/CPU
ollama-agent probe deep run --endpoint <name>   # echter Kontext-Verständnis-Score (0–100 %)
ollama-agent probe show                         # Fähigkeits-Matrix ansehen
ollama-agent probe deep                         # Verständnis-Scores ansehen (startet nichts)

Stufe 1–5 (probe): 1 einfache Antwort, 2 Anweisung befolgen, 3 logischer Schluss, 4 Tool-Aufruf, 5 Tool-Kette. Ein Modell unter 4/5 taugt nicht als Agent-Modell (kann keine Tools verketten).
Needle-Kontext (probe): größte Kontextgröße, bei der es einen einzelnen Fakt findet. Obergrenze, kein Verständnis.
Deep-Score (probe deep): gewichteter Prozentwert, wie gut das Modell den Kontext wirklich nutzt (Retrieval ×1, Multi-Hop ×2, Aggregation ×3). Das ist die Kennzahl für Aufgaben mit großem Kontext.
Tok/s + Warm-Zeit: Tempo. Warm-Zeit = typische Antwortzeit bei geladenem Modell auf kurze Frage.

3. Aufgaben-Profile (die „Stufen dazwischen”)

Ordne deine reale Nutzung einem dieser fünf Profile zu:

Profil	Kontext	Schwierigkeit	Tempo	Wonach auswählen
A — Router/Klassifikation	winzig	trivial (1 Kategorie wählen)	kritisch	kleinstes Modell mit schneller, stabiler JSON-Ausgabe
B — Schneller Chat	klein (<8k)	niedrig–mittel	wichtig	hohe Tok/s + Stufe 5/5 + kurze Warm-Zeit
C — Werkzeug-Aufgaben	mittel (8–32k)	mittel (Tools, Multi-Hop)	egal	Stufe 5/5 + solider Deep-Score
D — Code	mittel–groß	hoch (Präzision)	angenehm schnell	bestes Code-Modell mit 5/5
E — Dokumente verstehen	groß (64k+)	höchste (Aggregation)	egal	höchster Deep-Score, Tempo zweitrangig

4. Modell-Empfehlung pro Profil (Lab-Daten)

A — Router / Klassifikation → `gemma4:e4b` (Fallback `mistral`)

Klassifikation ist eine Mini-Aufgabe mit schema-erzwungener JSON-Antwort. Hier zählt Tempo und Zuverlässigkeit, nicht Kontext. gemma4:e4b: 5/5, 0,8 s warm — zuverlässiger als mistral (nur 1/5 bei echten Aufgaben, aber als reiner Klassifizierer mit 0,4 s brauchbar als Fallback).

B — Schneller Chat → `qwen3.5:9b` (Fallback `gpt-oss:20b`)

qwen3.5:9b: 5/5, 98 Tok/s, 3,6 s warm, Deep 54 % — der beste Kompromiss aus Tempo und Fähigkeit für kurze Dialoge. gemma4:e4b ist noch schneller (0,8 s), aber schwächer bei Verknüpfungen.

C — Werkzeug-Aufgaben → `gpt-oss:20b` (Fallback `qwen3.5:9b`)

gpt-oss:20b: 5/5, Deep 62 %, 2,2 s warm — starke Tool-Kette und ordentliche Kontextnutzung bei gutem Tempo.

D — Code → `qwen3-coder:latest` (Fallback `gemma4:26b-a4b`)

qwen3-coder: 5/5, 256k Needle, Logikstufe unter 1 s — das spezialisierte Code-Modell. Hinweis: gibt Tool-Calls manchmal als XML-Text aus, was der Salvage-Parser abfängt.

E — Dokumente verstehen/aggregieren → `nemotron-cascade-2` (Fallback `glm-4.7-flash:q4`)

nemotron-cascade-2: der klare Sieger für großen Kontext — 100 % Deep-Score, als einziges Modell auch die Aggregation vollständig (6/6). Langsamer (28 Tok/s, 4,8 s warm), aber bei diesem Profil ist Tempo egal. glm-4.7-flash:q4 (77 %) ist der solide Zweitplatzierte.

Nicht empfohlen

llama3.1:8b (2/5): scheitert an Logik und Tool-Kette — nur für triviale Ausgaben.
gemma4:26b-a4b für großen Kontext: Fähigkeit 5/5, aber der Tiefentest ist auf der 12-GB-Karte nicht durchführbar (>60 Min pro Lauf durch RAM-Offload). Für kurze Kontexte gut, für große ungeeignet auf dieser Hardware.
gemma4:e4b/gemma4:12b für großen Kontext: schnell und 5/5, aber Deep nur 38 % (Aggregation 0/6) — top für Profil A/B, nicht für E.

5. In der Config abbilden

Die Profile werden in models.tasks auf Task-Kategorien gemappt. Jede Kategorie hat eine Präferenzliste (erstes verfügbares Modell gewinnt) und eine description, die dem Router bei der Klassifikation hilft.

"models": {
  "default": "qwen3.5:9b",
  "default_category": "chat",
  "tasks": {
    "router":       { "models": ["gemma4:e4b", "mistral:latest"], "options": { "temperature": 0 } },
    "chat":         { "models": ["qwen3.5:9b", "gpt-oss:20b"],
                      "description": "kurze allgemeine Fragen, Gespräch, Wissen" },
    "code":         { "models": ["qwen3-coder:latest", "gemma4:26b-a4b-it-qat"],
                      "description": "Programmcode schreiben, korrigieren oder erklären" },
    "tool_calling": { "models": ["gpt-oss:20b", "qwen3.5:9b"], "options": { "temperature": 0 },
                      "description": "Aufgaben mit Werkzeugen oder mehreren Schritten" },
    "summarize":    { "models": ["nemotron-cascade-2:latest", "glm-4.7-flash:q4_K_M"],
                      "description": "einen langen Text zusammenfassen oder daraus Informationen ableiten" }
  }
}

Warum diese Zuordnung:

summarize bedeutet „langen Text lesen und verdichten” = Profil E → das Modell mit dem höchsten Deep-Score (nemotron), Tempo egal.
chat und tool_calling = Profil B/C → schnelle, fähige Modelle.
code = Profil D → das Code-Spezialmodell.
router = Profil A → schnellstes zuverlässiges Modell.

Die description-Felder deutlich formulieren — sie steuern die Treffsicherheit des Routers spürbar.

6. Vorgehen für den eigenen Server

Fähigkeit messen: ollama-agent probe run --endpoint <name> — sortiert die Spreu (unter 4/5, falsche Antworten) vom Weizen. Varianten-Modelle mit --exclude uncensored,heretic überspringen.
Verständnis messen (nur für die 5/5-Modelle, die du für großen Kontext erwägst): ollama-agent probe deep run --endpoint <name>. Bei schwacher Hardware --ctx 65536 setzen, sonst laufen 256k-Tests in die Zeit/Speichergrenze.
Profile zuordnen: Für jedes der fünf Profile aus Abschnitt 3 das beste Modell nach Abschnitt 4-Logik wählen — bei A/B/C/D nach Tempo+Fähigkeit, bei E nach Deep-Score.
Config schreiben (Abschnitt 5) und mit ollama-agent models prüfen, dass die gewählten Modelle auf einem gesunden Endpoint verfügbar sind.
Wenige Modelle konsequent nutzen: Jeder Modellwechsel kostet 30–60 s Ladezeit. Ein kompaktes Set (Router + 1 Allrounder + 1 Code + 1 Deep-Modell) schlägt zehn selten genutzte.

7. Hardware-Hinweis

Der Deep-Score ist eine Server-Eigenschaft, keine reine Modell-Eigenschaft: Auf einer Karte mit wenig VRAM lagert Ollama den KV-Cache bei großem Kontext in den RAM aus — das funktioniert, ist aber langsam und kann bei sehr großen Kontexten (256k) an Zeit/Speicher scheitern. Der Agent rechnet deshalb mit dem konservativen Minimum der gemessenen Kontextgrößen über alle Endpoints, auf die der Pool routen kann. Wer große Kontexte produktiv nutzen will, braucht entweder mehr VRAM oder akzeptiert die längeren Antwortzeiten (dafür sind die Timeouts großzügig auf 15 min gesetzt).