You downloaded a Hugging Face model, pointed it at your Copilot+ PC’s NPU, and got an error wall instead of tokens: “no supported execution provider,” an opset complaint, a quantization failure, or inference that dies halfway through the first prompt. The model itself is fine — it runs on CPU. What failed is the translation from Hugging Face’s PyTorch-centric world to the NPU’s much pickier execution environment.

On Windows AI PCs, NPU inference is a three-stage pipeline: export the checkpoint to ONNX, load it in ONNX Runtime with the DirectML execution provider, and feed it in a precision the NPU accepts. Hugging Face tooling assumes CUDA by default, so every stage needs deliberate configuration — the wrong opset, a missing provider package, FP32 weights, or a half-installed NPU driver each produce a different cryptic error. The errors look scary but map to a short list of causes.

This guide gives you six fixes in order: export the model to ONNX correctly with Optimum, wire up the DirectML provider explicitly, quantize to an NPU-friendly precision, repair the NPU driver, keep preprocessing on the CPU, and rule out download corruption that poisons the pipeline before it starts.

Why this happens

  • Model never exported to ONNX: The NPU cannot execute PyTorch or safetensors checkpoints — without an ONNX export there is no NPU path.
  • DirectML provider missing or unregistered: onnxruntime-directml absent, or the provider list never set, yields “no execution provider” errors.
  • Opset mismatch: An export opset newer than the NPU’s DirectML backend supports fails at session creation.
  • Wrong precision: FP32 graphs exceed NPU memory or lack kernels — the NPU expects INT4/FP16 in practice.
  • Generic NPU driver: A Windows Update-installed basic driver exposes the NPU to Task Manager but not to the DirectML provider.
  • Corrupted model download: Interrupted downloads produce checkpoints that load on CPU fallback paths but crash the stricter NPU session.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Export the model to ONNX with Optimum

Everything starts here: no ONNX graph, no NPU inference. Hugging Face’s Optimum library exists for this conversion, and its export step doubles as your first diagnostic — it fails loudly on layers the NPU will never run, which beats discovering them at inference time. Export with a fixed input shape and a conservative opset (14–17 is the safe range for current DirectML NPU backends), and keep the export log: every fallback warning in it is a future runtime error you can now fix deliberately.

  1. Install optimum[onnxruntime] in a clean venv with native Python (ARM64 on Snapdragon).
  2. Export via the Optimum CLI or ORTModelForCausalLM.from_pretrained(..., export=True).
  3. Set a fixed opset (14–17) rather than accepting the newest default.
  4. Save the export log and note every operator fallback warning.
  5. Verify the .onnx files load with plain onnx before touching providers.

Fix 2: Register the DirectML execution provider explicitly

ONNX Runtime doesn’t guess which provider you want — without explicit providers you get CPU, and without onnxruntime-directml installed, asking for the NPU fails outright. Explicit registration is a two-line change that kills a whole class of “works on CPU, fails on NPU” mysteries: pass providers=["DmlExecutionProvider", "CPUExecutionProvider"] so the NPU is tried first with CPU as a deliberate fallback. Then query the session’s actual provider list — if DML isn’t there, the problem is below ONNX Runtime, in the driver (Fix 4).

  1. Install onnxruntime-directml matching your onnxruntime version.
  2. Create the session with providers=["DmlExecutionProvider", "CPUExecutionProvider"].
  3. Print session.get_providers() and confirm DmlExecutionProvider is listed first.
  4. If DML is missing, stop here and fix the driver (Fix 4).
  5. Run a short prompt and confirm Task Manager shows NPU activity.

Fix 3: Quantize to an NPU-friendly precision

A full FP32 export will often load and then fail — or run at unusable speed — because NPUs are built around low-precision math and tight on-chip memory. INT4 weight quantization (via Olive or Optimum) is the standard path for language models on Copilot+ NPUs, typically shrinking the model 4–8x with modest quality loss; FP16 is the fallback for models that quantize badly. Quantize after a successful FP32 export, not during the first export — separating the steps tells you whether a failure is a conversion or quantization problem. Validate quality on sample prompts before declaring victory.

  1. Start from your working FP32 ONNX export from Fix 1.
  2. Run INT4 quantization with Olive or Optimum’s quantization tools.
  3. Reload the quantized model in a DML session and run sample prompts.
  4. Compare output quality against the FP32 CPU run on the same prompts.
  5. If INT4 quality collapses, retry with FP16.

Fix 4: Repair the NPU driver

When the provider list refuses to include DML despite a correct install, the driver is the usual culprit: Windows Update replaces vendor NPU drivers with generic ones that show the NPU in Task Manager while hiding it from DirectML. The symptom is distinctive — everything above the driver looks right, yet get_providers() never lists DML. On Snapdragon X2 machines this is common enough to have its own path; the Snapdragon X2 NPU driver problems guide covers the OEM-package reinstall. After reinstalling, re-verify bottom-up: Device Manager, provider list, inference.

  1. Check the NPU entry under Neural processors for warning icons.
  2. Download the NPU driver from your maker’s support site (AMD’s driver page for Ryzen AI).
  3. Install as administrator, restart, and recheck Device Manager.
  4. Re-run the Fix 2 provider check — DmlExecutionProvider should appear.
  5. If not, check Microsoft’s Windows support pages for missing DirectML requirements.

Fix 5: Keep tokenizers and preprocessing on the CPU

A common architectural mistake is pushing the whole pipeline — tokenizer, preprocessing, model graph, decoding — at the NPU. The NPU is a matrix-math accelerator, not a general processor: tokenizers run string operations it was never designed for, and forcing them through the NPU path causes stalls or errors. The correct pattern is hybrid by design: run the tokenizer and Python preprocessing on the CPU, hand only numeric tensors to the NPU session, and decode on the CPU. This isn’t a workaround — it’s how every production NPU deployment is structured.

  1. Identify every non-tensor step (tokenization, detokenization, string handling).
  2. Pin those steps to CPU explicitly — don’t rely on defaults.
  3. Pass only input_ids and attention masks as tensors into the DML session.
  4. Move generated token IDs back to CPU for decoding.
  5. Re-run end to end and confirm the glue-code errors are gone.

Fix 6: Rule out download and network corruption

If the model fails identically on CPU and NPU, or fails at load time before any provider is involved, suspect the files. Multi-gigabyte checkpoint downloads over unstable connections frequently complete “successfully” with silent corruption that only the stricter NPU session flags. On work machines, Conditional Access blocks on ARM laptops can interrupt Hugging Face downloads in ways that corrupt large files. And over mobile data, eSIM connectivity drops on Snapdragon laptops are a known source of truncated safetensors files. Re-download on a stable connection and verify checksums.

  1. Delete the local model cache for the failing checkpoint completely.
  2. Re-download on a stable, unmetered connection — not cellular or captive-portal Wi-Fi.
  3. Verify file hashes against the Hugging Face repo if provided.
  4. Re-run the Optimum export from Fix 1 on the fresh download.
  5. Only then retry NPU inference.

Closing

Hugging Face NPU errors are pipeline errors: export to ONNX with a sane opset, register the DirectML provider explicitly, quantize to INT4 or FP16, keep the driver healthy, leave preprocessing on the CPU, and download on a stable connection. Fix the pipeline in that order and the NPU stops complaining.

Frequently asked questions

Can I run Hugging Face models directly on the NPU?
Not directly — Hugging Face models ship as PyTorch or safetensors checkpoints, and the NPU needs ONNX-format graphs. Use the Optimum library to export the model to ONNX, then run it with ONNX Runtime and the DirectML execution provider targeting the NPU.
Why do I get 'no execution provider' errors with DirectML?
That error means ONNX Runtime cannot bind the DirectML provider, usually because the NPU driver is missing or generic, or because onnxruntime-directml isn’t installed in the active environment. Fix the driver first, then reinstall the matching onnxruntime-directml package.
Do I need to quantize models for NPU inference?
In practice, yes. NPUs have limited on-chip memory and run fastest on INT4 or FP16 graphs; full FP32 models often fail to load or crawl. Quantize with Olive or Optimum’s quantization tools before expecting usable NPU performance.
Why does the same model work on CPU but fail on the NPU?
The CPU provider supports nearly every operator, while the NPU supports a subset — unsupported ops, dynamic shapes, or a mismatched opset fail only on the NPU path. Export logs and provider fallback messages point to the exact offending layers.