Warum braucht RAG so viel RAM?

Schnelle Vektorsuche will den Index resident im Speicher. Jeder Dokument-Chunk wird zu einem Embedding — einem Vektor aus ein paar hundert bis ein paar tausend Floats — und bei Millionen von Chunks summiert sich das. Schieb den Index auf die Festplatte und die Suchlatenz springt hoch; den ganzen Grund, warum du selbst gehostet hast (Geschwindigkeit + Kontrolle) zu behalten, bedeutet, ihn im RAM zu behalten.

Wie viel RAM für einen gegebenen Korpus?

Grobes Gefühl: ein paar hunderttausend Embeddings sitzen gut in 2–4 GB. Niedrige Millionen, mit der App und dem OS drumherum, und du bist bei 16–32 GB. Zehnmillionen oder hochdimensionale Vektoren und du bist bei 48–80 GB, und darüber hinaus splittest du über Server. Dimension und Indextyp schwingen das stark, also miss deinen eigenen.

pgvector oder eine dedizierte Engine wie Qdrant?

Wenn du bereits Postgres betreibst, ist pgvector der Weg mit dem geringsten Aufwand — eine Erweiterung, eine Datenbank. Für Millionen von Vektoren mit schwerem Filtern verdient eine zweckgebaute Engine ihren separaten Dienst. Beginne mit dem, was du bereits betreibst; wechsle nur, wenn die Suche langsam wird.

Warum selbst hosten statt eines verwalteten Vektordienstes?

Zwei echte Gründe: deine Embeddings kodieren oft private Daten (Docs, Notizen, Kundeninhalte), und das Selbst-Hosten hält das auf einem Server, den du kontrollierst. Und es sind flache Kosten — verwaltete Dienste rechnen nach Vektoren und Abfragen ab, ein VPS ist eine monatliche Zahl ohne Pro-Abfrage-Rechnung.

Selbst gehostetes RAG im großen Maßstab: wie viel RAM ein Vektorindex wirklich frisst

Jedes RAG-Tutorial läuft auf einem Laptop mit ein paar hundert Dokumenten, und es fühlt sich mühelos an. Dann richtest du es auf einen echten Korpus — die Docs eines Unternehmens, Jahre von Tickets, eine Wissensbasis — und plötzlich ist Speicher das ganze Gespräch.

RAG skaliert nicht mit CPU. Es skaliert mit RAM.

Warum der Index Speicher will

Retrieval funktioniert, indem jeder Text-Chunk in ein Embedding verwandelt wird — einen Vektor, ein paar hundert bis ein paar tausend Zahlen lang. Suche bedeutet, deinen Abfragevektor gegen sie alle zu vergleichen, schnell. „Schnell“ ist das entscheidende Wort: für niedrige Latenz muss der Index im RAM leben. Auf der Festplatte funktioniert es, aber jede Abfrage zahlt eine Strafe, und niedriglatente Retrieval war überhaupt der Sinn des Selbst-Hostens.

Also skaliert die Speicherrechnung mit zwei Dingen: wie viele Chunks du hast und wie breit jeder Vektor ist.

Echte Zahlen, grob

Miss deinen eigenen — Dimension und Indextyp bewegen das stark — aber als Ausgangsgefühl:

Ein paar hunderttausend Embeddings — bequem in 2–4 GB. Eine persönliche Wissensbasis, die Docs eines einzelnen Produkts.
Niedrige Millionen — mit der App, dem Modell-Client und dem OS drumherum, plane für 16–32 GB. Das ist eine ernsthafte Unternehmens-Wissensbasis oder ein Multi-Quellen-RAG.
Zehnmillionen oder hochdimensionale Vektoren — jetzt bist du bei 48–80 GB, und darüber hinaus über mehrere Maschinen. Große Dokumentenbestände, mandantenfähiges Retrieval, oder du hältst mehrere Indizes gleichzeitig warm.

Ein Multi-Agent-System, das auch einen großen Index hält, stapelt beide Kosten auf dieselbe Maschine — so wird ein 32-GB-Plan still zu einem 64-GB.

Die Engine-Wahl, kurz

Wenn du bereits Postgres betreibst, ist pgvector die Option mit dem geringsten Aufwand — es ist eine Erweiterung, kein neuer Dienst, den es zu babysitten gilt. Wenn du Millionen von Vektoren hast und schnelle gefilterte Suche willst, verdient eine dedizierte Engine wie Qdrant oder Weaviate den separaten Prozess. Übertechnisiere es nicht am ersten Tag; betreibe, was du bereits betreibst, und splitte es aus, wenn die Suche tatsächlich langsamer wird.

Warum überhaupt selbst hosten

Zwei Gründe, aus denen Leute das tatsächlich tun, und keiner ist „um ein paar Dollar zu sparen“:

Privatsphäre. Embeddings sind nicht abstrakt — sie kodieren den Text, aus dem sie kamen. Deine Docs, die Inhalte deiner Kunden, deine internen Notizen, in Vektoren verwandelt und an die Server eines Dritten verschickt. Das Selbst-Hosten hält das auf einer Maschine, die du kontrollierst. Wenn die Daten sensibel genug sind, dass du auch in Krypto ohne KYC zahlst, macht eine verwaltete Vektor-Cloud den ganzen Sinn zunichte.

Flache Kosten. Verwaltete Vektordienste rechnen nach gespeicherten Vektoren und ausgeführten Abfragen ab. Ein VPS ist eine monatliche Zahl und du kannst ihn so hart hämmern, wie du willst. Im großen Maßstab schlägt vorhersehbar gemessen.

Was das für die Dimensionierung bedeutet

Beginne damit, deinen Korpus zu messen, nicht zu raten. Hol deine Embedding-Anzahl und -Dimension, lade eine Stichprobe, beobachte den residenten Speicher, extrapoliere. Dann wähle einen Plan mit Spielraum für den Index plus alles drumherum — die App, den Modell-Client, Platz zum Wachsen.

Für alles jenseits von ein paar Millionen privat gehaltenen Vektoren betreibt die Pro-Linie 32 bis 80 GB mit einer dedizierten IP und nächtlichen Backups, was zählt, wenn der Index das Produkt ist und ihn zu verlieren wehtut.