Fachartikel · KI & Automatisierung
Lokale KI-Modelle im Praxistest:
32 Modelle auf Apple Silicon
Welche lokalen Sprachmodelle taugen wirklich? Ein fortlaufender Benchmark — Agent-Tasks, Vision, Dokumentenanalyse.
Aktualisiert · 2026-05-18
Stack-Switch April → Mai 2026: omlx (statt llama.cpp) als MLX-nativer Inference-Server, NVFP4 (statt Q4_K_M) als Quantisierung, TurboQuant 3-bit-KV (statt q8_0) für den KV-Cache. Apples-to-Apples-Bench (15.05., gleiches Modell Qwen3.6-35B-A3B): 27/27 Tests identisches Pass/Quality-Pattern vs llama.cpp-Q5_K_M-Baseline, dabei ~70 TPS Decode statt ~30–40. Coding-Default im Lab ist seither Qwen3.6-A3B-NVFP4, Multimodal-Default Gemma-4-26B-A4B-NVFP4. Die April-Tabelle weiter unten bleibt als Modell-Querschnitt stehen — die Mai-Werte stehen separat im neuen Abschnitt "Mai-Stack: NVFP4 + omlx".
Modelle getestet
Von 1,3 GB bis 25 GB — Text, Vision und Agent auf zwei Macs
Test-Harnesses
CC-Agent · smolagents · VLM Oneshot — 12 Tests insgesamt
Benchmark-Runs
Fortlaufend seit Februar 2026 — V4, Stand April 2026
Cloud-KI ist gut — aber jede Anfrage verlässt das Unternehmensnetzwerk, kostet pro Token und schafft Abhängigkeiten. Lokale Modelle versprechen dasselbe ohne diese Nachteile. Die Frage ist: Halten sie dieses Versprechen wirklich?
Seit Februar 2026 teste ich systematisch lokale Sprachmodelle auf Apple Silicon — mit echten Agent-Tasks, Dokumenten-Vision und Syntheseaufgaben. Kein Synthese-Benchmark, sondern reale Workflows: Bugfixes, Refactoring, Rechnungsextraktion, Dokumentklassifikation.
V4 (April 2026) ist der bisher umfangreichste Durchgang: 32 Modelle, 3 unterschiedliche Harnesses, 140+ Runs auf M4 Pro und M1 Mac Mini.
Was getestet wird
CC-Agent (7 Tests)
Claude Code CLI als Agent-Backend: Bugfix (b1), Debug-Traceback (d1), Landing Page (lp1), Refactoring (r1), Suche (s1), Rechnungsextraktion (e1), Validierung (e2).
smolagents (2 Tests)
HuggingFace ToolCallingAgent: Dokumenten-Klassifikation (sa1), Multi-Doc-Synthese (sa2 — Fixture-Problem, offen).
VLM Oneshot (3 Tests)
Single-Shot Image-to-Text: Dokument beschreiben (vl1), Text extrahieren (vl2), Belegpositionen erfassen (vl3).
Hardware: M4 Pro 48 GB (primär) · M1 Mac Mini 8 GB (Edge-Validierung)
Empfehlung nach Use-Case
Was soll ich laufen lassen?
Drei klare Empfehlungen — abhängig von Aufgabe und verfügbarem RAM.
Agent-Tasks
Best ValueQwen3.5-4B think
2,5 GB · ~150 t/s · 6/7
Bugfixes, Refactoring, Code-Generierung, Dokumentenextraktion — 86% Cloud-Qualität ohne API-Kosten.
Jeder Mac mit 8 GB RAM
Vision & OCR (All-Rounder)
Effizienz-ChampionQwen3-VL-4B Q4
5,5 GB · ~42 t/s · 9/12
Beste Effizienz unter den Vision-Modellen. Besteht Agent-, smolagents- und VLM-Tests. Q4 reicht — kein F16 nötig.
M4 Pro empfohlen
Edge (8 GB Mac)
Minimal FootprintQwen3.5-2B think
1,3 GB · ~200 t/s · 4/7
Kleinste sinnvolle Option für einfache Agent-Tasks. Passt komplett in RAM eines M1 Mac Mini — inklusive OS.
M1 Mac Mini 8 GB
Erkenntnisse — V4, April 2026
Was der Benchmark wirklich zeigt
Sechs überraschende Befunde — mit konkreten Zahlen aus dem Benchmark.
Hardware gleich, Qualität gleich
6/7 auf M1 wie auf M4
Gleiche Modelle liefern auf M1 Mac Mini (8 GB) und M4 Pro (48 GB) identische Ergebnisse — nur 3–4× langsamer. Compute-Budget hat fast keinen Einfluss auf Qualität. Entscheidend ist die Modellarchitektur.
4B ist Minimum für Agent-Tasks
2B halluziniert Tool-Calls
Claude Code injiziert ~30 Tool-Definitionen in jede Anfrage. 2B-Modelle (Qwen3.5-2B, Qwen3-VL-2B) halluzinieren dann zufällige Tool-Names wie TaskStop oder TodoWrite statt zu arbeiten. 4B ist die untere Grenze.
Thinking hilft Agents, schadet Textaufgaben
think 6/7 vs. nothink 5/7
Qwen3.5-4B: think 6/7, nothink 5/7. Qwen3.5-35B: think 6/7, nothink 5/7. Agent-Tasks erfordern mehrstufige Planung — Thinking gibt dem Modell Raum zur Tool-Auswahl. Bei smolagents sa1 (Klassifikation) macht es keinen Unterschied.
VLM: Zwei Champions für verschiedene Aufgaben
F16 führt (11/12), Q4 effizienter (9/12)
Qwen3-VL-4B F16 ist das einzige Modell das alle drei Harnesses (CC-Agent + smolagents + VLM Oneshot) besteht. Qwen3-VL-4B Q4 ist effizienter (1,64 PASS/GB) und für die meisten Aufgaben ausreichend. F16 ist nicht universell notwendig — es hängt von der Modellarchitektur ab.
Deutsche OCR: Generalisten schlagen Spezialisten
93,9% vs. 77,6% (PaddleOCR)
Das 2 GB Qwen3-VL-2B schlägt alle OCR-Spezialisten auf deutschen Dokumenten. Chinesisch-trainierte Modelle (PaddleOCR-VL, Qianfan-OCR) scheitern an Umlauten und deutschen Layouts — auch nach 5 Re-Runs mit Konfigurations-Tuning.
smolagents funktioniert out-of-the-box
27/32 Modelle bestehen sa1
HuggingFace ToolCallingAgent läuft direkt gegen llama-server via OpenAI-kompatiblem Endpoint — ohne Prompt-Tuning. 14/15 frisch getestete Modelle bestehen sa1 beim ersten Anlauf. sa2 (Multi-Doc-Synthese) scheitert bei allen Modellen — das ist ein Fixture-Designproblem, kein Modellproblem.
Model Specs — V4 Matrix
32 Modelle im Überblick
Alle Modelle via llama-server auf M4 Pro 48 GB. Score = PASS / eligible Tests (sa2 ausgeklammert, da Fixture-Problem). Vollständige Rohdaten auf GitHub.
Hinweis · Score-Spalte lesen
Die Score-Spalte mischt drei verschiedene Bench-Suiten — die Zahlen sind nicht direkt zwischen Modellen unterschiedlicher Suiten vergleichbar. Welche Suite ein Modell durchlaufen hat, steht jetzt in der neuen Spalte Bench-Suite.
- Text — Text-Bench mit 7 Tests (CC-Agent b1/d1/lp1/r1/s1/e1/e2). Maximalscore 7/7.
- VLM — Vision-Bench mit 12 Tests (CC-Agent + smolagents + VLM Oneshot). Maximalscore 12/12.
- VLM + OCR — VLM-Bench mit zusätzlichem OCR-Sub-Bench (deutsche Dokumente). Score-Format X/12 (Y% OCR).
- VLM-DQ — VLM-Bench mit einem disqualifizierten Test (sa2, aus dem Scoring ausgeklammert). Maximalscore 11/11.
Beispiel: Ein 6/7-Text-Score ist nicht "besser" als 11/12 VLM — die Tests messen unterschiedliche Fähigkeiten. Innerhalb derselben Suite sind die Werte vergleichbar.
Top 10 — nach Score und Relevanz
M4 Pro 48 GB| # | Modell | Params | RAM | t/s | Think | Vision | Bench-Suite | Score |
|---|---|---|---|---|---|---|---|---|
| 1 | Qwen3-VL-4B F16 Champion | 4B | 9 GB | ~28 | — | ja | VLM | 11/12 |
| 2 | Qwen3-VL-4B Q4 | 4B | 5,5 GB | ~42 | — | ja | VLM | 9/12 |
| 3 | Qwen3.5-4B think | 4B | 2,5 GB | ~150 | ja | — | Text | 6/7 |
| 4 | Qwen3.5-9B think | 9B | 6 GB | ~60 | ja | — | Text | 6/7 |
| 5 | Qwen3.5-35B-A3B think | 35B | 20 GB | ~45 | ja | — | Text | 6/7 |
| 6 | Carnice-9B | 9B | 6 GB | ~50 | nein | — | Text | 6/7 |
| 7 | Nemotron-3-Nano-30B | 30B | 18 GB | ~30 | — | — | Text | 6/7 |
| 8 | Qwen3-Coder-30B-A3B | 30B | 20 GB | ~73 | — | — | Text | 6/7 |
| 9 | Qwen3.5-2B think | 2B | 1,3 GB | ~200 | ja | — | Text | 3/7 |
| 10 | gemma-4-e4b-q4-think | 4,5B | 5,5 GB | ~30 | ja | ja | VLM-DQ | 7/11 |
Alle weiteren Modelle anzeigen (Platz 11–32)
| # | Modell | Params | RAM | t/s | Think | Vision | Bench-Suite | Score |
|---|---|---|---|---|---|---|---|---|
| 11 | Qwen3-VL-2B Q4 | 2B | 3,5 GB | ~120 | — | ja | VLM + OCR | 2/12 (93,9% OCR) |
| 12 | GLM-OCR | ~4B | 9 GB | ~60 | — | ja | VLM + OCR | 1/12 (91,8% OCR) |
| 13 | Qwen3.5-9B nothink | 9B | 6 GB | ~60 | nein | — | Text | 6/7 |
| 14 | Qwen3.5-4B nothink | 4B | 2,5 GB | ~150 | nein | — | Text | 5/7 |
| 15 | GPT-OSS-20B | 20B | 12 GB | ~25 | — | — | Text | 4/7 |
| 16 | GLM-4.7-Flash | 30B | 17 GB | ~20 | — | — | Text | 4/7 |
| 17 | Qwen3.5-27B nothink | 27B | 19 GB | ~25 | nein | — | Text | 5/7 |
| 18 | Qwen3.5-27B think | 27B | 19 GB | ~25 | — | — | Text | 4/7 |
| 19 | Qwen3.5-35B-A3B nothink | 35B | 20 GB | ~45 | nein | — | Text | 5/7 |
| 20 | Qwen3-8B | 8B | 7 GB | ~40 | nein | — | Text | 3/7 |
| 21 | Qwen3.5-2B nothink | 2B | 1,3 GB | ~200 | nein | — | Text | 4/7 |
| 22 | phi-4-mini | 3,8B | 3 GB | ~80 | — | — | Text | 1/7 |
| 23 | Nemotron-Cascade-2-30B | 30B | 25 GB | ~20 | — | — | Text | 4/7 |
| 24 | InternVL3-2B | 2B | 3 GB | ~50 | — | ja | VLM | 2/12 |
| 25 | SmolVLM2-2.2B | 2,2B | 3 GB | ~55 | — | ja | VLM | 2/12 |
| 26 | gemma-4-e4b-q4-nothink | 4,5B | 5,5 GB | ~30 | nein | ja | VLM | 6/12 |
| 27 | gemma-4-e2b-think | 2,3B | 4,6 GB | ~67 | ja | ja | VLM | 5/12 |
| 28 | gemma-4-e2b-nothink | 2,3B | 4,6 GB | ~67 | nein | ja | VLM | 3/12 |
| 29 | Qianfan-OCR | ~4B | 5 GB | ~50 | — | ja | VLM + OCR | 2/12 (30,6% OCR) |
| 30 | DeepSeek-R1-Qwen3-8B | 8B | 5 GB | ~40 | — | — | Text | 0/7 |
| 31 | granite-3.3-8b | 8B | 5 GB | ~45 | — | — | Text | 0/7 |
| 32 | Bonsai-8B | 8B | 2 GB | — | — | — | Text | 0/7 |
Quant-Details, Context-Window und vollständige Per-Test-Matrix im GitHub-Repository. Score = PASS / eligible (DQ und sa2 ausgeklammert).
Update · Mai 2026
Mai-Stack: NVFP4 + omlx + TurboQuant
Zwischen April und Mai 2026 hat sich der Stack einmal komplett gedreht — gleicher Mac, gleiches Modell, anderer Server, andere Quantisierung. Hier die Apples-to-Apples-Zahlen.
Coding-Default (MoE-Champion)
Qwen3.6-A3B-NVFP4
19,95 GB · ~70 TPS · 23/27 (NoThink) · 24/27 (Think)
35B-MoE mit 3B aktiven Parametern, NVFP4-Quantisierung + TurboQuant 3-bit-KV. Quality-neutral zu llama.cpp Q5_K_M, aber rund doppelt so schnell im Decode. Default-Mode: NoThink — Think liefert +1 PASS und +2 Quality, braucht aber 4,5× länger Wallclock (22 min vs 4 min im 27-Test-Bench).
Multimodal-Default
Gemma-4-26B-A4B-NVFP4
15,26 GB · Vision inkl. · OpenCode-Frontend
Wenn Vision oder Multi-Turn-Edit-Tool-Loops gebraucht werden. Sampling defensiv (rep_pen 1,15) wegen Multi-Turn-Decoherence in langen Edit-Sessions. Bleibt das Modell für den OpenCode-Workflow auf dem Mac.
Decode-TPS · NVFP4 vs UD-4bit auf MLX
Qwen3.6-35B-A3B · omlx · greedy| Profil | UD-4bit | NVFP4 | Delta |
|---|---|---|---|
| short | 29,87 | 44,60 | +49 % |
| medium | 59,42 | 71,41 | +20 % |
| long_code | 51,11 | 58,05 | +14 % |
| long-prefix (decode) | ~60 | ~72 | +20 % |
Gleiches Modell, gleicher Mac (M4 Pro 48 GB), gleicher omlx-Server, gleiches Greedy-Sampling (temp=0). TTFT, Cache-Effekt und Output-Qualität sind zwischen UD-4bit und NVFP4 nicht messbar unterschiedlich. NVFP4 belegt zusätzlich ~5 % weniger Disk (19,95 GB vs 21 GB). TurboQuant 3-bit-KV trägt bis 104k Tokens funktional, RSS bleibt bei 31,2 GB (~106 KB pro Token).
Methodik · Mai-Bench
Die Mai-Werte sind gegen die April-Baseline gegengeprüft: gleicher 27-Test-Korpus B1–J3 (smolagents-A1–A5 sind obsolet, OpenCode hat das Agent-System ersetzt), gleiche Fixtures, gleiche Pass-/Quality-Bewertung. Ergebnis: 27/27 Tests identisches Pass/Quality-Pattern zwischen omlx-NVFP4-3bit-KV und llama.cpp-Q5_K_M-q8_0. Die 4-bit-Stufe + 3-bit-KV sind hier quality-neutral, nicht "ungefähr gleich".
Bench-Adapter unter lib/local-llm/benchmark/run_benchmark.py — external omlx-Server via OMLX_API_KEY, chat_template_kwargs-Forwarding und --reset-cache-before. Result-Files: models/qwen3.6-35b-a3b/results/2026-05-15-nvfp4-nothink.json und models/qwen3.6-35b-a3b/results/2026-05-15-nvfp4-think.json.
Vollständiger Benchmark auf GitHub — Open Source
Alle Fixture-Daten, Harness-Konfigurationen und Rohergebnisse sind öffentlich. 32 Modelle, 12 Tests, vollständige Per-Test-Matrix — reproduzierbar auf jeder Apple-Silicon-Hardware.
github.com/rewulff/llm-benchmarkFazit
Ein 2,5-GB-Modell auf einem Mac mini liefert 86 % Cloud-Qualität bei Null Grenzkosten. Das ist kein Kompromiss — das ist die neue Baseline für lokale KI-Agenten.
Der Benchmark läuft weiter. Neue Modelle, neue Harnesses, neue Erkenntnisse — alle Ergebnisse fließen in das GitHub-Repository ein. Stand dieses Artikels: V4, April 2026 — ergänzt um den Mai-Stack-Switch (omlx · NVFP4 · TurboQuant) am 18.05.2026.
Interesse an lokaler KI für Ihr Unternehmen?
KI, die in Ihrer Infrastruktur bleibt
Ich analysiere Ihren Automatisierungsbedarf und zeige, welche lokalen Modelle für Ihren Use-Case geeignet sind — DSGVO-konform, ohne Cloud-Abhängigkeit, ohne Vendor-Lock-in.