GPU as a Service

Dedizierte NVIDIA GPU-Karten über VMs oder Kubernetes.

Greifen Sie über GPU Passthrough auf Ihre VMs oder über den NVIDIA GPU Operator auf Ihre Kubernetes Cluster auf hochleistungsfähige NVIDIA Grafikprozessoren zu. Zwei Modi, ein Hardwarekatalog.

EINE DEMO ANFORDERN WIRD DIE DOKUMENTATION LESEN

4 GPU-Karten

L40S - A100 - H100 - RTX PRO

2 Modi

VM Passthrough - Kubernetes

96 GB

VRAM max (RTX PRO 6000)

3700 TOPS

Leistung RTX PRO 6000 (FP4)
GPU-KATALOG

Vier NVIDIA-Familien für jeden Workload.

L40S für Inferenz und Entwicklung, A100 für ML-Training, H100 für LLM und Exascale-Computing. Beginnen Sie mit L40S und arbeiten Sie sich dann nach oben.

L40S

NVIDIA Ada Lovelace

Bild 7
Speicher 48 GB GDDR6
ECC Inklusive
INT8-Leistung 733 TOPS
Leistung FP32 91.6 TFLOPs

Inferenz, generative KI, Echtzeit-Rendering, Entwicklung und Prototypenbau.

A100

NVIDIA Ampere

Bild 6
Speicher 80 GB HBM2e
ECC Inklusive
INT8-Leistung 624 TOPS
Leistung FP32 19.5 TFLOPs

ML-Training, Fine-Tuning von Modellen, Hochleistungsrechnen.

H100

NVIDIA Hopper

H100NVIDIA Hopper
Speicher 80 GB HBM2e
ECC Inklusive
INT8-Leistung 3026 TOPS
Performance Tensor TF32 756 TFLOPs

LLM, Transformers, verteiltes Training, Exascale Computing.

RTX PRO 6000

NVIDIA Blackwell

NVIDIA Blackwell
Speicher 96 GB GDDR7
ECC Inklusive
Leistung FP4 3.7 PFLOPS
Leistung FP32 117 TFLOPs

Multimodale LLM-Inferenz, Fine-Tuning von Modellen mit bis zu 70B Parametern, generative KI und Echtzeit-Rendering.

Ratschlag für den Start

Beginnen Sie mit einem L40S für Entwicklung und Prototypenbau. Wechseln Sie zu einem A100 für das Training von Standard-ML-Modellen, und heben Sie sich den H100 für anspruchsvolle Workloads wie LLM-Training oder High Performance Computing auf.
Zugangsmodi

Grafikprozessor auf VM oder Grafikprozessor auf Kubernetes.

Hikube bietet zwei Arten des Zugriffs auf dieselbe Hardware. Wählen Sie entsprechend Ihrer Workload und Ihrem Orchestrierungsgrad.

GPU auf PCI PassthroughVirtual Machine

Der physische Grafikprozessor wird über VFIO-PCI direkt an die VM angehängt. Vollständiger und exklusiver Zugriff auf den Beschleuniger - native Leistung, kein Orchestrierungs-Overhead.

  • Anwendungen, die eine vollständige Kontrolle über den Grafikprozessor erfordern.
  • Nicht containerisierte Legacy- oder spezialisierte Workloads.
  • Isolierte Entwicklungsumgebungen
  • Grafische Anwendungen (Rendering, CAD).
  • CUDA-Prototyping und -Experimente

Grafikprozessoren auf Kubernetes GPU Operator

GPUs werden über das NVIDIA Device Plugin, das vom GPU Operator verwaltet wird, den Pods ausgesetzt. Von Kubernetes orchestriertes Scheduling - gemeinsame Nutzung durch Pods, Autoscaling, ML-Pipelines.

  • Containered AI/ML Workloads.
  • Automatische Skalierung von GPU-Anwendungen.
  • Gemeinsame Nutzung von GPU-Ressourcen zwischen Pods.
  • Parallele und verteilte Jobs
  • Komplexe ML/AI-Pipelines
GPU auf VM
GPU auf Kubernetes
Art des Zugriffs
Exklusive PCI Passthrough
Device Plugin geteilt
Isolierung
1 Grafikprozessor = 1 VM (dediziert)
Scheduling orchestriert von K8s
Leistung
Native (passthrough)
Native (device plugin)
NVIDIA-Treiber
Handbücher über cloud-init
Automatisch (GPU Operator)
Scaling
Nur vertikal
Horizontal + Vertikal
Sharing zwischen Workloads
Nicht
Ja (zwischen Pods)
Setup-Zeit
~5 Minuten
~10 Minuten
Komplexität
Einfach
Mäßig
Einschalten

Mit ein paar Zeilen YAML bereit

Ob in einer VM oder einem Kubernetes-Cluster, die GPU-Konfiguration beschränkt sich darauf, den gewünschten GPU-Typ in Ihrem Manifest zu deklarieren. Der Rest, Treiber, Scheduling und Allokation werden von Hikube verwaltet.

Auf einer VM

Fügen Sie ein gpus[]-Feld zu Ihrer VMInstance hinzu. Der Grafikprozessor wird per PCI Passthrough angehängt, was Ihnen einen direkten und exklusiven Zugriff auf die Hardware garantiert. Multi-GPUs sind durch Wiederholung der Eingaben möglich.

yaml
kind: VMInstance
spec:
instanceType: u1.2xlarge
gpus:
- name: "nvidia.com/AD102GL_L40S".


Die NVIDIA-Treiber werden beim ersten Start über cloud-init installiert.

Vollständigen Leitfaden ansehen

Auf Kubernetes

Fügen Sie Ihrem Cluster einen GPU Group Node hinzu und fordern Sie die GPU in Ihren Pods über resources.limits an. Der GPU Operator verwaltet die Treiber automatisch.

yaml
kind: Kubernetes
spec: 
 nodeGroups: 
 -gpu-workers: 
 instanceType: u1.xlarge 
 gpus: 
 - name: "nvidia.com/AD102GL_L40S".

Trennen Sie Ihre Nodegruppen CPU und GPU für ein unabhängiges Scaling.

Vollständigen Leitfaden ansehen
DImensionierung

Empfohlenes CPU/RAM-Verhältnis pro Grafikprozessor.

Planen Sie 8 bis 16 vCPUs pro GPU ein. Für GPU-Workloads werden Instanzen der Universal Series (u1) empfohlen.

INSTANZEN
VCPU
RAM
EMPFOHLENE VERWENDUNG
u1.xlarge
4
16 GB
1× L40S - Entwicklung, Prototypenbau
u1.2xbreit
8
32 GB
1× A100 - Fine-Tuning, Multi-Model-Inference
u1.4xbreit
16
64 GB
1-2× A100 - intensives ML-Training
u1.8xbreit
32
128 GB
4× H100 - verteiltes Training, LLM
Überprüfung nach dem Einsatz

GPU-Zugang bestätigen

Auf einer VM

bash
# SSH-Verbindung
virtctl ssh -i ~/.ssh/id_ed25519 ubuntu@gpu-workstation

 # GPU überprüfen
 nvidia-smi

# Detaillierte Infos nvidia-smi \ 
 --query-gpu=name,memory.total,utilization.gpu \ 
 --format=csv

Auf Kubernetes

yaml
# GPUs, die von Node ausgestellt werden
kubectl get nodes -o custom-columns=\
NAME:.metadata.name,\?
GPU:.status.allocatable. 'nvidia.com/gpu'.

# Von einem Pod aus
kubectl exec -it <pod-name> -- nvidia-smi

# Zugewiesene Ressourcen
kubectl describe node <gpu-node> \
| grep -A5 "Allocated resources"
Warum die GPU-Cloud

Der Grafikprozessor als Beschleuniger für moderne Workloads.

Die CPU ist darauf ausgelegt, komplexe sequenzielle Aufgaben auszuführen. Der Grafikprozessor hingegen ist für massiven Parallelismus architektonisiert: Tausende von einzelnen Kernen arbeiten gleichzeitig an demselben Problem. Es ist dieser grundlegende Unterschied, der den Grafikprozessor für das Training von Machine-Learning-Modellen, groß angelegte Inferenzen, 3D-Rendering oder wissenschaftliches Rechnen unverzichtbar macht.

Der Kauf eigener GPU-Hardware bedeutet lange Investitionszyklen, schwer vorhersehbares Kapazitätsmanagement und schnelle Veralterung: Ein heute gekaufter H100 wird in drei Jahren veraltet sein. Das Modell GPU as a Service ermöglicht den Zugriff auf die neueste Generation von NVIDIA-Hardware bei Bedarf, skaliert nach der tatsächlichen Auslastung und bezahlt nur für das, was verbraucht wird.

Auf Hikube werden die Grafikprozessoren in der Schweiz gehostet und sind über Standard-APIs zugänglich, ohne Lock-in, ohne proprietäre Agenten. Ob Ihr Workload auf einer isolierten VM oder in einem von Teams gemeinsam genutzten Kubernetes-Cluster läuft, der Zugriff auf die Hardware bleibt gleich.

svgviewer-output

CPU vs. GPU: Das richtige Werkzeug für jede Aufgabe

Die CPU zeichnet sich bei sequentieller Verarbeitung mit niedriger Latenz aus. Der Grafikprozessor ist für massive Matrixoperationen optimiert: Tensor-Multiplikation, Convolutions, Attention Mechanisms, die das Herzstück von Deep Learning sind.

svgviewer-output

Datensouveränität garantiert

Ihre Vorlagen, Datasets und Checkpoints bleiben in der Schweiz. Native DSGVO-Konformität, ohne zusätzliche Konfiguration.

svgviewer-output

Zugang zur neuesten Generation ohne Capex

L40S, A100, H100 sind auf Anfrage erhältlich. Kein Kaufzyklus, keine Abschreibung, keine Serverraumverwaltung. Sie greifen auf die neueste Hardware zu, wenn Sie sie benötigen.

svgviewer-output

Integration in Ihren bestehenden Stack

Kubernetes-Standard, natives YAML, kompatibel mit Ihren bestehenden MLOps-Tools (Kubeflow, Argo Workflows, MLflow). Kein Umschreiben von Pipelines.

FAQ

Fragen zu GPU as a Service

Fragen, die Teams vor dem Einsatz ihrer ersten GPU-Workloads stellen.

Welchen Grafikprozessor sollte ich für meinen Workload auswählen?

Die allgemeine Regel: Beginnen Sie mit dem L40S, wenn es um Inferenz, Entwicklung oder Prototyping geht. Er deckt die überwiegende Mehrheit der Fälle zu geringen Kosten ab. Wechseln Sie auf denA100, wenn Sie Modelle ernsthaft trainieren (Fine-Tuning, große Datenmengen). Reservieren Sie den H100 für wirklich anspruchsvolle Workloads: Multi-Milliarden-Parameter-LLMs, verteiltes Training über mehrere Knoten.

VM oder Kubernetes, wie soll man sich entscheiden?

Wenn Ihre Anwendung nicht containerisiert ist, Sie vollen Zugriff auf den Grafikprozessor benötigen oder prototypisch arbeiten: nehmen Sie eine VM. Das ist einfacher, schneller zu implementieren und der Grafikprozessor steht Ihnen vollständig zur Verfügung.

Wenn Sie Ihre Workloads bereits mit Kubernetes orchestrieren, automatisches Scaling benötigen oder GPU-Ressourcen zwischen mehreren Teams aufteilen müssen: entscheiden Sie sich für Kubernetes. Die zusätzliche Komplexität wird durch Flexibilität ausgeglichen.

Kann ich einen Grafikprozessor zwischen mehreren Jobs teilen?

Planen Sie 8 bis 16 vCPUs pro Grafikprozessor ein. Ein u1.2xlarge (8 vCPUs, 32 GB RAM) ist ein guter Ausgangspunkt für einen einzelnen Grafikprozessor. Für vier H100-Grafikprozessoren sollten Sie auf u1.8xlarge (32 vCPUs, 128 GB RAM) erhöhen. Eine Unterdimensionierung der CPU führt zu Engpässen bei der Datenvorverarbeitung, die die GPU-Auslastung deckeln.

Muss man die NVIDIA-Treiber selbst verwalten?

Auf VM, ja. Sie installieren die Treiber über ein cloud-init-Skript beim ersten Start. Die Doku liefert das komplette Skript, es ist eine einmalige Manipulation.

Auf Kubernetes, nein. Der GPU Operator erledigt dies automatisch auf den GPU-Knoten. Sie aktivieren das Addon im Cluster-Manifest, der Rest ist transparent.

Kann ich einen Grafikprozessor zwischen mehreren Jobs teilen?

Im VM-Modus nicht. Der Grafikprozessor ist vollständig der VM gewidmet. Im Kubernetes-Modus können mit dem GPU Operator ganze GPUs verschiedenen Pods auf demselben Knoten zugewiesen werden, aber ein Pod kann nicht nur einen Bruchteil einer GPU anfordern. Wenn Sie mehrere kleine Jobs parallel laufen lassen müssen, ist der Kubernetes-Ansatz mit mehreren Pods auf einem Multi-GPU-Knoten am effizientesten.