KI lokal betreiben 2026: ein Leitfaden für Dokumenten-Fragen

Die Form eines lokalen Stacks

2026 lautet die Frage nicht mehr, ob du ein leistungsfähiges Modell auf eigener Hardware betreiben kannst. Das geht. Die Frage ist, welche Teile du zusammensteckst. Wer ein lokales LLM betreiben will für Dokumenten-Fragen, braucht drei Bausteine: eine Runtime, die das Modell lädt und bereitstellt, ein offenes Modell, das liest, und eine Quantisierung, die das Modell auf deinen RAM schrumpft. Stimmen diese drei, hast du einen privaten Assistenten für deine Dokumente, der nie nach Hause telefoniert.

Die Runtime wählen

Die Runtime ist das Programm, das aus einer Modelldatei etwas macht, mit dem du sprechen kannst.

• Ollama ist der einfachste Einstieg, um KI lokal auszuführen. Ein Befehl lädt ein Modell und stellt es auf localhost:11434 bereit. Es spricht eine OpenAI-kompatible API und nutzt seit v0.19 auf Apple Silicon ein MLX-Backend. Fang hier an, wenn es einfach laufen soll.
• llama.cpp ist die Engine unter weiten Teilen des Ökosystems: ein schlanker Inferenz-Kern, der GGUF-Modelldateien ausführt und einen OpenAI-kompatiblen Server auf :8080 bereitstellt. Wähle es, wenn du Kontrolle und minimalen Overhead willst.
• LM Studio ist die grafische Option: eine Desktop-Oberfläche, die Modelle (MLX und GGUF) lädt, ausführt und im Chat bedient und eine API auf :1234 anbietet. Gut für alle, die nicht im Terminal leben wollen.
• vLLM ist für Server: Hochdurchsatz-Bereitstellung auf der GPU, wenn viele Anfragen gleichzeitig bedient werden müssen, nicht für den einzelnen Laptop.
• MLX und oMLX sind der Apple-Silicon-Weg, dazu unten mehr.

Alle bieten einen OpenAI-kompatiblen Endpunkt. Das ist die stille Superkraft: Alles, was diese API aufrufen kann, auch pdf2okf, kann auf dein lokales Modell statt auf ein Cloud-Modell zeigen.

Das Modell wählen

Vier Familien decken fast jeden lokalen Bedarf an Dokumenten-Fragen ab, und alle vier sind wirklich offen:

• Gemma 4 (Google, veröffentlicht 02.04.2026, Apache-2.0): multimodal, mit 128K–256K Kontextfenster, von winzigen Edge-Varianten (E2B/E4B) bis zu einem 26B-Mixture-of-Experts und einem 31B-Dense-Modell. Es läuft offline auf Consumer-GPUs und Apple Silicon, und die Apache-2.0-Lizenz ist die Schlagzeile: keine Nutzungsbeschränkungen.
• Qwen3.5 (Alibaba, 03/2026, Apache-2.0): ein starker lokaler Allrounder mit langem Kontext, in Dense-Größen und als Mixture-of-Experts.
• Mistral (Frankreich/EU): die kleinen Modelle erschienen historisch unter Apache-2.0, Teil ihres Souveränitäts-Arguments; prüfe die Lizenz auf jeder Modellkarte.
• OLMo 3 (Ai2) ist die „fully open"-Referenz: Gewichte, Trainingsdaten, Code und Checkpoints, das ganze Modell also prüfbar.

Für einen Modell-für-Modell-Vergleich, samt europäischer Optionen, siehe welches offene Modell für deine Dokumente. Eine Lizenz-Notiz lohnt sich mitzunehmen: Die Community-Lizenz von Llama 4 verbietet die Nutzung in der EU, ein EU-Stack greift also besser zu Gemma, Qwen, Mistral oder OLMo. Den Unterschied zwischen den „offenen" Etiketten erklärt Open Weights vs. Open Source vs. Fully Open.

Quantisierung und die RAM-Faustregel

Ein Modell in voller Präzision ist für die meisten Maschinen zu groß, also läufst du eine quantisierte Version: dieselben Gewichte, niedriger aufgelöst gespeichert. Der Standard ist Q4_K_M: rund 75% kleiner als volle Präzision bei etwa 3% Qualitätsverlust. Dieser Tausch lohnt sich fast immer.

Die praktische Regel zur Dimensionierung: Ein 4-Bit-Modell braucht etwa die Hälfte seiner Parameterzahl in Gigabyte RAM, plus etwas Overhead für das Kontextfenster (den KV-Cache). Ein 7B-Modell passt also in rund 4 bis 5 GB, ein Modell der 27B-Klasse landet bei etwa 14 bis 16 GB. Passt du das Modell an deinen tatsächlichen Speicher an, läuft es; übertreibst du, kriecht es oder lädt gar nicht.

Apple Silicon im Detail

Macs sind dafür ungewöhnlich gut, wegen des Unified Memory: GPU und CPU teilen sich einen Pool, ein Modell kann fast deinen gesamten RAM nutzen, ohne dedizierte Grafikkarte. Apples MLX-Framework ist genau für diese Architektur gebaut, und oMLX ist ein eigener, OpenAI-kompatibler MLX-Server für Apple Silicon (eine Menüleisten-App), der einen lokalen Endpunkt bereitstellt. pdf2okf kann direkt darauf zeigen, BYOK-artig, nur dass der „Anbieter" dein eigener Mac ist und nichts ihn verlässt.

Sind sie gut genug?

Ehrliche Antwort: Für geerdete Dokumenten-Fragen ja. Wenn die Aufgabe des Modells ist, eine bereits abgerufene Passage zu lesen und daraus zu antworten, sind die kleinen offenen Modelle heute wirklich gut. Die Größe ist nicht der Engpass. Die Retrieval-Qualität ist es. Ein 7B-Modell mit dem richtigen Absatz schlägt ein Frontier-Modell mit dem falschen. Paradoxerweise kann starkes Reasoning die Treue bei Extraktion senken: Ein Modell, das zu sehr „nachdenkt", schmückt aus, statt zu zitieren.

Wo Frontier-Cloud-Modelle weiterhin vorne liegen, ist hartes, mehrstufiges Reasoning: viele Fakten über ein langes Argument verketten. Genau dafür ist BYOK (bring your own key) da: standardmäßig alles lokal, und nur für die seltene Frage, die es braucht, ein Frontier-Modell auf deinem eigenen Schlüssel.

Wo pdf2okf hineinpasst

pdf2okf ist von Grund auf modell-agnostisch. Es erzeugt ein OKF-kompatibles Bundle aus einfachen Markdown-Konzeptdateien, und die Struktur lebt im Bundle, nicht im Modell. Das macht das Modell zum austauschbaren Teil: heute Gemma 4, morgen Qwen, für eine sture Frage ein Frontier-Modell auf deinem Schlüssel. Das Bundle bleibt gleich, und deine Antworten bleiben darin verankert. Richte irgendeine der Runtimes oben auf pdf2okf, und deine lokale KI liest deine Dokumente dort, wo sie liegen, auf Hardware, die du kontrollierst, zugleich die sauberste Form von DSGVO-konformer KI, weil keine Seite je irgendwohin hochgeladen wird. Besitze das Modell, besitze das Format, und niemand kann dir die Fähigkeit abschalten, deine eigenen Dateien zu lesen.