Lokale KI 2026: Ollama, LM Studio und llama.cpp im ehrlichen Praxistest

Lokale KI bedeutet: Das Sprachmodell läuft auf deinem Rechner. Kein API-Schlüssel, keine Nutzungsgebühr, keine Anfrage, die einen fremden Server erreicht. Was vor zwei Jahren noch ein Bastelprojekt für Leute mit teurer Grafikkarte war, ist heute eine Installation, die zehn Minuten dauert.

Genau deshalb ist dieser Artikel auch der am schnellsten alternde in unserem ganzen Blog. Modellnamen, Versionen und Größen ändern sich hier im Wochentakt – ein Text, der Ihnen eine Rangliste der “besten Modelle” verkauft, ist in sechs Wochen falsch. Wir gehen deshalb anders vor: Der Artikel erklärt die Kategorien und Faustregeln, die stabil bleiben, und nennt konkrete Modelle nur als Momentaufnahme mit klarem Datum und nachprüfbarer Quelle.

Alle Modellangaben in diesem Artikel stammen vom 1. August 2026 und wurden an diesem Tag direkt aus der Ollama-Bibliothek, dem LM-Studio-Katalog und den GitHub-Releases abgerufen – nicht aus dem Gedächtnis, nicht aus Sekundärquellen. Wo Sie den aktuellen Stand selbst nachsehen, steht weiter unten.

Und weil Theorie in diesem Thema billig ist: Wir haben für diesen Artikel Ollama auf unserem eigenen Server installiert und selbst gemessen, wie schnell Modelle ohne jede Grafikkarte laufen. Die Zahlen stehen weiter unten, inklusive der unangenehmen.

Die kurze Version für Eilige

• Lokale KI ist gelöst, was die Software angeht. Die Installation ist ein Einzeiler, der Rest ist Hardware und Erwartungsmanagement.
• VRAM ist der Flaschenhals, nicht die Rechenleistung. Passt ein Modell nicht in den Grafikspeicher, hilft die schnellste GPU nichts.
• Faustregel: Modellgröße in GB ≈ benötigter Speicher. Ein 5,3-GB-Modell braucht rund 5,3 GB plus Reserve für den Kontext.
• Quantisierung ist der wichtigste Hebel – und Q4_K_M ist für die allermeisten Fälle der richtige Kompromiss. Unter Q4 wird es spürbar schlechter.
• Apple Silicon ist ein Sonderfall: Unified Memory heißt, der gesamte Arbeitsspeicher kann als Grafikspeicher dienen. Ein Mac mit 32 GB schlägt viele dedizierte Grafikkarten.
• CPU-only funktioniert – wir haben es gemessen: 25 Tokens/Sekunde bei einem 8B-Modell auf 12 Kernen ohne GPU. Langsam, aber benutzbar.
• Lokal gewinnt bei: Datenschutz, Dauerbetrieb, Offline, Massenverarbeitung. Cloud gewinnt bei: schwierigen Aufgaben, langen Kontexten, seltener Nutzung.
• Der ehrliche Teil: Für viele Menschen lohnt sich lokale KI schlicht nicht. Warum, steht weiter unten ungeschönt.

Warum überhaupt lokal?

Datenschutz – das stärkste Argument im deutschen Markt

Wenn Sie einen Text an einen Cloud-Dienst schicken, verlässt dieser Text Ihren Rechner. Das ist keine Unterstellung, sondern die Funktionsweise. Für private Notizen ist das meist egal. Für Mandantendaten, Patientenakten, Bewerbungsunterlagen, Verträge oder internen Quellcode ist es das nicht.

Die DSGVO macht daraus keine Geschmacksfrage. Sobald personenbezogene Daten verarbeitet werden, brauchen Sie eine Rechtsgrundlage, in aller Regel einen Auftragsverarbeitungsvertrag, und bei Anbietern außerhalb der EU zusätzlich eine tragfähige Grundlage für den Drittlandtransfer. Das ist alles machbar – seriöse Anbieter stellen die Verträge bereit –, aber es ist Aufwand, Dokumentation und ein Restrisiko.

Lokale Verarbeitung löst dieses Problem an der Wurzel: Was den Rechner nie verlässt, wird auch nicht übermittelt. Es gibt keinen Drittlandtransfer, wenn es keinen Transfer gibt. Für Kanzleien, Arztpraxen, Steuerberater, Betriebsräte und alle, die mit Berufsgeheimnissen arbeiten, ist das oft nicht nur bequemer, sondern der einzig gangbare Weg.

Ein wichtiger Zusatz, der gern unterschlagen wird: Lokale Verarbeitung befreit Sie nicht von der DSGVO. Sie verarbeiten weiterhin personenbezogene Daten und brauchen weiterhin ein Verzeichnis von Verarbeitungstätigkeiten, Löschkonzepte und technische Schutzmaßnahmen. Was entfällt, ist der Transfer an einen Dritten – der aufwendigste und rechtlich heikelste Teil.

Keine laufenden Kosten

Cloud-APIs rechnen pro Token ab. Bei gelegentlicher Nutzung ist das nahezu kostenlos. Bei automatisierten Abläufen, die tausende Dokumente verarbeiten, wird daraus ein Posten, der jeden Monat wiederkehrt und mit dem Erfolg wächst.

Lokal zahlen Sie einmal die Hardware und danach Strom. Das ist keine automatische Ersparnis – eine gebrauchte Grafikkarte mit 24 GB kostet mehr als viele Jahre moderater API-Nutzung. Aber die Kostenkurve ist flach statt linear. Wer viel verarbeitet, gewinnt; wer wenig verarbeitet, verliert.

Offline-Fähigkeit

Ein lokales Modell funktioniert im Zug, im Flugzeug, im Keller und bei Internetausfall. Für Außendienst, Werkstätten, Baustellen und Umgebungen ohne verlässliche Verbindung ist das kein Komfort, sondern die Voraussetzung überhaupt.

Keine Rate-Limits, keine Modellwechsel

Cloud-Anbieter drosseln Anfragen, ändern Preise, führen Modelle ein und stellen sie wieder ab. Wenn ein Anbieter das Modell abschaltet, auf das Ihr Arbeitsablauf abgestimmt ist, haben Sie ein Problem – Ihre sorgfältig entwickelten Prompts verhalten sich plötzlich anders.

Ein lokales Modell verändert sich nicht, solange Sie die Datei nicht ersetzen. Für reproduzierbare Abläufe ist das ein unterschätzter Vorteil. Sie können ein Modell einfrieren und wissen, dass die Ausgabe in einem Jahr noch derselben Logik folgt.

Volle Kontrolle

Sie bestimmen den Systemprompt, den Kontext, die Temperatur, die Filter – und Sie bestimmen, dass es keine Filter gibt, wo Sie keine wollen. Für Forschung, Sicherheitsanalysen oder Texte, die kommerzielle Anbieter aus Vorsicht ablehnen, ist das oft entscheidend.

Die drei Wege: Ollama, LM Studio, llama.cpp

Fast alles, was lokal läuft, basiert am Ende auf derselben Grundlage. Der Unterschied liegt darin, wie viel davon Sie sehen.

llama.cpp – das Fundament, auf dem der Rest steht

llama.cpp ist eine Inferenz-Engine in C/C++ ohne Abhängigkeiten. Sie ist der Grund, warum lokale KI auf normaler Hardware überhaupt praktikabel ist, und sie steckt – direkt oder indirekt – in den meisten anderen Werkzeugen.

Das Projekt ist außergewöhnlich aktiv: Zum Stand 1. August 2026 trägt das Repository ggml-org/llama.cpp rund 122.000 Sterne, steht unter MIT-Lizenz, und der jüngste Release trägt die Nummer b10217 vom 1. August 2026 – am selben Tag erschienen, an dem wir das geprüft haben. Releases erscheinen praktisch täglich, teils mehrfach.

Technisch bemerkenswert ist die Breite der unterstützten Hardware. Laut Projekt-Dokumentation gibt es Backends für CUDA (NVIDIA), HIP (AMD), Metal (Apple Silicon), Vulkan, SYCL (Intel), OpenCL (Adreno), WebGPU sowie CPU-Optimierungen für AVX, AVX2, AVX512 und AMX. Unterstützt werden Quantisierungen von 1,5 Bit bis 8 Bit. Und eine Funktion, die später noch wichtig wird: hybride CPU+GPU-Inferenz, mit der sich Modelle betreiben lassen, die größer sind als der verfügbare Grafikspeicher.

Die Bedienung hat sich zuletzt deutlich vereinfacht. Modelle lassen sich direkt von Hugging Face starten:

# Modell direkt von Hugging Face laden und starten
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF

# OpenAI-kompatiblen API-Server starten
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Für wen? Für alle, die genau steuern wollen, wie viele Schichten auf die GPU wandern, welche Kontextgröße gilt und wie der Speicher aufgeteilt wird. Wer nur chatten will, braucht das nicht – bekommt es aber über die anderen beiden Werkzeuge ohnehin mitgeliefert.

Ollama – der einfachste Einstieg

Ollama verpackt die Engine in etwas, das sich wie ein Paketmanager bedient. Ein Befehl lädt das Modell, startet es und stellt nebenbei einen lokalen API-Server bereit.

Stand 1. August 2026 ist die aktuelle Version v0.32.5 (veröffentlicht am 27. Juli 2026), das Repository hat rund 177.000 Sterne und steht unter MIT-Lizenz. Die Bibliothek unter ollama.com/library umfasst zu diesem Zeitpunkt 232 Modelle.

Der Reiz liegt in der Reibungslosigkeit:

ollama run qwen3.5:4b

Das lädt das Modell beim ersten Aufruf herunter und startet den Chat. Mehr ist es nicht.

Ein wichtiger Hinweis, der zum Thema dieses Artikels gehört: Ollama bietet seit einiger Zeit auch Cloud-Modelle an. In der Bibliothek sind sie mit cloud gekennzeichnet, und laut der offiziellen Dokumentation werden diese Anfragen “automatisch an Ollamas Cloud-Dienst ausgelagert”. Sie erfordern ein Konto (ollama signin) und werden mit einem Suffix aufgerufen:

ollama run gpt-oss:120b-cloud    # läuft NICHT lokal

Das ist ein legitimes Angebot für Modelle, die auf keinen normalen Rechner passen – aber es ist keine lokale KI. Wer Ollama aus Datenschutzgründen einsetzt, muss auf diese Kennzeichnung achten. Ein Modell mit -cloud im Namen verarbeitet Ihre Daten auf fremden Servern. Prüfen lässt sich das jederzeit mit ollama ps: Dort steht, ob und wie ein Modell lokal geladen ist.

Für wen? Für Entwickler, für Server, für alle, die Automatisierung wollen. Der lokale Endpunkt unter 127.0.0.1:11434 ist OpenAI-kompatibel, sodass sich vorhandene Skripte oft mit einer geänderten Basis-URL weiterverwenden lassen.

LM Studio – die grafische Oberfläche

LM Studio ist die Antwort für alle, die kein Terminal öffnen wollen: Modelle suchen, per Klick herunterladen, chatten, Parameter mit Schiebereglern einstellen.

Auch hier hat sich mehr geändert, als man vermuten würde. Stand 1. August 2026 heißt das Produkt auf der Startseite LM Studio Bionic und wird als Agent vermarktet, der lokal Dokumente bearbeiten, programmieren und Sprache in Echtzeit transkribieren kann. Die auf der Seite ausgelieferte Versionsangabe lautet 0.4.20. Als Laufzeitumgebungen nennt der Anbieter llama.cpp und MLX – womit sich der Kreis zum Fundament schließt.

Das Preismodell laut der Seite lmstudio.ai/pricing: Die lokale Nutzung ist kostenlos (“Free, $0”), inklusive lokaler Sprachtranskription und LM Link für bis zu fünf Geräte. Daneben gibt es optionale, kostenpflichtige Cloud-Credits für Modelle, die lokal nicht laufen – wieder derselbe Hinweis wie bei Ollama: Das ist dann kein lokaler Betrieb mehr.

Für wen? Für Nicht-Techniker, für alle, die Modelle ausprobieren und vergleichen wollen, und für alle, die den Modellkatalog lieber durchklicken als durchsuchen. LM Studio zeigt vor dem Download an, ob ein Modell in Ihren Speicher passt – für Einsteiger die vielleicht nützlichste Funktion überhaupt.

Welches Werkzeug also?

Die ehrliche Antwort: Beginnen Sie mit LM Studio, wenn Sie sehen wollen, ob lokale KI für Sie taugt. Wechseln Sie zu Ollama, sobald Sie etwas automatisieren wollen. llama.cpp brauchen Sie erst, wenn Ihnen die anderen beiden im Weg stehen – und dann wissen Sie auch, warum.

Quantisierung – der Punkt, an dem die meisten Artikel schwammig werden

Quantisierung ist das Verfahren, das lokale KI überhaupt ermöglicht. Und weil es fast überall nur angedeutet wird, hier ausführlich.

Das Grundprinzip

Ein Sprachmodell besteht aus Milliarden von Zahlen, den Gewichten. Trainiert werden sie üblicherweise mit 16 Bit pro Gewicht. Ein Modell mit 8 Milliarden Parametern belegt damit rund 16 Gigabyte – zwei Byte pro Parameter.

Quantisierung reduziert die Genauigkeit dieser Zahlen. Statt 16 Bit werden 8, 5, 4 oder noch weniger Bit verwendet. Das Modell wird kleiner und schneller, weil weniger Daten durch den Speicher bewegt werden müssen.

Die anschauliche Entsprechung: Sie speichern nicht mehr 3,14159265, sondern 3,14. Für die meisten Rechnungen reicht das. Für manche eben nicht.

GGUF – das Dateiformat

GGUF ist das Format, in dem quantisierte Modelle vorliegen. Es enthält die Gewichte samt Metadaten in einer einzigen Datei, unterstützt verschiedene Quantisierungsstufen und lässt sich teilweise in den Grafikspeicher und teilweise in den Arbeitsspeicher laden. Wenn Ihnen auf Hugging Face ein Modell mit “GGUF” im Namen begegnet, ist es für den lokalen Betrieb vorbereitet.

Was die Q-Zahlen bedeuten

Die Bezeichnungen wirken kryptisch, folgen aber einem System:

• Q steht für quantisiert.
• Die Zahl ist die durchschnittliche Bit-Anzahl pro Gewicht. Q4 ≈ 4 Bit, Q8 ≈ 8 Bit.
• K bezeichnet die neueren k-quant-Verfahren, die verschiedene Teile des Modells unterschiedlich stark komprimieren.
• S, M, L stehen für Small, Medium, Large – innerhalb derselben Bit-Stufe unterschiedlich große Varianten.

Statt das theoretisch zu erklären, hier eine reale Messreihe. Dies sind die tatsächlichen Dateigrößen ein und desselben Modells (granite4.1:8b, ein 8-Milliarden-Parameter-Modell), abgerufen aus der Ollama-Bibliothek am 1. August 2026:

An dieser Tabelle lässt sich das Wesentliche direkt ablesen: Von 18 GB auf 5,3 GB – eine Reduktion um 70 % – bei einem Qualitätsverlust, den die meisten Nutzer im Alltag nicht bemerken. Das ist der Grund, warum lokale KI funktioniert.

Wo die Qualität spürbar kippt

Die praktische Erfahrung der Gemeinschaft, die sich in vielen Vergleichen deckt:

• Q8 bis Q6: Unterschiede messbar, im Alltag nicht wahrnehmbar. Lohnt den zusätzlichen Speicher selten.
• Q5: Sehr gut. Sinnvoll, wenn der Speicher es hergibt.
• Q4_K_M: Der Standard. Deutlich kleiner, Qualität nahe am Original. Für praktisch alle Alltagsaufgaben die richtige Wahl.
• Q3: Hier beginnt es. Das Modell wird ungenauer, verliert bei langen Anweisungen den Faden, formatiert schlechter.
• Q2: Sichtbar beschädigt. Nur sinnvoll, wenn die Alternative “gar kein Modell” heißt.

Die wichtigste Faustregel überhaupt: Ein größeres Modell in stärkerer Quantisierung schlägt fast immer ein kleineres Modell in schwacher Quantisierung. Ein 8B-Modell in Q4 ist besser als ein 4B-Modell in Q8 – bei ungefähr gleichem Speicherbedarf. Wenn Sie sich entscheiden müssen: erst die Parameterzahl maximieren, dann die Quantisierung.

Eine Ausnahme kennt diese Regel: Unterhalb von Q4 kehrt sich das Verhältnis um. Ein 8B-Modell in Q2 ist meist schlechter als ein 4B-Modell in Q5.

Ein Sonderfall: QAT

In der Ollama-Bibliothek tauchen inzwischen Varianten mit dem Kürzel QAT auf – bei gemma4 etwa e2b-it-qat mit 4,3 GB gegenüber 7,2 GB bei der regulären Q4_K_M-Variante (Stand 1. August 2026). QAT steht für Quantization Aware Training: Das Modell wird bereits im Training auf die spätere Quantisierung vorbereitet, statt sie nachträglich anzuwenden. Das Ergebnis ist bei gleicher Größe in der Regel besser. Wenn Sie eine QAT-Variante finden, ist sie meist die klügere Wahl.

Hardware realistisch: VRAM ist der Flaschenhals

Die häufigste Fehlannahme beim Einstieg lautet: “Ich brauche eine schnelle Grafikkarte.” Richtig ist: Sie brauchen eine Grafikkarte mit viel Speicher. Das ist nicht dasselbe.

Warum Speicher wichtiger ist als Rechenleistung

Bei der Texterzeugung muss das Modell für jedes einzelne Token alle relevanten Gewichte aus dem Speicher lesen. Der begrenzende Faktor ist deshalb nicht, wie schnell der Chip rechnet, sondern wie schnell er Daten aus dem Speicher holt – und ob die Daten überhaupt hineinpassen.

Passt ein Modell nicht vollständig in den Grafikspeicher, muss der Rest über den Arbeitsspeicher laufen. Der ist um ein Vielfaches langsamer angebunden. Das Ergebnis ist kein leichter Einbruch, sondern oft ein Absturz um den Faktor zehn oder mehr. Eine ältere Karte mit 16 GB schlägt deshalb bei einem großen Modell eine neuere mit 8 GB deutlich.

Die Faustregel für den Speicherbedarf

Modellgröße in GB + 1 bis 3 GB Reserve = benötigter Speicher.

Die Dateigröße ist der größte Posten, aber nicht der einzige. Dazu kommt der KV-Cache, in dem der bisherige Gesprächsverlauf liegt. Er wächst mit der Kontextlänge – und moderne Modelle bieten sehr lange Kontexte an. Mehrere der am 1. August 2026 in der Ollama-Bibliothek gelisteten Modelle nennen 256K Kontextfenster (etwa qwen3.5 und gemma4 in den größeren Varianten). Wer diesen Kontext tatsächlich ausreizt, braucht dafür erheblich zusätzlichen Speicher. Im Alltag nutzt man selten mehr als einen Bruchteil davon.

Budgetklassen statt Kaufberatung

Konkrete Kaufempfehlungen veralten noch schneller als Modellnamen. Deshalb hier nach Speicherklassen sortiert – diese Einteilung bleibt gültig, auch wenn sich die Kartennamen ändern. Die Größenangaben sind reale Werte aus der Ollama-Bibliothek vom 1. August 2026.

Bis 8 GB Grafikspeicher Modelle bis etwa 7 Milliarden Parameter in Q4. Konkret möglich: qwen3.5:4b (3,4 GB), granite4.1:3b (2,1 GB), llama3.2:1b (1,3 GB), mistral:7b in Q4 (4,4 GB). Gut für Zusammenfassungen, Umformulierungen, einfache Klassifikation. Für anspruchsvolle Aufgaben zu klein.

12 bis 16 GB Die vernünftige Einstiegsklasse. Modelle bis rund 14 Milliarden Parameter passen bequem: granite4.1:8b (5,3 GB), gpt-oss in der kleineren Variante (14 GB, knapp), qwen3:14b (9,3 GB). Hier wird lokale KI zum ersten Mal richtig brauchbar.

24 GB Der Bereich, in dem es Spaß macht. Modelle um 27 bis 35 Milliarden Parameter laufen vollständig auf der GPU: qwen3.5:27b (17 GB), qwen3.6:27b (17 GB), granite4.1:30b (17 GB), qwen3:32b (20 GB). Für die meisten professionellen Anwendungen ist das der sinnvolle Zielbereich.

32 GB und mehr Modelle jenseits von 35 Milliarden Parametern, etwa qwen3.5:35b (24 GB) oder gemma4:31b (20 GB). Darüber wird es schnell exotisch: gpt-oss:120b liegt bei 65 GB, qwen3.5:122b bei 81 GB, qwen3:235b bei 142 GB und deepseek-r1:671b bei 404 GB. Diese Größen sind auf normaler Endanwender-Hardware nicht sinnvoll zu betreiben.

Apple Silicon – der Sonderfall

Macs mit M-Prozessoren haben Unified Memory: Prozessor und Grafikeinheit teilen sich denselben Speicher. Es gibt keine feste Aufteilung, kein Kopieren zwischen zwei Speicherbereichen – ein großer Teil des gesamten Arbeitsspeichers steht der Grafikeinheit zur Verfügung.

Praktisch heißt das: Ein Mac mit 32 GB kann Modelle laden, für die man sonst eine Grafikkarte der Oberklasse bräuchte. Ein Mac mit 64 GB bewegt sich in Regionen, die mit Einzelkarten kaum erreichbar sind. Die Speicherbandbreite ist geringer als bei dedizierten Karten, das Modell passt aber überhaupt erst hinein – und das ist die wichtigere Bedingung.

llama.cpp unterstützt Apple Silicon ausdrücklich als “first-class citizen” mit Metal-Optimierung; LM Studio nennt MLX als zweite Laufzeitumgebung neben llama.cpp. In der Ollama-Bibliothek finden sich entsprechend eigene MLX-Varianten, etwa qwen3.6:27b-mlx mit 20 GB (Stand 1. August 2026).

Der Haken: Der Speicher ist verlötet und beim Kauf festgelegt. Nachrüsten ist unmöglich. Wer einen Mac für lokale KI kauft, sollte beim Speicher großzügig sein – nachträglich lässt sich nichts korrigieren.

CPU-only: unsere eigene Messung

Über CPU-Betrieb wird viel behauptet und wenig gemessen. Deshalb haben wir es selbst getan.

Unser Server hat keine Grafikkarte – nur einen virtualisierten Grafikadapter ohne Rechenfähigkeit. Ollama meldet beim Start entsprechend: “No NVIDIA/AMD GPU detected. Ollama will run in CPU-only mode.” Die Hardware: 12 vCPU-Kerne eines AMD EPYC-Genoa mit AVX-512, 22 GB Arbeitsspeicher. Alle Modelle liefen bestätigt zu 100 % auf der CPU (ollama ps zeigt “100% CPU”).

Gemessen am 1. August 2026, jeweils über die Ollama-API mit ausgelesenen eval_count- und eval_duration-Werten:

Zur Einordnung: Menschen lesen etwa 5 bis 8 Tokens pro Sekunde. Alle drei Modelle erzeugen Text schneller, als man ihn lesen kann. CPU-only ist damit nicht “unbenutzbar”, sondern für Chat und Textarbeit durchaus praktikabel.

Zwei ehrliche Einschränkungen dazu. Erstens: Diese Werte gelten für kurze Antworten mit kurzem Kontext. Bei langen Eingaben – etwa einem eingefügten Dokument – dauert allein die Verarbeitung des Prompts spürbar, bevor das erste Token erscheint. Zweitens: Der Download der Modelle war mit wenigen Sekunden für 1 GB an einer Server-Anbindung deutlich schneller, als es zu Hause sein wird.

Und die unangenehmste Beobachtung, die wir nicht verschweigen: Das kleinste Modell war zwar mit Abstand das schnellste, antwortete aber sachlich falsch. Auf die Frage nach Quantisierung bei Sprachmodellen erklärte qwen3.5:0.8b die Quantisierung physikalischer Größen – Frequenzen und Spannungen. Fachlich korrekt beantwortet wurde dieselbe Frage erst von den beiden größeren Modellen. Das ist die Lektion in einem Satz: Geschwindigkeit ohne Qualität ist wertlos, und sehr kleine Modelle erfinden souverän klingenden Unsinn.

Was Sie an Speicherplatz einplanen müssen

Ein selten erwähnter Punkt: Modelle brauchen Platz auf der Festplatte, und man sammelt sie schneller, als man denkt. Unsere drei Testmodelle – nach jedem Maßstab eine bescheidene Auswahl – belegen zusammen 9,2 GB. Wer ernsthaft vergleicht, ist schnell im dreistelligen Gigabyte-Bereich. Eine SSD mit reichlich freiem Platz gehört zur Grundausstattung.

Schritt für Schritt: Der erste lokale Chat mit Ollama

Diese Anleitung haben wir am 1. August 2026 auf einem frischen Linux-Server genau so durchgeführt.

1. Installation

Unter Linux genügt ein Befehl:

curl -fsSL https://ollama.com/install.sh | sh

Unter macOS und Windows laden Sie den Installer von ollama.com/download.

Das Skript richtet unter Linux automatisch einen systemd-Dienst ein. Nach der Installation meldet es, dass die API unter 127.0.0.1:11434 bereitsteht – die Bindung an 127.0.0.1 bedeutet, dass der Dienst nur lokal erreichbar ist und nicht aus dem Internet. Das ist die richtige Voreinstellung; ändern Sie sie nur, wenn Sie genau wissen, was Sie tun.

Prüfen, ob es geklappt hat:

ollama --version
# ollama version is 0.32.5

2. Das erste Modell wählen

Beginnen Sie klein. Ein Modell im Bereich von 3 bis 5 GB läuft auf fast jeder Hardware und zeigt, ob Ihnen der Ansatz zusagt:

ollama pull qwen3.5:4b

Welches Modell heute die beste Wahl ist, ändert sich laufend – deshalb steht weiter unten, wo Sie das selbst nachsehen.

3. Chatten

ollama run qwen3.5:4b

Beim ersten Aufruf wird das Modell geladen, danach erscheint eine Eingabeaufforderung. Mit /bye beenden Sie die Sitzung.

4. Die API nutzen

Interessanter als der Chat ist der Server, der ohnehin schon läuft:

curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen3.5:4b",
  "prompt": "Fasse den folgenden Text in drei Stichpunkten zusammen: ...",
  "stream": false
}'

Die Antwort enthält neben dem Text auch Messwerte – eval_count für die Zahl der erzeugten Tokens und eval_duration in Nanosekunden. Genau daraus haben wir die Tabelle oben berechnet. Wer die eigene Hardware einschätzen will, teilt einfach eval_count durch eval_duration in Sekunden.

5. Nützliche Befehle

ollama list      # installierte Modelle
ollama ps        # was läuft gerade, und auf CPU oder GPU?
ollama rm NAME   # Modell löschen und Platz freigeben

ollama ps ist der wichtigste Befehl zur Fehlersuche: Er zeigt in der Spalte PROCESSOR, ob ein Modell auf der GPU oder der CPU läuft. Wenn dort unerwartet “100% CPU” steht, obwohl eine Grafikkarte vorhanden ist, passt das Modell nicht in den Speicher – dann hilft eine kleinere Quantisierung.

Welche Modelle heute – und warum diese Liste ein Verfallsdatum hat

Stand: 1. August 2026. Alle folgenden Angaben stammen von diesem Tag, direkt aus der Ollama-Bibliothek und dem LM-Studio-Katalog abgerufen. In sechs Wochen wird ein Teil davon überholt sein. Das ist keine Nachlässigkeit, sondern die Natur dieses Feldes.

Deshalb steht hier bewusst keine Rangliste, sondern eine Einordnung nach Größenklassen – die bleibt gültig, auch wenn die Namen wechseln.

Winzig (unter 2 GB) – für eingebettete Aufgaben

Beispiele mit realer Größe: llama3.2:1b (1,3 GB), qwen3:0.6b (523 MB), qwen3.5:0.8b (1,0 GB), minicpm-v4.6:1b.

Diese Modelle laufen auf praktisch allem, inklusive Einplatinenrechnern. Sinnvoll für eng umrissene Aufgaben: Klassifikation, Stichwortextraktion, einfaches Umformatieren. Nicht für offene Fragen – siehe unsere Messung oben, bei der genau so ein Modell eine Sachfrage souverän falsch beantwortete.

Klein (2 bis 6 GB) – der Alltagsbereich

Beispiele: qwen3.5:4b (3,4 GB), granite4.1:3b (2,1 GB), granite4.1:8b (5,3 GB), mistral:7b (4,4 GB), lfm2.5 (5,2 GB).

Hier beginnt echte Brauchbarkeit. Zusammenfassen, Umformulieren, Übersetzen, einfache Programmierhilfe, Fragen zu eingefügten Texten. Für die meisten Menschen, die lokale KI ausprobieren wollen, ist das der richtige Einstiegspunkt.

Bemerkenswert ist eine Architektur, die in dieser Klasse zunehmend auftaucht: Mixture-of-Experts (MoE). Bei lfm2.5:8b-a1b etwa deutet die Bezeichnung an, dass von 8 Milliarden Parametern nur rund 1 Milliarde pro Token aktiv ist. Das Modell belegt den Speicher der großen Variante, rechnet aber mit der Geschwindigkeit der kleinen. Für lokalen Betrieb ist dieser Ansatz besonders attraktiv – der Katalog beschreibt das Modell ausdrücklich als “edge model built for fast, reliable tool calling on consumer hardware”.

Mittel (6 bis 20 GB) – der professionelle Bereich

Beispiele: qwen3:14b (9,3 GB), gpt-oss (14 GB), granite4.1:30b (17 GB), qwen3.5:27b (17 GB), qwen3.6:27b (17 GB), gemma4:31b (20 GB).

Diese Klasse braucht 16 bis 24 GB Speicher, liefert dafür aber Ergebnisse, die für viele Aufgaben ausreichen. Mehrere dieser Modelle sind laut Bibliothek multimodal (Kennzeichnung vision) und beherrschen Werkzeugaufrufe (tools) – die Voraussetzung dafür, sie in Agenten-Abläufe einzubinden.

Groß (über 20 GB) – nur mit besonderer Hardware

qwen3.5:35b (24 GB), gpt-oss:120b (65 GB), qwen3.5:122b (81 GB), qwen3:235b (142 GB), deepseek-r1:671b (404 GB).

Für Endanwender-Hardware sind die oberen Einträge nicht sinnvoll. Genau hier setzen die Cloud-Angebote von Ollama und LM Studio an – mit dem bereits genannten Vorbehalt, dass das dann kein lokaler Betrieb mehr ist.

Wo Sie den aktuellen Stand selbst nachsehen

Weil dieser Abschnitt altert, hier die Quellen, die wir selbst benutzt haben. Prüfen Sie dort nach, bevor Sie sich auf eine Angabe aus irgendeinem Blogartikel verlassen – auch auf unsere:

• ollama.com/library – die Modellbibliothek. Über ?sort=newest sehen Sie die Neuzugänge, über die Detailseite eines Modells (Reiter “Tags”) alle Quantisierungsstufen mit exakten Dateigrößen und Kontextfenstern. Das ist die verlässlichste Quelle für Größenangaben, weil dort steht, was tatsächlich heruntergeladen wird.
• huggingface.co/models – die größte Modellsammlung. Nach “GGUF” filtern für lokal nutzbare Varianten.
• lmstudio.ai/models – kuratierter Katalog mit kurzen Einordnungen.
• github.com/ggml-org/llama.cpp/releases – der Versionsstand der Engine.
• github.com/ollama/ollama/releases – der Versionsstand von Ollama.

Ein Hinweis zur Bewertung: Achten Sie bei Hugging Face auf die Download-Zahlen statt auf die Likes. Likes sammeln auch Modelle, die niemand benutzt; Downloads zeigen, was tatsächlich läuft.

Was lokal gut funktioniert – und was nicht

Die entscheidende Frage ist nicht “Ist lokal besser?”, sondern “Für welche Aufgabe?”. Die Antwort fällt deutlicher aus, als beide Lager gern zugeben.

Lokal spielt seine Stärken aus bei:

Vertraulichen Dokumenten. Verträge, Personalakten, Krankenberichte, Gutachten. Hier ist der Datenschutzvorteil kein Argument unter vielen, sondern das ganze Argument.

Massenverarbeitung. Zehntausend Produktbeschreibungen umformulieren, Protokolle klassifizieren, Rechnungen auslesen. Aufgaben, die einzeln einfach sind, aber in großer Zahl anfallen. Hier fressen API-Kosten das Budget, während der lokale Rechner einfach über Nacht durchläuft.

Wiederkehrenden, eng umrissenen Aufgaben. Wenn Sie dieselbe Umformung tausendfach brauchen, reicht ein kleines Modell – und es ist schneller als jede API, weil kein Netzwerkweg dazwischenliegt.

Offline-Umgebungen. Ohne Verbindung gibt es keine Alternative.

Experimenten. Systemprompts durchprobieren, Parameter variieren, Modelle vergleichen – ohne bei jedem Versuch die Kostenuhr laufen zu sehen.

Reproduzierbarkeit. Ein eingefrorenes Modell liefert in einem Jahr noch dieselbe Logik. Cloud-Modelle werden ausgetauscht, ohne dass Sie gefragt werden.

Cloud bleibt klar überlegen bei:

Schwierigen Denkaufgaben. Komplexe Programmierprobleme, mehrstufige Analysen, anspruchsvolle fachliche Fragen. Die großen Modelle sind den lokal betreibbaren in dieser Disziplin voraus – das ist unbequem, aber es ist so.

Sehr langen Kontexten. Zwar nennen einige lokale Modelle inzwischen Kontextfenster von 256K, aber diese tatsächlich zu füllen erfordert Speicher, den kaum jemand hat. Die Angabe im Katalog und das, was auf Ihrer Hardware praktisch geht, sind zwei verschiedene Dinge.

Aktuellem Wissen. Ein lokales Modell weiß nichts, was nach seinem Training passiert ist, und hat von sich aus keinen Netzzugang.

Gelegentlicher Nutzung. Wenn Sie dreimal pro Woche eine Frage stellen, ist jede Hardware-Anschaffung wirtschaftlicher Unsinn. Kostenlose Kontingente decken das ab.

Multimodalität in der Breite. Es gibt gute lokale Modelle mit Bildverständnis, aber die Bandbreite an Fähigkeiten – Bild, Audio, Video, Werkzeugnutzung in einem – ist bei den großen Anbietern schlicht größer.

Der pragmatische Mittelweg

In der Praxis gewinnt selten eine Seite vollständig. Der vernünftige Aufbau ist hybrid: Ein lokales Modell übernimmt Routine und alles Vertrauliche, ein Cloud-Modell wird für die schwierigen Fälle gerufen. Weil Ollama und LM Studio beide OpenAI-kompatible Endpunkte anbieten, ist der Wechsel oft nur eine geänderte Basis-URL.

Wer wissen will, wie sich Cloud-Assistenten dabei unterscheiden, findet in unserem Vergleich ChatGPT vs. Claude vs. Gemini eine Einordnung – und in Was ist Claude? eine ausführliche Erklärung des Modells, mit dem dieser Blog entsteht.

Der ehrliche Teil: Wann sich lokale KI NICHT lohnt

Fast jeder Artikel zu diesem Thema endet mit “probier es aus, es ist großartig”. Das ist zu einfach. Hier die Fälle, in denen Sie es besser lassen.

Wenn Sie KI nur gelegentlich nutzen

Eine Grafikkarte mit 24 GB kostet mehr als viele Jahre normaler API-Nutzung. Wer ein paar Mal pro Woche eine Frage stellt, wird die Anschaffung nie hereinholen. Rechnen Sie ehrlich: Wie viele Anfragen pro Monat wirklich? Bei den meisten Menschen lautet die Antwort “weniger als gedacht”.

Wenn Sie die beste verfügbare Qualität brauchen

Bei schwierigen Aufgaben ist der Abstand real. Wenn Ihre Arbeit davon abhängt, dass die Antwort stimmt und die Aufgabe anspruchsvoll ist, ist ein lokales Modell auf normaler Hardware das falsche Werkzeug. Unser eigener Test hat das anschaulich gezeigt – ein kleines Modell antwortete flüssig, schnell und falsch.

Wenn Ihre Hardware nicht mitspielt

Mit 8 GB Arbeitsspeicher und ohne Grafikkarte werden Sie kleine Modelle betreiben können, aber die Erfahrung wird enttäuschen. Kaufen Sie keine Hardware für ein Vorhaben, das Sie noch nicht getestet haben. Probieren Sie es zuerst auf dem, was Sie haben.

Wenn “Datenschutz” nur ein gutes Gefühl ist

Lokale Verarbeitung ist ein echtes Argument, wenn Sie tatsächlich vertrauliche Daten verarbeiten. Wenn Sie sich Kochrezepte vorschlagen lassen, ist der Datenschutzgewinn theoretisch. Es lohnt sich, ehrlich zu prüfen, ob das eigene Motiv ein Bedürfnis oder ein Prinzip ist – beides ist legitim, aber nur eines rechtfertigt den Aufwand.

Wenn Sie den Betriebsaufwand unterschätzen

Lokale KI ist keine Anschaffung, sondern ein Betrieb. Modelle aktualisieren, Speicherplatz verwalten, Treiber pflegen, bei neuen Versionen prüfen, ob noch alles läuft. Das sind Stunden, die niemand einrechnet. Ollama erschien allein im Juli 2026 in mehreren Punktversionen; llama.cpp veröffentlicht praktisch täglich.

Wenn es Ihnen um Kostenersparnis in kleinem Maßstab geht

Strom ist nicht gratis. Ein Rechner mit leistungsfähiger Grafikkarte unter Last zieht spürbar Leistung. Bei deutschen Strompreisen relativiert das die Rechnung “lokal ist umsonst” erheblich. Der Vorteil entsteht bei Volumen, nicht bei sparsamer Gelegenheitsnutzung.

Unsere eigene Praxis – und warum sie so aussieht

Wir schreiben das offen, weil es zur Ehrlichkeit dieses Artikels gehört: Dieser Blog entsteht nicht mit lokaler KI. Vor diesem Artikel lief auf unserem Server kein Ollama, kein llama.cpp, kein lokales Modell – wir haben es eigens für diesen Text installiert, um echte Messwerte zu haben statt abgeschriebener.

Der Grund ist genau die Einschränkung, die oben steht. Unser Server hat keine Grafikkarte. Für lange, faktendichte, zweisprachige Texte brauchen wir das obere Ende der Qualitätsskala und lange Kontexte. Ein 8B-Modell mit 25 Tokens pro Sekunde auf der CPU kann das nicht leisten – nicht wegen der Geschwindigkeit, sondern wegen der Qualität.

Was wir nach diesem Test durchaus lokal betreiben würden: Klassifikation eingehender Nachrichten, Zusammenfassungen von Logdateien, das Umformatieren strukturierter Daten. Alles, was in großer Zahl anfällt und wo ein Fehler billig ist. Genau die Aufgaben also, die weiter oben in der Liste “Lokal spielt seine Stärken aus” stehen.

Das ist keine Ablehnung lokaler KI, sondern ihre bestimmungsgemäße Verwendung. Wer sie als Ersatz für alles verkauft, verkauft Ihnen eine Enttäuschung.

Häufige Fragen

Was ist lokale KI überhaupt? Ein KI-Modell, das vollständig auf Ihrem eigenen Gerät läuft. Die Modelldatei liegt auf Ihrer Festplatte, die Berechnung findet auf Ihrem Prozessor oder Ihrer Grafikkarte statt. Es wird nichts an einen Server übertragen – Ihre Eingaben verlassen das Gerät nicht.

Ist lokale KI kostenlos? Die Software ja: llama.cpp und Ollama stehen unter MIT-Lizenz, LM Studio ist für die lokale Nutzung kostenlos. Die Modelle selbst sind ebenfalls frei herunterladbar. Nicht kostenlos sind Hardware und Strom – und bei genügend Rechenleistung ist beides zusammen ein realer Posten.

Wie viel VRAM brauche ich für lokale KI? Als Faustregel: so viel, wie die Modelldatei groß ist, plus 1 bis 3 GB Reserve. 8 GB reichen für kleine Modelle, 16 GB sind der vernünftige Einstieg, 24 GB decken die meisten professionellen Anwendungen ab. Bei Apple Silicon zählt stattdessen der gesamte Arbeitsspeicher, weil er geteilt genutzt wird.

Ollama oder LM Studio – was ist besser? Sie lösen unterschiedliche Probleme. LM Studio ist besser zum Ausprobieren und Vergleichen, weil es eine grafische Oberfläche hat und vor dem Download anzeigt, ob ein Modell in Ihren Speicher passt. Ollama ist besser für Automatisierung und Dauerbetrieb, weil es sich per Befehl und API steuern lässt. Viele nutzen beides.

Was bedeutet Q4_K_M? Eine Quantisierungsstufe: rund 4 Bit pro Gewicht, nach dem k-quant-Verfahren, in mittlerer Variante. Es ist der übliche Standard, weil es die Datei stark verkleinert und die Qualität nahe am Original bleibt. Bei einem 8B-Modell schrumpft die Datei damit von 18 GB auf 5,3 GB (gemessen an granite4.1:8b, Stand 1. August 2026).

Läuft lokale KI ohne Grafikkarte? Ja. Wir haben es gemessen: Auf 12 CPU-Kernen ohne jede GPU erreichten wir 25,2 Tokens pro Sekunde mit einem 8B-Modell und 60,5 mit einem 0,8B-Modell – in beiden Fällen schneller, als ein Mensch liest. Einschränkung: Lange Eingaben brauchen spürbar Vorlaufzeit, und sehr kleine Modelle machen mehr Fehler.

Ist lokale KI DSGVO-konform? Sie beseitigt den heikelsten Teil – die Übermittlung an einen Dritten und den Drittlandtransfer. Von der DSGVO befreit sie nicht: Verzeichnis von Verarbeitungstätigkeiten, Löschkonzept, Zugriffsschutz und technische Maßnahmen bleiben Ihre Aufgabe. Der Vorteil ist real, aber er ist kein Freibrief.

Sind lokale Modelle so gut wie ChatGPT oder Claude? Bei einfachen bis mittleren Aufgaben kommen gute lokale Modelle erstaunlich nah heran. Bei schwierigen Denkaufgaben, langen Kontexten und Zuverlässigkeit bleibt ein deutlicher Abstand. Wer das Gegenteil behauptet, vergleicht meist ausgewählte Beispiele statt Alltagsbetrieb.

Was ist GGUF? Das Dateiformat für lokal betreibbare Modelle. Es enthält Gewichte und Metadaten in einer Datei, unterstützt verschiedene Quantisierungsstufen und erlaubt es, ein Modell teilweise in den Grafikspeicher und teilweise in den Arbeitsspeicher zu laden. Auf Hugging Face erkennen Sie geeignete Modelle am Kürzel “GGUF”.

Läuft ein Modell über Ollama wirklich immer lokal? Nein – und das ist ein wichtiger Punkt. Ollama bietet auch Cloud-Modelle an, erkennbar am Zusatz -cloud im Namen und an der Kennzeichnung cloud in der Bibliothek. Diese werden laut offizieller Dokumentation an Ollamas Server ausgelagert und erfordern ein Konto. Mit ollama ps sehen Sie, was tatsächlich auf Ihrer Maschine läuft.

Welches Modell soll ich zuerst ausprobieren? Eines im Bereich von 3 bis 5 GB – das läuft auf fast jeder Hardware. Welches konkret gerade die beste Wahl ist, ändert sich zu schnell für eine dauerhafte Empfehlung; sehen Sie unter ollama.com/library nach, was aktuell gut bewertet und häufig heruntergeladen wird.

Fazit: Ein Werkzeug, kein Ersatz

Lokale KI ist 2026 keine Bastelei mehr. Die Installation dauert Minuten, die Modelle sind gut, und selbst ohne Grafikkarte entsteht Text schneller, als man ihn liest – das haben wir für diesen Artikel selbst nachgemessen, statt es abzuschreiben.

Was daraus nicht folgt, ist die Empfehlung, alles lokal zu machen. Die ehrliche Antwort auf “Soll ich auf lokale KI umsteigen?” lautet: Es kommt darauf an, was Sie verarbeiten, wie oft, und wie schlimm ein Fehler ist.

• Verarbeiten Sie vertrauliche Daten? Dann ist lokale KI oft der einzige saubere Weg, und der Aufwand lohnt sich.
• Verarbeiten Sie große Mengen? Dann rechnet es sich, weil die Kostenkurve flach bleibt.
• Brauchen Sie höchste Qualität bei schwierigen Aufgaben? Dann bleibt die Cloud vorerst vorn.
• Nutzen Sie KI gelegentlich? Dann sparen Sie sich die Hardware.

Der wichtigste Rat zum Schluss betrifft nicht die Technik, sondern den Umgang mit Informationen darüber. Dieses Feld verändert sich schneller, als Artikel altern – auch dieser. Jede Modellangabe hier hat ein Datum: den 1. August 2026. Bevor Sie eine Kaufentscheidung auf eine Zahl aus irgendeinem Blogartikel stützen, schauen Sie in die Registries, die wir oben verlinkt haben. Dort steht, was heute gilt.

Und wenn Sie es einfach ausprobieren wollen: Ein Befehl, ein Modell von vier Gigabyte, zehn Minuten. Das ist ein kleiner Preis für eine belastbare eigene Meinung – und eine eigene Messung ist mehr wert als jede fremde Empfehlung. Wie wir generell zu quelloffener Software und den Fragen dahinter stehen, haben wir in unserem Artikel über Open-Source-Webbrowser ausführlicher beschrieben.