KI-Agenten-Server für 100K Kontext: 4 oder 8 RTX PRO 6000 Server Edition oder H200 NVL

Welchen Server zehn KI-Agenten mit 100K Kontext brauchen

Für etwa zehn LLM-Agenten, die den ganzen Tag mit mehr als 100.000 Token Kontext arbeiten, bestimmt der KV-Cache die Größe des Servers stärker als das Modell. Mit Qwen3-235B-A22B in FP8 und Tensor-Parallelismus über vier Karten halten vier NVIDIA RTX PRO 6000 Blackwell Server Edition das Modell und 12 Agenten mit 100.000 Token, aber nur 9 mit 131.072, nach unserer Dimensionierungsregel mit FP8-Cache. Für zehn Agenten mit 128K und Reserve nehmen Sie acht Karten der Server Edition als zwei TP=4-Kopien, die 18 halten, oder vier H200 NVL an einer Vierer-NVLink-Brücke, die 23 halten.

Die Werte in diesem Artikel sind unsere Schätzungen, keine Messungen, für eine Anfrage, die wir oft sehen: Ein Labor oder ein Entwicklungsteam möchte etwa zehn Agenten den ganzen Tag Dokumente, Code oder Daten bearbeiten lassen, und zwar mit einem offenen Mixture-of-Experts-Modell, das mit TP=4 läuft.

Die Aufgabe in einfachen Worten

Ein Agent arbeitet in Schritten. Er ruft das Modell auf, führt ein Werkzeug aus, etwa eine Suche, ein Skript oder eine Datenbankabfrage, hängt das Ergebnis an seinen Kontext und ruft das Modell erneut auf. Nach einigen Stunden Arbeit trägt ein Agent 100.000 Token oder mehr mit sich: die Aufgabe, die gelesenen Dokumente, die Ausgaben der Werkzeuge und seine eigenen Notizen. Unser Leitfaden zur GPU-Dimensionierung für KI-Agenten erklärt, warum eine Agentenaufgabe ein Vielfaches der Token eines Chats sendet.

Die GPU hält für jedes Token jedes offenen Agenten ein Arbeitsgedächtnis vor, den KV-Cache. Bei einem Chat-Assistenten mit Konversationen von 8.000 Token ist er klein; bei zehn Agenten mit 128.000 Token sind es 1,3 Millionen Token gleichzeitig, die bei diesem Modell in 16 Bit mehr GPU-Speicher belegen als das Modell selbst. Jedes neue Token liest außerdem den ganzen Cache, langer Kontext verlangsamt also jeden Schritt. Deshalb geht es bei dieser Aufgabe um Speicher je Agent und um Bandbreite, und die Kartenzahl folgt daraus.

Vier Optionen im Überblick

Agenten mit voller Kontextlänge je Server, Qwen3-235B-A22B-Instruct-2507 in FP8, FP8-KV-Cache (16-Bit-Cache in Klammern); 100K = 100.000 und 128K = 131.072 Token. Unsere Schätzung nach der Dimensionierungsregel unten, keine Messung.

Mit FP8-Cache tragen acht Karten der Server Edition und vier H200 NVL beide zehn Agenten mit 128K und haben Reserve. Zeigt Ihre Evaluierung, dass das Modell einen 16-Bit-Cache braucht, halten nur die Konfigurationen mit H200 NVL zehn Agenten bei 128K. Vier Karten der Server Edition tragen zehn Agenten bei 100K mit FP8-Cache und wenig Spielraum; sie sind der richtige Einstieg, wenn die Kontexte bei dieser Länge bleiben.

Warum bei langem Kontext der KV-Cache den Server bestimmt

Für ein Modell mit voller Attention in jeder Schicht beträgt der Cache je Token 2 × Schichten × KV-Heads × Head-Dimension × Byte je Wert. Die config.json von Qwen3-235B-A22B-Instruct-2507-FP8 auf Hugging Face nennt 94 Schichten, 4 KV-Heads und eine Head-Dimension von 128; ein Token belegt also 188 KiB in 16 Bit und 94 KiB in FP8. Laut Modellkarte beträgt der native Kontext 262.144 Token, und das vLLM-Beispiel dort nutzt --tensor-parallel-size 4.

Unsere Rechnung aus der config.json des Modells, gelesen am 24. Oktober 2026. Der FP8-Checkpoint umfasst auf Hugging Face 236 GB, also 219,8 GiB.

Unsere Dimensionierungsregel nimmt 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB je Karte und abzüglich der Gewichte: 83,0 GiB nutzbar je RTX PRO 6000 und 123,4 GiB je H200 NVL. Vier Karten der Server Edition ergeben 332,2 GiB, neben den Gewichten bleiben 112,4 GiB für den Cache; vier H200 NVL ergeben 493,4 GiB und lassen 273,6 GiB. Geteilt durch den Cache je Agent ergibt das die Tabelle oben. Den FP8-Cache aktivieren Sie in vLLM mit --kv-cache-dtype fp8; prüfen Sie die Antwortqualität damit an Ihrem eigenen Evaluierungsdatensatz, bevor Sie darauf dimensionieren.

TP=4 passt zu diesem Modell. Mit vier KV-Heads hält jede Karte einen Head, der Cache teilt sich gleichmäßig auf. Auf acht Karten hielte eine TP=8-Instanz nicht mehr Agenten als zwei TP=4-Kopien: Laut der vLLM-Dokumentation zu Context Parallel wird der Cache, sobald TP die Zahl der KV-Heads übersteigt, „tp_size / H-mal dupliziert“. Decode Context Parallelism (--decode-context-parallel-size) kann diese Duplizierung aufheben und nach unserer Rechnung die Agentenzahl einer einzelnen TP=8-Instanz etwa verdoppeln, und der Qwen3-Leitfaden von vLLM verlangt bei TP=8 für MoE-Checkpoints in FP8 --enable-expert-parallel. Testen Sie dieses Layout im Pilotbetrieb, bevor Sie damit rechnen. Unser Leitfaden zur RTX PRO 6000 ohne NVLink erklärt, was TP=4 über PCIe schickt.

Wie langer Kontext jeden Agenten bremst

Beim Decodieren liest die GPU für jedes neue Token die aktiven Gewichte und den ganzen Cache jedes Agenten im Batch. Qwen3-235B-A22B aktiviert 22 Milliarden Parameter je Token, in FP8 etwa 22 GB, und jeder Agent fügt seinen eigenen Cache hinzu. In einem Batch werden die Token der Agenten an unterschiedliche Experten geleitet, ein Schritt liest also mehr Gewichte als ein einzelnes Token; unsere Rechnung zählt nur die 22 GB, jeder Wert unten ist deshalb nach unserer Schätzung eine Obergrenze. Speicherbandbreite geteilt durch die je Schritt gelesenen Bytes ergibt eine Obergrenze je Agent.

Unsere Obergrenzen-Rechnung: 1.597 GB/s je RTX PRO 6000 Server Edition und 4,8 TB/s je H200 NVL (NVIDIA), FP8-Gewichte und FP8-Cache, TP=4; jeder Wert ist nach unserer Schätzung eine Obergrenze. Reale Werte liegen darunter: All-Reduce-Verkehr, Attention-Rechenzeit und Prefill neuer Werkzeugergebnisse sind nicht eingerechnet.

Das Muster zählt mehr als die einzelnen Werte: Bei 100K fügt der Cache von zehn Agenten jedem Decodierschritt etwa 24 GB je Karte hinzu, bei 8K etwa 2 GB, und die Bandbreite der H200 NVL wirkt vor allem bei langem Kontext. Eine veröffentlichte Messung zeigt dieselbe Richtung. In einem Aufbau-Log im Level1Techs-Forum vom Juli 2026 lief DeepSeek-V4-Flash unter SGLang mit TP=4 auf vier RTX PRO 6000 Max-Q mit 300 W: 697 erzeugte Token pro Sekunde bei Eingaben von 2.048 Token und 80 gleichzeitigen Anfragen, 39 Token pro Sekunde bei Eingaben von 65.536 Token und 24 gleichzeitigen Anfragen.

Der zweite Kostenblock ist der Prefill. Jeder Schritt bringt ein Werkzeugergebnis, das das Modell berechnen muss, und ein Cache-Fehltreffer bedeutet, den ganzen Kontext neu zu berechnen. Das Prefix Caching von vLLM hält frühere Schritte wiederverwendbar, wie unser Leitfaden zu Hardware für langen Kontext erklärt; der Anteil der Treffer gehört deshalb zu den ersten Werten, die Sie messen.

Wir bauen Inferenzserver mit vier oder acht GPUs für solche Lasten; schicken Sie uns Modell, Kontextlänge je Agent und Zahl der Agenten, und unser Team antwortet mit Cache-Budget, Konfiguration und Angebot.

Vier oder acht RTX PRO 6000 Server Edition

Der Inferenzknoten auf unserer Seite zu KI-Servern ist mit vier Karten der RTX PRO 6000 Server Edition mit zwei AMD-EPYC-Prozessoren, 768 GB DDR5-ECC-Speicher und vier NVMe-Laufwerken bestückt. Für diese Aufgabe hält er das FP8-Modell und zehn Agenten bis 100K als eine TP=4-Instanz. Alles läuft über eine Kopie: Ein Kartenfehler oder ein hängender Prozess stoppt alle Agenten, und die All-Reduces von TP=4 laufen über PCIe mit NCCL.

Mit acht Karten laufen zwei TP=4-Kopien des Modells, jede an einem Prozessorsockel, hinter einem Load Balancer mit Session-Affinität, damit jeder Agent zu der Kopie mit seinem Cache zurückkehrt. Das verdoppelt die Agenten auf 18 bei 128K, und eine Kopie arbeitet weiter, während die andere gewartet wird. Server mit acht Karten bauen wir auf Bestellung nach denselben Plattformregeln: zwei Sockel, mindestens sechs Prozessorkerne je GPU und Arbeitsspeicher mit dem Doppelten des GPU-Speichers, wie es NVIDIAs Leitfaden für zertifizierte Systeme vorgibt.

Vier oder acht H200 NVL mit NVLink

Die H200 NVL hat 141 GB HBM3e mit 4,8 TB/s, die dreifache Bandbreite der RTX PRO 6000 Server Edition, und NVIDIAs H200-Seite nennt Zweier- oder Vierer-NVLink-Brücken mit 900 GB/s je GPU gegenüber 128 GB/s für PCIe Gen5. Vier H200 NVL an einer Vierer-Brücke betreiben die TP=4-Instanz mit ihren All-Reduces über NVLink und halten 23 Agenten bei 128K mit FP8-Cache oder 11 mit 16-Bit-Cache. Die Karte rechnet FP8 nativ, hat aber keine FP4-Arithmetik, was für diesen FP8-Checkpoint keine Rolle spielt, und NVIDIA legt ihr ein Abonnement für NVIDIA AI Enterprise über fünf Jahre bei.

Acht H200 NVL bilden zwei Vierer-Domänen, zwei TP=4-Kopien mit NVLink innerhalb jeder Domäne, für etwa 46 Agenten bei 128K. Das ist der Trainingsknoten auf unserer Seite zu KI-Servern: acht H200 NVL mit NVLink-Brücken, zwei AMD-EPYC-Prozessoren, 2,3 TB DDR5-ECC, acht NVMe-Laufwerke und 400G-Netzwerk. Er lässt neben den Agenten auch Raum für Fine-Tuning. Unser Vergleich von RTX PRO 6000 und H200 NVL für LLM-Inferenz behandelt die Karten genauer.

Warum Server Edition und nicht Max-Q in diesem Rack

Die RTX PRO 6000 Max-Q Workstation Edition ist die Workstation-Karte: 300 W, aktive Kühlung und laut NVIDIA „für dichte Workstation-Konfigurationen (bis zu vier GPUs) optimiert“. Die Server Edition ist passiv gekühlt und laut NVIDIA „für Multi-GPU-Server mit passiver Kühlung“ ausgelegt. Ihr Product Brief SP-12355-001 (Juni 2025) nennt den Luftstrom, den sie am Kühlkörper braucht, von 43 CFM bei 25 °C Zuluft bis 125 CFM bei 45 °C, also den Luftstrom, für den die Lüfter eines GPU-Servers gebaut sind.

Viele Serverhersteller listen die Max-Q für ihre GPU-Server nicht. Lenovos Produktleitfaden LP2364 nennt sie für zwei ThinkSystem-Server und führt alle anderen als nicht unterstützt, Supermicro führt sie auf der GPU-Liste des SYS-422GA-NRT, nennt dort aber keine Anzahl für die Max-Q (die acht Karten gelten der Server Edition). Die Server Edition steht außerdem auf NVIDIAs vGPU-Liste, und ihr Power-Limit, laut Brief 300 W bis 600 W, lässt sich out-of-band so setzen, dass es nach einem Neuladen des Treibers erhalten bleibt. Auf dem Papier hat die Max-Q mehr Speicherbandbreite, 1.792 gegenüber 1.597 GB/s, was die Obergrenzen oben um etwa 12 Prozent anheben würde. Für einen Agenten-Server, der den ganzen Tag im Rack läuft, zählt mehr, dass der Hersteller das Gehäuse mit genau dieser Karte validiert hat. Vier Karten mit 600 W ziehen 2,4 kW und acht 4,8 kW, ohne den Host; an der Steckdose sind es mit zwei AMD EPYC 9355 oder zwei EPYC 9555 und 15 Prozent für den Rest des Servers nach unserer Schätzung etwa 3,4 kW und 6,3 kW. Planen Sie die Zuleitung nach der Netzteilangabe des Serverherstellers, wie unser Artikel zu Strom und Kühlung im GPU-Rack erklärt.

Arbeitsspeicher und KV-Cache-Offloading

NVIDIAs Leitfaden für zertifizierte Systeme, aktualisiert am 30. September 2026, setzt den Arbeitsspeicher auf mindestens das Doppelte des GPU-Speichers: 768 GB für vier RTX PRO 6000 Server Edition, 1.536 GB für acht, 1.128 GB für vier H200 NVL und 2.256 GB für acht; wir bestücken sie mit 1.152 GB und 2,3 TB. Bei Agenten hat dieser Speicher eine zweite Aufgabe.

Agenten pausieren, während ihre Werkzeuge laufen, und die Engine kann den Cache eines wartenden Agenten verdrängen, um Platz für andere zu schaffen. KV-Cache-Offloading hält diese Blöcke im CPU-Speicher, sodass der Agent weiterarbeitet, ohne 100.000 Token Prefill neu zu berechnen. Laut dem Offloading-Leitfaden von vLLM vom 22. Oktober 2026 „erweitert der Connector den Prefix-Cache, indem er fertige KV-Blöcke in langsamere, aber größere Stufen auslagert“; er empfiehlt eine CPU-Stufe, die größer ist als der gesamte KV-Cache der GPUs, weil eine kleinere nur spiegelt, was die GPU ohnehin hält, und keine zusätzlichen Treffer bringt.

Für vier Karten der Server Edition mit 112,4 GiB GPU-Cache hält eine CPU-Stufe von 256 GiB nach unserer Rechnung etwa 21 Agentenkontexte mit 128K in FP8. Von 768 GB, etwa 715 GiB, bleibt dann Platz für den Page-Cache des 219,8 GiB großen Checkpoints und etwa 240 GiB für Betriebssystem, die Werkzeuge der Agenten und einen Suchindex. Jede Karte lädt ihr Viertel eines 128K-Kontexts, etwa 3,2 GB, frühestens in etwa 50 ms zurück, bei den 64 GB/s, die PCIe 5.0 x16 je Richtung überträgt. Bei acht Karten planen Sie die 1.536 GB nach NVIDIAs Regel und eine Stufe je Kopie. Optionen und Parameter stehen in unserem Leitfaden zum KV-Cache-Offloading in CPU-Speicher und NVMe, die Dimensionierung des Hosts in unserem Leitfaden zu CPU, RAM und Speicher für einen Server mit vier GPUs.

Unser Engineering-Partner Vixen.UNO setzt vLLM und Agenten-Workflows im Rahmen unseres Private-AI/ML-Service on-premise auf; beschreiben Sie, wie lange Ihre Agenten laufen und wie lange ihre Werkzeuge pausieren, und wir dimensionieren GPU, Arbeitsspeicher und NVMe zusammen.

Was Sie im Pilotbetrieb messen

Ein Pilot mit dem geplanten Modell und aufgezeichneten Agentenaufgaben macht aus diesen Schätzungen Ihre eigenen Werte. Die Methode beschreibt unser Leitfaden dazu, was ein Private-AI-Pilot messen sollte; für Agenten mit langem Kontext entscheiden diese Werte zwischen vier und acht Karten.

1. Kontext je Aufruf im letzten Schritt einer Aufgabe und wie er über einen Arbeitstag wächst, aus dem Log des Gateways.
2. Trefferquote des Prefix-Caches, aus vllm:prefix_cache_hits geteilt durch vllm:prefix_cache_queries.
3. Druck auf den Cache: vllm:kv_cache_usage_perc nahe 1 und jeder Anstieg von vllm:num_preemptions, der bedeutet, dass Anfragen ihren Cache verloren haben.
4. Zeit bis zum ersten Token je Schritt (vllm:time_to_first_token_seconds) und Latenz zwischen Token (vllm:inter_token_latency_seconds) in der Spitzenstunde.
5. Antwortqualität mit FP8-Cache gegenüber 16-Bit-Cache an Ihrem eigenen Evaluierungsdatensatz.
6. Pausenlängen der Werkzeuge, aus denen folgt, wie viel Offload-Speicher die Agenten warm hält.
7. Stabilität der TP=4-Instanz über mehrere Tage, mit der geplanten Engine-Version und dem geplanten Treiber.

Unser Leitfaden zu Monitoring-Metriken von vLLM erklärt, wie Sie diese Werte mit Prometheus erfassen.

FAQ