Home / Guides / Troubleshooting / Windows
Windows
Written by Jakub Rusinowski · Last updated September 1, 2026
Founder, LLM Configurator — AI educator & workshop leader on local LLM deployment
+-----------------------------------------+
| Processes: |
| GPU PID Type Process name Usage |
|=========================================|
| No running processes found |
+-----------------------------------------+
| If you see | The cause is | Go to |
|---|---|---|
nvidia-smi shows 0% and no processes while the model generates | Windows handed the process the integrated GPU | Fix 1: set the graphics preference for the executable |
| It uses the RTX when launched from its shortcut but not from a terminal | The child process inherits the terminal host's preference | Fix 1 — set it for the terminal too |
| It uses the dGPU on mains power and the iGPU on battery | A vendor power policy disables or deprioritises the dGPU on battery | Fix 4: plug it in and check the vendor utility |
| Neither Windows nor the NVIDIA panel changes anything | A BIOS MUX or "hybrid/discrete" mode is overriding both | Fix 3: check the BIOS graphics mode |
| The dGPU is being used and it is still slow | A 4-6 GB laptop dGPU may simply be too small for this model | Fix 5: check the model against the real VRAM |
Two GPUs, and Windows picked the wrong one. The card is present in Device Manager, nvidia-smi runs and lists it, and games use it happily — but during inference it reports no processes and near-zero utilisation while an Intel Iris or Radeon integrated chip does the work at a fraction of the speed.
Hybrid laptops carry two GPUs — a power-efficient one integrated into the CPU and a discrete NVIDIA card — and Windows chooses between them per application, not per machine. The default policy favours power saving, which is right for a text editor and wrong for inference. A command-line process makes this worse: it usually inherits the graphics preference of whatever launched it, so ollama.exe started from Windows Terminal takes Windows Terminal's preference, and Windows Terminal is a text application the system is delighted to keep on the iGPU. Three separate layers can each override the others — the Windows graphics preference, the NVIDIA Control Panel setting, and any BIOS-level MUX or hybrid mode — and the lowest layer wins, which is why changing only the top one sometimes appears to do nothing.
Go to Settings → System → Display → Graphics, add the executable, choose Options → High performance. Do this for the inference binary (ollama.exe, LM Studio, or the python.exe inside your virtual environment) and for the terminal host you launch it from — WindowsTerminal.exe, powershell.exe, or Code.exe. The second half is the step people miss, and it is usually the one that actually changes the outcome, because the child process inherits the parent's preference.
# PowerShell — the full paths you will need to browse to
(Get-Command ollama).Source
where.exe python
(Get-Process WindowsTerminal -ErrorAction SilentlyContinue).Pathnvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csvNVIDIA Control Panel → Manage 3D Settings. On the Global Settings tab set *Preferred graphics processor* to High-performance NVIDIA processor, and on Program Settings add the same executables. This is a separate mechanism from the Windows setting, not a duplicate of it, and on some driver versions it is the one that takes effect. Setting both is not redundant — it removes a variable.
nvidia-smi dmon -c 10Many gaming laptops expose a firmware setting — variously MUX switch, Graphics Mode, Hybrid / Discrete, or Advanced Optimus — that decides at the hardware level which GPU drives the display and which is available. It overrides both software settings above. Set to Discrete or dGPU-only, the integrated chip is out of the picture entirely and this whole class of problem disappears; the cost is battery life, and the change usually needs a reboot. Vendor utilities (Armoury Crate, Lenovo Vantage, Alienware Command Center) often expose the same switch without a BIOS trip.
⚠️ Changing graphics mode in firmware can leave you at a blank screen on the next boot if the panel is wired to the other GPU. Know how to clear CMOS or boot into safe mode on your model before you change it.
Several vendors disable or heavily throttle the discrete GPU on battery, and some do it silently. If speed is fine on mains and poor unplugged, that is the mechanism rather than anything you have misconfigured. Check Windows' own power mode as well — Settings → System → Power & battery → Power mode set to *Best power efficiency* biases the whole system toward the iGPU. Sustained inference is a heavy continuous load and is not a battery workload in any case.
# PowerShell — on mains or on battery, and what power scheme is active?
(Get-CimInstance -ClassName Win32_Battery).BatteryStatus # 2 = on AC power
powercfg /getactiveschemeOnce the dGPU is available to the process, you can name it directly. Use nvidia-smi -L to list devices and prefer the UUID over the numeric index — indices are assigned by enumeration order and can change across reboots, driver updates, or when an eGPU is attached, so a config pinned to 0 silently points somewhere else one morning. Remember that setting this to a device that does not exist forces CPU inference, which is a different symptom on a nearby page.
# PowerShell — list devices with their UUIDs
nvidia-smi -L
# GPU 0: NVIDIA GeForce RTX 4060 Laptop GPU (UUID: GPU-1a2b3c4d-...)
# Pin by UUID for this session
$env:CUDA_VISIBLE_DEVICES="GPU-1a2b3c4d-..."
ollama servenvidia-smi --query-compute-apps=process_name,used_memory --format=csvWorth checking before you spend an evening on graphics preferences: laptop discrete GPUs are often 4 to 8 GB, and laptop variants of a desktop card can carry less memory and less bandwidth than the name suggests. If your RTX has 6 GB, a 7B model at Q4 fits and an 8B at Q5 does not, and forcing the dGPU will not change that arithmetic. Check the model against the card's real VRAM — if it does not fit, a smaller model on the right GPU beats a large model spilling to system RAM.
# PowerShell — the real numbers for the card in this laptop
nvidia-smi --query-gpu=name,memory.total,memory.used --format=csvIf the discrete GPU is now doing the work and generation is still slow, the next thing to rule out is the Windows driver spilling into system RAM — a laptop card with 6 GB reaches that ceiling quickly. If the card is not being used at all and nothing here changed it, the problem is upstream of GPU selection.
Include this when you report it
nvidia-smi -L and nvidia-smi --query-gpu=name,memory.total --format=csvBecause Windows chooses per application and defaults to power saving. Games ship with vendor profiles that request the discrete GPU; a command-line process has no profile and inherits its parent terminal's preference, which is usually the integrated chip.
Yes, and this is the step most often missed. A process launched from Windows Terminal inherits Windows Terminal's graphics preference. Setting it only on ollama.exe frequently changes nothing until you set it on the terminal host too.
A hardware multiplexer that decides which GPU drives the display. Where the firmware exposes a Discrete or dGPU-only mode, it overrides both the Windows and NVIDIA Control Panel settings, and switching to it removes this problem entirely at the cost of battery life.
A UUID. Numeric indices come from enumeration order and can change after a reboot, a driver update, or attaching an external GPU, at which point a pinned index quietly selects a different device. nvidia-smi -L prints both.
Yes, but keep expectations calibrated. A 6 GB card comfortably runs a 7-8B model at Q4 and will not run a 14B at any useful quality. Forcing the right GPU helps; it does not create VRAM, and a model that overflows 6 GB will be slow on the dGPU too.