KI-Surrogatmodelle für CAE mit NVIDIA PhysicsNeMo: GPUs, Speicher je Sample, Datenablage

Was ein Surrogatmodell im CAE-Ablauf ändert

Ein KI-Surrogatmodell ist ein neuronales Netz, das auf den eigenen Simulationsergebnissen einer Abteilung trainiert wird und die Felder eines neuen Entwurfs, etwa Oberflächendruck, Wandschubspannung oder Verformung, in Sekunden statt in einem vollen Solver-Lauf vorhersagt. NVIDIA PhysicsNeMo ist ein quelloffenes Framework für diese Arbeit: Es liefert die Modelle, die Datenpipelines und das Training auf mehreren GPUs für Aerodynamik, Crash und Strukturmechanik. Das Training braucht einen GPU-Server mit viel Speicher je Karte und schneller Datenablage, typischerweise vier oder acht NVIDIA H200 NVL oder NVIDIA RTX PRO 6000 Blackwell Server Edition; für die Nutzung des trainierten Modells reicht eine Karte.

Der Solver bleibt die Referenz. Ein Surrogat sortiert Hunderte von Varianten vor, die vielversprechenden gehen in einen vollen Lauf. Damit verschiebt sich die Hardwarefrage: Die Solver-Läufe brauchen FP64- oder Single-Precision-Leistung und Speicher je Million Zellen, wie unser Leitfaden zu GPUs für CFD-Simulation erklärt, das Surrogat-Training dagegen Speicher je GPU für ein Trainings-Sample, Bandbreite zwischen den GPUs und eine Datenablage in Terabyte.

Dieser Leitfaden behandelt die Trainingsseite für das IT-Team, das sie aufbaut und betreibt. Unser Leitfaden zum KI-Server für die Automobil-Entwicklung zeigt, wo Surrogate neben CFD, Fahrsimulation und Perzeptionstraining in einer Abteilung stehen.

PhysicsNeMo im Oktober 2026: Release, Installation und Anforderungen

PhysicsNeMo beschreibt sich als „open-source PyTorch framework for physics machine learning“, seine Modelle sind gewöhnliche torch.nn.Module-Objekte. Release 2.1.0 hat die physikinformierten Beispiele auf eine Schnittstelle physicsnemo.sym umgestellt und damit das separate Paket physicsnemo-sym ersetzt.

NVIDIA-PhysicsNeMo-Repository, Releases-Seite und Changelog auf GitHub sowie die PhysicsNeMo-Systemanforderungen auf docs.nvidia.com, gelesen am 25. Oktober 2026. Die Releases-Seite zeigt Tag und Monat; das Jahr ergibt sich aus dem Changelog, der Release 2.1.0 auf den 26. Mai 2026 datiert.

Die Liste der empfohlenen Hardware nennt unter anderem B100 und RTX PRO 6000 Blackwell für Blackwell sowie H100 und H200 für Hopper, auf Grundlage der Tests des PhysicsNeMo-Teams. NVIDIA rät zu seinem Container, um „the benefits of all the performance improvements“ zu erhalten. Die Standardinstallation im README nutzt das Extra cu13; CUDA 13 braucht den Treiber 580.65.06 oder neuer, wie unser Leitfaden zur RAPIDS-Workstation nach NVIDIAs Anforderungen angibt. Auf RTX-PRO-Blackwell-Karten scheitert ein Container oder Wheel ohne sm_120-Kernels mit dem Fehler, den unser Leitfaden zu „no kernel image“ auf Blackwell erklärt.

Modelle und Rezepte: Surrogatmodelle für CFD mit DoMINO, Crash und Strukturmechanik

Das Repository nennt unter anderem die Surrogat-Architekturen FNO, MeshGraphNet, Transolver, GeoTransolver, FLARE, DoMINO, FIGConvNet und das experimentelle GLOBE. Die CAE-Anwendungen sind als Rezepte verpackt.

Außenaerodynamik. Das vereinheitlichte Rezept trainiert standardmäßig GeoTransolver, einen Transformer für Regression auf Punktwolken mit 12 Schichten, 256 versteckten Einheiten und 8 Heads, außerdem Transolver, GLOBE und FLARE; DoMINO ist in der Rezeptgalerie als „DRAFT, doesn't run end-to-end“ markiert und hat ein eigenes Beispiel. DrivAerML ist der Datensatz, den das Rezept heute unterstützt, HiLift- und SHIFT-Datensätze sind angekündigt. Die Standardgenauigkeit ist bfloat16, float16 und float32 werden ebenfalls unterstützt.

Crash. Das Crash-Rezept trainiert auf LS-DYNA-Ergebnissen im Format d3plot, die das separate PhysicsNeMo-Curator in VTP oder Zarr umwandelt. Seine Beispielkonfiguration nutzt 121 Trainingsläufe, 5 Validierungsläufe und 51 Zeitschritte und vergleicht One-Shot-, zeitkonditionierte und autoregressive Verfahren; das README hält das zeitkonditionierte Verfahren für lange Zeithorizonte für das beste.

Struktur. Ein Beispiel mit einer sich verformenden Platte deckt die Strukturmechanik ab, die Galerie ergänzt Fälle zur Underfill-Dosierung und zur Luftströmung im Rechenzentrum für CFD.

Die 121 Läufe des Crash-Beispiels zeigen die Größenordnung, die eine Abteilung vor dem Training braucht: Hunderte abgeschlossene, konsistente Simulationen einer Produktfamilie. Ein Team mit einem solchen Archiv hat die Daten; der Server entscheidet, wie schnell es am Modell iterieren kann.

Trainingsdaten: Ablage für Simulationsergebnisse

Simulationsergebnisse sind groß, und das Surrogat-Training liest sie immer wieder. Die Datensatzkarte von DrivAerML auf Hugging Face nennt 500 Varianten des DrivAer-Stufenhecks, davon 484 öffentliche Läufe, zusammen 31,2 TB unter CC BY-SA 4.0, gerechnet mit OpenFOAM v2212.

Datensatzkarte DrivAerML auf Hugging Face, gelesen am 25. Oktober 2026. NVIDIAs DoMINO-README nennt „mesh sizes of 160M points per example“.

Nach unserer Rechnung sind 31,2 TB über 484 Läufe rund 64 GB je Lauf. Die Vorverarbeitung mit Curator nach Zarr „takes a couple of hours“, so das DoMINO-README, und die verarbeitete Kopie liegt neben den Rohdaten. Das DoMINO-README merkt außerdem an, dass das Modell standardmäßig rund hundertmal mehr Daten liest, als die Sampling-Größe braucht; deshalb mischt es die Volumendaten in der Vorverarbeitung, damit jeder Lesezugriff zufällige Ausschnitte statt des ganzen Netzes holt.

Für die Ablage planen wir drei Ebenen: das Rohdatenarchiv auf dem Dateispeicher der Abteilung, den verarbeiteten Trainingsdatensatz auf lokalen NVMe-Laufwerken im Trainingsserver und Checkpoints auf beiden. Ein Trainingsdatensatz aus einigen hundert Läufen passt auf mehrere NVMe-Laufwerke; der vollständige Rohdatensatz DrivAerML gehört nicht auf den GPU-Server. Unser Leitfaden zu CPU, RAM und Speicher für einen Server mit vier GPUs zeigt die Laufwerksaufteilung.

GPU-Speicher je Sample: Die Sampling-Auflösung entscheidet

Ein Surrogat lädt kein Netz mit 160 Millionen Punkten in eine Karte. Jeder Trainingsschritt sampelt eine Teilmenge der Zellen oder Punkte, und deren Zahl bestimmt zusammen mit dem Modell den Speicher je GPU. Die Batch-Größe ist im vereinheitlichten Rezept 1: Laut README unterstützt derzeit kein Modell im Rezept batch_size > 1.

Das Rezept nennt eine veröffentlichte Zahl für GLOBE, sein neuestes Modell, „designed for large 3D use cases“: rund 143 GB je GPU bei sampling_resolution=50000 in bf16, und 200.000 passen nicht auf Karten der 180-GB-Klasse. Der Standardwert von sampling_resolution in train.yaml ist 200.000, in der Galerie laufen andere Modelle mit 50.000 bis 200.000.

Unser Vergleich der rund 143 GB je GPU aus dem Rezept mit dem angegebenen Kartenspeicher laut NVIDIA-Produktseiten; GLOBE-Wert aus dem README des vereinheitlichten PhysicsNeMo-Rezepts für Außenaerodynamik, gelesen am 25. Oktober 2026.

Die Anforderung bestimmt also das Modell ebenso wie die Karte. Für GeoTransolver, den Standard, veröffentlicht das Rezept keinen Speicherwert, und das DoMINO-README rät bei Speichermangel, model.volume_points_sample und model.surface_points_sample zu senken. Lassen Sie vor der Auslegung das geplante Modell auf einer Karte mit zwei oder drei Sampling-Auflösungen laufen und lesen Sie den Spitzenspeicher mit nvidia-smi ab; schicken Sie uns diese Werte, und wir legen den Server danach aus. Passt ein Sample nicht auf eine Karte, lässt es sich auf mehrere verteilen.

Mehrere GPUs: DDP, FSDP2 und ShardTensor

PhysicsNeMo trainiert auf drei Arten über mehr als eine Karte. Mit DistributedDataParallel (DDP) hält jede GPU das ganze Modell und bearbeitet ihr eigenes Sample; das Rezept startet es mit torchrun --nproc_per_node=N und mittelt die Verluste mit einem einzigen zusammengefassten All-Reduce. FSDP2 verteilt Parameter und Optimiererzustand auf die GPUs, Release 2.2.0 hat vollständiges Speichern und Laden von FSDP2-Checkpoints ergänzt. ShardTensor, ein Tensortyp, der Domänenparallelität kennt, teilt ein hochaufgelöstes Sample auf mehrere GPUs auf und arbeitet zusammen mit DDP oder FSDP2.

Das DoMINO-README nennt das Ziel des Shardings: höher aufgelöste Eingaben und größere latente Räume, ohne wesentlich mehr Rechenzeit. Sein Parameter domain_size gibt die Zahl der GPUs je Batch an, 1 ist der Normalfall, und verlangt bei größeren Werten shard_points oder shard_grid. Wird ein Sample geteilt, tauschen die GPUs in jedem Schritt Daten aus; die Verbindung zwischen ihnen trägt also mehr Verkehr als bei reiner Datenparallelität. Hier zählt die NVLink-Brücke der H200 NVL: 900 GB/s je GPU zwischen verbundenen Karten, gegenüber PCIe Gen5 bei der RTX PRO 6000 Server Edition, die NVIDIA ohne NVLink führt.

Zur Dauer berichtet NVIDIAs DoMINO-README, dass nach Leistungsarbeit über mehrere Releases „overall training performance has decreased from about 5 days to just over 4 hours, with eight H100 GPUs“. Zu den Änderungen gehörten ein gemeinsamer Speicherpool mit RMM und weniger Lesezugriffe auf Volumendaten. Die Zahl gilt für einen Datensatz und ein Modell auf H100; sie zeigt eher die Wirkung der Datenpipeline als die einer Karte.

H200 NVL oder RTX PRO 6000 Server Edition für das Training

Beide Karten stehen über ihre Architektur auf NVIDIAs Hardwareliste für PhysicsNeMo, und beide unterstützen den Standard bfloat16. Sie unterscheiden sich im Speicher je GPU, in der Speicherbandbreite und in der Verbindung zwischen den Karten.

NVIDIA-Produktseiten und Product Briefs zur H200 NVL und zur RTX PRO 6000 Blackwell Server Edition, wie in unserem CFD-Leitfaden und unserem Leitfaden zum Server mit vier Karten zitiert; gelesen am 24. Oktober 2026.

Die H200 NVL ist die Trainingskarte, wenn ein Sample mehr als 96 GB braucht, wenn ShardTensor Samples auf mehrere Karten verteilt oder wenn die bandbreitenabhängigen Teile eines Graph- oder Transformer-Modells überwiegen. Jede H200 NVL enthält außerdem ein fünfjähriges Abonnement von NVIDIA AI Enterprise. Die RTX PRO 6000 Server Edition passt, wenn das Modell bei der geplanten Sampling-Auflösung deutlich unter 96 GB je Karte bleibt und das Training als reines DDP läuft; ihre 120 TFLOPS FP32 und 96 GB bedienen in derselben Abteilung auch die GPU-Solver.

Wir liefern beide Karten; nennen Sie uns Modell, Datensatzgröße und Trainingsplan, und unser Team antwortet mit einer Konfiguration für jede der beiden Karten.

Das trainierte Surrogat im Entwurfsprozess

Ein trainiertes Surrogat beantwortet eine Geometrie nach der anderen, ohne Gradienten und Optimiererzustand, und braucht daher weit weniger Speicher als das Training. DoMINO nimmt STL-Geometrien als Eingabe, sein Beispiel enthält ein Skript inference_on_stl.py. Zeiten für die Inferenz dieser Modelle veröffentlicht NVIDIA nicht.

Für die Konstrukteure bieten sich zwei Aufteilungen an. Die erste ist ein gemeinsamer Inferenzdienst auf dem Trainingsserver oder auf einer seiner Karten, wobei MIG eine RTX PRO 6000 Server Edition in bis zu vier isolierte Instanzen zu 24 GB teilt, wie unser Leitfaden zu MIG-Profilen zeigt. Die zweite ist eine Workstation je Ingenieur mit einer RTX PRO 6000 Workstation Edition oder Max-Q, die auch CAD und Vorverarbeitung übernimmt; unser Leitfaden zu GPU-Plattformen für Ingenieurbüros vergleicht die Varianten.

Konfigurationen für das Surrogat-Training

Sie gehen von den Referenz­konfigurationen auf unserer Seite zu KI-Servern aus. Arbeitsspeicher und Kerne folgen NVIDIAs Konfigurations­leitfaden für NVIDIA-Certified Systems: mindestens das Doppelte des GPU-Speichers als Arbeitsspeicher, mindestens sechs Kerne je GPU, zwei Sockel.

Referenz­konfigurationen unserer Seite zu KI-Servern; die Leistung an der Steckdose ist unsere Schätzung (Karten bei 600 W plus zwei EPYC 9355 mit 280 W oder zwei EPYC 9555 mit 360 W, plus 15 Prozent für den Rest), wie in unseren verwandten Leitfäden; eine Messung am gelieferten System bestätigt sie.

Ein Server mit vier Karten liegt bei voller Leistung über den 2,94 kW, die wir je 230-V-Anschluss mit 16 A einplanen, und braucht einen Anschluss mit 32 A oder Drehstrom, wie unser Leitfaden zu Strom und Kühlung im GPU-Rack herleitet. Das Training hält die Karten stundenlang nahe Volllast, deshalb gelten die Zuluftgrenzen des gewählten Gehäuses. Unser Leitfaden zur NVLink-Brücke der H200 NVL erklärt die Zweifach- und Vierfach-Aufteilung.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration passend zu Ihrer Arbeitslast und Ihrem Budget aus und antwortet innerhalb eines Werktages. Wir bauen KI-Server auf Bestellung mit H200 NVL oder RTX PRO 6000 Server Edition, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung und Herstellergarantie auf jede Komponente, und installieren auf Wunsch Betriebssystem, NVIDIA-Treiber, CUDA und eine Container-Laufzeit. Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt. Die Einrichtung der Trainingsumgebung und der Betrieb des trainierten Modells gehören zu unserem Service Private AI/ML.

FAQ