Auf einen Blick
Was „AI-Infrastruktur” auf Infrastrukturebene wirklich bedeutet. Praktische Sizing-Regeln, Referenz-Node-Profile und operative Leitplanken für den Produktivbetrieb.
Geeignet für
- Klassisches ML-Training im großen Maßstab (XGBoost, LightGBM, scikit-learn)
- Deep-Learning-Training und Fine-Tuning (PyTorch, TensorFlow, JAX)
- LLM-Inferenz und Serving (Batch und Real-Time)
- Embeddings, Reranking und GPU-beschleunigte Feature-Pipelines
- MLOps-Pipelines, die wiederholbares Training und kontrollierte Deployments erfordern
Zentrale Infrastruktur-Engpässe
- GPU-Speicherkapazität—die erste harte Grenze bei Training und Inferenz
- GPU-zu-GPU- und Node-zu-Node-Kommunikation für verteiltes Training
- Storage-Durchsatz für Data Loading und Checkpointing
- Vorhersehbare Latenz bei Inferenz unter Concurrency, inklusive KV-Cache-Wachstum
Wie „gut" aussieht
- Trainingsläufe werden durch Rechenarbeit begrenzt, nicht durch Warten auf Daten oder das Wiederholen fehlgeschlagener Jobs
- Fine-Tuning passt, ohne ständig OOM-Brände zu löschen
- Inferenz-Latenz bleibt stabil, während Concurrency steigt
- Kosten werden durch Hardware-Entscheidungen bestimmt, die Sie kontrollieren, nicht durch überraschende Abrechnungen
Wählen Sie Ihren AI-Ansatz
Die meisten Stacks fallen in eines dieser vier Muster. Wählen Sie das Modell, das dazu passt, wie Ihre Modelle von Daten in Produktion gelangen.
1. Klassisches ML zuerst auf CPU
Verwenden, wenn
- Ihre Modelle tabellarisch sind und CPU-freundlich laufen
- Sie viel RAM und hohe Memory Bandwidth brauchen, nicht GPUs
- Ihnen Durchsatz und Reproduzierbarkeit wichtiger sind als rohe FLOPS
Infrastrukturprofil
- CPU-Nodes mit hoher Core-Anzahl
- Große RAM-Footprints für Feature Engineering und Joins
- Schneller lokaler Storage für Feature Stores, Parquet-Caches und Spill
2. Deep-Learning-Training und Fine-Tuning
Verwenden, wenn
- Sie neuronale Netze trainieren oder Foundation Models fine-tunen
- Ihr Bottleneck GPU-Speicher und Trainingsdurchsatz ist
- Sie zuverlässiges Checkpointing und wiederholbare Runs brauchen
Infrastrukturprofil
- GPU-dichte Nodes
- Starke CPU und RAM, um GPUs konstant zu versorgen
- Schneller Storage und hoher Durchsatz für Checkpointing und Dataset Reads
- High-Performance-Interconnect, wenn Sie Training über mehrere Nodes skalieren
3. LLM-Inferenz und Model Serving
Verwenden, wenn
- Sie Real-Time-Inferenz mit strikten Latenz-Zielen betreiben
- Sie Batch-Inferenz mit hohem Durchsatz fahren
- Sie vorhersehbares Concurrency-Verhalten benötigen
Infrastrukturprofil
- GPU-Nodes, optimiert für stabile Latenz
- Genug GPU-Speicher-Headroom für KV-Cache, der mit Batch Size und Context Length wächst
- In Produktion betreiben Sie typischerweise einen Model Server, der Dynamic Batching und Concurrent Execution unterstützt. Das sind Entscheidungen auf Software-Ebene, keine Infrastruktur-Features
4. Hybrid: Hier trainieren, dort serven
Verwenden, wenn
- Sie eine klare Trennung zwischen Training-Bursts und Production Serving wollen
- Sie unabhängig für Experimente und Produktion skalieren müssen
- Sie sauberere Kosten-Zuordnung pro Workload wollen
Infrastrukturprofil
- Getrennte Worker-Pools für Training und Inferenz
- Gemeinsamer Storage, plus Ihre Artifact-Management- und Observability-Layer
- Klarer Promotion-Pfad vom Experiment in die Produktion
Was ist AI-, Machine-Learning- und Deep-Learning-Infrastruktur?
AI-Infrastruktur ist die Kombination aus Compute, Storage und Netzwerk, die zuverlässig bewältigt:
- Datenaufbereitung und wiederholtes Lesen von Datasets während des Trainings
- Training, Fine-Tuning und Checkpointing
- Model Serving mit vorhersehbarer Latenz und Throughput
- Sicheres Iterieren—Versioning, Rollback und Reproduzierbarkeit
Der schwierige Teil ist nicht „PyTorch zu betreiben”. Der schwierige Teil ist zu verhindern, dass die Plattform zur Chaosmaschine wird, wenn:
- Experimente sich vervielfachen und jeder heute GPUs braucht
- Training-Jobs mitten im Lauf scheitern und Checkpoints langsam sind
- Inference-Concurrency ansteigt und der KV-Cache Ihr VRAM auffrisst
- Teams Modelle in Produktion bringen, ohne konsistente Performance-Baselines
Wann sollte ich AI-Infrastruktur einsetzen?
Verwenden Sie diesen Ansatz, wenn:
- Ihr ML business-kritisch ist und Sie vorhersehbare Performance benötigen
- GPU-Workloads konstant genug sind, dass Cost Control zählt
- Sie Kontrolle brauchen, wo Daten und Modelle leben
- Sie einen Produktionspfad wollen, der sich nicht jeden Monat ändert
Überspringen Sie diesen Ansatz, wenn:
- Sie nur gelegentlich kleine Experimente machen
- Sie nicht das Team haben, um ML in Produktion zu betreiben
- Sie elastisch auf Null skalieren müssen und Ihre Workloads wirklich sporadisch sind
Faustregeln fürs Sizing
Diese Zahlen sind keine Gesetze. Sie sind ein sinnvoller Startpunkt für AI-Workloads. Der Schlüssel ist Sizing rund um GPU-Speicher, Data Throughput und Checkpointing.
Eine praktische Denkweise: Wenn Sie die Parameterzahl kennen, können Sie ein erstes VRAM-Budget abschätzen. Danach addieren Sie Activation Memory, getrieben durch Batch Size und Sequence Length. Für Inferenz addieren Sie KV-Cache-Headroom, der mit Concurrency und Kontext wächst.
Baseline-Faustregel
GPU-Speicher für Transformer-Training
Planen Sie ~18 Bytes pro Parameter für Mixed Precision AdamW, plus Activation Memory
GPU-Speicher für Transformer-Inferenz
Planen Sie ~6 Bytes pro Parameter für Mixed Precision Inferenz, plus Activation Memory
Inference-Headroom
Reservieren Sie VRAM für KV-Cache—er skaliert mit Batch Size und maximaler Kontextlänge plus maximalen neuen Tokens
Storage throughput
Priorisieren Sie hohen Throughput für wiederholtes Dataset-Lesen und Checkpointing
Training-Performance-Hebel
Mixed Precision ist ein gängiger Weg zu höherem Throughput auf Tensor-Core-GPUs
Was das Sizing schnell verändert
Sie brauchen mehr GPU-Speicher, wenn:
- Sie Batch Size oder Sequence Length erhöhen
- Sie große Modelle fine-tunen, ohne aggressive Memory-Taktiken
- Sie lange Context Windows mit hoher Concurrency serven
Sie brauchen mehr Storage-Throughput, wenn:
- Sie große Trainings-Datasets wiederholt lesen
- Sie häufig checkpointen und große State Snapshots schreiben
- Sie verteiltes Training betreiben und mehrere Nodes parallel checkpointen
Sie brauchen mehr Netzwerk, wenn:
- Sie Training über mehrere Nodes skalieren und Kommunikation zum Bottleneck wird
- Sie stabile Multi-Node-Collective-Performance unter Last wollen

Welche Pain Points löst das?
- Trainingsläufe, die stocken, weil Data Loading nicht mithält
- OOM-Failures durch unrealistische VRAM-Annahmen
- Langsame Rollouts, weil Model Load Time nicht engineered ist
- Inferenz-Latenz-Spikes, weil KV-Cache-Wachstum ignoriert wurde
- Unvorhersehbare Kosten und unklare Ownership über Umgebungen hinweg
- Fehlende Trennung zwischen Experimenten und Produktion
Erfordert operative Disziplin bei Scheduling, Quotas und Cleanup
Vorhersehbare Performance bei korrekter Auslegung von VRAM, I/O und Netzwerk
Unterdimensionierter Storage oder Netzwerk kann teure GPU-Kapazität verschwenden
Klare Kostentreiber: GPU, CPU, RAM, Storage und Bandbreite
Production Inference erfordert SLO-getriebenes Design, nicht nur „es läuft auf meinem Notebook“
Workload-Trennung ermöglicht unabhängiges Skalieren von Training und Inference
Wie verknüpfe ich AI mit Kosten?
AI-Kosten werden von wenigen Hebeln bestimmt. Machen Sie sie explizit.
1. GPU-Kostentreiber
- VRAM, den Ihr Modell und Ihr Trainingsansatz benötigen
- Inference-Headroom für KV-Cache und Concurrency
- Auslastung—Idle GPUs zerstören ROI
Regel: Wenn Sie GPUs nicht auslasten können, weil Storage zu langsam ist, zahlen Sie Premium-Geld fürs Warten.
2. Storage-Kostentreiber
- Dataset-Größe und wiederholte Reads während des Trainings
- Checkpoint-Frequenz und Checkpoint-Größe
- Artifact-Retention und Model-Versioning-Policies
3. Netzwerk-Kostentreiber
- Distributed-Training-Collectives über Nodes
- Cross-Node-Traffic von Storage zu GPU-Workern
- Serving-Traffic zwischen Replicas und Gateways
4. People-Kostentreiber
- Wie oft Trainingsläufe fehlschlagen
- Wie schwer Ergebnisse reproduzierbar sind
- Wie lange Rollouts dauern
Wie kann ich AI auf Worldstream bauen?
Worldstream ist ein Infrastruktur-Provider. Der Wert liegt in einer stabilen Basis und Kontrolle, ohne vage Verträge oder Lock-in-Positionierung.
Worldstream liefert die Infrastruktur-Basis. Sie betreiben darauf die ML-Stack Ihrer Wahl.
Option A: Bare-Metal GPU-Cluster
Verwenden, wenn: Sie maximale Kontrolle über Hardware-Verhalten und Performance-Profile wollen. Sie vorhersehbaren Training-Throughput und stabile Inferenz-Latenz benötigen.
- Training GPU Worker Pool
- Inference GPU Pool
- Separate Nodes, auf denen Sie Orchestration, eine Model Registry und Pipelines betreiben
Option B: Getrennte Pools für Training und Inferenz
Verwenden, wenn: Trainingsspitzen nicht die Production-SLOs gefährden dürfen.
- Training Pool auf Throughput dimensioniert
- Inference Pool auf Concurrency und Latenz dimensioniert
- Gemeinsamer Storage für Artifacts und gemeinsame Observability für Ihre Plattform
Option C: Hybride Storage-Strategie für AI
Verwenden, wenn: Training und Checkpointing hohen Throughput benötigen. Serving schnelle Model Load Time und vorhersehbare Reads braucht.
- High-Throughput-Storage-Pfad für Trainingsdaten und Checkpoints
- Artifact Storage für Modelle, Versionen und Rollback
Was Sie operativ erwarten können: Worldstream betreibt eigene Rechenzentren und ein eigenes Netzwerk und arbeitet mit Inhouse-Engineers. Zudem ist die Positionierung klar auf vorhersehbare Ausgaben und klare Vereinbarungen ausgerichtet.
Performance-Ziele und Ergebnisrichtlinien
Ziele hängen vom Workload ab. Diese Metriken halten Sie ehrlich.
Training und Fine-Tuning
Verfolgen:
- GPU Utilization und Zeit, die auf Input gewartet wird
- Data Loader Throughput
- Checkpoint Time und Checkpoint-Frequenz
- Job Failure Rate und Restart Time
Red Flags: GPUs fallen während Data Loading auf niedrige Auslastung. Checkpointing-Pausen dominieren die Trainingszeit. Häufige OOM—das bedeutet meist falsche Memory-Annahmen.
Inference und Serving
Verfolgen:
- p95 und p99 Latenz
- Time to First Token für LLMs
- Throughput bei Ziel-Latenz
- Memory-Headroom—insbesondere KV-Cache-Wachstum
Red Flags: Latenz steigt nichtlinear mit Concurrency. Häufige OOM nach Traffic-Spikes. Instabilität bei größerer Context Length.
Data und MLOps
Verfolgen:
- Dataset Staging Time
- Varianz der Pipeline-Step-Dauer
- Artifact Publish Time
- Restore Time aus Checkpoints und Rollbacks
Betrieb, Performance und Risikomanagement
Capacity Management
- GPU-Kapazitätsplanung von Storage- und Netzwerkplanung trennen
- Quotas und Scheduling verwenden—„First come, first served” vermeiden
- Buffer für Incident Response und dringende Production Fixes einplanen
Data Lifecycle
- Dataset-Retention und Cleanup definieren
- Modelle und Datasets konsistent versionieren
- Rollbacks zur Routine machen, nicht zur Heldentat
Monitoring
Minimal-Set:
- GPU Utilization, VRAM Usage und Throttling-Signale
- Storage Throughput und Latenz
- Checkpoint Time und Failure Rate
- Network Throughput und Errors
- Serving Latency Percentiles
Security
- Verschlüsselung in Transit
- Dev und Prod trennen
- Access Control für Datasets, Modelle und Inference Endpoints
- Zugriffe auf Modelle und Datasets auditieren, für Compliance
Backup und Restore
- Definieren, was „Restore” bedeutet—Training Restart, Artifact Restore oder vollständige Environment Recovery
- Restore-Pfade testen. Regelmäßig

Frequently Asked Questions
Nein. Es ist eine Baseline für Transformer-Training in Mixed Precision mit AdamW, plus Activation Memory. Es ist explizit als typische Anforderung dokumentiert. Activations können dominieren, abhängig von Batch Size und Sequence Length.
Glossar
AI-Begriffe erklärt
Activation Memory
GPU-Speicher, der genutzt wird, um Intermediate Tensors während des Forward Pass für die Gradient Computation zu halten.
AdamW
Gängiger Optimizer, der mehr Speicher benötigt, weil er Optimizer State vorhält.
Checkpointing
Speichern des Model State während des Trainings, um nach Failures fortsetzen zu können. Storage-Throughput ist relevant.
Deep Learning
Neural-Network-basiertes ML, typischerweise GPU-beschleunigt.
Fine-tuning
Training eines bestehenden Modells auf Ihren Daten, um Verhalten anzupassen.
Inference
Nutzung eines trainierten Modells zur Erzeugung von Outputs in Produktion.
KV Cache
Key-Value-Cache zur Beschleunigung autoregressiven Decodings. Speicherbedarf wächst mit Batch Size und Context Length.
Mixed Precision
Training oder Inferenz mit einer Mischung aus niedriger und höherer Präzision, um Throughput zu erhöhen und Memory Pressure zu reduzieren.
MLOps
Praktiken und Tooling, um Training und Deployment wiederholbar und sicher zu machen.
VRAM
GPU-Speicher. Oft die erste harte Grenze bei modernen AI-Workloads.
Activation Memory
GPU-Speicher, der genutzt wird, um Intermediate Tensors während des Forward Pass für die Gradient Computation zu halten.
Checkpointing
Speichern des Model State während des Trainings, um nach Failures fortsetzen zu können. Storage-Throughput ist relevant.
Fine-tuning
Training eines bestehenden Modells auf Ihren Daten, um Verhalten anzupassen.
KV Cache
Key-Value-Cache zur Beschleunigung autoregressiven Decodings. Speicherbedarf wächst mit Batch Size und Context Length.
MLOps
Praktiken und Tooling, um Training und Deployment wiederholbar und sicher zu machen.
AdamW
Gängiger Optimizer, der mehr Speicher benötigt, weil er Optimizer State vorhält.
Deep Learning
Neural-Network-basiertes ML, typischerweise GPU-beschleunigt.
Inference
Nutzung eines trainierten Modells zur Erzeugung von Outputs in Produktion.
Mixed Precision
Training oder Inferenz mit einer Mischung aus niedriger und höherer Präzision, um Throughput zu erhöhen und Memory Pressure zu reduzieren.
VRAM
GPU-Speicher. Oft die erste harte Grenze bei modernen AI-Workloads.
Nächste Schritte mit Worldstream
- Definieren Sie Ihr dominantes Muster: klassisches ML auf CPU, Training und Fine-Tuning, Inferenz und Serving oder Hybrid
- Wählen Sie ein Referenz-Node-Profil und führen Sie einen Proof Workload aus
- Messen Sie VRAM Usage gegen die parameterbasierte Baseline
- Messen Sie Checkpoint Time und Dataset Read Throughput
- Messen Sie Inferenz-Latenz unter Concurrency, inklusive KV-Cache-Headroom
- Dann Profil festlegen. Konsistenz schlägt Cleverness