GPU-Server für RAG und Firmen-Chatbot: Was ist neben der Grafikkarte wichtig?

Ein eigener Fehler ist die Annahme, dass ein größeres Modell eine schlechte Wissensbasis ausgleichen kann. Bei RAG hängt die Antwortqualität oft stärker von Dokumenten, Fragmentierung, Suche und Datenaktualität ab als von der Modellgröße.

Ein GPU-Server für RAG und einen Unternehmens-Chatbot sollte nicht nur nach der Grafikkarte ausgewählt werden: Entscheidend sind auch der Umfang des Videospeichers, die Geschwindigkeit des Modells, CPU, RAM, NVMe-Laufwerke, die Vektordatenbank, die Art der Dokumentenspeicherung, Netzwerk, Zugriffsrechte, Monitoring und Sicherheit. Für einen Pilotbetrieb reichen häufig eine Server-GPU, schneller NVMe-Speicher und ein klares Schema zur Dokumentenindizierung aus. Für ein Production-Szenario, in dem mehrere Abteilungen des Unternehmens den Chatbot nutzen, die Wissensbasis regelmäßig aktualisiert wird und Daten nicht an externe Dienste gesendet werden dürfen, braucht es bereits eine vollständige Architektur mit Redundanz, Protokollierung und Skalierungsplan.

Ein Unternehmens-Chatbot auf Basis von RAG antwortet nicht „aus dem Kopf“. Er erhält eine Nutzerfrage, sucht relevante Fragmente in internen Dokumenten, übergibt sie an das Sprachmodell und erzeugt eine Antwort auf Basis des gefundenen Kontexts. Deshalb muss der Server nicht nur das Modell ausführen, sondern auch Dokumente schnell durchsuchen, Berechtigungen prüfen, Indizes speichern, neue Dateien verarbeiten und gleichzeitige Anfragen bewältigen.

Wenn ein Server nur nach dem Namen der GPU ausgewählt wird, kann eine teure, aber unausgewogene Lösung entstehen. Zum Beispiel kann die GPU wegen langsamer Laufwerke ungenutzt bleiben, Antworten können sich wegen der Vektordatenbank verzögern, und das Sicherheitsteam kann den Start blockieren, weil keine Zugriffskontrolle für Dokumente vorhanden ist.

Was RAG in einem Unternehmens-Chatbot bedeutet

RAG (Retrieval-Augmented Generation) ist ein Ansatz, bei dem ein Sprachmodell zusätzlichen Kontext aus einer externen Wissensbasis erhält. In einem Unternehmens-Chatbot kann diese Wissensbasis Vorschriften, Anweisungen, Verträge, Artikel aus der Support-Wissensdatenbank, interne Richtlinien, Kundenkarten, technische Dokumentation oder Materialien aus einem Unternehmensportal umfassen.

Vereinfacht sieht der Prozess so aus:

1. Der Nutzer stellt eine Frage.
2. Das System wandelt die Frage in eine numerische Darstellung für die Suche um.
3. Die Vektordatenbank findet ähnliche Dokumentfragmente.
4. Ein zusätzliches Modul kann die gefundenen Fragmente nach Nützlichkeit sortieren.
5. Das Sprachmodell erhält die Frage und die ausgewählten Fragmente.
6. Der Chatbot erzeugt eine Antwort.
7. Das System speichert Logs, Metriken und bei Bedarf Links zu Quellen.

Im NVIDIA RAG Blueprint wird eine solche Architektur als eigenständige Enterprise-Pipeline betrachtet: Datenaufnahme, Informationsextraktion, Suche, Antwortgenerierung und Kontrolle des Systembetriebs. Das ist wichtig, weil RAG keine einzelne Komponente ist, sondern ein Verbund aus Services, bei dem jeder Teil Geschwindigkeit und Antwortqualität beeinflusst.

Eine Unternehmens-RAG-Lösung besteht normalerweise aus mehreren Teilen:

• einem Sprachmodell zur Antwortgenerierung;
• einem Modell für die semantische Suche;
• einer Vektordatenbank;
• einem Modul zur Aufnahme und Verarbeitung von Dokumenten;
• einem Speicher für Quelldateien;
• einer Metadatenbank;
• Prüfungen der Zugriffsrechte;
• Protokollierung von Anfragen;
• Monitoring von Qualität und Performance;
• einer Chatbot-Oberfläche oder API zur Integration in Unternehmenssysteme.

Eine GPU wird meistens benötigt, um das Sprachmodell auszuführen und einzelne Suchschritte zu beschleunigen. Aber nicht alle Teile von RAG hängen gleichermaßen von der Grafikkarte ab. Dokumentenindizierung, Speicherung, Berechtigungsfilterung, API-Arbeit, Aufgabenwarteschlangen und Monitoring können CPU, RAM, Laufwerke und Netzwerk stärker belasten.

Warum die Grafikkarte nicht alles löst

Die Grafikkarte übernimmt schwere Berechnungen, kann aber Architekturfehler nicht beheben. Wenn Dokumente schlecht vorbereitet sind, generiert der Server schlechte Antworten einfach schneller. Wenn die Wissensbasis auf langsamem Speicher liegt, wartet der Nutzer trotzdem, auch wenn die GPU fast frei ist. Wenn nicht genug RAM vorhanden ist, konkurrieren Indizes und Caches mit anderen Services.

Ein Chatbot kann nicht wegen der GPU langsam sein, sondern wegen anderer Engpässe:

• dem Modell wird ein zu langer Kontext übergeben;
• mehrere Nutzer erzeugen gleichzeitig eine Warteschlange von Anfragen;
• die Vektordatenbank durchsucht Dokumente zu langsam;
• Dokumente liegen auf externem Speicher mit langsamem Zugriff;
• die CPU kommt mit der Verarbeitung von PDFs, Tabellen und Präsentationen nicht nach;
• für Indizes und Caches ist nicht genug RAM vorhanden;
• statt NVMe werden gewöhnliche SSDs oder Netzwerkspeicher ohne die nötige Geschwindigkeit eingesetzt;
• es gibt keinen Cache für häufige Fragen;
• das System verarbeitet dieselben Dokumente wiederholt;
• das ausgewählte Modell passt nicht gut in den Videospeicher;
• Monitoring ist nicht eingerichtet, sodass das Team die tatsächliche Ursache der Verzögerungen nicht sieht.

Für RAG zählt nicht nur die maximale Geschwindigkeit der Textgenerierung, sondern die gesamte Antwortzeit: Suche, Sortierung der Fragmente, Kontextvorbereitung, Generierung und Auslieferung des Ergebnisses an den Nutzer. Wenn einer dieser Schritte langsam ist, rettet auch die stärkste GPU die User Experience nicht.

Woraus eine Serverarchitektur für RAG besteht

Ein Unternehmens-RAG-Server sollte als mehrere miteinander verbundene Subsysteme betrachtet werden. Sie können auf einem physischen Server, auf mehreren Knoten oder in einer gemischten Architektur laufen.

Antwortgenerierung

Das Sprachmodell ist der sichtbarste Teil des Systems. Es ist die Komponente, die die Antwort für den Nutzer formuliert. Dafür sind wichtig:

• Umfang des Videospeichers;
• Modellgröße;
• Kontextlänge;
• Anzahl gleichzeitiger Nutzer;
• Betriebsmodus des Modells;
• Zeit bis zur ersten Antwort;
• stabile Latenz unter Last.

Je größer das Modell und je länger der Kontext, desto mehr Videospeicher wird benötigt. Für einen einfachen Pilotbetrieb kann ein kompakteres Modell und eine einzelne GPU ausreichen. Für ein Production-Szenario mit vielen Nutzern und langen Dokumenten sind VRAM-Reserve und eine sorgfältigere Inferenzkonfiguration erforderlich.

In der vLLM-Dokumentation werden Parameter gesondert betrachtet, die GPU-Speichernutzung, Cache und Modelldurchsatz beeinflussen. Das ist ein gutes Beispiel dafür, dass Performance nicht nur von der GPU selbst abhängt, sondern auch davon, wie Warteschlangen, Caching und parallele Anfrageverarbeitung organisiert sind.

Semantische Suche

Damit der Chatbot das richtige Dokument findet, werden der Text der Frage und die Texte der Dokumente in numerische Darstellungen umgewandelt. So kann nicht nur nach exakten Wörtern, sondern auch nach semantischer Nähe gesucht werden.

Zum Beispiel fragt ein Nutzer: „Wie nehme ich unbezahlten Urlaub?“ In den Dokumenten kann die Formulierung „Urlaub ohne Gehaltsfortzahlung“ stehen. Eine normale Stichwortsuche findet das passende Fragment möglicherweise nicht, während die semantische Suche diese Formulierungen mit höherer Wahrscheinlichkeit verbindet.

Das Modell für diese Suche kann auf CPU oder GPU laufen. Wenn die Wissensbasis klein ist und selten aktualisiert wird, ist eine GPU für diesen Schritt nicht immer kritisch. Wenn Dokumente ständig hinzugefügt werden, viele PDFs und Tabellen vorhanden sind und täglich neu indiziert wird, wird Beschleunigung wichtig.

NVIDIA NeMo Retriever beschreibt eine solche Pipeline als Satz von Komponenten für Datenextraktion, Embedding-Erstellung, Indizierung und erneutes Sortieren der Ergebnisse. In einer Unternehmensumgebung ist das besonders wichtig, weil die Suchqualität die Antwortqualität direkt beeinflusst.

Vektordatenbank

Die Vektordatenbank speichert Dokumentfragmente in einer Form, die für die semantische Suche geeignet ist. Sie entscheidet, welche Fragmente in den Kontext des Modells gelangen.

Für eine Vektordatenbank sind wichtig:

• Indexgröße;
• Lesegeschwindigkeit;
• RAM-Kapazität;
• schnelle Laufwerke;
• Filterung nach Metadaten;
• Backup;
• Wiederherstellung nach einem Ausfall;
• Unterstützung von Zugriffsrechten.

In Production darf eine Vektordatenbank nicht wie ein temporärer Ordner behandelt werden. Wenn der Index verloren geht, veraltet ist oder ohne Berücksichtigung von Zugriffsrechten erstellt wurde, beginnt der Chatbot falsch zu antworten oder Dokumente zu verwenden, die ein bestimmter Nutzer nicht sehen darf.

Dokumentenaufnahme und -verarbeitung

Die Vorbereitung von Dokumenten ist oft schwieriger, als es zunächst scheint. Eine Unternehmens-Wissensbasis besteht selten aus sauber strukturierten Textdateien. Meist enthält sie PDFs, Scans, DOCX-Dateien, Tabellen, Präsentationen, HTML-Seiten, Archive, alte Versionen von Anweisungen und Duplikate.

In der Aufnahmephase muss man:

• Text extrahieren;
• Störzeichen entfernen;
• Duplikate entfernen;
• aktuelle Versionen von veralteten trennen;
• Dokumente in Fragmente aufteilen;
• Metadaten hinzufügen;
• die Verbindung zum Quelldokument erhalten;
• Zugriffsrechte berücksichtigen;
• Daten für die Indizierung vorbereiten.

Wenn dieser Schritt schlecht umgesetzt ist, antwortet auch ein starkes Modell selbstbewusst, aber ungenau. Es erhält das falsche Fragment, eine veraltete Dokumentversion oder Text ohne den benötigten Kontext.

Speicherung von Dokumenten, Indizes und Logs

Für RAG werden unterschiedliche Datentypen benötigt, und sie sollten besser nicht in einem gemeinsamen Ordner vermischt werden:

• Quelldokumente;
• bereinigter Text;
• Dokumentfragmente;
• Embeddings;
• Indizes der Vektordatenbank;
• Metadaten;
• Anfrage-Logs;
• Nutzerbewertungen;
• Backups.

NVMe-Laufwerke sind besonders nützlich für aktive Indizes, Cache, temporäre Dateien und schnelles Neuindizieren. Große Archive können separat gespeichert werden, aber der aktive Datensatz muss schnell gelesen werden. Andernfalls wartet die GPU, während der Server die Daten vorbereitet.

CPU und RAM

Die CPU wird nicht nur „der Vollständigkeit halber“ benötigt. Sie bedient die API, Dokumentenverarbeitung, Textextraktion, Filterung, Warteschlangen, Hintergrundaufgaben, Monitoring und einen Teil der Suchlogik. Wenn der Server einen schwachen Prozessor hat, kann das gesamte System bremsen, noch bevor die Anfrage die GPU erreicht.

RAM wird benötigt für:

• die Vektordatenbank;
• Indizes;
• Cache für beliebte Anfragen;
• Warteschlangen zur Dokumentenverarbeitung;
• Container;
• Systemservices;
• Monitoring;
• mehrere Modelle oder Services auf einem Knoten.

Für einen Pilotbetrieb kann eine moderate RAM-Menge ausreichen. Für Production, wo Datenbank, API, Indizierung, Monitoring und mehrere Nutzer gleichzeitig arbeiten, wird Sparen am Arbeitsspeicher schnell zum Problem.

Netzwerk

Das Netzwerk ist wichtig, wenn Dokumente auf externem Speicher liegen, die Vektordatenbank auf einen anderen Server ausgelagert ist, mehrere GPU-Knoten vorhanden sind oder der Chatbot an Unternehmenssysteme angebunden wird.

Für einen Pilotbetrieb reicht oft 10G. Für Production mit großem Dokumentenvolumen, separatem Speicher und mehreren Knoten sollte man frühzeitig 25G und mehr einplanen. Bei Clusterarchitekturen und schweren AI-Workloads wird das Netzwerk schnell genauso wichtig wie GPU und Laufwerke.

Sicherheit

Ein Unternehmens-Chatbot arbeitet mit internen Daten. Deshalb muss Sicherheit in die Architektur eingebaut werden und darf nicht erst nach dem Pilotbetrieb ergänzt werden.

Vorab muss geklärt werden:

• wer Zugriff auf welche Dokumente hat;
• wie Berechtigungen geprüft werden, bevor Fragmente an das Modell übergeben werden;
• wo Anfrage-Logs gespeichert werden;
• ob personenbezogene Daten in Logs gelangen;
• ob Dokumente und Indizes verschlüsselt werden;
• wie veraltete oder verbotene Dokumente entfernt werden;
• wer die Wissensbasis neu indizieren darf;
• wie Fehler und verdächtige Anfragen erfasst werden;
• ob Daten an externe APIs gesendet werden dürfen.

OWASP hebt in der Risikoliste für LLM-Anwendungen Prompt Injection gesondert hervor: eine Situation, in der eine bösartige Anweisung in einer Anfrage oder einem Dokument versucht, das Verhalten des Modells zu verändern. Für RAG ist das besonders wichtig: Eine gefährliche Anweisung kann nicht nur vom Nutzer kommen, sondern auch aus einem Dokument, das in die Wissensbasis hochgeladen wurde.

Welche Daten die Serverkonfiguration beeinflussen

Vor der Serverauswahl sollte nicht nur das Modell beschrieben werden, sondern auch die Aufgabe selbst. Zwei Unternehmen können beide einen „Unternehmens-Chatbot“ starten, aber sehr unterschiedliche Hardwareanforderungen haben.

Besonders wichtig ist es, Wachstum einzuschätzen. Wenn die Wissensbasis heute 100 GB umfasst, in einem Jahr aber 2 TB Dokumente mit täglichen Aktualisierungen enthält, kann der Pilotserver schnell zu einer Übergangslösung werden.

Anforderungen für Pilotbetrieb, Production und Multi-User-Szenario

Es gibt keine universelle Konfiguration für alle RAG-Systeme. Es gibt aber Orientierungswerte, die helfen, Fehler am Anfang zu vermeiden.

Diese Werte sollten nicht als fertige Spezifikation verstanden werden. Der reale Server wird nach Tests des Modells, Bewertung der Wissensbasis, Anzahl der Nutzer, Sicherheitsanforderungen und zulässiger Antwortzeit ausgewählt.

Wie man eine GPU für RAG und einen Chatbot auswählt

Die Auswahl der GPU beginnt nicht mit der Frage „welche Grafikkarte ist die leistungsstärkste“, sondern damit, welches Modell ausgeführt wird, welchen Kontext es benötigt und wie viele Nutzer gleichzeitig arbeiten.

Bei der Auswahl einer GPU sind wichtig:

• Umfang des Videospeichers;
• Unterstützung des benötigten Software-Stacks;
• Stromverbrauch;
• Formfaktor;
• Anforderungen an die Kühlung;
• Möglichkeit zur Installation mehrerer GPUs;
• Kompatibilität mit der Serverplattform;
• Reserve für Wachstum von Modell und Nutzerzahl.

Für kleinere Pilotprojekte und Unternehmensassistenten mit moderater Last kann man mit der allgemeinen Kategorie NVIDIA-GPUs für KI und neuronale Netze beginnen und eine Karte für das konkrete Modell und den benötigten VRAM-Umfang auswählen. Für einen Teil der Aufgaben kann beispielsweise eine NVIDIA L40S 48GB oder eine NVIDIA RTX PRO 6000 Blackwell Server Edition geeignet sein, wenn der Server bei Stromversorgung, Kühlung und Abmessungen kompatibel ist.

Für schwerere lokale Modelle, langen Kontext und Production-Last lohnt es sich, Lösungen mit größerem Videospeicher zu betrachten: NVIDIA A100 80GB, NVIDIA H100 80GB oder NVIDIA H200. Aber auch eine solche GPU ist für sich allein keine gute Wahl, wenn der Server sie bei Stromversorgung, Kühlung, Steckplätzen und Gesamtarchitektur nicht tragen kann.

Für RAG ist oft nicht die Spitzenleistung unter Idealbedingungen am wichtigsten, sondern der stabile Betrieb mit realen Anfragen. Nutzer bewerten keine „theoretischen Tokens pro Sekunde“. Sie sehen, wie schnell der Chatbot zu antworten beginnt, wie genau die Antwort ist und ob der Service in Spitzenzeiten stabil bleibt.

CPU, RAM und NVMe: wo versteckte Grenzen entstehen

In einem RAG-Projekt können CPU, RAM und Laufwerke genauso wichtig sein wie die GPU.

Die CPU ist an Dokumentenverarbeitung, API-Arbeit, Ergebnisfilterung, Anfragevorbereitung, Hintergrundaufgaben und Monitoring beteiligt. Wenn Dokumente ständig aktualisiert werden, muss der Server regelmäßig Text extrahieren, Fragmente neu aufbauen und den Index aktualisieren. Das ist nicht immer GPU-Last.

RAM wird für Vektordatenbank, Caches, Container, Warteschlangen und Systemprozesse benötigt. Wenn der Speicher knapp wird, arbeitet der Server instabil: Latenzen steigen, Indizierung dauert länger, und Services konkurrieren um Ressourcen.

NVMe-Laufwerke werden für aktive Daten benötigt:

• Indizes;
• temporäre Dateien;
• Cache;
• Logs;
• bereinigten Text;
• lokale Kopien der Wissensbasis;
• schnelles Neuindizieren.

Wenn an NVMe gespart wird, kann die GPU ungenutzt bleiben. Das Geld wurde in den Beschleuniger investiert, aber die Daten erreichen das Modell zu langsam.

Sicherheit von Unternehmens-RAG

Unternehmens-RAG arbeitet fast immer mit sensiblen Daten. Dazu können Verträge, kommerzielle Angebote, Finanzdokumente, personenbezogene Daten, Kundenkorrespondenz, interne Vorschriften und technische Dokumentation gehören.

Vor dem Start muss definiert werden:

• welche Dokumente indiziert werden dürfen;
• welche Dokumente nicht verwendet werden dürfen;
• wer für die Aktualität der Wissensbasis verantwortlich ist;
• wie Nutzerberechtigungen geprüft werden;
• wie veraltete Dokumente entfernt werden;
• wie Logs gespeichert werden;
• wer Zugriff auf die Anfragehistorie hat;
• ob Daten an externe Dienste gesendet werden dürfen;
• was bei Verdacht auf ein Datenleck zu tun ist.

Wenn ein Mitarbeiter in einem Unternehmenssystem keinen Zugriff auf ein Dokument hat, darf der Chatbot dieses Dokument nicht zur Antwortgenerierung verwenden. Diese Regel sollte nicht auf der Ebene einer „Modellanweisung“ umgesetzt werden, sondern auf Architekturebene: Metadaten, Filter, Rollen und Berechtigungsprüfung, bevor der Kontext an das Modell übergeben wird.

NIST empfiehlt in seinem Risikoprofil für generative KI, solche Systeme über Risikomanagement, Audit, Lebenszyklus und Vertrauenswürdigkeit der Ergebnisse zu betrachten. Für einen Unternehmens-Chatbot bedeutet das, dass die Serverarchitektur nicht nur Geschwindigkeit, sondern auch Kontrolle unterstützen muss: wer gefragt hat, welche Dokumente verwendet wurden, warum eine bestimmte Antwort gegeben wurde und ob sich das System nach einem Ausfall wiederherstellen lässt.

Wie man RAG und einen Unternehmens-Chatbot einführt

Die Einführung sollte besser nicht mit dem Kauf eines Servers beginnen, sondern mit der Vorbereitung von Daten und Szenarien.

Datenquellen sammeln

Es muss festgelegt werden, woher der Chatbot sein Wissen bezieht:

• Wissensbasis;
• Unternehmensportal;
• Dateiordner;
• CRM;
• Support-Tickets;
• Anweisungen;
• Verträge;
• Vorschriften;
• technische Dokumentation;
• Schulungsmaterialien.

In dieser Phase ist es wichtig, Überflüssiges sofort zu entfernen: Entwürfe, Duplikate, veraltete Versionen, Dokumente ohne Verantwortlichen und Dateien, die laut Sicherheitsrichtlinie nicht verwendet werden dürfen.

Dokumente vorbereiten

Dokumente müssen in eine Form gebracht werden, mit der das Suchsystem arbeiten kann:

• Text extrahieren;
• Formatierung bereinigen;
• Tabellen verarbeiten;
• nützlichen Text von Serviceinhalten trennen;
• die Verbindung zur Quelldatei erhalten;
• Datum, Verantwortlichen, Abteilung und Zugriffsebene hinzufügen.

Wenn die Wissensbasis viele Scans enthält, wird Texterkennung benötigt. Wenn es viele Tabellen gibt, muss gesondert geprüft werden, ob beim Extrahieren der Sinn verloren geht.

Dokumente in Fragmente aufteilen

Zu kleine Fragmente verlieren Kontext. Zu große Fragmente erhöhen die Modelllast und können die Genauigkeit verschlechtern. Für Unternehmens-RAG ist es wichtig, verschiedene Fragmentgrößen an realen Fragen zu testen.

Eine 40-seitige Anweisung kann beispielsweise mehrere unterschiedliche Verfahren enthalten. Wenn dem Modell das gesamte Dokument übergeben wird, kann es unnötige Informationen aufgreifen. Wenn das Dokument zu fein aufgeteilt wird, verliert die Antwort möglicherweise Bedingungen und Ausnahmen.

Index aufbauen

Nach der Vorbereitung werden Fragmente in Vektoren umgewandelt und in die Datenbank geladen. In diesem Schritt dürfen Metadaten nicht vergessen werden:

• Abteilung;
• Dokumenttyp;
• Aktualisierungsdatum;
• Version;
• Verantwortlicher;
• Sprache;
• Zugriffsebene;
• Link zum Quelldokument.

Ohne Metadaten ist es schwierig, Ergebnisse zu filtern, veraltete Dokumente zu entfernen und dem Nutzer zu erklären, worauf eine Antwort basiert.

Suche und Sortierung konfigurieren

Ein gutes RAG-System nimmt nicht einfach die ersten ähnlichen Fragmente. Es muss wirklich nützliche Quellen auswählen. Dafür werden Filterung, hybride Suche und erneutes Sortieren der Ergebnisse eingesetzt.

Es ist wichtig, die Suchqualität getrennt von der Generierungsqualität zu prüfen. Wenn das System die falschen Fragmente findet, erzeugt das Modell fast zwangsläufig eine schwache Antwort.

Antwortgenerierung konfigurieren

Das Modell sollte auf Basis der gefundenen Dokumente antworten und keine fehlenden Daten erfinden. Für einen Unternehmens-Chatbot ist es sinnvoll, Regeln vorab festzulegen:

• was zu tun ist, wenn Informationen fehlen;
• wann eine Rückfrage gestellt werden soll;
• wie auf Dokumente verwiesen wird;
• wie auf strittige Fragen geantwortet wird;
• welche Themen verboten sind;
• welche Daten in der Antwort nicht angezeigt werden dürfen.

Pilot starten und Qualität messen

Der Pilot sollte nicht mit idealen Demo-Fragen durchgeführt werden, sondern mit realen Anfragen von Mitarbeitern. Der Testsatz sollte enthalten:

• einfache Fragen;
• Fragen mit mehrdeutiger Formulierung;
• Fragen zu veralteten Dokumenten;
• Anfragen mit eingeschränkten Berechtigungen;
• Fragen, bei denen die richtige Antwort „es gibt nicht genug Informationen“ lautet;
• Versuche, Einschränkungen zu umgehen.

Nach dem Pilot wird klarer, was verstärkt werden muss: GPU, RAM, Laufwerke, Suche, Zugriffsrechte, Dokumentenvorbereitung oder Prompt-Qualität.

Welche Metriken überwacht werden sollten

Ohne Monitoring lässt sich nicht verstehen, ob der Server die Last bewältigt. Das Team sieht möglicherweise, dass „der Chatbot langsam ist“, weiß aber nicht, wo das eigentliche Problem liegt.

Für die Infrastruktur sollten überwacht werden:

• GPU-Auslastung;
• Nutzung des Videospeichers;
• GPU-Temperatur;
• CPU-Auslastung;
• RAM-Nutzung;
• Laufwerksgeschwindigkeit;
• Netzwerklatenz;
• freier Speicherplatz;
• Fehler von Containern und Services.

Für die RAG-Pipeline:

• Suchzeit;
• Zeit für erneutes Sortieren;
• Zeit zur Antwortgenerierung;
• Zeit bis zum ersten Token;
• gesamte Antwortzeit;
• Anzahl der gefundenen Fragmente;
• Anteil der Antworten ohne relevanten Kontext;
• Fehler beim Dokumentzugriff.

Für die Qualität:

• Antwortgenauigkeit;
• Vorhandensein von Links zu Dokumenten;
• Anteil der Antworten „nicht genug Informationen“;
• Nutzerbewertungen;
• Folgefragen;
• Beschwerden über veraltete Daten.

Für die Sicherheit:

• Versuche, auf geschützte Dokumente zuzugreifen;
• verdächtige Anfragen;
• Anzeichen von Prompt Injection;
• Lecks sensibler Daten in Logs;
• ungewöhnliche Aktivitätsspitzen.

Wenn diese Metriken nicht von Anfang an gesammelt werden, wird ein Production-Start zum Ratespiel. Das Team ändert Modell, GPU oder Datenbank, ohne zu verstehen, wo der tatsächliche Engpass liegt.

Ein Server oder mehrere Knoten

Ein einzelner Server kann eine gute Lösung für einen Pilotbetrieb oder einen ersten Production-Start sein. Er ist einfacher zu kaufen, zu warten und zu debuggen.

Ein einzelner Server ist geeignet, wenn:

• die Wissensbasis eine moderate Größe hat;
• es nicht viele Nutzer gibt;
• Dokumente nicht kontinuierlich aktualisiert werden;
• das Modell in eine GPU passt;
• keine strengen Anforderungen an Fehlertoleranz bestehen;
• die Vektordatenbank keine separate hohe Last erzeugt;
• das Projekt nur eine Hypothese überprüft.

Mehrere Knoten werden benötigt, wenn das System Teil eines realen Geschäftsprozesses wird:

• es gibt viele Nutzer;
• es gibt mehrere Chatbots für unterschiedliche Abteilungen;
• die Wissensbasis wächst schnell;
• Dokumente werden täglich oder häufiger aktualisiert;
• eine separate Vektordatenbank wird benötigt;
• das Modell ist schwergewichtig;
• der Kontext ist lang;
• Fehlertoleranz ist erforderlich;
• es gibt Anforderungen an p95/p99-Latenzen;
• separate Umgebungen für Dokumentenverarbeitung und Antwortgenerierung werden benötigt.

Die Architektur kann unterschiedlich aussehen. In einer Variante ist der GPU-Server nur für das Modell zuständig, während die Vektordatenbank auf einem separaten Knoten läuft. In einer anderen übernimmt ein separater Server die Dokumentenverarbeitung und Indizierung. In einer komplexeren Architektur stehen mehrere GPU-Server hinter einem Load Balancer, während Dokumente und Indizes separat gespeichert werden.

Wichtig ist, keinen Cluster zu früh aufzubauen, aber auch keinen Server ohne Wachstumsspielraum zu kaufen.

Häufige Fehler bei der Auswahl eines Servers für RAG

Die teuersten Fehler zeigen sich meist nicht beim Kauf, sondern einige Monate später.

Unternehmen machen häufig Folgendes:

1. Sie wählen den Server nur nach der GPU aus.
2. Sie berechnen die Kontextlänge nicht.
3. Sie berücksichtigen gleichzeitige Nutzer nicht.
4. Sie speichern Dokumente, Indizes und Logs auf einem Laufwerk.
5. Sie reservieren keinen RAM für die Vektordatenbank.
6. Sie testen die Geschwindigkeit der Neuindizierung nicht.
7. Sie denken Zugriffsrechte nicht durch.
8. Sie berücksichtigen das Wachstum der Wissensbasis nicht.
9. Sie messen die Suchqualität nicht.
10. Sie testen nur bequeme Demo-Fragen.
11. Sie planen Updates von Modellen und Treibern nicht.
12. Sie starten Production ohne Backup.
13. Sie prüfen Stromversorgung, Kühlung und Platz im Rack nicht.
14. Sie sammeln Metriken nicht ab dem ersten Tag.

Ein eigener Fehler ist die Annahme, dass ein größeres Modell eine schlechte Wissensbasis ausgleichen kann. Bei RAG hängt die Antwortqualität oft stärker von Dokumenten, Fragmentierung, Suche und Datenaktualität ab als von der Modellgröße.

Was in die Spezifikation für einen GPU-Server gehört

Vor der Beschaffung sollte der Server besser von der Aufgabe her beschrieben werden, nicht über eine Liste von Komponenten. Die Spezifikation sollte enthalten:

• die Hauptaufgabe des Chatbots;
• Dokumenttypen;
• aktuelle Größe der Wissensbasis;
• Wachstumsprognose für ein Jahr;
• Häufigkeit der Dokumentaktualisierung;
• Anzahl der Nutzer;
• gleichzeitige Spitzenlast;
• Modell oder Modellklasse;
• minimaler Umfang des Videospeichers;
• Anforderungen an die Antwortzeit;
• Anforderungen an die Datenspeicherung;
• Anforderungen an Zugriffsrechte;
• Backup-Anforderungen;
• Monitoring-Anforderungen;
• Beschränkungen bei Rack, Stromversorgung und Kühlung;
• Skalierungsplan.

Beispielformulierung:

Benötigt wird ein Server für einen Unternehmens-RAG-Chatbot auf Basis interner Dokumente des Unternehmens. Zum Start: bis zu 50 Nutzer, Wissensbasis bis 500 GB, tägliche Dokumentaktualisierung, Betrieb in einer geschlossenen Umgebung, Speicherung personenbezogener und kommerzieller Daten, erwartete Antwortzeit für die meisten Anfragen bis 5–8 Sekunden sowie Möglichkeit zur Erweiterung von GPU, RAM und NVMe innerhalb von 12 Monaten.

Diese Beschreibung ist nützlicher als die Formulierung „wir brauchen einen Server für KI“. Sie hilft zu erkennen, wo die realen Grenzen liegen werden: Videospeicher, Suche, Laufwerke, RAM, Netzwerk, Sicherheit oder Skalierung.

FAQ

Benötigt man eine GPU für RAG?

Ja, wenn das Sprachmodell lokal läuft und schnell antworten muss. Aber die RAG-Pipeline belastet nicht nur die GPU. Suche, Dokumentenverarbeitung, Vektordatenbank, Filterung, API und Monitoring benötigen CPU, RAM, schnelle Laufwerke und ein stabiles Netzwerk.

Kann man mit einer GPU starten?

Ja, besonders wenn es sich um einen Pilotbetrieb, eine kleine Wissensbasis und eine begrenzte Nutzerzahl handelt. Es ist aber besser, vorab zu prüfen, ob eine zweite GPU hinzugefügt, RAM erweitert und zusätzliche NVMe-Laufwerke installiert werden können.

Was ist wichtiger: GPU oder RAM?

Für die Antwortgenerierung sind GPU und Videospeicher wichtig. Für Suche, Indizes, Cache, Dokumentenverarbeitung und stabilen Servicebetrieb sind RAM und Laufwerke wichtig. In Production dürfen sie nicht getrennt betrachtet werden.

Warum antwortet ein Chatbot auf einer leistungsstarken GPU langsam?

Die Ursache kann ein langer Kontext, eine langsame Vektordatenbank, eine schwache CPU, zu wenig RAM, langsamer Speicher, Anfragewarteschlangen oder eine schlechte Inferenzkonfiguration sein.

Benötigt man einen separaten Server für die Vektordatenbank?

Für einen Pilotbetrieb nicht immer. Für Production, eine große Wissensbasis, mehrere Abteilungen und hohe Last kann ein separater Knoten für die Vektordatenbank sinnvoll sein.

Was ist besser: ein großes Modell oder gute Suche?

Für Unternehmens-RAG sind gute Suche und hochwertige Dokumentenvorbereitung oft wichtiger. Ein großes Modell behebt keine veralteten Dateien, schlechte Indizierung oder fehlende Prüfung von Zugriffsrechten.

Was muss vor dem Kauf unbedingt geprüft werden?

Geprüft werden müssen Umfang des Videospeichers, RAM, CPU, NVMe, Netzwerk, Stromversorgung, Kühlung, Treiberkompatibilität, Upgrade-Möglichkeiten, Monitoring, Backup, Zugriffsrechte und Anforderungen an die Datenspeicherung.

Fazit

Ein GPU-Server für RAG und einen Unternehmens-Chatbot sollte von der Aufgabe her ausgewählt werden, nicht vom Namen der Grafikkarte. Wichtig ist, vorab zu verstehen, welche Dokumente verwendet werden, wie häufig sie aktualisiert werden, wie viele Nutzer Fragen stellen, welchen Kontext das Modell benötigt, welche Daten das Unternehmen nicht verlassen dürfen und welche Antwortzeit akzeptabel ist.

Ein guter RAG-Server ist ein ausgewogenes System: GPU für Generierung, CPU für Verarbeitung, RAM für Indizes und Caches, NVMe für schnelle Daten, Netzwerk für Integrationen, Monitoring für Qualitätskontrolle und Sicherheit zum Schutz der Unternehmensinformationen. Wenn diese Teile im Voraus durchdacht werden, lässt sich der Chatbot einfacher starten, skalieren und in Production betreiben.