How to use your gaming PC’s GPU from your laptop for batch jobs

Why the jobs go to the PC

A desktop graphics card does its work on data in its own memory, fed over a bus that is many times faster than any home network. There are research projects that forward GPU calls over TCP, and libraries that keep PyTorch code on a laptop and send tensor operations to a remote NVIDIA machine, but for batch jobs the plain answer is better: copy the inputs once, run the whole job on the PC, copy the results back.

On a Mac this is the only way to use an NVIDIA card. macOS has no CUDA, and Apple silicon Macs don’t take external NVIDIA GPUs. The Mac’s own GPU works through Metal (PyTorch’s mps device, MLX, llama.cpp), which is often enough for small jobs and is a good reason to send only the big ones away.

Step 1: make the PC reachable over SSH

On Windows 10 and 11, the OpenSSH server is an optional feature. In an administrator PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

Then from the laptop, ssh alice@workstation should give you a Windows prompt. Use a key rather than a password (ssh-copy-id doesn’t exist on Windows; append the laptop’s public key to C:\Users\alice\.ssh\authorized_keys, or for an administrator account to C:\ProgramData\ssh\administrators_authorized_keys).

Away from home, a mesh VPN such as Tailscale or ZeroTier gives both computers a stable private address without opening a port on your router.

Step 2: the GPU stack on the PC

Two common setups:

• WSL 2 with CUDA. Install the current NVIDIA driver for Windows only; inside WSL the GPU appears through it, and NVIDIA’s guide warns against installing a Linux display driver in the distribution. nvidia-smi inside WSL should show the card. Then install PyTorch or your framework for Linux as usual. From the laptop, run commands in WSL with ssh alice@workstation wsl -e bash -lc "…".
• Native Windows Python. PyTorch and most frameworks ship CUDA builds for Windows. Simpler to start with, and less like the Linux servers the tutorials assume.

Check what the card has free before you size a job, since a game or the desktop also uses its memory:

nvidia-smi --query-gpu=name,memory.used,memory.total --format=csv

Step 3: send a job and get the result

The simplest loop is copy, run, copy back:

scp -r data/ alice@workstation:work/data/
ssh alice@workstation 'wsl -e bash -lc "cd /mnt/c/Users/alice/work && python3 train.py --config run7.yaml > run7.log 2>&1"'
scp alice@workstation:work/out/run7.pt results/

The quoting matters: the SSH command first reaches the Windows shell, so the part meant for Linux goes in double quotes. scp copies into the Windows home folder, which WSL sees under /mnt/c/Users/alice; for large datasets, keeping them inside the WSL file system is faster. For native Windows Python, drop the wsl -e bash -lc and use Windows paths.

The weak spot is the session. The job above lives as long as that SSH connection, so the laptop has to stay awake and connected, and a job left running in the background on Windows, or in WSL, is not guaranteed to outlive the session that started it. For runs of many hours, start them at the PC itself (or over Remote Desktop) in a terminal you leave open, and use SSH to check the log. On a Linux box, tmux or nohup keeps a job going after you disconnect. For interactive work, Jupyter on the PC through an SSH tunnel (ssh -L 8888:localhost:8888 alice@workstation) is the usual setup.

For many jobs, GNU parallel or a small task queue takes over the bookkeeping; How to use the idle computers you own for batch jobs compares them.

Step 4: sleep, heat and the person who wants to play

• Sleep. Windows sleeps after a while on the default power plan, and a sleeping PC drops the job. powercfg /change standby-timeout-ac 0 turns off sleep on mains power; set it back when you are done. Wake-on-LAN can wake it from the laptop if the network card and BIOS support it.
• The game. A training run and a game fight over the same GPU memory: either one crashes or both crawl. A manual setup has no idea someone sat down, so agree on hours, or stop the job by hand before playing.
• Heat and noise. A GPU at full load for hours is loud and hot. Limiting its power target with the vendor’s tools costs little speed and much noise.
• What the job can reach. A job started over SSH runs as your Windows account, with access to everything that account can read. For code you did not write, use a separate account.

The fleet way: Oarbank

Oarbank is a self-hosted job queue for the computers you own: Macs, Linux machines and Windows PCs. One computer runs the coordinator (the Mac can be it); the gaming PC runs a node, installed from the Windows MSI as a service and joined with a one-time code from the console. Work is packaged as a module with the open-source SDK, and each batch you start is a campaign.

What it does about the problems above:

• The right GPU for each job. A module’s runner names the GPU APIs it can use, for example cuda on Windows and Linux and metal on macOS, and its jobs go only to nodes that provide one. Each node reports what it found (oarbank-agent gpu-apis).

• The game comes first. By default, a node runs no fleet GPU work while a program you protect is using the GPU. A rule can name the game, by its folder for example, and keep fleet GPU work off the PC while it runs:

  [[rule]]
  id          = "games"
  match       = { path_prefix = 'C:\Games\' }
  active_when = "present"
  pause_fleet = { scope = "gpu" }

  While the rule is active the node also takes no new GPU jobs. Add a memory guard and caps so the desktop stays usable, and fewer jobs while someone is at the computer.

• Sleep and failures. A node that sleeps or leaves the network gives its jobs back, and the coordinator hands them to another node or back to this one later.

• The sandbox. Every job runs in an AppContainer on Windows (Seatbelt on macOS, Landlock and seccomp on Linux), with GPU access and network hosts granted per module version.

For language-model batches, the SDK’s llmserve example module runs prompts through llama.cpp (CUDA, Vulkan, Metal or the CPU) or MLX on each node; Run language-model batches with llmserve covers it.

Be clear about where it stands. As of Oarbank 2.11.1, its hardware compatibility page lists GPU detection as verified on Apple silicon and still untested on NVIDIA, AMD and Intel GPUs on Windows and Linux, and asks for reports; the Windows installers are not code-signed yet. You write or adapt a module before the first job. And for one training run this weekend, the SSH steps above are less to set up. Oarbank is source-available: free for personal and noncommercial use, with a commercial licence from Codonic for commercial use.

A gaming PC’s GPU for batch jobs

Can my Mac use the NVIDIA GPU in my gaming PC?

Not as a local GPU: macOS has no CUDA and Apple silicon Macs do not support external NVIDIA cards. Run the jobs on the PC instead and send them from the Mac over SSH, copying the inputs there and the results back.

How do I SSH into a Windows PC?

Install Windows’ OpenSSH server optional feature (Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0), start the sshd service and set it to start automatically. Use a key rather than a password; administrator accounts read keys from C:\ProgramData\ssh\administrators_authorized_keys.

Do I need a Linux NVIDIA driver inside WSL 2?

No. Install the current NVIDIA driver for Windows; WSL 2 reaches the GPU through it, and NVIDIA advises against installing a Linux display driver inside the distribution. nvidia-smi inside WSL should show the card.

How do I stop the PC sleeping during a long job?

powercfg /change standby-timeout-ac 0 turns off sleep on mains power; set it back afterwards. A sleeping PC drops whatever it was running.

Can GPU jobs and games share the card?

Not well: both need the GPU’s memory, and one of them crashes or both slow down. Agree on hours, stop jobs before playing, or use a job queue that pauses GPU work while the game runs.