Lokale KI ist nur eine Datei und ein Programm — so führen Sie sie selbst aus

Lokale KI ist nur eine Datei und ein Programm — so führen Sie sie selbst aus

Überall wird Ihnen gesagt, Sie sollten KI auf eigener Hardware betreiben. Fast niemand erklärt, was das eigentlich bedeutet. Das Fachjargon türmt sich schnell auf — weights, quantization, VRAM, GGUF — und das Ganze sieht plötzlich nach einem Data-Science-Abschluss und einer Workstation aus, die mehr kostet als ein Gebrauchtwagen. Dieser Eindruck ist falsch, und genau deshalb geben die meisten auf und zahlen weiter für ein Cloud-Abo. Also: ein ehrlicher Satz, dann die Bestandteile darunter.

Lokale KI ist einfach eine Modelldatei auf Ihrem Computer und ein Programm, das sie ausführt. Mehr nicht. Keine Cloud, keine API-Schlüssel, kein Internet, kein Abo. Alles andere ist ein kleines Detail.

[video: Local AI Demystified — Mohammed Kmail]

Was lokale KI tatsächlich ist (und wie sie sich von ChatGPT unterscheidet)

Wenn Sie ChatGPT, Claude oder Gemini öffnen, wird Ihr Prompt nicht auf Ihrem Schreibtisch verarbeitet. Er geht über das Netz in ein Rechenzentrum, wo eine Maschine, die Sie nie gesehen haben, ein sehr großes Modell ausführt, und die Antwort wird zurück zu Ihnen gestreamt. Ihr eigener Computer trägt fast nichts dazu bei — er ist im Grunde ein entferntes Terminal in fremder Hardware.

Lokaler Betrieb kehrt dieses Verhältnis um. Das Modell — die Datei, die das gesamte erlernte Verhalten enthält — wird auf Ihre Maschine kopiert, und Ihre eigene CPU oder GPU erledigt die Berechnung. Nichts muss Ihren Schreibtisch verlassen. Dieser Wechsel bringt drei konkrete Vorteile:

• Privat. Ihre Daten wandern nirgendwohin; sie bleiben auf Ihrem Computer.
• Kostenlos. Kein Abo, keine Kosten pro Token.
• Offline. Ein Flugzeug, ein Café mit furchtbarem WLAN — egal.

Der ehrliche Haken: Die Modelle, die zu Hause laufen, sind deutlich kleiner als die Frontier-Modelle hinter Claude oder OpenAI. Aber sie sind in den letzten zwei Jahren verblüffend gut geworden, und für sehr viele Alltagsaufgaben — sogar fürs Programmieren — reichen sie mehr als aus.

Die fünf Bausteine

Jedes lokale KI-Werkzeug, egal wie poliert es wirkt, ist aus denselben fünf Teilen gebaut. Wer sie versteht, versteht lokale Modelle besser als die meisten, die darüber schreiben.

Baustein 1: die Modelldatei

Ein Modell ist buchstäblich nur eine Datei. Eine sehr große Datei — mehrere hundert Gigabyte sind möglich — voller Zahlen, die Gewichte heißen. Milliarden von Zahlen, die beim Training des Modells entstanden sind. Diese Datei denkt nicht und läuft nicht; sie liegt auf Ihrer Festplatte wie jede andere Datei. Unternehmen wie Meta, Google, Alibaba und Mistral veröffentlichen diese Dateien kostenlos — das sind die offenen Modelle: Llama, Gemma, Qwen, DeepSeek. Sie können sie einfach herunterladen.

Baustein 2: Modellgrößen (Parameter)

Modellnamen tragen Zahlen wie 4 Milliarden, 8 Milliarden, 70 Milliarden. Das B steht für Milliarden von Parametern — im Grunde, wie viele Zahlen in der Datei stecken. Die Regel ist einfach: Mehr Parameter bedeuten in der Regel ein klügeres Modell, aber auch eine größere Datei, die mehr Speicher und Rechenleistung braucht. Ein Modell mit 8 Milliarden Parametern hat wenige Gigabyte; eines mit 70 Milliarden ist so groß, dass die meisten Laptops es nicht einmal laden können, und manche es nicht einmal speichern können.

Baustein 3: Quantisierung

Das ist der größte Trick der lokalen KI, und er klingt furchteinflößender, als er ist. Quantisierung ist dieselbe Idee wie das Komprimieren eines Fotos: Die Milliarden Zahlen werden mit geringerer Genauigkeit gespeichert, und die Datei wird dramatisch kleiner, ohne dass die Qualität merklich leidet. Ein Modell, das normalerweise 16 GB Speicher braucht, kommt nach der Quantisierung mit 5–7 GB aus. Das GGML / GGUF Format, von dem Sie ständig hören, ist nur das Standarddateiformat für diese komprimierten Modelle. Quantisierung ist der ganze Grund, warum normale Computer überhaupt KI-Modelle ausführen können.

Baustein 4: die Inferenz-Engine

Das ist der Teil, den fast niemand erklärt. Ein Modell ist eine Datei voller Zahlen, und eine Datei kann sich nicht selbst ausführen. Man braucht ein Programm, das diese Zahlen in den Speicher lädt und rechnet, um das nächste Token vorherzusagen. Dieses Programm ist die Inferenz-Engine. Das bekannteste ist llama.cpp. Und hier ist das Geheimnis: Fast jedes Werkzeug, das Sie verwenden werden — LM Studio, Ollama, Docker Model Runner — ist nur eine Hülle um eine solche Engine. Die Engine erledigt die ganze Arbeit; das Werkzeug macht die Nutzung angenehm.

Baustein 5: Ihre Hardware

Es gibt wirklich nur eine Frage, die entscheidet, was läuft: Wie viel Speicher ist vorhanden, und wie schnell ist er? Auf einem PC mit dedizierter Grafikkarte ist das die VRAM. Auf einem modernen Mac der M-Serie ist es das Unified Memory (Apple teilt den Speicher zwischen CPU und GPU). Die Faustregel: Die Modelldatei muss in diesen Speicher passen, mit etwas Luft nach oben.

• 8 GB VRAM/Unified Memory → Modelle mit 3–4 Milliarden Parametern, sogar unquantisiert.
• 16 GB → bis zu 7–8 Milliarden Parameter.
• 32 GB → der Bereich von 14–30 Milliarden, wo lokale Modelle sich wirklich klug anfühlen.

Zwei Dinge zählen, und sie stehen in einem Spannungsverhältnis. Die Speicherkapazität bestimmt die Größe des Modells, das laufen kann; die Speichergeschwindigkeit bestimmt die Token pro Sekunde. Eine dedizierte GPU ist bei der Inferenz oft zwei- bis dreimal schneller, hat aber weniger Kapazität; ein Mac mit 128 GB Unified Memory kann weit größere Modelle ausführen, aber langsam. Der Bereich von 14–35 Milliarden ist der Sweet Spot — ordentliche Leistung, ohne das Gefühl, etwas zu verpassen. Und denken Sie an das Kontextfenster: Längere Gespräche und größere Dokumente füllen ebenfalls den Speicher, weil all dieser Kontext in denselben Platz passen muss.

Die vier Wege, ein Modell zu betreiben

Es gibt viele Wege, ein lokales Modell zu betreiben, und wie überall in der Software hängt es davon ab, wie viel Kontrolle Sie wollen. Was auch immer Sie wählen: Es sind immer dieselben drei Entscheidungen — ein Modell auswählen, eine Größe und Quantisierung wählen, die in den Speicher passt, und entscheiden, wie Sie mit ihm sprechen wollen (Chatfenster oder Code). Mit diesem Bild ergibt jedes Werkzeug Sinn.

1. LM Studio — die klickbare App

LM Studio ist eine gewöhnliche Desktop-App. Sie klicken, laden herunter, fassen alles an und müssen nie ein Terminal öffnen. Suchen Sie in der Modellansicht ein Modell, das zu Ihrem Speicher passt, wählen Sie eine Quantisierungsstufe (Q4, Q6, Q8 — niedriger ist stärker komprimiert), prüfen Sie die benötigten Fähigkeiten (Vision, Tool-Nutzung, Reasoning), laden Sie herunter, laden Sie das Modell und chatten Sie. Es ist einer der einfachsten Wege, Modelle herunterzuladen, und hat die meisten Funktionen. Für Entwickler, die es mit curl ansprechen wollen, stellt es außerdem einen lokalen Server und eine API bereit.

2. Ollama — der Favorit der Entwickler

Ollama ist etwas weniger visuell und gibt Ihnen etwas weniger Kontrolle, aber es ist der beliebteste Weg für Entwickler, lokale Modelle herunterzuladen und auszuführen. Von ollama.com installiert, wird es zu einem Terminal-Befehl:

ollama list          # models you already have
ollama pull <model>   # download a model from the hub
ollama run <model>    # load it into memory and chat

Während Ollama läuft, stellt es alle seine Modelle auf einem lokalen Port (11434) mit einer OpenAI-kompatiblen API bereit — Sie können also Anfragen im selben Format senden wie an ChatGPT oder Anthropic, und jedes angeforderte Modell wird automatisch geladen. Damit ist es die naheliegende Wahl, wenn Ihre Skripte und Anwendungen mit einem Modell auf Ihrer eigenen Maschine sprechen sollen.

3. Docker Model Runner — Modelle als Container

Docker Model Runner ist eine experimentelle Funktion in Docker Desktop, die Modelle wie Container behandelt. Sie können Dockerfiles und Compose-Dateien schreiben und Modelle direkt als Abhängigkeit mit Ihren Anwendungen ausliefern. Auf Linux mit Nvidia-Hardware funktioniert es sehr gut (CPU funktioniert, ist aber extrem langsam), und es stellt wie die anderen eine REST-API bereit. Wenn Sie ohnehin in einem Docker-Stack arbeiten und Modelle direkt neben Ihren Anwendungen haben wollen, ist das der Weg, sie zu betreiben.

4. Reiner Code — die Engine selbst ausführen

Die letzte Stufe ist, ein Modell in reinem Code auszuführen und eine eigene Inferenz-Engine (llama.cpp) einzubinden, statt sich auf eine Hülle zu verlassen. Die Überraschung: llama.cpp ist die Engine, die alle oben genannten Werkzeuge bereits verwenden — hier wird sie nur direkt aufgerufen. Modelldatei laden, Antwort erzeugen, ausführen:

# pseudo-code: load a GGUF model file and generate
model = load_model("qwen2.5-7b-instruct-q4.gguf")
response = model.chat("Write a haiku about running AI locally")
print(response)

Sie können Ihren Code auch auf einen laufenden Server von Ollama, LM Studio oder Docker Model Runner richten und genau dasselbe tun. Die meisten Entwickler verwalten Modelle schließlich über etwas wie Ollama und rufen sie im Code auf — der manuelle Weg ist für den Fall, dass Sie jedes Teil verstehen und höchst effizient arbeiten wollen.

Welches sollten Sie verwenden?

• Sie wollen nur chatten und nie ein Terminal sehen? Nehmen Sie LM Studio. Einfachste Downloads, die meisten Funktionen.
• Entwickler, die ein Modell wollen, mit dem Skripte und Anwendungen sprechen können? Nehmen Sie Ollama. Dazu greifen die meisten täglich.
• Sie leben schon in Docker und deployen Dinge? Nehmen Sie Docker Model Runner. Großartig im Produktivbetrieb.
• Sie wollen alles verstehen und höchst effizient arbeiten? Nehmen Sie Ihren eigenen Code mit llama.cpp.

Das Fazit

All diese Werkzeuge verwenden dieselben Bausteine: ein Modell, das buchstäblich eine Menge Zahlen in einer Datei ist, und eine Inferenz-Engine, mit schicken Funktionen obendrauf. Wer das versteht, versteht lokale Modelle. Sie brauchen keinen Monsterrechner — sogar ein Telefon kann kleine Modelle ausführen. Wählen Sie das Werkzeug, das zu Ihrer gewünschten Kontrolle passt, wählen Sie ein Modell, das in Ihren Speicher passt, und Sie betreiben KI auf Ihrem eigenen Schreibtisch: kostenlos, privat und offline.

Weiterlesen — die Quellen: die Konzepte im Detail

Dieser Artikel ist die Vogelperspektive. Wenn Sie die Mechanik wirklich verstehen wollen — was ein Gewicht ist, wie Quantisierung tatsächlich funktioniert, warum eine GPU schnell ist, was das GGUF-Format enthält —, gehen die folgenden Ressourcen auf jedes Konzept ins Detail. Jeder Link ist eine primäre oder autoritative Quelle, verifiziert 2026-09-08.

Was ein Modell tatsächlich ist (Gewichte, Parameter, Token)

• Hugging Face — "What are LLMs?" Eine klare, einsteigerfreundliche Erklärung, was ein großes Sprachmodell ist, die drei Transformer-Typen und wie die Tokenisierung funktioniert. https://huggingface.co/learn/agents-course/en/unit1/what-are-llms
• Jay Alammar — "The Illustrated Transformer" Die klassische visuelle Erklärung der Transformer-Architektur, auf der jedes moderne LLM beruht. Wer verstehen will, was tatsächlich in der Modelldatei steckt, sollte hier beginnen. https://jalammar.github.io/illustrated-transformer/
• Databricks — "What are Large Language Models?" Ein solider Überblick darüber, was LLMs sind, wie sie trainiert werden und was sie können. https://www.databricks.com/blog/what-are-large-language-models

Quantisierung und das GGUF-Format

• Maarten Grootendorst — "A Visual Guide to Quantization" Der beste Deep Dive zur Quantisierung, mit über 60 Illustrationen. Erklärt die Intuition, die Methoden und die Kompromisse. https://www.maartengrootendorst.com/blog/quantization/
• GGUF-Dateiformat — Spezifikation Die offizielle Spezifikation des GGUF-Formats — das binäre Layout, die Metadaten-Schlüssel und jeder Quantisierungstyp (Q4_K_M, Q8_0 usw.). https://github.com/ggml-org/ggml/blob/master/docs/gguf.md
• Hugging Face Hub — GGUF-Dokumentation Wie GGUF-Modelle auf dem Hub gespeichert und bereitgestellt werden, mit einer vollständigen Tabelle der Quantisierungstypen und ihrer Bitbreiten. https://huggingface.co/docs/hub/en/gguf
• Paul Ilvez — "Demystifying LLM Quantization Suffixes" Was Q4_K_M, Q8_0 und Q6_K wirklich bedeuten, mit einer Perplexitätstabelle zum Qualitätsverlust je Quantisierungsstufe. https://medium.com/@paul.ilvez/demystifying-llm-quantization-suffixes-what-q4-k-m-q8-0-and-q6-k-really-mean-0ec2770f17d3
• SitePoint — "Q4 vs Q6 vs Q8: The Quantization Decision Framework" Ein praktischer Entscheidungsrahmen für die Wahl einer Quantisierungsstufe, mit Checkliste. https://www.sitepoint.com/q4-vs-q6-vs-q8-quantization-local-llms/

Hardware: VRAM, GPUs und Speicher

• Hyperstack — "VRAM Requirements for LLMs" Wie viel VRAM für welche Modellgröße tatsächlich nötig ist und warum das zählt. https://www.hyperstack.cloud/blog/case-study/how-much-vram-do-you-need-for-llms
• LM Po — "A Guide to Estimating VRAM for LLMs" Eine praktische Anleitung, um den VRAM-Bedarf für ein bestimmtes Modell abzuschätzen. https://medium.com/@lmpo/a-guide-to-estimating-vram-for-llms-637a7568d0ea
• DataCamp — "Understanding TPUs vs GPUs in AI" Warum GPUs bei der parallelen Mathematik, die LLMs brauchen, schnell sind und wie sie sich von CPUs und TPUs unterscheiden. https://www.datacamp.com/blog/tpu-vs-gpu-ai
• JAX Scaling Book — "How to Think About GPUs" Ein tieferer, technischerer Blick auf die GPU-Architektur — Streaming-Multiprozessoren, HBM-Speicher und warum die Speicherbandbreite die Inferenzgeschwindigkeit bestimmt. https://jax-ml.github.io/scaling-book/gpus/

Die Werkzeuge im Detail

• llama.cpp (GitHub) Die Inferenz-Engine hinter den meisten lokalen KI-Werkzeugen. Das README erklärt ihr Ziel, die Build-Dokumentation behandelt die GPU-Backends (CUDA, Vulkan, Metal). https://github.com/ggml-org/llama.cpp
• llama.cpp-HTTP-Server — Dokumentation Wie llama.cpp als lokaler Server mit REST-API betrieben wird — dasselbe Muster, das Ollama und LM Studio einhüllen. https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
• Ollama-Dokumentation — ein GGUF-Modell importieren Wie eine eigene GGUF-Datei über ein Modelfile in Ollama kommt. https://docs.ollama.com/import
• Hugging Face — "Use Ollama with any GGUF Model" GGUF-Modelle vom Hub direkt über Ollama ausführen. https://huggingface.co/docs/hub/en/ollama
• n8n — "How to Run a Local LLM" Eine vollständige Einrichtungsanleitung für Ollama, LM Studio, Jan und andere Laufzeitumgebungen, mit Modell-Empfehlungen. https://blog.n8n.io/local-llm/
• Xybrid — "Run LLMs Locally: A Complete Guide" Welche Modelle auf welche Hardware passen, die wichtigsten Laufzeitumgebungen und welche Leistung zu erwarten ist. https://www.xybrid.ai/blog/run-llm-locally-complete-guide

Quellen

• Tech With Tim, "Local AI Explained: How to Run AI Models on Your Computer" — https://www.youtube.com/watch?v=edIHPoWgIKU (Transkript abgerufen 2026-09-08)
• llama.cpp (die Inferenz-Engine hinter den meisten lokalen KI-Werkzeugen) — https://github.com/ggml-org/llama.cpp
• Ollama — https://ollama.com
• LM Studio — https://lmstudio.ai
• Docker Model Runner (experimentelle Funktion in Docker Desktop) — https://docs.docker.com/desktop/features/model-runner/