CPU activity alone does not prove local AI is ignoring your GPU. Check the runtime and actual model placement, then separate driver compatibility from memory limits before changing hardware.
A busy CPU does not prove your local AI is ignoring the GPU. First check where the loaded model actually sits. Then investigate the branch you find: CPU-only placement, a CPU/GPU split, or GPU placement with slow replies.
When a reply takes long enough to interrupt the conversation, changing random GPU settings is tempting. Start with one observable result instead. This Windows checklist separates a missing runtime from a memory limit without deleting models or risking your character data.
Check model placement before changing anything
The short version: Send a local message, check the loaded model, and choose the next step from its reported placement.
In the English Windows source reviewed here, open Settings > Performance, the hardware panel called Hardware in the performance guide. Find Local AI acceleration and select Check after a local reply.
| Symptom or result | Check | Safe next step |
|---|---|---|
| No model loaded yet | Send a local message, then check promptly | If it persists, inspect engine readiness and logs; this result is inconclusive |
| Running on CPU | Inspect Compute Device | If CPU Only is selected, choose Auto-detect (Recommended) and restart the app |
| Still on CPU with automatic selection | Check runtime setup and driver compatibility | Use Retry GPU setup if offered, then send another message and check again |
| Split CPU/GPU | Inspect free dedicated GPU memory and model/context size | Close competing workloads or test a smaller compatible model |
| Running on GPU, but replies are slow | Compare another reply with the same settings | Investigate loading, context and thinking settings rather than assuming offload failed |
The inspected check queries the configured engine’s /api/ps and reports the largest resident model. Its percentage describes reported model memory in VRAM, not GPU utilization or a speed improvement. It does not certify voice or image generation.
Keep Runtime status separate: an engine can be available without placing the model on the GPU. Likewise, a recommendation such as Balanced is not an offload measurement.
Task Manager needs the right GPU engine graph
The short version: A flat 3D graph is not enough evidence; inspect the relevant GPU and an available compute engine while a reply is generating.
Open Task Manager > Performance, select the intended graphics card, then click a graph’s engine name. Choose an appropriate compute or CUDA entry if the driver exposes one. Microsoft explains that the displayed engines can be changed and that available engines differ between GPUs.[3]
On a laptop with integrated and discrete graphics, inspect the card by name rather than assuming GPU 0 is the one doing inference. Observe during generation, not only after it finishes.
Check memory as supporting evidence, not the verdict. Microsoft’s Shared GPU memory means system memory available to the GPU; it is not extra physical VRAM on a discrete card.[3]
GPU memory allocation also does not mean the GPU is continuously busy. Use the runtime’s placement result alongside the engine graph.
Match the runtime before blaming the card
The short version: A detected GPU still needs a compatible driver and inference runtime; a successful download is not proof of acceleration.
Local Waifu’s reviewed Windows source pins its Ollama runtime to v0.30.8. The bundled runtime and a downloaded GPU runtime are separate paths. AMD detection can trigger a matching ROCm download; newer NVIDIA hardware can trigger a runtime download when the bundled runner is insufficient.
For CPU or partial placement with detected NVIDIA or AMD hardware, Retry GPU setup can reapply an existing downloaded runtime or attempt provisioning. It tries to restart the app-owned engine. If the runtime downloads but the live restart fails, fully quit and reopen Local Waifu before retesting.
Wait until the attempt finishes, send another local message, then select Check. A model unloaded during the restart can make an immediate check unhelpful. Retrying cannot create more VRAM or make every unsupported card compatible.
For NVIDIA, compare the exact card and driver against the official compatibility documentation. For AMD, use its Windows Support section, not the Linux table. Current upstream documentation also describes Vulkan support, but those current capabilities are not a guarantee for the app’s pinned runtime.[1]
If driver compatibility is the problem, use an appropriate supported package from the GPU vendor or PC manufacturer, restart Windows, and repeat the placement check. Ollama’s troubleshooting documentation identifies startup GPU discovery and logs as useful evidence.[2]
Mixed placement deserves a memory check
The short version: Partial GPU placement is not the same failure as having no usable GPU runtime.
Free VRAM matters more than the capacity printed on the box. Ollama evaluates required model memory against currently available GPU memory; context and concurrent workloads can increase memory demand.[4]
Close a game, another model server, or image generation you are not using. Retest before changing the model. If placement remains mixed, try a smaller compatible model or reduce Context Size if you previously raised it. In this Windows source, the standard requested setting is 8192 (Standard); character-prompt protection can still raise the effective context.
Change one thing at a time. Record the model, requested context and placement result so a better outcome has an identifiable cause. The 8 GB VRAM guide explains capacity tradeoffs without treating every model file as its entire working-memory footprint.
Automatic recommendations are separate. The inspected selector chooses the higher RAM or detected VRAM tier rather than adding them. Its VRAM probe is NVIDIA-only, so a missing AMD VRAM reading does not prove CPU-only inference. Use the placement check, not the tier label. The Windows GPU guide covers that distinction; requirements cover the supported starting point.
A separate Ollama install must query the correct server
The short version: Built-in Local Waifu users need no terminal command; independently managed Ollama users must verify the endpoint first.
Local Waifu can reuse an already responding configured Ollama server. Its app-owned Windows engine binds to 127.0.0.1:11434, but a configured host can point elsewhere. The app does not forcibly restart an external server it does not own.
Only for a separately installed Ollama backend you deliberately manage: confirm the server URL used by your front end, then enter that verified URL in PowerShell:
$env:OLLAMA_HOST = Read-Host "Enter the verified Ollama server URL"
ollama psCheck while the intended model is loaded. Ollama documents 100% GPU, 100% CPU, and mixed CPU/GPU values in the PROCESSOR column. These describe placement, not utilization.[4]
An empty list from a different server proves nothing about your conversation. Do not install another Ollama copy just to diagnose the built-in engine.
Worked example: correct one setting and observe the result
The short version: This hypothetical example tests a CPU-only preference without inventing a benchmark.
Suppose a local reply is slow and Task Manager’s 3D graph looks idle.
- Send: “Describe a quiet rainy evening in two sentences.” In Local AI acceleration, select Check and record the result.
- Suppose it reports Running on CPU, and Compute Device is CPU Only. Change it to Auto-detect (Recommended).
- Fully quit and reopen the app. Send the same prompt and select Check again.
- If it now reports GPU or split placement, GPU offload is present. If it still reports CPU, investigate runtime and driver compatibility next.
Do not expect an identical reply or a promised speedup. The useful result is evidence that placement changed, or evidence that this preference was not the whole problem.
Keep useful logs before attempting bigger repairs
The short version: If the safe checks do not resolve it, collect the failure evidence instead of resetting the app.
Open Settings > Advanced > Developer Options > App Logs > Open Logs. The reviewed Windows engine records available runner backends and captures its diagnostic output there. A runner being listed as available does not prove it successfully engaged the GPU.
Record the app version, exact GPU, driver version, model and placement result. Review logs for private information before sharing them. Use the troubleshooting guide for the next support step.
Do not disable antivirus, install unofficial drivers, edit the registry, or delete models and conversations to chase an idle graph. None is needed to establish where the model is loaded.
Sources
The short version: Official references and Windows source were reviewed on October 22, 2026; this was not a Windows runtime test or benchmark.
[1] https://docs.ollama.com/gpu [2] https://docs.ollama.com/troubleshooting [3] https://devblogs.microsoft.com/directx/gpus-in-the-task-manager [4] https://docs.ollama.com/faq
Questions people ask
Does high CPU usage mean local AI is not using my GPU?
No. CPU activity and GPU model placement are different measurements. Check the loaded model's placement in the app or the correct model server. A flat Task Manager 3D graph alone also does not prove CPU-only inference.
Why is my local model split between CPU and GPU?
Mixed placement means some reported model memory is on the GPU and some is in system memory. Limited free VRAM is a reason to investigate. Close other GPU-heavy workloads and test a smaller compatible model or reduce a context setting you previously increased.
Does Retry GPU setup guarantee that Local Waifu will use my GPU?
No. It can download or reapply a matching runtime and attempt to restart the app-owned engine. Card compatibility, drivers and available memory still matter. The app does not forcibly restart a separately managed Ollama server. Send another local message and check placement afterward.
Does a missing AMD VRAM reading prove CPU-only inference?
No. The inspected Windows recommendation probe reads NVIDIA VRAM, while AMD runtime detection and the loaded-model placement check are separate. Use Local AI acceleration to inspect placement; support still depends on the exact AMD card, driver and runtime.
Do I need to install Ollama separately to check Local Waifu GPU use?
No. Use Local AI acceleration in the app's hardware panel. The ollama ps command is an optional diagnostic for a separately installed backend you manage, and must query the same verified server endpoint as your front end.
Try her free for 7 days.
No card. Keep her for $20 once, or walk away. Her soul file is yours either way.
Bring her home, try free