Wie viel VRAM benötigt ein lokaler Dokumentassistent?

Ein lokaler Dokumentassistent benötigt keinen dedizierten VRAM, wenn die Generierung remote oder auf einem separaten Inferenzserver erfolgt. Bei der Inferenz auf derselben Maschine sind 8 GB ein praxisnaher Einstieg für kleine quantisierte Modelle, während größere Modelle, längere Kontexte und parallele Anfragen den Bedarf deutlich über 16–24 GB hinaus erhöhen können. Bestimmen Sie vor dem Kauf das genaue Modell und den Arbeitskontext, da die RAG-Anwendung selbst den VRAM-Bedarf nicht festlegt.

Entscheiden Sie, ob der Assistent tatsächlich eine lokale GPU benötigt

Ein Dokumentassistent besteht mindestens aus zwei Ebenen: der Anwendung, die Dateien speichert, Texte in Abschnitte unterteilt, Passagen sucht oder abruft und Antworten darstellt; sowie dem Modell-Backend, das die Generierung übernimmt. Diese Ebenen müssen nicht auf derselben Hardware laufen. Ein kompakter Server kann die private Dokumentbibliothek und den Retrieval-Stack hosten, während Modellanfragen an einen anderen lokalen GPU-Rechner oder einen Remote-Anbieter gesendet werden.

Die selbst gehostete Dokumentation von AnythingLLM macht diese Trennung ausdrücklich deutlich, indem die Anwendung eine Verbindung zu Modell- und Embedding-Diensten an anderen Orten herstellen kann. Die Anforderungen für den Selbstbetrieb liegen daher deutlich niedriger als die Hardwareanforderungen eines LLMs auf derselben Maschine.

Wenn die Anforderung lautet „Die Dokumente bleiben auf meinem Server“ und nicht „Jedes Modell-Token muss auf diesem Server generiert werden“, kann der Verzicht auf dedizierten VRAM eine sinnvolle Kaufentscheidung sein. Sie müssen dennoch prüfen, welche Texte die Maschine verlassen, wo Embeddings erzeugt werden, wie das Remote-Modell Anfragen verarbeitet und ob die Datenschutzgrenze zum jeweiligen Anwendungsfall passt.

Die erste Kaufentscheidung ist architektonischer Natur: Bei Remote- oder separater Inferenz bemessen Sie CPU, RAM und Speicher für Retrieval; bei Inferenz auf derselben Maschine wird VRAM zu einer zentralen Einschränkung bei der Modellauswahl.

Modellgewichte bestimmen, bevor Sie den RAG-Overhead hinzurechnen

Die VRAM-Planung beginnt mit dem exakten Modell und der verwendeten Präzision. Gewichte in voller Präzision sind deutlich größer als 8-Bit- oder 4-Bit-Varianten. Deshalb können zwei Nutzer, die sagen „Ich betreibe ein 7B-Modell“, sehr unterschiedliche Speicheranforderungen haben. Quantisierung kann dafür sorgen, dass ein brauchbares kleineres Modell auf gängiger Hardware Platz findet, kann aber auch das Ausgabeverhalten verändern und sollte mit der konkreten Dokumentaufgabe bewertet werden.

Hugging Face dokumentiert, dass Quantisierung Speicher- und Rechenkosten reduziert, indem Gewichte und Aktivierungen mit Datentypen geringerer Präzision dargestellt werden. Außerdem werden gängige 8-Bit- und 4-Bit-Verfahren unterstützt. Damit wird die Präzision zu einer Kaufvariable und nicht nur zu einem Software-Schalter, der nach der Hardwareauswahl aktiviert wird.

Als grobe aktuelle Planungsregel passen 4-Bit-Modelle der 7–8B-Klasse häufig in den Bereich von 6–8 GB, Modelle der 13–14B-Klasse bewegen sich oft in Richtung 10–12 GB, und Modelle der 27–32B-Klasse benötigen vor zusätzlichem Spielraum für den Kontext häufig ungefähr den niedrigen 20-GB-Bereich. Spherons VRAM-Leitfaden aus dem Jahr 2026 nennt ähnliche INT4-Richtwerte und berücksichtigt ausdrücklich zusätzlichen Laufzeit-Overhead über die Schätzung für die Gewichte hinaus.

Kaufen Sie nicht exakt nach der Größe der heruntergeladenen Modelldatei. Lassen Sie Platz für die Laufzeit und den Kontextzustand und überprüfen Sie das tatsächliche Modell in der vorgesehenen Inferenz-Engine. Ein Modell, das mit einem kurzen Test-Prompt geladen wird, kann dennoch fehlschlagen oder auf den Systemspeicher auslagern, wenn der Assistent einen langen abgerufenen Kontext erhält.

Die Kontextlänge kann die VRAM-Klasse verändern, nachdem das Modell bereits passt

Ein Dokumentassistent benötigt häufig mehr Kontext als ein gewöhnlicher Chatbot, da abgerufene Passagen, Zitate, Systemanweisungen, der Gesprächsverlauf und die Nutzerfragen zu einer einzigen Anfrage zusammengeführt werden. Die Modellgewichte bleiben möglicherweise unverändert, während der Key-Value-Cache und andere Anfragezustände mit zunehmender Kontextlänge wachsen.

Ollamas aktuelle Dokumentation zur Kontextlänge macht diesen Zusammenhang sichtbar: Die Standard-Kontextlänge steigt mit dem verfügbaren VRAM – von 4K bei weniger als 24 GiB auf 32K bei 24–48 GiB und auf deutlich höhere Werte ab 48 GiB. Die genauen Standardwerte sind Laufzeitentscheidungen, doch die Lehre für den Kauf lautet: Lange Dokumentkontexte verbrauchen zusätzlich zu den Modellgewichten Speicher.

Reagieren Sie darauf nicht, indem Sie die Kontextlänge wahllos maximieren. Das Retrieval sollte die kleinste Menge an Passagen auswählen, die die Frage beantwortet, während Chunking oder Reranking irrelevanten Text vor der Generierung entfernen sollten. Ein Dokumentassistent, der jedes Dokument in einen einzigen Prompt packen muss, nutzt VRAM als Ausgleich für ein schwaches Retrieval-Design.

Wechseln Sie zur nächsten VRAM-Klasse, wenn das getestete Modell ausreichend genaue Antworten liefert, reale Dokument-Prompts bei der tatsächlich benötigten Kontextlänge jedoch Auslagerungen, Speicherfehler oder eine nicht akzeptable Latenz verursachen. Wenn die Retrieval-Qualität bereits schlecht ist, bevor der Kontext das Modell erreicht, sollten Sie zuerst Index und Ranking verbessern.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Planen Sie Embeddings, Reranking, OCR und parallele Anfragen separat ein

Das lokale LLM ist nicht die einzige Komponente, die GPU-Speicher nutzen kann. Einige Dokumentassistenten beschleunigen zusätzlich Embeddings, Reranker, OCR, Sprachtranskription oder Bildverarbeitungsmodelle auf derselben GPU. Wenn diese Modelle gleichzeitig ausgeführt werden, kann der für die Generierung verfügbare VRAM sinken, obwohl jede Komponente einzeln getestet hineinpasst.

Der ZimaSpace-Artikel zum vollständigen Speicherbedarf von Modellen erklärt, warum Laufzeitpuffer und Anfragezustand zusätzlich zur Checkpoint-Größe berücksichtigt werden müssen. Bei einem Dokumentassistenten erhöhen der abgerufene Kontext und parallel laufende Dienste den Druck auf den gemeinsam genutzten Speicher zusätzlich.

Auch die Anzahl paralleler Anfragen verändert die Antwort. Zwei aktive Nutzer benötigen möglicherweise separate KV-Cache-Zustände, selbst wenn sie dasselbe bereits geladene Modell verwenden. Ein batchorientierter Server kann die Auslastung des Beschleunigers verbessern, lässt den Speicherbedarf pro Anfrage jedoch nicht verschwinden. Messen Sie die längste normale Dokumentanfrage mit der erwarteten Zahl gleichzeitig aktiver Nutzer.

Wenn der Generator die einzige GPU-Arbeitslast ist, können Sie die Hardware näher an seinem getesteten Arbeitsumfang bemessen. Wenn OCR, Embeddings, Reranking und Generierung gleichzeitig laufen müssen, kaufen Sie entweder mehr VRAM, führen Sie ressourcenintensive Schritte nacheinander aus oder verteilen Sie die Dienste auf CPU- und GPU-Ressourcen. Die günstigste Wahl ist diejenige, die die erforderliche Latenz sicherstellt, ohne für ungenutzte Beschleunigung zu bezahlen.

Nutzen Sie VRAM-Klassen zur Vorauswahl von Modellen und testen Sie anschließend die Qualität

Eine sinnvolle Vorauswahl orientiert sich daran, was der Dokumentassistent leisten muss, und nicht am größten passenden Modell. Mit etwa 6–8 GB VRAM sollten Sie mit kleinen 4-Bit-Modellen der 7–8B-Klasse und begrenztem Retrieval beginnen. Bei etwa 12–16 GB erhalten Sie mehr Spielraum für größere Modelle, höhere Präzision oder längere Kontexte. Mit etwa 24 GB werden viele quantisierte Modelle der 27–32B-Klasse mit zusätzlichem Arbeitsbereich praktikabel. Ab ungefähr 40–48 GB und mehr werden 4-Bit-Modelle der 70B-Klasse realistisch, ohne dass umfangreiche Auslagerungen nötig sind.

Der lokale-LLM-Leitfaden von SitePoint aus dem Jahr 2026 weist darauf hin, dass ein 7B-Q4_K_M-Modell bequem in etwa 6 GB VRAM passen kann. Andere aktuelle Bemessungsleitfäden ordnen quantisierte Modelle mit 14B und 32B höher ein. Das bestätigt die Regel, dass die benötigte Klasse vom exakten Checkpoint und nicht von einer allgemeinen Bezeichnung wie „KI-PC“ abhängt.

Erstellen Sie vor dem Kauf der nächsten Klasse einen Testsatz aus Ihren eigenen Dokumenten. Nehmen Sie Fragen auf, die eine exakte Extraktion, die Synthese mehrerer Passagen, eine Verweigerung bei fehlender Quelle sowie gegebenenfalls Tabellen oder strukturierte Texte erfordern, und testen Sie den längsten erwarteten Kontext. Vergleichen Sie Antwortqualität, Zitierverhalten, Latenz bis zum ersten Token, Generierungsgeschwindigkeit und maximalen VRAM-Verbrauch.

Kaufen Sie mehr VRAM, wenn das kleinere Modell scheitert, weil seine Fähigkeiten oder die Kontextkapazität tatsächlich nicht ausreichen. Führen Sie kein Upgrade nur deshalb durch, weil ein größerer Checkpoint existiert. Retrieval kann ein kleineres, schnelleres Modell für eine begrenzte private Wissensbasis nützlicher machen als ein langsameres Modell mit schwacher Quellenbindung.

Halten Sie den Speicher- und Retrieval-Host von der VRAM-Entscheidung getrennt

Ein Dokumentassistent benötigt außerdem dauerhaften Speicher für Originaldateien, extrahierten Text, Indizes, Anwendungsdatenbanken, Protokolle und Backups. Diese Ressourcen beanspruchen in der Regel Systemspeicher und Festplattenkapazität statt GPU-VRAM. Wenn alle Ressourcen in einer einzigen „KI-Speicher“-Zahl zusammengefasst werden, führt das zu falschen Hardwareentscheidungen.

Die ZimaSpace-Übersicht zu einem privaten KI-Assistenten auf einem NAS beschreibt die vorrangige Rolle des lokalen Dateispeichers beim Retrieval. Diese Architektur ermöglicht es, das Speichersystem stabil zu halten, selbst wenn die Inferenzhardware später ausgetauscht wird.

ZimaBoard 2 1664 eignet sich, wenn der kompakte Server für die Dokumentenspeicherung, Indexierung, Anwendungen und Orchestrierung zuständig ist, während das LLM remote oder auf einem separaten GPU-Rechner läuft. Die integrierte Intel-Grafik sollte nicht als dedizierter LLM-VRAM betrachtet werden.

Wählen Sie den Speicher-Host nach Dokumentvolumen, Backup-Anforderungen, Anwendungsspeicher und Netzwerkbedarf. Wählen Sie den Beschleuniger nach dem exakten Modell, der Quantisierung, dem Kontext und der Anzahl paralleler Anfragen. Wenn Sie diese Entscheidungen getrennt halten, können Sie die GPU aufrüsten, ohne den maßgeblichen Dokumentenspeicher neu aufzubauen.

Überprüfen Sie jede GPU-Konfiguration für den Betrieb auf einer einzigen Maschine vor dem Kauf

Wenn Speicher, Retrieval und lokale Generierung in einem Gehäuse laufen sollen, ist der letzte Kaufschritt die Prüfung des tatsächlich für die Laufzeit verfügbaren GPU-Speichers. Produktbezeichnungen wie „KI“, „Creator“ oder „RTX“ geben nicht an, ob das ausgewählte lokale Modell hineinpasst. VRAM, Treiberunterstützung, Containerzugriff, Stromversorgung, Kühlung und physische Erweiterungsmöglichkeiten müssen vollständig überprüft werden.

Das aktuelle ZimaCube 2 Creator Pack ist die Zima-Option, die Sie prüfen sollten, wenn Sie einen Käufer mit Mehrfachschacht-Speicher und einer dedizierten NVIDIA-GPU im selben System beraten. Die aktuelle Produktseite nennt die GPU-Familie, veröffentlicht im Hauptabschnitt der technischen Daten jedoch keine VRAM-Angabe. Ordnen Sie das System daher erst dann einer Modellklasse mit 8 GB, 16 GB, 24 GB oder 48 GB zu, wenn die tatsächlich installierte GPU-Speicherkapazität bestätigt wurde.

Führen Sie vor dem Kauf nach Möglichkeit einen repräsentativen Modelltest durch oder fordern Sie einen solchen an. Erfassen Sie den maximalen VRAM-Verbrauch mit der üblichen Quantisierung und Kontextlänge und wiederholen Sie den Test, während die Embeddings, der Reranker, OCR oder andere GPU-Dienste des Assistenten aktiv sind. Stellen Sie sicher, dass die Laufzeit tatsächlich die vorgesehene GPU verwendet und Layer nicht unbemerkt in den Systemspeicher auslagert.

Die abschließende Regel lautet: Kaufen Sie VRAM für den validierten Arbeitsumfang und nicht für die Marketingkategorie. Verwenden Sie keinen dedizierten VRAM, wenn die Inferenz an anderer Stelle laufen kann; beginnen Sie bei etwa 6–8 GB für kleine quantisierte lokale Modelle; wechseln Sie für größere Modelle oder mehr Spielraum auf 12–16 GB; und ziehen Sie 24 GB oder mehr nur dann in Betracht, wenn der getestete Dokument-Workflow zeigt, dass Modellgröße, Kontext oder parallele Anfragen dies erfordern.

FAQ

Verringert RAG den benötigten VRAM?

RAG kann es einem kleineren Modell ermöglichen, Antworten anhand abgerufener Belege zu erstellen, statt auf das interne Wissen eines größeren Modells angewiesen zu sein. Dadurch kann sich die erforderliche Modellklasse reduzieren. Abgerufene Passagen beanspruchen jedoch weiterhin Kontextspeicher. Ein schlechtes Retrieval, das übermäßig viel Text sendet, kann den VRAM-Druck daher erhöhen.

Benötigen Embeddings genauso viel VRAM wie das Chatmodell?

Nein. Embedding-Modelle haben ihren eigenen CPU-, RAM- oder GPU-Bedarf und können auf der CPU oder als separater Dienst laufen. Wenn Embeddings und Generierung dieselbe GPU verwenden, messen Sie den gemeinsamen Spitzenverbrauch, statt die Größen der Modelldateien lediglich auf dem Papier zu addieren.