Architektur einer privaten KI-Plattform für 2.000 Nutzer: welche Server welche Aufgabe übernehmen

Die Serverrollen einer privaten KI-Plattform

Die Architektur einer privaten KI-Plattform für 2.000 Mitarbeiter besteht aus einer Reihe von Serverrollen und nicht aus einem großen Server. GPU-Inferenzserver betreiben die Sprachmodelle, eine kleinere GPU oder MIG-Instanzen betreiben das Embedding-Modell und den Reranker, und CPU-Server oder virtuelle Maschinen tragen die Vektordatenbank, den Dokumentenspeicher, das Gateway mit Identität, die Observability, den Modellspeicher und die Kubernetes-Control-Plane. Im Rechenbeispiel unten hält jeder von zwei GPU-Servern mit fünf RTX PRO 6000 Server Edition oder zwei H200 NVL je Server die ganze Spitze, und die meisten CPU-Rollen laufen in zwei oder drei Replikaten.

Die Zahl der GPUs dieser LLM-Infrastruktur im Unternehmen ergibt sich aus den Anfragen in Bearbeitung, nicht aus der Kopfzahl, und dieser Artikel übernimmt sie aus unserem Leitfaden zu privaten ChatGPT-Servern nach Unternehmensgröße, statt die Rechnung zu wiederholen.

Was jede Rolle tut und worauf sie läuft

GPU-Inferenzserver betreiben die Serving-Engine, etwa vLLM, mit einer Kopie des Modells je Karte, wenn das Modell auf eine Karte passt. NVIDIAs Enterprise RAG Retrieval Scaling and Sizing Guide, aktualisiert am 22. August 2026, sagt: „Das NIM LLM ist die Hauptkomponente, die die Leistung beeinflusst“, und skaliert die übrigen Dienste in festen Verhältnissen dazu.

Retrieval-Modelle sind klein und werden nach ihrer Rate ausgelegt, nicht nach ihrem Speicher. Die Baseline des Leitfadens stellt einer LLM-GPU, die je Karte ein Nemotron-Modell mit 49B betreibt, eine GPU für den Reranking-Dienst und eine halbe GPU für den Embedding-Dienst zur Seite, „mit Run:ai oder MIG“. Bei der achtfachen Größe teilen sich acht LLM-GPUs weiterhin eine Reranker-GPU, eine halbe Embedder-GPU und die Viertel-GPU des Indexknotens, der für die Aufnahme der Dokumente genutzt wird, insgesamt 9,75 GPUs auf zwei Knoten. Die Baseline ist eine Chat-Last mit 128 Eingabe- und 128 Ausgabe-Token bei einer Nebenläufigkeit von 20 je LLM-GPU; längere RAG-Prompts verlangen deshalb einen Test dieser Verhältnisse.

Die Vektordatenbank und der Dokumentenspeicher brauchen CPU-Kerne, ECC-Speicher und NVMe statt GPUs. In derselben Baseline laufen die Query-Knoten von Milvus auf CPU, aufgeführt als zwei Knoten mit je 16 vCPU und 40 GiB und skaliert mit einem Knoten je 4 Millionen Vektoren bis 40 Millionen, und der RAG-Server, der Prompts aus den abgerufenen Passagen zusammensetzt, hat 16 vCPU und 64 GiB. Der Dokumentenspeicher hält die Quelldateien und den geparsten Text der Chunks.

Das Gateway ist der einzige Zugang für Nutzer und Anwendungen. Es prüft jeden Nutzer per Single Sign-on gegen den Verzeichnisdienst, setzt Schlüssel und Limits je Team durch und schreibt das Query-Log, wie unser Artikel zum LLM-Gateway mit Schlüsseln, Budgets und Protokollierung erklärt. Die Observability sammelt die Metriken der Serving-Engine und den Zustand der GPUs; NVIDIAs Observability-Leitfaden für seine Referenzarchitekturen, aktualisiert am 14. Juli 2026, nutzt Kube Prometheus und Grafana, mit dem DCGM Exporter unter seinen Datenquellen. Der Modellspeicher hält jeden genutzten Checkpoint und den vorherigen, zentral und auf NVMe in jedem GPU-Server, damit ein neu gestarteter Server von der lokalen Platte lädt. gpt-oss-120b ist ein Checkpoint von 65,3 GB, der bei der vollen Leitungsrate von 25 Gbit/s rund 21 Sekunden braucht, vor Protokoll-Overhead.

Rechenbeispiel: 2.000 Mitarbeiter auf zwei GPU-Servern

Unser Leitfaden zur Unternehmensgröße verwendet die Beispielwerte 40 Prozent Nutzer in der Spitzenstunde, je 6 Anfragen pro Stunde, 30 Sekunden je Anfrage und einen Spitzenfaktor von 2. Für 2.000 Mitarbeiter ergeben sie eine Spitze von 80 Anfragen in Bearbeitung. Mit gpt-oss-120b bei deklarierten 32K Kontext und einem 16-Bit-KV-Cache hält eine RTX PRO 6000 nach der Schätzung dieses Leitfadens rund 19 Gespräche und eine H200 NVL rund 55. Zwei Server, von denen jeder die Spitze allein trägt, brauchen fünf RTX PRO 6000 oder zwei H200 NVL je Server und halten 95 oder 110 Gespräche, wenn einer ausfällt.

GPU-Zahlen aus unseren Leitfäden zur Unternehmensgröße und zur Hochverfügbarkeit (gpt-oss-120b bei 32K, 16-Bit-KV-Cache, Spitze von 80 nach Beispielwerten); Ausfalltoleranz von etcd aus der FAQ zu etcd v3.6; die übrigen Zahlen sind Designentscheidungen des Beispiels.

Jeder Server muss jedes Modell des Dienstes halten; die Retrieval-Karte sitzt deshalb in beiden, und nach einem Ausfall trägt eine Karte die ganze Retrieval-Last. Unser Leitfaden zu Embedding- und Reranker-Servern für RAG schätzt aus NVIDIAs Zahlen, dass bei 40 Passagen je Anfrage eine L4 mit NVIDIAs 1B-Reranker rund 1,3 Anfragen pro Sekunde rerankt und eine L40S rund 4,3. Dieses Beispiel nimmt an, dass jede Anfrage in der Spitze eine RAG-Anfrage mit 40 Passagen ist. Dann treffen 80 Anfragen in Bearbeitung zu je 30 Sekunden mit rund 2,7 pro Sekunde ein, und das Beispiel plant deshalb eine L40S je Server. Mit weniger Passagen je Anfrage oder mit Retrieval nur bei einem Teil der Anfragen sinkt die Last proportional, und die L4, die unser Leitfaden zur Unternehmensgröße für die Qwen3-Modelle mit 0,6B vorsieht, trägt sie dann möglicherweise. Testen Sie die Karte mit Ihrem eigenen Reranker und Ihrer Passagenzahl.

Mit drei Servern halten die zwei, die nach einem Ausfall verbleiben, die Spitze mit je drei RTX PRO 6000 oder einer H200 NVL, neun Karten statt zehn oder drei statt vier. Unser Leitfaden zur Hochverfügbarkeit über zwei GPU-Knoten vergleicht diese Aufbauten.

KI-Server bauen wir auf Bestellung mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Schicken Sie uns Ihre Kopfzahl, Ihre Modelle und die Größe Ihres RAG-Korpus über das Formular unten, und wir liefern Konfiguration und Angebot innerhalb eines Werktages.

Was NVIDIAs Enterprise Reference Architectures beschreiben

NVIDIA beschreibt seine Enterprise Reference Architectures als „validierte, wiederholbare Designs“, die „Rechenleistung, Netzwerk, Storage und Software zusammenbringen“. Sein Design RTX PRO AI Factory, zuletzt aktualisiert am 18. Mai 2026, „basiert auf einer Infrastrukturkonfiguration 2-8-5-200 (2 CPUs, 8 GPUs, 5 NICs mit je 200 Gbit/s)“. Seine Beispiele haben 16 Knoten mit 128 GPUs und 32 Knoten mit 256.

Zwei seiner Entscheidungen lassen sich auf eine Plattform mit zwei oder drei GPU-Servern übertragen. Die erste sind separate Control-Plane-Knoten, denn „Control-Plane-Knoten werden benötigt, um die Software auszuführen, die den Cluster verwaltet und Nutzern Zugang bietet“. Sein Beispiel hat drei für die Kubernetes-Control-Plane neben denen für das Cluster-Management und Slurm, jeden mit zwei Prozessoren mit 32 Kernen und mindestens 256 GB Speicher. Die zweite sind separate Netzwerke, im Design benannt als Netzwerke für Compute East-West, Converged North-South und Out-of-Band-Management.

Die East-West-Fabric und die NICs mit 200 Gbit/s dienen Jobs, die sich über mehrere Knoten erstrecken, während eine Plattform, die eine Kopie des Modells je Karte betreibt, keine Anfrage über Servergrenzen hinweg schickt. Bei zwei oder drei GPU-Servern übernehmen virtuelle Maschinen die Control-Plane-Rollen.

Bare-Metal-Kubernetes oder virtuelle Maschinen für die CPU-Rollen

Im Beispiel sind die GPU-Server Bare-Metal-Worker-Knoten von Kubernetes. Die Serving-Engine sieht ganze Karten und MIG-Instanzen ohne Hypervisor-Schicht, und die Fragen nach Passthrough, vGPU-Profilen und deren Lizenzen stellen sich nicht. Kubernetes hält die CPU-Workloads mit Taints von diesen Servern fern, die laut seiner Dokumentation „es einem Knoten erlauben, eine Menge von Pods abzuweisen“; nur Pods mit passender Toleration, etwa die Serving-Engine und die Retrieval-Modelle, lassen sich dort platzieren. Die Software-Schichten auf diesen Knoten behandelt unser Leitfaden zu einer privaten LLM-Plattform auf Kubernetes.

Die CPU-Rollen passen in virtuelle Maschinen auf einem vorhandenen Virtualisierungscluster. Platzieren Sie die Replikate jeder Rolle mit Anti-Affinitätsregeln auf verschiedenen Hosts. Eine Control Plane in virtuellen Maschinen hängt dann von der Verfügbarkeit dieses Clusters ab, und etcd braucht eine Mehrheit seiner Mitglieder. Die FAQ zu etcd v3.6 hält fest: „Ein etcd-Cluster braucht eine Mehrheit der Knoten, ein Quorum, um sich auf Aktualisierungen des Cluster-Zustands zu einigen“, und ihre Tabelle gibt drei Mitgliedern eine Ausfalltoleranz von eins und zwei Mitgliedern keine.

Bare-Metal-CPU-Server für diese Rollen sind sinnvoll, wo kein geeigneter Virtualisierungscluster existiert oder wo die Plattform getrennt davon administriert werden muss.

Netzwerkzonen für eine On-Premise-KI-Plattform

Die Zonen sind unser Beispiel; NVIDIAs Design RTX PRO AI Factory nennt Netzwerke für Compute East-West, Converged North-South und Out-of-Band-Management.

Nutzerverkehr ist gestreamter Text und braucht wenig Bandbreite. Die größeren Datenflüsse sind Checkpoints, die vom Modellspeicher auf die GPU-Server kopiert werden, und Dokumente, die bei der Ingestion in die Datenzone wandern; diese beiden Pfade bekommen deshalb die schnellen Verbindungen. Die Modell-Endpunkte nehmen Anfragen nur vom Gateway und vom RAG-Server an, sodass Schlüssel, Limits und das Query-Log für jede Anfrage gelten. Das Query-Log enthält Prompts und Antworten; es liegt deshalb in der Datenzone, mit eingeschränktem Zugriff und einer festgelegten Aufbewahrungsfrist.

Vom Pilot mit 200 Mitarbeitern zu 2.000 Mitarbeitern

Mit denselben Beispielwerten erreicht ein Pilot mit 200 Mitarbeitern in der Spitze rund 8 Anfragen in Bearbeitung, 1.000 Mitarbeiter erreichen rund 40 und 2.000 Mitarbeiter 80. Die Rollen bleiben dieselben, und jede Phase ergänzt Karten und Kopien.

Spitzen nach den Beispielwerten unseres Leitfadens zur Unternehmensgröße, wie oben; Gespräche je Karte für gpt-oss-120b bei 32K mit einem 16-Bit-KV-Cache aus demselben Leitfaden.

Der Pilotserver entspricht dem Private-KI-Starter auf unserer Seite zu KI-Servern und hält rund 19 Gespräche gegenüber einer Spitze von 8, ohne Failover. Bei 1.000 Mitarbeitern hielten zwei Karten je Server 38 Gespräche, weniger als die Spitze von 40; diese Phase nimmt deshalb drei. Ein Gehäuse für acht GPUs, das für die zweite Phase gekauft wird, nimmt die Karten der dritten ohne neuen Server auf. Ersetzen Sie vor jedem Schritt die Beispielwerte durch Zahlen aus den Gateway-Logs der vorherigen Phase.

Unsere Leistung Private AI/ML startet mit einem Pilotprojekt auf einem Prozess mit klaren Metriken. Nennen Sie uns die Abteilung, die beginnen würde, und die Dokumentquellen, die ihr Assistent nutzen soll.

Wo die Disaster-Recovery-Kopie steht

N+1 in einem Serverraum schützt gegen den Verlust eines Servers, ein zweiter Standort gegen den Verlust des Raums. Die Disaster-Recovery-Kopie ist eine weitere Platzierung der Rollen an einem zweiten Standort; Vektorindex, Dokumente, Gateway-Konfiguration und Query-Log werden dorthin repliziert und die Modelle aus dem Modellspeicher kopiert. Ihre GPU-Kapazität hängt davon ab, welche KI-Dienste den Verlust eines Standorts überstehen müssen, und unser Artikel zu Disaster Recovery für eine private KI-Plattform behandelt diese Entscheidung.

Was wir liefern

Wir liefern die GPU-Server dieser Architektur als nach Auftrag gebaute KI-Server mit 2 bis 8 GPUs je Knoten: die RTX PRO 6000 Server Edition, die H200 NVL mit NVLink-Bridges sowie die L40S und die L4 für Retrieval, im Burn-in getestet und mit Herstellergarantie. NVIDIA-AI-Enterprise- und vGPU-Lizenzen kommen auf dieselbe Rechnung, unter einem EU-Vertrag. Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Die Plattform darüber, private LLMs, RAG, eine Kubernetes-basierte Plattform und die Protokollierung von Anfragen und Antworten, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ