GPUs in Kubernetes: Praxisleitfaden für H100, MIG & Time‑Slicing

Wie du GPU‑Ressourcen sicher, effizient und cloud‑native für Entwicklung, Inferenz und Training bereitstellst – inklusive H100‑MIG und Time‑Slicing, YAML‑Beispielen und Betriebsrichtlinien.

TL;DR

• Ja, eine einzelne GPU kann von mehreren Pods genutzt werden – entweder hardware‑isoliert via MIG (Multi‑Instance GPU) oder kooperativ via Time‑Slicing.
• Entwickler fordern genau die GPU‑Größe an, die sie brauchen (z. B. nvidia.com/mig-3g.40gb: 1), erhalten planbare Performance und zahlen/verbrauch en nur, was sie nutzen.
• Cloud‑native Patterns (GitOps, CI/CD, IaC, Rolling/Blue‑Green, Canary, Autoscaling, Multi‑Tenancy) funktionieren auch für GPU‑Workloads – wenn die Infrastruktur sauber modelliert ist.

Dieser Beitrag zeigt End‑to‑End, wie man Bare‑Metal‑Kubernetes (z.B. mit NVIDIA H100) produktionsreif betreibt, wie man MIG und Time‑Slicing sinnvoll kombiniert und welche Betriebs‑ und Governance‑Aspekte (Quotas, Labeling, Monitoring, Kostenkontrolle) entscheidend sind.

Warum GPUs in Kubernetes? Drei sehr pragmatische Gründe

1. Ausnutzung & Kostenkontrolle: Klassisch „eine GPU pro Job" ist Verschwendung. Viele Inferenz‑ und Dev‑Workloads brauchen keine volle H100. Slicing ermöglicht, die teure Ressource feingranular zu verteilen – ohne den üblichen Zoo aus Spezial‑Provisionern.
2. Produktionsreife & Governance: Kubernetes bringt Isolation, Namespaces, Quotas, RBAC, Audit. Das macht Multi‑Tenant‑Umgebungen beherrschbar – inklusive Showback/Chargeback, Compliance und reproduzierbaren Deployments.
3. Developer Velocity: Dieselben cloud‑nativen Patterns (Helm/Kustomize, GitOps, Progressive Delivery, Self‑Service‑Portale) gelten auch für GPU‑Workloads. Teams deployen schneller und standardisierter, statt jedes Mal Infrastruktur neu zu erfinden.

Kurz: CAPEX/OPEX runter, Produktivität rauf, Risiko kontrolliert. Keine Raketenwissenschaft – nur saubere Architektur.

Architekturüberblick: H100 auf Bare‑Metal‑Kubernetes

Ein typischer Stack sieht so aus:

• Bare‑Metal‑Nodes mit NVIDIA H100 (SXM oder PCIe), Container Runtime (Containerd), aktuellem NVIDIA‑Treiber.
• Kubernetes (>= 1.26 empfohlen), NVIDIA GPU Operator oder dedizierte Installation von Device Plugin/DCGM (je nach Betriebsphilosophie).
• NVIDIA K8s Device Plugin aktiviert Erkennung und Scheduling von GPUs bzw. MIG‑Instanzen.
• DCGM/Exporter liefert Metriken (Prometheus/Grafana).
• GitOps/CI/CD verwaltet die YAMLs für MIG‑Layouts, Device‑Plugin‑Einstellungen, Quotas und Workloads.

Die zentrale Entscheidung: MIG (harte Isolation, feste Profile) vs. Time‑Slicing (kooperatives Teilen, sehr flexibel) – oder beides, aber knotenweise sauber getrennt.

Option A: MIG (Multi‑Instance GPU) – harte Isolation & planbare Performance

MIG teilt eine H100 hardwareseitig in isolierte Instanzen. Jede Instanz erhält dedizierten Anteil an Compute, L2‑Cache, HBM. Ergebnis: stabile Latenz und keine Interferenz zwischen Tenants.

Unterstützte Profile (Beispiele für H100)

• 7 Instanzen: 1g.10gb (je ~10 GB)
• 4 Instanzen: 1g.20gb oder 2g.20gb
• 3 Instanzen: 3g.40gb
• 2 Instanzen: 4g.40gb
• 1 Instanz: 7g.80gb (volle GPU)

Daumenregel: Performance skaliert grob proportional zur Instanzgröße. Eine 3g.40gb liefert etwa 3/7 der Rechenleistung einer vollen H100 (ohne die typischen Interferenz‑Artefakte von Soft‑Sharing).

Setup: MIG auf den Nodes aktivieren

# MIG-Modus aktivieren

nvidia-smi -mig 1

# MIG-Instanzen erstellen (Beispiel: 3x 3g.40gb)
nvidia-smi mig -cgi 9,9,9 -C

# Verfügbare Profile anzeigen

nvidia-smi mig -lgip

Praxis‑Tipps

• Pro Node ein konsistentes MIG‑Layout – erleichtert Scheduling und verhindert „Tetris‑Momente".
• MIG‑Layouts deklarativ verwalten (IaC/GitOps), nicht manuell via Run‑Book.
• Keine Mischung aus MIG und Time‑Slicing auf demselben physikalischen GPU‑Device. Trenne das knotenweise (Label/taints).

Kubernetes‑Integration: NVIDIA Device Plugin

Das Device Plugin macht MIG‑Profile als discrete Ressourcen im Scheduler sichtbar.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nvidia-device-plugin-daemonset
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: nvidia-device-plugin-ds
  template:
    spec:
      containers:
      - image: nvcr.io/nvidia/k8s-device-plugin:v0.14.0
        name: nvidia-device-plugin-ctr
        env:
        - name: MIG_STRATEGY
          value: "single"  # oder "mixed"
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        volumeMounts:
        - name: device-plugin
          mountPath: /var/lib/kubelet/device-plugins

Wichtig

• MIG_STRATEGY=single: Scheduler matcht Pods gegen konkrete MIG‑Profile (nvidia.com/mig-3g.40gb).
• MIG_STRATEGY=mixed: Mehr Flexibilität, aber erfordert bewusste Ressourcen‑Definition und Matching‑Logik in den Workloads.

Pods, die MIG‑Instanzen anfordern

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
  - name: cuda-container
    image: nvcr.io/nvidia/cuda:12.0-base
    resources:
      limits:
        nvidia.com/mig-3g.40gb: 1  # Fordert eine 3g.40gb MIG-Instanz an

So simpel ist es für Developer: eine Zeile im resources.limits entscheidet über die Größe der GPU‑Scheibe.

Wann MIG die richtige Wahl ist

• Multi‑Tenant mit strikter Isolation (Security, predictable QoS).
• Inference (Niedrige, stabile Latenzen; hoher Durchsatz, planbar).
• Entwicklung/Testing (kleine Scheiben, günstige Nutzung).
• Workloads mit vorhersagbarem GPU‑Bedarf.

Nicht optimal: Large‑Model‑Training mit starker GPU‑zu‑GPU‑Kommunikation (NCCL, P2P). Hier ist volle GPU pro Pod sinnvoller – oder mehrere volle GPUs per Node/Job.

Option B: Time‑Slicing – maximale Auslastung bei kooperativem Sharing

Time‑Slicing teilt eine GPU in Zeitslots zwischen mehreren Pods. Das erhöht die Auslastung bei Workloads, die nicht ständig die GPU auslasten (z. B. Entwicklungs‑Notebooks, sporadische Inferenz, Pre‑/Post‑Processing).

Konfiguration via ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: gpu-sharing-config
  namespace: kube-system
data:
  config.yaml: |
    version: v1
    sharing:
      timeSlicing:
        resources:
        - name: nvidia.com/gpu
          replicas: 4  # Teilt jede GPU in 4 Slots    

Device Plugin mit Time‑Slicing starten

- env:
  - name: CONFIG_FILE
    value: /etc/kubernetes/gpu-sharing-config/config.yaml
  volumeMounts:
  - name: gpu-sharing-config
    mountPath: /etc/kubernetes/gpu-sharing-config

Wann Time‑Slicing sinnvoll ist

• Burst‑Workloads (short‑lived, „spiky").
• Development‑Umgebungen und Notebooks.
• Wenn MIG‑Profile zu grob sind oder häufig wechseln müssten.

Trade‑offs

• Keine harte Isolation wie bei MIG (Ressourceninterferenz möglich).
• Performance ist lastabhängig (Mitspieler haben Einfluss). Für SLO‑kritische Inferenz eher MIG.

Scheduling & Node‑Design: Sauber trennen, einfach denken

Konsequenz schlägt Mikrotuning. Plane deine Flotte in klare Node‑Rollen:

• **gpu-mig**: Nodes mit aktivem MIG und festem Profil‑Layout (z. B. 3× 3g.40gb).
• **gpu-full**: Nodes mit vollen GPUs (kein MIG, kein Time‑Slicing) für Training/HPC.
• **gpu-ts**: Nodes mit Time‑Slicing.

Labeling & Affinity

kubectl label nodes gpu-node-1 gpu-type=h100-mig
kubectl label nodes gpu-node-2 gpu-type=h100-full
kubectl label nodes gpu-node-3 gpu-type=h100-ts

Workloads setzen Node Affinity oder nutzen separate NodePools. Ergebnis: Vorhersehbares Scheduling, keine seitlichen Effekte.

Quotas & Fair‑Use

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: team-a
spec:
  hard:
    nvidia.com/mig-3g.40gb: "6"

So verhinderst du, dass ein Team „aus Versehen" den ganzen Cluster belegt. In Shared‑Environments ergänzend LimitRanges und DefaultRequests setzen.

Monitoring & Observability: DCGM als Fundament

Was du nicht misst, optimierst du nicht. Für GPUs ist DCGM Exporter der Standardweg zu Prometheus/Grafana – inklusive MIG‑Awareness.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dcgm-exporter
spec:
  template:
    spec:
      containers:
      - name: dcgm-exporter
        image: nvcr.io/nvidia/k8s/dcgm-exporter:3.0.0
        env:
        - name: DCGM_EXPORTER_KUBERNETES_GPU_ID_TYPE
          value: "mig-uuid"

Was monitoren?

• GPU Utilization (SM, Tensor Cores), Memory Utilization, Memory BW.
• Per‑Pod/Per‑Tenant Nutzungsgrade (Chargeback/Showback).
• Thermals/Power, ECC, Retired Pages (Hardware‑Gesundheit).
• Scheduling‑KPIs: Pending‑Zeiten, Failed‑Placements, Preemption.

Zielbild: Ein klares Cost‑/Utilization‑Dashboard pro Namespace/Team, wöchentlich getrackt. Auslastung < 40 %? Profile anpassen (gröber/feiner), Autoscaling justieren, Trainingsfenster bündeln.

Developer Experience: Self‑Service ohne Überraschungen

Entwickler wollen einfach anfordern, was sie brauchen – ohne Tickets, ohne tribal knowledge.

Ressourcen anfragen – einheitliches Interface

• MIG‑Pods: limits: { nvidia.com/mig-<profile>: 1 }
• Time‑Slicing‑Pods: limits: { nvidia.com/gpu: 1 } (geteilt per ConfigMap)
• Voll‑GPU: limits: { nvidia.com/gpu: 1 } auf gpu-type=h100-full

Images & Toolchains

• Standardisierte Base‑Images (nvcr.io/nvidia/cuda:<version>), plus PyTorch/TensorFlow Varianten.
• Build‑Pipelines (Kaniko/BuildKit) mit Targeted CUDNN/CUDA Versionen je Workload.
• Repro‑Daten: Modelle, Tokenizer, Weights als OCI‑Artifacts oder via Model Registry mit immutable Tags.

Dev‑Loops beschleunigen

• Time‑Slicing für Notebooks (Jupyter, VS Code Remote). Mehr gleichzeitige Sessions pro GPU, akzeptable Latenz.
• MIG‑Slices für dedizierte Test‑/Benchmark‑Runs (stabil, reproduzierbar).
• Feature Gates via Helm Values – Team schaltet selbstständig zwischen TS/MIG/Full um (natürlich nur auf passenden Nodes).

Betriebsprozesse: GitOps‑Flow für GPU‑Infrastruktur

1. MIG‑Layouts als YAML/TOML im Git‑Repo (je Node‑Gruppe).
2. Device‑Plugin‑DaemonSet mit MIG_STRATEGY/Time‑Slicing‑Config versioniert.
3. Node Labels/Taints deklarativ via Cluster‑API/Ansible/Terraform.
4. Quotas/LimitRanges je Namespace, RoleBindings für Self‑Service.
5. Dashboards/Alerts als Code (Grafana/Alertmanager as Code).

Change Management

• MIG‑Layout‑Änderungen sind disruptiv (Re‑Partition der GPUs). Planen als Wartungsfenster mit Workload‑Eviction und Drain.
• Device‑Plugin‑Versionen staged ausrollen (canary NodePool).
• Policy as Code (OPA/Gatekeeper): Erzwingt korrekte Ressourcen‑Anfragen, verhindert „nvidia.com/gpu: 7" in falschen Pools.

Performance-Tuning & Fallstricke

GPU-Workloads in Kubernetes sind leistungsfähig, aber auch empfindlich gegenüber architektonischen Details. Wer das Optimum aus einer H100-Flotte herausholen will, muss einige Stellschrauben kennen und bewusst justieren.

1) NUMA & Topology

In Servern mit mehreren CPU-Sockets hängen GPUs an spezifischen NUMA-Nodes. Wenn ein Pod auf dem „falschen" NUMA-Node landet, entstehen zusätzliche PCIe-Hops, die die Performance spürbar verschlechtern. Für LLM-Inference ist das oft noch akzeptabel, für HPC- oder Trainingsjobs mit hohen IO-Raten nicht. Lösung: Topology-Aware Scheduling aktivieren und den Kubernetes Topology Manager mit der Policy single-numa-node konfigurieren. Damit wird CPU-Affinity sichergestellt und unnötige Cross-Socket-Kommunikation vermieden.

2) Volle GPU für verteiltes Training

MIG eignet sich hervorragend für Inferenz oder kleinere dedizierte Jobs – für verteiltes Training ist es dagegen ungeeignet. Frameworks wie PyTorch DDP oder Horovod setzen auf direkte GPU-zu-GPU-Kommunikation via NVLink oder InfiniBand. Diese ist bei MIG-Slices technisch nicht möglich. Wer also ernsthaftes Training betreiben möchte, sollte ganze GPUs pro Pod bereitstellen und MIG auf den betreffenden Nodes deaktivieren.

3) Zeitscheiben im Time-Slicing richtig dimensionieren

Time-Slicing ist ein nützliches Werkzeug, um GPUs mit mehreren Pods zu teilen. Aber zu viele Zeitscheiben pro GPU führen zu hohem Kontextwechsel-Overhead und schwankender Latenz. Als Faustregel gelten 2–4 Zeitscheiben für Development-Umgebungen (Notebooks, Testjobs) und maximal 6–8 für Produktionslasten. Die exakte Zahl hängt von den Workload-Charakteristiken ab: Batch-Verarbeitung verträgt mehr Replicas, latenzkritische Inferenz weniger.

4) Ressourcenlimits konsequent setzen

Pods ohne GPU-Limits sind ein Planbarkeits-Killer. Kubernetes kann dann nicht sinnvoll schedulen und die Cluster-Auslastung wird unvorhersehbar. Best Practice: Erzwinge GPU-Limits per Admission Policy (z. B. OPA/Gatekeeper). Jeder Pod muss definieren, ob er einen MIG-Slice oder eine ganze GPU benötigt.

5) Mixed Strategy bewusst einsetzen

Das Device Plugin erlaubt mit MIG_STRATEGY=mixed das gleichzeitige Nutzen unterschiedlicher MIG-Profile. Klingt flexibel, ist aber komplex und nur sinnvoll, wenn die Organisation eine klare Standardisierung der Profile etabliert hat. Ohne klare Regeln führt es schnell zu Scheduling-Chaos und Ressourcenverschwendung.

6) Images pinnen

GPU-Workloads sind empfindlich gegenüber Inkompatibilitäten in der CUDA/CUDNN/Treiber/Framework-Matrix. Versionen „frei flottieren" zu lassen, endet schnell in schwer reproduzierbaren Bugs. Empfehlung: Golden Images pro Workload-Familie pflegen, Versionen strikt pinnen und nur nach definierten Tests upgraden.

7) Persistent Storage & IO

GPU-Jobs sind oft IO-gebunden. Selbst die schnellste H100 wartet sinnlos, wenn Daten zu langsam nachgeladen werden. Daher: NVMe-Storage lokal für Hotsets, Objektspeicher für große Datenmengen und Read-Only Volume Mounts für Modelle. Bei sehr großen Datenpipelines lohnt ein Blick auf RDMA-fähige Netzwerke.

8) Security

Auch GPU-Workloads müssen Security-Best Practices einhalten. Container brauchen keine Root-Rechte, sondern sollten mit minimalen Capabilities, seccomp und AppArmor/SELinux-Profilen laufen. Filesysteme am besten read-only, wo möglich. Überraschend viele Beispiel-Manifeste im Netz arbeiten noch mit root-Containern – ein unnötiges Risiko.

Kosten & Kapazitätsplanung: Effizienz statt Peak-Slides

Der wahre Kostenfaktor bei GPU-Clustern ist nicht die Anschaffung, sondern die unzureichende Auslastung. Eine H100, die im Schnitt nur zu 30 % ausgelastet ist, verbrennt Kapital. Ziel muss sein: durchschnittlich > 60 % Auslastung über die Woche hinweg.

Slicing als Standard

MIG und Time-Slicing sind die zentralen Werkzeuge, um GPUs effizienter auszulasten. Statt eine volle GPU für einen kleinen Inferenz-Job zu blockieren, teilt man die Karte in mehrere Slices und erreicht so eine gleichmäßigere Verteilung.

Tiered Pools

Nicht jede Anwendung hat dieselben Anforderungen. Deshalb sollten GPU-Ressourcen in dedizierte Pools aufgeteilt werden:

• prod-inference: MIG-basiert, stabile Latenz, hohe Verfügbarkeit.
• prod-training: volle GPUs, optimiert für Multi-GPU-Training und HPC.
• dev: Time-Slicing, maximale Flexibilität, kein SLA.

So lassen sich Service Levels klar abgrenzen und unterschiedliche Preismodelle einfach erklären.

Showback & Chargeback

Kostentransparenz entsteht durch Metriken. Mit DCGM Exporter und Prometheus können GPU-Nutzungsdaten pro Namespace oder Pod erhoben werden. Daraus lassen sich Reports erstellen, die den Verbrauch klar darstellen („Team B verbrauchte 800 GPU-Stunden auf MIG-Slices"). Wer will, kann diese Daten in Chargeback-Modelle überführen – mit Preisen pro Slice oder Zeitslot. Das fördert Eigenverantwortung und reduziert interne Verteilungskämpfe.

Reserved vs. Spot/Preemptible

In hybriden Szenarien lohnt es, unterschiedliche Kapazitätstypen zu nutzen:

• Reserved Pools für Produktions-Inferenz mit klaren SLOs.
• Spot oder Preemptible GPUs für Trainingsjobs, die Unterbrechungen tolerieren.

Das senkt Kosten signifikant, ohne Verlässlichkeit zu gefährden.

Effekt in der Praxis

Mit sauberem Slicing, klaren Pools und Kostentransparenz können mehr Teams und Jobs gleichzeitig auf derselben Hardware laufen. Anstelle von endlosen Diskussionen über GPU-Kontingente liefern Dashboards Fakten. Ergebnis: höhere Effizienz, weniger Politik, mehr Durchsatz.

End‑to‑End‑Beispiel: Von leerer Node zum produktiven MIG‑Cluster

1) Node vorbereiten

• Aktueller NVIDIA‑Treiber & CUDA installiert.
• Containerd konfiguriert, nvidia‑container‑runtime aktiv.

2) MIG aktivieren & Layout setzen

nvidia-smi -mig 1
nvidia-smi mig -cgi 9,9,9 -C
nvidia-smi mig -lgip

3) Device Plugin deployen

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nvidia-device-plugin-daemonset
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: nvidia-device-plugin-ds
  template:
    spec:
      containers:
      - image: nvcr.io/nvidia/k8s-device-plugin:v0.14.0
        name: nvidia-device-plugin-ctr
        env:
        - name: MIG_STRATEGY
          value: "single"
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        volumeMounts:
        - name: device-plugin
          mountPath: /var/lib/kubelet/device-plugins

4) Nodes labeln

kubectl label nodes gpu-node-1 gpu-type=h100-mig

5) Quotas setzen

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: team-a
spec:
  hard:
    nvidia.com/mig-3g.40gb: "6"

6) Monitoring aktivieren

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dcgm-exporter
spec:
  template:
    spec:
      containers:
      - name: dcgm-exporter
        image: nvcr.io/nvidia/k8s/dcgm-exporter:3.0.0
        env:
        - name: DCGM_EXPORTER_KUBERNETES_GPU_ID_TYPE
          value: "mig-uuid"

7) Workload deployen

apiVersion: v1
kind: Pod
metadata:
  name: inference-pod
  namespace: team-a
spec:
  nodeSelector:
    gpu-type: h100-mig
  containers:
  - name: model-server
    image: nvcr.io/nvidia/cuda:12.0-base
    resources:
      limits:
        nvidia.com/mig-3g.40gb: 1
    command: ["bash","-lc","nvidia-smi && python serve.py"]

Ergebnis: Stabiler, isolierter Inferenz‑Pod auf einer dedizierten MIG‑Instanz mit sauberem Monitoring und Governance.

Alternative End‑to‑End: Time‑Slicing‑Pool für Dev & Burst

1) ConfigMap erstellen

apiVersion: v1
kind: ConfigMap
metadata:
  name: gpu-sharing-config
  namespace: kube-system
data:
  config.yaml: |
    version: v1
    sharing:
      timeSlicing:
        resources:
        - name: nvidia.com/gpu
          replicas: 4    

2) Device Plugin mit Config mounten

- env:
  - name: CONFIG_FILE
    value: /etc/kubernetes/gpu-sharing-config/config.yaml
  volumeMounts:
  - name: gpu-sharing-config
    mountPath: /etc/kubernetes/gpu-sharing-config

3) Nodes labeln

kubectl label nodes gpu-node-3 gpu-type=h100-ts

4) Dev‑Pod starten

apiVersion: v1
kind: Pod
metadata:
  name: dev-notebook
  namespace: team-b
spec:
  nodeSelector:
    gpu-type: h100-ts
  containers:
  - name: notebook
    image: nvcr.io/nvidia/cuda:12.0-base
    resources:
      limits:
        nvidia.com/gpu: 1
    command: ["bash","-lc","jupyter lab --ip=0.0.0.0 --no-browser"]

Ergebnis: Vier Dev‑Pods teilen sich eine H100 kooperativ. Für notebooks ideal, für SLO‑kritische Produktion nicht

Weiterführend

• Governance & Security für KI-Teams
• Developer Platforms von ayedo
• k3k: agent-less k3s in Kubernetes

Flexible Einsatzszenarien mit günstigen GPU-Anbietern wie Hetzner

Die beschriebenen Methoden – MIG, Time-Slicing und klare Kubernetes-Integration – sind nicht nur auf High-End-On-Premises-Cluster mit Millionenbudget beschränkt. Gerade Anbieter wie Hetzner, die dedizierte GPU-Server ohne langfristige Vertragsbindung anbieten, eröffnen Unternehmen jeder Größe zusätzliche Handlungsoptionen.

Kosteneffiziente Test- und Entwicklungsumgebungen

Ein zentrales Problem vieler KI-Teams: Wie validieren wir unsere Modelle, ohne Produktionsressourcen zu blockieren?

Mit Hetzner lassen sich dedizierte GPU-Server flexibel und kurzfristig anmieten. Unternehmen können diese mit Kubernetes und dem NVIDIA Device Plugin ausstatten, MIG-Partitionen oder Time-Slicing konfigurieren und die gleiche Infrastruktur-Logik nutzen wie in ihrer On-Premises-Umgebung.

Vorteil: Entwickler können kostengünstig experimentieren, Benchmarks fahren oder Continuous-Integration-Pipelines für GPU-Workloads etablieren – ohne hohe Fixkosten oder langfristige Verpflichtungen.

Staging und Pre-Production für KI-Workloads

In regulierten Branchen (z. B. Finance, Healthcare) ist es oft notwendig, neue Modelle in einer kontrollierten Umgebung zu verproben, bevor sie in produktive, streng überwachte Rechenzentren übernommen werden. Hetzner-Server sind dafür ideal:

• MIG für reproduzierbare Testszenarien: Teams können ein neues Modell auf einer festen GPU-Scheibe (3g.40gb) validieren und exakt dieselbe Instanzgröße später On-Premises nachstellen.
• Time-Slicing für Multi-User-Staging: Mehrere Entwickler teilen sich denselben GPU-Server für Pre-Release-Tests, ohne dass Ressourcen verschwendet werden.
• Kubernetes-Standardisierung: Die gleichen YAMLs, die in der Public-Cloud oder On-Premises laufen, können auch auf Hetzner getestet werden.

Hybrid-Strategien für Kosten- und Compliance-Optimierung

Nicht jedes Unternehmen möchte oder darf sämtliche Workloads in die Public Cloud verlagern. Mit Hetzner entsteht ein kosteneffizienter Mittelweg:

• Nicht-kritische Workloads wie Feature-Experimente, Hyperparameter-Tuning oder synthetische Datengenerierung laufen kostengünstig bei Hetzner.
• Kritische Workloads wie Produktions-Inferenz mit strengen SLAs verbleiben On-Premises, wo volle Kontrolle über Sicherheit, Datenschutz und Betriebsumgebung herrscht.
• Unternehmen können mit Federation- oder Multi-Cluster-Ansätzen (z. B. Rancher, Crossplane, Cluster API) nahtlos zwischen On-Premises- und Hetzner-Umgebungen orchestrieren.

Skalierung ohne Vendor-Lock-in

Ein oft unterschätzter Vorteil von Anbietern wie Hetzner: Sie stellen rohe, dedizierte Hardware bereit, die vollständig in Kubernetes integriert werden kann – ohne proprietäre APIs oder Lock-in-Risiken.

Für Unternehmen bedeutet das:

• Komplette Kontrolle über Treiber, CUDA-Versionen und MIG-Layouts.
• Reproduzierbarkeit: Ein einmal getestetes Setup lässt sich On-Premises oder bei anderen Anbietern exakt replizieren.
• Portabilität: Workloads sind nicht an eine spezifische Public-Cloud-Plattform gebunden, sondern können beliebig verlagert werden.

Compliance und Governance

Auch in streng regulierten Umfeldern bieten Hetzner-Server interessante Optionen. Zwar wird man hochkritische Workloads nicht in ein externes Rechenzentrum auslagern – aber für Development, Staging und Pre-Compliance-Tests reicht es oft, dass die Umgebung technisch mit der späteren Produktionsumgebung übereinstimmt. Mit Kubernetes-Namespace-Isolation, ResourceQuotas, RBAC und DCGM-Monitoring können auch bei externen GPU-Servern klare Governance-Mechanismen etabliert werden.

Fazit: Mehr Optionen, weniger Blockaden

Die Kombination aus GPU-Slicing (MIG/TS), Kubernetes-Standardisierung und kostengünstigen Anbietern wie Hetzner erlaubt Unternehmen jeder Größe, flexibel zu arbeiten:

• Start-ups können früh mit GPUs arbeiten, ohne langfristige Verträge.
• Mittelständler erhalten Test- und Staging-Umgebungen, die sich mit vertretbaren Budgets betreiben lassen.
• Konzerne mit hohen Compliance-Anforderungen können Hybrid-Modelle fahren: On-Premises für kritisch, Hetzner für explorativ.

Ergebnis: Weniger Blockaden, schnellere Iteration, bessere Ressourcenauslastung – und das alles mit überschaubaren Kosten.

Was können wir für Sie tun?

Als Managed Service Provider unterstützt ayedo Unternehmen dabei, GPU-Ressourcen in Kubernetes sicher, effizient und cloud-native bereitzustellen. Wir übernehmen die Implementierung von MIG-Layouts und Time-Slicing, richten dedizierte Node-Pools für Training, Inferenz und Development ein und sorgen mit Quotas, Monitoring und GitOps-Prozessen für Governance und Transparenz. Entwickler profitieren von standardisierten Workflows und Self-Service-Mechanismen, während Entscheider die volle Kontrolle über Kosten, Auslastung und Compliance behalten. So entsteht eine zukunftsfähige GPU-Infrastruktur, die Innovation beschleunigt und zugleich Ressourcen optimal nutzt.