Benchmark-Ergebnisse
Fähigkeits-Matrix (eingebauter Probe-Test)
Abschnitt betitelt „Fähigkeits-Matrix (eingebauter Probe-Test)“Der standardisierte Test (ollama-agent probe) misst pro Modell und pro Endpoint: Komplexitätsstufen 1–5, größte bewältigte Kontextgröße (Needle-Test bis 256k, Call-Timeout 10 min), Antwortzeiten und Stabilität. Alle 25 Modelle wurden auf beiden Lab-Servern getestet (probe show für die volle Tabelle); hier die brauchbaren Kandidaten auf dem schnellen Server (11434):
| Modell | Stufen | Kontext real | Tok/s | warm | Anmerkung |
|---|---|---|---|---|---|
| gemma4:26b-a4b-it-qat | 5/5 | 256k ✓ | 35.3 | 6.6s | volles deklariertes Fenster nutzbar (256k in 4m08s) — bester Allrounder |
| gemma4:e4b | 5/5 | 128k (Modellmax) | 94.7 | 0.8s | 128k in 25s! — idealer Router + Schnell-Worker |
| qwen3.5:9b | 5/5 | 256k ✓ | 98.7 | 4.0s | 256k in 1m22 — schnellstes Großkontext-Modell |
| gemma4:12b-it-qat | 5/5 | 256k ✓ | 71.2 | 3.7s | ausgewogen |
| qwen3-coder:latest | 5/5 | 256k ✓ | 30.9 | 1.0s | 256k knapp unterm Timeout (9m08) — Code-Referenz |
| gpt-oss:20b | 5/5 | 128k (Modellmax) | 52.0 | 2.2s | solide |
| krishairnd/Gemma-4-Uncensored | 5/5 | 128k (Modellmax) | 54.0 | 2.1s | uncensored-Option |
| nemotron-cascade-2 | 5/5 | 128k | 28.7 | 4.8s | 256k inhaltlich nicht bestanden (Needle nicht gefunden) |
| glm-4.7-flash:q4_K_M | 5/5 | 128k | 26.8 | 12.9s | q8_0-Variante: 64k-Timeout, lohnt nicht |
| llama3.1:8b | 2/5 | 128k | 77.7 | 0.5s | schnell, aber scheitert an Logik + Tool-Kette |
Durchgefallen (Auswahl): mistral/mistral-nemo (rechnen falsch, 0–1/5), deepseek-r1 (kein Tool-Support), qwen3.5:27b und gemma4:31b (2–4 Tok/s, Kontext bricht früh), gurubot/girl (0/5). Auf dem 11436 bestehen dieselben Modelle dieselben Stufen, aber alles 2–5× langsamer und Kontexte enden 1–2 Stufen früher (Timeouts).
Zwei Lehren aus diesem Lauf:
- Die Matrix ist eine Server-Eigenschaft, keine Modell-Eigenschaft. Derselbe
gpt-oss:20bschafft auf der NVIDIA-Instanz den 32k-Test in 27 Sekunden und läuft auf der CPU-Instanz in den 10-Minuten-Timeout. Deshalb misst der Probe pro Endpoint, und der Agent rechnet mit dem Minimum über alle Server, auf die der Pool routen kann. - Der Probe deckt Konfigurations-Irrtümer auf: Die Lab-Server waren gedanklich vertauscht — Port 11434 ist die NVIDIA-Instanz (RTX 3080 Ti), Port 11436 die bewusst CPU-only-Instanz mit 262k-Standard-Kontext. Die Messwerte (77 Tok/s = GPU-Klasse,
size_vramin/api/ps) haben das aufgedeckt, bevor die falsche Annahme in den Betrieb gewandert ist.
Die Detailwerte (alle Stufen-Zeiten) stehen in state_dir/model-matrix.json; der Agent nutzt die gemessenen Kontextgrößen automatisch für die History-Kompaktierung. Stufen-Ergebnisse (welches Modell welche Komplexität schafft) waren auf beiden Servern identisch — die Fähigkeit ist modellseitig, das Tempo serverseitig.
Gemessen mit cmd/modelbench gegen einen Ollama-0.30-Server (RTX-GPU mit 12 GB VRAM). Eigene Server testen mit:
go run ./cmd/modelbench -host http://<server>:11434 -models "mistral:latest,llama3.1:8b,..."Drei Disziplinen pro Modell:
- Rechnen: einfache Korrektheit + Antworttempo (Zeit enthält beim ersten Call das Modell-Laden)
- Tool-Call: ruft das Modell ein Tool korrekt auf (
structured= natives Format,salvaged= vom Parser gerettet,none= gar nicht) und gibt es das Ergebnis wieder? - Klassifikation: Eignung als
router-Modell — 4 Test-Inputs in Kategorien einordnen (JSON-Schema-erzwungen, Thinking deaktiviert)
Ergebnisse (Stand 2026-07, Ollama 0.30.10)
Abschnitt betitelt „Ergebnisse (Stand 2026-07, Ollama 0.30.10)“| Modell | Größe | Rechnen | Tool-Call | Klassifikation | Zeit/Klassif. |
|---|---|---|---|---|---|
| mistral:latest | 4.4 GB | ok, sehr schnell | structured ✓ | 4/4 | 1.9s |
| llama3.1:8b | 4.9 GB | ok | structured ✓ | 4/4 | 2.1s |
| qwen3-coder:latest | 18.6 GB | ok | structured ✓ (6.6s) | 4/4 | 1.2s |
| gemma4:12b-it-qat | 7.2 GB | ok | structured ✓ | 4/4 | 4.6s |
| qwen3.5:9b | 6.6 GB | ok, aber langsam (Thinking) | structured ✓ | 4/4 | 3.2s |
| gpt-oss:20b | 13.8 GB | ok | structured ✓ | 4/4 | 12.7s |
| mistral-nemo:latest | 7.1 GB | falsch (17+25=32!) | structured ✓ | 4/4 | 2.5s |
| deepseek-r1:8b | 5.2 GB | ok, langsam | kein Tool-Support | 4/4 | 44s |
Erkenntnisse
Abschnitt betitelt „Erkenntnisse“mistral:latestist der beste Router: schnellste korrekte Klassifikation, kleinstes Modell.llama3.1:8bist gleichwertiger Fallback.llama3.1:8bist das beste Arbeitspferd für Chat und Tool-Calling: zuverlässig, natives Tool-Format, kein Thinking-Overhead.qwen3-coderist erste Wahl für Code — und nebenbei ein exzellenter Klassifizierer. Aber: 18.6 GB passt nicht in 12 GB VRAM (teilweise CPU-Offload, spürbar langsamer) und es gibt Tool-Calls gelegentlich als XML-Text aus (fängt der Salvage-Parser ab).- Thinking-Modelle (qwen3.5, deepseek-r1) mit Bedacht einsetzen: Sie „denken” vor jeder Antwort (30–50s). Für Router-/Summarize-Calls schaltet die Plattform Thinking automatisch ab; im Chat bleibt die Latenz.
deepseek-r1kann außerdem keine Tools — als Agent-Modell ungeeignet. mistral-nemofällt durch: rechnet falsch (17+25=32). Nicht für faktische Aufgaben verwenden.- Modelle > 12 GB (gpt-oss:20b, qwen3-coder) laufen auf der GPU nur mit CPU-Offload — funktioniert, kostet aber deutlich Tempo.
Kontext-Tiefentest verändert das Bild
Abschnitt betitelt „Kontext-Tiefentest verändert das Bild“Der Needle-Test (oben) sagt nur, ob ein Modell einen Fakt im großen Kontext findet. Der Tiefentest (probe deep) misst, ob es den Kontext wirklich versteht — und das ordnet die Empfehlung neu:
| Modell | Kontext | Deep-Score | Retrieval | Multi-Hop | Aggregation |
|---|---|---|---|---|---|
| nemotron-cascade-2 | 128k | 100 % | 3/3 | 4/4 | 6/6 |
| glm-4.7-flash:q4 | 128k | 77 % | 3/3 | 4/4 | 3/6 |
| gpt-oss:20b | 128k | 62 % | 3/3 | 2/4 | 3/6 |
| qwen3.5:9b | 128k | 54 % | 3/3 | 4/4 | 0/6 |
| gemma4:e4b / gemma4:12b | 128k | 38 % | 3/3 | 2/4 | 0/6 |
| qwen3-coder | 256k | 38 % | 3/3 | 2/4 | 0/6 |
| mistral | 32k | 31 % | 2/3 | 2/4 | 0/6 |
| gemma4:26b-a4b | 256k | Timeout* | — | — | — |
*gemma4:26b: Tiefentest bei großem Kontext auf der 12-GB-Karte nicht durchführbar (>60 Min pro Lauf durch RAM-Offload). Fähigkeit 5/5, aber für große Kontexte auf dieser Hardware ungeeignet.
Zwei Kernbefunde:
- Retrieval ≠ Verständnis (der RULER-Effekt): Fast alle Modelle finden Fakten (3/3), aber bei der Aggregation über das ganze Dokument brechen die meisten auf 0/6 ein. Ein reiner Needle-Test hätte sie alle als „128k ✓” durchgewunken.
- Der bisherige Allrounder gemma4:26b ist für großen Kontext raus — nicht wegen Unfähigkeit, sondern weil der Tiefentest auf der 12-GB-Karte nicht in vertretbarer Zeit läuft. Für Groß-Kontext-Arbeit gewinnt nemotron-cascade-2 (100 %).
Empfohlene Task-Zuordnung
Abschnitt betitelt „Empfohlene Task-Zuordnung“Die vollständige Herleitung und die Schritt-für-Schritt-Anleitung stehen im Modell-Guide. Kurzfassung der Zuordnung für dieses Lab-Setup:
| Kategorie | Modell (Fallback) | Grund |
|---|---|---|
router | gemma4:e4b (mistral) | schnellste zuverlässige Klassifikation |
chat | qwen3.5:9b (gpt-oss:20b) | 5/5, 98 Tok/s, guter Allrounder |
code | qwen3-coder (gemma4:26b) | Code-Spezialist, 5/5 |
tool_calling | gpt-oss:20b (qwen3.5:9b) | starke Tool-Kette, Deep 62 % |
summarize | nemotron-cascade-2 (glm-4.7-flash) | höchster Deep-Score (100 %) für Dokument-Verständnis |
Hinweise:
- Pool-Effekt: Der Agent rechnet mit dem konservativen Kontext-Minimum über alle Endpoints. Solange die langsame CPU-Instanz (11436) im Pool ist, gilt für ein Modell min(nvidia, cpu). Für Groß-Kontext-Arbeit die CPU-Instanz aus der Config nehmen oder als Failover-Backup akzeptieren.
- Server-Topologie (docker-compose auf dem ai-server):
ollama-nvidiaPort 11434 (RTX 3080 Ti, KV-Cache q8_0),ollama-cpuPort 11436 (bewusst CPU-only, 262k-Kontext), AMD-Instanz auf 11435 vorbereitet aber deaktiviert.