Local Waifu has an AMD runtime provisioning path on Windows, with Vulkan as a fallback. Detecting Radeon hardware or recommending a model tier does not prove GPU acceleration. Send a local message, check Local AI acceleration, then investigate runtime readiness, drivers or memory according to the result.
Local Waifu on AMD needs more than a detected Radeon name: it needs a usable inference runtime and a model that actually loads onto the GPU. Before replacing a card or reinstalling everything, check those separately. A Light recommendation, a missing ROCm runner and CPU-only model placement are different findings.
I build Local Waifu. This checklist follows the Windows source reviewed on November 3, 2026, rather than a firsthand Radeon benchmark. It covers local text generation, not proof of acceleration for voice or image generation. Your installed release may differ from the inspected source.
Start with the result after a local message
The short version: Open Settings > Performance, send a local message, then use Local AI acceleration > Check.
The English Windows navigation calls this panel Performance; the hardware settings guide describes the same controls. Check after a reply so the engine has a resident model to report.
| What you see | What it establishes | What to check next |
|---|---|---|
| No model loaded yet | No useful placement result is available | Send a local message and check again; if it persists, inspect engine readiness and logs |
| Running on CPU | The reported model has no reported VRAM placement | Compute Device, runtime readiness and Windows driver compatibility |
| Split CPU/GPU | Some reported model memory is in VRAM | Free VRAM, competing applications and model/context size |
| Running on GPU | The check reports essentially all model memory in VRAM | If replies remain slow, investigate settings and workload rather than assuming no offload |
The check uses the configured engine’s /api/ps response and selects the largest resident model. Its percentage compares reported model memory in VRAM with total reported model memory. It is not GPU utilization or a measured speed improvement.
If more than one model is resident, keep that selection rule in mind. An idle Task Manager 3D graph is also not enough to overrule placement evidence. The broader CPU instead of GPU troubleshooting article covers compute graphs and separately managed Ollama servers; this article focuses on the AMD setup branch.
Separate Radeon detection from runtime readiness
The short version: An AMD adapter name decides which setup path to try; it does not certify that ROCm or Vulkan can run your model.
The reviewed vendor probe first checks NVIDIA tooling, then Windows video-controller names. AMD or Radeon in those names can select the AMD provisioning path. On a mixed-vendor PC, NVIDIA can take precedence. This is coarse vendor detection, not a per-card compatibility test.
The current source pins this provisioning path to Ollama v0.40.13. For AMD, it copies the bundled runtime and overlays the matching ROCm runner archive. The ROCm archive is not treated as a complete standalone application containing its own engine executable.
That distinction matters when setup fails: downloading a runner and assembling a usable runtime are separate steps. Initial provisioning needs internet. The app also checks for about 3 GB of free space before AMD setup; this is temporary/runtime setup headroom, not the space needed for your chat-model downloads.
An updated, separately downloaded AI engine can already contain the GPU runners. In that case the app skips this separate provisioning path, and retry can explain that no additional GPU download is needed. Do not treat the absence of a fresh ROCm download as a failure by itself.
After checking acceleration, look for ROCm runtime ready and Vulkan fallback ready. Those describe runner availability in the selected runtime path. Neither confirms that the driver accepted the card or that the loaded model used that backend. The placement result answers the next question.
Check the Windows compatibility list, not a Linux success story
The short version: Match your exact Radeon model and driver to Windows documentation, and keep the runtime version attached to every compatibility claim.
AMD’s Windows HIP SDK requirements distinguish GPU runtime support from SDK support. The reviewed page identifies itself as HIP SDK 7.2.0 documentation. For example, it lists the RX 7900 XTX as supported and the RX 6800 XT as unsupported for that Windows release. Those entries do not establish compatibility for every version of Local Waifu’s packaged runtime.
An RX 6000 owner should therefore avoid concluding either “Linux users made it work, so this Windows ROCm runner must work” or “ROCm is unavailable, so the card cannot help at all.” The reviewed Local Waifu source retains Vulkan as an AMD fallback, including for systems where the driver does not expose the expected ROCm support. Verify placement after loading a model rather than treating fallback availability as success.
The official llama.cpp build documentation describes separate HIP and Vulkan backends. It also explicitly says HSA_OVERRIDE_GFX_VERSION, a workaround found in some Linux discussions, is not supported on Windows. Do not copy that advice into a Windows repair checklist.
These upstream pages move. Their latest support matrix and build flags are useful references, not evidence that a specific Local Waifu binary includes or successfully exercises every upstream capability. Installing a development SDK or compiling another engine is not the first repair step for an app-managed runtime.
Retry setup only after checking the obvious blockers
The short version: Rule out CPU Only, network failure and insufficient disk space before retrying, then measure placement again.
Use this order:
- Record the exact GPU name, app version and AMD driver version. Confirm the PC meets the published requirements.
- In Settings > Performance, inspect Compute Device. If you selected CPU Only, change it to Auto-detect (Recommended) and fully restart the app.
- Check internet access and free space on the app-data drive. AMD runtime setup asks for about 3 GB; model storage is additional.
- If Retry GPU setup is offered, run it and wait for the attempt to finish. It can provision or reapply the GPU runtime and attempt to restart the app-owned engine.
- If the runtime is prepared but the live restart fails, fully quit and reopen Local Waifu. Send another local message, then select Check again.
If the exact driver/runtime combination is unsupported, repeatedly downloading the same files will not change that. Use the appropriate supported AMD or PC-manufacturer driver package, restart Windows after a driver change, and retest. Do not disable security software or fetch replacement DLLs from forum attachments.
An independently managed Ollama server is a separate case: Local Waifu does not forcibly restart a server it does not own. A setup retry cannot prove that an external process has switched runtimes.
Do not use the automatic tier as an AMD health check
The short version: Current source reads AMD dedicated VRAM, but the recommendation still says nothing about successful GPU offload.
Older source-based articles describe a NVIDIA-only VRAM probe. The Windows source reviewed for this article has changed: it tries NVIDIA’s reading first, otherwise uses an AMD probe that reads dedicated memory from display-adapter registry data, with a WMI fallback. The probe is best-effort; the source notes that WMI’s older memory field can underreport larger cards.
That hardware reading feeds a separate selector. Light extends through 18 GB; Balanced starts at 19 GB. A detected 16 GB Radeon with 16 GB system RAM therefore remains Light. With 32 GB system RAM, the RAM side can select Balanced. The selector chooses the higher resource tier, not the sum of RAM and VRAM.
Neither result means the whole recommended model fits into free VRAM. If placement is split, close an unused game or another GPU-heavy application before retesting. Try a smaller compatible model if needed. If you previously increased context, reduce that request within the app’s supported settings and check again. Do not assume a larger tier will fix a backend problem.
Mixed-GPU laptops need one extra check
The short version: If Vulkan is available but the wrong adapter appears involved, identify the device before setting an override.
The reviewed AMD panel includes Vulkan device(s). It saves a GGML_VK_VISIBLE_DEVICES selection for the app-owned engine and requires a restart. This can help distinguish integrated from discrete graphics on a laptop.
Leave it automatic unless you have evidence for the intended Vulkan device index. Do not assume Task Manager’s GPU numbering matches backend enumeration, or that the discrete Radeon is always device 0. Record the current value before changing it. Restart and compare placement afterward; revert an override that does not help.
This field is specific to Vulkan device visibility. It is not a universal ROCm repair or a way to add VRAM.
Keep the evidence if acceleration still fails
The short version: Save the placement result and runtime details before attempting a reset.
Record the GPU and driver version alongside the app version, model name, context setting, ROCm/Vulkan readiness and post-message placement result. Include the precise setup error if a download failed. Review diagnostic logs for private information before sharing them through the troubleshooting support route.
There is no reason to delete conversations or model files merely to establish whether a runner is present. The useful next step is a report that separates “AMD detected, ROCm missing” from “Vulkan present, model still on CPU” or “GPU placement works, replies remain slow.”
Source review: Windows src-tauri/src/sidecars/gpu_runtime.rs for provisioning and AMD VRAM detection; src-tauri/src/platform/windows.rs and src-tauri/src/inference/hardware_tier.rs for recommendations; src-tauri/src/commands/system.rs for placement; src/components/settings/HardwareTab.tsx and English translations for controls. This was source inspection, not a Windows binary test or speed comparison.
Public references reviewed November 3, 2026: AMD Windows requirements and llama.cpp backend build documentation. Check documentation for the installed versions before drawing a purchase conclusion.
Questions people ask
Does Local Waifu support AMD GPUs on Windows?
The reviewed Windows source detects AMD hardware and provisions an Ollama ROCm runtime, while retaining Vulkan as a fallback. Actual acceleration depends on the exact Radeon card, driver and installed runtime. This is not a guarantee for every AMD GPU.
Does ROCm unavailable mean my Radeon cannot accelerate chat?
No. Vulkan may still work. Check Vulkan readiness, send a local message, and inspect Local AI acceleration. A ready runner means its files are available, not that the loaded model has successfully used it.
Why does a 16 GB AMD card still receive the Light recommendation?
The current selector keeps values through 18 GB in Light. It takes the higher tier from system RAM and detected dedicated VRAM, without adding them. A higher RAM tier can change the recommendation, but no tier label proves GPU placement.
Should I install the HIP SDK or compile llama.cpp to fix Local Waifu?
Not as the first troubleshooting step. Local Waifu manages its inference runtime. Check the app's runtime setup and the exact Windows driver compatibility first. Upstream build instructions describe developers compiling another runtime, not a required repair for the installed app.
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