You run something local. It answers. Nothing tells you which piece of silicon did the work, and the answer is identical either way, so most people never ask. Then a laptop with a 48 TOPS neural engine gets hot and loud doing something a phone does silently, and the question becomes urgent.
On Windows the decision is made by a layer called Windows ML, which sits on ONNX Runtime and picks an execution provider at run time. Here is the part that surprised me when I read the specification rather than the marketing: whether your NPU gets used is decided by a driver version and an on-demand download, not by the processor in the machine. And for one vendor the supported driver range has a documented upper bound.
One front door, several back rooms
Until recently an application that wanted your GPU or NPU had to know which acceleration library your hardware spoke, bundle it, and keep it updated. Windows ML replaced that: the application asks for a model to run, and Windows works out what the machine has.
Two providers ship inside the runtime: CPU, and DirectML, which Microsoft's own list now labels legacy. Everything else, meaning every vendor path that reaches an NPU or uses a graphics card properly, is downloaded on demand and is documented as available on Windows 11 version 24H2, build 26100, or greater, subject to device and driver compatibility.
The providers, and what each one demands
From Microsoft's execution provider list, as published in the 26 August 2026 revision. The requirements column is the interesting one and it is almost never quoted anywhere.
| Provider | Vendor | Runs on | What it requires |
|---|---|---|---|
| QNN | Qualcomm | Hexagon NPU | Snapdragon X Elite or X Plus, NPU driver 30.0.140.0 or above |
| OpenVINO | Intel | CPU, GPU or NPU | CPU path: 11th gen Core or newer, 8 GB. GPU path: 12th gen or newer, 16 GB. NPU path: Core Ultra Series 1 or newer, 16 GB |
| VitisAI | AMD | Ryzen AI NPU | A driver range: Adrenalin 25.6.3 with NPU driver 32.00.0203.280 at the bottom, Adrenalin 25.9.1 with NPU driver 32.00.0203.297 at the top |
| MIGraphX | AMD | Radeon GPU | GPU driver version 25.10.13.09, marked exactly. Not supported for generative scenarios today |
| NvTensorRtRtx | NVIDIA | GeForce RTX GPU | RTX 30 series and above, minimum recommended driver 32.0.15.5585 with CUDA 12.5 |
| DirectML | Microsoft | Any DirectX 12 GPU | Ships in the box, and is labelled legacy |
| CPU | Microsoft | Your processor | Nothing. This is the floor, and it always works |
A few things fall out of that table immediately. Intel's NPU path wants 16 GB of memory, which is the same bar the Copilot+ programme sets and a reminder that memory gates more of this than clock speed does. AMD has two providers because its NPU and its graphics card are reached through different software. And AMD's GPU provider carries a line worth reading twice: not supported for GenAI scenarios today, which is to say it is not the path a local language model takes.
The part nobody mentions: version pins
Two entries in that list are not "this version or newer". They are narrower, and the consequence is real.
AMD's VitisAI provider has a maximum. The documented range runs from Adrenalin Edition 25.6.3 with NPU driver 32.00.0203.280 up to Adrenalin Edition 25.9.1 with NPU driver 32.00.0203.297. A driver above that ceiling is outside the supported window. The usual advice, keep your drivers current, is exactly the wrong instinct here, and nothing in Windows will tell you that the NPU path stopped being available. Your model will keep working, on the CPU.
AMD's MIGraphX provider names one version and says exactly. Not a minimum, one build.
NVIDIA and Qualcomm state minimums, which behave the way people expect.
These pins move, which is why the date on this section matters more than the numbers in it. Treat the table as evidence that a range exists and always check the current list before a driver update, not as a set of versions to memorise.
Silent fallback, and why it is correct
When Windows ML cannot use the provider it wanted, it falls back: another provider, then the GPU, then the CPU. Nothing errors, and the model returns the same answer.
That behaviour is right. An application that refused to run because a driver was one build too new would be worse for everybody. But it means the difference between the fast, cool path and the slow, hot one is invisible from inside the application, which is why "my AI laptop gets hot doing AI" is such a common and such a confusing complaint. The work happened. It happened in the wrong place.
It also explains something people report about local models specifically: the model runs, produces correct output, and the NPU sits at zero the whole time. That is the fallback working as designed. The companion guide on whether your NPU is doing anything covers how to read the counter itself.
How to find out which one ran
Three ways, in ascending order of effort and certainty.
Watch the counters. Task Manager's NPU and GPU columns during a real workload will tell you where the work landed if it lasts more than a second or two. Free, instant, and blind to anything short.
Record a trace. Windows Performance Recorder has a Neural Processing profile, and ONNX Runtime emits its own tracing events. Recorded together you get the session setup, the provider that was selected, the per-inference times and the operators that took the longest:
wpr -start NeuralProcessing -start CPU
:: run the model here
wpr -stop npu.etl -compressOpen the result in Windows Performance Analyzer and look under Neural Processing. Microsoft publishes the ONNX Runtime recording profiles for the fuller version of this, which adds the provider configuration to the same timeline.
Ask the runtime. If you are running your own code rather than somebody's application, the session reports the provider it selected. That is the only method that gives a name rather than an inference, and it is one line of code.
Which engine you actually want
| Work | Best engine | Why |
|---|---|---|
| Background effects, captions, wake words, anything running for hours | NPU | Small model, continuous, and the power difference is the entire point |
| A language model you are waiting on | GPU with its own memory | Bandwidth sets the pace, and a graphics card has several times more of it |
| Image generation | GPU | Heavy arithmetic on data that fits, which is what a GPU is for |
| Anything on a machine with no accelerator support | CPU | Slower, always available, and correct |
The rule underneath the table is short: the NPU wins on watts, the GPU wins on speed, and the CPU wins on always working. If you are choosing hardware rather than tuning what you own, the memory arithmetic in how much memory a local model needs will tell you more than any TOPS comparison.
Where PC Workman fits
PC Workman does not select execution providers and does not read NPU counters. What it reads is the evidence that the fallback happened: processor load where you expected none, package power climbing, temperatures rising and clocks reacting, during a task you believed was offloaded.
That is a genuinely useful signal on this particular problem, because the silent fallback leaves no other trace. A local model that is quietly running on your CPU looks exactly like a busy CPU.
Related: is your NPU doing anything · what TOPS actually measures · all guides →
Provider names, vendors and hardware and driver requirements are quoted from Microsoft, Windows ML execution providers, revision dated 26 August 2026; the version pins in it change, so check that page before a driver update rather than trusting the numbers here. Selection and fallback behaviour from Copilot+ PCs developer guide and What is Windows ML.