Privater ChatGPT-Server für 100, 500 oder 2.000 Mitarbeiter: KI-Server nach Unternehmensgröße auslegen

So legen Sie einen privaten ChatGPT-Server für Ihr Unternehmen aus

Ein privater ChatGPT-Server, also ein KI-Server für das ganze Unternehmen, wird nach der Spitzenzahl der Anfragen in Bearbeitung ausgelegt, und von der Zahl der Mitarbeiter kommen Sie in drei Schritten dorthin. Schätzen Sie, wie viele Mitarbeiter den Assistenten in der Spitzenstunde nutzen, rechnen Sie ihre Anfragen mit der Dauer jeder Anfrage in Anfragen in Bearbeitung um und prüfen Sie, ob die GPUs die Gewichte des Modells und zusätzlich einen KV-Cache für jede Anfrage in dieser Spitze fassen. Mit gpt-oss-120b bei deklarierten 32K Kontext hält eine RTX PRO 6000 rund 19 Gespräche und eine H200 NVL rund 55, nach der Schätzung in unserem Beitrag zu den LLM-Hardware-Anforderungen je Modell.

Mit den Beispielwerten unten ergibt das für 100 Mitarbeiter eine Kopie des Modells auf einer Karte, für 500 zwei Kopien und für 2.000 fünf Kopien auf RTX PRO 6000 oder zwei Kopien auf H200 NVL. Ab 500 Mitarbeitern hält jeder von zwei Servern die ganze Spitze, damit einer ausfallen kann, und jede Größe ergänzt Kapazität für die RAG-Modelle. Die Nutzungszahlen sind Beispiele, die Sie durch Ihre eigenen ersetzen, und die Speicherzahlen sind unsere Schätzungen, keine Messungen.

Von Mitarbeitern zu Nutzern der Spitzenstunde und Anfragen in Bearbeitung

Der erste Schritt ist der Anteil der Mitarbeiter, die den Assistenten in der Spitzenstunde nutzen. Wir haben kein veröffentlichtes Verhältnis zwischen Mitarbeiterzahl und aktiven oder gleichzeitigen Nutzern gefunden, und keines der Sizing-Dokumente von NVIDIA, die wir gelesen haben, setzt eines voraus. NVIDIAs Blog zu den Kosten der LLM-Inferenz vom Juni 2025 macht einen verwandten Punkt zur Nebenläufigkeit: „Beachten Sie, dass dies nicht dasselbe ist wie die Zahl gleichzeitiger Nutzer, weil nicht alle zur selben Zeit eine aktive Anfrage haben.“ Der Blog legt stattdessen nach der Spitzenzahl der Anfragen pro Sekunde und nach Latenzzielen aus.

Der zweite Schritt rechnet Nutzer in Anfragen in Bearbeitung um. Das Gesetz von Little aus der Warteschlangentheorie besagt, dass die mittlere Zahl der Elemente in einem System gleich der Ankunftsrate mal der mittleren Verweildauer jedes Elements darin ist. Für einen Assistenten sind das die Anfragen pro Sekunde in der Spitzenstunde mal die Ende-zu-Ende-Latenz einer Anfrage, vom Absenden bis zum letzten Token. Ein Spitzenfaktor hebt dann den Stundenmittelwert auf die stärksten Minuten an.

Wir verwenden in diesem ganzen Artikel die folgenden Beispielwerte. Sie sind keine Marktstatistik, und ein Pilot ersetzt jeden davon durch eine Zahl aus seinen Gateway-Logs.

1. Nutzer in der Spitzenstunde: 40 Prozent der Mitarbeiter (Beispielwert).
2. Anfragen je Nutzer in der Spitzenstunde: 6 pro Stunde (Beispielwert).
3. Zeit in Bearbeitung: 30 Sekunden je Anfrage, Reasoning-Token eingeschlossen (Beispielwert).
4. Spitzenfaktor: 2-mal der Stundenmittelwert (Beispielwert).

Bei 500 Mitarbeitern senden 200 Nutzer 1.200 Anfragen pro Stunde, also eine alle 3 Sekunden. Bei je 30 Sekunden sind im Mittel 10 Anfragen in Bearbeitung und in der Beispielspitze 20. Die Zeit in Bearbeitung hängt von GPU, Engine und Last ab; messen Sie sie deshalb auf dem GPU-Typ, den die Produktion nutzen wird, wie unser Leitfaden dazu erklärt, was ein privater KI-Pilot messen sollte. Eine langsamere Test-GPU zeigt bei gleichem Verkehr mehr Anfragen in Bearbeitung.

Speicher je Gespräch und Gespräche je Karte

Der dritte Schritt ist der Speicher. Jede Anfrage in Bearbeitung hält einen KV-Cache auf der GPU, und die Karten müssen ihn neben den Gewichten fassen. Unsere Auslegungsregel, dieselbe wie in unserem Leitfaden dazu, wie viele Nutzer eine RTX PRO 6000 bedient, nimmt 90 Prozent des Speichers, den der Treiber meldet, abzüglich rund 3 GiB je Karte, abzüglich der Gewichte. Der Treiber meldet 95,6 GiB auf einer RTX PRO 6000 mit 96 GB und 140,4 GiB auf einer H200 NVL mit 141 GB.

gpt-oss-120b mit 117B Parametern, davon 5,1B aktiv, ist ein Checkpoint von 65,3 GB mit Expertengewichten in MXFP4, rund 60,8 GiB. OpenAIs Model Card ordnet es Anwendungsfällen zu, „die auf eine einzelne 80-GB-GPU passen“. Seine config.json nennt 36 Schichten, von denen 18 ihre Attention über ein Fenster von 128 Token und 18 über den ganzen Kontext berechnen, mit 8 Key-Value-Köpfen der Dimension 64. Ein Token kostet deshalb in den Schichten mit voller Attention 36 KiB 16-Bit-Cache, und ein Gespräch mit 32K kostet 1,125 GiB.

Unsere Schätzungen für gpt-oss-120b mit 16-Bit-KV-Cache, eine Kopie je Karte: 0,9 × vom Treiber gemeldeter Speicher, abzüglich 3 GiB, abzüglich 60,8 GiB Gewichte; Schichten und Köpfe aus der config.json des Modells auf Hugging Face, abgerufen am 9. Oktober 2026.

Das sind Gespräche, die im selben Moment bis zur deklarierten Länge gefüllt sind, und kürzere lassen Platz für mehr. Sie begrenzen nur den Speicher, und die Antwortzeit unter Last braucht einen eigenen Test. NVIDIAs Blog zum Benchmarking vermerkt, dass ein ausgelastetes System durch Batching mehr Anfragen bedient, aber „dies geht auf Kosten einer höheren Latenz“. Für den Fall, dass der Cache nicht reicht, schreibt vLLMs Tuning-Leitfaden: „Es gibt Situationen, in denen der KV-Cache-Speicher nicht ausreicht, um alle gebatchten Anfragen zu verarbeiten“; vLLM verdrängt dann Anfragen und berechnet sie später neu. Unser Leitfaden zur Hardware für gpt-oss-120b behandelt die Varianten des Modells.

Rechenbeispiele für 100, 500 und 2.000 Mitarbeiter

Das Modell passt auf eine Karte, mehr Kapazität kommt deshalb aus Kopien, einer vLLM-Instanz je Karte hinter einem Load Balancer, statt aus der Aufteilung des Modells. Jede Größe unten zählt die Kopien, die die Beispielspitze braucht, und verteilt sie ab 500 Mitarbeitern auf zwei Server, von denen jeder die ganze Spitze hält, sodass der Dienst den Ausfall eines Servers übersteht.

Nutzer und Spitzen aus den Beispielwerten oben (40 Prozent, 6 Anfragen pro Stunde, 30 Sekunden, Spitzenfaktor 2); Sitzungen nach unserer Speicherschätzung für gpt-oss-120b bei 32K aus der Tabelle oben.

Bei 100 Mitarbeitern liegt die Spitze von 4 weit unter den 19 Gesprächen, die eine Karte hält; eine Karte trägt also das Modell, und die zweite wird in MIG-Instanzen mit 24 GB für das Embedding-Modell, den Reranker und ein kleines Task-Modell aufgeteilt. Failover braucht bei dieser Größe einen zweiten Server derselben Bauart. Solange das Modell noch ausgewählt wird, hält ein DGX Spark (128 GB) gpt-oss-120b mit etwa 30 Gesprächen bei 32K im Speicher, aber seine Speicherbandbreite von 273 GB/s macht ihn zu einer Maschine für Pilot und Entwicklung und nicht zum Produktivserver.

Bei 500 Mitarbeitern brauchen 20 Anfragen in der Spitze zwei Kopien, und zwei Server mit je zwei Karten halten vier. Fällt ein Server aus, hält der andere noch 38 Gespräche. Bei 2.000 Mitarbeitern brauchen 80 Anfragen fünf Kopien auf RTX PRO 6000 oder zwei Kopien auf H200 NVL. Zwei Server mit je zwei H200 NVL halten 110 Gespräche, wenn einer ausfällt, und zwei Server mit je fünf RTX PRO 6000 halten 95. Mit vier RTX PRO 6000 je Server hielte der verbleibende Server 76, weniger als die Beispielspitze von 80.

Verlangt der Evaluationssatz ein größeres Modell, etwa DeepSeek-V4-Flash unter der MIT-Lizenz, legt unser Überblicksbeitrag eine Kopie mit Tensor-Parallelismus auf zwei RTX PRO 6000. Seine Konfiguration hat einen Key-Value-Kopf, und vLLMs Blog vom 7. August 2026 vermerkt: „Sobald TP die Zahl der KV-Köpfe übersteigt, beginnt der Cache, sich über die GPUs hinweg zu duplizieren.“ Jede Karte einer Kopie hält deshalb den ganzen Cache in den rund 5,3 GiB, die neben ihrer Hälfte der 167 GB großen Gewichte von -0731 frei bleiben, nach unserer Schätzung Platz für rund 43 Gespräche zu je 0,12 GiB im FP8-Cache, den vLLMs Rezept setzt. Zwei Kopien decken die Beispielspitze von 80, und zwei Server mit je vier Karten halten sie, wenn einer ausfällt.

Inferenzserver bauen wir mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Schicken Sie uns über das Formular unten Ihre Mitarbeiterzahl, die Anwendungsfälle und die Modelle, die Sie in Betracht ziehen, und wir legen den Server danach aus.

Embedding-Modelle, Reranker und Index-Storage für RAG

Ein Assistent, der aus Unternehmensdokumenten antwortet, braucht zusätzlich ein Embedding-Modell, meist einen Reranker und einen Vektorindex, jedes mit eigenem Speicher. Die Serien Qwen3 Embedding und Reranker unter Apache 2.0 gibt es in den Größen 0,6B, 4B und 8B mit einer Sequenzlänge von 32K. Das 0,6B-Embedding-Modell liefert Vektoren mit 1.024 Dimensionen, das 8B-Modell bis zu 4.096. In BF16 belegen die Gewichte rund 1,2 GB bei einem 0,6B-Modell und rund 16 GB bei einem 8B-Modell, gerechnet als Parameter mal zwei Byte, vor Aktivierungen.

Die beiden 0,6B-Modelle passen auf jede der kleinen Karten, die wir liefern, von der RTX PRO 2000 mit 16 GB bis zur L4 und RTX PRO 4000 mit 24 GB. Das 8B-Paar braucht rund 32 GB Gewichte, was auf die L40S mit 48 GB hinweist oder auf zwei MIG-Instanzen mit 24 GB auf einer RTX PRO 6000. NVIDIAs MIG-Leitfaden, aktualisiert am 11. September 2026, nennt bis zu vier Instanzen auf jeder Edition der RTX PRO 6000 und sieben auf der H200 NVL. MIG hilft bei diesen kleinen Modellen und bei einem Task-Modell für Chat-Titel und Tags, aber nicht bei gpt-oss-120b, dessen 60,8 GiB die ganze Karte brauchen. Unser Leitfaden zur privaten ChatGPT-Alternative erklärt, warum die Hintergrundaufgaben des Frontends auf einem eigenen Modell laufen sollten.

Der Index braucht schnellen Storage, ausgelegt nach dem Korpus. Bei vier Byte je Wert belegen eine Million Chunks mit Vektoren aus 1.024 Dimensionen rund 4,1 GB vor Indexstrukturen und Chunk-Text, und 4.096 Dimensionen belegen das Vierfache. Planen Sie NVMe-Platz für den Index, die Quelldokumente, jeden Modell-Checkpoint, den Sie behalten, und das Query-Log ein.

Was die Größe verändert

Kontextzahlen aus der Tabelle oben; Reasoning-Stufen aus OpenAIs Model Card zu gpt-oss-120b; Frontend-Aufgaben aus unserem Leitfaden zur privaten ChatGPT-Alternative.

Der deklarierte Kontext wirkt am stärksten auf den Speicher, das Reasoning stark auf die Zeit. OpenAIs Model Card beschreibt die Reasoning-Stufen von gpt-oss von „Low: schnelle Antworten für allgemeine Dialoge“ bis „High: tiefe und detaillierte Analyse“, festgelegt im System-Prompt. Reasoning-Token werden wie jede Antwort erzeugt, eine hohe Stufe hält jede Anfrage also länger in Bearbeitung und erhöht bei gleicher Anfragerate die Nebenläufigkeit. Messen Sie die Zeit in Bearbeitung auf der Stufe, mit der jeder Anwendungsfall laufen wird.

Die Schätzung im Piloten prüfen

Jedes Ergebnis oben hängt von den Beispielwerten ab; ersetzen Sie sie also, bevor Sie Hardware bestellen. Führen Sie einen Piloten mit einer Abteilung durch, protokollieren Sie jede Anfrage am Gateway mit Start- und Endzeit und nehmen Sie die Ankunftsrate der stärksten Stunde und die Verteilung der Prompt- und Antwortlängen. Testen Sie dann die infrage kommende GPU unter Last in der erwarteten Spitze mit den eigenen Prompts des Piloten und prüfen Sie die Zeit bis zum ersten Token und die Geschwindigkeit je Nutzer gegen Ziele, die Sie vor dem Test festgelegt haben. Rechnen Sie die Ankunftsrate auf die gesamte Mitarbeiterzahl hoch, nicht die Nebenläufigkeit, die der Pilot gezeigt hat.

Wenn Sie den Piloten für sich planen und messen lassen wollen, startet unsere Leistung Private AI/ML mit einem Pilotprojekt auf einem Prozess mit klaren Metriken. Schreiben Sie uns, welchen Prozess er abdecken soll und wie viele Mitarbeiter den Assistenten nutzen würden.

Was wir liefern

Wir liefern die RTX PRO 6000 als Workstation, Max-Q und Server Edition, die H200 NVL mit NVLink-Bridges, die DGX Spark Founders Edition und die kleinen Karten für RAG-Modelle: die L4, die L40S und die RTX PRO 2000, 4000 und 4500. Sie kommen als Karten oder in nach Auftrag gebauten KI-Servern mit 2 bis 8 GPUs je Knoten, im Burn-in getestet, mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen, und liefern Konfiguration und Angebot innerhalb eines Werktages. Modelle, RAG und die Plattform darüber sind unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ