Ollama wechselt Basis auf llama.cpp – und kämpft mit Performance-Gap bei MoE-Modellen

Aktueller Stand

Ollama positioniert sich als de-facto-Einstiegspunkt für lokale LLM-Inferenz auf Consumer-Hardware – der Basisstack aus Ollama, OpenWebUI und ComfyUI gilt in der Community als etabliertes Startsetup für Linux-Workstations. Das Tool ist kostenlos und Open-Source; Monetarisierung findet nicht direkt statt.

Im Vergleich zu llama.cpp und LM Studio verliert Ollama jedoch Boden bei anspruchsvollen Workloads: Ein Praxistest zeigt, dass Ollama bei MoE-Modellen wie Qwen3.6 messbar langsamer ist als llama.cpp – besonders bei langen Kontexten. Die Inference-Engine macht dabei einen erheblichen Unterschied. Gleichzeitig wurde eine kritische unauthentisierte Speicherlücke entdeckt, die in Multi-User- oder Produktivumgebungen sensible Konversationsdaten exponieren kann. Die Nutzerbasis reicht von Hobbyisten auf RTX-3090-Setups bis zu Security-Practitionern, die Modelle zwischen 7B und 32B für Infosec-Arbeit einsetzen.

Wichtigste Updates

Der architektonisch bedeutsamste Schritt der vergangenen 30 Tage ist der Wechsel der Inferenz-Basis: Ollama v0.30.0-rc15 ersetzt GGML durch llama.cpp als direkte Grundlage. Das hat praktische Konsequenzen für das Ökosystem – Entwickler könnten Modelle nun direkt in llama.cpp einreichen und Ollama-Kompatibilität automatisch erhalten. Die Community kritisiert allerdings, dass das Ollama-README llama.cpp nicht als Basis attribuiert. Der Release-Candidate-Status signalisiert, dass der stabile Release noch aussteht.

Gleichzeitig wurde eine sicherheitsrelevante Schwachstelle publik: Eine kritische unauthentisierte Speicherlücke in Ollama – beschrieben unter dem Namen „Bleeding Llama" – kann private Eingaben und Konversationsinhalte exponieren. Besonders in produktiven oder Multi-User-Umgebungen ist das Risiko erheblich. Nutzer wurden aufgefordert, ihre Installation sofort zu prüfen und zu aktualisieren.

Ein Praxisbericht aus der Community legt strukturelle Performance-Grenzen offen: Ollama bremste Qwen3.6 35B-A3B aus, während llama.cpp dessen Stärken bei langen Kontexten voll ausspielte. Für MoE-Modelle ist der Backend-Wechsel damit kein theoretisches, sondern ein messbares Thema.

Auf Ökosystemebene gewinnt Ollama als Integrationsziel an Breite: AIPointer v1.2.0 erhielt eine Ollama-Integration für lokale Vision-Modelle mit Sub-2s-TTFT, das ORC-Framework listet Ollama als primäres lokales Backend für deklarative LLM-Workflows, und ml-intern ermöglicht SFT-Workflows mit Qwen3.6 über eine Ollama-kompatible Harness. Die Plattform fungiert zunehmend als Gravitationszentrum für Third-Party-Integrationen – auch wenn direktere Alternativen bei Spezialworkloads aufholen.

Was zu erwarten

Der stabile Release von Ollama v0.30.0 – aktuell noch im Release-Candidate-Stadium – steht unmittelbar aus. Mit dem llama.cpp-Unterbau dürfte die Frage der offiziellen Attribution und der Upstream-Synchronisierung ein Dauerthema in der Community bleiben. Ob Ollama den Performance-Rückstand bei MoE-Modellen gegenüber nativem llama.cpp schliessen kann, hängt davon ab, wie eng die Integration künftig gehalten wird. Die Sicherheitslücke „Bleeding Llama" macht ein zeitnahes Patch-Update unausweichlich. Auf Integrationsseite mehren sich Third-Party-Projekte, die Ollama als lokales Backend einbinden – was die Plattformabhängigkeit anderer Tools von Ollamas Stabilität erhöht und Zuverlässigkeitsdruck erzeugt.