Georgi Gerganov hat still und leise eine Website lanciert: llama.app. Das klingt unspektakulär, ist aber ein bemerkenswertes Signal – denn Gerganov ist der Mann, ohne den lokale KI so, wie wir sie heute kennen, schlicht nicht existieren würde. „Our goal is to make local AI accessible to everyone“, schreibt Gerganov auf seinem X-Account und reißt, wie er es verspricht, mit seiner neuen Website alle Eintrittsbarrieren nieder. Es gibt ja einige Akteure, die freie und lokale KI möglich machen, zum Beispiel Ollama. Aber oft ist es so, dass man hinter deren „Walled Garden“ eingesperrt ist, und so ist es auch bei Ollama. Braucht man es nun nicht mehr?
Anfang 2023 portierte Gerganov das Meta-LLaMA-Modell in reines C/C++ – übers Wochenende, auf einem MacBook. Was als persönliches Experiment begann, wurde zur Grundlage für ein ganzes Ökosystem. llama.cpp läuft heute auf praktisch jeder Hardware: CPU, NVIDIA-GPU, AMD-GPU, Apple Silicon. Keine Python-Abhängigkeiten, kein aufwändiges Setup, MIT-Lizenz. Dass seither Hunderttausende Entwickler lokal mit KI-Modellen experimentieren können, geht maßgeblich auf dieses Projekt zurück.
Kein Wunder also, dass ggml-org – Gerganovs Organisation hinter llama.cpp – in enger Partnerschaft mit Hugging Face ist. Die Zusammenarbeit bringt administrativen Rückhalt, ohne die Open-Source-Natur des Projekts anzutasten.
Gerganovs neue Website ist im Kern ein gut gestaltetes Eingangstor zum Projekt. Ein einziger Befehl installiert alles:
curl -LsSf https://llama.app/install.sh | sh
Danach kann man einen vollständig lokalen KI-Server starten, der eine OpenAI-kompatible API auf einem lokalen Port bereitstellt. Modelle kommen direkt von Hugging Face, im GGUF-Format, dem inzwischen etablierten Standard für quantisierte Modelle.
Ollama hingegen, das sehr einsteigerfreundlich und deshalb für viele der erste Kontakt mit lokaler KI ist, hat einen anderen Ansatz. Ollama ist im Kern eine Abstraktionsschicht über llama.cpp. Und diese Schicht hat ihren Preis. Ollama verwaltet seine eigene Registry mit vorverarbeiteten Modellen. Was dort nicht drin ist, gibt es nicht – zumindest nicht ohne Umwege. Auf Hugging Face erscheinen neue Modelle und Experimente täglich im GGUF-Format, oft Stunden nach der ersten Veröffentlichung. Ollama hinkt naturgemäß hinterher. Selbst konvertieren ist zwar möglich, aber sehr aufwändig und fehleranfällig und für viele eine Hürde zu viel.
Zudem: Ollama hat in letzter Zeit interessante Modelle – insbesondere die wirklich spannenden, neueren Entwicklungen – vermehrt nur in der eigenen Cloud verfügbar gemacht, für die ein kostenpflichtiger Account nötig ist. Das ist geschäftlich nachvollziehbar, widerspricht aber dem Grundgedanken vieler, die gerade wegen der lokalen Ausführung zu diesem Ansatz gegriffen haben: Datenschutz, Unabhängigkeit, keine laufenden Kosten.
Und es gibt einen Performance-Overhead. Weil Ollama eine zusätzliche Verwaltungsschicht einzieht, ist es in Benchmarks unter Last spürbar langsamer als llama.cpp direkt – in manchen Szenarien mit mehreren parallelen Anfragen bis zu 40 Prozent.
Wer hingegen llama.cpp direkt nutzt, hat unmittelbaren Zugriff auf die gesamte Hugging-Face-Bibliothek im GGUF-Format. Neue Modellarchitekturen werden in llama.cpp oft schon innerhalb weniger Tage nach Veröffentlichung unterstützt – erst danach, mit erheblicher Verzögerung, landen sie (vielleicht) bei Ollama (falls die Abstraktionsschicht für die neue Architektur aufgebohrt wird). Wer mit neuen Ideen experimentieren will – ob Mixture-of-Experts-Architekturen, neue Quantisierungsverfahren oder frisch veröffentlichte Forschungsmodelle – ist mit llama.cpp klar im Vorteil.
Hinzu kommt volle Kontrolle über Parameter: Kontextfenster, Quantisierungsstufe (Q4_K_M, Q6_K, Q8_0 …), GPU-Layer-Verteilung, Batch-Größe. Ollama setzt hier auf sinnvolle Defaults, die aber manchmal zu konservativ sind.
Kann man Ollama in Open WebUI einfach durch llama.cpp ersetzen? Die kurze Antwort: Fast. Der Unterschied ist gering, jedoch für bestimmte Einsatzszenarien gravierend.
Beide Systeme sprechen das OpenAI-API-Format – konkret den /v1/chat/completions-Endpunkt. Open WebUI, das populäre lokale Frontend, unterstützt beide direkt. Der Unterschied liegt im Verbindungstyp:
- Ollama bindet man in Open WebUI über den nativen Ollama-Connector ein (Default Port 11434).
- llama.cpp fügt man als OpenAI-kompatible Verbindung hinzu (Default Port 8080, URL: http://localhost:8080).
Das ist ein Schritt mehr, aber kein Problem. In der Open-WebUI-Community gibt es sogar eine aktive Diskussion, llama.cpp in der Unterstützungshierarchie über Ollama zu stellen – gerade weil die direkte Anbindung stabiler und flexibler sei.
Ein relevanter Unterschied ist jedoch: llama.cpp-Server lädt standardmäßig genau ein Modell auf einmal. Wer zwischen Modellen wechseln will, muss den Server neu starten oder llama-swap einsetzen, ein kleines Tool für genau diesen Zweck. Ollama hingegen wechselt Modelle automatisch, was bequemer, aber auch langsamer ist. Und das bedeutet außerdem: Für professionelle Nutzung fehlt llama.cpp ein entscheidender Baustein. Wenn mehrere Nutzer gleichzeitig zugreifen, die unterschiedliche Modelle bevorzugen, die aber im Hintergrund manuell gewechselt werden müssten, ist llama.cpp eindeutig aus dem Spiel. Während Ollama für solche Szenarien schon sehr ausgereift und erprobt ist.
Doch wer Ollama nutzt, sollte nicht verzagen, sondern sich nur in Geduld üben. Es gibt dort bereits konkrete Pläne, die interne Abstraktionsschicht abzubauen und direkten Zugriff auf GGUF-Dateien von Hugging Face zu ermöglichen – ohne vorherige Konvertierung oder Registrierung im eigenen Repository. Die neue Version ist bereits angekündigt, die Umsetzung zieht sich allerdings schon eine ganze Weile. Denn das ist technisch nicht trivial, Ollamas Architektur wurde von Grund auf anders konzipiert. Wer also Ollama schon nutzt und zufrieden ist, kann einfach abwarten – der freie und direkte Zugriff auf Hugging Face wird auch dort kommen.
Update: Stand heute 02.06.2026 ist jetzt die neue Ollama Version v0.30.0 mit direkter llama.cpp und GGUF Unterstützung verfügbar. Es gibt noch Inkompatibilitäten, für produktive Systeme ist es evtl. empfehlenswert, noch auf die ersten Fehlerkorrekturen zu warten.