Local-LLM-Roundup 18. Mai 2026: Ollama 0.23.4, llama.cpp b9202, drei CVEs und Qwen3.6 / Kimi K2

🚀 Releases

Ollama – mehrere Releases in einer Woche

Ollama hat in der vergangenen Woche vier stabile Versionen und zwei Pre-Releases veröffentlicht:

• v0.23.4 (13. Mai) – Aktuell stabiler Stand. ollama launch opencode unterstützt jetzt Vision-Modelle mit Bildeingaben; Formatierungsfehler bei Claude-Tool-Ergebnissen mit lokalen Bildpfaden behoben.
• v0.23.3 (12. Mai) – Enthält den Fix für die Windows-Updater-CVEs (PR #16100, siehe Sicherheit-Abschnitt); MLX-Verbesserungen (Push-Verhalten, Thread-Affinität, macOS-26-Target-Leak).
• v0.23.2 (7. Mai) – /api/show-Antworten werden jetzt gecacht, was die Medianlatenz um ~6,7× verbessert – spürbar für Integrationen wie VS Code.
• v0.23.1 (5. Mai) – Gemma 4 MTP (Multi-Token Prediction) Speculative Decoding für den MLX-Runner auf macOS; verspricht > 2× Speedup beim Gemma 4 31B-Coding-Modell (ollama run gemma4:31b-coding-mtp-bf16).
• v0.23.0 (3. Mai) – Claude Desktop via ollama launch claude-desktop integriert (Claude Cowork & Claude Code im Desktop-App-Kontext).

Zwei Pre-Releases verdienen besondere Aufmerksamkeit:

• v0.24.0-rc0 (14. Mai) – Codex-App-Integration (ollama launch opencode) und MLX-Memory-Trace-Logging.
• v0.30.0-rc15 (13. Mai, experimentell) – Tiefgreifende Architekturänderung: Ollama wechselt von einem GGML-eigenen Stack auf direkte llama.cpp-Unterstützung; GGUF-Kompatibilität wird native. MLX bleibt für Apple-Silicon-Beschleunigung zuständig. Noch nicht produktionsreif – bekannte Einschränkungen bei laguna-xs.2 und llama3.2-vision.

Quellen: github.com/ollama/ollama/releases

llama.cpp – Builds b9019–b9202 (4.–17. Mai)

llama.cpp veröffentlicht mehrmals täglich Builds. Bemerkenswerte Änderungen der letzten zwei Wochen:

• b9019 – Großes Refactoring: load_hparams und load_tensors in modulspezifische Klassen ausgelagert (sauberere Modell-Architektur).
• b9023 – Neuer Server-Endpoint /models?reload=1 für Hot-Reload ohne Neustart.
• b9026 – Schnelle Walsh-Hadamard-Transformation für KV-Rotation implementiert.
• b9028 – Option zum Einsparen von Gerätepuffer-Speicher.
• b9030 – cpp-httplib auf 0.43.3 aktualisiert.
• b9031 – Backends werden nur noch bei Bedarf geladen (weniger Overhead).
• b9200 (17. Mai) – Fix für --embd-normalize im Server (war zuvor nicht registriert, sodass der /embedding-Handler einen Hard-coded-Default verwendete).
• Merged: MTP Speculative Decoding für Qwen3.6 (16. Mai) – Ermöglicht 1,4–2× schnellere Generierung; Parameter umbenannt von --spec-type mtp zu --spec-type draft-mtp (13. Mai).
• In Arbeit: DeepSeek V4-Support – GGUF-Konvertierung, nativer FP4/FP8-Quant, CUDA-Optimierungen befinden sich in aktiver PR-Phase.

Aktueller Build: b9202 (17. Mai 2026) · Quelle: github.com/ggml-org/llama.cpp/releases

🔴 Sicherheit – Drei Ollama-CVEs (alle Plattformen / Windows)

CVE-2026-7482 „Bleeding Llama“ – BEHOBEN, Update dringend empfohlen

Betrifft: Alle Plattformen, Ollama < 0.17.1 · Schwere: Kritisch (CVSS 9.1)

Ein Heap-Out-of-Bounds-Read im GGUF-Loader erlaubt es einem nicht authentifizierten Angreifer, der den Ollama-HTTP-API-Port (11434) erreicht, den gesamten Prozessspeicher auszulesen – inklusive Umgebungsvariablen, API-Keys, System-Prompts und laufender Konversationen. Der F16→F32-Konvertierungspfad ist verlustlos und macht die Exfiltration besonders zuverlässig.

Status: Behoben in Ollama v0.17.1 (24. Februar 2026). Die Release Notes enthielten keinen Sicherheitshinweis – wer das Update damals übersprungen hat, ist weiterhin verwundbar. CVE wurde erst am 28. April 2026 vergeben; Disclosure durch Cyera Research am 2. Mai 2026.

Maßnahme: Sofort auf v0.17.1 oder neuer upgraden. Ollama niemals ohne authentifizierenden Proxy an 0.0.0.0 binden. Secrets in möglicherweise betroffenen Instanzen rotieren.

CVE-2026-42248 & CVE-2026-42249 – Windows-Updater-Chain – JETZT BEHOBEN

Betrifft: Windows only, Ollama 0.12.10 bis 0.23.2 · Schwere: Hoch (CVSS 7.7 jeweils)

Zwei getrennte Fehler im Windows-Autoupdater, die kombiniert zu persistenter Code-Ausführung führen: CVE-2026-42248 (fehlende Signaturprüfung beim Update-Download) und CVE-2026-42249 (Path-Traversal im Staging-Verzeichnis). Ein Angreifer auf dem Netzwerkpfad (WLAN, DNS-Poisoning, böswilliger Proxy) kann beliebige Executables in den Windows-Startup-Ordner schleusen, die bei jedem Login ausgeführt werden.

Status: Fix (PR #16100 „app: harden update flows“) wurde am 11. Mai auf main gemergt und ist in v0.23.3 (12. Mai 2026) enthalten. Windows-Nutzer auf 0.12.10–0.23.2 sollten sofort auf ≥ v0.23.3 upgraden. Als kurzfristige Mitigation bis zum Update: Auto-Downloads in den Ollama-App-Einstellungen deaktivieren oder den Outbound-Zugriff von ollama app.exe per Firewall sperren.

Quellen: Mondoo-Analyse, CERT.PL Advisory

🆕 Open-Weight-Modelle

Qwen3.6-27B & 35B-A3B (Alibaba, Apache 2.0)

Alibabas neues Qwen3.6-Family (veröffentlicht 22. April 2026) ist jetzt vollständig im Ökosystem angekommen. Das 27B-Dense-Modell erreicht 77,2 % auf SWE-bench Verified und übertrifft damit das deutlich größere Qwen3.5-397B-A17B-MoE-Modell (76,2 %) auf Agentic-Coding-Benchmarks. Besonderheiten: 262K nativer Kontext (erweiterbar auf 1M via YaRN), Hybrid-Thinking-Modus (<think>…</think>), multimodal (Text + Vision).

• Ollama: ollama pull qwen3.6:27b (Text-Variante verfügbar); Vision-Features (mmproj) noch nicht über Ollama nutzbar.
• llama.cpp / GGUF: unsloth/Qwen3.6-27B-GGUF oder batiai/Qwen3.6-27B-GGUF auf Hugging Face. Q4_K_M benötigt ~18 GB RAM/VRAM (RTX 4090, M2 Pro 24 GB). MTP Speculative Decoding seit 16. Mai in llama.cpp: bis zu 140 t/s für 27B.
• Achtung: CUDA 13.2 produziert unlesbaren Output auf Qwen3.6-GGUFs – 13.1 oder 13.3 verwenden.

Kimi K2 / K2.5 / K2.6 (Moonshot AI, MIT-Lizenz)

Moonshot AI hat die Kimi-K2-Familie in kurzer Zeit auf K2.6 weiterentwickelt. Das Basismodell Kimi K2 ist ein MoE mit 32B aktiven / 1T Gesamt-Parametern; K2.6 erweitert das auf 256K Kontext, Hybrid-Thinking und Vision-Support (separat mmproj). Alle Versionen sind unter modifizierter MIT-Lizenz veröffentlicht.

• GGUF: unsloth/Kimi-K2-Instruct-GGUF und unsloth/Kimi-K2.6-GGUF auf Hugging Face; Dynamic-2-bit-Quants (UD-Q2_K_XL) benötigen ≥ 350 GB RAM/VRAM – nur für Systeme mit großem Speicher geeignet. Für Einzelpersonen mit einer H200-GPU ist das 1,8-Bit-Quant (UD-TQ1_0, ~230 GB) die zugänglichste Option.
• Inference: llama.cpp mit aktuellen Builds; ik_llama.cpp-Fork bietet verbesserte MoE-Hybrid-Offloading-Performance.
• Ollama: Auf der Ollama-Bibliotheksseite als Kimi-K2.5 gelistet; voller lokaler Betrieb setzt jedoch erheblichen Speicher voraus.

Weitere bemerkenswerte Modelle

• GLM-5.1 (Zhipu AI) – Neue Generation, im Ollama-Ökosystem verfügbar.
• Gemma 4 31B Coding MTP – MTP-Speculative-Decoding-Variante für Ollamas MLX-Runner auf Apple Silicon; >2× Speedup auf Macs (ollama run gemma4:31b-coding-mtp-bf16).
• Laguna XS.2 (Poolside AI) – Erstes Open-Weight-Coding-Modell von Poolside, seit Ollama v0.22.0 verfügbar.
• Nemotron 3 Omni (NVIDIA) – Neu in Ollama v0.22.0 gelistet.

🔀 Ökosystem

Open WebUI – v0.9.5 (10. Mai)

Open WebUI ist auf Version 0.9.5 aktualisiert worden. Nennenswerte neue Features der letzten Releases:

• Kalender-Workspace – Vollständige Kalenderintegration mit Erinnerungen (In-App-Toasts, Browser-Benachrichtigungen, Webhooks) und Automatisierungsplanung.
• Responses API / Ollama-Proxy – Der Ollama-Proxy leitet jetzt /v1/responses-Anfragen direkt an Ollama-Modelle weiter; Azure OpenAI unterstützt das neue /openai/v1-Format.
• Dateianhang aus Verlauf – Bereits hochgeladene Dateien können direkt ohne erneuten Upload in neuen Chats referenziert werden.
• DB-Migration: Asyncpg → psycopg v3 (transparente Änderung, aber eigene asyncpg-Connection-Strings müssen ggf. angepasst werden).
• Brotli-Update wegen CVE-2025-6176.

Desktop-App v0.0.20 (6. Mai) behebt den Blank-Webview-Bug auf Linux (SwiftShader-Rendering statt in-process GPU).

Quelle: github.com/open-webui/open-webui/releases

llama-cpp-python – 11. Mai 2026

Die Python-Bindings für llama.cpp wurden mit aktuellen llama.cpp-Commits synchronisiert. Neu: gpt-oss Chat-Format-Support, Qwen3.5-Hybrid-Prefix-Reuse-Fix, riscv64-Wheel-Builds, Ruff-basiertes Linting in CI.

🧠 Performance & Engineering

MTP Speculative Decoding kommt in der Breite an

Multi-Token Prediction (MTP) ist derzeit das meistdiskutierte Beschleunigungsfeature. llama.cpp hat MTP-Support für Qwen3.6 am 16. Mai gemergt. Ollama bietet MTP seit v0.23.1 für Gemma 4 auf Apple Silicon (MLX-Runner). Unsloth hat dedizierte MTP-GGUF-Varianten für Qwen3.6-27B und -35B-A3B veröffentlicht, die laut eigenen Benchmarks 1,4× (MoE) bis 2× (Dense) Speedup ohne Qualitätsverlust erreichen.

Tensor-Parallelismus-Bug bei Qwen3.6-35B-A3B mit ≥ 3 GPUs

Ein bekannter Bug in llama.cpp: Bei Verwendung von Tensor-Parallelismus mit drei oder mehr GPUs auf Qwen3.6-35B-A3B produziert llama-server nur endlose Slash-Ausgaben. Zwei GPUs oder kleinere Modelle sind nicht betroffen. Der Bug ist bekannt und in Bearbeitung.

AMD ROCm-Builds für llama.cpp

Das lemonade-sdk/llamacpp-rocm-Projekt liefert aktuelle llama.cpp-Binaries mit ROCm 7-Support für Windows und Ubuntu (GPU-Targets: gfx1150/1151, gfx120X, gfx110X, gfx103X). Build b1268 vom 15. Mai entspricht llama.cpp-Commit cc720.

🆚 Ollama vs. llama.cpp – Relevanter Unterschied heute

Olalma v0.30.0-rc kündigt an, intern auf llama.cpp zu migrieren – ein strategischer Wechsel, der langfristig die Feature-Parität erhöhen sollte. Aktuell gilt aber noch: llama.cpp unterstützt Qwen3.6 mit vollständigem Vision-Feature (mmproj-Datei) und MTP-Speculative-Decoding bereits heute vollständig; Ollama liefert die 27B-Dense-Variante textbasiert über ollama pull qwen3.6:27b, aber Vision und MTP stehen in Ollama für dieses Modell noch aus. Für Nutzer, die Qwen3.6 mit Bildeingabe oder maximaler Geschwindigkeit benötigen, ist derzeit llama.cpp direkt die erste Wahl.