Das lokale LLM-Ökosystem braucht Ollama nicht

• Ollama war anfangs ein frühes Tool, das die lokale Ausführung von LLMs vereinfachte, verlor später jedoch durch verschleierte Herkunft und die Hinwendung zu einer Cloud-zentrierten Ausrichtung Vertrauen
• Der Beitrag von llama.cpp als Kern-Engine wurde heruntergespielt, und mit dem Wechsel zu einem eigenen ggml-Backend kam es zu Leistungseinbußen und der Wiedereinführung von Bugs
• Wegen irreführender Modellbezeichnungen, der Verteilung einer nicht offenen GUI-App und einer ineffizienten Modelfile-Struktur hält die Kritik aus der Community an
• Flaschenhälse im Modell-Registry, Sicherheitslücken und eine Vendor-Lock-in-Struktur stehen im Widerspruch zu einer Local-first-Philosophie
• Open-Source-Alternativen wie llama.cpp, LM Studio und Jan bieten bereits mehr Leistung und Transparenz und haben sich als Zentrum des lokalen LLM-Ökosystems etabliert

---

Probleme von Ollama und Alternativen im lokalen LLM-Ökosystem

• Ursprung und frühe Rolle von Ollama

  • Ollama erhielt Aufmerksamkeit als erster llama.cpp-Wrapper, der die lokale Ausführung von LLMs vereinfachte
    • Nutzer konnten Modelle ausführen, ohne C++ selbst zu bauen oder einen Server zu konfigurieren
  • Später begann das Projekt jedoch, die Herkunft zu verschleiern, Nutzer in die Irre zu führen und sich von einer lokal orientierten Philosophie zu entfernen hin zu einer durch Venture Capital getragenen, Cloud-zentrierten Struktur
  • Gegründet wurde das Unternehmen von Jeffrey Morgan und Michael Chiang, die zuvor das Docker-GUI-Tool Kitematic entwickelt hatten, das von Docker Inc. übernommen wurde
  • Das Startup stammt aus Y Combinator (W21), wurde 2023 öffentlich gestartet und positionierte sich als „Docker for LLMs“

• Unzureichende Anerkennung für llama.cpp

  • Ollamas Inferenzfunktion hängt vollständig von Georgi Gerganovs llama.cpp ab
  • Über mehr als ein Jahr hinweg wurde llama.cpp weder in README, Website noch Marketingmaterial erwähnt, selbst der MIT-Lizenzhinweis fehlte
  • Ein Community-Issue zur Einhaltung der Lizenz (#3185) blieb über 400 Tage unbeantwortet
  • Später ergänzte ein Mitgründer am Ende der README lediglich die Zeile „llama.cpp project founded by Georgi Gerganov“
  • Ollama erklärte, man habe viele Patches eingebracht und werde schrittweise auf eine eigene Engine umstellen, wodurch die Anerkennung bewusst klein gehalten worden sei

Eigener Backend-Wechsel und Leistungsverlust

• Einführung eines benutzerdefinierten ggml-Backends

  • Mitte 2025 wechselte Ollama von llama.cpp auf eine eigene, auf ggml basierende Implementierung
  • Als Grund wurde Stabilität genannt, tatsächlich wurden jedoch bereits behobene Bugs wieder eingeführt
  • Es traten zahlreiche Probleme auf, darunter Fehler bei strukturierten Ausgaben, Ausfälle bei Vision-Modellen und GGML-Assertion-Crashes
  • Neuere Modelle wie GPT-OSS 20B funktionierten nicht oder scheiterten an nicht unterstützten Tensor-Typen
  • Gerganov wies selbst darauf hin, dass Ollama ggml fehlerhaft geforkt habe

• Ergebnisse aus Leistungsvergleichen

  • In Community-Benchmarks war llama.cpp 1,8-mal schneller als Ollama (161 vs. 89 Tokens/s)
  • Auch auf der CPU gab es einen Leistungsunterschied von 30 bis 50 %
  • Im Test mit Qwen-3 Coder 32B erreichte llama.cpp 70 % höheren Durchsatz
  • Als Ursachen werden Ollamas Daemon-Architektur, ineffizientes GPU-Offloading und veraltetes Backend genannt

Irreführende Modellbezeichnungen

• Fall DeepSeek-R1

  • Ollama bezeichnet verkleinerte Modelle wie DeepSeek-R1-Distill-Qwen-32B schlicht als „DeepSeek-R1“
  • Obwohl es nicht das tatsächliche 671B-Parameter-Modell ist, wird derselbe Name verwendet
  • Dadurch glaubten Nutzer fälschlich, sie hätten „DeepSeek-R1 lokal ausgeführt“, was dem Ruf von DeepSeek schadete
  • Die entsprechenden GitHub-Issues (#8557, #8698) wurden als Duplikate behandelt und blieben ungelöst
  • Auch derzeit startet ollama run deepseek-r1 weiterhin ein verkleinertes Modell

Veröffentlichung einer geschlossenen App

• Nicht offene Verteilung der GUI-App

  • Im Juli 2025 veröffentlichte Ollama eine GUI-App für macOS und Windows
  • Sie wurde in einem privaten Repository entwickelt, ohne Lizenz verteilt und der Quellcode blieb unveröffentlicht
  • Für ein Projekt, das zuvor ein Open-Source-Image gepflegt hatte, war dies ein abrupter Schritt in Richtung Geschlossenheit
  • Die Community äußerte Bedenken wegen möglicher AGPL-3.0-Abhängigkeiten und Lizenzverstößen
  • Auf der Website wurde neben dem GitHub-Link ein Download-Button platziert, was den Eindruck von Open Source vermittelte
  • Erst nach monatelangem Schweigen wurde die App im November 2025 in das Haupt-Repository übernommen
  • XDA kritisierte: „Ein Projekt, das sich als Open Source darstellt, muss klar kommunizieren, was öffentlich ist und was nicht“

Ineffizienz von Modelfile

• Überschneidung mit dem GGUF-Format

  • Das GGUF-Format enthält alle für die Modellausführung nötigen Informationen in einer einzigen Datei
  • Ollama ergänzt dazu mit Modelfile eine separate Konfigurationsdatei in einer Dockerfile-ähnlichen Struktur
  • Dadurch werden bereits in GGUF enthaltene Informationen doppelt definiert und unnötige Komplexität erzeugt
  • Ollama erkennt automatisch nur eine hart kodierte Liste von Templates, neue Templates werden ignoriert
  • In der Folge geht das Instruktionsformat des Modells kaputt, und Nutzer müssen manuell konvertieren

• Ineffiziente Parameteränderungen

  • Für Parameteränderungen muss zunächst per ollama show --modelfile exportiert, dann angepasst und anschließend mit ollama create neu erstellt werden
  • Dabei wird das gesamte 30- bis 60-GB-Modell kopiert
  • Die Community kritisierte dies als „ineffiziente und unnötige Duplizierung“
  • In llama.cpp lassen sich Parameter einfach über Kommandozeilenargumente anpassen

• Probleme bei der Template-Kompatibilität

  • Ollama nutzt die Go-Template-Syntax, die nicht zu den von Modellerstellern verwendeten Jinja-Templates passt
  • LM Studio und llama.cpp unterstützen Jinja direkt, bei Ollama ist eine Konvertierung nötig
  • Es wurden zahlreiche Fälle gemeldet, in denen durch Konvertierungsfehler Dialogformate beschädigt wurden

Flaschenhals in der Modell-Registry

• Verzögerungen bei der Modellaufnahme

  • Selbst wenn neue Modelle auf Hugging Face erscheinen, können sie in Ollama erst genutzt werden, nachdem sie manuell paketiert und registriert wurden
  • Auch die unterstützten Quantisierungsformate sind auf Q4_K_M, Q8_0 usw. beschränkt
  • Dadurch kommt es zu Verzögerungen zwischen Modellveröffentlichung und Nutzung in Ollama
  • In der Community verbreiteten sich PSA-Beiträge mit dem Hinweis: „Zum Testen neuer Modelle lieber llama.cpp oder vLLM verwenden“

• Einschränkungen bei Quantisierung

  • Ollama unterstützt Q5-, Q6- und IQ-Varianten nicht
  • Selbst auf Nutzeranfragen lautet die Antwort oft, man solle ein anderes Tool verwenden
  • Zwar ist mit dem Befehl ollama run hf.co/{repo}:{quant} inzwischen ein direkter Abruf von Hugging Face möglich, dennoch wird weiterhin in einen internen Hash-Speicher kopiert und nichts geteilt, außerdem bleiben die Template-Probleme bestehen

Cloud-Wechsel und Sicherheitsprobleme

• Einführung von Cloud-Modellen

  • Ende 2025 fügte Ollama Cloud-gehostete Modelle hinzu
  • Obwohl es sich um ein Local-first-Tool handelte, senden einige Modelle Prompts an externe Server
  • Bei der Nutzung von Drittanbieter-Modellen wie MiniMax können Daten nach außen übertragen werden
  • Ollama gibt an, keine Logs zu speichern, doch die Richtlinien der Drittanbieter bleiben unklar
  • Bei Modellen auf Basis von Alibaba Cloud gibt es keine Garantie zur Datenaufbewahrung

• Sicherheitslücken

  • CVE-2025-51471: Eine bösartige Registry kann Authentifizierungs-Tokens stehlen
  • Ein Fix-PR existierte, wurde jedoch monatelang nicht übernommen
  • Für ein Tool, das lokale Privatsphäre als Kernwert hervorhebt, ist das ein schwerwiegendes strukturelles Problem

Venture-Capital-zentrierte Struktur

• Ein wiederkehrendes Muster

  • Ein Open-Source-Projekt wird umhüllt, um eine Nutzerbasis aufzubauen → Finanzierung einzuwerben → zur Monetarisierung zu wechseln
  • Ollamas schrittweiser Verlauf
    • Start als Open Source, auf Basis von llama.cpp
    • Verringerung der Herkunftsangabe, Verpackung als unabhängiges Produkt
    • Lock-in über Modell-Registry und Format
    • Veröffentlichung einer geschlossenen GUI
    • Monetarisierung durch Einführung von Cloud-Services

• Vendor-Lock-in-Struktur

  • Ollama speichert Modelle unter gehashten Dateinamen, was die Kompatibilität mit anderen Tools erschwert
  • GGUF kann importiert werden, der Export ist jedoch absichtlich umständlich gestaltet
  • Nutzer werden dadurch an das Ollama-Ökosystem gebunden

Alternative Tools

• llama.cpp

  • Bietet einen OpenAI-kompatiblen API-Server (llama-server), Web-UI, feingranulare Parametersteuerung und hohen Durchsatz
  • Im Februar 2026 trat ggml.ai Hugging Face bei, was die langfristige Nachhaltigkeit stärkt
  • Basierend auf der MIT-Lizenz, mit über 450 Mitwirkenden

• Weitere Alternativen

  • llama-swap: unterstützt das Laden mehrerer Modelle und Hot-Swap
  • LiteLLM: bietet einen OpenAI-kompatiblen Proxy über mehrere Backends hinweg
  • LM Studio: GUI-basiert, verwendet llama.cpp, vollständig GGUF-kompatibel
  • Jan, Msty: Open-Source-Desktop-Apps mit Local-first-Design
  • koboldcpp, Red Hat ramalama: containerbasierte Modellausführung mit klarer Herkunftsangabe

Fazit: Die Richtung des lokalen LLM-Ökosystems

• Georgi Gerganovs llama.cpp ist die Grundlage lokaler KI-Innovation
  • Durch Zusammenarbeit der Community können leistungsfähige Modelle auch auf Consumer-Hardware ausgeführt werden
• Ollama ist auf dieser Basis gewachsen, hat aber durch verschleierte Herkunft, Qualitätsverlust, zunehmende Geschlossenheit und den Wechsel zur Cloud Vertrauen eingebüßt
• Was das lokale LLM-Ökosystem braucht, ist nicht Ollama, sondern llama.cpp
  • Echte Offenheit und Leistung werden bereits von Community-zentrierten Tools bereitgestellt

[shblue21]

Ich stimme dem bis zu einem gewissen Grad zu, und wenn man es lokal wirklich richtig nutzen will, scheint mir LM Studio die bessere Wahl zu sein.

[kirinonakar]

Ich habe anfangs auch mit ollama angefangen, bin aber inzwischen schon seit Längerem zu LM Studio gewechselt.

[GN⁺]

Hacker-News-Kommentare

• Die meisten Nutzer lokaler LLMs finden, dass Ollama dank seiner UX-Probleme gelöst hat
  Man kann Modelle mit einem Einzeiler starten, und sogar ROCm-Treiber werden automatisch gehandhabt
  Dagegen klingt llama.cpp schon vom Namen her wie eine C++-Bibliothek, was für normale Nutzer schwer zugänglich wirkt
  Ich will Programme einfach nicht selbst bauen, sondern sie nur unkompliziert zum Spaß ausprobieren

  • Inzwischen enthält llama.cpp standardmäßig eine GUI. Früher war das nicht so, aber die Zeiten haben sich geändert
  • Es gibt viele Alternativen wie „LM Studio, Jan, Msty, koboldcpp…“, aber ich frage mich, welcher ernsthafte Nachfolger als Ersatz für Ollama infrage kommt
    Ich nutze einen Mac Mini, aber auch ein CLI-Tool wäre okay. Die Stärke von Ollama lag in der einfachen Installation und dem Modell-Download, daher erwarte ich von einer Alternative einen ähnlichen Komfort
  • Wie wäre es mit kobold.cpp oder LM Studio. LM Studio ist zwar nicht Open Source, gibt llama.cpp aber fairen Kredit
    Ich finde, Qualitätskontrolle ist wichtig, damit nicht kaputte Modellunterstützung integriert oder fehlerhafte GGUFs hochgeladen werden
  • Stimme zu. Das ist eine ähnliche Situation wie bei Docker
    Natürlich kann man auch direkt runc verwenden, aber die meisten entscheiden sich für docker run
    UX ist ein Schlüsselfaktor für die Verbreitung von Technik, und wenn ein Projekt keine gute Oberfläche baut, ist nichts dagegen einzuwenden, dass jemand einen Wrapper darum baut
  • Dass Ollama das UX-Problem gelöst hat, entschuldigt Lizenzverstöße nicht

• Ich war es leid, dieselben Argumente immer wieder zu wiederholen, also habe ich die Zeitleiste und Quellen, die ich kenne, einmal gesammelt

  • Danke für diesen Artikel. Ich habe selbst ein wenig zu llama.cpp beigetragen, und das Verhalten der Ollama-Gründer war wirklich enttäuschend
    Als Alternative empfehle ich llama-file. Mozilla AIs llamafile funktioniert als einzelne ausführbare Datei unabhängig vom Betriebssystem und ist vollständig Open Source
    Es basiert auf CosmopolitanC von Justine Tunney und verwendet llama.cpp ganz offiziell
  • Für jemanden, dem der FOSS-Gedanke wichtig ist, war das ein sehr lehrreicher Artikel
  • Da waren viele Dinge dabei, die ich nicht wusste
  • Die Zusammenfassung und die Zeitleiste seien hervorragend

• Ich finde, Ollama ist in Sachen Benutzerfreundlichkeit 1000-mal besser
  llama.cpp ist großartig, aber nicht benutzerfreundlich für normale Nutzer
  Ich habe mit Ollama angefangen, bin aber wegen der neuesten Fixes zu llama.cpp gewechselt
  Für die Modellverwaltung nutze ich trotzdem weiterhin Ollama. Es ist einfach zu bequem, also verwalte ich das Cache-Verzeichnis per eigenem Skript

  • Im Blogbeitrag hieß es, die Alternativen seien intuitiv, aber in Wirklichkeit sind sie das nicht
    Für eine einfache Chat-App vielleicht schon, aber sobald man eine OpenAI-kompatible API und Modellverwaltung braucht, sinkt die Zugänglichkeit drastisch
  • Die standardmäßige context size von Ollama war so klein, dass sich viele beschwerten, das Modell sei dumm
    Um das dauerhaft zu ändern, musste man eine neue Modelldatei erstellen, und das war noch komplizierter
    Dieser Docker-artige Ansatz ist für normale Nutzer eher unpraktisch, und für fortgeschrittene Nutzer ist llama.cpp meiner Meinung nach besser
  • Nur zur Info: In llama.cpp gibt es jetzt einen Router-Modus, mit dem sich Modelle in Echtzeit wechseln lassen
  • Die aktuellen Versionen sind deutlich leistungsfähiger geworden. Siehe llama.cpp tools/serv
  • Ich nutze LM Studio seit 3 Jahren, und schon damals war es viel besser als Ollama

• Es wurden zwei Sichtweisen auf die MIT-Lizenz zusammengefasst

  1. „Mit einer einzigen Zeile Credit ist alles erlaubt“
  2. „Rechtlich ist es frei, aber es gibt eine moralische Verantwortung gegenüber der Community“
     Der Gründer von llama.cpp, Georgi Gerganov, hat seinen Unmut nur über fehlende Credits geäußert. Er handelte also eher im Sinne der ersten Auslegung
  • Die zweite Auslegung ergibt meiner Meinung nach keinen Sinn. Wenn man GPL-Pflichten will, sollte man eben GPL verwenden
    MIT ist ein juristisches Dokument, keine moralische Richtlinie
    Persönlich finde ich, dass man für Software für Endnutzer besser GPL verwenden sollte
    Erst MIT zu wählen und sich dann zu beschweren, dass Unternehmen den Code übernehmen, ist widersprüchlich
    Unternehmen haben meiner Meinung nach keine Moral, nur Menschen haben sie
  • Georgi hätte jederzeit auf GPL umstellen können, wenn er das gewollt hätte. Er hat es aber nicht getan
    Am Ende haben sich beide Projekte weiterentwickelt, und die Nutzer haben mehr Auswahl bekommen

• Früher war es unpraktisch, weil man den Standard-Modellordner nicht ändern konnte
  Um ein Modell zu registrieren, musste man einen Dockerfile-ähnlichen Prozess durchlaufen, und das Modell wurde in einen Hash-Storage kopiert, sodass sich sein Speicherort nicht ändern ließ
  Deshalb bin ich zu LM Studio gewechselt. Es ist nicht vollständig Open Source, aber es legte den Modellordner offen und war mit Hugging Face integriert

  • Inzwischen geht das. Über die Umgebungsvariable OLLAMA_MODELS in der Server-Konfigurationsdatei kann man den Pfad festlegen
  • Ich hatte mit genau diesem Problem ebenfalls zu kämpfen. Vor und nach dem SSD-Upgrade wollte ich es mit LM Studio vergleichen, aber das Finden und Aufräumen der Modelle war so kompliziert und unnötig schmerzhaft

• Wegen der Struktur, bei der Ollama Modelldateien in einen Hash-Blob-Storage kopiert, lassen sie sich nicht mit anderen Tools teilen
  Das ist vermutlich für Deduplizierung gedacht, macht es aber letztlich schwer, andere Tools auszuprobieren
  Da Modelldateien so groß sind, sind Speicherplatz und Downloads eine erhebliche Belastung

• Unter Arch Linux liefert pacman -Ss ollama 16 Ergebnisse, aber für llama.cpp oder lmstudio gibt es 0
  Hoffentlich ändert sich das irgendwann

  • llama.cpp aktualisiert sich zu schnell, um als stabiles Paket geeignet zu sein, ist aber stattdessen über das AUR installierbar
    Vulkan-, ROCm- und CUDA-Versionen werden alle unterstützt
  • Unter openSUSE kann man llamacpp dagegen mit zypper finden
    Versionen und Unterstützung unterscheiden sich je nach Distribution, und genau deshalb gibt es am Ende so viele Linux-Distributionen
  • Ich habe es unter CachyOS mit yay -S llama.cpp installiert, und es war viel schneller und besser als Ollama

• Der Name „llama.cpp“ klingt inzwischen nicht mehr besonders zugänglich
  Früher stand er für Metas Llama-Modelle, aber inzwischen gibt es viele leistungsfähigere Open-Source-Modelle

  • Allerdings hat „Ollama“ dasselbe Problem
    Der Name „Local LLaMA“ wird inzwischen fast als allgemeine Bezeichnung für das lokale Ausführen von Modellen verwendet
  • Ein Blick auf Wikipedias Liste generischer und generisierter Marken zeigt, dass dieses Phänomen häufig ist

• Ich habe Ollama von Anfang an gemieden, weil es den Eindruck machte, den gesamten Workflow kontrollieren zu wollen
  Im Nachhinein war das, denke ich, die richtige Entscheidung

• Die Hash-Blob-Storage-Struktur von Ollama ist die größte Falle
  Wenn man über Monate Modelle heruntergeladen hat, muss man beim Wechsel zu einem anderen Tool alles erneut herunterladen
  Die meisten Nutzer merken das erst, wenn sie schon tief investiert sind, und spüren dann die hohen Wechselkosten