GPU as a Service

Dedizierte NVIDIA GPU-Karten über VMs oder Kubernetes.

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

KOSTENLOS STARTEN 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 bevor Sie aufrüsten.

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 Prototyping.

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.

Tipp für den Start

Beginnen Sie mit einem L40S für Entwicklung und Prototyping. 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

GPU auf VM oder GPU auf Kubernetes.

Hikube bietet zwei Zugriffsmodi auf dieselbe Hardware. Wählen Sie je nach Workload und Ihrem Orchestrierungsgrad.

GPU auf Virtual Machine PCI Passthrough

Die physische GPU wird über VFIO-PCI direkt an die VM angehängt. Vollständiger, exklusiver Zugriff auf den Beschleuniger - native Leistung, ohne Orchestrierungs-Overhead.

  • Anwendungen, die eine volle Kontrolle über den GPU erfordern.
  • Nicht containerisierte Legacy- oder spezialisierte Workloads.
  • Isolierte Entwicklungsumgebungen
  • Grafikanwendungen (Rendering, CAD).
  • CUDA-Prototyping und -Experimente

Mehr über Virtuelle Maschinen erfahren

GPU auf Kubernetes Operator

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

  • Containerisierte KI/ML Workloads.
  • Automatische Skalierung von GPU-Anwendungen.
  • Gemeinsame Nutzung von GPU-Ressourcen zwischen Pods.
  • Parallele und verteilte Jobs
  • Komplexe KI/ML-Pipelines

Mehr über Kubernetes erfahren

GPU auf VM
GPU auf Kubernetes
Zugriffsart
Exklusiver PCI Passthrough
Geteiltes Device Plugin
Isolierung
1 GPU = 1 VM (dediziert)
Von K8s orchestriertes Scheduling
Leistung
Native (passthrough)
Native (Device Plugin)
NVIDIA-Treiber
Manuell über cloud-init
Automatisch (GPU Operator)
Scaling
Nur vertikal
Horizontal + Vertikal
Sharing zwischen Workloads
Nein
Ja (zwischen Pods)
Setup-Zeit
~5 Minuten
~10 Minuten
Komplexität
Einfach
Mäßig
ERSTE SCHRITTE

Mit wenigen Zeilen YAML bereit

Ob auf einer VM oder einem Kubernetes-Cluster. Die GPU-Konfiguration beschränkt sich darauf, den gewünschten GPU-Typ in Ihrem Manifest zu deklarieren. Den Rest, Treiber, Scheduling und Zuweisung, übernimmt Hikube.

Auf einer VM

Fügen Sie ein gpus[]-Feld zu Ihrer Auf einer VM - Fugen Sie Ihrer VMInstance ein gpus[]-Feld hinzu. Die GPU wird per PCI Passthrough angehangt und gibt Ihnen direkten, exklusiven Hardwarezugriff. Multi-GPU ist durch Wiederholen der Eintrage moglich.

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 Nodegroup  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 CPU- und GPU- Nodegroups für unabhängiges Scaling.

Vollständigen Leitfaden ansehen
DImensionierung

Empfohlenes CPU/RAM-Verhältnis pro GPU.

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

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

GPU-Zugriff 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 GPU AUS DER CLOUD

Die GPU, Beschleuniger moderner Workloads.

Die CPU ist darauf ausgelegt, komplexe sequenzielle Aufgaben auszufuhren. Die GPU hingegen ist für massive Parallelitat konzipiert: Tausende einfacher Kerne, die gleichzeitig am selben Problem arbeiten. Genau dieser grundlegende Unterschied macht die GPU unverzichtbar für das Training von Machine-Learning-Modellen, gross angelegte Inferenz, 3D-Rendering oder wissenschaftliches Rechnen.

Eigene GPU-Hardware zu kaufen bedeutet lange Investitionszyklen, schwer planbare Kapazitat und schnelle Veralterung: Ein heute gekaufter H100 ist in 3 Jahren uberholt. Das Modell GPU as a Service bietet On-Demand-Zugriff auf die neueste Generation von NVIDIA-Hardware, skaliert nach tatsachlicher Last und lasst Sie nur fur den tatsachlichen Verbrauch zahlen.

Auf Hikube werden die GPUs in der Schweiz gehostet und sind uber Standard-APIs zugänglich, ohne Lock-in, ohne proprietären Agenten. Ob Ihr Workload auf einer isolierten VM oder in einem teamubergreifend genutzten Kubernetes-Cluster lauft - der Hardwarezugriff bleibt identisch.

svgviewer-output

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

CPU vs. GPU: das richtige Werkzeug fur jede Aufgabe - Die CPU glanzt bei sequenzieller Verarbeitung mit niedriger Latenz. Die GPU ist fur massive Matrixoperationen optimiert: Tensor-Multiplikation, Convolutions, Attention-Mechanismen - das Herzstuck von Deep Learning.

svgviewer-output

Garantierte Datensouveränität

Ihre Modelle, 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 auf Anfrage verfügbar. Kein Kaufzyklus, keine Abschreibung, keine Serverraumverwaltung. Sie greifen genau dann auf die neueste Hardware zu, wenn Sie sie brauchen.

 

svgviewer-output

Integration in Ihren bestehenden Stack

Standard-Kubernetes, 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.

Welche GPU soll ich fur meinen Workload wahlen?

Faustregel: Beginnen Sie mit der L40S fur alles rund um Inferenz, Entwicklung oder Prototyping - sie deckt die grosse Mehrheit der Falle kostengünstig ab. Wechseln Sie zur A100, wenn Sie Modelle ernsthaft trainieren (Fine-Tuning, grosse Datasets). Reservieren Sie die H100 fur wirklich anspruchsvolle Workloads: LLMs mit mehreren Milliarden Parametern, verteiltes Training über mehrere Knoten.

VM oder Kubernetes - wie entscheide ich mich?

Wenn Ihre Anwendung nicht containerisiert ist, Sie vollen Zugriff auf den Grafikprozessor benötigen oder prototypisch arbeiten: nehmen Sie eine Virtuelle Maschinen. 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.

Wie dimensioniere ich CPU/RAM rund um eine GPU?

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 ich 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 eine GPU fur mehrere Jobs teilen?

Im VM-Modus nein: Der GPU ist vollständig der VM gewidmet. Im Kubernetes-Modus kan der GPU Operator ganze GPUs verschiedenen Pods auf demselben Knoten zugewiesen, aber ein Pod kann keinen Bruchteil einer GPU anfordern. Um mehrere kleine Jobs parallel laufen zu lassen, ist der Kubernetes-Ansatz mit mehreren Pods auf einem Multi-GPU-Knoten am effizientesten.