Die wichtigsten Rag System Requirements für erfolgreiche Implementierungen

Betriebssicherheit durch ausreichenden Speicherplatz

Für einen stabilen Betrieb des NVIDIA RAG Blueprint sollten mindestens 200 GB freier Speicherplatz eingeplant werden. Diese Größe ist kein Komfortwert, sondern eine praktische Untergrenze für Modell-Downloads, Container, Indizes, Protokolle und temporäre Dateien.

Der größte Anteil entfällt meist auf den Modell-Cache. Dafür können etwa 100 bis 150 GB anfallen. Container-Images benötigen zusätzlich ungefähr 20 bis 30 GB. Der verbleibende Platz wird von der Vektordatenbank, Suchindizes, Uploads und Laufzeitdaten genutzt. Bei wachsenden Dokumentbeständen steigt dieser Bedarf weiter. Entscheidend ist außerdem der freie Platz während eines Updates: Neue Modellversionen werden häufig zunächst vollständig geladen, bevor alte Dateien gelöscht werden. Wer das Laufwerk zu knapp bemisst, riskiert abgebrochene Downloads, fehlerhafte Containerstarts oder einen Ausfall der Indexierung.

200 GB freien Speicher als Mindestwert bereitstellen
Modell-Cache und Container auf einem schnellen SSD- oder NVMe-Laufwerk ablegen
Zusätzliche Reserve für neue Modelle, Indizes und temporäre Dateien einplanen
Wachstum von Dokumentbestand und Protokollen regelmäßig überwachen
Aufbewahrungsregeln für alte Images, Caches und Logs festlegen

Für produktive Umgebungen ist eine Reserve von etwa 20 bis 30 Prozent sinnvoll. Ein Alarm bei 70 bis 80 Prozent Belegung gibt dem Betriebsteam noch Zeit zum Handeln.

Betriebssystem sowie Treiber und CUDA korrekt vorbereiten

Der NVIDIA RAG Blueprint setzt Ubuntu 22.04 als Betriebssystem voraus. Für eine verlässliche Ausführung müssen außerdem der NVIDIA-Treiber und die CUDA-Laufzeit zusammenpassen. Vorgesehen sind mindestens Treiber-Version 560 sowie CUDA 12.9.

Diese Werte sollten vor der Installation geprüft werden. Ein neueres CUDA-Toolkit allein genügt nicht, wenn der installierte Treiber die benötigte CUDA-Version nicht unterstützt. Umgekehrt kann ein passender Treiber durch alte Bibliotheken oder fehlerhafte Container-Konfigurationen ausgebremst werden.

Prüfen Sie auf dem Zielsystem zuerst die erkannte GPU und die Treiberversion. Der Befehl nvidia-smi zeigt, ob der Treiber aktiv ist und welche CUDA-Kompatibilität der Host meldet. Die eigentliche Anwendung läuft danach in Containern; deshalb müssen auch die NVIDIA-Container-Runtime und deren GPU-Zugriff korrekt eingerichtet sein.

Ubuntu 22.04 als unterstützte Basis installieren
NVIDIA-Treiber 560 oder höher verwenden
CUDA 12.9 oder höher mit der Treiberversion abgleichen
GPU-Erkennung mit nvidia-smi testen
NVIDIA Container Toolkit vor dem Blueprint-Deployment prüfen
Kernel-Updates und Treiberänderungen zuerst in einer Testumgebung ausführen

Bei Kubernetes muss jeder GPU-Worker den passenden Treiber bereitstellen, und die Cluster-Komponenten müssen die GPU als Ressource erkennen. Ein kurzer Funktionstest auf jedem vorgesehenen Worker verhindert, dass ein einzelner falsch vorbereiteter Knoten zum Engpass wird.

Übersicht der zentralen Anforderungen für eine stabile RAG-Implementierung

Bereich	Anforderung	Empfehlung	Risiko bei Unterdimensionierung
Speicherplatz	Mindestens 200 GB freier Speicher	20 bis 30 Prozent zusätzliche Reserve einplanen	Abgebrochene Downloads, fehlerhafte Containerstarts und fehlgeschlagene Indexierung
Modell-Cache	Etwa 100 bis 150 GB	Auf einem schnellen SSD- oder NVMe-Laufwerk speichern	Verzögerte Modellstarts und Engpässe bei Updates
Container	Etwa 20 bis 30 GB	Alte Images regelmäßig bereinigen	Volllaufende Laufwerke und fehlgeschlagene Deployments
Betriebssystem	Ubuntu 22.04	Kernel- und Systemupdates zunächst in einer Testumgebung prüfen	Inkompatibilitäten mit Treibern oder Container-Komponenten
NVIDIA-Treiber und CUDA	Treiber 560 oder höher sowie CUDA 12.9 oder höher	Versionen auf Host, Runtime und Containern abgleichen	GPU wird nicht erkannt oder Anwendungen starten nicht
Docker-Bereitstellung	3 H100, 3 B200 oder 3 RTX PRO 6000	GPU-Durchreichung mit einem Testcontainer verifizieren	Unzureichende Inferenzleistung und Ressourcen-Engpässe
Kubernetes	8 H100 mit 80 GB, 8 B200 oder 8 RTX PRO 6000	GPU-Topologie, Node-Platzierung und Ressourcenlimits planen	Fehlende Ressourcen für parallele Dienste und Replikate
MIG-Alternative	5 H100 mit 80 GB und aktivierter MIG-Unterstützung	Instanzgrößen an Modell, Batch-Größe und Kontextlänge anpassen	Warteschlangen, knapper GPU-Speicher und schwankende Latenzen
Optionale GPU-Dienste	Richtwert: eine zusätzliche GPU je aktiviertem Dienst	VLM-, Captioning-, Parser- und Audio-Lasten separat testen	Engpässe bei Spitzenlasten und längere Antwortzeiten
Self-Hosting einzelner Microservices	Eine NVIDIA L40 oder vergleichbare GPU	GPU-Bedarf je Pipeline-Komponente messen	Unzureichender Durchsatz bei Embedding, Retrieval oder Reranking
Vektordatenbank	Elasticsearch ohne GPU oder Milvus optional GPU-beschleunigt	Vektordimension, Indexgröße, Suchlast und Latenzziel berücksichtigen	Hoher Speicherbedarf, langsame Suche oder verzögerte Indexierung
Cloud-API	Lite-Modus ohne lokale GPU möglich	Datenschutz, Netzqualität, Rate Limits und laufende Kosten prüfen	Abhängigkeit von Netzwerk und Anbieter sowie unerwartete Kosten
Monitoring	Überwachung von Speicher, GPU, CPU, RAM, Logs und Antwortzeiten	Alarme ab etwa 70 bis 80 Prozent Speicherauslastung einrichten	Probleme werden erst nach Ausfällen erkannt
Abnahmetest	Referenzdokumente, Lasttests und Wiederherstellungsszenarien	Normalbetrieb, Spitzenlast und Knotenausfall simulieren	Fehler treten erst im Produktivbetrieb auf

Docker-Bereitstellung mit lokaler GPU planen

Bei der Docker-Bereitstellung mit lokal betriebenen NIM-Microservices muss die GPU-Konfiguration zur Standardlast passen. Das Standard-LLM Nemotron 3 Super 120B A12B benötigt im FP8-TP2-Modus zwei GPUs. Für das vollständige Blueprint-Setup sind dafür 3 × NVIDIA H100, 3 × NVIDIA B200 oder 3 × NVIDIA RTX PRO 6000 vorgesehen.

Die dritte GPU schafft Ressourcen für weitere Pipeline-Bestandteile und verhindert, dass Inferenz, Embeddings oder andere Dienste um dieselben Rechenkapazitäten ringen. Vor dem Start muss Docker die GPUs an die Container durchreichen. Dazu gehören eine funktionsfähige NVIDIA-Container-Runtime, korrekt gesetzte Gerätefreigaben und ausreichend gemeinsam nutzbarer Hauptspeicher.

3 × H100, 3 × B200 oder 3 × RTX PRO 6000 für die Standardkonfiguration einplanen
Den FP8-TP2-Modus und die dafür nötige GPU-Verteilung prüfen
GPU-Zugriff innerhalb eines Docker-Testcontainers verifizieren
CPU, RAM und PCIe-Anbindung nicht als Nebensache behandeln
GPU-Auslastung, Speicherdruck und Antwortzeiten im Betrieb überwachen

Für kleinere Tests ist auch ein anderer Betriebsweg möglich: NVIDIA-gehostete NIM-Microservices entlasten die lokale Hardware. Im containerlosen Lite-Modus kann die Verarbeitung ohne lokale GPU über NVIDIA Cloud APIs erfolgen. Dafür müssen Netzwerkzugriff, Zugangsdaten, Datenfluss und laufende API-Kosten vorab geklärt werden. Das ist praktisch, aber nicht automatisch die richtige Wahl für vertrauliche oder stark regulierte Inhalte.

Kubernetes-Cluster mit dem passenden GPU-Ausbau dimensionieren

Für das Standard-Helm-Chart sollten Kubernetes-Betreiber einen Cluster mit 8 × H100 mit 80 GB, 8 × B200 oder 8 × RTX PRO 6000 einplanen. Mit aktivierter Multi-Instance GPU (MIG) kann auch eine Konfiguration mit 5 × H100 mit 80 GB ausreichen.

Neben der GPU-Anzahl ist ihre Verteilung auf Worker-Knoten entscheidend. Verlangt ein Dienst mehrere GPUs für parallele Inferenz, müssen diese Ressourcen auf demselben Knoten verfügbar sein. Ebenso muss der Cluster Modellstarts, Datenaufnahme, Suchanfragen und Nebenprozesse gleichzeitig tragen. Besonders bei mehreren Replikaten steigt der Bedarf an CPU und RAM deutlich.

8 × H100 80 GB, 8 × B200 oder 8 × RTX PRO 6000 als Standardausbau prüfen
Alternativ 5 × H100 80 GB mit MIG bewerten
GPU-Topologie und Platzierung per Node bewusst planen
CPU- und RAM-Reserven für Datenaufnahme und parallele Anfragen vorsehen
GPU-Ressourcen über passende Kubernetes-Requests und -Limits reservieren
Autoscaling nur einsetzen, wenn zusätzliche GPU-Kapazität tatsächlich verfügbar ist

Optionale GPU-Dienste erhöhen den Bedarf. Als grober Richtwert gilt eine zusätzliche GPU je aktiviertem Dienst, etwa für VLM-Generierung, Bild-Captioning, VLM-Reranking, Nemotron Parse oder Audioverarbeitung. MIG und andere kontrollierte GPU-Sharing-Verfahren können diese Zusatzlast bündeln, sofern Speicherbedarf, Parallelität und Latenzziel zusammenpassen.

Zusätzliche GPU-Dienste und MIG-Ressourcen einplanen

Optionale GPU-Dienste sollten von Anfang an in die Kapazitätsplanung einfließen. Dazu zählen VLM-Generierung, Bild-Captioning, VLM-Reranking, Nemotron Parse und Audioverarbeitung. Als belastbarer Richtwert gilt: pro aktiviertem GPU-Dienst eine zusätzliche GPU.

Die tatsächliche Last hängt von Dokumenttyp, Anfragevolumen, Modellgröße und gewünschter Antwortzeit ab. Ein Captioning-Dienst kann bei vielen Bildern zum Engpass werden, während ein selten genutzter Parser deutlich weniger Druck erzeugt. Deshalb sollten Spitzenlasten und nicht nur Durchschnittswerte zählen.

MIG teilt eine kompatible GPU in getrennte Instanzen. Jede Instanz erhält fest zugewiesene Rechen- und Speicherressourcen. Dadurch lassen sich kleinere Dienste voneinander isolieren und besser auslasten. Für das Standard-Helm-Chart kann eine Konfiguration mit 5 × H100 mit 80 GB und MIG ausreichen.

GPU-Dienste nach Anfragevolumen und Latenzziel bewerten
Für jeden aktivierten optionalen Dienst zunächst eine zusätzliche GPU kalkulieren
MIG nur bei kompatiblen Workloads und klaren Speicherprofilen einsetzen
Instanzgrößen an Modell, Batch-Größe und Kontextlänge anpassen
Freie Kapazität für Lastspitzen und Neustarts reservieren
Geteilte GPUs nicht ohne Ressourcenlimits betreiben

MIG reduziert den Hardwarebedarf, ersetzt aber keine Lastmessung. Zu kleine Instanzen führen zu Warteschlangen, knapperem GPU-Speicher und schwankenden Antwortzeiten. Vor dem Produktivbetrieb sollte jeder Dienst mit realistischen Bild-, Audio- und Dokumentmengen getestet werden. Erst dann zeigt sich, ob die Aufteilung trägt oder ob eine dedizierte GPU die sauberere Lösung ist.

Self-Hosting einzelner NIM-Microservices auslegen

Beim Self-Hosting einzelner NIM-Microservices genügt für den Pipeline-Betrieb meist eine NVIDIA L40 oder eine vergleichbare GPU. Diese Variante eignet sich, wenn nur ausgewählte Komponenten lokal laufen sollen und das vollständige Blueprint-Setup nicht benötigt wird.

Eine GPU wird besonders dann relevant, wenn Milvus mit GPU-Beschleunigung als Vektordatenbank eingesetzt wird. Die Hardware übernimmt dabei rechenintensive Aufgaben bei Suche und Indexierung. Ohne diese Beschleunigung kann Milvus auch anders dimensioniert werden, doch die Antwortzeit hängt dann stärker von CPU, RAM und Datenmenge ab.

Die standardmäßig verwendete Elasticsearch-Vektordatenbank benötigt keine GPU. Wird jedoch ein anderes Vektor-Backend gewählt oder die GPU-Beschleunigung für Elasticsearch aktiviert, müssen die jeweiligen Anforderungen des Backends separat geprüft werden.

1 × NVIDIA L40 oder eine vergleichbare GPU für den Pipeline-Betrieb vorsehen
GPU-Bedarf von Embedding-, Retrieval- und Reranking-Diensten getrennt bewerten
Milvus nur mit GPU-Beschleunigung betreiben, wenn der Suchdurchsatz dies rechtfertigt
Elasticsearch ohne GPU als ressourcenschonende Standardoption berücksichtigen
Bei einem Backend-Wechsel Speicherbedarf, Indexgröße und Parallelität neu kalkulieren

Für eine belastbare Entscheidung sollten drei Messwerte im Vordergrund stehen: Abfragen pro Sekunde, Suchlatenz und Indexierungsdauer. Kleine Lasttests mit dem vorgesehenen Dokumentbestand zeigen, ob eine einzelne L40 ausreicht oder ob eine stärkere beziehungsweise zusätzliche GPU nötig wird.

Vektordatenbank und GPU-Beschleunigung passend auswählen

Die Wahl der Vektordatenbank beeinflusst Antwortzeit, Indexierung und Betriebsaufwand. Für den NVIDIA RAG Blueprint ist Elasticsearch die Standardoption. Sie benötigt für die Vektorsuche keine GPU und passt daher zu Umgebungen, in denen Suchfunktionen, Filter und bestehende Elasticsearch-Strukturen zusammengeführt werden sollen.

Milvus kann ebenfalls eingesetzt werden. Eine GPU ist dabei besonders dann sinnvoll, wenn die Vektordatenbank GPU-beschleunigte Indexierung oder Suche nutzt. Das lohnt sich vor allem bei großen Vektormengen, vielen parallelen Abfragen oder einem engen Latenzziel. Bei kleinen Datenbeständen bringt die zusätzliche Beschleunigung dagegen oft wenig.

Vor der Auswahl sollten die Eigenschaften des Datenbestands feststehen: Anzahl der Vektoren, Dimension des Embeddings, Aktualisierungsrate und Filterlogik. Ein Vektor mit 1.536 Dimensionen benötigt bei 32-Bit-Gleitkommazahlen allein rund 6 KB Rohdaten. Bei zehn Millionen Vektoren sind das bereits etwa 60 GB, noch ohne Index, Replikate und Metadaten. Niedrigere Präzision kann Platz sparen, muss aber gegen die Trefferqualität geprüft werden.

Elasticsearch wählen, wenn keine GPU für die Vektorsuche vorgesehen ist
Milvus mit GPU-Beschleunigung bei großen Suchlasten und kurzen Latenzzielen bewerten
Vektordimension, Präzision und Indexverfahren gemeinsam kalkulieren
Replikate, Metadaten und Wiederherstellungsreserven in die Kapazitätsplanung aufnehmen
Filterabfragen und hybride Suche mit realen Dokumenten testen
Trefferqualität nicht zugunsten reiner Geschwindigkeit opfern

Bei einem geänderten Vektor-Backend gelten dessen eigene Anforderungen. Das betrifft etwa kompatible Versionen, Indexformate, Speicherbedarf und verfügbare Treiber. Eine GPU-Beschleunigung muss im Lasttest einen messbaren Vorteil bei Durchsatz oder Latenz liefern. Andernfalls ist die einfachere CPU-basierte Architektur oft der klügere Weg.

Cloud-APIs als Alternative zu lokaler Hardware nutzen

Cloud-APIs ermöglichen den Betrieb des NVIDIA RAG Blueprint, ohne die Inferenz-Hardware selbst bereitzustellen. Im Lite-Modus erfolgt die Verarbeitung über NVIDIA Cloud APIs. Das eignet sich besonders für Machbarkeitsstudien, wechselnde Lasten und Teams, die keine GPU-Infrastruktur betreiben möchten.

Der wichtigste Unterschied liegt im Datenweg: Dokumente oder daraus erzeugte Inhalte verlassen dabei die eigene Umgebung. Vor dem Einsatz müssen deshalb Datenklassifizierung, Auftragsverarbeitung, Speicherfristen und mögliche Standortvorgaben geklärt werden. Für personenbezogene, vertrauliche oder exportbeschränkte Daten ist eine Cloud-Anbindung nicht automatisch zulässig.

Auch die Netzwerkanbindung wird zum Systembestandteil. Für stabile Antworten braucht die Anwendung eine geringe Latenz, ausreichend Upload-Bandbreite und eine definierte Ausweichstrategie bei API-Fehlern. Zeitüberschreitungen, Rate Limits und kurzfristige Dienstunterbrechungen sollten technisch abgefangen werden, etwa durch Wiederholungen mit Obergrenze und eine kontrollierte Fehlermeldung.

API-Zugang, Schlüsselverwaltung und Rollen vor dem Testbetrieb einrichten
Übertragene Inhalte auf Schutzbedarf und zulässige Verarbeitung prüfen
Region, Aufbewahrung und Nutzungsbedingungen des API-Dienstes dokumentieren
Monatliche Kosten anhand von Token-, Anfrage- und Speicherverbrauch kalkulieren
Rate Limits, Zeitüberschreitungen und Ausfälle in einem Test simulieren
Eine Abschalt- oder Wechseloption für steigende Kosten vorsehen

Für produktive Systeme lohnt sich ein kontrollierter Vergleich zwischen Cloud- und Eigenbetrieb. Gemessen werden sollten Antwortzeit, Übertragungskosten, Fehlerrate und Kosten je Anfrage. So wird sichtbar, ob die flexible API-Nutzung wirtschaftlich bleibt oder ob ein lokaler Betrieb bei gleichmäßiger Last langfristig besser passt.

Fazit: Systemanforderungen vor der Implementierung prüfen

Eine erfolgreiche Implementierung beginnt mit einem reproduzierbaren Abnahmetest. Prüfen Sie die Umgebung nicht nur auf den Start des Deployments, sondern auf den gesamten Ablauf: Dokumentaufnahme, Indexaufbau, Anfrageverarbeitung, Fehlerbehandlung und Wiederanlauf nach einem Neustart.

Alle benötigten Dienste und Schnittstellen in einer festen Versionsmatrix dokumentieren
Ein kleines Referenz-Dokumentpaket für Installations- und Regressionstests definieren
Messbare Ziele für Antwortzeit, Durchsatz und Verfügbarkeit festlegen
Wiederherstellung aus Sicherungen praktisch testen, nicht nur theoretisch planen
Änderungen an Modellen, Images und Konfigurationen nachvollziehbar protokollieren
Ein Rollback-Verfahren vor dem ersten Produktiveinsatz verifizieren

Besonders wichtig ist die Trennung von Minimalanforderung und Produktionsreserve. Ein System kann die technische Untergrenze erfüllen und trotzdem bei Spitzenlast, Wartung oder parallelen Deployments versagen. Die Kapazitätsplanung sollte daher drei Szenarien abbilden: Normalbetrieb, erwartete Spitzenlast und Ausfall eines relevanten Knotens.

Die Abnahme ist erst abgeschlossen, wenn die RAG-Pipeline unter realistischen Bedingungen verlässlich arbeitet. Dazu gehören unterschiedliche Dokumentformate, unvollständige Eingaben und mehrere gleichzeitige Nutzer. Wer diese Prüfung vor dem Go-live durchführt, entdeckt Fehlstellen dort, wo sie noch günstig zu beheben sind.