Stand: 24. Mai 2026 — Quellen: GitHub Releases, offizielle Changelogs, Cyera Research, CERT Polska, Unsloth Docs
🚀 Releases
Ollama
Der aktuelle stabile Stand ist Ollama v0.24.0 (veröffentlicht 14. Mai 2026). Das Highlight: ollama launch codex-app startet OpenAIs Codex Desktop-Erfahrung direkt aus Ollama heraus — inklusive eingebautem Browser zum Annotieren laufender lokaler Apps, Review-Modus mit Kommentarfunktion und parallelen Worktrees. Zusätzlich wurde der MLX-Sampler für Apple Silicon überarbeitet.
Die unmittelbaren Vorgänger bringen ebenfalls relevante Verbesserungen:
- v0.23.4 (13. Mai):
ollama launch opencodeunterstützt jetzt Vision-Modelle mit Bildeingaben. - v0.23.2 (7. Mai):
/api/show-Antworten werden gecacht — dadurch sinkt die Median-Latenz um den Faktor 6,7×, was Integrationen wie VS Code spürbar beschleunigt. Claude Desktop wurde in dieser Version wieder ausollama launchentfernt, weil die Anthropic-Integration auf deren eigene Modelle beschränkt ist. - v0.23.1 (5. Mai): Gemma 4 MTP Speculative Decoding für den MLX-Runner — auf Macs mehr als 2× schneller bei Coding-Tasks mit
gemma4:31b-coding-mtp-bf16. - v0.23.0 (3. Mai): Claude Desktop Launch-Integration.
🔬 Pre-Release: Ollama v0.30.0-rc21 (13. Mai 2026) — eine Architektur-Umstellung: Ollama wechselt davon, auf GGML aufzubauen, zu einer direkten llama.cpp-Integration. Zusätzlich wird das GGUF-Format nativ unterstützt, MLX übernimmt weiterhin Apple-Silicon-Beschleunigung. Das Team bittet um Feedback zu Performance, Abstürzen und Speichernutzung. Bekannte Einschränkung: laguna-xs.2 und llama3.2-vision laufen im RC noch nicht. Ollama hat damit auf GitHub über 172.000 Sterne.
llama.cpp
llama.cpp b9294 wurde am 23. Mai 2026 veröffentlicht — das Projekt liefert derzeit im Schnitt alle vier Stunden ein neues Build, hat über 112.000 GitHub-Sterne und erscheint inzwischen unter der Organisation ggml-org. Build b9292 (22. Mai) enthält einen Fix für einen Integer-Overflow im Perplexity-Berechner. Die Windows Prebuilt-Pakete unterstützen CUDA, Vulkan, HIP und SYCL — Nutzer müssen in den meisten Fällen nicht mehr selbst kompilieren.
Das AMD-ROCm-Build (lemonade-sdk/llamacpp-rocm) ist ebenfalls aktuell: Build b1276 vom 22. Mai mit ROCm 7.13/7.14 für Windows und Ubuntu, GPU-Targets gfx103X–gfx1151.
llama-cpp-python wurde zuletzt am 11. Mai 2026 aktualisiert (PyPI) und enthält u.a. RISCV64-Wheel-Builds sowie gpt-oss Chat-Format-Unterstützung.
LM Studio
LM Studio v0.4.14 Build 4 (22. Mai 2026): MTP Speculative Decoding ist jetzt stabil — Modelle mit eingebauten Multi-Token-Prediction-Köpfen generieren dadurch deutlich schneller. Außerdem: Beta des LM Studio Engine Protocol, lms chat zeigt jetzt, auf welchem LM-Link-Gerät ein Remote-Modell läuft.
LM Studio v0.4.13 (13. Mai 2026): mlx-engine v1.8.1 bringt parallele Vorhersagen für Vision-Modelle (Qwen 3.5/3.6, Gemma 4) auf Apple Silicon — dieses Update wird für alle Nutzer empfohlen. Außerdem: Tool-Call-Grammatik für gpt-oss-Modelle mit dem llama.cpp-Engine (ab v2.7.1) für deutlich höhere Tool-Call-Erfolgsrate.
Open WebUI
Open WebUI v0.9.5 (10. Mai 2026, 138.000 GitHub-Sterne): Die wichtigste Neuerung ist die offizielle Desktop-App für Mac, Windows und Linux — kein Docker, kein Terminal, kein Setup. Die App verbindet sich mit beliebig vielen Open-WebUI-Instanzen, kommt mit system-weitem Floating-Chat-Bar (Shift+Cmd+I / Shift+Ctrl+I), Push-to-Talk und automatischen Updates. Außerdem wurde der async-Datenbankdriver von asyncpg auf psycopg v3 migriert (Breaking Change für individuelle Connection Strings) und Brotli aktualisiert (CVE-2025-6176). Hinweis: Dieses Release enthält DB-Schema-Änderungen — vor dem Upgrade Backup erstellen, Rolling Updates in Multi-Worker-Deployments werden nicht unterstützt.
🆕 Open-Weight-Modelle
Kimi K2.6 (Moonshot AI)
Kimi K2.6 ist ein natives multimodales, agentenoptimiertes MoE-Modell mit ca. 1 Billion Parametern (384 Experten × 14B, 256K Kontext, MIT-Lizenz). Moonshot positioniert es für Long-Horizon-Coding, autonomes Task-Orchestrieren und Vision-Eingaben. Auf Ollama direkt verfügbar: ollama pull kimi-k2.6. GGUF-Quants von Unsloth auf Hugging Face: UD-Q2_K_XL (~350 GB RAM/VRAM erforderlich), UD-Q8_K_XL gilt als verlustfrei (da das Modell nativ INT4-Gewichte für MoE-Schichten und BF16 für den Rest nutzt). Für Vision-Unterstützung gibt es eine separate mmproj-Datei.
Hardware-Realität: Die 2-bit-Quant läuft auf 4× H100 oder 2× H200 vollständig in VRAM; auf einem 256-GB Mac Studio ist Single-User-Inferenz mit RAM-Offload möglich. Vorsicht: Einige Community-Quants (z.B. bei ubergarm) erfordern den ik_llama.cpp-Fork und laufen nicht in Vanilla llama.cpp, Ollama oder LM Studio.
Qwen 3.6 27B (Alibaba)
Alibasas dichter Coding-Spezialist mit 77,2 % auf SWE-bench — bestes Ergebnis eines Dense-Modells in dieser Größenklasse. Benötigt ca. 22 GB VRAM. Verfügbar auf Ollama: ollama pull qwen3.6:27b. LM Studio unterstützt das Modell ab v0.4.12 (17. April).
Kimi K2.5 (Moonshot AI)
Der Vorgänger von K2.6 — ebenfalls 1-Billion-Parameter-MoE, SOTA in Vision, Coding und Chat. Unsloth bietet GGUFs an (UD-TQ1_0, ~240 GB im 1,8-bit-Quant), lauffähig auf einem einzelnen H200 mit System-RAM-Offload.
DeepSeek V4 Flash (DeepSeek)
284B Parameter, 13B aktiv pro Token, 1M Token Kontext, MIT-Lizenz. DeepSeek V4 Flash ist speziell für niedrige Inferenzkosten optimiert. Mainline-llama.cpp-Support ist noch WIP (PR seit Anfang Mai aktiv, FP4/FP8-GGUF-Architektur benötigt spezielle Laufzeit-Unterstützung). Community-Forks: antirez/llama.cpp-deepseek-v4-flash (Metal + CUDA, Q2-Quant ~76 GB RAM, Q4 ~256 GB) und nisparks/llama.cpp (WIP-Branch mit FP4/FP8-GGUF). Auf Ollama noch nicht offiziell verfügbar. Antirez kündigte am 7. Mai 2026 die eigenständige Engine DS4 (DwarfStar4) an — eine hochspezialisierte Metal/CUDA-Inferenz-Engine ausschließlich für DeepSeek V4 Flash ohne externe Abhängigkeiten.
GLM-5.1 (Zhipu AI)
Auf Ollama verfügbar: ollama pull glm-5.1. Positioniert als starker Dense-Coding-Performer auf SWE-Bench Pro.
🔴 Sicherheit
⚠️ CVE-2026-7482 „Bleeding Llama“ — Kritisch, alle Plattformen, Ollama < 0.17.1
Forscher von Cyera entdeckten einen Heap-Out-of-Bounds-Read im GGUF-Model-Loader von Ollama (CVSS 9.1). Ein Angreifer schickt eine manipulierte GGUF-Datei, die einen zu großen Tensor-Offset deklariert — Ollama liest dann weit über den Puffer hinaus und gibt Heap-Speicher preis. Ohne Authentifizierung genügen drei API-Aufrufe. Aus dem geleakten Speicher können API-Keys, Umgebungsvariablen, System-Prompts, laufende Konversationen aller Nutzer und proprietärer Code extrahiert werden. Über 300.000 internetexponierte Ollama-Server wurden als potenziell betroffen identifiziert.
Fix: Ollama ≥ 0.17.1 (gepatcht seit 25. Februar 2026). Nutzer auf aktuellem v0.24.x sind nicht betroffen. Wer noch ältere Versionen betreibt: sofort updaten, alle Secrets rotieren und Ollama aus dem Internet nehmen. Der Patch erschien ohne expliziten Security-Hinweis in den Release Notes — was die öffentliche Warnung verzögerte.
⚠️ CVE-2026-42248 + CVE-2026-42249 — Windows only, Ollama 0.12.10–0.17.5 (bestätigt)
Striga-Forscher entdeckten zwei Schwachstellen im Windows-Auto-Updater von Ollama, die kombiniert zu persistenter Remote Code Execution bei jedem Login führen. CVE-2026-: Der Updater übernimmt den Staging-Pfad direkt aus HTTP-Response-Headern, ohne sie zu sanitisieren. Ein Angreifer, der die Update-Antwort kontrolliert, kann eine bösartige EXE in den Windows-Startup-Ordner schreiben. CVE-2026-42248 (fehlende Signaturprüfung) ermöglicht Code Execution auch ohne Path Traversal. CERT Polska hat die Versionen 0.12.10–0.17.5 als verwundbar bestätigt (veröffentlicht 29. April 2026). Ob 0.24.x gepatcht ist, wurde von den Maintainern bislang nicht offiziell kommuniziert. Empfehlung für Windows-Nutzer: Auto-Update in Ollama deaktivieren, den Ollama-Startup-Ordner-Eintrag prüfen und auf den aktuellen Stand upgraden. Der OLLAMA_UPDATE_URL kann missbraucht werden, wenn er auf HTTP umgestellt wird.
🔀 Ökosystem
Open WebUI Desktop App
Die neue native Desktop-App (v0.0.20, Mai 2026) behebt unter Linux den Blank-Webview-Bug durch SwiftShader-Software-Rendering. Modelle, die über Hugging Face heruntergeladen wurden, werden jetzt direkt im models/-Ordner gespeichert (nicht mehr in models/huggingface/), damit llama-server sie automatisch findet. Bestehende Modelle werden beim Start automatisch migriert.
LM Studio — Lokale Verbindung & Engine-Protokoll
LM Studio führt mit v0.4.14 das LM Studio Engine Protocol (Beta) ein — eine standardisierte Schnittstelle für Engine-Plugins. LM Link (Remote-Verbindung zu anderen LM-Studio-Instanzen, Ende-zu-Ende-verschlüsselt via Tailscale) ist stabil. Im April erwarb LM Studio das Startup Locally AI, das native iPhone/iPad/Mac-Apps anbietet.
llama-cpp-python
Die Python-Bindings (PyPI, Mai 2026) unterstützen jetzt RISCV64-Wheel-Builds und können das gpt-oss-Chat-Format über eine strftime_now-Funktion rendern. Qwen-3.5-Hybrid-Prefix-Reuse-Bug wurde gefixt.
🧠 Performance & Engineering
Speculative Decoding: MTP überall
Multi-Token Prediction (MTP) ist die Technik der Woche: Ollama 0.23.1 aktivierte Gemma-4-MTP für den MLX-Runner (Mac, 2× Speedup auf 31B-Coding-Variante). LM Studio 0.4.14 bringt MTP nun stabil für den llama.cpp-Engine. Das Prinzip: Modelle mit eingebauten „Entwurf-Köpfen“ schlagen mehrere Tokens vor, die dann parallel verifiziert werden — günstig bei langen Generierungen mit repetitivem Muster.
DeepSeek V4 — Quant-Frontier
Das größte Quantisierungs-Abenteuer dieser Woche: DeepSeek V4 Flash mit nativen FP4/FP8-Gewichten benötigt neue GGUF-Typen (F8_E4M3_B128, MXFP4), die im Mainline llama.cpp noch nicht finalisiert sind. Der antirez-Fork demonstriert, dass 2-bit-gequante MoE-Routing-Experten auf einem MacBook mit 128 GB RAM bereits nutzbar sind — ein Beispiel, wie aggressives Quantisieren von MoE-Schichten möglich ist, weil nur eine Handvoll Experten pro Token aktiv ist.
Tensor-Parallelismus-Bug in llama.cpp
Ein bekanntes Problem (gemeldet KW19/20): Bei Tensor-Parallelismus mit drei oder mehr GPUs auf Qwen3.6-35B-A3B produziert llama-server einen endlosen Strom von Schrägstrichen als Ausgabe. Mit zwei GPUs oder kleineren Modellen tritt der Bug nicht auf. Workaround: auf ≤2 GPUs oder Modell wechseln.
🆚 Ollama vs. llama.cpp — Architektur-Divergenz
Ein bemerkenswerter strategischer Schritt: Ollama 0.30.0-rc wechselt intern von GGML zu direktem llama.cpp-Support. Damit konvergieren beide Tools auf demselben Kern — Ollama wird zur komfortablen Hülle (Modell-Registry, REST-API, Desktop-App, Launch-Integrationen) über denselben Inference-Stack, den llama.cpp nackt und ohne Abstraktion bereitstellt. Für Nutzer ändert sich im Alltag wenig; für Entwickler, die Ollama embedden, kann die Architektur-Änderung Auswirkungen auf Memory-Footprint und Performance haben — dazu wird um Feedback gebeten. llama.cpp selbst bleibt der plainste, schnellste Weg für direkte GGUF-Inferenz mit OpenAI-kompatiblem HTTP-Server (llama-server) und eignet sich weiterhin besser für fortgeschrittene GGUF-Kontrolle, Multi-GPU-Tuning und neue Modell-Architekturen wie DeepSeek V4.
Dieser Roundup wird täglich veröffentlicht. Feedback und Korrekturen gerne als Kommentar oder per E-Mail.