Intel NPU driver 1.39.0 gets a release candidate for Linux testing
The new drop re-enables runtime compilation, ships firmware for three chip families, and adds an nvidia-smi-style monitoring tool.
Intel shipped the first release candidate for its Linux NPU driver, version 1.39.0. The tag is v1.39.0-rc1, and it sits exactly one testing step short of the final release. If you run AI workloads on Intel's AI-PC silicon, it's a green light to start validating against the new stack.
The drop arrives soon after the stable v1.38.0 release from September. It's not a flashy feature upgrade so much as a healthy quarterly-style refresh. The bundled NPU compiler moved to tag npu_ud_2026_44_rc1. Level Zero climbed to v1.33.1. OpenVINO and ONNX Runtime both moved forward, and new firmware binaries cover the 37xx, 40xx, and 50xx hardware families. Intel's AI-PC lineup now spans Meteor Lake all the way to Wildcat Lake.
What actually changed
The release notes are terse. The pull request that folded RC1 into main (PR #154) describes the drop as "the new UMD, compiler, firmware and test snapshots, updated third-party dependencies." About nine commits touched 134 files versus the previous baseline. Approved by Jozef Wludzik.
The one change developers will actually notice is that the Compiler-In-Plugin path got re-enabled. In v1.38.0 Intel had flipped the ENABLE_INTEL_NPU_COMPILER build flag to OFF, stamped with a TODO and an internal ticket. This release turns it back on. That restores Intel's preferred on-device compilation model, where the NPU plugin compiles models at runtime using the compiler shipped inside the driver, instead of leaning on pre-compiled blobs.
The firmware tells the real story, though. Dig into the headers and you get the granular picture of what the silicon can now do. The JSM API got a minor bump from 41 to 43. Intel added two new QoS levels, ECO and UTILITY, for classing background and low-priority workloads. A new doorbell_timestamp field and host_tracking_id improve observability into exactly when the kernel rings the doorbell to submit a job.
The intel-npu-smi tool
Then there's the monitoring tool. Intel has been quietly developing intel-npu-smi, its answer to nvidia-smi, and this release documents it for the first time. That's a clear tell that the company wants people to actually watch NPU health rather than assume it just works.
The tool reads NPU power, frequency, and utilization straight from the terminal and can log that to CSV. It zeroes in on Wildcat Lake power reporting, a fix that was already trickling into the 1.35.x cycle. Fedora users get it packaged as a subpackage of the driver itself, so it drops in almost for free.
There's a benchmark worth citing here. Independent testing on a Beelink EQi 304, a Wildcat Lake machine with a 15 TOPS NPU, ran an INT4 Llama 3.2 1B model through OpenVINO on Ubuntu 26.04. That hit about 30 tokens per second. Not going to run your biggest local models, but genuinely useful for always-on, low-power inference.
Wildcat Lake is the buyer-facing story
Wildcat Lake support is the real reason this matters for most people. Intel's budget 18A part landed in April, and its single-tile NPU tops out at 17 TOPS. That sits below the 40 TOPS bar Microsoft demands for Copilot+ PC certification, so those machines miss the badge. It's a genuine compromise for the value segment, though 17 TOPS is plenty for background AI tasks and always-on assistants.
The fence command changed too, if you like that kind of thing. A new increment-by-N mask lets a caller bump a fence value by N instead of always overwriting it. Small on paper. The sort of change that matters when you're doing tight synchronization.
What comes next
RC1 is the testing gate before the final v1.39.0 tag. The cadence has picked up hard. Intel went from 1.35 in July to 1.38 in September to 1.39 now, each one tagged to an ISO work week. It reflects a release rhythm tied to the compiler and firmware rather than slow feature development.
For that reason, production users should test the RC first. The re-enabled compiler path means you'll want to re-test any apps leaning on runtime compilation, since the optimizations have shifted. Then wait for the final tag before rolling out broadly. It's arguably a healthy on-cadence snapshot rather than something you need to chase immediately.
The release tarballs live on the GitHub releases page, with distribution builds for Ubuntu and others. Debian packages have been GPG-signed since v1.22.0, a small but welcome nod to supply-chain security.
