u/toreanjoel

My main machine - Ryzen 9 7945HX, RX 7900 XTX 24GB, 96GB DDR5, is primarily a gaming machine, so it stays on Windows. Instead of full passthrough (which would hand the card to a single Linux VM and kill it as a gaming host I imagine?), I've been using Hyper-V GPU partitioning (GPU-P) to split utilization between the host and VMs, with Sunshine/Moonlight for remote access.

Worth flagging upfront: the 7900 XTX isn't on Microsoft's official GPU-P supported list, only the Radeon PRO V710 is listed I believe and I might need advice here, but the SR-IOV hardware is present on RDNA3 and it partitions fine with a driver workaround. Would be curious if anyone else is running consumer RDNA3 under GPU-P. It works, but it feels like "non-idea" on AMD, and I'm not sure I've found the ceiling of what's practical.

Where I want to take it next:

• Local inference on bigger models - 24GB VRAM + 96GB RAM is the only real headroom I own (day-to-day serving already lives on a Mac Mini M4 running Ollama (cloud)/Open WebUI/LiteLLM)
• Dynamically provisioned sandbox VMs, tooling that spins environments up and down via API for testing, ideally with GPU access when needed
  • Something I am experimenting with building for myself and want to do this internally
• General self-hosting experiments as my M4 Mini is a 16Gb variant.

Hard constraints: not buying a new GPU, and not giving up gaming on this box (maybe I can get another setup and take the GPU out here later and keep it for its memory as a host). So NVIDIA suggestions don't help me here, and full passthrough is out, ideally partitioning, which I know this card is not meant for.

I'm on Windows specifically because of the AMD GPU situation, consumer RDNA3 driver support keeps me here vs. moving to Proxmox or a Linux hypervisor. I am open to suggestions as I research.

Questions for anyone running AMD:

1. Is GPU-P still the best (or only) way to share a consumer Radeon between a Windows host and VMs in currently, or has something better emerged, SR-IOV, virtio-GPU with ROCm, container-based approaches?
2. How's ROCm inside a GPU-P partition, or is everyone just running inference on the host and isolating everything else?
3. I've scripted VM provisioning with Hyper-V PowerShell (host-side - New-VM from a Windows ISO, CPU/memory config, the usual) and manage them via the Hyper-V GUI as needed. Has anyone taken this further ? (I don't mind if there is some tool that allows me to have this experience with AMD, I am also willing to brute force this as it will be internal usage.

Rest of the lab is mid-upgrade too, a new gateway SBC and a fibre run to my subnet are next, and this rig is the focus right after that lands. The fibre is more the media converter <> fibre runs so that I have lower bandwidth accessing the machine over the network and data transfer over the subnet.

Note: I am happy to explore tools that exist already, my setup is AMD specific and I am open to Unix operating systems if there is something that can help cater or even dual boot options

I've been building a personal gateway running on ARM SBCs (currently a NanoPi Zero 2 and had it on Nano PI Neo3/RPI 3B before) that manages Zrok tunnels, and reverse proxies to expose local services. It started as a wireless-first device, WiFi was the upstream, ethernet downstream, which made it portable and easy to drop anywhere.

But I've been going back and forth on whether WiFi should stay in the architecture at all.

The problem with WiFi upstream:
Consistency. Race conditions on boot, upstream instability, and the fact that WireGuard sitting on a flaky WiFi underlay means my tunnel quality is directly tied to whatever the wireless environment is doing. I've been fighting this for a while and it's the part of the setup that causes the most headaches.

What I'm moving toward:
Driving a wired ethernet feed to the gateway instead, either via a fibre run using something like InvisiLight (ultra-thin fibre with media converters at each end) or just a direct cable. From there the gateway gets a clean, stable uplink and WireGuard has a reliable underlay to sit on. I'd also remove the WAN upstream handling from the software entirely since the house router takes care of that.

The reason I keep coming back to WiFi:
Some devices don't have two ethernet ports, Raspberry PI's, small SBCs, anything I want to drop into the gateway's subnet without running a cable. If I kill WiFi entirely, those devices either need a USB ethernet adapter or they're out. There's also something to be said for the original portability, being able to place the gateway anywhere without thinking about cabling.

I also looked at mesh:
But mesh solves a coverage problem, not a consistency problem. My issue isn't signal reach, it's stability of the upstream connection itself. A mesh backhaul is still wireless, which doesn't fix the root cause.

Where I'm at:
Leaning toward wired as the primary uplink and keeping WiFi as a secondary interface only, for devices that need it (might not even want to keep it and remove the portability idea), not as the gateway's upstream. But this is a meaningful architecture change from where the project started and I'm second-guessing whether dropping wireless-first is the right call long term.

Has anyone navigated a similar decision with a home gateway or router project? Is there a case for keeping WiFi as the primary upstream that I'm missing, or does wired always win when consistency is the goal?

I pretty much just need to confirm ideas others with more experience would opt as a default (Which I believe I know the answer) and if it makes sense and where it doesn't for wireless cases. Open to learning!