AI PCs have had a strange problem for a while now. The NPU, the dedicated AI block AMD has been building into its Ryzen AI chips, is supposed to be the efficient, always-on place to run local language models. In practice, the software around it has often felt a step behind the hardware. AMD’s newest update, Ryzen AI Software 1.9, doesn’t fix that overnight, but it does chip away at two of the biggest limits developers kept running into: short context windows and the clunky way fine-tuned models had to be shipped.
The release landed on GitHub on October 30, and on November 2 AMD followed up with a developer blog post walking through the feature I think is the most interesting part of it: dynamic LoRA switching on the NPU.
One base model, swappable specialists
Quick refresher if you haven’t messed with fine-tuning. LoRA (low-rank adaptation) is the popular trick for teaching an existing model a new skill without retraining the whole thing. You freeze the big base model and train a small set of extra weights, the adapter, that nudges its behavior toward writing SQL, answering domain questions, or matching a particular style. The adapter is tiny compared to the model it sits on.
Until this release, AMD’s supported way to run a fine-tuned model on the Ryzen AI NPU was what it calls a static merge. You baked the adapter into the base weights and compiled the result into one NPU binary. That’s fine if you only have one specialist. If you have five, you end up shipping five complete copies of the same base model, which is a rough deal on a laptop where memory is already shared between the CPU, the integrated GPU and the NPU. Switching from one specialist to another also meant loading a whole different model.
With 1.9, the base is compiled once and stays resident on the NPU, while each adapter becomes a small, separately loadable piece. An app picks which one is active per request. In AMD’s sample code it’s literally one call, set_active_adapter("sql_spider"), then another to flip to a medical adapter, and one more to drop back to the plain base model, all without reloading anything.
AMD’s example is honest about scale. It trains two adapters on a Qwen3-4B model quantized to INT4: one for text-to-SQL using the Spider benchmark, one for medical multiple-choice questions using MedMCQA. On the NPU, the SQL adapter lifted execution accuracy from 47.5% to 63.0%, and the medical adapter raised exact-match scores from 42.0% to 53.0%. Both were measured on 200 examples each, which is a decent sanity check rather than a rigorous benchmark run, and these are AMD’s own numbers. Still, double-digit jumps from a small adapter are exactly the kind of result that makes LoRA so popular in the first place.
The most useful bit of the blog post is a warning, not a brag. Because the base model runs quantized on the NPU, AMD says you have to train the adapter against that already-quantized base. Train it on the full-precision model instead, and the corrections the adapter learned won’t line up with the weights it’s actually being added to, so a lot of the benefit disappears on-device. The suggested pipeline is to quantize once with AMD’s Quark tool (INT4 AWQ), fine-tune each adapter against that frozen base, compile everything with one model_generate call per adapter, and only then deploy. Only that last step happens on the Ryzen AI PC itself; the training happens elsewhere.
There’s a catch on coverage, too. Dynamic LoRA currently works with exactly three text models: Qwen2.5-3B, Qwen3-4B and Qwen3.5-4B. If your favorite model isn’t a small Qwen, this feature isn’t for you yet.
Longer context and a bigger model list, with asterisks
The other headline change is context length. Earlier releases capped LLMs on the NPU at 4K or 16K tokens depending on the setup, which is tight for anything like summarizing long documents or keeping a chat assistant on track. The 1.9 release notes say context now extends beyond those limits. What they don’t say is the new ceiling, and I’d want to see real numbers on how speed and memory hold up as context grows before calling this solved. Long prompts are where small on-device accelerators usually start to sweat.
Model support grew as well. Gemma-4-E2B and Gemma-4-E4B (both text) and Hy-MT2-1.8B are newly supported. AMD also added Phi-4-14B, Qwen3.5-9B, Granite-4.1-8B and Gemma-4-12B, but it labels those four “functional only (performance not optimized).” That phrase is doing a lot of work. It means they run, not that they run well, so anyone hoping to make a 12B or 14B model their daily driver on an NPU should test before committing. The release also adds the ability to import INT4 models produced through quantization-aware training, which should help teams that already quantize in their own training pipelines.
Now the part that will annoy some people. AMD’s OnnxRuntime GenAI documentation says 1.9 moves to OGA version 0.18.0, up from 0.14.0 in Ryzen AI 1.8, and that NPU models published for earlier releases are not compatible with this one. If you built something on 1.8, plan on downloading the updated models rather than expecting a drop-in upgrade. That’s a fairly normal growing pain for a young software stack, but it’s worth knowing before you hit update on a working setup.
Hardware support is the other fine print. The LLM deployment docs list NPU-only and hybrid NPU-plus-iGPU execution for Ryzen AI 300 series chips (Strix and Krackan Point), while older Ryzen 7000 and 8000 mobile chips built on Phoenix and Hawk Point fall back to GPU or CPU inference for LLMs. The release notes’ supported-hardware list also includes Strix Halo, Gorgon Point and the Ryzen AI 400 series, which AMD rates at up to 60 NPU TOPS on its top mobile chips. So if you’re on an early-generation Ryzen AI laptop, most of this update simply won’t reach your NPU.
It’s also worth remembering that the Ryzen AI stack isn’t one tool. AMD’s docs point to the Lemonade SDK and Lemonade Server for an Ollama- or OpenAI-style local API, OnnxRuntime GenAI for the NPU and hybrid paths, FastFlowLM as an NPU-first runtime, and llama.cpp for GPU inference. Dynamic LoRA lives in the OGA flow, so how quickly it shows up in friendlier front ends is still an open question.
Cody’s take
I like this release because it’s practical. Dynamic LoRA isn’t flashy, but it solves a real deployment headache: one resident base model that can act as several narrow specialists is a much better fit for a laptop than a pile of near-identical full models. For anyone building a local app that needs, say, a coding helper, a support-docs bot and a writing assistant on the same machine, that’s a meaningful change. And AMD deserves credit for calling out the train-on-the-quantized-base trap instead of letting developers discover it the hard way.
The realistic view is that it’s early. Three supported models, an unstated context ceiling, “functional only” labels on the bigger models and a model-compatibility break with 1.8 all say this is a stack still finding its footing. If you’re a developer with a Ryzen AI 300 or 400 machine, it’s worth grabbing the Ryzen AI Software examples and trying your own adapters. If you’re a regular user waiting for the NPU in your laptop to feel essential, this is a solid step, not the finish line.
Author
