Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Skalierbare KI/ML-Infrastrukturen¶

Hinweis zur Software-Auswahl:
Diese Dokumentation priorisiert Open-Source-Software, die auf Ubuntu-Servern betrieben werden kann.
Bei kommerziellen Cloud-Lösungen wird stets eine Open-Source-Alternative für das eigene Rechenzentrum (On-Premise) gegenübergestellt.
LLM-Modelle und Inference-Server werden unabhängig vom Preis gelistet, da sie die funktionale Kernkomponente darstellen.

Legende¶

Lernpfad-Übersicht¶

graph LR
    A["🟢 Phase 1\nSingle-Node & CUDA"] --> B["🟡 Phase 2\nContainer & MLOps"]
    B --> C["🔴 Phase 3\nCluster-Skalierung"]
    A --> A1["Hardware & CUDA\nvLLM & Ollama\nGPU-Monitoring"]
    B --> B1["Docker / Podman\nKubernetes / K3s\nMLflow Pipelines"]
    C --> C1["Multi-Node Cluster\nGPU Partitioning (MIG)\nDistributed Training"]

Inhaltsverzeichnis¶

• 🟢 Phase 1 – Hardware, CUDA & Single-Node Serving
  • 1.1 Konzept: Hardware-Anforderungen für KI/ML
  • 1.2 Thema: NVIDIA CUDA & Driver unter Ubuntu einrichten
  • 1.3 Thema: Single-Node Inference-Server (vLLM & Ollama)
  • 1.4 Thema: GPU-Monitoring (Prometheus & Grafana)
• 🟡 Phase 2 – Containerisierung, Orchestrierung & MLOps
  • 2.1 Konzept: Container-Vorteile im ML-Bereich
  • 2.2 Thema: Docker & Podman für GPU-Workloads
  • 2.3 Thema: Kubernetes (K8s) & K3s für ML-Orchestrierung
  • 2.4 Thema: MLOps-Pipelines & Versionierung (MLflow)
• 🔴 Phase 3 – Cluster-Skalierung, Virtualisierung & High-Availability
  • 3.1 Konzept: Skalierungstechnologien (Horizontal vs. Vertikal)
  • 3.2 Thema: GPU-Virtualisierung & Partitionierung (MIG)
  • 3.3 Thema: High-Performance Storage für Trainingsdaten
  • 3.4 Thema: Multi-Node Clustering & Distributed Training
• 📋 Praxisprojekte
• 📦 Vollständige Softwareübersicht & Vergleich

🟢 Phase 1 – Hardware, CUDA & Single-Node Serving¶

Was lerne ich hier?
Die richtige Hardware-Evaluierung, das Installieren der GPU-Treiber unter Ubuntu und das Hosten deines ersten Inference-Servers inklusive Überwachung.
Voraussetzungen: Grundkenntnisse in Linux-Systemadministration.

1.1 Konzept: Hardware-Anforderungen für KI/ML¶

Konzept: CPU vs. GPU vs. TPU¶

Konzept: Der VRAM-Flaschenhals¶

Das wichtigste Kriterium einer GPU für LLMs ist der VRAM (Video-RAM). Ein Modell muss vollständig in den VRAM passen, um schnell ausgeführt zu werden.

Modellgröße berechnen (Faustregel):
Parameterzahl (z.B. 8B) * Byte pro Parameter (FP16 = 2 Byte, INT8 = 1 Byte, INT4 = 0.5 Byte)
Beispiel Llama 3 8B in FP16: 8.000.000.000 * 2 Byte = 16 GB VRAM benötigt.

1.2 Thema: NVIDIA CUDA & Driver unter Ubuntu einrichten¶

Konzept: Der GPU-Treiber-Stack¶

Damit Applikationen die GPU nutzen können, muss der Stack korrekt installiert sein:

graph TD
    A["🐍 KI-Anwendung (PyTorch / vLLM)"] --> B["⚙️ CUDA Toolkit (Bibliotheken)"]
    B --> C["📦 NVIDIA Container Toolkit (für Docker)"]
    C --> D["🐧 Kernel-Treiber (Ubuntu NVIDIA Driver)"]
    D --> E["🔌 Physische GPU"]

CLI-Befehle zur Einrichtung unter Ubuntu 24.04 LTS:¶

# NVIDIA-Treiber installieren
sudo apt update
sudo apt install nvidia-driver-550 nvidia-utils-550

# System neustarten und Installation prüfen
sudo reboot
nvidia-smi  # Zeigt GPU-Temperatur, VRAM und Prozesse

1.3 Thema: Single-Node Inference-Server (vLLM & Ollama)¶

Konzept: Batching und Durchsatz-Optimierung¶

Ein Standard-LLM-Inference-Server reagiert träge, wenn viele Anfragen parallel eingehen. Leistungsstarke Server wie vLLM nutzen PagedAttention, um VRAM-Fragmentierung zu verhindern und Anfragen dynamisch zu bündeln (Continuous Batching).

Software – Open Source / LLM:¶

Vergleich: Open Source vs. Kommerziell¶

1.4 Thema: GPU-Monitoring (Prometheus & Grafana)¶

Konzept: DCGM (Data Center GPU Manager)¶

NVIDIA-GPUs im Rechenzentrum liefern detaillierte Metriken über Auslastung, Temperatur, Stromverbrauch und Speicherfehler. Der DCGM Exporter übersetzt diese in das Prometheus-Format.

Software – alle Open Source:¶

🟡 Phase 2 – Containerisierung, Orchestrierung & MLOps¶

Was lerne ich hier?
Wie du ML-Umgebungen in Docker-Containern isolierst, Workloads über Kubernetes steuerst und den Lebenszyklus von Modellen mit MLOps-Tools verwaltest.
Voraussetzungen: Phase 1 abgeschlossen.

2.1 Konzept: Container-Vorteile im ML-Bereich¶

Das Dependency-Chaos verhindern¶

ML-Code hat komplexe Abhängigkeiten (bestimmte Python-Versionen, spezifische PyTorch-Versionen, die genau zu einer CUDA-Version passen müssen). Container kapseln diese Umgebung ein für alle Mal ein:

[PyTorch 2.3] -> [CUDA 12.1] -> [NVIDIA Driver 535] (Im Docker-Image fest verbaut)

2.2 Thema: Docker & Podman für GPU-Workloads¶

Konzept: NVIDIA Container Toolkit¶

Docker-Container können standardmäßig nicht auf die Grafikkarte zugreifen. Das NVIDIA Container Toolkit schleift die GPU sicher in den Container durch.

# Docker mit GPU-Zugriff starten
docker run --gpus all -it nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

Software – alle Open Source:¶

2.3 Thema: Kubernetes (K8s) & K3s für ML-Orchestrierung¶

Konzept: GPU-Scheduling¶

Kubernetes verwaltet ein Cluster aus Servern. Durch den NVIDIA GPU Operator kann Kubernetes erkennen, welche Nodes freie GPUs haben, und Container gezielt dort deployen:

# Pod-Ressourcenanforderung in Kubernetes
resources:
  limits:
    nvidia.com/gpu: 1  # Kubernetes reserviert genau 1 GPU für diesen Container

Software – alle Open Source:¶

2.4 Thema: MLOps-Pipelines & Versionierung (MLflow)¶

Konzept: Das Modell-Register¶

Modelle verhalten sich anders als herkömmlicher Code. Sie bestehen aus Code + Hyperparametern + Trainingsdaten. MLflow trackt all diese Faktoren und registriert die daraus resultierenden Modellgewichte.

Software – alle Open Source:¶

Vergleich: Open Source vs. Kommerziell¶

🔴 Phase 3 – Cluster-Skalierung, Virtualisierung & High-Availability¶

Was lerne ich hier?
Wie du GPUs virtualisierst, extrem schnelle Speichersysteme für Terabytes an Trainingsdaten anbindest und Modelle über mehrere Server parallel trainierst.
Voraussetzungen: Phase 1 & 2 abgeschlossen.

3.1 Konzept: Skalierungstechnologien (Horizontal vs. Vertikal)¶

3.2 Thema: GPU-Virtualisierung & Partitionierung (MIG)¶

Konzept: Multi-Instance GPU (MIG)¶

Größere GPUs (wie NVIDIA H100 oder A100) sind für kleinere Aufgaben (z. B. Entwicklung oder Übersetzung) unterfordert. Durch MIG kann eine physische GPU in bis zu 7 unabhängige Hardware-Instanzen partitioniert werden.

Physische GPU (z.B. A100 80GB) 
   --> Instance 1 (10GB VRAM) -> User A (Dev-Notebook)
   --> Instance 2 (10GB VRAM) -> User B (Test-Bot)
   --> Instance 3 (20GB VRAM) -> Pipeline (Inferenz)
   --> Instance 4 (40GB VRAM) -> Pipeline (Training)

Software – alle Open Source:¶

3.3 Thema: High-Performance Storage für Trainingsdaten¶

Konzept: Warum Standard-HDDs scheitern¶

Beim Deep Learning müssen Millionen kleinster Dateien (z. B. Bilder oder Audio-Snippets) parallel in den GPU-Speicher geschaufelt werden. Standard-Netzwerkfreigaben (NFS) erzeugen hier einen Flaschenhals. Benötigt werden Objektspeicher mit NVMe-Backends.

Software – alle Open Source:¶

Vergleich: Open Source vs. Kommerziell¶

3.4 Thema: Multi-Node Clustering & Distributed Training¶

Konzept: Distributed Data Parallel (DDP)¶

Wenn ein Modell zu groß für einen Server ist oder das Training zu lange dauert, wird der Trainingsprozess aufgeteilt:

• Data Parallelism (DDP): Jede GPU erhält das gesamte Modell, aber unterschiedliche Daten-Batches. Synchronisation erfolgt nach jedem Schritt.
• Model Parallelism: Das Modell wird in Schichten aufgeteilt. Node A berechnet Schichten 1–10, Node B berechnet 11–20.

Software – alle Open Source:¶

📋 Praxisprojekte¶

🟢 Einsteiger: Lokaler vLLM Inference-Server unter Ubuntu¶

Wir installieren vLLM und starten ein 8B-Modell als API-Schnittstelle.

# Virtuelle Umgebung vorbereiten
python3 -m venv .venv
source .venv/bin/activate
pip install vllm

# vLLM Server starten
python3 -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Meta-Llama-3-8B-Instruct \
    --port 8000

Software (alle Open Source): Ubuntu · Python · vLLM · PyTorch

🟡 Fortgeschritten: GPU-Überwachungs-Dashboard aufbauen¶

Wir erfassen die GPU-Temperatur und VRAM-Auslastung und visualisieren sie.

graph LR
    A["🔌 GPU"] --> B["📦 DCGM Exporter"]
    B -->|Port 9400| C["⚡ Prometheus DB"]
    C -->|Port 9090| D["💻 Grafana Web-UI"]

Software (alle Open Source): Docker · NVIDIA DCGM Exporter · Prometheus · Grafana

🔴 Experte: K3s Edge-Cluster mit GPU-Support¶

Wir setzen ein K3s-Kubernetes-Cluster auf Ubuntu auf, installieren den GPU-Operator und deployen einen vLLM-Service, der automatisch auf Nodes mit freiem GPU-Speicher gescheduled wird.

graph TD
    A["git push config"] --> B["☸️ K3s Control Plane"]
    B -->|GPU Operator| C["🖥️ Worker Node 1 (RTX 4090)\nvLLM Pod läuft"]
    B -->|Keine GPU| D["🖥️ Worker Node 2 (No GPU)\nWird übersprungen"]

Software (alle Open Source): K3s · NVIDIA GPU Operator · vLLM · Docker/Containerd

📦 Vollständige Softwareübersicht & Vergleich¶

Inference & Model-Serving¶

Container & Orchestrierung¶

MLOps & Pipelines¶

High-Performance Storage¶

Compute & Distributed Training¶

Monitoring¶

Weiterführende Ressourcen¶

• NVIDIA DCGM Docs – Offizielle Treiber- und Metrik-Doku
• vLLM Documentation – PagedAttention konfigurieren 🟩
• Kubeflow Project – Orchestrierungs-Handbuch 🟩
• K3s Light Kubernetes – Cluster-Dokumentation 🟩
• Ceph Distributed Storage – Speicherarchitekturen 🟩

Letzte Aktualisierung: Juli 2026

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).