Deploying a GPU cluster is not just about the hardware. It's about the tooling (or a lack thereof) that helps you get the most out of the cluster.
Operating GPU clusters for our customers and running distributed workloads for internal research help us understand where those tools make the biggest difference. That feedback loop steers our product roadmap, and it is exactly why we know what must be improved before we get a feature request.
In 2026 so far, this loop produced multiple improvements to our Instant clusters: more comprehensive workload management, layered health checks, faster access to container images, audit logging, and flexible provisioning. More additions are on the way.
This post covers what we shipped. Later installments in the series go deeper on each.
Instant clusters, a recap
You can deploy GPU clusters with self-service access: no approvals, quotas, or sales calls.
The latest GPU accelerators are available at up to 144× NVIDIA HGX™ B300, 128× NVIDIA HGX™ B200, and 64× NVIDIA HGX™ H200 per cluster, all on InfiniBand. NVIDIA GB300 NVL72 is also available in configurations from 2× to 18× trays. Each tray contains 4× NVIDIA Blackwell Ultra GPUs and 2× NVIDIA Grace CPUs.
If you need clusters with more GPUs and custom configurations, contact us.
Instant clusters are provisioned in as little as 20 minutes and available with pay-as-you-go contracts, giving you maximum flexibility for rapid deployments.
Slurm or Kubernetes, ready at deployment
Organizations typically standardize on Slurm for HPC-style batch training or Kubernetes for cloud-native orchestration. Verda’s Instant clusters support both. You pick one at deployment, and the cluster arrives with that scheduler configured and validated: Slurm via Slinky, or Kubernetes with Kueue pre-installed.
Slinky
With Slinky, the open-source project from SchedMD (now part of NVIDIA), we turn a Kubernetes GPU cluster into a ready-to-use Slurm environment. We manage the underlying Kubernetes components while preserving the Slurm experience. You keep using sbatch , srun , squeue , sacct , and your existing job scripts, and your workloads retain the core strengths of Slurm: fine-grained hardware control, gang scheduling, enforced QoS, and per-job accounting.
See our docs to get started with Slinky.
Kueue
Native Kubernetes has a scheduler but no queue or quota management out of the box. So we ship our Kubernetes clusters with Kueue pre-installed. You define quotas and priorities; Kueue ensures fair cluster allocation for your distributed AI workloads.
Follow our docs to configure Kueue for job queuing.
GPU cluster health checks
Some GPU and fabric degradations can be silent as your jobs just get slower. And even when something does crash, the dashboard showing a dead node is useful for the postmortem; it does nothing for the twelve hours of training you just lost.
We recently expanded health checks on Instant clusters into continuous, layered validation, consolidated behind a single registry that covers both Slurm and Kubernetes clusters, with one aim: catch problems before your jobs do.
Our health tests include:
- Continuous monitoring: A passive suite that runs on every node next to your workloads at no measurable overhead, watching the signals that precede failures.
- Active node tests: Short per-node diagnostics that run every six hours on idle nodes to catch the early signs of degradation.
- System-level benchmarks: Optional tests that run on idle clusters or nodes.
Every result is judged against a committed baseline per GPU model and topology, and reported as Healthy, Degraded, or Failed. When a node drifts, we get an alert and start an investigation without waiting to get your support ticket.
The benchmark suite and the tuned configurations behind it are used for some of our internal and customer workloads. See our docs for more information about the health checks on Kubernetes and Slinky Instant clusters.
A container registry next to your compute
A cold start on a new GPU cluster usually begins with a wait: pulling container images across the public internet, where rate limits apply and egress is billed.
We host a container registry inside the same high-speed network as your Instant clusters, so images sit next to the GPU nodes reading them. That cuts egress costs on external data traffic and takes the long image pull out of your setup time.
See the container registry documentation for credential and Docker configuration, image operations, and more.
Audit logs: who did what, and when
Recently released audit logs answer the questions of what happened, when it happened, who did it, and which object it affected for each critical event in your project.
Verda records per-project events chronologically across GPU instances and Instant clusters, storage products, SSH keys, cloud API credentials, startup scripts, team membership, billing, and account security. For you, it means traceability and accountability for supported events across your team without extra setups.
Project owners and administrators can view audit logs under Project management in the UI console, or retrieve them via our Public API for ingestion into your own tooling.
Both the console and the API read a 90 day window. Read our docs to extend the retention period.
Deploy a GPU cluster with Terraform, SDK, or API
To deploy and manage Instant clusters on Verda, you can choose from four provisioning methods: UI console, Terraform, SDK, and REST API.
Here is an example using our Python SDK to show how easy it is to deploy GPU clusters on Verda.
First, generate your client credentials and save them as environment variables:
# save the client credentials as environment variables export VERDA_CLIENT_ID=YOUR_ID_HERE export VERDA_CLIENT_SECRET=YOUR_SECRET_HERE
Then create a new Instant cluster with a single SDK call:
import os from verda import VerdaClient client = VerdaClient(os.environ['VERDA_CLIENT_ID'], os.environ['VERDA_CLIENT_SECRET']) cluster = client.clusters.create( cluster_type='16B200', image='ubuntu-24.04-cuda-13.0-cluster', hostname='my-first-verda-cluster', ssh_key_ids=[key.id for key in client.ssh_keys.get()], )
About 20 minutes from now you could be running your first training step. Start with a single SDK call, or a couple of clicks in the UI console. All provisioning methods give you the same GPU cluster:
