Ein RAG-System auf eigener Hardware lässt sich 2026 aus offenen Standardbausteinen aufbauen. Sprachmodelle mit 14 bis 35 Milliarden Parametern beantworten Fragen zu internen Dokumenten gut genug für den Arbeitsalltag, und für einen abgegrenzten Anwendungsfall reicht oft ein einzelner GPU-Server. Die Schwierigkeiten liegen an anderer Stelle: in der Aufbereitung der Dokumente, in Berechtigungen, die bis in den Suchindex reichen müssen, und in einem Betrieb, der Qualität misst.
Welche Bausteine ein lokales RAG-System braucht, wie man Modell und Hardware dimensioniert und woran On-Premise-Projekte in der Praxis scheitern.
Ein Cloud-Dienst ist schneller aufgesetzt. Der lokale Betrieb lohnt sich, wenn mindestens einer der folgenden Gründe zutrifft und die Voraussetzungen erfüllt sind. Fehlen die Voraussetzungen, scheitert das Projekt in der Cloud genauso.
Ein RAG-System hat zwei Pfade. Die Indexierung bereitet Dokumente auf und legt sie durchsuchbar ab. Die Anfrage holt die passenden Abschnitte und lässt das Sprachmodell daraus eine Antwort mit Quellenangaben formulieren. Für jeden Baustein gibt es lokal betreibbare Open-Source-Werkzeuge; die Tabelle nennt verbreitete Beispiele.
| Baustein | Aufgabe | Lokale Optionen (Auswahl) | Typische Stolperstelle |
|---|---|---|---|
| Parsen und OCR | Text und Struktur aus PDF, Office-Dateien und Mails gewinnen | Docling, Apache Tika, Tesseract | Tabellen und Scans verlieren ihre Struktur. Der Fehler zeigt sich erst später als schlechte Antwort. |
| Chunking | Dokumente in abrufbare Abschnitte teilen | Strukturbewusster Schnitt an Überschriften und Absätzen | Feste Fenster zerschneiden Tabellen, Aufzählungen und Definitionen. |
| Embedding | Abschnitte als Vektoren abbilden | Mehrsprachige Modelle wie BGE-M3 oder multilingual-e5 | Überwiegend englisch trainierte Modelle tun sich mit deutschen Komposita und Fachbegriffen schwer. |
| Index | Vektor- und Volltextsuche mit Metadaten | PostgreSQL mit pgvector, Qdrant, OpenSearch | Zugriffsrechte fehlen als Metadaten. Sie nachzurüsten ist ein Umbau. |
| Reranker | Kandidaten genauer sortieren | Cross-Encoder wie bge-reranker | Fehlt häufig. Dann landen mittelmäßige Treffer im Kontext. |
| Sprachmodell und Serving | Antwort aus Frage und Kontext erzeugen | vLLM, llama.cpp, Ollama, jeweils mit OpenAI-kompatibler Schnittstelle | Das Entwicklungs-Setup geht unverändert in den Mehrbenutzerbetrieb. |
| Tracing und Evaluation | Jede Antwort zurückverfolgen und Qualität messen | Langfuse (selbst gehostet), eigenes Logging, Goldset | Wird erst nach der ersten Beschwerde eingebaut. |
Die wichtigste Entscheidung für spätere Wechsel ist die OpenAI-kompatible Schnittstelle zum Modellserver. Die Anwendung ruft den lokalen Modellserver so auf wie einen externen Dienst, nur zeigt die Adresse ins eigene Netz. Der Umzug vom Entwicklungsrechner auf den GPU-Server ändert dann im Wesentlichen die Adresse. Die kompatible Schnittstelle senkt den Integrationsaufwand; ein Modellwechsel bleibt trotzdem ein Release: Chat-Template, unterstützte Parameter und das Antwortverhalten des neuen Modells können Anpassungen an Prompts und Aufrufen verlangen, und das Goldset läuft in jedem Fall neu (siehe Betrieb).
In einem RAG-System hat das Sprachmodell eine klar umrissene Aufgabe: aus dem mitgelieferten Kontext korrekt zusammenfassen, Quellen zitieren und ablehnen, wenn die Antwort darin fehlt. Eigenes Weltwissen braucht es dafür kaum. Deshalb kommen die meisten Anwendungsfälle ohne die ganz großen Modelle aus.
| Modellklasse | Grafikspeicher für die Gewichte bei 4 Bit (grobe Planungswerte) | Geeignet für |
|---|---|---|
| Klein, 1 bis 4 Mrd. Parameter | etwa 1 bis 3 GB | Klassifikation, Routing, einfache Extraktion |
| Mittel, 7 bis 14 Mrd. Parameter | etwa 5 bis 10 GB | Eng umrissene Fälle: Fragen zu kurzen, gut strukturierten Dokumenten, strukturierte Extraktion. Für deutsche Texte nach meiner Erfahrung eher das obere Ende der Klasse. |
| Groß, 24 bis 35 Mrd. Parameter: dicht wie Qwen3-32B, Qwen3.8-27B oder Gemma 4 31B, MoE wie Qwen3.6-35B-A3B oder Gemma 4 26B A4B | etwa 15 bis 22 GB | Nach meiner Erfahrung der Ausgangspunkt für produktives RAG auf anspruchsvolleren deutschen Beständen: Synthese über mehrere Treffer, lange Kontexte, Tabellen, Zitieren und Ablehnen. Ob das genügt, zeigt die Evaluation am eigenen Bestand |
| Sehr groß: dicht ab 70 Mrd. Parameter wie Llama 3.3 70B, große MoE wie gpt-oss-120b | ab etwa 40 GB, gpt-oss-120b etwa 60 bis 80 GB | In RAG selten nötig; eher für Agenten mit Werkzeugen und mehrstufiges Schlussfolgern |
Die Werte sind grobe Planungswerte für die geladenen Modellgewichte. Rein rechnerisch belegen 14 Milliarden Parameter bei vier Bit etwa 7 GB; dazu kommen Quantisierungsmetadaten und einzelne Tensoren, die in höherer Präzision bleiben, deshalb liegen die Angaben in der Tabelle darüber. Die 4-Bit-Quantisierung senkt den Speicherbedarf gegenüber 16 Bit auf etwa ein Viertel, mit einem Qualitätsverlust, der von Modell und Aufgabe abhängt und am eigenen Goldset zu prüfen ist. Nicht enthalten sind der Laufzeitbedarf des Modellservers und der KV-Cache, der mit der Kontextlänge und der Zahl gleichzeitiger Anfragen wächst. Wer zehn Nutzern gleichzeitig je 16.000 Token Kontext geben will, muss den Cache mit einrechnen. Sonst reicht die Karte im Test, im Betrieb aber nicht mehr.
Die Größenangaben sind Erfahrungswerte, keine technischen Grenzen. Nach meiner Erfahrung beginnt produktives RAG auf deutschen Dokumenten bei etwa 14 Milliarden Parametern; ab 24 bis 35 Milliarden werden Zitieren, Ablehnen und die Synthese über mehrere Treffer spürbar robuster. Ob ein kleineres Modell für den eigenen Fall genügt, entscheidet die Evaluation am eigenen Bestand, nicht die Parameterzahl. Mixture-of-Experts-Modelle verschieben die Rechnung: Bei Qwen3.6-35B-A3B und Gemma 4 26B A4B rechnen pro Token nur 3 bis 4 Milliarden Parameter, die Gewichte passen quantisiert mit 15 bis 22 GB auf eine 24- oder 32-GB-Karte, und das Antworttempo liegt nahe an dem eines kleinen dichten Modells. gpt-oss-120b (117 Milliarden gesamt, 5,1 Milliarden aktiv) läuft auf einer einzelnen 80-GB-Karte. Der Unterschied zwischen mittel und groß ist damit eine Grafikkarte, kein Cluster. Wie viel Speicher, Durchsatz und Latenz der eigene Fall braucht, messen Teams in der LLM- und RAG-Schulung am eigenen Modellserver nach.
Größer heißt dabei nicht treuer zur Quelle. Auf dem Hallucination Leaderboard von Vectara, das misst, wie oft Zusammenfassungen vom Ausgangsdokument abweichen, liegt gpt-oss-120b bei rund 14 Prozent, Gemma 4 26B A4B bei 5, Qwen3-14B bei 5, Qwen3-32B bei 6 und Llama 3.3 70B bei 4 Prozent (Stand Mai 2026). Die neuere Generation Qwen 3.5 liegt dort bei 10 bis 12 Prozent, also hinter den älteren Qwen3-Modellen; für Qwen 3.6 und 3.8 gibt es noch keine Werte. Die Zahlen sind mit Vorsicht zu lesen: Der Benchmark bewertet englische Zusammenfassungen einzelner Dokumente, kein vollständiges RAG-System auf deutschen Beständen mit mehreren Treffern, und er sagt nichts darüber, ob ein Modell zuverlässig zitiert oder korrekt ablehnt. Was er zeigt: Die Treue zur Quelle hängt mehr an Modellfamilie und Training als an der Parameterzahl, und genau diese Treue zählt in RAG.
Die meisten schlechten RAG-Antworten haben ihre Ursache vor dem Sprachmodell: Der passende Abschnitt war nicht unter den Treffern. Ein größeres Modell ändert daran nichts. Drei Maßnahmen bringen in Projekten am meisten.
Die Suche wird getrennt von der Antwort gemessen: Welcher Anteil der relevanten Abschnitte steht unter den ersten k Treffern (Recall@k), und wie weit oben stehen sie (nDCG)? Hat eine Frage nur einen relevanten Abschnitt, reduziert sich Recall@k auf die Frage, ob er unter den ersten k ist (Hit@k). Erst wenn diese Werte stimmen, lohnt sich die Arbeit am Prompt.
Auf eigener Hardware entfällt die Übermittlung an den Modellanbieter, aber nicht von selbst jede Übermittlung nach außen. Jeder Baustein wird einzeln geprüft: OCR-Dienste, Embedding-Schnittstellen, ein Bewertermodell in der Evaluation, die Telemetrie von Frameworks und Werkzeuge, die der Assistent aufruft, können Inhalte nach außen senden. Dazu kommen die internen Fragen, und ein Index, der alles durchsuchbar macht, verschärft sie.
Als Arbeitsannahme gilt in jedem Projekt: Solange nicht das Gegenteil gezeigt ist, enthalten die Dokumente personenbezogene Daten. Die rechtliche Bewertung im Einzelfall ist Sache von Datenschutzbeauftragten und Rechtsberatung; die Architektur schafft die technischen Voraussetzungen, damit deren Vorgaben umsetzbar sind.
Ein RAG-System verändert sich, ohne dass jemand Code anfasst: Dokumente kommen hinzu, Fassungen veralten, ein Modell-Update ändert das Antwortverhalten. Ohne Messung fällt das erst über Beschwerden auf.
Goldset, Metriken für Suche und Antwort und den Regressionslauf vor jedem Release baut die LLM- und RAG-Schulung gemeinsam mit dem Team auf dessen eigenem Stack auf.
| Phase | Typische Dauer | Inhalt |
|---|---|---|
| Pilot | 4 bis 8 Wochen | Ein Anwendungsfall, zwei bis drei Datenquellen, Goldset mit 50 bis 200 Fragen, vorab festgelegte Kriterien für die Entscheidung über den Rollout |
| Produktiver Rollout | 3 bis 6 Monate | Berechtigungen, Protokollierung, Evaluation im Betrieb, Feedback-Schleife, Schulung der Nutzer |
| Laufender Betrieb | dauerhaft | Neuindexierung, Messung bei jedem Modellwechsel, Pflege des Goldsets |
Den größten Posten bilden in fast jedem Projekt die Aufbereitung der Dokumente und die Klärung der Rechte. Modellserver und Index sind vergleichsweise schnell eingerichtet. Als Einstieg eignet sich ein Assistent, der sucht, zusammenfasst und belegt, mit einem Menschen, der die Antwort prüft. Ungeeignet für den Anfang sind Anwendungen, die selbst entscheiden, Personen bewerten oder ungeprüft an Kunden schreiben.
RAG on-premise ist heute vor allem eine Frage der Daten und des Betriebs. Modell und Hardware sind die kleinere Aufgabe: Die Klasse von 24 bis 35 Milliarden Parametern ist nach meiner Erfahrung für die meisten Fälle der passende Ausgangspunkt und läuft auf einer einzelnen Grafikkarte; ob sie für den eigenen Bestand reicht, zeigt das Goldset. Teure Umbauten vermeidet, wer drei Dinge früh festlegt: Zugriffsrechte als Metadaten im Index, ein Goldset aus realen Fragen und eine OpenAI-kompatible Schnittstelle zum Modell.
Den Stack auf eigener Hardware aufbauen und messen: LLM- und RAG-Schulung (On-Premise-Lab) · Klären, ob die Datenplattform den Anwendungsfall trägt: KI-Readiness-Assessment · In den Betrieb bringen: LLMOps-Workshop
Dr.-Ing. Grigory Devadze baut RAG- und Agenten-Systeme in Beratungsprojekten, darunter lokal betriebene, und schult Entwicklerteams im Einsatz von LLMs und MLOps. Profil · LinkedIn · Alle Artikel
Dr.-Ing. Grigory