How Curiosity About the Snapdragon NPU Turned Into HK NPU STUDIO

Holger Kreuzhofen — Sat, 17 Oct 2026 17:26:43 +0000

Local AI for Snapdragon® PCs

Your Hardware • Your AI • Your Control

Developing software is rarely a straight line.

Sometimes it feels like progress, sometimes like chaos, and sometimes like you're one problem away from giving up completely.

That has been part of the story of HK NPU STUDIO.

🚀 What is HK NPU STUDIO?

HK NPU STUDIO is my project to build a local AI studio for Snapdragon-powered Windows ARM PCs, with a clear focus on the NPU.

My goal sounds simple, but in practice it is challenging:

run AI locally
use the Snapdragon NPU as the core accelerator
avoid unnecessary cloud dependency
keep control in the hands of the user
build something practical, reliable, and useful

This is not just about making AI run.

It is about building a product with a clear direction:

Your Hardware • Your AI • Your Control

💡 The idea behind it

From the beginning, I had a bigger vision for HK NPU STUDIO.

I did not want it to become just another interface or a generic AI wrapper.

I wanted to find out what happens when local AI, Snapdragon NPUs, and real product development come together.

My long-term vision includes things like:

image generation
inpainting
photo restoration
AI-powered enhancement
local image editing
more control over models and execution paths
a product experience that becomes more polished over time

Not everything is possible yet.

Some parts are already working, some are still experimental, and some are goals for the future.

And that is exactly where the project stands today:

part real, part difficult, part unfinished — but moving forward.

✅ What is already possible

HK NPU STUDIO is no longer just an idea.

A lot of groundwork has already been done.

Today the project includes work around:

local image generation
ControlNet
NPU-based upscaling
Phoenix Boost
Photo Restoration
inpainting development
Qualcomm QNN / QAIRT runtime testing

A lot of this work is not glamorous.

It is not only:

“Look what I built.”

It is also:

testing
debugging
isolating failures
comparing runtime behavior
validating outputs
organizing model and runtime files
protecting known-good states
and trying not to break what already works

That is real development too.

⚠️ The hard part: reality

What makes a project like this difficult is not just writing code.

The real challenge is the combination of:

new hardware paths
runtime and version compatibility
Windows ARM specifics
tooling limitations
model packaging
deployment
licensing questions
product quality

There were many moments when I thought:

“This is getting too complicated.”

“Maybe this will never work properly.”

“Maybe I should stop here.”

And yes, I seriously considered giving up more than once.

But each time, I kept going.

Not because everything was easy, but because I wanted to understand the next problem.

I wanted to know why something was failing.

Then I would test another idea, compare another result, read another log, and move one step further.

That mindset has shaped this project as much as any technical decision.

🔍 Sometimes the problem is completely different from what it looks like

One thing this project has taught me is not to jump to conclusions too quickly.

Recently, an NPU context suddenly refused to load in an isolated test environment.

The errors looked like a much bigger compatibility problem between the runtime, the hardware, and the context itself.

The actual cause was far less dramatic:

one required catalog file was missing from the runtime package.

Add that file, run the exact same test again, and the failure disappears.

Situations like this are frustrating, but also valuable.

They remind me not to say too quickly:

“The model does not work.”

or:

“The hardware cannot do this.”

Sometimes that is true.

Sometimes one requirement somewhere in a long technical chain is simply missing.

And this is usually the point where, instead of giving up, I want to know even more badly why it does not work.

So I keep looking.

🗑️ I also learned to throw things away

Another important lesson:

Just because something technically works somehow does not mean it belongs in the product.

At one point I was experimenting with an image-editing path where it became clear that the existing model could probably be pushed in roughly the right direction with enough tricks.

But the architecture was not really designed for the job.

I could have kept bending the implementation around it.

I decided not to.

A proof of concept is not automatically a product feature.

If the result is not reliable enough, or if the technical foundation is wrong, I would rather put an idea aside and come back later with a better approach.

In the long run, I would rather have fewer features I can stand behind than a long list of features that only work under very specific conditions.

⚡ NPU first means NPU first

Photo Restoration is a good example of a rule I set for myself.

If I describe a feature as an NPU feature, I want the actual neural inference to run on the NPU.

Of course, the CPU still has work to do.

Images need to be loaded.

Data needs to be prepared.

Masks and intermediate results may need to be calculated.

Files need to be written.

That is normal.

What I do not want is to describe something as NPU-accelerated while the actual AI inference quietly happens on the CPU or GPU.

That is a line I have drawn for the project.

🚀 Where I want HK NPU STUDIO to go

I have a fairly clear idea of what HK NPU STUDIO could become.

My vision goes well beyond pure image generation.

I want to be able to:

create images locally
restore old or damaged images
upscale them
edit specific image regions
remove unwanted objects
add new content
continue working with an image locally

And wherever it technically makes sense, I want the AI processing to run on the Snapdragon NPU.

That does not mean I can promise when, or even whether, every idea will become a finished feature.

Some things are already surprisingly possible with current hardware and models.

For others, suitable models, NPU contexts, runtime support, or simply the quality I expect from a real product feature are still missing.

That boundary is exactly what I find interesting:

What is truly possible today — and what may only become practical with the next hardware or runtime generation?

🔬 The technology does not stand still

That is why I do not think of HK NPU STUDIO as something that will simply be “finished” one day.

Qualcomm keeps developing its AI runtimes.

New Snapdragon generations appear.

Models change.

New possibilities emerge.

Other approaches disappear again.

Right now, for example, I am spending time evaluating newer QAIRT runtime versions.

For me, it is not enough to see that a new runtime starts successfully.

I want to know whether an existing NPU context still behaves correctly.

So I test:

the same context

with the same input

on different runtime versions

and compare the actual outputs.

If the result is exactly identical, that tells me much more than simply knowing that the application did not crash.

My development process has changed because of experiences like this.

Today I try to follow a simple rule:

Prove the cause before changing code.
Change one variable.
Compare before and after.
If the result gets worse, revert it.
Then move to the next step.

It sounds slower.

Most of the time, it saves a lot of time.

🐛 Feedback from other users changed the project too

Another important part of the project has been people running HK NPU STUDIO on systems other than mine.

Some problems would probably never have appeared on my own development machine.

Hardcoded paths are a good example.

Something can work perfectly for months because all expected directories happen to exist on one system.

Then someone installs the software on another PC and suddenly a hidden assumption becomes obvious.

Those reports are not always fun to receive.

You think something is finished, and then a new issue appears.

But constructive criticism and good bug reports have made HK NPU STUDIO significantly better.

So today I am grateful for both kinds of feedback:

“Works for me.”

and:

“Nothing works here.”

Sometimes the second one leads to the more interesting work.

🤖 I am developing myself too, not just the software

I am not a large development team.

And I do not have an immediate answer for every problem.

A lot of what I do, I learn while working on the project.

I read documentation, analyze failures, compare versions, test hypotheses, and try different approaches.

And of course I also use modern AI tools.

It would be a little strange to work on a local AI project and refuse to use them.

They help me:

analyze problems
challenge ideas
write and review tests
improve documentation
search for possible causes

But the final test is always real.

A theoretically perfect suggestion is useless to me if the application works worse afterward.

The code has to run.

The NPU has to actually be used.

The result has to be correct.

And if I am preparing a release, the whole thing needs to work outside my development environment too.

That combination of modern tools, experimentation, and real hardware validation has become a major part of how I work on HK NPU STUDIO.

🌍 Open source also means making development visible

HK NPU STUDIO is a public project.

Of course I want to release software that is as good as I can make it.

But I also think it is important not to pretend that development always follows a straight line.

There are:

bugs
wrong decisions
discarded approaches
features that take longer than expected
ideas that simply turn out not to be good enough

For me, that is also part of an open project.

The finished result is not the only interesting part.

The problems, decisions, wrong turns, and sometimes the realization that an approach is simply not good enough are part of the story too.

Feedback from users has already forced me to rethink assumptions and improve parts of the project more than once.

I do not see that as a weakness.

I think that is how an experiment slowly becomes reliable software.

🔭 I still do not know where this ends

I do not know what HK NPU STUDIO will look like in one or two years.

Maybe future Snapdragon generations will make things practical that still seem unrealistic today.

Maybe new models will push local image editing much further on the NPU.

Maybe I will discover that some ideas simply do not make sense.

What I do know is that I still have a lot of things I want to try and improve.

And even though I have more than once reached the point where I thought I had no patience left for another runtime issue, another failed test, or another error that made no sense, I have always come back so far.

Usually with the same thought:

“There has to be a reason why this does not work.”

And then I start looking again.

Maybe that describes HK NPU STUDIO better than any feature list.

For me, it is a project about finding out what local AI on this hardware can really do — and then pushing that boundary a little further each time.

To everyone who tries the project, reports bugs, suggests improvements, challenges decisions, or simply tells me that something works:

Thank you.

You have contributed more to its development in some areas than you may realize.

I’m curious to see how far local AI on Snapdragon PCs can go — and how far HK NPU STUDIO can go with it.