Remote desktop GPU passthrough explained

A virtual machine normally sees an emulated display adapter — a software device with no real silicon behind it. Everything the desktop draws is rendered by the CPU. That is adequate for text and window compositing, and hopeless for anything that expects a real graphics pipeline.

GPU passthrough changes the wiring. The hypervisor detaches a physical graphics device from the host and maps it directly into the guest, usually over the platform's IO memory management unit. The guest OS enumerates a genuine GPU, loads the vendor driver, and runs hardware-accelerated work at close to bare-metal throughput.

• Full passthrough: one physical GPU is dedicated to one virtual machine. Best performance and full video memory, vendor drivers work unmodified, and nothing is shared. Also the most expensive per seat, because the card is idle whenever that one session is idle.
• vGPU (mediated / sliced): the hypervisor partitions one physical card into several scheduled virtual devices, each with a fixed slice of video memory. Several desktops share one card, which cuts cost per seat sharply at the price of a lower peak ceiling and time-sliced scheduling.
• API remoting (virtual GL): no device is passed through at all. Graphics API calls made inside the guest are forwarded to a GPU elsewhere and the results are shipped back. Cheapest and most portable, but it breaks on applications that probe for a hardware device or use APIs the shim does not cover.

The practical ordering is: API remoting for light acceleration, vGPU for most professional workloads, full passthrough for sustained heavy rendering or training runs where a whole card is genuinely saturated.

The obvious win is application performance — viewport frame rates in a 3D scene, timeline scrubbing in an editor, tensor throughput in a training loop. The less obvious win, and the one that matters most for a streamed desktop, is the encoder.

• Hardware encode: modern GPUs carry a dedicated video encode block. It compresses each frame in roughly 3-6 ms, against 10-20 ms for a software encoder at comparable quality.
• CPU relief: moving encode off the CPU returns those cores to the applications, which removes the stutter you get when a busy desktop and a busy encoder compete for the same cores.
• Higher sustainable resolution: hardware encode makes 4K at 60 frames per second practical, where software encode usually forces a drop in resolution or frame rate to hold latency.

In terms of the pipeline described in the remote desktop latency guide, hardware encode removes roughly 10 ms from the fixed pipeline depth. That is not the largest term — geographic distance still is — but it is one of the few you can buy outright.

A GPU is the single most expensive attribute you can attach to a desktop template, so it is worth being honest about whether the workload needs one. These do not:

• Browsers, email, chat and document work — modern desktop compositors handle these on CPU without visible cost.
• Code editing, terminals, builds and test runs — these are CPU and IO bound; more cores beat a graphics card every time.
• Data work in spreadsheets, notebooks and SQL clients, unless the notebook is training models rather than querying them.
• Video playback and conferencing — CPU decode is sufficient at typical meeting resolutions.

The clean pattern is to keep your everyday template CPU-only and attach a GPU template only for the hours you actually render. With per-second metering that is a genuine saving rather than a bookkeeping exercise.

A GPU-backed session runs several times the hourly cost of a CPU-only one, and the accelerated instance dominates that figure — storage, transport and control plane are rounding errors beside it. Three things control the bill:

• Sharing model: a vGPU slice costs a fraction of a dedicated card. If your peak workload fits inside a slice, take the slice.
• Hours attached, not hours owned: a metered cloud desktop bills the GPU only while the session runs, which is the whole argument against buying workstations that sit dark overnight.
• Suspend discipline: a suspended session releases the accelerator. Auto-suspend on idle is the difference between paying for render hours and paying for calendar hours.

See pricing for current per-second rates by template class.

• Driver licensing: vGPU deployments generally require a vendor software licence in addition to the hardware. This is handled at the platform layer, but it is why vGPU seats are not simply priced as a fraction of a card.
• Snapshot and migration limits: a machine with a device passed through cannot always be live-migrated or snapshotted the way a plain instance can. This is why workspace state continuity should live at the application layer rather than depend on machine snapshots.
• Application device probes: some licensed applications check for a specific device or a stable device ID. Sliced and remoted GPUs occasionally fail those probes where a full passthrough card passes.
• Region availability: accelerated instance types are stocked in fewer regions than general-purpose ones, so the nearest GPU region may be further away than your nearest CPU region — and that distance costs you latency.

Templates declare their acceleration class, and the session broker places each session on an instance type that satisfies it in the nearest region that stocks it. Sessions inherit hardware encode automatically when the placement has an encode block, so you do not configure the codec by hand.

Because workspace state is captured at the application layer by Ghost Sync rather than by machine snapshots, you can end a GPU session, release the accelerator, and resume the same working state later on a CPU-only template — which is the cheapest way to keep a render workflow open across a week.

What is GPU passthrough on a remote desktop?

GPU passthrough gives a virtual machine direct access to a physical graphics card, so the guest OS sees a real GPU and loads the vendor driver. The desktop can then run hardware-accelerated 3D, video encoding and GPU compute at close to bare-metal speed instead of falling back to CPU software rendering.

Do I need a GPU for a cloud desktop?

For browsing, office work, code editing and terminals, no — a modern CPU handles compositing fine and a GPU mostly adds cost. You need one for 3D and CAD, GPU-accelerated video editing and colour grading, machine-learning work, and any workload where the application refuses to start without a hardware device.

Does a GPU make a remote desktop feel faster?

Indirectly, yes. Its biggest latency benefit is hardware video encoding: an on-GPU encoder compresses each frame in roughly 3-6 ms versus 10-20 ms in software, so it shaves real time off input-to-photon latency and frees CPU headroom for the applications themselves.

What is the difference between vGPU and full passthrough?

Full passthrough dedicates an entire physical GPU to one virtual machine — maximum performance, no sharing. vGPU slices one physical card into several scheduled virtual devices so multiple desktops share it, which is far cheaper per seat but caps each seat's peak throughput and video memory.

How much does a GPU cloud desktop cost?

A GPU-backed session typically costs several times a CPU-only session per hour, because the underlying accelerated instance is the dominant cost term. Metered per-second billing keeps this manageable: you attach a GPU template only for the hours you actually render, rather than paying for an idle card all month.

Send the application list and a rough idea of scene or dataset size to hello@sisidesk.com and we will suggest a template class and the expected hourly cost before you commit to anything.