Ein Server für RAG und KI-Agenten lässt sich nicht allein anhand der Anzahl und Leistung seiner GPUs auswählen. Die Leistung hängt von der gesamten Kette ab: vom Einlesen der Dokumente, dem Aufbau des Index, der Suche, der Arbeit von CPU und Arbeitsspeicher, der Datenübertragung im Netzwerk, der Verarbeitung langer Kontexte und der Platzierung des KV-Caches. Für ein Pilotprojekt können die Komponenten auf einem Knoten zusammengeführt werden, eine Produktivkonfiguration sollte jedoch anhand des Umfangs der Wissensbasis, der Anzahl gleichzeitiger Anfragen und der zulässigen Latenz dimensioniert werden.
RAG (Retrieval-Augmented Generation) ist die Generierung von Antworten mit Unterstützung durch die Suche in einer externen Wissensbasis, etwa in einem internen Unternehmens-Wiki, in Internetquellen oder in einem Dokumentenordner. Bevor das große Sprachmodell aufgerufen wird, findet das System relevante Dokumentfragmente und fügt sie dem Prompt hinzu. Ein KI-Agent führt mehr Aktionen aus: Er präzisiert die Aufgabe, greift auf Datenbanken und APIs zu, startet zusätzliche Suchvorgänge, prüft Zwischenergebnisse und erstellt anschließend die Antwort.
Eine hohe Geschwindigkeit bei der Token-Generierung bedeutet daher nicht zwangsläufig, dass der Nutzer das Ergebnis schnell sieht. Die GPU kann ungenutzt bleiben, während der Server den Index vom Speicher liest, Dokumente nach Zugriffsrechten filtert oder auf die Antwort eines externen Systems wartet.
GPU servers
Aus welchen Phasen besteht ein RAG-System
RAG arbeitet in zwei Betriebsarten: Vorbereitung der Wissensbasis und Verarbeitung von Anfragen. Beide belasten die Hardware unterschiedlich.
Vorbereitung der Wissensbasis
Bevor die Suche beginnen kann, muss das System:
- Dokumente aus Dateien, Portalen, E-Mails oder Datenbanken erfassen.
- Text aus PDFs, Office-Dokumenten, HTML-Seiten, Bildern und Tabellen extrahieren.
- Gescannte Dokumente erkennen, die Daten bereinigen und Duplikate entfernen.
- Das Material in Fragmente aufteilen.
- Für jedes Fragment eine Vektordarstellung erstellen.
- Text, Vektoren, Metadaten und Zugriffsrechte speichern.
- Den Suchindex aufbauen.
- Eine Sicherung der Quelldaten und der Konfiguration vorbereiten.
In dieser Phase sind CPU, RAM und die Schreibgeschwindigkeit der NVMe-Laufwerke besonders wichtig. Eine Massenaufnahme kann alle Kerne auslasten, eine I/O-Warteschlange erzeugen und den aktiven Index aus dem Systemcache verdrängen.
Verarbeitung von Anfragen
Nach Eingang einer Frage führt das System folgende Schritte aus:
- Es überprüft den Nutzer und seine Berechtigungen.
- Es erstellt einen Vektor für die Frage.
- Es sucht in der Vektordatenbank nach Kandidaten.
- Es filtert sie nach Sprache, Datum, Dokumenttyp und Zugriffsebene.
- Es ordnet die gefundenen Fragmente erneut.
- Es stellt den Kontext für das Sprachmodell zusammen.
- Es generiert die Antwort und speichert Servicedaten.
In einem agentischen Szenario wird diese Abfolge wiederholt. Die NVIDIA-Dokumentation zu agentischem RAG beschreibt eine Architektur, bei der eine Aufgabe in Phasen unterteilt wird, während separate Mini-Agenten die Suche durchführen, eine Teilantwort erstellen und bei unzureichenden Daten eine neue Anfrage starten. Eine einzige Nutzerfrage kann daher Dutzende Aufrufe der Suche, des Modells und externer Systeme auslösen.
| Phase | Hauptaufgabe | Wichtige Ressourcen | Möglicher Engpass |
|---|---|---|---|
| Dokumentenaufnahme | Einlesen, Erkennung und Bereinigung | CPU, RAM, NVMe | Langsame Dateiverarbeitung |
| Vektorerstellung | Inferenz des Embedding-Modells | GPU oder CPU, RAM | Geringer Batch-Durchsatz |
| Indexaufbau | Schreiben der Suchstruktur | RAM, NVMe, CPU | Unzureichender Arbeitsspeicher |
| Suche | Lesen des Index und Filtern | RAM, NVMe, CPU | Fehlzugriffe im Systemcache |
| Erneute Rangfolge | Bewertung der gefundenen Fragmente | GPU oder CPU | Anfragewarteschlange |
| Kontextverarbeitung | Verarbeitung einer langen Eingabe durch das Modell | GPU, KV-Cache | Lange Zeit bis zum ersten Token |
| Generierung | Sequenzielle Erstellung der Antwort | GPU, KV-Cache | Geringe Ausgabegeschwindigkeit |
| Agentenaktionen | API-Aufrufe und wiederholte Schleifen | CPU, Netzwerk | Aufsummierte Latenz |
Wofür die GPU zuständig ist
Die GPU führt Berechnungen für das Sprachmodell, das Embedding-Modell und das Modell zur erneuten Rangfolge aus. Diese Aufgaben müssen nicht zwingend auf demselben Beschleuniger laufen.
Der Videospeicher wird nicht nur für die Modellgewichte genutzt. Darin befinden sich außerdem:
- Arbeitsbuffer der Engine;
- der KV-Cache aktiver Anfragen;
- temporäre Daten der Kontextverarbeitung;
- zusätzliche Modelle;
- Reserven für Lastspitzen und Fragmentierung.
Ein Modell, das bei einem Test mit einer einzelnen Anfrage in den Speicher passt, kann daher bei steigender Parallelität ausfallen. Auch die umgekehrte Situation ist häufig: Die GPU-Auslastung ist niedrig, aber die Antworten sind langsam. In diesem Fall wartet der Beschleuniger wahrscheinlich auf die Suche, die Tokenisierung, das Lesen vom Datenträger oder einen Netzwerkaufruf. Der Kauf einer leistungsstärkeren GPU beseitigt keine Latenz in einer anderen Schicht.
Warum die CPU wichtig ist
Die CPU übernimmt die Aufgaben rund um das Sprachmodell:
- Textextraktion und Bereinigung;
- Dokumenterkennung;
- Aufteilung in Fragmente und Tokenisierung;
- Filterung nach Metadaten;
- Betrieb der Vektordatenbank;
- Container, Warteschlangen und APIs;
- Verschlüsselung des Datenverkehrs;
- Werkzeuge des KI-Agenten.
Für die Hintergrundindexierung ist die Anzahl der Kerne wichtig. Berücksichtigt werden müssen jedoch auch die Leistung einzelner Kerne, die Zahl der Speicherkanäle, die verfügbaren PCIe-Lanes und die Anbindung der Geräte.
Ist die GPU mit einem Prozessor verbunden, während das Speichergerät oder der Netzwerkadapter von einem anderen NUMA-Knoten bedient wird, müssen die Daten zwischen den Sockeln übertragen werden. Unter hoher Last erhöht dies die Latenz und führt zu Konkurrenz auf der Verbindung zwischen den Prozessoren.
Ein-Sockel-Server mit AMD EPYC eignen sich, wenn viele PCIe-Lanes und Speicherkanäle benötigt werden, ohne die Ressourcen auf mehrere Sockel aufzuteilen, sofern NUMA korrekt konfiguriert und die Prozessorarchitektur berücksichtigt wird. Server mit Intel Xeon sind in einer breiten Auswahl an Ein- und Zwei-Sockel-Konfigurationen verfügbar. Die Plattform sollte nach ihrer tatsächlichen PCIe-Topologie, der Anzahl der Beschleuniger, der Speicherkapazität und den verfügbaren Laufwerksschächten ausgewählt werden, nicht nur nach der Prozessorfamilie.
Interner Aufbau eines KI-Servers mit mehreren Beschleunigern: GPUs, Prozessorbereich, Stromversorgung und Kühlsystem.
Bildquelle: Dell Technologies
RAM: Index und Systemcache
Die Größe der Quelldokumente zeigt nicht, wie viel RAM das System benötigt. Nach der Aufteilung wird aus einem Dokument eine Vielzahl von Fragmenten. Für jedes Fragment werden ein Vektor, der Text, eine Kennung, Metadaten und ein Teil der Suchstruktur gespeichert.
Im RAM können sich gleichzeitig befinden:
- aktive Vektoren und der Suchgraph;
- Feldindizes für die Filterung;
- häufig verwendete Fragmente;
- der System-Dateicache;
- Datenbankprozesse und Anfragewarteschlangen;
- eine neue Indexversion während des Neuaufbaus;
- ein aus dem Videospeicher ausgelagerter Teil des Modells oder des KV-Caches.
Eine Vektordatenbank kann einen Teil ihrer Daten auf dem Datenträger speichern. Beispielsweise empfiehlt Qdrant, Vektoren, Metadaten, Indizes, Replikation und Speichermodus getrennt zu berechnen. Bei einer datenträgerbasierten Platzierung hängt die Leistung stärker von der Größe des Systemcaches und der Speicherlatenz ab.
Passt der Arbeitsdatensatz nicht in den RAM, liest der Server häufiger Seiten von NVMe. Die durchschnittliche Latenz kann akzeptabel erscheinen, während einzelne Anfragen deutlich länger dauern. Eine Auslagerungsdatei löst das Problem nicht, weil sie sich auf demselben NVMe-Speicher befindet. Speicherreserven werden außerdem für Aktualisierungen benötigt: Eine Zeit lang bedient die alte Indexversion weiterhin Anfragen, während die neue Version bereits RAM und Speicherplatz belegt.
Warum RAG schnellen NVMe-Speicher benötigt
Auf den Laufwerken befinden sich die Quelldokumente, bereinigter Text, Fragmente, Vektoren, der Index, Datenbankprotokolle, Modelldateien, temporäre Daten für den Neuaufbau und Sicherungen.
Die Last kombiniert verschiedene Vorgänge:
- sequenzielles Lesen großer Modelldateien;
- zufälliges Lesen kleiner Indexblöcke;
- anhaltende Schreibvorgänge bei der Dokumentenaufnahme;
- synchrones Schreiben von Datenbankprotokollen;
- Lesen der alten Indexversion bei gleichzeitigem Schreiben der neuen;
- Sicherungen im Hintergrund.
Die Spitzengeschwindigkeit aus dem Datenblatt ist daher nicht die einzige wichtige Kennzahl. Bewertet werden müssen auch die Latenz einzelner Vorgänge, die Zahl der Ein-/Ausgabeoperationen pro Sekunde, die dauerhaft erreichbare Schreibgeschwindigkeit, die Schreibausdauer und der Schutz bei Stromausfall. Eine Consumer-SSD kann in einem kurzen Test schnell sein, aber nach dem Füllen ihres internen Caches deutlich langsamer werden.
Datenbank, Protokolle, Modelle und Sicherungen sollten nicht ohne genaue Dimensionierung auf demselben Array abgelegt werden. Andernfalls konkurrieren der Neuaufbau des Index oder das Kopieren eines Snapshots mit der Suche für Nutzeranfragen. Zudem ist zu beachten, dass RAID den Ausfall eines Laufwerks abfangen und/oder zusätzliche Leistung liefern kann, eine Sicherung jedoch nicht ersetzt.
Lokaler NVMe-Speicher bietet normalerweise die niedrigste Latenz. Gemeinsam genutzter Speicher vereinfacht den Betrieb mehrerer Knoten, fügt jedoch einen Netzwerkpfad hinzu. In einer kompatiblen Architektur reduziert NVIDIA GPUDirect Storage unnötige Kopiervorgänge über den Systemspeicher bei der Datenübertragung zwischen Speicher und GPU. Der Nutzen hängt von Software, Dateisystem, PCIe-Topologie und Lastprofil ab.
Netzwerk: Nicht nur die Bandbreite zählt
Auf einem einzelnen Server mit lokaler Datenbank bleibt der größte Teil des Datenaustauschs innerhalb des Systems. Sobald die Komponenten getrennt werden, wird das Netzwerk Teil jeder Anfrage.
Darüber laufen:
- Nutzeranfragen und Antworten;
- Anfragen an die Vektordatenbank;
- gefundene Fragmente und Metadaten;
- Aufrufe von Unternehmens-APIs;
- Zugriff auf gemeinsam genutzten Speicher;
- Replikation des Index;
- Protokolle und Sicherungen;
- Kommunikation zwischen Knoten einer verteilten Inferenz.
Die Antwortzeit wird durch Latenz, Schwankungen, Paketverluste und überlastete Warteschlangen beeinflusst. Ein kleines Paket mit einem Suchergebnis kann die Generierung verzögern, selbst wenn die durchschnittliche Auslastung der Verbindung niedrig ist.
Für einen einzelnen Server mit lokalem NVMe-Speicher kann sogar ein 1-GbE-Netzwerk im Rechenzentrum ausreichen, 10 GbE sind jedoch das bessere Ziel. Verbindungen mit 25 oder 100 Gbit/s und Remote Direct Memory Access sind bei entferntem Speicher, einem verteilten Modell, der Replikation eines großen Index oder der Übertragung des KV-Caches zwischen Knoten gerechtfertigt. Sicherungen und der Neuaufbau des Index dürfen nicht unkontrolliert dieselbe Verbindung belegen wie Produktivanfragen.
KV-Cache: der verborgene Verbraucher von Videospeicher
Bei der Textverarbeitung speichert das Modell Zwischendaten des Aufmerksamkeitsmechanismus für bereits gelesene Token. Dadurch müssen sie bei der Generierung jedes nachfolgenden Tokens nicht erneut berechnet werden. Diese Daten werden als KV-Cache bezeichnet.
Der KV-Cache ist weder eine Vektordatenbank noch eine Kopie der Dokumente oder der Modellgewichte. Er ist der Arbeitsspeicher für aktive Sequenzen. Je länger der Kontext und je größer die Zahl gleichzeitiger Anfragen, desto mehr Platz belegt er.
Eine vereinfachte Schätzung lautet:
Anzahl der Schichten × 2 × Anzahl der KV-Köpfe × Kopfgröße × Anzahl der Token × Anzahl der Sequenzen × Größe eines Elements.
Der Faktor 2 berücksichtigt Schlüssel und Werte. Die Größe eines Elements hängt vom Datenformat ab, die Anzahl der KV-Köpfe von der Modellarchitektur.
Bei einem hypothetischen Modell mit 80 Schichten, 8 KV-Köpfen, einer Kopfgröße von 128, zwei Byte pro Wert und einem Kontext von 32.768 Token würde der Cache für eine vollständig belegte Sequenz etwa 10 GB benötigen. Acht unabhängige Sequenzen erfordern etwa 80 GB, sechzehn etwa 160 GB. Diese Schätzung berücksichtigt weder Verwaltungsaufwand noch die Verteilung auf mehrere GPUs oder die Wiederverwendung gemeinsamer Präfixe. Sie zeigt jedoch, warum ein Modell bei einer einzelnen Anfrage in den Speicher passt und unter Last nicht mehr.
So lässt sich der Verbrauch des KV-Caches reduzieren
Üblicherweise werden mehrere Methoden kombiniert:
- typische und maximale Kontextlänge begrenzen;
- die Anzahl aktiver Sequenzen steuern;
- den Cache blockweise zuweisen und ungenutzte Seiten freigeben;
- gemeinsame Systemanweisungen wiederverwenden;
- die Speicherpräzision reduzieren;
- einen Teil des Caches in den RAM auslagern;
- NVMe oder externen Speicher für wiederkehrende Präfixe verwenden;
- Eingabeverarbeitung und Generierung auf verschiedene Knoten verteilen.
Laut der vLLM-Dokumentation reduziert die Speicherung des KV-Caches in FP8 dessen Größe und ermöglicht es, mehr Token unterzubringen. Dieser Modus muss mit dem ausgewählten Modell und Beschleuniger getestet werden: Die Speichereinsparung kann mit zusätzlichen Berechnungen und Anforderungen an die Skalierung der Werte verbunden sein.
Warum ein langer Kontext das erste Token verzögert
Das Modell muss zunächst die Anweisungen, den Verlauf und die gefundenen Dokumente lesen. Erst danach beginnt die Generierung. Das erste Token kann durch einen übermäßig großen Kontext, eine GPU-Warteschlange, unzureichenden Videospeicher oder die fehlende Möglichkeit zur Wiederverwendung eines zuvor berechneten Präfixes verzögert werden.
Ein großes Kontextfenster sollte daher nicht als kostenlose Möglichkeit zur Qualitätssteigerung betrachtet werden. Zuerst sollten die Suche verbessert, Duplikate entfernt und Fragmente genauer neu geordnet werden, statt alle gefundenen Dokumente an das Modell zu senden.
Most popular GPU
Typische Engpässe
| Symptom | Wahrscheinliche Ursache | Was gemessen werden sollte | Was geändert werden sollte |
|---|---|---|---|
| Die GPU ist ungenutzt und Antworten sind langsam | Suche, CPU oder Netzwerk | Latenz der Phasen und Kernauslastung | Suche und Datenübertragung optimieren |
| Das erste Token erscheint erst nach langer Zeit | Großer Kontext oder Warteschlange | Eingabelänge, Wartezeit und Kontextverarbeitung | Kontext reduzieren und Cache konfigurieren |
| Die Generierung ist langsam | Begrenzung durch GPU oder Speicher | Token pro Sekunde und GPU-Auslastung | Modell und Parallelisierung abstimmen |
| Die Suche wird bei wachsender Datenbank langsamer | Der Index passt nicht in den RAM | NVMe-Lesevorgänge und Cache-Fehlzugriffe | RAM hinzufügen oder Speichermodus ändern |
| Die Indexierung verschlechtert die Antwortleistung | Konkurrenz um CPU und NVMe | Datenträgerwarteschlange und Kernauslastung | Prozesse trennen oder Limits setzen |
| Der Videospeicher ist ausgeschöpft | Der KV-Cache wächst | Anzahl der Sequenzen und Token | Parallelität reduzieren oder Cache auslagern |
| Filter arbeiten langsam | Ungeeignete Metadatenindizes | Suche mit und ohne Filter | Indizes für die benötigten Felder erstellen |
| Kopiervorgänge erhöhen die Latenz | Gemeinsamer Datenträger oder Netzwerkkanal | Datenträger- und Netzwerkverkehr | Wartungsfenster oder separaten Pfad einrichten |
Optimiert werden muss der gesamte Pfad einer Anfrage, nicht eine einzelne Zahl aus einem GPU-Benchmark. Eine Verkürzung der Suchzeit um einen Bruchteil einer Sekunde kann mehr bewirken als eine höhere Generierungsgeschwindigkeit, insbesondere wenn ein Agent die Suche mehrfach ausführt.
Welche Kennzahlen gemessen werden sollten
Auf Nutzerebene sind die gesamte Antwortzeit, die Zeit bis zum ersten Token, der Median, das 95. und 99. Perzentil, die Anzahl der Agentenschritte und die Fehlerquote wichtig.
Für das Modell werden gemessen:
- die Anzahl der Eingabe- und Ausgabetoken;
- die Wartezeit in der Warteschlange;
- die Zeit der Kontextverarbeitung;
- die Generierungsgeschwindigkeit;
- die Belegung des Videospeichers;
- die Anzahl aktiver Sequenzen;
- Belegung und Wiederverwendung des KV-Caches.
Für die Suche und den Server sollten die Zeiten für Vektorisierung, Suche, Filterung und erneute Rangfolge, die Auslastung einzelner Kerne, die Nutzung von RAM und Systemcache, die NVMe-Latenz, die Netzwerklatenz und erneute Übertragungen gemessen werden.
Ein Durchschnittswert verbirgt seltene Einbrüche. Dauert eine von hundert Anfragen 20 Sekunden, werden Nutzer das Problem bemerken, selbst wenn der Durchschnitt akzeptabel bleibt.
Ein Server oder mehrere Knoten
Alle Komponenten können auf einem Server untergebracht werden, wenn die Datenbank klein, die Nutzerzahl begrenzt und Aktualisierungen selten sind. Diese Architektur ist einfacher, kostengünstiger und erzeugt weniger Netzwerkübergänge.
Mit dem Wachstum des Systems entstehen Einschränkungen:
- die Indexierung konkurriert mit der Modellinferenz;
- der Vektordatenbank fehlt RAM;
- Datenträgeroperationen beeinträchtigen die Suche;
- Suche und Generierung lassen sich nicht unabhängig skalieren;
- der Ausfall eines Knotens stoppt das gesamte System.
Eine Plattform wie der Dell PowerEdge R760 kann als Rechen- oder Suchknoten eingesetzt werden. Die Konfiguration muss jedoch hinsichtlich der Anzahl unterstützter GPUs, der Riser, der Stromversorgung, der Kühlung und der Optionen für Laufwerksschächte geprüft werden. Derselbe Servermodellname bedeutet nicht, dass jede Konfiguration dieselben Möglichkeiten bietet.
Die Trennung von Modell und Vektordatenbank ist sinnvoll, wenn der Index schneller wächst als die Modelllast, Dokumente kontinuierlich aktualisiert werden oder mehrere Dienste dieselbe Wissensbasis nutzen. Suchknoten können dann durch zusätzlichen RAM und NVMe-Speicher skaliert werden, Inferenzknoten durch weitere GPUs.
Für große Systeme ist eine separate Pipeline zur Datenaufnahme sinnvoll. Sie analysiert Dokumente, erstellt Vektoren, baut eine neue Indexversion auf und validiert sie vor der Veröffentlichung. Die Produktivdatenbank bedient weiterhin Anfragen, ohne mit der Massenindexierung um Ressourcen zu konkurrieren.
Die Auslagerung des KV-Caches auf schnellen Speicher ist nicht für jedes System erforderlich. Sie kann bei langen, wiederkehrenden Präfixen und mehrstufigen Dialogen sinnvoll sein, erhöht jedoch die Anforderungen an Netzwerk und Speicher. Bei einem Test von Dell Technologies wurden vLLM, LMCache, externer Speicher und ein Netzwerk mit Remote Direct Memory Access verwendet. Die Ergebnisse gelten für diese konkrete Testumgebung und ersetzen keine Tests mit der eigenen Last.
So wird die Konfiguration dimensioniert
Die Dimensionierung beginnt mit dem Lastprofil, nicht mit dem Gehäusemodell.
Modellschicht
Festgelegt werden müssen das Hauptmodell, das Format der Gewichte, die Anzahl der GPUs, der typische und maximale Kontext, die Antwortlänge, die Zahl gleichzeitiger Anfragen und die zulässige Zeit bis zum ersten Token. Embedding- und Reranking-Modelle müssen ebenfalls berücksichtigt werden.
Videospeicher
Zu den Modellgewichten werden Arbeitsbuffer, KV-Cache, zusätzliche Modelle und Reserven für Lastspitzen addiert. Die Berechnung muss auf der tatsächlichen Anzahl gleichzeitiger Sequenzen basieren.
Suchschicht
Zu berücksichtigen sind die Anzahl der Dokumente, die durchschnittliche Zahl der Fragmente, die Vektordimensionalität, das Zahlenformat, die Indexstruktur, Metadaten, Replikate, Aktualisierungshäufigkeit und das Wachstum der Datenbank.
RAM
Aktiver Index, Vektoren, Metadatenindizes, Systemcache, Datenbankprozesse, Speicher für den Neuaufbau und eine mögliche Auslagerung von der GPU werden addiert. Es ist eine Reserve erforderlich, damit Lastspitzen das System nicht zu permanenten Lesezugriffen auf den Datenträger zwingen.
Speicher
Der NVMe-Speicher muss ausreichend Kapazität für Dokumente, Fragmente, Vektoren, Index, Protokolle, die temporäre Kopie beim Neuaufbau, Modelle, Snapshots und lokale Sicherungen bieten. Zu prüfen sind Schreibausdauer und Leistung bei gleichzeitigen Lese- und Aktualisierungsvorgängen.
Server-Topologie
Die Plattform muss die ausgewählten GPUs, NVMe-Laufwerke, Netzwerkadapter und Controller ohne kritische Einschränkungen durch gemeinsam genutzte Lanes unterstützen. Auch die Platzierung der Geräte relativ zu den Prozessoren, Stromversorgung, Kühlung und Erweiterungsmöglichkeiten müssen geprüft werden. Für Workloads dieser Art kommen KI-Server infrage, die konkrete Konfiguration muss jedoch mit den benötigten Beschleunigern und Speichergeräten kompatibel sein.
End-to-End-Test
Der Test muss die Produktivkette nachbilden:
Frage → Vektorerstellung → Suche → Filterung → erneute Rangfolge → Kontextzusammenstellung → Modellverarbeitung → Agentenaktionen → Antwort.
Hintergrundaktualisierungen und Protokollierung sollten gleichzeitig laufen. Ein Test nur eines Sprachmodells mit einem vorbereiteten Prompt zeigt lediglich einen Teil der Systemleistung.
Sicherung und Wiederherstellung
Für die Wiederherstellung werden mehr als Modellgewichte und Dokumente benötigt. Gesichert werden sollten auch die bereinigten Daten, Regeln zur Aufteilung in Fragmente, die Version des Embedding-Modells, Indexparameter, Metadaten, Zugriffsrechte, Datenbank-Snapshots, Systemanweisungen und die Konfiguration der Agentenwerkzeuge. Geheimnisse und Schlüssel müssen separat gespeichert werden.
Der Index kann neu aufgebaut werden, bei einer großen Datenbank dauert dieser Vorgang jedoch lange und belastet CPU, GPU und NVMe-Speicher erneut. Ein Replikat schützt vor dem Ausfall eines Knotens, nicht aber vor versehentlichem Löschen. Sicherungen sollten daher getrennt vom Produktivarray gespeichert werden. Zulässiger Datenverlust und Wiederherstellungszeit sind im Voraus festzulegen.
Fazit
Die Leistung von RAG und KI-Agenten wird durch das Gleichgewicht der gesamten Infrastruktur bestimmt. Die GPU führt die Modelle aus, RAM hält den aktiven Index und Cache, NVMe ermöglicht den Datenzugriff, die CPU übernimmt Vorbereitung und Suche, und das Netzwerk verbindet getrennte Dienste. Der KV-Cache verknüpft zusätzlich Kontextlänge und Parallelität mit dem Verbrauch von Videospeicher. Eine zuverlässige Konfiguration kann erst ausgewählt werden, nachdem der vollständige Datenpfad berechnet und ein End-to-End-Lasttest unter produktionsnahen Bedingungen einschließlich möglicher Lastspitzen durchgeführt wurde.
Inhaltsverzeichnis:
