Stand: 30. Mai 2026 — Zusammenfassung der wichtigsten Entwicklungen im lokalen LLM-Ökosystem der vergangenen Woche.
🚀 Releases
Ollama v0.24.0 — aktuelles Stable-Release (14. Mai 2026)
Das aktuelle stabile Release bringt die Integration der Codex-App (ollama launch codex-app): ein Desktop-Erlebnis für parallele Coding-Threads mit eingebautem Browser, direkten Seiten-Annotationen und Review-Modus. Empfohlene Modelle für Codex-Aufgaben laut Release Notes sind kimi-k2.6, glm-5.1, gemma4:31b und qwen3.6. Außerdem wurde der MLX-Sampler für bessere Generierungsqualität auf Apple Silicon überarbeitet. → GitHub Release
Ollama v0.23.x — Highlights der Mai-Patch-Reihe
- v0.23.4 (13. Mai):
ollama launch opencodeunterstützt jetzt Vision-Modelle mit Bildeingaben; Fix für Claude-Tool-Ergebnis-Formatierung. - v0.23.3 (12. Mai): MLX-Stabilitätsfixes — Timeout-Probleme während der Inferenz behoben, macOS-26-Target-Leck im Metallib gepatcht.
- v0.23.2 (7. Mai):
/api/show-Antworten werden jetzt gecacht — Median-Latenz um ~6,7× verbessert, was VS-Code-Integrationen deutlich beschleunigt. Claude Desktop wurde aus dem Standard-Launch entfernt (war auf Anthropic-Modelle beschränkt). - v0.23.1 (5. Mai): Gemma-4-MTP-Spekulative-Dekodierung auf Mac — über 2× Geschwindigkeitsgewinn beim Gemma 4 31B auf Coding-Aufgaben (
gemma4:31b-coding-mtp-bf16).
⚠️ Ollama v0.30.0-rc (Pre-release)
Ein laufendes Pre-Release (zuletzt rc21/rc23, 13.–22. Mai) kündigt eine fundamentale Architektur-Änderung an: Ollama wird künftig llama.cpp direkt nutzen statt auf GGML aufzubauen, und erhält damit native GGUF-Kompatibilität. MLX bleibt der Beschleuniger auf Apple Silicon. Bekannte Einschränkungen in der Vorschau: laguna-xs.2 und llama3.2-vision werden noch nicht unterstützt. → Pre-release-Feedback-Thread
llama.cpp b9413 — aktueller Stand (29. Mai 2026)
llama.cpp veröffentlicht nahezu stündlich neue Builds. Die wichtigsten Commits vom 29. Mai:
- b9413 (neustes): CUDA-Fix — PTX-Versionscheck auf Host-Seite, um PDL-Dispatch auf Blackwell-GPUs (sm_90a/sm_90f vs. sm_90) korrekt zu behandeln; verhindert falsche Ergebnisse bei Mixed-Architecture-Builds.
- b9412: Server-Timeout auf 3600 Sekunden hochgesetzt (war zu niedrig für große Modelle mit langen Generierungen).
- b9411 🔑 Major: Vollständige Unterstützung der DeepSeek-V3.2-Modellfamilie (Architektur
LLM_ARCH_DEEPSEEK32, DSA Lightning Indexer, NVFP4-Support) — Details siehe Modell-Abschnitt. - b9410: FlashAttention nutzt jetzt f16-Maske statt f32 — spart VRAM ohne Qualitätsverlust.
- b9403: Vulkan-Backend-Fix: fehlendes
buffer-Set im Allreduce-Fallback behoben (führte zu korrumpiertem Output). - b9402: Hexagon-Backend (Qualcomm): Op-Fusion-Infrastruktur hinzugefügt, erste Anwendung: RMS_NORM+MUL-Fusion für Snapdragon-NPUs.
Open WebUI v0.9.5 (10. Mai 2026)
Letztes stabiles Release bringt einen vollständigen Kalender-Workspace mit Wiederholungs-Events, Browser-Notifications und Webhook-Erinnerungen. Weitere Neuerungen: Der Ollama-Proxy unterstützt die Responses API (/v1/responses), Azure-OpenAI-Verbindungen wurden auf das neuere /openai/v1-Format aktualisiert, und die Datenbank-Treiber wurden von asyncpg auf psycopg v3 migriert. Außerdem wurde Brotli aktualisiert (CVE-2025-6176). → GitHub
🆕 Open-Weight-Modelle
DeepSeek V3.2 — jetzt nativ in llama.cpp (b9411)
DeepSeek V3.2 ist ein MoE-Modell mit 675 Mrd. Gesamtparametern, davon 37 Mrd. aktiv pro Token. Die DeepSeek Sparse Attention (DSA)-Technik reduziert Inferenzkosten in Long-Context-Szenarien um 50–75 %. Das Modell unterstützt NVFP4. Mit Build b9411 wurde die native GGUF-Konvertierung und Laufzeit-Unterstützung in llama.cpp gelandet — inklusive DSA-Lightning-Indexer und separatem KV-Cache für DSA. Für Ollama-Nutzer: das Modell ist über die Ollama-Bibliothek verfügbar, Community-GGUF-Quantisierungen (Q4_K_M etc.) sind auf Hugging Face erhältlich.
Kimi K2.5 / K2.6 (Moonshot AI)
Kimi K2.6 ist ein 1-Billion-Parameter-MoE-Modell (32 Mrd. aktiv/Token) mit 262.144 Token Kontext und nativer Multimodalität (Text + Bild, experimentell Video). In Ollama läuft K2.6 ausschließlich als Cloud-Modell (ollama run kimi-k2.6:cloud) — lokale GGUF-Tags gibt es derzeit nicht in der offiziellen Bibliothek, da die Hardware-Anforderungen (Vollpräzision: 4× H200 GPU, ~640 GB VRAM) für Local-Inference prohibitiv sind. Für Self-Hosting: Unsloth bietet GGUF-Quantisierungen an (UD-Q2_K_XL ≈ 350 GB RAM/VRAM-Minimum). llama.cpp-Inferenz ist möglich, erfordert aber entsprechende Multi-GPU-Hardware oder CPU/GPU-Offloading.
- Unsloth GGUF: huggingface.co/unsloth/Kimi-K2.6-GGUF
- Ollama Library: ollama.com/library/kimi-k2.6 (Cloud)
GLM-5 & Qwen 3.6
Beide Modelle sind im Ollama-Release-Notes-Header (v0.24.0) als unterstützte Modelle aufgeführt. GLM-5 (Zhipu AI) ist laut Ollama-Blog auch über den Cloud-Service verfügbar. Qwen3.6-35B-A3B (MoE, 3 Mrd. aktiv) läuft lokal auf Consumer-Hardware. Hinweis: Bei Tensor-Parallelismus mit 3+ GPUs auf Qwen3.6 in llama.cpp-server wurde ein bekannter Bug mit Endlos-Slash-Output gemeldet (2 GPUs funktionieren korrekt).
🔴 Sicherheit
CVE-2026-7482 „Bleeding Llama“ — kritisch, CVSS 9.1 (alle Plattformen)
Betroffen: Ollama < 0.17.1, alle Plattformen. Gepatcht in 0.17.1 — für aktuelle 0.24.x-Nutzer nicht relevant.
Ein Heap-Out-of-Bounds-Read im GGUF-Modell-Loader ermöglicht unauthentifizierten Angreifern, den gesamten Prozess-Speicher des Ollama-Servers auszulesen. Angreifer können über den /api/create-Endpunkt eine manipulierte GGUF-Datei mit überdeklarierten Tensor-Offsets hochladen; das Server liest dann weit über den Buffer hinaus. Geleakte Daten können API-Keys, Umgebungsvariablen, System-Prompts und laufende Nutzer-Konversationen enthalten. Über 300.000 öffentlich erreichbare Ollama-Server wurden als potenziell betroffen identifiziert. Wer noch Ollama < 0.17.1 betreibt: sofort updaten und API-Keys rotieren. → Cyera Research
CVE-2026-42248 & CVE-2026-42249 — Windows-Updater-RCE, CVSS 7.7 (Windows only)
Betroffen: Ollama für Windows 0.12.10 bis 0.17.5 ausschließlich. macOS nicht betroffen.
Zwei Schwachstellen im Windows-Auto-Updater: CVE-2026-42248 (fehlende Signaturprüfung) und CVE-2026-42249 (Path Traversal über HTTP-Response-Header) erlauben es, bei einem Man-in-the-Middle-Angriff auf den Update-Server eine beliebige ausführbare Datei in den Windows-Autostart-Ordner zu schreiben. Die Datei wird bei jedem Login ausgeführt. Laut CERT Polska (Warnung 29. April 2026) sind die Lücken trotz Disclosure im Januar 2026 noch nicht offiziell gepatcht. Wer Ollama für Windows in den betroffenen Versionen nutzt: auf 0.24.0 updaten und OLLAMA_UPDATE_URL nicht auf externe Server zeigen lassen. → Help Net Security
🔀 Ökosystem
Open WebUI Desktop v0.0.20 (6. Mai 2026)
Die Electron-Desktop-App behebt einen kritischen Blank-Webview-Bug unter Linux (SwiftShader-Software-Rendering als Workaround für defekte GPU-Kompositing-Flags). Außerdem: Links öffnen sich jetzt im Standard-Browser statt in Electron. ARM64-Builds für Linux (.deb, AppImage) und Windows wurden zuvor in v0.0.19 eingeführt — unterstützt Raspberry Pi, NVIDIA DGX Spark und Snapdragon-Laptops.
llama-cpp-python 0.x (11. Mai 2026)
Neues Release auf PyPI, synchronisiert mit aktuellen llama.cpp-Commits. Riscv64-Wheel-Builds wurden zur Release-Pipeline hinzugefügt. Qwen-3.5-Hybrid-Prefix-Reuse-Fix integriert. → PyPI
llama-cpp-pydist (28. Mai 2026)
Alternatives Python-Package für llama.cpp mit vorgefertigten Wheels, zuletzt aktualisiert am 28. Mai 2026. Nützlich als Drop-in ohne eigene Kompilierung. → PyPI
ROCm-Builds für llama.cpp (lemonade-sdk)
Täglich aktualisierte llama.cpp-Binaries mit AMD ROCm 7.x für Windows und Ubuntu, GPU-Targets gfx103X–gfx1151. Build b1283 vom 29. Mai 2026 basiert auf llama.cpp-Commit 06d26. → GitHub
🧠 Performance & Engineering
Ollama auf Apple Silicon: MLX vs. llama.cpp-Metal
Seit Ollama 0.19+ wird auf Apple Silicon automatisch MLX als Inferenz-Backend eingesetzt. Gemessene Gewinne im Vergleich zum alten llama.cpp-Metal-Pfad: auf einem M4 Pro (Mac mini) mit Qwen3-Coder-30B-A3B etwa 130 tok/s (MLX) vs. 43 tok/s (llama.cpp-Metal) — ein Faktor 3. Ollama 0.23.1 bringt außerdem Gemma-4-MTP-Spekulative-Dekodierung: über 2× Geschwindigkeit für das 31B-Modell auf Coding-Tasks. llama.cpp direkt mit Metal-Backend bleibt die Wahl für maximale Kontrolle und experimentelle Quantisierungen — ohne MLX-Overhead, dafür ohne die Komfort-Layer von Ollama.
DeepSeek V3.2 DSA in llama.cpp: Architektur-Details
Der in b9411 gelandete DSA-Lightning-Indexer ist eine separate KV-Cache-Implementierung, die spezifisch für die Sparse-Attention-Muster von DeepSeek V3.2 optimiert ist. Die DSA-Technik reduziert Inferenzkosten in Long-Context-Szenarien laut Modell-Spec um 50–75 %. NVFP4 (native FP4 für MoE-Expert-Gewichte) wird in der CUDA-Backend-Implementierung unterstützt, erfordert aber Blackwell-GPUs (sm_90a).
Kimi K2.6: Quantisierungs-Hinweise für Self-Hoster
Unsloth empfiehlt für K2.6 die Quantisierung UD-Q8_K_XL als „verlustfrei“, da das Modell ursprünglich in INT4 veröffentlicht wurde — Q8_K_XL folgt dem nativen Präzisionsprofil. Der 2-bit-Quant UD-Q2_K_XL (350 GB) ist ein sinnvoller Kompromiss für Multi-GPU-Server. Perplexitätswerte: Q8_K_XL = 1,8419, Q4_K_XL = 1,8420 — nahezu identisch.
🆚 Ollama vs. llama.cpp — Aktuelle Unterschiede
Architektur: Ollama v0.30.0-rc (Pre-release) will llama.cpp direkt einbinden statt auf GGML aufzubauen. Damit nähert sich Ollama intern der llama.cpp-Codebasis an. Für Endnutzer ändert sich die API nicht — aber GGUF-Dateien sollen künftig ohne Konvertierung in Ollama geladen werden können.
DeepSeek V3.2: llama.cpp b9411 liefert nativen Support. Ollama stellt das Modell über seine Bibliothek bereit (Quantisierung und Packaging durch das Ollama-Team), exposes jedoch nicht den DSA-Lightning-Indexer direkt als Nutzer-Parameter.
Kimi K2.6: Ollama bietet nur den Cloud-Tag (:cloud) an — keine lokale GGUF-Option in der offiziellen Bibliothek. llama.cpp-Nutzer können Community-GGUFs von Hugging Face laden, benötigen aber entsprechende Hardware (350 GB+ für den kleinsten praktizierbaren Quant).