Referenzaufbau: Robotik- und KI-Labor in einem Rack

Die vorangegangenen Beiträge beschreiben die Architektur, den Software-Stack, das Leistungsbudget und das Netzwerkdesign. Dieser hier hängt allem ein Preisschild und eine Stückliste an – abgeleitet von realer Hardware, die Kentino ausgeliefert und vermessen hat, und nicht von einer theoretischen Stückliste aus dem Marketingprospekt.

Zielbild ist ein Forschungs- oder Integrationslabor, das ein bis vier Roboter betreibt, dazu Inferenz im eigenen Haus und eine Startbahn fürs Training. Mittlere Größenordnung: keine Bastelkiste, die gerade so ein 7B-Modell bedient, aber auch kein Hyperscale-Cluster, für den es ein eigenes Facility-Team braucht. Eine ernsthafte Arbeitsumgebung, die ein Team aus zwei bis sechs Personen ohne eigene DevOps aufbauen, betreiben und weiterentwickeln kann.

Der Beitrag behandelt zwei Ausbaustufen desselben Architekturmusters. Die 4-GPU-Stufe für die Entwicklung ist der Startpunkt der meisten Labore. Die 8-GPU-Stufe für den Produktivbetrieb ist das, wo sie nach dem ersten echten Workload landen. Die Hardware unterscheidet sich, die Architektur ist identisch.

Was die Flottendaten zeigen

Kentino betreibt eine Flotte einheitlich konfigurierter 4-GPU-Compute-Knoten. Jede Einheit trägt dieselbe Spezifikation: AMD EPYC 7542 (32 Kerne / 64 Threads, 2.9 GHz Boost), 512 GB DDR4 ECC LRDIMM mit 2666 MT/s auf acht DIMMs, vier RTX 4090 GPUs (je 24 GB VRAM, zusammen 96 GB), eine 2-TB-NVMe als Scratch-Laufwerk und eine 512-GB-SATA-SSD für das Betriebssystem. Als Mainboard dient das ASRockRack ROMED8-2T/BCM. Ubuntu 24.04 LTS, Kernel 6.8.0-generic, NVIDIA-Treiber 590.48.01, CUDA 13.1/13.2.

Alle zehn Knoten liefern identische Benchmark-Werte. Das ist kein Zufall, sondern der Sinn eines Referenzaufbaus: Wenn jede Einheit mit derselben Konfiguration das Haus verlässt, ist der Benchmark eine Spezifikation und kein Glückstreffer.

GPU-Rechenleistung

FP16-Tensor-Core-Matmul über alle vier Karten (Workload 8192 × 8192):

GPU 1 liegt rund 6% unter den GPUs 0, 2 und 3 – das bewegt sich im üblichen Rahmen der Serienstreuung bei Consumer-Karten. Alle vier bestanden den 60-sekündigen GPU-Burn und den kombinierten GPU-plus-CPU-Burn ohne einen einzigen Rechenfehler. Der thermische Spielraum ist komfortabel: Die Drosselschwelle der RTX 4090 liegt bei 83 °C, die heißeste Karte der Flotte erreichte unter gleichzeitiger GPU- und CPU-Last 73 °C. Auf keinem Knoten wurde Throttling beobachtet.

Ein praktischer Hinweis zu den Power-Limits: Die Flotte wird mit leicht unterschiedlichen Limits je Karte ausgeliefert (450 W, 480 W, 500 W je nach Steckplatz). Für den dauerhaften Produktivbetrieb glättet eine einheitliche Einstellung auf 450 W die Gesamtaufnahme und reduziert die Unwucht zwischen den Netzteilen. Der TFLOPS-Verlust von 450 W gegenüber 500 W liegt unter 2% – die asymmetrische Schienenlast ist das nicht wert.

vLLM-Inferenz – Llama 3.3 70B AWQ

Gemessen mit vLLM 0.19.0, tensor_parallel_size=4, gpu_memory_utilization=0.80, max_model_len=2048:

Eine wichtige Einschränkung: Der Benchmark nutzte den Quantisierungskernel awq , nicht awq_marlin. Der Pfad über awq_marlin ist auf Ada Lovelace (RTX 4090) bei der Latenz einzelner Anfragen 2–3× schneller. Im Produktivbetrieb sollten Sie awq_marlin oder den FP8-Pfad unter vLLM 0.20+ verwenden, der den Abstand weiter verringert. Mit awq_marlinsteigt der oben genannte Einzelanfragewert von etwa 8 Token/s auf rund 16–20 Token/s auf diesen Karten – und liegt damit näher an dem, was Anwender in der Praxis erleben. Beim Batch-Durchsatz fällt der Gewinn anteilig kleiner aus, weil der Engpass bei hoher Parallelität von der Rechenleistung auf die Speicherbandbreite wandert.

Diese Werte gelten für Llama 3.3 70B in INT4 (AWQ). Ein 7B- oder 8B-Modell in Q4 läuft auf derselben Hardware 4–6× schneller pro Token, ein 13B-Modell etwa 2.5× schneller. Der 70B-Wert ist die maßgebliche Größe für VLMs und große Planungsmodelle im Robotikumfeld.

llama.cpp – Einzelnutzer, keine Parallelität

Gemessen mit llama-cpp-python 0.3.20 (CUDA/cuBLAS), Llama 3.3 70B Instruct Q4_K_M GGUF, alle vier GPUs:

llama.cpp lädt schneller (10.8 s gegenüber 95 s bei vLLM) und liefert auf diesen Karten im Einzelnutzerbetrieb höhere Dekodiergeschwindigkeit, weil der Overhead des Continuous-Batching-Schedulers entfällt. Der Preis dafür ist null Parallelität – immer nur ein Nutzer. Richtig gelesen heißen diese Zahlen: llama.cpp auf einem 4-GPU-Knoten gibt Entwicklern ein reaktionsschnelles 70B-Modell für die interaktive Arbeit; vLLM ist die richtige Wahl, sobald mehr als ein Client anfragt.

Die vollständige Entscheidungsmatrix zum Serving-Stack finden Sie unter I02 . Kurzfassung: mit vLLM in Docker starten, awq_marlin als Quantisierung verwenden und nur für Einzelnutzer-Entwicklungsmaschinen oder Jetson-Deployments auf llama.cpp wechseln.

GPU-Speicherbandbreite

Die Bandbreite auf der Karte selbst (Device-to-Device) liegt bei allen vier Karten konstant bei 920.2–920.6 GB/s – sie weichen um weniger als 0.04% voneinander ab, was bestätigt, dass GDDR6X hier nicht die variable Größe ist. Die PCIe-Bandbreite Host→Device erreicht 26.2–26.3 GB/s und belegt, dass Gen4 x16 unter Last vollständig ausgehandelt wird (im Leerlauf meldet der Link wegen ASPM-Stromsparen Gen1 – normal, kein Fehler). Peer-to-Peer-Transfers zwischen GPUs über PCIe (ohne NVLink) messen 19–22 GB/s, was der erwarteten Obergrenze für Peer-to-Peer über einen gemeinsamen PCIe-Root-Complex ohne NVLink entspricht (Hintergrund in N03 ).

NVMe-Speicher

Die sequenzielle Bandbreite liegt nahe an der Obergrenze von Gen4 x4. Die zufälligen IOPS bei Queue-Tiefe 32 sind gut ausgelastet: 568K Lese-IOPS liegen deutlich über dem, was das Laden von LLM-Gewichten oder der Zugriff auf Datensätze auf Einzelknotenebene verlangen. Ein Modell von NVMe in den VRAM zu laden dauert je nach Größe 10–30 Sekunden – dieses Laufwerk ist nicht der Engpass.

Der Referenzaufbau

Stückliste – 4-GPU-Entwicklungsstufe

Die Entwicklungsstufe ist der richtige Einstieg für ein Labor mit ein bis zwei Robotern, ein bis zwei aktiven Modellen und gelegentlichem LoRA-Finetuning nebenher.

Entwicklungsstufe: 4-GPU-Compute-Knoten + managed ToR-Switch + 6-GHz-AP + 5-kVA-Online-USV.

Stückliste – 8-GPU-Produktivstufe

Die Produktivstufe verdoppelt die Zahl der GPUs. Das Architekturmuster bleibt gleich; CPU, RAM und Gehäuse skalieren entsprechend mit, um acht PCIe-Steckplätze mit voller Bandbreite zu versorgen. Eine AMD-EPYC-Plattform der Generation Genoa oder Turin liefert das Lane-Budget für 8× x16 ohne Kompromisse bei der Bifurcation (siehe W02).

Hinweis: Die 25-GbE-NIC als Erweiterung ist nur im 8-GPU-Gehäuse sinnvoll. Im 4-GPU-Gehäuse ist kein Platz für eine zusätzliche Netzwerkkarte – die beiden 10-GbE-Ports onboard auf dem ROMED8-2T/BCM sind auf der 4-GPU-Stufe die praktische Grenze (siehe N01 sowie die Regeln auf der Produktseite).

Storage jenseits des Compute-Knotens

Für die Entwicklungsstufe liefert ein NAS mit 4 Einschüben und 4× 16 TB HDDs im RAID-5 48 TB nutzbar – genug für ein Jahr Episodendaten in einem Labor mit 2 Robotern. Binden Sie es mit 10 GbE an den ToR-Switch an und legen Sie es nicht auf dieselbe Schnittstelle wie den Roboterverkehr.

Strom und Kühlung für das Rack

Aus I04:

Die Daten aus dem Flotten-Stresstest bestätigen, dass der 4-GPU-Knoten bei voller GPU-Last rund 1,914 W zieht, wenn alle vier Karten ihr Power-Limit erreichen. Rechnet man CPU (~120 W im Dauerbetrieb), NVMe und Lüfter hinzu, landet der Knoten bei etwa 2.1–2.2 kW dauerhaft.

Elektroinstallation für die Entwicklungsstufe: 400 V bei 16 A Drehstrom sind das Minimum, 32 A Drehstrom geben Luft zum Wachsen. Die beiden Netzteilkabel gehören auf zwei getrennte Phasen. Den Verdrahtungsplan finden Sie unter I04 und P02 . Für die Produktivstufe (10 kW im gesamten Rack) brauchen Sie 400 V bei 32 A Drehstrom und mindestens 15 kW Kühlleistung.

USV-Dimensionierung: Legen Sie nur den Server aus, nicht die Roboter. Für die Entwicklungsstufe ist eine 5-kVA-Doppelwandler-Online-USV die kleinste vernünftige Wahl, für die Produktivstufe 10 kVA. Immer Doppelwandler-Online spezifizieren. Siehe P05.

Software-Stack auf Bare Metal

Software-Stack: gepinntes Ubuntu + NVIDIA-Treiber → Container-Toolkit → vLLM + llama.cpp + nginx + Monitoring.

Das Pinnen des Treibers ist nicht verhandelbar. Die Flotte läuft mit Treiber 590.48.01; apt-mark hold nvidia-driver-590 ist der erste Handgriff nach der Bare-Metal-Installation. Ein unbeaufsichtigtes apt-get upgrade , das einen neueren Treiber nachzieht, hat die Inferenz im Produktivbetrieb genau so oft zerschossen, wie Sie es erwarten würden. Das vollständige Vorgehen finden Sie unter L01 .

Monitoring ist keine Kür. Die Flottendaten zeigen, dass GPU 3 auf einem Knoten während der Benchmarks korrigierbare PCIe-AER-Fehler (RxErr + BadTLP) aufwies – von der Hardware automatisch behoben, aber in den DCGM-Zählern sichtbar. Ohne Monitoring taucht so etwas Wochen später als „gelegentlich seltsame Inferenzfehler" auf. Richten Sie DCGM ein und setzen Sie einen Alarm auf korrigierbare ECC-Fehler oberhalb einer Grundrate. Den Prometheus-plus-Grafana-Stack beschreibt L05 .

Varianten der Dimensionierung

Die 4-GPU-Entwicklungsstufe – was sie tatsächlich leistet

96 GB VRAM insgesamt (4× 24 GB) bei TP=4:

Das 72B-VLM passt bei INT4 nicht komfortabel auf 4× 24 GB – rechnerisch ist es knapp, aber Kontextfenster jenseits von 4K sprengen den Rahmen. Nutzen Sie entweder die 32B-Variante des VLM oder steigen Sie auf die 8-GPU-Stufe beziehungsweise einen Knoten mit 4× RTX Pro 6000 Blackwell (je 96 GB VRAM) für die 72B-Klasse um. Die Diskussion zu VRAM und Modellklassen finden Sie unter W07 .

Die Entwicklungsstufe bewältigt: ein 70B-Inferenzmodell für 1–3 parallele Roboter-Clients, ein VLM der 32B-Klasse für visuelle Abfragen und gelegentliches LoRA-Finetuning auf einem kleineren Basismodell. Damit sind 80% der Anwendungsfälle in Robotiklaboren im Jahr 2026 abgedeckt.

Die 8-GPU-Produktivstufe – die zusätzliche Reserve

192 GB VRAM insgesamt (8× 24 GB):

Die 8-GPU-Stufe öffnet außerdem die Tür zum gleichzeitigen Betrieb mehrerer Modelle: ein 70B-LLM auf 4 GPUs und ein 32B-VLM auf den anderen 4, die aus einer einzigen Maschine eine gemischte Roboterflotte mit unterschiedlichen Modellanforderungen zur selben Zeit bedienen. Auf der 4-GPU-Stufe erfordert das einen Modellwechsel mit 30–120 s Ausfallzeit je Wechsel.

Hinweis zu TP=8 für ein 70B-Modell: TP=8 über PCIe-Peer-to-Peer (ohne NVLink) skaliert bei einer Parallelität über 8 schlechter als TP=4 × PP=2, weil die Kosten der All-Reduce-Kommunikation mit dem Grad der Tensorparallelität wachsen. Die Benchmark-Daten zeigen 19–22 GB/s Bandbreite zwischen den GPUs über PCIe – genug für TP=4, aber ein All-Reduce mit TP=8 sättigt diese Verbindungen bei großen Batch-Größen. Empfohlene Konfiguration für ein 70B-Modell auf 8× 4090 ist TP=4 × PP=2, wie in I02gezeigt.

Rack-Aufbau

Der Compute-Knoten sitzt immer unterhalb von Switch und USV – die Luftführung von vorn nach hinten verlangt, dass die kalte Luft an der Rackfront eintritt (Kaltgang oder Raumklimatisierung), durch den Server strömt und hinten in den Warmgang austritt. Zur Disziplin bei der Luftführung siehe W05 und I04 .

Der Jump-Host ist eine 1U- oder Kleinformatmaschine mit Displayanschluss, die für die Erstinbetriebnahme, die Treiberinstallation und für Wartungsarbeiten dient, wenn der Hauptserver über das Netzwerk nicht erreichbar ist. Eine GPU braucht er nicht. Eine gebrauchte Workstation oder ein kleines 1U-System mit 16 GB RAM und einer Gen3-SSD genügt.

Was dieser Aufbau nicht ist

Kein Desktop-GPU-Server im Rackgehäuse. Der offene Desktop-Tower – GPUs auf Riser-Karten, kein Gehäuse, Lüfter Richtung Decke – ist nicht das, was hier beschrieben wird. Desktop-Aufbauten sind für die Entwicklung in Ordnung; sie sind nicht für den 24/7-Dauerbetrieb ausgelegt und bieten nicht die gerichtete Luftführung von vorn nach hinten, die GPUs über Wochen auf konstanter Betriebstemperatur hält.

Kein NVLink-Cluster. Die RTX 4090 (Consumer- beziehungsweise Workstation-Klasse) hat kein NVLink. Transfers zwischen GPUs laufen über PCIe mit 19–22 GB/s, nicht mit 900 GB/s. Für Inferenz-Serving mit TP=4 reicht das aus, für TP=8-Training ist es eine echte Einschränkung. Wenn Ihr Workload verteiltes Training auf einem Modell ab 70B ist, ändern eine RTX Pro 6000 Blackwell (in der Multi-GPU-Ausführung NVLink-fähig) oder eine Plattform mit NVSwitch die Rechnung – aber auch den Preis. Siehe N03.

Keine redundanten Netzteile. Die Konfiguration mit zwei Netzteilen ist eine geteilte Stromversorgung: Netzteil A versorgt die GPUs 0 und 1 (plus Mainboard), Netzteil B die GPUs 2 und 3. Fällt Netzteil A aus, verlieren Sie zwei GPUs und das Mainboard. Es gibt keine automatische Übernahme. Das ist ehrliches Dual-PSU – es gleicht die Schienenlast aus und verringert das Ausfallrisiko gegenüber einem einzelnen großen Netzteil, aber es ist keine N+1-Redundanz. Siehe W04.

Keine Cloud-Alternative für alles. Wenn der Hauptworkload Ihres Labors zehn Modellaufrufe am Tag sind, rechtfertigt die TCO-Rechnung keinen Betrieb im eigenen Haus. Dieser Aufbau amortisiert sich gegenüber Cloud-API-Ausgaben, wenn Sie dauerhaft Inferenz für mehrere Clients fahren, regelmäßig finetunen oder unter Auflagen zur Datenhaltung arbeiten. Die ausführliche Rechnung finden Sie unter T02 .

Warum genau diese Entscheidungen

AMD EPYC 7542 als Host-CPU. Eine EPYC mit 32 Kernen stellt allein aus der CPU 128 PCIe-4.0-Lanes bereit – genug für 4× GPUs mit x16 ohne Bifurcation, dazu eine NIC, Storage und einen PCIe-Switch für Erweiterungen. EPYC ist in dieser Größenordnung nicht ohne Grund die Standardplattform für Multi-GPU-KI-Server: Ein Intel Xeon mit derselben Kernzahl bietet weniger PCIe-Lanes, was bei Konfigurationen ab 4 GPUs Kompromisse bei der Bifurcation erzwingt. Die Lane-Arithmetik finden Sie unter W02 .

512 GB Arbeitsspeicher. Die Flotte wird mit 512 GB ausgeliefert (8× 64 GB) und übertrifft damit die nominale Vorgabe von 256 GB. Das ist Absicht: Das Laden großer Modelle beim Containerstart, das Prefetching von Datensätzen fürs Training und der Seitencache des Betriebssystems beanspruchen allesamt Arbeitsspeicher, den der VRAM nicht abdecken kann. Bei vLLM mit aktiviertem KV-Cache-Swap ist der Arbeitsspeicher direkt als Überlauf nutzbar – 4 GB Swap je GPU verlangen 16 GB Reserve im Arbeitsspeicher. 512 GB bieten diese Reserve und zusätzlich Platz für Isaac Sim, das beim Policy-Training 10–30 GB Simulationszustand im Arbeitsspeicher halten kann.

2 TB NVMe als Scratch. Der Benchmark weist 4,589 MB/s sequenzielles Lesen aus – schnell genug, um ein 70B-Modell in FP8 (~75 GB) in unter 20 Sekunden zu laden. In einem Labor, das häufig Modelle wechselt (Entwicklungsworkflow, A/B-Tests von Inferenz-Stacks), zählt die Ladezeit. Eine langsamere SATA-SSD verdoppelt oder verdreifacht diese Zeit je Wechsel.

Luftführung von vorn nach hinten im Rack. Der häufigste Fehler bei Erstaufbauten: Die Desktop-Ausrichtung (Ansaugen seitlich, Abluft oben und hinten) funktioniert in einem geschlossenen Rack nicht. Der Compute-Knoten muss eine gerichtete Luftführung nutzen, die zur Kaltgang-Warmgang-Konvention des Racks passt. Siehe I01 und W05.

Eine ehrliche Einordnung der Hardware von 2026

Dies ist ein Referenzaufbau mit Stand Mai 2026. Die RTX 4090 ist nicht die neueste GPU-Option bei Kentino – die RTX 5090 (32 GB VRAM, Blackwell-Architektur, sm_120) und die RTX Pro 6000 Blackwell (96 GB VRAM) sind verfügbar und verschieben die Rechnung beim VRAM je Karte deutlich. Ein 4-GPU-Knoten mit RTX Pro 6000 Blackwell bietet 384 GB VRAM – genug, um Qwen 2.5 VL 72B in FP8 bequem auf vier Karten zu hosten – zu entsprechend höheren Kosten je Karte.

Was sich zwischen den Generationen nicht ändert, ist das Architekturmuster: AMD-EPYC-Host, Multi-GPU über PCIe, Gehäuse mit Luftführung von vorn nach hinten, zwei Netzteile, Ubuntu 24.04, vLLM in Docker, Prometheus plus DCGM-Exporter. Dieses Muster hat zwei GPU-Generationen überdauert und wird auch die nächste überstehen. Die Stückliste wird günstiger und schneller; das Muster bleibt.

---

Dieser Beitrag gehört zum Kentino Wiki, einer Referenzreihe über KI-Compute, Robotik und die Systeme, die beides verbinden. Anmerkungen und Korrekturen gerne an info@kentino.com.