GPU as a Service

Dedicated NVIDIA GPUs via VMs or Kubernetes

Access high-performance NVIDIA GPUs via GPU Passthrough on your VMs, or via the NVIDIA GPU Operator on your Kubernetes clusters. Two modes, a single hardware catalog.

TRY FOR FREE READ THE DOCUMENTATION

4 GPUs

L40S - A100 - H100 - RTX PRO

2 modes

VM Passthrough - Kubernetes

96 GB

VRAM max (RTX PRO 6000)

3700 TOPS

Performance RTX PRO 6000 (FP4)
GPU CATALOGUE

Four NVIDIA families for each workload

L40S for inference and development, A100 for ML training, H100 for LLM and exascale computing. Start with the L40S before moving up.

L40S

NVIDIA Ada Lovelace

image 7
Memory 48 GB GDDR6
ECC Included
Performance INT8 733 TOPS
Performance FP32 91.6 TFLOPs

Inference, generative AI, real-time rendering, development and prototyping.

A100

NVIDIA Ampere

image 6
Memory 80 GB HBM2e
ECC Included
Performance INT8 624 TOPS
Performance FP32 19.5 TFLOPs

ML training, model fine-tuning, high-performance computing.

H100

NVIDIA Hopper

H100NVIDIA Hopper
Memory 80 GB HBM2e
ECC Included
Performance INT8 3026 TOPS
Performance Tensor TF32 756 TFLOPs

LLM, transformers, distributed training, exascale computing.

RTX PRO 6000

NVIDIA Blackwell

NVIDIA Blackwell
Memory 96 GB GDDR7
ECC Included
Performance FP4 3.7 PFLOPS
Performance FP32 117 TFLOPs

Multimodal LLM inference, fine-tuning of models with up to 70B parameters, generative AI and real-time rendering.

Getting-started tip

Start with an L40S for development and prototyping. Move to an A100 for standard ML model training, and reserve the H100 for demanding workloads such as LLM training or high-performance computing.
Access modes

GPU on VM or GPU on Kubernetes

Hikube offers two ways to access the same hardware. Choose based on your workload and level of orchestration.

GPU on Virtual Machine PCI Passthrough

The physical GPU is attached directly to the VM via VFIO-PCI. Full, exclusive access to the accelerator - native performance, with no orchestration overhead.

  • Applications needing full control of the GPU
  • Legacy or specialised non-containerised workloads
  • Isolated development environments
  • Graphics applications (rendering, CAD)
  • CUDA prototyping and experimentation

Learn more about VMs

GPUs on Kubernetes GPU Operator

GPUs are exposed to pods via the NVIDIA Device Plugin, managed by the GPU Operator. Scheduling orchestrated by Kubernetes - sharing across pods, autoscaling, ML pipelines.

  • Containerised AI/ML workloads
  • Automatic scaling of GPU applications
  • GPU resource sharing across pods
  • Parallel and distributed jobs
  • Complex ML/AI pipelines

Learn more about Kubernetes

GPU on VM
GPU on Kubernetes
Access mode
Exclusive PCI Passthrough
Shared Device Plugin
Isolation
1 GPU = 1 VM (dedicated)
Scheduling orchestrated by K8s
Performance
Native (passthrough)
Native (device plugin)
NVIDIA drivers
Manuals via cloud-init
Automatic (GPU Operator)
Scaling
Vertical only
Horizontal + Vertical
Sharing across workloads
No
Yes (across pods)
Setup time
~5 minutes
~10 minutes
Complexity
Simple
Moderate
Getting started

Ready in a few lines of YAML

Whether on a VM or a Kubernetes cluster, GPU configuration comes down to declaring the GPU type you want in your manifest. The rest - drivers, scheduling and allocation - is handled by Hikube.

On a VM

Add a gpus[] field to your VMInstance. The GPU is attached in PCI Passthrough, giving you direct, exclusive access to the hardware. Multi-GPU is possible by repeating the entries.

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


NVIDIA drivers are installed via cloud-init at first boot.

See the complete guide

On Kubernetes

Add a GPU node group to your cluster, then request the GPU in your pods via resources.limits. The GPU Operator manages the drivers automatically.

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


 

Separate your CPU and GPU node groups for independent scaling.

See the complete guide
SIZING

Recommended CPU/RAM ratio per GPU

Plan for 8 to 16 vCPUs per GPU. Universal (u1) family instances are recommended for GPU workloads.

INSTANCES
VCPU
RAM
RECOMMENDED USE
u1.xlarge
4
16 GB
1× L40S - development, prototyping
u1.2xwide
8
32 GB
1× A100 - fine-tuning, multi-model inference
u1.4xwide
16
64 GB
1-2× A100 - intensive ML training
u1.8xwide
32
128 GB
4× H100 - distributed drive, LLM
Post-deployment verification

Confirm GPU access

On a VM

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

 # Check GPU
 nvidia-smi

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


 

On Kubernetes

yaml
# GPUs exposed per node
kubectl get nodes -o custom-columns=\
NAME:.metadata.name,\
GPU:.status.allocatable. 'nvidia\.com/gpu'

# From a pod
kubectl exec -it <pod-name> -- nvidia-smi

# Allocated resources
kubectl describe node <gpu-node> \
| grep -A5 "Allocated resources"
Why the GPU cloud

The GPU, accelerator of modern workloads

The CPU is built to execute complex sequential tasks. The GPU, by contrast, is built for massive parallelism: thousands of simple cores working simultaneously on the same problem. It's this fundamental difference that makes the GPU indispensable for training machine-learning models, large-scale inference, 3D rendering or scientific computing.

Buying your own GPU hardware means long investment cycles, capacity that's hard to plan, and rapid obsolescence: an H100 bought today will be outdated in 3 years. The GPU as a Service model gives you on-demand access to the latest generation of NVIDIA hardware, lets you scale with real load, and means you only pay for what you use.

On Hikube, GPUs are hosted in Switzerland and accessible via standard APIs, with no lock-in and no proprietary agents. Whether your workload runs on an isolated VM or in a Kubernetes cluster shared across teams, hardware access stays the same.

svgviewer-output

CPU vs GPU: the right tool for each task

The CPU excels at low-latency sequential processing. The GPU is optimised for massive matrix operations: tensor multiplication, convolutions, attention mechanisms, which are at the heart of deep learning.

svgviewer-output

Guaranteed data sovereignty

Your models, datasets and checkpoints stay in Switzerland. Native GDPR compliance, with no extra configuration.

svgviewer-output

Latest generation, no Capex

L40S, A100, H100 available on demand. No purchase cycle, no depreciation, no server-room management. You access the newest hardware exactly when you need it.

svgviewer-output

Integration into your existing stack

Standard Kubernetes, native YAML, compatible with your existing MLOps tools (Kubeflow, Argo Workflows, MLflow). No pipeline rewriting.

FAQ

Questions about GPU as a Service

The questions teams ask before deploying their first GPU workloads.

Which GPU should I choose for my workload?

General rule: start with the L40S for anything involving inference, development or prototyping - it covers the vast majority of cases at lower cost. Move to the A100 when you train models seriously (fine-tuning, large datasets). Reserve the H100 for truly demanding workloads: multi-billion-parameter LLMs, distributed training across several nodes.

VM or Kubernetes, how do I choose?

If your application isn't containerized, you need full access to the GPU, or you're prototyping: chose a Virtual Machine. It's simpler, faster to set up, and the GPU is entirely dedicated to you.

If you're already orchestrating with Kubernetes, need automatic scaling or want to share GPU resources across several teams: go with Kubernetes. The added complexity is offset by the flexibility.

How do I size CPU/RAM around a GPU?

Plan for 8 to 16 vCPUs per GPU. A u1.2xlarge (8 vCPU, 32 GB RAM) is a good starting point for a single GPU. For 4 H100 GPUs, go up to u1.8xlarge (32 vCPU, 128 GB RAM). Undersizing the CPU creates data pre-processing bottlenecks that cap GPU utilisation.

Do I have to manage the NVIDIA drivers myself?

On VM, yes. You install the drivers via a cloud-init script at first boot. The doc provides the full script, so it's a one-time operation.

On Kubernetes, no. The GPU Operator handles it automatically on GPU nodes. You enable the add-on in the cluster manifest, and the rest is transparent.

Can I share a GPU across several jobs?

In VM mode, no. The GPU is entirely dedicated to the VM. In Kubernetes mode, the GPU Operator can allocate whole GPUs to different pods on the same node, but a pod can't request a fraction of a GPU. To run several small jobs in parallel, the Kubernetes approach with multiple pods on a multi-GPU node is the most efficient.