FinOps für KI-Workloads: GPU-Kosten in AWS, Azure und GCP um bis zu 60 % senken

Einleitung: Die GPU-Kostenexplosion, die kein Budget überlebt

Hand aufs Herz: Wenn Sie in den letzten Monaten Ihre Cloud-Rechnung geöffnet haben und Ihnen die GPU-Kosten ins Auge gesprungen sind — Sie sind nicht allein. Künstliche Intelligenz hat 2026 die Cloud-Landschaft fundamental verändert, und mit ihr die Kostenstruktur ganzer Unternehmen. Laut Forrester werden die weltweiten Public-Cloud-Ausgaben in diesem Jahr voraussichtlich 1,03 Billionen US-Dollar erreichen. Ein wachsender Anteil davon entfällt auf GPU-basierte KI-Workloads.

Die Zahlen sind ziemlich ernüchternd: Bei KI-fokussierten Unternehmen machen GPU-intensive Workloads inzwischen 18 % der gesamten Cloud-Ausgaben aus — gegenüber lediglich 4 % im Jahr 2023. GPU-Instanzen kosten das 5- bis 10-Fache herkömmlicher Compute-Instanzen, und eine einzige H100-Instanz bei AWS kann über 32 US-Dollar pro Stunde verschlingen.

Das Paradoxe daran: 98 % aller FinOps-Teams verwalten inzwischen KI-Kosten (gegenüber 63 % noch ein Jahr zuvor), und 63 % der Organisationen tracken aktiv ihre KI/ML-Ausgaben. Trotzdem befinden sich nur 14,2 % der Unternehmen auf der höchsten FinOps-Reifestufe „Run". Die Mehrheit kämpft also noch mit grundlegenden Optimierungsproblemen, während die Kosten exponentiell steigen. Unternehmen ohne strukturierte FinOps-Praktiken verschwenden schätzungsweise 32–40 % ihres Cloud-Budgets.

In diesem Artikel zeige ich Ihnen sieben bewährte Strategien, mit denen Sie Ihre GPU-Cloud-Kosten in AWS, Azure und GCP um 40–60 % senken können. Jede Strategie kommt mit konkreten Code-Beispielen, Preisvergleichen und realen Konfigurationen — damit Sie nicht nur verstehen, was zu tun ist, sondern wie Sie es sofort umsetzen können.

Warum GPU-Cloud-Kosten 2026 explodieren

Die aktuelle Kostenexplosion bei GPU-Workloads hat mehrere Ursachen, die sich gegenseitig verstärken. Erstens hat die breite Einführung von Large Language Models, Diffusionsmodellen und multimodalen KI-Systemen die Nachfrage nach High-End-GPUs wie der NVIDIA H100 und der neuen Blackwell B200 massiv erhöht. Zweitens hat sich die Trainingszeit für moderne Foundation Models von Tagen auf Wochen und Monate ausgedehnt — bei entsprechend multiplizierten Kosten. Und drittens erfordern viele produktive Inference-Workloads 24/7-Verfügbarkeit, was die Kosten von einmaligen Trainingsläufen zu permanenten Betriebskosten verschiebt.

Ein Blick auf die realen Preise macht das Problem greifbar:

GPU-Typ	Typischer Stundenpreis (On-Demand)	Einsatzgebiet
NVIDIA T4	0,40–0,60 USD/h	Leichte Inference, Entwicklung
NVIDIA V100	0,40–0,60 USD/h	Training kleinerer Modelle
NVIDIA A100	1,20–2,50 USD/h	Training und Inference mittlerer Modelle
NVIDIA H100	2,50–6,00+ USD/h	LLM-Training, große Modelle
AWS p5.48xlarge (8× H100)	~32,77 USD/h	Distributed Training

Das Kernproblem: Traditionelle FinOps-Methoden — entwickelt für CPU-basierte Workloads mit relativ linearer Skalierung — greifen bei GPU-Kosten oft zu kurz. GPU-Workloads haben völlig andere Nutzungsmuster: lange Trainingsjobs mit voller Auslastung, gefolgt von Leerlaufphasen; Inference-Endpunkte mit stark schwankender Last; und Entwicklungsumgebungen, in denen teure GPUs oft stundenlang idle laufen. Ohne GPU-spezifische FinOps-Strategien wird ein erheblicher Teil des Budgets schlicht verschwendet.

Die neue Realität: GPU-FinOps als eigene Disziplin

GPU-Kosten lassen sich nicht einfach durch die gleichen Hebel optimieren wie herkömmliche Compute-Kosten. Sie erfordern ein tiefes Verständnis von Hardware-Architektur (MIG, NVLink, GPU-Memory), Modelloptimierung (Quantisierung, Distillation) und Orchestrierung (GPU-Sharing, Time-Slicing). Die folgenden sieben Strategien adressieren genau diese Dimensionen — und ja, Sie können die meisten davon schon diese Woche umsetzen.

Strategie 1 — Spot-Instanzen mit intelligentem Checkpointing

Spot-Instanzen (bei AWS „Spot Instances", bei Azure „Spot VMs", bei GCP „Preemptible/Spot VMs") sind ehrlich gesagt die vielleicht wirkungsvollste Einzelmaßnahme zur GPU-Kostensenkung überhaupt. Sie bieten Einsparungen von 60–90 % gegenüber On-Demand-Preisen, indem sie überschüssige Kapazität der Cloud-Provider nutzen.

Der Haken? Spot-Instanzen können mit einer kurzen Vorwarnzeit (typisch 2 Minuten bei AWS, 30 Sekunden bei GCP) entzogen werden.

Für GPU-Workloads bedeutet das: Ohne robustes Checkpointing riskieren Sie den Verlust von stunden- oder tagelanger Trainingsarbeit. Die Lösung ist ein automatisches Checkpointing-System, das den Modellzustand regelmäßig sichert und nach einem Spot-Entzug nahtlos fortsetzen kann. Klingt aufwändig, ist es aber nicht — schauen wir uns das an.

Kubernetes Pod-Spezifikation für Spot-GPU-Nodes

Das folgende Beispiel zeigt eine Kubernetes-Pod-Spezifikation, die GPU-Workloads gezielt auf Spot-Nodes mit Toleranz für Spot-Unterbrechungen platziert:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-training-spot
  labels:
    workload-type: training
    cost-tier: spot
spec:
  # Tolerierung fuer Spot-Taints
  tolerations:
  - key: "kubernetes.azure.com/scalesetpriority"
    operator: "Equal"
    value: "spot"
    effect: "NoSchedule"
  - key: "cloud.google.com/gke-spot"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: "node.kubernetes.io/instance-type"
            operator: In
            values:
            - "p3.2xlarge"    # V100 Spot
            - "g5.xlarge"     # A10G Spot
          - key: "karpenter.sh/capacity-type"
            operator: In
            values:
            - "spot"
  containers:
  - name: training
    image: my-registry/gpu-training:latest
    resources:
      limits:
        nvidia.com/gpu: 1
      requests:
        nvidia.com/gpu: 1
        memory: "32Gi"
        cpu: "8"
    env:
    - name: CHECKPOINT_DIR
      value: "/mnt/checkpoints"
    - name: CHECKPOINT_INTERVAL
      value: "300"  # Alle 5 Minuten
    volumeMounts:
    - name: checkpoint-storage
      mountPath: /mnt/checkpoints
  volumes:
  - name: checkpoint-storage
    persistentVolumeClaim:
      claimName: checkpoint-pvc
  terminationGracePeriodSeconds: 120

Python-Checkpointing-Skript für unterbrechungsfreies Training

Das zugehörige Python-Skript implementiert automatisches Checkpointing und erkennt Spot-Unterbrechungssignale. In der Praxis hat sich dieses Muster bei uns als äußerst zuverlässig erwiesen:

import torch
import signal
import os
import sys
import boto3
import requests
from datetime import datetime

class SpotCheckpointManager:
    """Verwaltet automatisches Checkpointing fuer Spot-GPU-Instanzen."""

    def __init__(self, model, optimizer, checkpoint_dir, s3_bucket=None):
        self.model = model
        self.optimizer = optimizer
        self.checkpoint_dir = checkpoint_dir
        self.s3_bucket = s3_bucket
        self.epoch = 0
        self.global_step = 0
        self.interrupted = False

        # Signal-Handler fuer SIGTERM (Spot-Terminierung)
        signal.signal(signal.SIGTERM, self._handle_termination)

        # Letzten Checkpoint laden, falls vorhanden
        self._load_latest_checkpoint()

    def _handle_termination(self, signum, frame):
        print(f"[{datetime.now()}] SPOT-TERMINIERUNG erkannt! "
              f"Sichere Checkpoint bei Epoch {self.epoch}, "
              f"Step {self.global_step}...")
        self.save_checkpoint(emergency=True)
        self.interrupted = True

    def save_checkpoint(self, emergency=False):
        checkpoint = {
            "model_state_dict": self.model.state_dict(),
            "optimizer_state_dict": self.optimizer.state_dict(),
            "epoch": self.epoch,
            "global_step": self.global_step,
            "timestamp": datetime.now().isoformat(),
            "emergency": emergency
        }

        filename = f"checkpoint_epoch{self.epoch}_step{self.global_step}.pt"
        filepath = os.path.join(self.checkpoint_dir, filename)
        torch.save(checkpoint, filepath)
        print(f"Checkpoint gespeichert: {filepath}")

        # Optional: Backup auf S3
        if self.s3_bucket:
            s3 = boto3.client("s3")
            s3.upload_file(
                filepath, self.s3_bucket,
                f"checkpoints/{filename}"
            )

    def _load_latest_checkpoint(self):
        if not os.path.exists(self.checkpoint_dir):
            os.makedirs(self.checkpoint_dir, exist_ok=True)
            return

        checkpoints = sorted([
            f for f in os.listdir(self.checkpoint_dir)
            if f.endswith(".pt")
        ])

        if checkpoints:
            latest = os.path.join(self.checkpoint_dir, checkpoints[-1])
            checkpoint = torch.load(latest)
            self.model.load_state_dict(checkpoint["model_state_dict"])
            self.optimizer.load_state_dict(
                checkpoint["optimizer_state_dict"]
            )
            self.epoch = checkpoint["epoch"]
            self.global_step = checkpoint["global_step"]
            print(f"Checkpoint wiederhergestellt: Epoch {self.epoch}, "
                  f"Step {self.global_step}")


# Verwendung im Training:
# manager = SpotCheckpointManager(model, optimizer, "/mnt/checkpoints")
# for epoch in range(manager.epoch, num_epochs):
#     for batch in dataloader:
#         if manager.interrupted:
#             sys.exit(0)
#         # ... Training ...
#         manager.global_step += 1
#         if manager.global_step % 500 == 0:
#             manager.save_checkpoint()

Wann Spot-Instanzen NICHT geeignet sind

Spot-Instanzen eignen sich hervorragend für fehlertolerante Workloads wie Modelltraining (mit Checkpointing), Batch-Inference, Hyperparameter-Suche und Datenvorverarbeitung. Sie sind hingegen nicht empfehlenswert für latenzempfindliche Inference-Endpunkte in Produktion, zeitkritische Trainingsläufe mit festen Deadlines oder Workloads ohne Checkpointing-Unterstützung.

Eine bewährte Strategie ist die Kombination: On-Demand- oder Reserved-Instanzen für die Basis-Kapazität und Spot-Instanzen für Peak-Workloads und experimentelle Trainingsläufe. Damit schlafen Sie nachts ruhiger.

Strategie 2 — Reserved Instances und Savings Plans gezielt einsetzen

Für vorhersehbare GPU-Workloads bieten Reserved Instances (RIs) und Savings Plans die zweitstärksten Einsparungen nach Spot-Instanzen. AWS bietet bis zu 72 % Rabatt bei dreijährigen Reservierungen. Und es kommt noch besser: Im Juni 2025 hat AWS die Preise für P5-Instanzen (H100) um bis zu 45 % und für P4d-Instanzen um 33 % gesenkt — ein klares Signal, dass der Wettbewerb um GPU-Workloads intensiver wird.

Vergleich der Commitment-Optionen

Anbieter	Instrument	Laufzeit	Typische Einsparung	Flexibilität
AWS	Reserved Instances	1–3 Jahre	40–72 %	Instanzfamilie gebunden
AWS	Compute Savings Plans	1–3 Jahre	35–66 %	Region- und Instanzfamilie flexibel
AWS	EC2 Instance Savings Plans	1–3 Jahre	40–72 %	Instanzfamilie gebunden, Größe flexibel
Azure	Reserved VM Instances	1–3 Jahre	40–72 %	VM-Serie gebunden
GCP	Committed Use Discounts (CUDs)	1–3 Jahre	40–57 %	Maschinentyp gebunden

Konkretes Beispiel: AWS p5.48xlarge

Mal ein konkretes Rechenbeispiel: Eine AWS p5.48xlarge-Instanz (8 x NVIDIA H100) kostet On-Demand ca. 32,77 USD/Stunde, also rund 287.000 USD pro Jahr bei Dauerbetrieb. Mit einem 3-Jahres-Commitment sinkt der effektive Preis auf ca. 1,13 Millionen USD für drei Jahre — eine Einsparung von etwa 56 % gegenüber On-Demand. Das sind über 300.000 USD, die man sich sparen kann. Pro Jahr.

AWS CLI: Savings Plan erwerben

Mit dem folgenden AWS-CLI-Befehl können Sie einen Compute Savings Plan erwerben:

# Savings Plan fuer GPU-Workloads erwerben
# Commitment: 10 USD/Stunde fuer 1 Jahr (No Upfront)
aws savingsplans create-savings-plan \
  --savings-plan-offering-id "offering-id-hier-einsetzen" \
  --commitment "10.0" \
  --savings-plan-type "ComputeSavingsPlans" \
  --term-duration-in-seconds 31536000 \
  --payment-option "NoUpfront" \
  --tags Key=Team,Value=ML-Platform Key=Environment,Value=Production

# Verfuegbare Offerings fuer GPU-Instanzen anzeigen
aws savingsplans describe-savings-plans-offerings \
  --product-type "EC2" \
  --plan-type "ComputeSavingsPlans" \
  --filters "name=instanceFamily,values=p5" \
  --filters "name=region,values=us-east-1"

# Bestehende Savings Plans und Auslastung pruefen
aws savingsplans describe-savings-plans \
  --query "SavingsPlans[*].{ID:SavingsPlanId,Type:SavingsPlanType,Commitment:Commitment,Utilization:Utilization}" \
  --output table

Die „Base + Burst"-Strategie

Der effektivste Ansatz für GPU-Kosten kombiniert verschiedene Preismodelle in Schichten — und meiner Erfahrung nach ist das der Punkt, an dem die wirklichen Einsparungen passieren:

1. Basis-Schicht (Reserved/Savings Plans): Reservieren Sie die GPU-Kapazität, die Sie zu mindestens 70–80 % der Zeit benötigen. Das betrifft typischerweise produktive Inference-Endpunkte und regelmäßige Retraining-Pipelines.
2. Burst-Schicht (Spot-Instanzen): Für variable Workloads wie Hyperparameter-Tuning, Ad-hoc-Trainingsläufe und Batch-Verarbeitung nutzen Sie Spot-Instanzen mit automatischem Checkpointing.
3. Notfall-Schicht (On-Demand): Ein kleines On-Demand-Kontingent für zeitkritische Workloads, wenn Spot-Kapazität nicht verfügbar ist.

Diese Schichtung erreicht typischerweise Gesamteinsparungen von 50–65 % gegenüber reinem On-Demand-Betrieb.

Strategie 3 — GPU-Rightsizing: Die richtige Instanz für jeden Workload

Einer der häufigsten und teuersten Fehler — und ich sehe das wirklich ständig — ist das reflexartige Greifen zur leistungsstärksten GPU-Instanz. Nicht jeder Workload benötigt eine H100 oder A100. Die Wahl der richtigen GPU-Instanz kann die Kosten um das 3- bis 8-Fache reduzieren, ohne die Performance wesentlich zu beeinträchtigen.

Entscheidungsmatrix: GPU-Instanz nach Workload-Typ

Workload-Typ	Empfohlene GPU	AWS-Instanz	Azure-Instanz	GCP-Instanz	Preis (ca.)
LLM-Training (>13B Param.)	H100 / B200	p5.48xlarge / P6-B200	ND H100 v5	a3-highgpu-8g	6–33 USD/h
LLM-Training (1–13B Param.)	A100	p4d.24xlarge	ND A100 v4	a2-highgpu-1g	1,20–2,50 USD/h
Fine-Tuning (LoRA/QLoRA)	A10G / L4	g5.xlarge	NV A10 v5	g2-standard-4	0,70–1,20 USD/h
Inference (hoher Durchsatz)	L4 / T4	g5.xlarge / g4dn.xlarge	NV T4 v3	g2-standard-4	0,40–1,00 USD/h
Inference (kostenoptimal)	Inferentia/TPU	inf2.xlarge	—	ct5lp (TPU v5)	0,20–0,80 USD/h
Entwicklung/Prototyping	T4	g4dn.xlarge	NV T4 v3	n1 + T4	0,40–0,60 USD/h

Spezialisierte KI-Beschleuniger berücksichtigen

Was viele Teams übersehen: Neben NVIDIA-GPUs bieten die Cloud-Provider eigene KI-Beschleuniger an, die für bestimmte Workloads deutlich kosteneffizienter sein können:

• AWS Inferentia2 (inf2): Bis zu 4x besseres Preis-Leistungs-Verhältnis für Inference-Workloads gegenüber vergleichbaren GPU-Instanzen. Unterstützt Modelle bis zu 175B Parameter mit NeuronLink-Interconnect.
• AWS Trainium (trn1): Entwickelt für kosteneffizientes Training. Bis zu 50 % günstiger als vergleichbare GPU-Instanzen für unterstützte Modellarchitekturen.
• GCP TPU v5p/v5e: Googles Tensor Processing Units, optimiert für JAX- und TensorFlow-Workloads. TPU v5e bietet ein hervorragendes Preis-Leistungs-Verhältnis für Inference.
• Azure ND MI300X v5: AMDs Instinct-basierte Instanzen als Alternative zu NVIDIA, oft mit besserer Verfügbarkeit.

Die neuen AWS P6-B200-Instanzen mit NVIDIA Blackwell B200-GPUs liefern die 2,5-fache Performance der H100 und können bei vergleichbaren Workloads die Kosten pro Trainingseinheit deutlich senken, da die Gesamtlaufzeit proportional sinkt. Das klingt erstmal teurer pro Stunde, rechnet sich aber unterm Strich fast immer.

GPU-Auslastung überprüfen

Bevor Sie GPU-Instanzen auswählen oder optimieren, sollten Sie unbedingt die aktuelle Auslastung messen. Der folgende Befehl nutzt den CloudWatch-Agenten und nvidia-smi:

# GPU-Auslastung auf einer laufenden EC2-Instanz pruefen
# (Erfordert nvidia-smi auf der Instanz)
aws ssm send-command \
  --instance-ids "i-0abcdef1234567890" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["nvidia-smi --query-gpu=gpu_name,utilization.gpu,utilization.memory,memory.total,memory.used,memory.free,temperature.gpu,power.draw --format=csv,noheader,nounits"]' \
  --output text \
  --query "Command.CommandId"

# CloudWatch-Metriken fuer GPU-Auslastung abrufen (letzte 3 Stunden)
aws cloudwatch get-metric-statistics \
  --namespace "GPU" \
  --metric-name "gpu_utilization" \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --start-time $(date -u -v-3H +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Average Maximum Minimum \
  --output table

# Faustregel: GPU-Auslastung unter 50% = Downsizing pruefen
# GPU-Speicher unter 40% genutzt = kleinere GPU moeglich

Als Faustregel gilt: Liegt die durchschnittliche GPU-Auslastung unter 50 % oder wird weniger als 40 % des GPU-Speichers genutzt, ist ein Downsizing auf eine günstigere Instanz wahrscheinlich möglich — ohne spürbare Performance-Einbußen. Sie wären überrascht, wie oft das der Fall ist.

Strategie 4 — Modelloptimierung: Quantisierung und Distillation

Die kosteneffektivste GPU-Stunde ist die, die gar nicht erst anfällt. So einfach ist das. Modelloptimierung reduziert den Ressourcenbedarf eines Modells direkt und senkt damit sowohl Training- als auch Inference-Kosten. Die zwei wichtigsten Techniken sind Quantisierung und Knowledge Distillation.

Quantisierung: Von FP32 zu INT4

Quantisierung reduziert die numerische Präzision der Modellgewichte und Aktivierungen. Hier ein Überblick, was das konkret bedeutet:

Präzision	Bits pro Gewicht	Speicherbedarf (7B-Modell)	Inference-Geschwindigkeit	Typischer Genauigkeitsverlust
FP32	32	~28 GB	1x (Baseline)	— (Referenz)
FP16 / BF16	16	~14 GB	~1,8x	< 0,1 %
INT8	8	~7 GB	~2,5x	0,5–1,5 %
INT4	4	~3,5 GB	~3,5x	1–3 %

Die Umstellung von FP16 auf INT8 kann die Inference-Kosten um ca. 50 % senken, da das Modell weniger GPU-Speicher benötigt und auf günstigeren Instanzen laufen kann. Ein 7B-Parameter-Modell, das in FP16 eine A100 benötigt, kann in INT4 problemlos auf einer T4 ausgeführt werden — zu einem Bruchteil der Kosten. Das ist ehrlich gesagt einer der größten Quick Wins, die es gibt.

PyTorch-Quantisierungsbeispiel

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
import time

# --- Methode 1: INT8-Quantisierung mit bitsandbytes ---
quantization_config_8bit = BitsAndBytesConfig(
    load_in_8bit=True,
    llm_int8_threshold=6.0,
    llm_int8_has_fp16_weight=False,
)

model_8bit = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.1-8B",
    quantization_config=quantization_config_8bit,
    device_map="auto",
    torch_dtype=torch.float16,
)

# --- Methode 2: INT4-Quantisierung (GPTQ / NF4) ---
quantization_config_4bit = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_quant_type="nf4",          # NormalFloat4
    bnb_4bit_use_double_quant=True,      # Doppelte Quantisierung
)

model_4bit = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.1-8B",
    quantization_config=quantization_config_4bit,
    device_map="auto",
)

# --- Speicherverbrauch vergleichen ---
def get_model_size_mb(model):
    param_size = sum(p.nelement() * p.element_size() for p in model.parameters())
    buffer_size = sum(b.nelement() * b.element_size() for b in model.buffers())
    return (param_size + buffer_size) / (1024 ** 2)

print(f"INT8-Modell: {get_model_size_mb(model_8bit):.0f} MB")
print(f"INT4-Modell: {get_model_size_mb(model_4bit):.0f} MB")

# --- Inference-Benchmark ---
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.1-8B")
input_text = "Erklaere die Vorteile von FinOps fuer KI-Workloads:"
inputs = tokenizer(input_text, return_tensors="pt").to("cuda")

start = time.time()
with torch.no_grad():
    outputs = model_4bit.generate(**inputs, max_new_tokens=200)
elapsed = time.time() - start

tokens_generated = outputs.shape[1] - inputs["input_ids"].shape[1]
print(f"INT4 Inference: {tokens_generated} Tokens in {elapsed:.2f}s "
      f"({tokens_generated/elapsed:.1f} Tokens/s)")

Knowledge Distillation

Knowledge Distillation geht einen Schritt weiter als Quantisierung: Ein großes „Lehrer-Modell" wird verwendet, um ein wesentlich kleineres „Schüler-Modell" zu trainieren. Das Schüler-Modell lernt dabei, die Ausgaben des Lehrers nachzuahmen, und erreicht oft 90–98 % der Qualität bei einem Bruchteil der Parameterzahl.

Ein auf diese Weise destilliertes Modell mit 1,5B Parametern kann ein 13B-Modell in spezifischen Domänen nahezu erreichen — bei 5–8x geringeren Inference-Kosten. Der Aufwand für die Distillation lohnt sich besonders dann, wenn ein Modell langfristig im Produktivbetrieb läuft.

Vorsicht bei Genauigkeitsverlust

Jede Optimierung bringt Kompromisse mit sich. Hier meine Empfehlungen für die Praxis:

• INT8-Quantisierung ist für die meisten Inference-Workloads bedenkenlos einsetzbar (< 1 % Genauigkeitsverlust).
• INT4-Quantisierung erfordert sorgfältiges Testen, insbesondere bei mathematischen Aufgaben und Reasoning.
• Immer auf einem Evaluierungsdatensatz testen, bevor quantisierte Modelle in Produktion gehen.
• GPTQ und AWQ liefern bei INT4 bessere Ergebnisse als naive Round-to-Nearest-Quantisierung.

Strategie 5 — Auto-Scaling und Idle-Kill-Policies

GPU-Leerlaufzeit ist der stille Budgetkiller. Klingt dramatisch? Ist es auch. Eine H100-Instanz, die über Nacht oder am Wochenende idle läuft, kostet bei AWS über 780 USD pro Tag — für null produktive Arbeit. Studien zeigen, dass durchschnittlich 30–50 % der GPU-Kosten auf Leerlaufzeiten entfallen.

Automatische Skalierung und Abschaltrichtlinien sind daher schlicht unverzichtbar.

Kubernetes HPA mit GPU-basierter Skalierung

Der Horizontal Pod Autoscaler (HPA) kann auf benutzerdefinierte GPU-Metriken reagieren, um Inference-Pods dynamisch hoch- und herunterzuskalieren:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: gpu-inference-hpa
  namespace: ml-inference
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: llm-inference-server
  minReplicas: 1
  maxReplicas: 12
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300   # 5 Min. warten vor Scale-Down
      policies:
      - type: Pods
        value: 2
        periodSeconds: 60               # Max. 2 Pods pro Minute entfernen
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60               # Max. 4 Pods pro Minute hinzufuegen
  metrics:
  # GPU-Auslastung als primaere Metrik
  - type: Pods
    pods:
      metric:
        name: DCGM_FI_DEV_GPU_UTIL      # NVIDIA DCGM Metrik
      target:
        type: AverageValue
        averageValue: "70"               # Ziel: 70% GPU-Auslastung
  # Request-Warteschlange als sekundaere Metrik
  - type: Pods
    pods:
      metric:
        name: inference_queue_length
      target:
        type: AverageValue
        averageValue: "10"               # Max. 10 Requests in der Queue
  # Anfragen pro Sekunde
  - type: Pods
    pods:
      metric:
        name: requests_per_second
      target:
        type: AverageValue
        averageValue: "50"

AWS Lambda + CloudWatch: Automatische GPU-Abschaltung

Das folgende Beispiel zeigt eine AWS-Lambda-Funktion, die GPU-Instanzen mit geringer Auslastung automatisch stoppt. In unserer Umgebung hat allein dieses Skript die Entwicklungskosten um fast 70 % gesenkt:

import boto3
import os
from datetime import datetime, timedelta

ec2 = boto3.client("ec2")
cloudwatch = boto3.client("cloudwatch")

# Konfiguration
GPU_IDLE_THRESHOLD = float(os.environ.get("GPU_IDLE_THRESHOLD", "15"))
IDLE_MINUTES = int(os.environ.get("IDLE_MINUTES", "30"))
PROTECTED_TAG = "auto-shutdown-exempt"


def lambda_handler(event, context):
    """
    Stoppt GPU-Instanzen, deren GPU-Auslastung unter dem Schwellenwert liegt.
    Wird alle 15 Minuten per CloudWatch Events Rule ausgeloest.
    """

    # Alle laufenden GPU-Instanzen finden
    response = ec2.describe_instances(
        Filters=[
            {"Name": "instance-state-name", "Values": ["running"]},
            {"Name": "instance-type", "Values": [
                "p3.*", "p4d.*", "p5.*",       # Training-Instanzen
                "g4dn.*", "g5.*", "g6.*",       # Inference-Instanzen
                "inf2.*", "trn1.*"              # Spezial-Beschleuniger
            ]}
        ]
    )

    stopped_instances = []
    checked_instances = 0

    for reservation in response["Reservations"]:
        for instance in reservation["Instances"]:
            instance_id = instance["InstanceId"]
            instance_type = instance["InstanceType"]

            # Geschuetzte Instanzen ueberspringen
            tags = {t["Key"]: t["Value"] for t in instance.get("Tags", [])}
            if tags.get(PROTECTED_TAG) == "true":
                continue

            checked_instances += 1

            # GPU-Auslastung der letzten N Minuten pruefen
            end_time = datetime.utcnow()
            start_time = end_time - timedelta(minutes=IDLE_MINUTES)

            metrics = cloudwatch.get_metric_statistics(
                Namespace="GPU",
                MetricName="gpu_utilization",
                Dimensions=[
                    {"Name": "InstanceId", "Value": instance_id}
                ],
                StartTime=start_time,
                EndTime=end_time,
                Period=300,
                Statistics=["Average"]
            )

            if metrics["Datapoints"]:
                avg_util = sum(
                    dp["Average"] for dp in metrics["Datapoints"]
                ) / len(metrics["Datapoints"])

                if avg_util < GPU_IDLE_THRESHOLD:
                    # Instanz stoppen
                    ec2.stop_instances(InstanceIds=[instance_id])

                    # Benachrichtigung per SNS
                    sns = boto3.client("sns")
                    sns.publish(
                        TopicArn=os.environ["SNS_TOPIC_ARN"],
                        Subject=f"GPU-Instanz gestoppt: {instance_id}",
                        Message=(
                            f"Instanz {instance_id} ({instance_type}) "
                            f"wurde automatisch gestoppt.\n"
                            f"Durchschnittliche GPU-Auslastung: "
                            f"{avg_util:.1f}% (Schwellenwert: "
                            f"{GPU_IDLE_THRESHOLD}%)\n"
                            f"Team: {tags.get('Team', 'unbekannt')}\n"
                            f"Projekt: {tags.get('Project', 'unbekannt')}"
                        )
                    )
                    stopped_instances.append(instance_id)

    return {
        "checked": checked_instances,
        "stopped": stopped_instances,
        "timestamp": datetime.utcnow().isoformat()
    }

Diese Kombination aus GPU-basiertem Auto-Scaling und automatischer Idle-Abschaltung kann die GPU-Kosten um 30–50 % senken — besonders in Entwicklungs- und Staging-Umgebungen, wo GPUs häufig außerhalb der Arbeitszeiten ungenutzt laufen.

Strategie 6 — GPU-Sharing in Kubernetes mit MIG und Time-Slicing

Nicht jeder GPU-Workload benötigt eine vollständige GPU. Das klingt offensichtlich, aber Sie wären überrascht, wie viele Teams trotzdem ganze GPUs für leichte Inference-Aufgaben, Entwicklungsnotebooks oder Modell-Serving mit geringem Durchsatz reservieren. NVIDIA bietet zwei Technologien, um eine physische GPU auf mehrere Workloads aufzuteilen: Multi-Instance GPU (MIG) und GPU Time-Slicing. Richtig eingesetzt, kann GPU-Sharing die Infrastrukturkosten um bis zu 90 % senken.

NVIDIA MIG (Multi-Instance GPU)

MIG ist auf den NVIDIA-GPUs A100, A30 und H100 verfügbar und partitioniert eine physische GPU in bis zu 7 isolierte Instanzen. Jede Partition hat eigenen GPU-Speicher und eigene Rechenressourcen — es gibt keine Interferenz zwischen den Partitionen. Eine A100 mit 80 GB GPU-RAM kann beispielsweise in 7 Partitionen mit jeweils ~10 GB aufgeteilt werden.

MIG eignet sich besonders gut für:

• Mehrere Inference-Endpunkte auf einer GPU
• Isolation zwischen verschiedenen Teams oder Projekten
• Garantierte GPU-Ressourcen ohne Über- oder Unterprovisionierung

GPU Time-Slicing

Time-Slicing teilt die GPU-Zeit zwischen mehreren Containern, ähnlich wie CPU-Time-Sharing. Im Gegensatz zu MIG bietet es keine Speicher-Isolation — alle Workloads teilen sich den GPU-Speicher. Dafür funktioniert es auf allen NVIDIA-GPU-Generationen (auch T4, V100) und erlaubt eine feinere Granularität. Für Dev-Umgebungen ist das meistens völlig ausreichend.

Kubernetes-Konfiguration für GPU Time-Slicing

Die folgende ConfigMap konfiguriert den NVIDIA GPU Operator in Kubernetes für Time-Slicing:

# ConfigMap fuer NVIDIA GPU Operator Time-Slicing
apiVersion: v1
kind: ConfigMap
metadata:
  name: gpu-sharing-config
  namespace: gpu-operator
data:
  t4-timeslice: |-
    version: v1
    sharing:
      timeSlicing:
        renameByDefault: false
        failRequestsGreaterThanOne: false
        resources:
        - name: nvidia.com/gpu
          replicas: 4           # 4 Workloads teilen sich eine T4
  a100-mig: |-
    version: v1
    sharing:
      mig:
        strategy: "mixed"       # Erlaubt verschiedene MIG-Profile
        resources:
        - name: nvidia.com/mig-1g.10gb
          replicas: 7           # 7 x 1g.10gb Slices
        - name: nvidia.com/mig-2g.20gb
          replicas: 3           # 3 x 2g.20gb Slices
        - name: nvidia.com/mig-3g.40gb
          replicas: 2           # 2 x 3g.40gb Slices
---
# ClusterPolicy: GPU-Sharing aktivieren
apiVersion: nvidia.com/v1
kind: ClusterPolicy
metadata:
  name: gpu-cluster-policy
spec:
  devicePlugin:
    config:
      name: gpu-sharing-config
      default: t4-timeslice
  migManager:
    enabled: true
    config:
      name: gpu-sharing-config
---
# Beispiel-Deployment: Inference-Pod mit Time-Slicing
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-lightweight
  namespace: ml-inference
spec:
  replicas: 4
  selector:
    matchLabels:
      app: inference-lightweight
  template:
    metadata:
      labels:
        app: inference-lightweight
    spec:
      containers:
      - name: model-server
        image: my-registry/inference-server:latest
        resources:
          limits:
            nvidia.com/gpu: 1    # Erhaelt 1/4 der GPU durch Time-Slicing
          requests:
            memory: "4Gi"
            cpu: "2"

Wann welchen Ansatz verwenden?

Kriterium	MIG	Time-Slicing
GPU-Unterstützung	A100, A30, H100	Alle NVIDIA-GPUs
Speicher-Isolation	Ja (vollständig)	Nein (geteilt)
Rechenleistung-Isolation	Ja	Nein (zeitlich geteilt)
Max. Partitionen	Bis zu 7	Konfigurierbar (typisch 2–8)
Idealer Einsatz	Produktion, Multi-Tenant	Entwicklung, leichte Inference
Overhead	Minimal	Kontextwechsel-Overhead

Strategie 7 — FinOps-Governance: Tagging, Budgets und Kostenmetriken

Technische Optimierungen allein reichen nicht aus — das muss man ganz klar sagen. Ohne Governance, also verbindliche Richtlinien, Sichtbarkeit und Verantwortlichkeiten, schleichen sich GPU-Kosten unbemerkt wieder nach oben. Eine FinOps-Governance-Strategie für KI-Workloads umfasst drei Säulen: konsequentes Tagging, Budget-Kontrollen und KI-spezifische Kostenmetriken.

Tagging-Strategie für KI-Ressourcen

Jede GPU-Ressource sollte mindestens die folgenden Tags tragen:

• Team / CostCenter: Welches Team ist verantwortlich?
• Project: Welches Projekt oder Modell nutzt die Ressource?
• Environment: Production, Staging, Development, Experiment
• WorkloadType: Training, Inference, Fine-Tuning, Development
• ModelName / ModelVersion: Welches Modell wird trainiert oder deployed?
• AutoShutdown: Darf die Instanz automatisch gestoppt werden?
• ExpirationDate: Wann soll die Ressource überprüft oder gelöscht werden?

Das Tagging mag wie bürokratischer Overhead wirken, aber glauben Sie mir: Sobald Sie die erste überraschende 5-stellige Rechnung ohne klare Zuordnung erhalten, werden Sie froh sein, es eingeführt zu haben.

Terraform: Tagging-Pflicht erzwingen

Das folgende Terraform-Modul erzwingt die Einhaltung der Tagging-Richtlinien für alle GPU-Instanzen:

# modules/gpu-instance/main.tf
# Erzwingt vollstaendiges Tagging fuer GPU-Ressourcen

variable "required_tags" {
  description = "Pflicht-Tags fuer alle GPU-Ressourcen"
  type = object({
    Team         = string
    Project      = string
    Environment  = string
    WorkloadType = string
    ModelName    = string
    CostCenter   = string
    AutoShutdown = string
  })

  validation {
    condition = contains(
      ["Training", "Inference", "FineTuning", "Development"],
      var.required_tags.WorkloadType
    )
    error_message = "WorkloadType muss Training, Inference, FineTuning oder Development sein."
  }

  validation {
    condition = contains(
      ["Production", "Staging", "Development", "Experiment"],
      var.required_tags.Environment
    )
    error_message = "Environment muss Production, Staging, Development oder Experiment sein."
  }
}

variable "instance_type" {
  description = "EC2-Instanztyp (GPU)"
  type        = string
}

# GPU-Instanz mit erzwungenen Tags
resource "aws_instance" "gpu_workload" {
  ami           = data.aws_ami.deep_learning.id
  instance_type = var.instance_type

  tags = merge(var.required_tags, {
    Name           = "${var.required_tags.Project}-${var.required_tags.WorkloadType}"
    ManagedBy      = "terraform"
    CreatedAt      = timestamp()
    FinOpsReviewed = "true"
  })

  # Automatische Abschaltung planen
  metadata_options {
    http_tokens = "required"
  }

  root_block_device {
    volume_size = 200
    volume_type = "gp3"
    tags        = var.required_tags
  }
}

# Budget-Alarm pro Projekt
resource "aws_budgets_budget" "gpu_project_budget" {
  name         = "gpu-${var.required_tags.Project}-monthly"
  budget_type  = "COST"
  limit_amount = var.monthly_budget_limit
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name   = "TagKeyValue"
    values = ["user:Project$${var.required_tags.Project}"]
  }

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 80
    threshold_type            = "PERCENTAGE"
    notification_type         = "FORECASTED"
    subscriber_email_addresses = var.alert_emails
  }

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 100
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_email_addresses = var.alert_emails
  }
}

# AWS Tag-Policy (Organisation-Level)
resource "aws_organizations_policy" "gpu_tagging" {
  name    = "gpu-resource-tagging"
  type    = "TAG_POLICY"
  content = jsonencode({
    tags = {
      WorkloadType = {
        tag_key = {
          "@@assign" = "WorkloadType"
        }
        tag_value = {
          "@@assign" = [
            "Training", "Inference", "FineTuning", "Development"
          ]
        }
        enforced_for = {
          "@@assign" = ["ec2:instance", "sagemaker:*"]
        }
      }
    }
  })
}

KI-spezifische Kostenmetriken

Traditionelle Cloud-Metriken wie „Kosten pro Instanz" oder „Kosten pro Stunde" sind für KI-Workloads schlicht unzureichend. Stattdessen sollten Sie diese Metriken tracken:

• Kosten pro Training (Cost per Training Run): Gesamtkosten für einen vollständigen Trainingslauf, einschließlich Compute, Storage und Data Transfer.
• Kosten pro Token (Cost per Token): Bei LLMs die Kosten pro generiertem Token — ermöglicht direkten Vergleich verschiedener Modelle und Infrastruktur-Konfigurationen.
• Kosten pro Inference-Request: Durchschnittliche Kosten pro Anfrage an einen Inference-Endpunkt.
• GPU-Auslastungseffizienz: Verhältnis von produktiver GPU-Nutzung zu bezahlter GPU-Zeit.
• Kosten pro Modell-Genauigkeitspunkt: Wie viel kostet eine Verbesserung der Modellqualität um einen Prozentpunkt? (Diese Metrik ist besonders aufschlussreich, wenn man entscheiden muss, ob sich weiteres Training noch lohnt.)

Die FOCUS-Spezifikation (FinOps Open Cost and Usage Specification) bietet seit 2025 erweiterte Unterstützung für GPU-Metriken und ermöglicht eine Provider-übergreifende Kostendarstellung. Teams, die FOCUS implementieren, können ihre GPU-Kosten über AWS, Azure und GCP hinweg standardisiert vergleichen und optimieren.

GPU-Kostenvergleich: AWS vs. Azure vs. GCP

Jetzt wird es spannend — der direkte Preisvergleich. Die Preise für GPU-Instanzen variieren erheblich zwischen den drei großen Cloud-Anbietern. Die folgende Tabelle zeigt einen direkten Vergleich der gängigsten GPU-Instanzen (Stand: März 2026, Region US East / West Europe, Preise in USD pro Stunde):

GPU	AWS (Instanz / Preis)	Azure (Instanz / Preis)	GCP (Instanz / Preis)
NVIDIA T4	g4dn.xlarge / ~0,526 USD/h	NC4as T4 v3 / ~0,526 USD/h	n1-standard-4 + T4 / ~0,45 USD/h
NVIDIA A10G	g5.xlarge / ~1,006 USD/h	NV A10 v5 / ~0,90 USD/h	g2-standard-4 / ~0,84 USD/h
NVIDIA L4	g6.xlarge / ~0,80 USD/h	— (begrenzt verfügbar)	g2-standard-4 (L4) / ~0,70 USD/h
NVIDIA A100 (40 GB)	p4d.24xlarge / ~32,77 USD/h (8 GPU)	ND A100 v4 / ~27,20 USD/h (8 GPU)	a2-highgpu-1g / ~2,87 USD/h (1 GPU)
NVIDIA H100	p5.48xlarge / ~32,77 USD/h (8 GPU)	ND H100 v5 / ~27,20 USD/h (8 GPU)	a3-highgpu-8g / ~31,22 USD/h (8 GPU)
Spot / Low-Priority	60–90 % günstiger	60–80 % günstiger	60–91 % günstiger
Eigene KI-Chips	Inferentia2 (inf2): ab ~0,76 USD/h	Maia 100 (Preview)	TPU v5e: ab ~1,20 USD/h

Wichtige Hinweise zum Preisvergleich:

• AWS und Azure bündeln Multi-GPU-Instanzen (8 GPUs in einer Instanz), während GCP einzelne GPUs an VMs anhängen kann — das macht direkte Vergleiche bei A100/H100 etwas knifflig.
• Spot-Preise schwanken stark nach Region und Tageszeit. Die angegebenen Rabatte sind Richtwerte.
• GCP bietet die flexibelste GPU-Konfiguration (Attach von 1, 2, 4 oder 8 GPUs an verschiedene Maschinentypen).
• Azure hat tendenziell die beste Verfügbarkeit für Enterprise-Kunden mit bestehenden EA-Verträgen.
• AWS bietet mit Inferentia2 und Trainium die ausgereiftesten eigenen KI-Beschleuniger für kostenoptimierte Inference.

Praxisbeispiel: Von 50.000 EUR auf unter 18.000 EUR monatliche GPU-Kosten

Genug Theorie — schauen wir uns an, wie die sieben Strategien in der Praxis zusammenwirken. Das folgende Szenario basiert auf einem realistischen Fall: Ein mittelständisches KI-Unternehmen betreibt auf AWS eine NLP-Plattform mit mehreren LLM-basierten Diensten.

Ausgangssituation (vor Optimierung)

Kostenstelle	Konfiguration	Monatliche Kosten
Training-Cluster	2x p4d.24xlarge On-Demand, ~60 h/Woche	17.100 EUR
Inference-Endpunkte	4x g5.2xlarge On-Demand, 24/7	11.700 EUR
Entwicklung / Notebooks	8x g4dn.xlarge On-Demand, 24/7 laufend	9.200 EUR
Fine-Tuning-Jobs	2x g5.4xlarge On-Demand, ~40 h/Woche	5.200 EUR
Hyperparameter-Suche	4x g5.xlarge On-Demand, ~30 h/Woche	6.800 EUR
Gesamt		50.000 EUR

50.000 Euro im Monat. Jeden Monat. Das tut weh.

Optimierungsmaßnahmen

1. Spot-Instanzen (Strategie 1): Training und Hyperparameter-Suche auf Spot umgestellt mit automatischem Checkpointing. Einsparung: ~65 % auf diese Workloads.
2. Reserved Instances (Strategie 2): 1-Jahres-Savings-Plan für die 4 Inference-Instanzen (24/7-Betrieb). Einsparung: ~40 %.
3. GPU-Rightsizing (Strategie 3): Inference von g5.2xlarge auf g5.xlarge downsized (die GPU-Auslastung lag bei nur 35 %). Fine-Tuning von g5.4xlarge auf g5.xlarge downsized (LoRA statt Full-Fine-Tuning). Einsparung: ~45 %.
4. Quantisierung (Strategie 4): Inference-Modelle von FP16 auf INT8 quantisiert, wodurch 2 der 4 Inference-Instanzen komplett eliminiert werden konnten. Einsparung: ~50 % auf Inference.
5. Idle-Kill-Policies (Strategie 5): Entwickler-Notebooks werden nach 30 Minuten Inaktivität automatisch gestoppt, tatsächliche Nutzung nur ~8 h/Tag. Einsparung: ~67 % auf Entwicklungskosten.
6. GPU-Sharing (Strategie 6): Time-Slicing auf den verbleibenden Entwicklungs-GPUs: 2 physische T4-GPUs bedienen 8 Entwickler-Notebooks. Einsparung: ~75 % auf Dev-GPU-Kosten.
7. Tagging und Governance (Strategie 7): Budget-Alerts und monatliche Reviews identifizieren kontinuierlich weitere Optimierungspotenziale.

Ergebnis nach Optimierung

Kostenstelle	Neue Konfiguration	Monatliche Kosten
Training-Cluster	2x p4d.24xlarge Spot + Checkpointing	5.985 EUR
Inference-Endpunkte	2x g5.xlarge RI + INT8-Quantisierung	2.920 EUR
Entwicklung / Notebooks	2x g4dn.xlarge mit Time-Slicing + Idle-Kill	760 EUR
Fine-Tuning-Jobs	2x g5.xlarge Spot + LoRA	1.950 EUR
Hyperparameter-Suche	4x g5.xlarge Spot	2.380 EUR
Governance-Tools	CloudWatch, Lambda, SNS	~50 EUR
Gesamt		14.045 EUR

Gesamteinsparung: ~72 % (von 50.000 EUR auf rund 14.000 EUR/Monat). Selbst konservativ geschätzt — unter Berücksichtigung von Spot-Unterbrechungen, die gelegentlich On-Demand-Fallbacks erfordern — liegt die realistische Einsparung bei 60–65 %, also einer Reduktion auf ca. 17.500–20.000 EUR monatlich.

Der Schlüssel zum Erfolg war die Kombination aller sieben Strategien. Keine einzelne Maßnahme hätte eine derart drastische Reduktion ermöglicht. Die größten Einzeleffekte hatten Spot-Instanzen (Strategie 1) und Modelloptimierung (Strategie 4).

Häufig gestellte Fragen (FAQ)

Was sind Spot-Instanzen und wie viel kann man bei GPU-Workloads sparen?

Spot-Instanzen sind Cloud-Compute-Kapazitäten, die Provider zu deutlich reduzierten Preisen anbieten, wenn die Nachfrage gering ist. Bei AWS heißen sie „Spot Instances", bei Azure „Spot VMs" und bei GCP „Spot VMs" (ehemals Preemptible VMs). Der entscheidende Unterschied zu On-Demand-Instanzen: Spot-Instanzen können vom Provider mit kurzer Vorwarnzeit (typischerweise 2 Minuten bei AWS, 30 Sekunden bei GCP) entzogen werden, wenn die Kapazität anderweitig benötigt wird. Die Einsparungen liegen bei 60–90 % gegenüber On-Demand-Preisen. Für GPU-Workloads ist jedoch zwingend ein robustes Checkpointing-System erforderlich, das den Trainingsfortschritt regelmäßig sichert und nach einer Unterbrechung automatisch fortsetzt.

Welche GPU-Instanz sollte ich für KI-Training vs. Inference wählen?

Die Wahl hängt stark vom Workload ab. Für das Training großer Modelle (über 13 Milliarden Parameter) sind NVIDIA H100 oder die neuen Blackwell B200 GPUs empfehlenswert (AWS p5.48xlarge, Azure ND H100 v5). Für mittlere Modelle (1–13B Parameter) reicht oft eine A100 (AWS p4d.24xlarge). Für Fine-Tuning mit LoRA/QLoRA genügt häufig eine A10G oder L4 (AWS g5.xlarge oder g6.xlarge). Für Inference sollten Sie die kosteneffizienteste Option wählen: NVIDIA T4 oder L4 für allgemeine Inference, oder spezialisierte Beschleuniger wie AWS Inferentia2 oder GCP TPU v5e. Und ganz wichtig: Messen Sie die tatsächliche GPU-Auslastung — liegt sie unter 50 %, ist ein Downsizing wahrscheinlich möglich.

Lohnt sich Model Quantization und wie stark sinkt die Genauigkeit?

Ja, Quantisierung lohnt sich in den meisten Fällen erheblich. Die Umstellung von FP16 auf INT8 reduziert den Speicherbedarf um ca. 50 % und die Inference-Kosten um einen ähnlichen Anteil, bei typischerweise weniger als 1,5 % Genauigkeitsverlust. INT4-Quantisierung (z. B. mit GPTQ oder AWQ) halbiert den Speicherbedarf nochmals und ermöglicht es, Modelle auf deutlich günstigeren GPUs auszuführen — allerdings mit einem Genauigkeitsverlust von 1–3 %, der besonders bei mathematischen Aufgaben spürbar sein kann. Die Faustregel: INT8 ist für die meisten produktiven Inference-Workloads bedenkenlos einsetzbar. Bei INT4 sollten Sie vor dem Produktionseinsatz immer auf Ihrem spezifischen Evaluierungsdatensatz testen.

Wie implementiert man GPU-Sharing in einem Kubernetes-Cluster?

GPU-Sharing in Kubernetes wird über den NVIDIA GPU Operator und den NVIDIA Device Plugin implementiert. Es gibt zwei Hauptansätze: MIG (Multi-Instance GPU) partitioniert eine A100 oder H100 in bis zu 7 physisch isolierte GPU-Instanzen mit eigenem Speicher und eigenen Rechenressourcen — ideal für Produktion. Time-Slicing teilt die GPU-Rechenzeit zwischen mehreren Pods, funktioniert auf allen NVIDIA-GPUs (auch T4, V100), bietet aber keine Speicher-Isolation. Die Konfiguration erfolgt über eine ConfigMap, die dem GPU Operator die Sharing-Parameter mitteilt. Pods fordern dann wie gewohnt nvidia.com/gpu: 1 an, erhalten aber nur den konfigurierten Anteil der physischen GPU. Für Entwicklungsumgebungen ist Time-Slicing mit 4–8 Replicas pro GPU der einfachste und kosteneffektivste Ansatz.

Was kostet eine GPU-Stunde bei AWS, Azure und GCP im Vergleich?

Die Kosten variieren stark je nach GPU-Typ und Preismodell. Für eine NVIDIA T4 zahlen Sie On-Demand ca. 0,45–0,53 USD/h bei allen drei Providern. Eine NVIDIA A10G / L4 kostet zwischen 0,70 und 1,01 USD/h. Für eine einzelne NVIDIA A100 liegen die Kosten bei 1,20–2,87 USD/h, wobei GCP mit einzeln angehängten GPUs die transparentere Preisstruktur bietet. H100-Instanzen kosten typischerweise 2,50–6,00+ USD/h pro GPU. Mit Spot-Instanzen lassen sich diese Preise um 60–90 % senken, und Reserved Instances (1–3 Jahre Laufzeit) bieten 40–72 % Rabatt. Die kostengünstigsten Optionen für Inference sind spezialisierte Chips wie AWS Inferentia2 (ab ca. 0,76 USD/h) und GCP TPU v5e (ab ca. 1,20 USD/h).