Fallstudie: KI-Workstation mit 4x RTX 4090

Dieser Artikel dokumentiert einen kompletten Build, den ein Forschungskunde in Auftrag gegeben hat: eine rackfähige, 24/7-taugliche LLM-Inferenz-Workstation mit genügend VRAM, um Modelle der 70B-Klasse ohne Cloud-Abhängigkeit zu betreiben. Alle Angaben hier wurden an der realen Hardware gemessen. Keine synthetischen Schätzungen, keine Marketingzahlen.

Der Build wurde im April 2026 beauftragt und ausgeliefert. Die Abnahme-Benchmarks liefen am 2026-04-10.

Warum 4× RTX 4090

Die Workload-Anforderung stand von Anfang an fest: ein quantisiertes 70B-LLM mit brauchbarer Latenz pro Einzelanfrage betreiben, parallele Anfragen eines kleinen Forschungsteams bedienen und aus Gründen der Datenkontrolle alles on-premise halten. Offen war nur, wie viele GPUs welcher Art es dafür braucht.

Ein 70B-Modell in INT4 (AWQ oder GGUF Q4_K_M) belegt in der Praxis rund 38–40 GB VRAM. Damit scheiden Einzel-GPU-Lösungen komplett aus — selbst eine RTX 4090 mit 24 GB kann das Modell nicht allein halten. Sie benötigen mindestens zwei, besser vier Karten, damit das Tensor-Parallel-Serving unter vLLM noch Reserven für den KV-Cache hat.

Vier RTX-4090-Karten ergeben zusammen 96 GB VRAM. Das genügt, um ein Llama 3.3 70B AWQ INT4 mit gpu_memory_utilization=0.80 zu laden und dennoch nennenswerten KV-Cache-Platz für gebündelte Anfragen zu behalten. Hinzu kommt die Rechenkapazität — 4× 128 SM-Chips, die gleichzeitig arbeiten —, die für die Geschwindigkeit der Prompt-Verarbeitung entscheidend ist.

Als Alternative stand 4× RTX Pro 6000 Blackwell im Raum, also 4× 96 GB = 384 GB VRAM. Das ist eine völlig andere Liga: mehr VRAM, als ein einzelnes 70B-Modell je benötigt, geeignet für den gleichzeitigen Betrieb mehrerer großer Modelle oder für Modelle der 200B+-Klasse bei vernünftiger Quantisierung. Für diesen Workload — ein Hauptmodell, kleine parallele Batches, Budget einer Single-Tenant-Workstation — bliebe diese Zusatzkapazität ungenutzt, und der Preisunterschied ist erheblich. Für den genannten Anwendungsfall war 4× RTX 4090 die richtige Antwort.

Im Portfolio existiert außerdem eine Variante mit 8× L40. Die L40 bietet 48 GB VRAM pro Karte, ECC-Unterstützung und ist auf Dauerlast im Rechenzentrum ausgelegt. Bei diesem Kunden verlangte der Workload keine Zuverlässigkeitsverträge auf Rechenzentrumsniveau, das Fehlen der treiberseitigen Eigenheiten von Consumer-Karten war nur ein Nebenvorteil, und das Budget gab diese Option nicht her. Als Upgrade-Pfad aber gut zu wissen.

Eine architektonische Grenze sei vorab genannt: RTX-4090-Karten haben kein NVLink. Die gesamte GPU-zu-GPU-Kommunikation läuft über PCIe Peer-to-Peer. Für Tensor-Parallel-Inferenz ist das relevant (siehe Benchmark-Abschnitt) und sollte vor der Bestellung verstanden sein. Siehe N03 für eine ausführliche Betrachtung, wann NVLink zählt und wann nicht.

Hardware-Spezifikation

Einige Anmerkungen zu diesen Entscheidungen:

CPU. Der EPYC 7542 ist ein 32-Kern-Chip der Rome-Generation mit 128 MB L3-Cache über 8 CCDs. Für eine Inferenz-Workstation ist das an reiner Kernzahl überdimensioniert — mit reiner Inferenz lasten Sie 64 Threads nicht aus. Seine Berechtigung bezieht er aus dem PCIe-Lane-Budget: Rome-EPYC stellt 128 PCIe-4.0-Lanes direkt von der CPU bereit, weshalb sich vier GPUs mit vollen x16 auf dieser Plattform betreiben lassen — ohne geteilte Lanes und ohne Bifurcation. Die RTX 4090 ist ein PCIe-4.0-x16-Gerät; Sie wollen vier volle x16-Slots, und EPYC liefert sie. Siehe W02 für Details zur Lane-Topologie.

RAM. Ausgeliefert wurde das System mit 512 GB DDR4 ECC LRDIMM und damit mit mehr als den ursprünglich spezifizierten 256 GB. Zusätzlicher Arbeitsspeicher bringt hier echten Nutzen: Das Laden eines Modells von der NVMe läuft über den Systemspeicher, bevor es in den VRAM übertragen wird. Bei größeren Modellen oder beim Wechsel zwischen Modellen bedeuten 512 GB, dass Sie mehrere Gewichtssätze gleichzeitig im RAM halten und wiederholte NVMe-Zugriffe vermeiden.

NVMe. Der Modellspeicher (2 TB) liegt auf einem schnellen PCIe-4.0-NVMe-Laufwerk. Beim Laden zählt die sequenzielle Lesegeschwindigkeit: Eine 38 GB große Modelldatei ist bei 4,589 MB/s sequenziellem Lesen in rund 8–10 Sekunden geladen. Die gemessenen Ladezeiten bestätigen das: llama.cpp lud das 70B Q4_K_M GGUF in 10.8 Sekunden, vLLM (das beim Laden zusätzlich CUDA-Graphen aufbaut) brauchte 95 Sekunden.

Zwei Netzteile. Das Gehäuse nutzt zwei ATX-Netzteile. Das ist eine aufgeteilte Stromversorgung: Jedes Netzteil versorgt einen Teil des Systems — typischerweise je zwei GPUs samt zugehöriger Board-Komponenten. Fällt ein Netzteil aus, verlieren Sie die GPUs an dessen Schiene. Das ist keine N+1-Redundanz, sondern eine Auslegung auf den Leistungsbedarf, kein Failover-Konzept. Für Produktivsysteme mit vertraglich zugesicherter Verfügbarkeit ist dieser Unterschied wichtig. Siehe W04 für die vollständige Diskussion zur Netzteil-Dimensionierung.

Luftstrom im Gehäuse. Das Gehäuse ist für den Rack-Einbau ausgelegt und arbeitet mit industriell gerichtetem Luftstrom von vorn nach hinten. Die GPUs sind nicht als Open-Air-Karten verbaut, sondern sitzen in einem gerichteten Luftkanal, in dem Gehäuselüfter die Luft über die Kühlkörper ziehen und nach hinten ausblasen. Damit eignet sich das System für den 24/7-Dauerbetrieb im Rack. Siehe W05 für Details zum thermischen Design.

Software-Stack

Die Python-Umgebung liegt unter /home/logic/llm-env/, die Modelle auf der NVMe unter /mnt/nvme/models/.

Ergebnisse der Inbetriebnahme

GPU-Rechenleistung: Basiswerte

Der erste Test ist immer die reine Rechenleistung: Matrixmultiplikation in FP16 (Tensor-Core-Pfad) und FP32. Er bestätigt, dass die Karten einwandfrei arbeiten, und liefert einen Basiswert zum Abgleich mit den Nennwerten.

Zur Einordnung: Das theoretische FP16-Tensor-Core-Maximum der RTX 4090 liegt bei ~330 TFLOPS, FP32 bei ~82.6 TFLOPS. Die Benchmark-Werte bei ~52 % des FP16-Maximums sind zu erwarten — gemessen wird eine Matrixmultiplikation unter Dauerdurchsatz, die den theoretischen Spitzenwert eines handoptimierten GEMM-Kernels nicht erreicht. Sie belegen, dass alle vier Tensor-Core-Arrays arbeiten und konsistent liefern.

GPU 1 liegt bei FP16 rund 6 % unter den anderen. Das ist normale Serienstreuung innerhalb desselben Bins. Kein Hardwarefehler.

GPU-Speicherbandbreite

Die VRAM-Bandbreite von 920 GB/s entspricht der Spezifikation der RTX 4090 (1,008 GB/s Spitzenwert; die Differenz ist Benchmark-Overhead). Genau dieser Wert entscheidet über den Decode-Durchsatz: Für jedes erzeugte Token müssen der gesamte KV-Cache und die Gewichtstensoren aus dem VRAM geladen werden — die Bandbreite setzt also unmittelbar die Obergrenze der Generierungsgeschwindigkeit.

Der GPU-zu-GPU-Wert (19–22 GB/s über PCIe Peer-to-Peer) ist die architektonische Einschränkung, die für Tensor-Parallel-Serving zählt. Mit NVLink läuft dieser Pfad mit 900 GB/s, mit reinem PCIe erhalten Sie davon rund 2 %. Für Inferenz ist das nicht katastrophal — der größte Teil der Tensor-Parallel-Kommunikation eines 70B-AWQ-INT4-Modells über 4 GPUs passt in das, was PCIe leisten kann —, aber die Decode-Geschwindigkeit einzelner Anfragen fällt gegenüber einem NVLink-System niedriger aus. Siehe den Benchmark-Abschnitt weiter unten sowie N03 für die ausführlichere Diskussion.

Eine Auffälligkeit: Die Device-to-Host-Bandbreite wurde mit 1.4 GB/s gemessen, weit unter den für PCIe Gen4 x16 erwarteten ~26 GB/s. Das ist ein bekanntes CUDA-Verhalten bei nicht gepinntem Speicher. Wenn Ihre Anwendung häufig Daten von der GPU zum Host bewegt (z. B. Sampling aus Output-Logits in einer eigenen Pipeline), nutzen Sie torch.pin_memory() oder reservieren Sie gepinnte Puffer vorab. Die Standard-Serving-Pipelines von vLLM und llama.cpp nutzen diesen Pfad in der Hot Loop nicht.

Alle PCIe-Links liefen unter Last bestätigt mit Gen4 x16 (16 GT/s). Im Leerlauf nutzt der Treiber die ASPM-Energiesparfunktion, und die Links fallen auf Gen1 (2.5 GT/s) zurück — das ist normal und kein Verkabelungs- oder Riser-Fehler.

NVMe-Speicher

Das sind starke NVMe-Werte für ein Consumer-/Prosumer-Laufwerk mit PCIe 4.0. Für das Modell-Serving zählt das sequenzielle Lesen: 4,589 MB/s bedeuten, dass ein 38-GB-Modell in etwa 8–9 Sekunden im RAM liegt, noch vor jedem VRAM-Transfer. Die 568K zufälligen IOPS sind vor allem dann relevant, wenn Sie eine Retrieval-Pipeline (RAG, Vektorspeicher) betreiben, deren Workload aus vielen kleinen Zufallszugriffen besteht — das Laufwerk bewältigt das, ohne zum Flaschenhals zu werden.

vLLM-Inferenz — Llama 3.3 70B AWQ INT4

Das ist der zentrale Benchmark. Modell: casperhansen/llama-3.3-70b-instruct-awq. Serving: vLLM 0.19.0 mit tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

Die Decode-Geschwindigkeit von 8.0 tok/s bei Einzelanfragen braucht Kontext. vLLM 0.19.0 betrieb das AWQ-Modell mit dem awq -Kernel, nicht mit awq_marlin. Der awq_marlin -Kernel ist der schnellere Pfad für AWQ auf Ada-Lovelace- (RTX 4090) und Blackwell-GPUs — laut Benchmark-Notizen wurde er bei diesem Abnahmelauf nicht ausgewählt; erwartet wird ein Zugewinn um das 2–3-Fache bei der Decode-Geschwindigkeit einzelner Anfragen. Mit awq_marlinsollte dasselbe Modell auf derselben Hardware etwa 16–24 tok/s im Single-Stream erreichen.

Aussagekräftiger für den Produktivbetrieb sind die 179.3 tok/s aggregiert bei 32 parallelen Anfragen. Genau das sieht ein kleines Team, das den Endpunkt gleichzeitig nutzt, als kombinierte Systemleistung. Durch Continuous Batching in vLLM verteilen parallele Anfragen KV-Cache und Attention-Berechnung über den Batch — deshalb führen 32× so viele Nutzer nicht zu 32× so hoher Latenz.

Die 2,043 ms Latenz bei einer 16-Token-Anfrage sind die Untergrenze der TTFT (Time-to-First-Token) unter vLLM in dieser Konfiguration. Für interaktive Anwendungsfälle (Chat, Code-Assistenz) ist das eher langsam. Hauptursache ist der Tensor-Parallel-Overhead für Scatter/Gather über vier GPUs via PCIe — jeder Prefill-Schritt erfordert ein AllReduce über alle vier Karten durch die PCIe-Fabric. Mit NVLink läge die TTFT bei rund 50–100 ms; mit PCIe P2P bei 20 GB/s dehnt sie sich weiter aus. Das ist der unmittelbare Preis der NVLink-losen Architektur bei latenzkritischen Einzelanfragen (siehe N03).

llama.cpp — Llama 3.3 70B Q4_K_M GGUF

Modell: Llama-3.3-70B-Instruct-Q4_K_M.gguf. Backend: llama-cpp-python 0.3.20 mit CUDA/cuBLAS, alle Layer auf die GPU ausgelagert.

llama.cpp liefert beim Single-Stream-Decode rund 20 tok/s — besser als der aktuelle vLLM-AWQ-Wert und darauf zurückzuführen, dass der cuBLAS-basierte Kernel-Pfad von llama.cpp gut mit der Q4_K_M-Quantisierung harmoniert. llama.cpp unterstützt kein paralleles Batching mehrerer gleichzeitiger Anfragen wie vLLM; die 20 tok/s sind also eine Obergrenze pro Sitzung, keine Gesamtkapazität. Für interaktive Einzelnutzer-Workflows sind 20 tok/s eine angenehme Lesegeschwindigkeit bei englischer Ausgabe.

Die Prompt-Verarbeitung mit 1,568 tok/s ist hoch. Gemessen wird, wie schnell das Modell den Prompt aufnimmt (Prefill-Phase). Schnelles Prefill zählt, wenn Sie ein Modell mit langen System-Prompts oder Dokumentkontext betreiben. Bei 1,568 tok/s ist ein Dokumentkontext von 4,000 Tokens in unter 3 Sekunden verarbeitet, bevor die Generierung startet.

Zur Wirtschaftlichkeit und zum Vergleich mit Cloud-Alternativen siehe T01 (tok/s pro Euro) und T02 (Kosten pro Million Tokens on-premise vs. Cloud).

Wofür die beiden Engines gedacht sind

Stresstest — Dauerlast

Drei 60-sekündige Stresstests prüften die thermische und elektrische Stabilität unter Volllast: reiner GPU-Burn, reiner CPU-Burn und kombinierter GPU+CPU-Burn.

GPU-Burn (FP16-Matrixmultiplikation bei 100 %, 60 s)

Null Rechenfehler auf allen vier GPUs. Die Temperaturen stiegen von ~28°C Ausgangswert bis Sekunde 40 auf ein stabiles Plateau. GPU 2 lief mit 72°C am wärmsten — sie ist an dieser Position die heißeste Karte im Luftstrompfad des Gehäuses. Die Drosselschwelle der RTX 4090 liegt bei 83°C; der höchste Messwert (72°C) lässt 11°C Reserve. Zu keinem Zeitpunkt hat das System gedrosselt.

Die Leistungsgrenzen waren auf den vier Karten unterschiedlich gesetzt (480 W, 450 W, 500 W, 480 W). Diese kleine Inkonsistenz sollte vereinheitlicht werden: nvidia-smi -pl 480 -i 0,1,2,3 (oder der jeweils passende Grenzwert), um vor dem Produktiveinsatz einheitliche Limits zu setzen.

Kombinierter GPU+CPU-Burn (alle 4 GPUs + 64 CPU-Threads gleichzeitig, 60 s)

64 zusätzliche CPU-Threads unter 100 % Last senkten die aggregierten GPU-TFLOPS um lediglich 0.6 %. Der EPYC 7542 zieht unter Volllast rund 200 W TDP; das Gesamtsystem lag bei etwa 2.1–2.2 kW. Alle Temperaturen blieben im Rahmen: GPU 2 erreichte unter kombinierter Last 73°C und damit weiterhin 10°C unter der Drosselschwelle.

Die Load Average erreichte in der CPU-Burn-Phase 55+ (bei 64 Threads zu erwarten). Das System blieb durchgehend vollständig stabil: keine thermischen Ereignisse, keine Rechenfehler, keine Kernel-Panics.

Damit ist belegt, dass sich das System für 24/7-Dauerlast bei Inferenz-Workloads eignet, bei denen auch die CPU beschäftigt ist (Vorverarbeitung, Tokenisierung, Overhead der Serving-Infrastruktur).

Was gut funktioniert hat

Die EPYC-Plattform. Das PCIe-Lane-Budget ist wirklich gelöst. Alle vier RTX-4090-Karten laufen unter Last mit vollen Gen4 x16 (bestätigt im PCIe-Statuscheck 04d ). Keine Bifurcation, keine degradierten Slots. Manche AMD-Ryzen-Builds mit vier GPUs betreiben zwei oder mehr Slots nur mit x8; auf EPYC Rome ist das nicht der Fall.

RAM. 512 GB sind komfortabel. Beim Laden des Modells durch llama.cpp wird die 38 GB große GGUF-Datei per Memory-Mapping eingebunden; mit 512 GB können Sie neben dem LLM-Server weitere Prozesse betreiben, ohne dass diese um Speicher konkurrieren.

Sequenzielle NVMe-Geschwindigkeit. 4,589 MB/s sequenzielles Lesen halten die Ladezeiten kurz. In einem Workflow mit vielen Modellwechseln — laden, testen, wechseln — summiert sich das über einen Arbeitstag.

Temperaturen. Höchste Dauertemperatur im ungünstigsten Fall: 73°C (GPU 2, kombinierter Burn) mit 10°C Reserve. In einem typischen Inferenz-Workload laufen die GPUs nicht dauerhaft mit 100 % Auslastung — der Decode ist durch die VRAM-Bandbreite begrenzt, nicht durch die Rechenleistung —, weshalb die realen Betriebstemperaturen unter dem Spitzenwert des Stresstests liegen.

llama.cpp mit 1,568 tok/s bei der Prompt-Auswertung. Dieser Wert hat uns positiv überrascht. Der cuBLAS-Prefill-Pfad auf vier 4090ern ist schnell. Anwendungen mit langem Kontext profitieren davon.

Was uns überrascht hat

Der verpasste AWQ-Kernel in vLLM. Der Benchmark lief mit dem awq -Kernel statt mit awq_marlin. Die Abnahme-Suite hat das anhand der damaligen Modellkonfiguration automatisch so gewählt. Mit awq_marlindürfte der Durchsatz bei Einzelanfragen von 8 tok/s auf 16–24 tok/s springen. Das ist eine Frage der Softwarekonfiguration, keine Hardwaregrenze — prüfen Sie beim Aufsetzen des Produktiv-Servings den String der Quantisierungsmethode in vLLM.

D2H-Bandbreite. Device-to-Host mit 1.4 GB/s hat uns bei der ersten Analyse überrascht. Es handelt sich um das CUDA-Verhalten bei nicht gepinntem Speicher, nicht um einen PCIe-Fehler. Für Standard-Serving-Stacks (vLLM, llama.cpp) ist das irrelevant. Bei eigenem Inferenzcode, der Tensoren zur Nachverarbeitung auf die CPU verschiebt, sollten Sie gepinnte Speicherbereiche allokieren.

Von PCIe AER korrigierte Fehler an GPU 3. Während des vLLM-Benchmarks protokollierte GPU 3 (Bus c1:00.0) korrigierte PCIe-Fehler (RxErr + BadTLP). Sie wurden von der Hardware automatisch korrigiert und beeinflussten die Berechnung nicht. Wahrscheinliche Ursache: der Sitz des PCIe-Risers oder eine Link-Neuverhandlung bei Gen4-Geschwindigkeit. Empfehlung: unter dauerhafter Produktivlast beobachten; steigen die Fehlerzähler, das Riser-Kabel von GPU 3 neu stecken. Während der Stresstests selbst: null Fehler.

Kurzer Link-Flap der Netzwerkkarte. Die Netzwerkschnittstelle fiel während der GPU-Benchmark-Last kurz aus und kam wieder (13:38 UTC). Wahrscheinlich ein Spannungseinbruch durch das gleichzeitige Hochfahren der GPUs. Im Produktivbetrieb mit laufendem nvidia-persistenced (das die GPU-Kontexte initialisiert hält) fallen solche Transienten zu Lastbeginn kleiner aus. Aktivieren Sie nvidia-persistenced vor dem Produktivbetrieb als systemd-Dienst.

Was wir bei v2 anders machen würden

Aktivieren Sie awq_marlin von Anfang an. Prüfen Sie den Quantisierungs-Kernel-Pfad von vLLM während der Inbetriebnahme, nicht danach. Ergänzen Sie das Abnahmeskript um eine Kernel-Identitätsprüfung.

GPU-Leistungsgrenzen vor dem Benchmarking vereinheitlichen. Die vier Karten kamen mit unterschiedlich konfigurierten Limits (480 W, 450 W, 500 W, 480 W). Ein einheitliches Limit (nvidia-smi -pl) vor dem ersten Benchmark-Lauf liefert sauberere, besser vergleichbare Werte und vermeidet die ungleichmäßige Leistungsaufnahme beim kombinierten Burn.

Einen Monitoring-Stack bereits bei der Auslieferung einrichten. Prometheus mit DCGM-Exporter plus Grafana ist in wenigen Stunden aufgesetzt und macht GPU-Temperatur, VRAM-Auslastung und PCIe-Fehlerraten in Echtzeit sichtbar. Das gehört in die Standard-Inbetriebnahme statt auf die Aufgabenliste nach der Auslieferung. Siehe L05 für die Anleitung zum Aufbau des Stacks.

Tragen Sie nvidia-persistenced beim Betriebssystem-Setup fest in die systemd-Unit-Datei ein. Es ist ein Einzeiler, wird aber regelmäßig vergessen. Ohne ihn dauert die erste GPU-Last nach einer Ruhephase ein paar Sekunden länger und erzeugt genau den Spannungseinbruch, der den Link-Flap der Netzwerkkarte ausgelöst hat.

LVM erweitern. Vom Systemdatenträger (512 GB SATA) sind der LVM-Partition nur 100 GB zugewiesen. Die verbleibenden 374 GB liegen brach. Es gibt keinen Grund, das so zu lassen: lvextend und resize2fs dauern 30 Sekunden und geben Ihnen diesen Platz für Betriebssystem-Overhead, Logs und Docker-Layer zurück.

Eine zweite NVMe für den Modellspeicher erwägen. Die einzelne 2-TB-NVMe hält derzeit alle Modelle und wird sich füllen, sobald die Modellbibliothek wächst. Eine zweite 4-TB-NVMe im RAID 0 oder schlicht als separater Mountpunkt /mnt/nvme2 würde Flexibilität schaffen und die sequenzielle Leserate auch bei einer größeren Gesamtbibliothek hoch halten.

Vergleich: Alternativen zu diesem Build

Der Workload des Kunden hätte sich auch mit anderer Hardware abbilden lassen. Hier ein ehrlicher Vergleich:

4× RTX 4090 mit 96 GB sind die kleinste sinnvolle Konfiguration, um Llama 3.3 70B AWQ INT4 unter vLLM mit nennenswertem Batch-Durchsatz zu betreiben. Es ist nicht die Obergrenze: Ein 8-GPU-Build erhöht die Kapazität proportional. Für einen Forschungskunden, der eine einzelne dedizierte Workstation will und keinen Serving-Cluster, ist 4× oft der richtige Einstieg.

Weder die 4×- noch die 8×-Konfiguration verfügt über NVLink zwischen den GPUs; Tensor-Parallel-Inferenz läuft daher über PCIe. Praktisch wirkt sich das auf die TTFT-Latenz einzelner Anfragen aus, nicht auf den aggregierten Batch-Durchsatz. Bei Workloads in Teamgröße (Dutzende Anfragen pro Stunde, nicht Tausende) ist das kein limitierender Faktor. Für Anforderungen unter 100 ms TTFT siehe N03 sowie die Begründung, warum das Portfolio auf PCIe-verbundene Multi-GPU-Systeme statt auf NVSwitch-Fabrics setzt.

Gesamtleistung und Elektroplanung

Unter dauerhafter GPU-Last lag die Gesamtleistungsaufnahme bei rund 1,900–2,200 W, gemessen an den GPU-Schienen (1,914 W beim reinen GPU-Burn; ~2,100 W geschätzt zusammen mit CPU, Laufwerken und Board). Kalkulieren Sie die Wirkungsgradverluste der Netzteile ein (rechnen Sie mit 90 %) und planen Sie mindestens einen Stromkreis mit 16 A/230 V, besser 20 A für Reserve.

Das Layout mit zwei Netzteilen verteilt diese Last auf zwei Steckdosen. Beide müssen an Stromkreisen hängen, die die Last jeweils eigenständig tragen: Versorgt Netzteil A zwei GPUs mit je 500 W plus 200 W für Board und CPU, sind das 1,200 W auf diesem Stromkreis. Dimensionieren Sie entsprechend.

Kühlbedarf des Raums: Rechnen Sie das System mit 2.5 kW Dauerlast (konservativ, inklusive Wirkungsgradverlusten und Reserve). In einem Serverraum oder Rack-Schrank mit mehreren Systemen summiert sich dieser Wert schnell.

Siehe P01 zu Einphasen- vs. Dreiphasen-Anschluss und P04 zur Dimensionierung der Sicherungen.

Preisrahmen

Ein Build dieser Spezifikation — EPYC-7542-Plattform, 512 GB ECC-RAM, 4× RTX 4090, 2 TB NVMe, Rack-Gehäuse mit zwei Netzteilen — bewegt sich bei aktuellen Komponentenpreisen im Bereich €18,000–€24,000 zzgl. MwSt. — je nach Gehäusewahl, Beschaffungszeitpunkt des RAMs und GPU-Verfügbarkeit. Die Lieferzeit beträgt 10–28 Tage, abhängig von der Komponentenverfügbarkeit und bei Bestellung bestätigt.

Nicht enthalten sind Installation, Rack-PDU, Netzwerk (10-GbE-Switch, Verkabelung) sowie sämtliche Softwarelizenzen. Das System wird mit vorinstalliertem Ubuntu 24.04 LTS und vorkonfiguriertem Python-venv ausgeliefert; die Modellgewichte bringen Sie selbst mit.

Wofür dieser Build richtig ist

• LLM-Inferenz in Forschung und kleinen Teams. Ein 70B-Modell für ein Team von 5–15 Nutzern betreiben. Die 179 tok/s aggregiert unter vLLM bewältigen parallele Sitzungen komfortabel.
• Modellbewertung und -iteration. Kurze NVMe-Ladezeiten machen den Wechsel zwischen Kandidatenmodellen schnell. Dank des PCIe-Lane-Budgets der EPYC-Plattform laufen alle vier GPUs stets mit voller Bandbreite.
• Datensouveräne Deployments. Die gesamte Inferenz läuft lokal. Kein Token verlässt das Gebäude. Das ist der wichtigste nicht-wirtschaftliche Grund, im Forschungsumfeld on-premise zu arbeiten.
• Budgetbewusster Einstieg in die 70B-Klasse. Die RTX 4090 ist die Consumer-GPU mit dem größten VRAM. Mit 24 GB pro Karte und vier Karten kommen Sie auf 96 GB und erreichen die 70B-Klasse, ohne in die Preisregion professioneller GPUs zu wechseln.

Wofür dieser Build nicht geeignet ist

• TTFT unter 100 ms bei Einzelanfragen. Die Tensor-Parallel-Topologie über PCIe P2P setzt bei großen Modellen eine Untergrenze für die TTFT. Wenn Sie bei Modellen ab 70B schnelle interaktive Latenzen brauchen, ist diese Architektur die falsche Wahl. Dann benötigen Sie NVLink-verbundene GPUs — und damit eine völlig andere Hardwareklasse (siehe N03).
• Mehrere große Modelle gleichzeitig betreiben. Bei 96 GB Gesamt-VRAM und gpu_memory_utilization=0.80stehen Ihnen rund 77 GB nutzbar zur Verfügung. Ein zweites 70B-INT4-Modell passt nicht mehr hinein. Wenn Sie zwei Modelle gleichzeitig vorhalten müssen, wechseln Sie auf eine Plattform mit mehr VRAM pro GPU oder mit mehr GPUs.
• Produktiv-Serving im großen Maßstab. Für Hunderte parallele Nutzer oder SLA-gestützte Verfügbarkeit ist diese Architektur (keine NIC-Erweiterungen im 4-GPU-Gehäuse, Einzelknoten, Consumer-GPUs ohne ECC) nicht die richtige Grundlage. Dafür eignet sich der 8-GPU-Kentino-AI-Server mit L40 oder RTX Pro 6000 Blackwell, sauberem Monitoring und zwei Netzwerkkarten.
• Große Modelle trainieren. Mit 96 GB Gesamt-VRAM können Sie 70B-Modelle feinabstimmen (LoRA, QLoRA), aber kein vollständiges Parametertraining durchführen. Beim Training ist das VRAM-Budget enger als bei der Inferenz. Wenn Training Teil des geplanten Workloads ist, sollten Sie das einkalkulieren.

---

Dieser Beitrag ist Teil des Kentino Wiki, Reihe C (Fallstudien). Build-Daten gemessen am 2026-04-10. Artikel veröffentlicht am 2026-05-15. Korrekturen und ergänzende Messungen gern an info@kentino.com.