Stand: 26. Mai 2026 — Alle Links führen zu den primären Quellen; Versionsnummern beziehen sich auf den jeweils offiziellen Release.
🚀 Releases
Ollama
Die aktuelle stabile Version ist v0.24.0 (14. Mai 2026). Das Highlight: Codex-App-Integration per ollama launch codex-app. Die Codex-App bringt einen eingebauten Browser mit, über den man lokale Server direkt annotieren und Code-Reviews ohne Kontextwechsel durchführen kann. Außerdem wurde der MLX-Sampler für Apple Silicon überarbeitet. Als empfohlene Codex-Modelle für lokale Nutzung ohne Cloud-Abo listet der Release-Text nemotron-3-super, gemma4:31b und qwen3.6.
Weitere Releases im Mai:
- v0.23.4 (13. Mai) –
ollama launch opencodeunterstützt jetzt Visions-Modelle mit Bild-Inputs; besseres Formatting für Claude-Tool-Ergebnisse bei lokalen Bildpfaden. - v0.23.3 (12. Mai) – Mehrere MLX-Fixes, darunter ein macOS-26-Target-Leak im v3-Metallib behoben.
- v0.23.2 (7. Mai) –
/api/show-Antworten werden gecacht: Median-Latenz sinkt um ~6,7×, was VS-Code-Integrationen und ähnliche Tools deutlich schneller macht. Claude Desktop wurde ausollama launchentfernt (nur Anthropic-Modelle unterstützt). - v0.23.1 (5. Mai) – Gemma-4-MTP-Speculative-Decoding für den MLX-Runner auf Macs: über 2× Speedup für Gemma 4 31B bei Coding-Aufgaben (
ollama run gemma4:31b-coding-mtp-bf16). - v0.23.0 (3. Mai) –
ollama launch claude-desktop: Claude Desktop inkl. Claude Cowork und Claude Code als lokale Integration.
Ollama v0.30.0 – Pre-Release ⚠️
v0.30.0-rc21 (13. Mai 2026) ist ein Pre-Release mit einer grundlegenden Architekturumstellung: Ollama soll künftig direkt auf llama.cpp aufbauen statt auf dem GGML-Layer zu sitzen, und bekommt volle GGUF-Dateiformatkompatibilität. MLX bleibt für Apple-Silicon-Beschleunigung erhalten. Bekannte Einschränkungen in der Pre-Release-Phase: laguna-xs.2 und llama3.2-vision werden noch nicht unterstützt. Feedback kann über den dazugehörigen GitHub-PR gegeben werden.
llama.cpp
Die neueste Build-Version ist b9305 (24. Mai 2026) mit einem CMake-Fix für den UI-Build. Davor landete b9297 (23. Mai) mit NVFP4-MTP-Scale-Tensors und verlinkten Qwen3.5-MTP-Tensoren. In der llama-cpp-python-Bibliothek wurde zudem ein Initialisierungsbug behoben (embeddings_pre_norm_masked=false in llama_context), der in bestimmten Qwen3.5-Graphen einen ASSERT-Fehler auslöste. Das Python-Binding llama-cpp-python erschien zuletzt am 11. Mai 2026 auf PyPI.
llama.cpp zählt inzwischen über 109.000 GitHub-Stars und bleibt das Herzstück für GGUF-basierte lokale Inferenz. Im Gegensatz zu Ollama, das bisher einen vereinfachten Quant-Satz (Q4_K_M, Q8_0) für seine Registry bereitstellt, bleibt llama.cpp die direkte Anlaufstelle für die vollständige Quantisierungspalette von IQ2 bis BF16.
Open WebUI
v0.9.5 (10. Mai 2026) ist die aktuelle stabile Release. Relevante Neuerungen: Der Ollama-Proxy unterstützt jetzt die Responses API – Clients können /v1/responses direkt mit Ollama-Modellen über Open WebUI nutzen. Außerdem gibt es einen vollständigen Calendar-Workspace mit Erinnerungen, Webhooks und Scheduler-Konfiguration. Das Brotli-Paket wurde wegen CVE-2025-6176 aktualisiert. Der Desktop-Client liegt bei v0.0.20 mit einem Linux-Webview-Fix (SwiftShader statt In-Process-GPU).
🆕 Open-Weight-Modelle
Kimi K2.5 und K2.6 (Moonshot AI)
Kimi K2.5 ist ein 1-Billion-Parameter-MoE-Modell (32B aktiv) von Moonshot AI mit 256K-Kontextfenster und MIT-Lizenz. Es ist direkt per ollama pull kimi-k2.5 verfügbar. Unsloth stellt GGUF-Quantisierungen bereit, darunter das Dynamic-1,8-Bit-Quant (UD-TQ1_0, ~230 GB) und das 2-Bit-Quant (UD-Q2_K_XL, ~381 GB). Für die kleinen Quants werden mindestens 128–256 GB kombinierter RAM/VRAM empfohlen; auf einem einzelnen H200 mit CPU-Offloading sind ~5–10 tok/s realistisch.
Kimi K2.6 ergänzt K2.5 um nativen Vision-Support (multimodaler mmproj im GGUF), ebenfalls 1T Parameter (384×14B MoE), 256K Kontext und MIT-Lizenz. Das Dynamic-2-Bit-Quant (UD-Q2_K_XL) benötigt mindestens 350 GB Speicher. GGUFs auf Hugging Face von Unsloth und ubergarm verfügbar; ubergarns Varianten nutzen ik_llama.cpp für bessere MLA-3-Optimierung und laufen nicht in Standard-llama.cpp/Ollama. ollama pull kimi-k2.6 für die Standard-Quants über die Ollama-Library.
GLM-5.1 (Z.ai / Zhipu AI)
GLM-5.1 wurde am 7. April 2026 als Open-Source-Modell veröffentlicht. Es ist ein Post-Training-Upgrade von GLM-5: 744B Parameter MoE (40B aktiv), 200K-Kontext, MIT-Lizenz auf Hugging Face. Das Modell belegt Platz 1 auf SWE-Bench Pro (58,4 Punkte, vor Claude Opus 4.6 mit 57,3). Die gesamte GLM-5-Familie wurde auf ca. 100.000 Huawei-Ascend-910B-Chips trainiert – ohne NVIDIA-Hardware. Für lokale Inferenz wird die Vollpräzision erst ab 8× H200 (FP8) praktikabel; ein 2-Bit-Quant benötigt ~241 GB RAM. Inference via vLLM oder SGLang; ein direktes Ollama-Pull der vollen Modellgröße ist derzeit nicht sinnvoll möglich.
🔴 Sicherheit
CVE-2026-7482 „Bleeding Llama“ – Kritisch · Alle Plattformen · Ollama < 0.17.1
Cyera Research entdeckte eine kritische Heap-out-of-bounds-Read-Schwachstelle (CVSS 9.1) im GGUF-Model-Loader von Ollama. Ein Angreifer kann eine manipulierte GGUF-Datei hochladen, die größere Tensor-Offsets deklariert als die Datei enthält, was Ollama dazu bringt, weit über den vorgesehenen Puffer hinaus zu lesen. Aus dem Heap können dabei extrahiert werden: API-Keys, Umgebungsvariablen, System-Prompts, Conversation-History aller gleichzeitiger Nutzer sowie proprietärer Code, der an das Modell übergeben wurde. Die Ausnutzung erfordert keine Authentifizierung und ist in drei API-Aufrufen möglich.
Schätzungsweise 300.000 internet-exponierte Ollama-Server sind/waren betroffen (standardmäßig bindet Ollama an 127.0.0.1, viele Deployments setzen aber OLLAMA_HOST=0.0.0.0). Der Patch landete in Ollama v0.17.1 (25. Februar 2026), wurde aber nicht als Sicherheits-Fix markiert. Die CVE-Nummer wurde erst am 28. April 2026 durch Echo (CNA) zugewiesen, da MITRE zwei Monate nicht reagierte. Wer heute v0.24.x nutzt, ist nicht betroffen. Instanzen, die vor dem Update öffentlich erreichbar waren: Credentials rotieren, Logs prüfen.
CVE-2026-42248 & CVE-2026-42249 – Windows-only · Ollama für Windows 0.12.10–0.17.5
Striga-Forscher entdeckten zwei Schwachstellen im Windows-Auto-Updater von Ollama, die zusammen persistente Code-Ausführung ermöglichen:
- CVE-2026-42248: Die Signaturprüf-Funktion im Windows-Build existiert, wird aufgerufen – prüft aber nichts. Jede heruntergeladene Datei wird ohne Integritätsprüfung ausgeführt.
- CVE-2026-42249: Path-Traversal im Updater: Der lokale Pfad für das Installer-Staging-Verzeichnis wird direkt aus HTTP-Response-Headern (ETag) ohne Sanitisierung gebaut. Ein Angreifer, der den Update-Server kontrolliert, kann so ein beliebiges Executable in den Windows-Startup-Ordner schreiben.
Die kombinierte Angriffskette setzt voraus, dass AutoUpdateEnabled aktiv ist (Standard) und der Angreifer die Update-Antwort kontrollieren kann (z. B. via OLLAMA_UPDATE_URL-Override auf einfaches HTTP). CERT Polska koordinierte die Disclosure und bestätigte v0.15.1 als verwundbar. Stand Anfang Mai 2026 existiert kein öffentlicher Patch von Ollama für diese CVEs. Empfehlung für Windows-Nutzer: Auto-Update deaktivieren und den Ollama-Startup-Ordner-Shortcut entfernen, bis ein Fix erscheint. macOS-Builds sind nicht betroffen (korrekte Code-Signing-Prüfung).
🔀 Ökosystem
DwarfStar4 (DS4) by antirez
Salvatore Sanfilippo – Schöpfer von Redis – veröffentlichte am 7. Mai 2026 auf GitHub einen spezialisierten Inference-Engine für DeepSeek V4 Flash: DwarfStar4 (DS4). Das C- und Metal-Projekt läuft zunächst auf Apple Silicon und erreicht auf einem MacBook Pro M3 Max (128 GB) mit Q2-Quantisierung ca. 26 tok/s bei ~50 W Leistungsaufnahme. Am 11. Mai folgte eine separierbare Backend-Architektur mit einem CUDA-Pfad neben dem ursprünglichen Metal-Code; ein ROCm-Branch für AMD kam am 13. Mai dazu. Sanfilippo betont ausdrücklich, dass das Projekt ohne llama.cpp und GGML von Georgi Gerganov nicht möglich wäre, und positioniert DS4 als Speziallösung für die ungewöhnliche extreme Sparsity von DeepSeek V4 Flash – während llama.cpp 95 % der Anwendungsfälle abdeckt.
llama-swap
In der Community wächst das Interesse an llama-swap als leichtgewichtigem Go-Proxy vor llama-server: Er nimmt das model-Feld einer API-Anfrage, lädt automatisch den richtigen llama-server, proxied die Anfrage und entlädt das Modell nach einem konfigurierbaren TTL. Damit repliziert man Ollamas Auto-Unload-Verhalten mit direktem llama.cpp-Zugang und voller Quantisierungsauswahl. Mehrere Community-Guides im Mai beschreiben die Migration von Ollama zu llama.cpp + llama-swap für Headless-Server-Deployments.
Open WebUI – Responses API für Ollama
Mit v0.9.5 leitet Open WebUI /v1/responses-Anfragen transparent an Ollama-Modelle weiter. Das erlaubt es, Responses-API-Clients (z. B. Codex-App) direkt mit selbst gehosteten Modellen zu verbinden, ohne dass ein separater Adapter nötig ist.
🧠 Performance & Engineering
NVFP4 in llama.cpp – Blackwell-native Beschleunigung
NVFP4 (Nvidias block-skaliertes FP4, GGML_TYPE_NVFP4 = 40) ist seit Ende März/April 2026 in llama.cpp gemerged. Auf Blackwell-Hardware (RTX 5090, RTX PRO 6000 Blackwell, B200) gibt es echte Tensor-Core-Beschleunigung; ältere Karten profitieren nur von den geringeren Speicheranforderungen. Praktisches Beispiel: Qwen 3.6-27B schrumpft von ~17 GB (Q4_K_M) auf ~14 GB in NVFP4 – der Unterschied zwischen Einpassen und RAM-Offloading bei einer 16-GB-Karte. Build b9297 fügte zusätzlich NVFP4-MTP-Scale-Tensors für Qwen3.5 hinzu. Die Qualität von NVFP4 vs. Q4_K_M wird noch community-seitig getestet; frühe r/LocalLLaMA-Berichte deuten auf einen kleinen, aber messbaren Rückgang bei kleineren Modellen hin.
DeepSeek V4 Flash – kein offizieller upstream-Support
DeepSeek V4 Flash (284B gesamt, 13B aktiv, 1M-Kontext) ist in upstream llama.cpp noch nicht offiziell unterstützt. Das Modell nutzt eine hybride CSA+HCA-Aufmerksamkeit und native FP4/FP8-Sparse-Expert-Gewichte, die einen Community-Patch erfordern. Es existieren mehrere WIP-Branches (u. a. wip/deepseek-v4-support von nisparks, antirez‘ Fork). Auf einem einzelnen NVIDIA-GPU mit 96 GB VRAM (RTX 6000 Ada) sind 8–12 tok/s realistisch. Zur Verwendung über Ollama: Stand heute nicht verfügbar.
AMD ROCm-Builds für llama.cpp
Das lemonade-sdk/llamacpp-rocm-Projekt liefert tägliche vorkompilierte llama.cpp-Binaries mit ROCm-Support für Windows und Ubuntu. Die aktuellste Version b1278 (24. Mai 2026) baut auf llama.cpp-Commit b9305 auf und nutzt ROCm 7.14.0 für AMD-GPU-Targets gfx1151/gfx1150/gfx120X/gfx110X/gfx103X.
🆚 Ollama vs. llama.cpp
Architektur-Konvergenz: Das Pre-Release v0.30.0 zeigt, wohin Ollama sich bewegt: direkte llama.cpp-Integration statt des bisherigen GGML-Wrappers. Wenn dieser Umbau die Stable-Phase erreicht, schrumpft die technische Distanz zwischen beiden Tools erheblich. Bis dahin bleibt der praktische Unterschied: Ollama liefert ollama pull model in einer Minute, llama.cpp gibt volle Kontrolle über Quantisierungsgrad, Sampling-Parameter und Modell-Auswahl aus dem gesamten Hugging-Face-GGUF-Ökosystem. Für DeepSeek V4 Flash ist aktuell weder Ollama noch upstream llama.cpp eine Plug-and-Play-Lösung – hier sind Community-Forks oder DS4 die einzigen Optionen.