Infrastruktur für das Training von Modellen für maschinelles Lernen

Wenn's um die Infrastruktur fürs maschinelle Lernen geht, denkt man sofort an GPUs. NVIDIA A100s, H100s, Cloud-GPU-Instanzen. Das passt gut für bestimmte Aufgaben: zum Trainieren großer neuronaler Netze, vor allem Transformer und großer Bildverarbeitungsmodelle, wo der Durchsatz bei der Matrixmultiplikation die Zeit bis zur Fertigstellung bestimmt.

Für einen Großteil der ML-Arbeit in der Praxis ist das nicht richtig. Feature Engineering, klassisches ML, Hyperparameter-Tuning, Inference Serving und Gradient Boosting brauchen keine GPU-Beschleunigung. Sie brauchen schnelle CPUs, viel RAM und Speicher-I/O, der während der Arbeit nicht gedrosselt wird. Genau das ist das Profil eines dedizierten Bare-Metal-Servers.

Die Entscheidung zwischen GPU und CPU für ML-Workloads

Wann ist eine GPU die richtige Wahl?

Das Training neuronaler Netze mit vielen Parametern kann von der Parallelität von GPUs profitieren, weil moderne Deep-Learning-Frameworks das Training in Matrixoperationen aufteilen, die GPUs viel schneller als CPUs machen können. Ein Convolutional Neural Network, das auf ImageNet trainiert wird, ein BERT, das auf einem großen Korpus fein abgestimmt wird, oder ein Diffusionsmodell für die Bilderzeugung: Das sind alles Aufgaben für GPUs. Man kann sie zwar auf CPUs laufen lassen, aber das ist praktisch unbrauchbar, wenn es um mehr als kleine Datensätze geht.

Cloud-GPU-Instanzen sind sinnvoll, wenn GPU-Jobs nicht so oft vorkommen und es sich nicht lohnt, eigene GPU-Hardware anzuschaffen. A100-Instanzen für 3 bis 10 Dollar pro Stunde sind für gelegentliche Trainingsläufe völlig okay.

Wenn dedizierte CPU-Server gewinnen

Einige ML-Workload-Kategorien laufen auf CPUs mit vielen Kernen schneller als auf Cloud-GPU-Instanzen und sind dabei viel günstiger:

• Gradient Boosting (XGBoost, LightGBM, CatBoost): Diese Frameworks sind echt gut für CPU-Parallelität optimiert. Das Training mit XGBoost auf 16 Kernen mit OpenMP ist echt schnell. GPU-Beschleunigung für Gradient Boosting ist super für riesige Datensätze, aber es macht die Sache komplizierter und teurer, was sich bei Datensätzen unter 10 GB kaum lohnt.
• scikit-learn in großem Maßstab: Random Forests, SVMs und Ensemble-Methoden laufen parallel auf mehreren CPU-Kernen. Ein 16-Kern-EPYC schafft eine kreuzvalidierte Rastersuche über Hunderte von Parameterkombinationen in der Zeit, die eine Single-Core-Cloud-Instanz brauchen würde, um nur einen Bruchteil davon zu erledigen.
• Feature-Engineering-Pipelines: Die auf Pandas , Polars und Spark basierende Feature-Berechnung braucht viel Speicher und ist I/O-gebunden. Mit 192 GB RAM bleibt deine ganze Feature-Matrix im Speicher. Dank NVMe wird das Laden von Daten aus Parquet-Dateien nicht zum Problem.
• Hyperparameter-Optimierung: Wenn man 16 parallele Optuna-Versuche durchführt , jeder als einzelner Thread-Trainingsjob, werden alle 16 Kerne gleichzeitig genutzt. Das ist besser, als für eine GPU-Instanz zu bezahlen, die während der Auswertungsphase jedes Versuchs meistens nicht genutzt wird.
• ML-Inferenz-Bereitstellung: Die meisten Produktions-Inferenz-Endpunkte für klassisches ML, tabellarische Modelle und kleine neuronale Netze laufen auf der CPU. Die Latenzanforderungen liegen normalerweise im Bereich von zehn Millisekunden, was die CPU-Inferenz locker schafft.

AMD EPYC 4545P für maschinelles Lernen

Vorteile der Architektur

Der AMD EPYC 4545P ist ein Prozessor mit 16 Kernen und 32 Threads, der auf der Zen 4-Architektur von AMD basiert. Für ML-Workloads sind drei Architekturmerkmale wichtig:

• AVX-512-Unterstützung: Macht vektorisierte Gleitkommaoperationen für numerische Bibliotheken wie NumPy und Intel MKL möglich . Mit AVX-512 kompilierte ML-Frameworks laufen auf kompatiblen CPUs 20 bis 40 % schneller als auf Systemen, die nur AVX-256 unterstützen.
• Großer L3-Cache: Verringert die Latenz beim Speicherzugriff für häufig genutzte Modellparameter und Merkmalsdaten während Trainingsschleifen. Besonders das XGBoost-Training profitiert von Datenstrukturen, die im Cache gespeichert sind.
• DDR5-Speicherbandbreite: DDR5 hat ungefähr die 1,5-fache theoretische Bandbreite von DDR4. Bei Operationen, die von der Speicherbandbreite abhängen, wie zum Beispiel große Matrixmultiplikationen auf einer CPU, bedeutet diese Bandbreite direkt schnellere Berechnungen.

Das sind keine kleinen Unterschiede. Beim XGBoost-Training mit einem 5-GB-Datensatz liefert die Kombination aus 16 Kernen, AVX-512 und DDR5-Bandbreite auf einem EPYC-System Ergebnisse, die mit dem GPU-beschleunigten Training für diese spezielle Workload-Klasse mithalten können.

Speicherkapazität zum Laden von Datensätzen

Der häufigste praktische Engpass bei CPU-basiertem ML ist das Laden von Daten. Eine Merkmalsmatrix mit 50 Millionen Zeilen und 200 Merkmalen im float32-Format braucht ungefähr 40 GB RAM. Auf einem System mit 32 GB muss dieser Datensatz in Teilen geladen werden, was jeden Schritt der Trainingspipeline komplizierter macht.

Auf einem 192-GB-System wird diese 40-GB-Feature-Matrix einmal geladen und bleibt während der Kreuzvalidierungs-Folds, mehreren Algorithmusvergleichen und der Feature-Wichtigkeitsanalyse im Speicher. Kein Chunking. Kein erneutes Laden zwischen den Experimenten. Die Geschwindigkeit der Experimentiterationen wird deutlich verbessert, vor allem in den explorativen Phasen.

TensorFlow und PyTorch auf der CPU

CPU-Training für kleinere neuronale Netze

Nicht jedes Training von neuronalen Netzen braucht eine GPU. Flache Netze, tabellarische neuronale Netze (TabNet, SAINT) und kleine Sequenzmodelle, die mit mittelgroßen Datensätzen trainiert werden, laufen ganz gut auf der CPU, wenn die Anzahl der Modellparameter unter etwa 10 bis 50 Millionen bleibt.

PyTorch nutzt OpenMP für CPU-Parallelität. Wenn du OMP_NUM_THREADS=16 und torch.set_num_threads(16) auf einem System mit 16 Kernen einstellst, wird sichergestellt, dass PyTorch beim Training alle verfügbaren Kerne nutzt. Bei Batch-Größen, die in den CPU-Cache passen (kleine Modelle, dichte Schichten), ist der Trainingsdurchsatz höher als man normalerweise denkt.

Die CPU-Optimierung von TensorFlow nutzt Intel MKL-DNN (oneDNN), das auf kompatibler Hardware von AVX-512 profitiert. Mit AVX-512 erstellte TensorFlow-Builds laufen auf EPYC messbar schneller als auf älteren Xeon-Systemen, die noch vor der Unterstützung von AVX-512 entwickelt wurden.

Das Laden von Daten als echter Engpass

Bei CPU-Trainingsschleifen ist der Datenlader oft langsamer als der Modell-Vorwärtsdurchlauf. PyTorch-Datenlader mit num_workers=8 oder höher auf einem 16-Kern-System können Batches schnell genug vorab laden, damit die Trainingsschleife nicht ins Stocken gerät.

NVMe ändert diese Rechnung noch mehr. Das Lesen von Parquet-Dateien für das Batch-Training auf einem SSD hängt oft. Bei NVMe 5 GB/s sequentiellem Lesen bleiben die Datenlader-Threads auch bei großen Batch-Größen vor der Trainingsschleife. Das ist wichtig für Modelle, die mit Bilddaten, von der Festplatte tokenisierten Texten oder tabellarischen Daten aus großen Parquet-Partitionen trainiert werden.

Hyperparameter-Optimierung Parallelität

Die Hyperparametersuche ist total parallel. Jeder Versuch läuft unabhängig. Auf einem 16-Kern-System kannst du 16 Versuche gleichzeitig machen, ohne dass es zu einem Overhead bei der Kommunikation zwischen den Prozessen kommt.

Optuna, Ray Tune und GridSearchCV von scikit-learn unterstützen alle die parallele Ausführung von Versuchen über die Multiprocessing-Funktion von Python. Eine Rastersuche über 256 Parameterkombinationen, die mit einem einzelnen Thread 8 Stunden dauert, ist mit 16 Kernen in etwa 30 Minuten erledigt. Diese Komprimierung verändert die Arbeitsweise von ML-Teams.

Cloud-Alternativen für diesen Anwendungsfall kosten entweder pro Core, was bei langen Suchvorgängen schnell teuer wird, oder man muss verteilte Ray-Cluster hochfahren, was mit zusätzlichem Verwaltungsaufwand verbunden ist. Ein dedizierter Server, auf dem alle 16 Kerne für eine 30-minütige Suche laufen, hat keine Kosten für die Cluster-Koordination.

Inferenz-Bereitstellungsinfrastruktur

Latenz und Durchsatz für Produktionsendpunkte

Die meisten ML-Inferenz-Endpunkte in der Produktion brauchen keine GPU. Tabellarische Modelle, Empfehlungsmaschinen, Klassifikatoren zur Betrugserkennung und NLP-Modelle mit weniger als 100 Millionen Parametern bearbeiten Anfragen auf modernen CPUs in 1 bis 20 Millisekunden. Die GPU-Inferenz erhöht die Infrastrukturkosten und die Komplexität, was nur dann sinnvoll ist, wenn du große Sprachmodelle oder Bildgenerierung einsetzt.

Ein dedizierter Server mit FastAPI oder TorchServe kann bei typischen tabellarischen ML-Modellen mehrere hundert bis ein paar tausend Inferenzanfragen pro Sekunde abarbeiten, je nachdem, wie komplex das Modell ist und wie viel Rechenaufwand die Berechnung der Features braucht. Für Teams, die gerade für GPU-Inferenzinstanzen für kleinere Modelle bezahlen, kann die Umstellung auf CPU-Inferenz auf dedizierter Hardware die Kosten für die Inferenzinfrastruktur um 60 bis 80 % senken.

Modell-Caching und Speicher

Um mehrere Modellversionen gleichzeitig im Speicher zu haben, braucht man RAM. Eine ML-Plattform, die 10 verschiedene Modellversionen mit einer Größe von jeweils 2 bis 4 GB bedient, braucht allein für das Modell-Caching 20 bis 40 GB Speicher, noch bevor man den Overhead für die Bearbeitung von Anfragen mitrechnet. Mit 192 GB hat man genug Platz für eine vollständige Modellregistrierung im Speicher sowie für die Anwendungsschicht und das Betriebssystem, ohne dass es zu Konflikten kommt.

Kostenvergleich: Optionen für die ML-Infrastruktur

Anwendungsfall	Cloud-Option	Cloud-Kosten	InMotion Hosting	InMotion Hosting
XGBoost / Gradientenverstärkung	c5.4xlarge (16 vCPU)	~480 $/Monat	Extrem dediziert (16 Kerne)	349,99 $/Monat
Hyperparameter-Optimierung (parallel)	c5.4xlarge Spot	~150 $/Monat + Risiko	Fortgeschrittene dedizierte	149,99 $/Monat
CPU-Inferenz-Berechnung	c5.2xlarge x2	~480 $/Monat	Unverzichtbar Engagiert	99,99 $/Monat
Umfangreiches Feature Engineering im Arbeitsspeicher	r5.4xlarge (128 GB)	~780 $/Monat	Extrem dediziert (192 GB)	349,99 $/Monat

Was auf der Cloud-GPU bleibt

Dedizierte CPU-Server können Cloud-GPUs nicht für alle Aufgaben ersetzen. Die Feinabstimmung großer Sprachmodelle, das Training von Vision-Transformern von Grund auf und das Training mit stabiler Diffusion sind immer noch an GPUs gebunden. Der praktische Ansatz für die meisten ML-Teams:

• Mach Feature Engineering, EDA, Gradient Boosting und Inferenz auf einer speziellen CPU-Infrastruktur.
• Nutze Cloud-GPU-Spot-Instanzen für regelmäßige Deep-Learning-Trainingsjobs.
• Verwende dedizierte CPU-Inferenz für alle Modelle außer sehr großen neuronalen Netzen.
• Verarbeite die Daten vor der Bereitstellung auf dediziertem NVMeSpeicher statt auf Cloud-Objektspeicher.

Dieser hybride Ansatz nutzt die Kosten- und Leistungsvorteile beider Optionen, ohne dass man sich bei unterschiedlichen Anforderungen für eine einzige Infrastruktur entscheiden muss.

Einrichten

Der Extreme Dedicated ServerInMotion Hosting kommt mit einem AMD EPYC 4545P, 192 GB DDR5 ECC RAM und zwei 3,84 TB NVMe , die vom APS-Team InMotion Hostingverwaltet werden. Die Einrichtung der Python-Umgebung, CUDA (falls du später eine externe GPU hinzufügst) und die Installation des ML-Frameworks gehören zur Standard-Serverkonfiguration, bei der InMotion Solutions im Rahmen von Premier Care helfen kann.

• Schau dir mal die dedizierten Server an: inmotionhosting .com/dedicated-servers
• Vergleich der Preisstufen: inmotionhosting .com/dedicated-servers/dedicated-server-price
• Details zu Premier Care: inmotionhosting .com/blog/inmotion-premier-care/

Für Teams, die über 300 Dollar pro Monat für Cloud-CPU-Instanzen für ML-Workloads ausgeben, macht sich der Wechsel zu dedizierter Hardware schon im ersten Abrechnungszeitraum bezahlt.