Welche Hardware brauchst du für lokale Dokumenten-KI?

Der Speicher ist der entscheidende Engpass

Wer fragt, welche Maschine es braucht, um ein lokales Modell auf den eigenen Dokumenten zu betreiben, denkt meist an rohe Geschwindigkeit: eine schnelle GPU, viele Kerne. Die eigentliche Hürde ist einfacher: Passt das Modell überhaupt in den Speicher? Passt es, läuft es; passt es nicht, rettet dich kein Takt. Also dimensioniere zuerst den Speicher.

Die ehrliche Nachricht: Du brauchst fast sicher weniger, als du denkst. Für geerdete Dokumenten-Fragen (eine Passage lesen und daraus antworten) reicht ein mittelgroßes offenes Modell auf einem gut ausgestatteten Laptop oder einer einzelnen Consumer-GPU. Ein Rechenzentrum brauchst du nicht.

Die Q4-Faustregel

Ein Modell in voller Präzision ist mit 16 Bit pro Gewicht gespeichert, für die meisten Maschinen zu groß. Also läufst du eine quantisierte Kopie: dieselben Gewichte, niedriger aufgelöst gespeichert. Der Standard ist Q4_K_M: 4-Bit-Gewichte, rund 75% kleiner als volle Präzision bei etwa 3% Qualitätsverlust. Für Dokumentenarbeit lohnt sich dieser Tausch fast immer.

Daraus folgt die eine Formel, die du dir merken solltest:

Ein 4-Bit-Modell braucht für die Gewichte etwa die Hälfte seiner Parameterzahl in Gigabyte RAM oder VRAM, plus Reserve für den Kontext.

Ein ~8B-Modell will also rund 4–5 GB, ein ~14B-Modell etwa 7–9 GB, ein ~27–32B-Modell landet im mittleren bis hohen Zehnerbereich an GB, und ein ~70B-Modell liegt jenseits von 35 GB, alles noch ohne Kontext. Behandle jede Zahl hier als groben Richtwert, nicht als Datenblatt: Der tatsächliche Bedarf verschiebt sich mit der Quantisierung, der Runtime und der geladenen Kontextmenge.

Drei Wege, ein Modell im Speicher zu halten

Es gibt drei Hardware-Wege, und sie wägen Preis, Geschwindigkeit und Obergrenze unterschiedlich ab.

Dedizierte GPU. Die schnellste Option, und die starrste. Eine GPU ist schnell, weil die Gewichte in ihrem dedizierten VRAM liegen, doch dieses VRAM ist eine harte Wand. Eine Consumer-Karte mit 12, 16 oder 24 GB läuft alles, was hineinpasst, und verweigert alles andere. Eine 24-GB-Karte hält bequem ein quantisiertes ~27–32B-Modell; ein ~70B-Modell heißt: eine größere Karte oder zwei davon. Kaufe zuerst nach der VRAM-Zahl; die Geschwindigkeit folgt.

Apple Silicon. Der Trick eines Macs ist der Unified Memory: ein RAM-Pool, den CPU und GPU teilen, ohne separate VRAM-Grenze. Ein Mac mit 32, 64 oder 128 GB kann fast den ganzen Pool einem Modell widmen und hält so Modelle, die sonst eine deutlich teurere dedizierte GPU verlangten. Es ist der nachsichtigste Weg für größere Modelle auf einer einzelnen Maschine, und der Grund, warum ein Mac eine so bequeme Maschine für lokale KI ist, behandelt in lokale Dokumenten-KI auf dem Mac.

CPU + System-RAM. Der günstigste Weg, und der langsamste. Jede Maschine mit genug RAM kann ein Modell allein auf der CPU betreiben, ganz ohne GPU. Es funktioniert, und für die gelegentliche Frage ist es völlig brauchbar, aber die Generierung ist merklich langsamer als auf GPU oder Apple Silicon. Gut zum Ausprobieren; weniger gut, wenn du den ganzen Tag im Tool lebst.

Eine Dimensionierungstabelle nach Modell

Grobe RAM/VRAM-Werte bei Q4, mit einer Beispielmaschine. Damit passt du ein Modell an Hardware an, die du schon hast oder kaufen willst.

| Modellgröße | RAM/VRAM bei Q4 (grob) | Beispielmaschine | |---|---|---| | ~8B | ~5–8 GB | ein aktueller Laptop oder jede 16-GB-Maschine | | ~14B | ~10–12 GB | eine 16-GB-GPU oder ein 16–32-GB-Mac | | ~27–32B | ~18–24 GB | eine 24-GB-GPU oder ein 32-GB-Mac | | ~70B | ~40 GB+ | ein 64–128-GB-Mac oder mehrere GPUs |

Die Reserve über der reinen Gewichtsgröße ist für Betriebssystem und Kontextfenster. Reale Modelle fügen sich sauber in diese Bänder: Gemma 4 mit seiner 31B-Dense- und 26B-Mixture-of-Experts-Variante und Qwen3.5 mit seinem 27B-Dense liegen in der ~27–32B-Zeile; ihre kleineren Geschwister und Mistrals kleine Modelle der 24B-Klasse decken die leichteren Zeilen ab.

Auch das Kontextfenster kostet Speicher

Die Gewichte sind nicht das Einzige im Speicher. Jeder Token, den du dem Modell gibst, belegt Platz im Kontextfenster: der Cache wächst mit der geladenen Textmenge. Ein langes, komplett hineinkopiertes Dokument kann so viel Zusatzspeicher kosten wie ein Stück des Modells selbst. Das ist der stille Grund, warum „pack einfach alles rein" schlecht skaliert: längerer Kontext heißt mehr RAM und langsamere Antworten.

Der günstigere Zug ist, nur die relevanten Teile abzurufen und dem Modell diese zu geben. Kleinerer Kontext, weniger Speicher, schnellere Antworten. Und nebenbei oft bessere Antworten, denn ein Modell mit dem richtigen Absatz schlägt eines, das in hundert falschen ertrinkt.

Was du für Dokumenten-Fragen wirklich kaufen solltest

Der Sweetspot für Dokumenten-Fragen ist ein quantisiertes ~27–32B-Modell auf einem 32-GB-Mac oder einer 24-GB-GPU. Das gibt dir ein wirklich leistungsfähiges Modell mit Platz für ein gesundes Kontextfenster, auf einer einzelnen Maschine, die du ohne zweite Hypothek kaufst. Sind deine Dokumente überschaubar, reicht ein ~8–14B-Modell auf einer 16-GB-Maschine locker. Die Größe ist beim geerdeten Retrieval seit einer Weile nicht mehr der Engpass; die Retrieval-Qualität zählt mehr. Welches Modell auf diese Hardware gehört, zeigt welches offene Modell für deine Dokumente; die Runtimes, die es bereitstellen, behandelt KI lokal betreiben 2026.

Willst du gar kein Modell selbst betreiben, ist BYOK die andere Tür: richte das Tool auf deinen eigenen API-Schlüssel (dein Anbieter, deine Region, deine Rechnung), und die lokale Hardware-Frage entfällt ganz.

Die Hardware, die du nicht brauchst

Hier ist der Teil, der das Budget verändert. Klassisches RAG braucht eine Vektordatenbank und meist einen Embedding-Server, um sie zu füllen: Infrastruktur, die du aufsetzt, hostest, synchron hältst und bei jeder Dokumentänderung neu einbettest. Das ist echte Hardware und echter Betrieb.

pdf2okf nutzt nichts davon. Es durchsucht OKF-kompatibles Markdown direkt (kein Index zum Hosten, nichts neu einzubetten), und die Struktur lebt im OKFZ-Bundle, nicht in einer Datenbank. Das streicht eine ganze Ebene des Stacks: Du dimensionierst für das Modell und sonst nichts. Betreibe es voll On-Device, wo keine Seite je die Maschine verlässt, oder über deinen eigenen Schlüssel. So oder so bleibt nur die einfache Hardware-Frage, die dieser Artikel beantwortet. (OKF ist Googles offener Standard; pdf2okf ist dazu kompatibel und hat ihn nicht erfunden.)