Share one physical GPU across every virtual machine on your Proxmox cluster — on the consumer cards you already own, from any vendor, with no per-GPU licence. A Proxmox driver that makes your hypervisor AI-ready and drives AI serving or GPU security workloads, now with our own GGUF-compatible inference engine built in, plus a live web manager that shows real GPU & CPU telemetry — per model, per node, in real time.
This is the ComputeEngine manager driving a real Proxmox cluster. We task an AI node with a language model and watch one consumer iGPU light up — live GPU %, VRAM, and the exact model that's resident, per node.
Splitting one card across many virtual machines is a solved problem — if you can stomach the licence tax and the hardware it demands. ComputeEngine was built because we couldn't.
The incumbent charges $10–250 per user, per year, forever just to slice a card you already bought. Stop paying and the GPU stops working.
Their sharing refuses to run on the consumer GPUs in your rack. You're pushed into one vendor and expensive datacenter-only cards to do something your hardware can already do.
The free alternative bolts one whole GPU to one VM. Every other machine on the host gets nothing — an expensive card sitting 90% idle.
The web manager isn't a status page — it's a live map of your GPU fabric. Physical GPUs flow into compute units flow into model endpoints, and the whole graph lights up in real time as work moves through it.
Real GPU engine %, VRAM used, and host-core load streamed over WebSocket — sub-second, straight from the nodes. No agents to babysit, no polling lag.
GPU and CPU sit side by side on every node. The connector to the busy tile lights, so you see at a glance whether a job landed on the accelerator or fell back to cores.
Every VM's model endpoints are listed in-place — and the one that's actually resident and serving glows, while the rest stay dark. The fleet's real state, at a glance.
Watch a single physical card feed multiple compute units. Dedicated or pooled, the topology is drawn from live data — not a diagram you have to keep up to date.
Point the manager at any node and pull an Ollama model straight from the dashboard. It lands on the node, loads into the vGPU, and appears in the graph.
The manager carries its own payload and can push-install ComputeEngine to a peer node over SSH — binaries, scripts, GPU preflight and all — from one place.
ComputeEngine turns a single physical GPU into a shared resource for the virtual machines on your Proxmox cluster — so your homelab or small fleet can run local LLMs, AI inference, and GPU-accelerated desktops without buying a card per VM or renting one in the cloud.
The same shared-GPU fabric now drives more than language models. Tell ComputeEngine the job — and it places the work where it runs best, on one box or a whole fleet.
Local LLMs and inference across the cluster, served from the GPUs you already own — no cloud bill, no per-token meter, no data leaving your rack.
Aim the same fabric at GPU-accelerated password auditing and recovery. Turn an old mining rig's stack of cards into a full-tilt recovery farm — every card working, at native speed.
Many users at once: each request lands on the least-busy GPU automatically, and every conversation stays pinned to the node that already holds its context — low latency, nothing sitting idle.
A model too large for a single GPU? Combine several into one and the fabric spreads it. Or run a full copy per node and scale users outward. One GPU, many GPUs, or many nodes — your call.
Tell it the workload and the model, and ComputeEngine recommends where it should run — which card, how much memory, dedicated or shared — then refuses to overload a card that can't fit the job.
Yesterday's crypto-mining cards are perfect recovery workhorses. ComputeEngine puts an idle rack of consumer GPUs back to work — no rip-and-replace, no datacenter upgrade.
Whole VMs aren't the only way to share a card. Point the same GPU straight into a lightweight container — LXC or Docker — with one command, and it runs at native speed with no virtualization tax.
A container reaches the card directly — nothing sits between your workload and the silicon. Ideal for a recovery farm or a batch job that wants every last cycle of the GPU.
Some cards are too old for the full virtual-machine path — but drop them into a container and they run clean. That ex-mining rack you'd written off goes straight back to work.
A VM and a container sharing the same card are weighed together, on one scale. Give each a class and the busy card is split between them fairly — neither side ignores the other.
One command binds a card into a container and installs everything it needs inside — then it shows up in the same live map, and the same priority view, as every VM on the host.
When several machines and containers share one GPU and all want it at once, ComputeEngine doesn't split it blindly down the middle. Give each one a class — and the card's time is shared by weight, so the work that matters wins the moment things get busy.
Your interactive appliance stays snappy while a batch job grinds behind it — and when the appliance goes quiet, that batch job soaks up the whole idle card. No starved foreground, no wasted silicon. Set it in one flag; retune it live, no downtime.
Setting a priority is a promise. ComputeEngine keeps you honest about it — it measures what each machine actually pulls from the card, live, and holds it up against what you asked for. So a busy GPU proves it's being shared the way you set it, and nothing quietly starves or hogs more than its share.
Real per-machine usage, from any card, any vendor — on screen as a live readout, or as a clean data feed your own dashboards can graph. No guessing which VM is eating the GPU, no black box.
A card too small for the model you want isn't the end of it. ComputeEngine tiers the model — the hot, active part stays in fast GPU memory, the rest sits in system memory — so it fits and runs where it otherwise couldn't. And it's honest about it: it tells you up front whether a model will run smoothly, run only in batch, or simply won't fit well — before you waste a load.
Keep the part of the model that's working right now in fast GPU memory and park the rest in system memory. A model larger than your card fits — and the biggest, sparsest models gain the most.
When several models share one card, the important one keeps its seat in GPU memory and the background one spills to system memory first — the same class you set for GPU time now decides who holds the fast memory.
No thrashing surprises. ComputeEngine works out the split ahead of time and calls it straight — runs great, batch-only, or won't fit — so you commit a card to a model that will actually perform.
ComputeEngine no longer borrows someone else's inference runtime. Demerzel is our own model-running kernel, written from nothing in Rust — and it is running today, in the product, on real models. It reads the same GGUF model files you already have, so nothing you've downloaded needs converting, re‑quantising or re‑packing.
No wrapper around someone else's binary, no Python in the path, no foreign runtime we don't control. The whole forward pass — weights, attention, cache, sampling — is our own code, so its future is ours to steer rather than something we inherit.
All ten GGUF compression formats decode bit‑for‑bit against our own reference vectors — not "close enough", identical. A model runs the way its author quantised it, and we can prove it rather than assert it.
Split a model across boxes: the first slice of layers here, the next slice there, joined over ordinary networking. Each machine holds only its own piece, and several conversations run at once against the same loaded slice.
Models are mapped rather than read, so a large file is ready in moments and only the parts actually being used occupy memory. Many sessions on one machine share a single copy of the weights instead of each paying for their own.
Where each slice lands is worked out from measured free GPU memory across the fleet — including room for the conversation to grow — keeping consecutive layers on the same box wherever it can, so the network is crossed as few times as possible.
This is the first working generation of the kernel. It runs real models correctly and it runs them distributed — raw single‑machine speed is the next thing we're coming for, and we'd rather tell you that than dress it up. More lands as we go.
Some jobs a GPU finishes in a fraction of the time — heavy math, hashing, big batch crunching. ComputeEngine spots those and runs them on the GPU instead of grinding the CPU, then hands the result back. Everything else stays on the CPU. No guessing, and for the common libraries, nothing to rewrite.
Parallel-heavy work goes to the GPU; everyday work stays on the CPU — decided job by job, not once at boot. Your VM just runs faster where it counts.
It weighs the move before making it. If shifting a job to the GPU would cost more than it saves, it doesn't bother — no slower-on-the-GPU surprises, ever.
Local card slammed? A job can run on another node's GPU and come back. The whole cluster is one pool of compute, not a rack of islands.
Point ComputeEngine at a host and it detects the GPU — AMD, NVIDIA or Intel — and sets that machine up correctly on its own. A self-healing preflight even reclaims a card that was locked to a single VM. No vendor-specific dance, no driver archaeology.
A lightweight piece on every host, and one web app to rule them all.
A Proxmox driver that makes your hypervisor ready for the AI world. Install it on each host and that machine's GPU becomes a shared resource for its VMs — a lightweight vGPU per guest, no datacenter card, no licence, no cloud. A self-healing preflight even reclaims a card that was locked to a single VM.
Run the entire fleet from a web app. See live GPU/CPU telemetry, watch which model is resident on which node, pull new models, and provision fresh nodes over SSH — all from one dashboard, no command-line archaeology, no per-host fiddling.
There is a great deal under ComputeEngine that does not belong on a public page: how the vMPU brokers work across CPU and GPU, how AGNUS holds a model larger than the card, how Demerzel splits one model across machines, and the measured reasons a 192-core server is not the AI powerhouse everyone assumes. That brief is available to commercial partners under NDA, behind an authenticator gate.
Business licence required. Access is by invitation and every entry is logged.
Build once, push to your nodes over SSH, and bring up the manager. The install lays everything out under /opt/ce and symlinks the CLIs — three commands and you're sharing silicon.
# 1 · push the driver to a node (free the GPU, enable sharing, run the manager) $ SSHPASS=… PREFLIGHT=1 WITH_MANAGER=1 \ scripts/install/ce-node-deploy.sh 10.0.110.246 10.0.110.247 10.0.110.248 ✓ /opt/ce laid out · CLIs symlinked · GPU freed · manager live on :8443 # 2 · (or) let the manager provision a peer node for you $ ce-orchestrator install-node --host 10.0.110.248 --user root --preflight # 3 · stamp a GPU-accelerated AI node (Ubuntu + Ollama on the shared GPU) $ VRAM=4G ./ce-ai-node.sh 9101 ✓ ai-node-9101 up · vGPU attached · Ollama serving
One push over SSH lands the binaries, self-heals the GPU (reclaims a card locked to one VM), and brings up the GPU-sharing stack.
WITH_MANAGER=1 runs the orchestrator as a service. Open :8443 and your live fabric is there.
Stamp reproducible GPU VMs that run local LLMs on the shared card — one command per node, cluster-wide.
Sharing a GPU across virtual machines isn't new — paying a per-user licence and buying datacenter-only cards to do it is the catch. No one else gives you free + consumer cards + any vendor + native VM sharing at once.
| Solution | Licence cost | Shares 1 GPU across VMs |
Consumer cards |
Any vendor |
VM / Proxmox-native |
Live migration |
Audience |
|---|---|---|---|---|---|---|---|
| NVIDIA vGPU / GRID | $10–250 / user / yr | ✓ | ✗ | ✗ | ~ | ✓ | Enterprise |
| VMware vSphere vGPU | VMware + NVIDIA fees | ✓ | ✗ | ✗ | ✗ | ✓ | Enterprise |
| VMware Bitfusion | Discontinued (EoL 2025) | — | — | ✗ | ✗ | — | — (dead) |
| HAMi | Free (open source) | ✓ (containers) | ✓ | ✓ | ✗ | ✗ | Kubernetes / AI |
| KAI Scheduler (run:ai) | Free (open source) | ✓ (containers) | ✓ | ~ | ✗ | ✗ | Kubernetes / AI |
| GPU passthrough (VFIO) | Free | ✗ 1 GPU = 1 VM | ✓ | ✓ | ✓ | ✗ | Homelab |
| ComputeEngine | No per-GPU licence | ✓ | ✓ | ✓ | ✓ | v2 ☉ | Homelab / SMB |
✓ full · ~ partial / conditional · ✗ not supported · — n/a · v2 ☉ on the roadmap. Live migration (moving a running, GPU-backed VM between nodes with no downtime) is planned for ComputeEngine v2. Competitor data from vendor primary sources, 2026 (NVIDIA vGPU licensing & pricing guide, pve.proxmox.com vGPU wiki, project-hami.io, developer.nvidia.com KAI, Broadcom/VMware Bitfusion end-of-life notices). NVIDIA vGPU is a per-concurrent-user subscription ($10 vApps / $50 vPC / $250 vWS per user/yr) on datacenter-only cards; Bitfusion reached end of support May 2025.
No per-GPU licence, no datacenter-card tax, built for the hardware you already run. Grab it from your portal, point the manager at your nodes, and start sharing.