What a passed-through GPU changes
With a physical GPU handed to the VM through VFIO (or DDA on Hyper-V), Device Manager shows two entries under Display adapters: the virtual one that was always there and the NVIDIA card with its real name once the datacenter driver is installed. nvidia-smi in a command prompt lists it with driver version and memory. CUDA works. DirectX 12 and OpenGL 4.6 work, because the real driver is present. NVENC works for OBS and FFmpeg. The list of things that break above gets short.
Two things don't change. The VM's CPU, RAM, disk and network are still virtualised and still shared with the host's other tenants, so a passed-through card on a small plan is a fast GPU behind a slow everything else. And RDP doesn't automatically know the card exists, which is the next section.
RDP and the GPU
Remote Desktop has its own rendering and encoding path, and by default on Windows Server it uses the CPU for both even when a GPU is present. That surprises people who've just spent money on a card, so here is precisely what Microsoft ships and what they took away.
RemoteFX vGPU, the old mechanism that gave RDP sessions a share of a host GPU, is gone. Microsoft's KB4570006 states it "was disabled in all applicable Windows platforms in the July 2020 Windows security updates (July 14, 2020)" after a set of remote code execution vulnerabilities (CVE-2020-1036 among them) and removed in the April 2021 updates, with DDA named as the secure replacement. Any guide that tells you to enable RemoteFX is describing a Windows that no longer exists.
What exists now is a pair of group policies that tell the Remote Desktop Session Host to use the GPU. Microsoft documents them for Azure Virtual Desktop in the guide to enabling GPU acceleration, and the same policies apply to any Windows Server session host. In gpedit.msc, under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment:
Use hardware graphics adapters for all Remote Desktop Services sessions set to Enabled makes the session render applications on the GPU and skips the software path. This is the one that makes DirectX and OpenGL apps work at speed inside an RDP session.
Configure H.264/AVC hardware encoding for Remote Desktop Connections set to Enabled moves the encoding of the screen to the GPU's NVENC engine, which takes the encoder off your vCPUs. Prioritize H.264/AVC 444 Graphics mode for Remote Desktop Connections switches the codec to a 4:4:4 chroma profile that keeps text sharp, which matters on a desktop with a lot of small type and matters less for video.
After a gpupdate /force and a fresh RDP session, Microsoft's verification is an event log: Applications and Services Logs > Microsoft > Windows > RemoteDesktopServices-RdpCoreTs > Operational, event ID 170 with the text "AVC hardware encoder enabled: 1", and event ID 162 showing the AVC444 profile. If 170 reports 0, the encoder policy isn't in effect or the driver doesn't expose NVENC to the session.
Even with all three policies on, RDP is still RDP. It runs at a capped frame rate, it drops frames under network jitter, it has input latency of a few tens of milliseconds on a good link, and it's tuned for a desktop with documents on it, not for a 60 fps viewport. For CAD review and a trading platform that's fine. For anything that feels like a game it isn't, and that's the case for the tools in the next section.
Parsec, Sunshine and Moonlight, NICE DCV
The alternatives to RDP for a GPU desktop all work the same way: a host agent captures the display output from the GPU, encodes it with NVENC (or the AMD and Intel equivalents) at 60 frames a second or more, streams it over UDP with a low-latency client and treats input as a first-class stream. Parsec is the commercial one with a free personal tier and a client for everything. Sunshine is the open-source host, whose documentation lists NVENC, AMD AMF, Intel QuickSync and a software encoder, and it pairs with the Moonlight client, which started life as an open-source implementation of NVIDIA's GameStream protocol. NICE DCV is Amazon's, free to use on their instances and licensed elsewhere, and it's the one enterprise CAD shops tend to have already.
The practical difference from RDP: you log in to the console session, not a separate RDP session, so the GPU is driving the actual desktop and every application sees it. That has a consequence for headless servers, and it's the next section.
A caveat I don't have a clean answer for: Sunshine's Windows service can't capture a desktop that no user has logged into at the console, so a reboot leaves you needing a way to log in first. People solve it with an auto-logon plus a lock-screen workaround, or by keeping RDP as the fallback to reach the machine and then disconnecting into the console with tscon. I've used the second one and it works, but I've never found a version of it that felt like anything other than a workaround.
The virtual display problem on a headless GPU
A GPU in a server has no monitor attached. Windows treats a GPU with no display as a compute device: it won't put a desktop on it, and a capture tool like Sunshine or Parsec asking for the display output of that card gets nothing. Datacenter cards like the L4 have no display outputs at all, so this is the default state on every GPU VPS.
Two fixes. The hardware one is a dummy plug, an HDMI or DisplayPort dongle with resistors that convinces the card a monitor is connected; it works on cards that have a port, which means it works on a workstation card in a dedicated server you can ask a technician to fit, and not on an L4 in a VPS. The software one is an IDD (Indirect Display Driver), which Microsoft's driver documentation describes as "a simple user-mode driver model to support monitors that aren't connected to traditional GPU display outputs", with "creating virtual monitors for applications such as virtual desktop environments" listed as a typical scenario. An IDD creates a virtual monitor of whatever resolution and refresh rate you choose, Windows extends the desktop onto it, and because the driver is user-mode (UMDF) it can't take the system down when it misbehaves. Open-source IDDs exist and are what most GPU streaming setups on headless Windows use; Parsec ships its own. Install one, set it as the only active display, then point the streaming host at it.
A flat reference for the state of Device Manager on a working setup: Display adapters shows the NVIDIA card and the hypervisor's virtual adapter; Monitors shows the IDD's virtual monitor (or Generic PnP Monitor for a dummy plug); Display Settings shows one display at the resolution you set. If the virtual adapter is still the one with the desktop on it, the streaming host will capture the CPU-rendered framebuffer and the GPU will sit idle.
Windows licensing on a VPS
You bring the Windows licence. A provider can supply a template with Windows Server installed, but activation is against a licence key you hold, either a retail or volume key or a subscription, and Windows Server's licensing is core-based with a minimum count per VM. Remote Desktop beyond the two administrative sessions needs RDS CALs on top. None of that changes because a GPU is in the VM, and none of it is the provider's to include. The GPU driver itself is free for datacenter and RTX PRO cards; vGPU profiles need an NVIDIA licence, which is one more reason passthrough is the simpler product.
The connection basics, client settings and the first login on a fresh Windows VPS are in the knowledge base on connecting to your Windows VPS using RDP. LumaDock's Windows VPS hosting line, for reference, is the plain case: a KVM VM on NVMe with the virtual display adapter described at the top of this article. A card in the VM is the GPU line's job.
Use cases that fit and use cases providers ban
The legitimate list is long. Render nodes for Blender, V-Ray or Unreal, driven headless by a farm manager, where nobody looks at a desktop at all. CUDA on Windows for teams whose toolchain is Windows-only. Trading and charting platforms whose GUIs redraw hundreds of series in real time and stutter on WARP; the earlier piece on forex VPS hosting for MetaTrader covers the non-GPU version of that setup, and a card makes the difference for the heavier platforms. A remote workstation for CAD, video or DAW work, used over Parsec or DCV by one person at a time. Game servers that need a GPU, which is a smaller set than people think, since most dedicated server binaries are headless, but a few (some Unreal Engine servers with rendering enabled, simulation-heavy titles) do.
Then there's the list that gets accounts closed. Running a game client on a server to bot, farm, multi-box or bypass anti-cheat is prohibited in the terms of every hosting provider I've read, and the game publishers' terms on top. Providers detect it and terminate without much discussion, the anti-cheat vendors flag datacenter IP ranges, and the whole thing ends with a banned game account and a banned hosting account. A GPU VPS is a fine place to host a game server for other people to join, and a bad place to be a player on, because both the hosting terms and the anti-cheat vendors treat a datacenter address as a red flag.
The same goes for cryptocurrency mining on a GPU VPS, which most acceptable-use policies exclude explicitly. A monthly GPU plan is priced for inference and desktops, and a card pegged at 100% for weeks for hashing is the kind of thing a provider notices within a day.
What to verify on day one
Device Manager showing the real card under Display adapters. nvidia-smi printing it. A quick dxdiag, whose Display tab should name the NVIDIA card with a hardware feature level of 12_x and not "Microsoft Basic Render Driver". If RDP is your daily client, the three group policies from above and event 170 with a 1 in it. If it isn't, an IDD or dummy plug, the streaming host pointed at it, and a test from the client you'll use in practice. And one measurement I'd take before deciding the card is slow: run the same DirectX or CUDA benchmark once over RDP and once over Parsec. On the VMs I've set up the gap was large enough to make people think the GPU had stopped working when they went back to RDP.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
