How to Share an NVIDIA GPU Across Multiple Proxmox LXC Containers

Sharing one NVIDIA GPU across several Proxmox LXC containers lets you run AI inference, transcoding, and other GPU jobs on lighter and faster containers instead of dedicating a whole GPU to a single virtual machine. This guide walks through the full setup process.

A modern NVIDIA GPU can do more work than most home labs or small businesses actually need. If you put a Plex or Jellyfin transcoder, a small AI inference tool, and an image-generation app each in their own VM with GPU passthrough, most of the GPU sits idle. This happens because VFIO passthrough gives the whole GPU to just one VM at a time.

Sharing the same GPU across several Proxmox LXC containers fixes this. Containers use the host's kernel and NVIDIA driver together, so they don't each need their own separate GPU.

This is not the same as the exclusive VFIO GPU passthrough in our Proxmox NVIDIA GPU passthrough guide. That method gives the whole GPU to one VM and takes it away from the host. Use that method when one guest needs the entire card on its own, like a Windows gaming VM or a job that needs full hardware isolation.

Use the method in this guide when you have several smaller jobs, like AI inference and video transcoding, that can take turns using the same GPU without you having to reboot or reassign hardware.

Before you start, you must confirm the following on your Proxmox host:

• A Proxmox VE 9.2 host or Proxmox VE 8.x with a recent kernel. Run pveversion to confirm.
• An NVIDIA GPU that works with the driver version you plan to install. Consumer GeForce cards support CUDA and NVENC/NVDEC, but they limit how many NVENC sessions can run at once.
• Root or sudo access to the Proxmox shell. You can open this directly, or through the Shell button in the web UI on your node.
• At least one LXC container template already downloaded. For example, Ubuntu 24.04 or Debian 13, under local > CT Templates.

Note: Because this guide focuses on sharing a GPU among Proxmox LXC containers rather than passing it to a VM, everything below happens at the container level using the host's own driver, not a hypervisor-level VFIO binding.

The GPU driver's kernel module always lives on the Proxmox host. Containers only need matching userspace libraries later, not their own kernel module.

First, stop the open-source nouveau driver from claiming the card:

After the reboot, install build tools and the matching kernel headers so the driver can build its DKMS module:

Then, download the current NVIDIA Linux driver. Before running this, check NVIDIA's driver download page for the latest driver version:

The --dkms flag matters. It tells DKMS to rebuild the driver automatically after a Proxmox kernel update. If you skip this flag, GPU sharing breaks the next time the kernel updates. 

Confirm the host sees the card:

You should see the GPU name, driver version, and CUDA version in the output. Write down the exact driver version. It must match on the host and inside every container that shares the GPU.

The host driver exposes the GPU through device files under /dev. List them with:

You'll typically see /dev/nvidia0 for the GPU itself, /dev/nvidiactl for the control device, and /dev/nvidia-uvm plus /dev/nvidia-uvm-tools, which is needed for CUDA. You may also see /dev/nvidia-modeset.

Write down the major and minor numbers shown in the listing. These numbers are specific to your own host and kernel, so don't copy numbers from another tutorial; always check your own output.

At this point, you must create a new container from the Proxmox shell or the web UI. Unprivileged containers are the default in Proxmox, and the safer choice for GPU workloads. They map the container's root user to a normal, unprivileged user on the host:

Adjust the storage name, template, and network bridge to match your own host setup. Don't start the container yet. The GPU settings still need to go into its configuration file first.

Proxmox VE 8.2 and later, including Proxmox VE 9.2, support native device passthrough entries directly in the container config. Edit the container's config file on the host:

Add one devN: line per device node you listed in Step 2:

The mode=0666 setting makes the device usable inside an unprivileged container, with no extra idmap work needed. It gives read and write access to any user, while the container's cgroup still controls whether the device can be reached at all.

Note: If your Proxmox version doesn't support the devN: syntax, or you need extra nodes like /dev/nvidia-caps/nvidia-cap1 for MIG-capable cards, use the older method instead. Add these raw LXC lines to the same file, using the major numbers from your own ls -la /dev/nvidia* output:

Then, start the container with:

Inside the container, you must install the same NVIDIA driver version you used on the host.

Tell the installer to skip the kernel module. The container already uses the host's kernel module, through the device nodes you mounted earlier:

Version match matters more than anything else in this setup. If the host runs driver 580.178.04, the container must use the same 580.178.04 package, not a newer or older one. Otherwise, nvidia-smi will show a version mismatch and won't talk to the GPU.

Now confirm that the container can see the GPU:

This should print the same GPU name and driver version as the host. For CUDA workloads, install the CUDA toolkit that matches your driver's supported CUDA version and run a quick test:

For media workloads, you can test hardware encode and decode with ffmpeg:

If both commands run without a "no NVENC capable devices found" or "CUDA error" message, the setup worked. The GPU is now shared into this container, and it's ready to run real AI inference or transcoding jobs.

Repeat Steps 3 to 6 for each new container, using a new container ID and the same /dev/nvidia* device nodes. The GPU driver, not the hypervisor, controls access, so multiple containers can use the GPU at once; unlike VFIO passthrough, which locks it to one VM.

Keep two practical limits in mind when running several containers this way. GeForce cards cap concurrent NVENC sessions, usually at three; extra jobs queue or fail. And CUDA workloads share the same compute and memory, so heavy jobs compete for speed rather than getting a guaranteed share, unless you add NVIDIA MPS or time-slicing.

Tips: If you want to skip the driver matching and cgroup setup altogether, PerLod's GPU dedicated servers give you a ready NVIDIA host to build this multi-container setup on. You get to run several containerized AI or media jobs on one GPU host, without managing the bare-metal hardware yourself.

Sharing an NVIDIA GPU across several Proxmox LXC containers turns one card into shared infrastructure for lighter AI and media jobs, instead of locking it to a single VM like VFIO passthrough does.

It depends on installing a DKMS-backed driver on the host, mounting the same device nodes with matching permissions into each container, and keeping the driver version identical everywhere. 

Follow these three steps correctly, and the GPU keeps working through Proxmox updates and kernel changes.