One H100, on denv’s stack.
Two separate tests, both one request at a time. The write-ups have the prompts, the settings and what the numbers do not say.
One model on one GPU type, ready to deploy.
Each recipe is tested on its GPU type before it enters the catalog. It is pinned by image digest and weights revision, so what serves is what was tested. One endpoint covers every provider you deploy to. Recipe pages for Llama, Qwen and DeepSeek. Engines: vLLM and SGLang.
Fast by default.
- Engine, version, precision and engine arguments tuned for the GPU type
- llm-d routing that knows each replica’s cache and load
- Prefill/decode split and wide expert parallelism for large models
- Weights cached at each site, so new replicas start sooner
- Autoscaling targets set for the model
Dashboards from the first request.
- Time to first token, throughput and queue depth
- KV-cache use and GPU health per replica
- Default alerts for the model, on as soon as it deploys
Keeps serving when a GPU fails.
- A GPU repair policy for every node it runs on
- A disruption budget, so repairs never take all replicas at once
- Traffic moves to healthy replicas, at any provider
Run on the clouds you use, or on your own servers.
You pay the provider directly. denv does not sell or resell GPUs. See every provider with its GPU types and regions, or read how one cluster spans them.
Lambda
AvailableYour own Lambda API key. denv launches and terminates machines in your account.
Nebius AI Cloud
AvailableYour own Nebius service account key. denv launches and terminates machines in your project.
Amazon EC2
AvailableYour own AWS credentials. denv launches and terminates instances in your account.
Hetzner dedicated GPU servers
AvailableRun the one-line join on each server. It connects out to your cluster.
Your own servers (bare metal)
AvailableRun the one-line join on each server. No inbound ports and no VPN.
GPU aggregators
ComingYour own API key, once a driver passes conformance.
Have GPUs? List them on denv.
Become a providerGPUs fail. Your endpoint keeps answering.
Health checks and auto-repair run the same way at every provider and on your own servers. If a GPU or a whole site stops answering, traffic fails over to healthy replicas. How repair works and how failover works.
01Detect
Health checks watch XID errors, ECC and NVLink faults, heat throttling and silent nodes.
02Contain
The node takes no new work. Running replicas drain within the recipe’s disruption budget.
03Recover
Multi-provider failover: traffic moves to healthy replicas, at the same provider or another one.
04Repair
Auto-repair walks GPU reset, then reboot, then GPU driver reinstall. If it keeps failing, denv replaces the machine, or opens a ticket for servers you own.
05Prove
Every step is recorded. Each month you get a signed uptime report per GPU and per provider.
03:12:04 XID 79 · GPU fell off the bus detect03:12:05 cordon · no new replicas contain03:12:06 traffic → lambda-us replicas recover03:13:02 fatal error · skip reset · replace repair03:21:47 gpu-22 joined · GPU test passed ✓counted in this month’s uptime report prove
Like EKS on top of EC2, but for inference.
GPU clouds become providers on denv. Underneath is real Kubernetes: you get a kubeconfig, and kubectl and Helm work. denv adds the recipe, the endpoint, GPU driver management, health checks and failover across providers. NVIDIA MIG and Kubernetes DRA share a GPU when the model does not need the whole card.
Your tools work unchanged.
- Every deployment runs on a real Kubernetes cluster
- You get a kubeconfig. kubectl and Helm work as usual
- GPU driver install on join, and driver reinstall when repair asks for it
- Leave any time: your manifests run on any other cluster
Jobs that survive a bad node.
- Standard Kubernetes Jobs, queued with Kueue
- Quotas and priorities per team
- Pods on a failed node requeue at any provider you allow
- Jobs resume from checkpoints in a mounted bucket
$ kubectl get nodes -L denv.ai/site,denv.ai/gpu-typeNAME STATUS ROLES AGE VERSION SITE GPU-TYPEgpu-07 Ready <none> 12d v1.31.4 nebius-eu h100-80gbgpu-22 Ready <none> 9m v1.31.4 nebius-eu h100-80gbgpu-31 Ready <none> 6d v1.31.4 lambda-us h100-80gbdc-r2-04 Ready <none> 41d v1.31.4 own-dc l40s-48gb$ kubectl get envNAME PROFILE GPU CURRENT PHASE READY AGEchat-prod standard h100-80gb chat-prod-v3 ready 4 12dembed-prod simple l40s-48gb embed-prod-v1 ready 2 41d$
Run it on denv, or in your own account.
Both run the same software. Your GPU bill stays between you and your provider. See self-hosted inference and pricing.
denv runs the control plane.
- A dedicated control plane for each cluster
- denv runs, upgrades and monitors it
- Paid per cluster plus per GPU under management
Install it on any Kubernetes you run.
- One Helm chart on EKS, GKE, OpenShift or k3s
- Runs air-gapped, with no call home
- Licensed per GPU under management
For a license, write to anup@denv.ai
List your GPUs where teams deploy models.
For neoclouds, data centers, aggregators and anyone else with GPUs.
- What it takes
An API denv can launch and terminate machines with, or machines that run the one-line join. Then a conformance run on a test pool.
- What you get
Customers who want their models to keep serving across more than one provider.
- Who bills
You do. Customers pay you directly. denv does not sell or resell GPUs.
Set it up from Claude Code or Cursor.
denv will ship an MCP server. Your coding agent can deploy a model, add GPUs and explain an incident. See what it will offer. The workload notes, with only the numbers we have published, are coding agents and computer use.
Ask
Tell your agent to deploy a model on your GPU server with denv. It checks that a recipe fits the GPU.
Approve
You sign in and approve once. The agent gets a short-lived token for one cluster, with a spend limit.
Watch
The agent joins the server, deploys the recipe and sends a test request. Anything that launches machines shows a plan and waits for you.
Questions teams ask first.
Which models can I deploy?
Open-weight models served with vLLM or SGLang, from a recipe: one model on one GPU type. Llama, Qwen, DeepSeek and others are the usual starting points. If a recipe is not in the catalog yet, write to us or bring your own weights. See the recipe pages and how to run LLM inference.
What is a recipe?
A tested bundle for one model on one GPU type. It sets the engine and version, precision, engine arguments, serving profile and autoscaling targets. It ships dashboards and default alerts, and the repair policy and disruption budget that keep it serving. It is pinned by image digest and weights revision, and tested on its GPU type before it serves.
Can I bring my own model or config?
Yes. You can write a custom recipe with your own weights or engine settings. denv tests it on your GPU type before it serves traffic.
Which GPUs?
NVIDIA GPUs from the providers in the catalog: A10, A10G, L4, L40S, A100, H100, H200 and B200, depending on the provider. Your own servers work with any NVIDIA GPU. See H100, H200, B200 and the providers page.
Can I use my own servers?
Yes. Run one command on each server, on-prem, in a colo, at Hetzner or anywhere with an NVIDIA GPU. It connects out to your cluster, so you open no inbound ports and set up no VPN. See self-hosted inference and Hetzner.
Who bills me for the GPUs?
The provider, directly, at its own prices. You use your own account with them. denv never sells or resells GPUs, and does not sell per-token inference.
I have GPUs. Can I offer them on denv?
Yes. GPU clouds become providers on denv. denv needs an API it can launch and terminate your machines with, or machines that run the one-line join. After a conformance run, your GPUs appear in the catalog. Customers pay you directly. See how to list GPUs.
What happens when a GPU fails?
Health checks catch XID errors, ECC and NVLink faults, heat and silent nodes. denv cordons the node, drains it within the disruption budget, fails traffic over to healthy replicas (including another provider), then auto-repairs: GPU reset, reboot, driver reinstall, or replace the machine. See GPU failover and GPU repair.
How fast is it?
On one public test, one H100 on denv’s stack placed 3rd of 23 providers serving Qwen, and 2.6–3.9× a typical provider in that test. A separate run on one H100 went from 50.8 to 213 tokens per second. One day, one request at a time. The benchmark and the 213 tok/s write-up have the method and the caveats.
How does pricing work?
A platform fee per cluster plus a fee per GPU under management, paid from day one. There is no free tier. Self-hosted is licensed per GPU. Your GPU bill stays with the provider. For rates, write to anup@denv.ai. See pricing.
Where does my data live?
Prompts, outputs and model weights stay on the machines you run, at your providers or on your own servers. denv stores cluster state, metrics and repair records. To keep those in your account too, self-host it.
How far along is it?
Early. The docs mark what is coming soon, including the MCP server. Write to us and we will show you what runs today.