Server für Coding-Agenten: 2, 4 oder 8 RTX PRO 6000 Server Edition, 20 bis 100 Entwickler

Welchen Server 20 bis 100 Entwickler für Coding-Agenten brauchen

Für 20 bis 100 Entwickler, die Coding-Agenten mit offenen Modellen nutzen, deckt ein Server mit zwei, vier oder acht Karten der NVIDIA RTX PRO 6000 Blackwell Server Edition den Bedarf ab; die Kartenzahl richtet sich danach, wie viele Agenten gleichzeitig Text erzeugen und wie lang ihre Kontexte werden. Zwei Karten mit Qwen3-Coder-Next tragen höchstens etwa 35 Agentensitzungen mit 64K Token bei geplanten 50 Token pro Sekunde je Sitzung, vier Karten etwa 70 und acht Karten etwa 140; das ist nach unserer Schätzung eine Obergrenze, die ein Pilot bestätigt.; ein FP8-Cache verdoppelt jeden Wert ungefähr.

Ein Team, das das größte Qwen-Coding-Modell Qwen3-Coder-480B-A35B einsetzen will, braucht acht Karten für höchstens 13 bis 26 Sitzungen oder acht H200 NVL für 34 bis 69. Unser Leitfaden zum privaten Coding-Assistenten behandelt Modellwahl, Lizenzen, Completion-Modelle, IDE-Erweiterungen und die erste Stufe vom DGX Spark bis zu einer oder zwei Karten. Diese Seite setzt dort an, wo jener endet: bei einer Entwicklungsabteilung mit 20 bis 100 Personen, in der mehrere Dutzend Agenten gleichzeitig arbeiten und sich die Frage nach dem Server stellt.

Die Aufgabe in einfachen Worten

Ein Coding-Agent arbeitet eine Aufgabe in Schritten ab. Er liest Dateien, startet einen Build oder die Tests, liest die Ausgabe und ruft das Modell erneut mit allem auf, was er bis dahin gesehen hat. Nach einer Stunde Arbeit enthält der Prompt jedes Aufrufs Zehntausende Token. Das Modell hält für jedes Token jeder offenen Sitzung ein Arbeitsgedächtnis vor, den KV-Cache, und jedes neue Token liest den ganzen Cache seiner Sitzung erneut.

Für den Server folgen daraus zwei Werte. Der erste ist, wie viele Sitzungen neben dem Modell in den GPU-Speicher passen. Der zweite ist, wie viele davon gleichzeitig Text erzeugen können, bevor jede unter eine brauchbare Geschwindigkeit fällt, denn jede Sitzung fügt jedem Schritt die Bytes ihres Caches hinzu. Der kleinere der beiden Werte entscheidet, wie viele Entwickler der Server trägt.

Entwickler sind keine Sitzungen. Viele nutzen Agenten nur einen Teil des Tages, manche lassen zwei Agenten parallel laufen. Unsere Regel zählt eine erzeugende Sitzung je Entwickler in der Spitzenstunde, die Obergrenze für ein Team, in dem jeder Entwickler mit einem Agenten arbeitet. Das Gateway-Log eines Piloten liefert den echten Anteil, und bei einem kleineren Anteil reicht derselbe Server für mehr Personen.

Kontextlänge je Sitzung: 64K, 128K oder 256K

Die Dokumentation von Ollama verlangt für Agenten und Coding-Werkzeuge mindestens 64.000 Token Kontext, und die Qwen3-Coder-Modelle haben einen nativen Kontext von 262.144 Token. Wir dimensionieren bei 64K (65.536 Token) und bei 128K (131.072), den Längen, mit denen Agenten auf großen Repositories meist arbeiten, und lassen 256K den wenigen Sitzungen, die diese Länge brauchen.

Der Cache je Token beträgt 2 × Schichten mit voller Attention × KV-Heads × Head-Dimension × Byte je Wert, mit den Zahlen aus der config.json jedes Modells auf Hugging Face. Modelle mit voller Attention in nur einem Teil ihrer Schichten brauchen deutlich weniger.

Repository-Größen von Hugging Face, gelesen am 24. Oktober 2026 (gpt-oss-120b: die 15 safetensors-Dateien im Hauptverzeichnis). Cache in BF16 nach unserer Rechnung aus der jeweiligen config.json; ein FP8-Cache halbiert ihn. Qwen3-Coder-Next fügt je Sitzung bis zu etwa 80 MiB Zustand der linearen Attention hinzu.

Qwen3-Coder-480B-A35B hat 62 Schichten mit 8 KV-Heads der Dimension 128, das ergibt 248 KiB je Token. Qwen3-Coder-Next, ein 80B-Modell mit 3B aktiven Parametern, hält einen Cache je Token nur in jeder vierten seiner 48 Schichten, mit 2 KV-Heads der Dimension 256, also 24 KiB je Token. gpt-oss-120b nutzt in 18 seiner 36 Schichten ein gleitendes Fenster von 128 Token und in den anderen 18 volle Attention, mit 8 KV-Heads der Dimension 64, und sein Kontext endet bei 131.072 Token. Alle vier stehen unter Apache 2.0.

Zwei Grenzen: Speicher und Geschwindigkeit je Sitzung

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. Zwei Karten ergeben 166,1 GiB, vier 332,2 GiB und acht 664,3 GiB. Der Platz neben den Gewichten, geteilt durch den Cache je Sitzung, ergibt die Sitzungen, die in den Speicher passen.

Die Geschwindigkeit ist die zweite Grenze. Jeder Decodierschritt liest die aktiven Gewichte und den Cache jeder Sitzung im Batch; die Bandbreite einer Karte geteilt durch die je Schritt gelesenen Bytes ergibt eine Obergrenze je Sitzung. Wir zählen je Schritt die aktiven Gewichte eines Tokens; in einem Batch eines Mixture-of-Experts-Modells gehen die Token der Sitzungen an unterschiedliche Experten, ein Schritt liest also mehr. Jeder dieser Werte ist deshalb nach unserer Schätzung eine Obergrenze, ebenso jede daraus abgeleitete Zahl von Sitzungen bei 50 Token pro Sekunde. Wir planen diese Obergrenze mit 50 Token pro Sekunde. Das ist das Zweieinhalbfache der 20 Token pro Sekunde, die aus 50 ms je Token folgen, dem Beispielwert für Agentenschritte in unserem Leitfaden zu Latenzzielen für LLMs; der Abstand ist nötig, weil reales Decodieren deutlich unter der Obergrenze bleibt. Bei Qwen3-Coder-Next auf einem Paar hielte der Speicher 57 Sitzungen mit 64K, bei 57 fällt die Obergrenze aber auf etwa 32 Token pro Sekunde; bei 35 Sitzungen bleibt sie bei 50.

Sitzungen je Server nach unserer Dimensionierungsregel und unserer Obergrenzen-Rechnung, BF16-Cache (FP8-Cache in Klammern; gpt-oss-120b nur mit BF16-Cache); „geplant“ ist die kleinere der beiden Grenzen; wo der Speicher die kleinere ist, wiederholt die Spalte zur Geschwindigkeit seinen Wert (auf acht H200 NVL liegt die Obergrenze bei 34 oder 69 Sitzungen mit 64K noch bei etwa 63 Token/s). 1.597 GB/s je RTX PRO 6000 Server Edition und 4,8 TB/s je H200 NVL (NVIDIA); je Schritt gelesene aktive Gewichte: 3 GB für Coder-Next, etwa 5 GB für gpt-oss-120b, 35 GB für Coder-480B. Schätzungen, keine Messungen; die Werte bei 50 Token/s beruhen auf Höchstwerten, die nach unserer Schätzung Obergrenzen sind.

In den Obergrenzen fehlen der All-Reduce-Verkehr zwischen den Karten und, wichtiger noch, der Prefill: Jeder Agentenschritt bringt die Ausgabe eines Werkzeugs oder eines Builds mit, die das Modell berechnen muss, bevor es antwortet. Prefix Caching, in vLLM standardmäßig aktiv, hält den früheren Teil der Sitzung wiederverwendbar, solange ihr Cache im Speicher bleibt; der erste Wert, den ein Pilot misst, ist deshalb der Anteil der Treffer im Prefix-Cache. Unser Leitfaden zu Hardware für langen Kontext erklärt den Effekt.

Wie viele Entwickler jede Konfiguration trägt

Mit einer erzeugenden Sitzung je Entwickler in der Spitzenstunde wird aus der Tabelle eine Teamgröße. Das sind die Bereiche, die wir vor einem Piloten vorschlagen, bei 64K Kontext, sofern nicht anders angegeben; wo die Geschwindigkeit sie bestimmt, sind sie nach unserer Schätzung eine Obergrenze.

Unsere Schätzungen aus der Tabelle oben, eine erzeugende Sitzung je Entwickler in der Spitzenstunde. Den FP8-Cache aktivieren Sie in vLLM mit --kv-cache-dtype fp8; prüfen Sie die Antwortqualität damit an Ihren eigenen Aufgaben, bevor Sie darauf dimensionieren.

Für 20 bis 40 Entwickler mit Qwen3-Coder-Next sind zwei Karten der Einstieg; für 40 bis 100 vier Karten, mit FP8-Cache bis 100, wenn Ihre Evaluierung ihn zulässt; bei 100 Entwicklern mit 128K Kontext acht Karten. Das 480B-Modell verschiebt den Maßstab: Es braucht acht Karten schon für seine Gewichte und trägt dann 13 bis 26 Sitzungen mit 64K auf acht RTX PRO 6000 Server Edition, 34 bis 69 auf acht H200 NVL; es passt zu einem Team, das seine Qualität für einen Teil der Aufgaben braucht, neben einem kleineren Modell für den Rest.

Wir bauen diese Server mit zwei, vier oder acht RTX PRO 6000 Server Edition oder acht H200 NVL; senden Sie uns die Zahl der Entwickler, den Anteil mit Agenten und die geplante Kontextlänge, und unser Team antwortet mit einer Konfiguration und ihren Sitzungen.

Zwei Karten: ein Paar für ein Team von 20 bis 35

Der Einstiegsserver auf unserer Seite zu KI-Servern ist mit zwei Karten der RTX PRO 6000 Server Edition, zwei AMD-EPYC-Prozessoren, 384 GB DDR5-ECC-Speicher und zwei NVMe-Laufwerken bestückt. Qwen3-Coder-Next in FP8 läuft darauf als eine TP=2-Instanz, wie die Modellkarte auf Hugging Face mit --tensor-parallel-size 2 und --tool-call-parser qwen3_coder zeigt. Von den zwei KV-Heads liegt einer auf jeder Karte, der Cache teilt sich also gleichmäßig.

Der Server zieht nach unserer Schätzung rund 1,8 kW und läuft an einem Anschluss mit 230 V und 16 A. Seine Grenze ist die Redundanz: Eine Instanz bedient alle, und ein Kartenfehler stoppt alle Agenten. gpt-oss-120b passt auf dasselbe Paar mit höchstens 24 Sitzungen bei der geplanten Geschwindigkeit, nach unserer Schätzung eine Obergrenze, oder läuft als zwei Kopien auf je einer Karte mit je 9 Sitzungen zu 64K im Speicher, wenn das Team zwei unabhängige Instanzen bevorzugt.

Vier Karten: zwei Paare für 40 bis 100 Entwickler

Der Inferenzknoten hat vier Karten der RTX PRO 6000 Server Edition mit 768 GB DDR5-ECC und vier NVMe-Laufwerken, nach unserer Schätzung bei rund 3,4 kW. Auf vier Karten läuft Qwen3-Coder-Next am besten als zwei Paare hinter einem Load Balancer mit Session-Affinität, damit jeder Agent zu der Kopie zurückkehrt, die seinen Cache hält. Eine einzelne TP=4-Instanz würde bei einem Modell mit zwei KV-Heads den Cache duplizieren, und vLLM schaltet seinen Custom All-Reduce standardmäßig für mehr als zwei GPUs ohne NVLink ab, wie unser Leitfaden zum Coding-Assistenten erklärt; vLLM 0.30.0 (Release Notes vom 22. September 2026) hat dafür einen optionalen FlashInfer-PCIe-IPC-All-Reduce für Systeme ohne NVLink ergänzt (#53576). Unser Artikel zur RTX PRO 6000 ohne NVLink behandelt, was ein Paar über PCIe schickt.

Mit zwei Paaren arbeitet die Abteilung außerdem weiter, während ein Paar aktualisiert wird. Derselbe Knoten kann stattdessen ein Paar mit Qwen3-Coder-Next und eines mit gpt-oss-120b betreiben, damit Teams die Modelle auf ihren eigenen Repositories vergleichen.

Acht Karten: 100 Entwickler oder das 480B-Modell

Acht Karten braucht eine Abteilung von etwa 100 Personen, deren Agenten den ganzen Tag arbeiten, oder ein Team, das Qwen3-Coder-480B-A35B einsetzt. Sein FP8-Checkpoint mit 482 GB, also 449 GiB, lässt auf acht Karten der RTX PRO 6000 Server Edition nach unserer Dimensionierungsregel 215 GiB Platz für den Cache: 13 Sitzungen zu 64K mit 16-Bit-Cache, 27 in FP8. Mit 8 KV-Heads legt TP=8 einen Head auf jede Karte, nichts wird dupliziert. Der Qwen3-Leitfaden von vLLM verlangt bei TP=8 für FP8-Checkpoints dieser MoE-Modelle --enable-expert-parallel, und die Modellkarte rät, den Kontext zu verkleinern, etwa auf 32.768, wenn der Speicher nicht reicht.

Acht H200 NVL mit NVLink-Brücken, der Trainingsknoten auf unserer Seite zu KI-Servern mit 2,3 TB DDR5-ECC und 400G-Netzwerk, halten dasselbe Modell mit 34 Sitzungen zu 64K, mit FP8-Cache 69, bei dreifacher Bandbreite je Karte. Die Brücken verbinden je vier Karten, eine TP=8-Instanz geht also zwischen den beiden NVLink-Domänen weiter über PCIe. Beide Achtkartenserver ziehen nach unserer Schätzung mit zwei AMD EPYC 9555 rund 6,3 kW, und Dells Datenblatt nennt als Richtwert etwa 8 kW je Knoten mit acht Karten; planen Sie den Drehstromanschluss mit 400 V deshalb nach dem Wert des Serverherstellers, wie unser Leitfaden zum Stromanschluss von GPU-Servern ausführt. Der Arbeitsspeicher folgt NVIDIAs Leitfaden für zertifizierte Systeme mit dem Doppelten des GPU-Speichers, 1.536 GB für acht RTX PRO 6000 Server Edition.

Ein veröffentlichter Durchsatzwert für diese Karten

Die Ergebnisse von MLPerf® Inference v6.1 enthalten gpt-oss-120b, eines der Coding-Modelle aus der Tabelle. Acht RTX PRO 6000 Server Edition in einem HPE ProLiant Compute DL380a Gen12 erzeugten offline 15.256 Token pro Sekunde und im Server-Szenario, das Latenzgrenzen je Anfrage einhält, 14.581,7 Token pro Sekunde. Nach unserer Division, keine MLPerf-Metrik, sind das im Server-Szenario etwa 1.823 Token pro Sekunde je Karte. Andere Systeme mit acht Karten der Server Edition erreichten im selben Benchmark offline 15.508,4 (Cisco UCS C845A M8) und 15.738,5 (Nebius).

Ein Standard-Benchmark bildet keine Agentensitzungen auf Ihrer Codebasis ab; der Wert sagt also, was die Karten auf diesem Modell in einem Standardtest leisten, nicht, wie viele Entwickler sie tragen. MLPerf® Inference v6.1, Rechenzentrum, Closed Division, gpt-oss-120b, Szenarien Offline und Server, Einträge 6.1-0050, 6.1-0013 und 6.1-0082, abgerufen von mlcommons.org am 24. Oktober 2026, Ergebnisse von der MLCommons Association verifiziert. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

Was Sie vor der Bestellung im Piloten messen

Ein Pilot mit aufgezeichneten Agentenaufgaben aus Ihren eigenen Repositories ersetzt unsere Annahmen durch Ihre Werte. Unser Leitfaden dazu, was ein Private-AI-Pilot messen sollte, beschreibt die Methode; für Coding-Agenten entscheiden diese Werte zwischen zwei, vier und acht Karten.

1. Gleichzeitig erzeugende Sitzungen in der Spitzenstunde aus dem Gateway-Log, im Verhältnis zur Zahl der Entwickler.
2. Prompt-Länge im letzten Schritt einer langen Aufgabe, die über 64K oder 128K entscheidet.
3. Trefferquote des Prefix-Caches, aus vllm:prefix_cache_hits geteilt durch vllm:prefix_cache_queries.
4. Zeit bis zum ersten Token und Latenz zwischen Token je Schritt in der Spitzenstunde.
5. Erfolgsquote der Aufgaben auf Ihren eigenen Repositories mit FP8-Cache gegenüber 16-Bit-Cache und mit Qwen3-Coder-Next gegenüber dem 480B-Modell.
6. Preemptions in vllm:num_preemptions, die zeigen, dass Agenten ihren Cache verlieren.

Unser Engineering-Partner Vixen.UNO setzt Coding-Modelle im Rahmen unseres Private-AI/ML-Service on-premise mit Zugriffskontrolle und Protokollierung auf; beschreiben Sie Ihre Repositories und wie Ihre Entwickler mit Agenten arbeiten, und wir richten den Piloten ein und dimensionieren den Server nach seinen Werten.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration auf Ihre Arbeitslast und Ihr Budget aus und antwortet innerhalb eines Werktages. Wir bauen KI-Server auf Bestellung mit zwei, vier oder acht RTX PRO 6000 Server Edition, der passiven Karte für Rack-Server im Dauerbetrieb, oder mit acht H200 NVL mit NVLink-Brücken, vor der Lieferung montiert und getestet. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch. Auf jede Komponente gilt die Herstellergarantie, und die Bestellung läuft über einen EU-Vertrag und eine Rechnung.

FAQ