Qualcomm AI Hub Models: a model zoo wired to a hosted device lab
Qualcomm® AI Hub Models is our collection of state-of-the-art machine learning models optimized for performance (latency, memory etc.) and ready to deploy on Qualcomm® devices.
At a glance
- What is it?
- The repository ships PyTorch model definitions plus export, quantization and profiling scripts that run against Qualcomm's cloud-hosted hardware. The interesting part is not the model list, it is the compile-profile-verify loop, and that loop requires an API token.
- Who is it for?
- Adopt it if you are targeting Snapdragon NPUs and want compiled artifacts plus on-device latency numbers without owning the hardware; the export path through AI Hub Workbench is the only way to get QNN binaries from this repo. Do not adopt it if you need an offline, self-contained toolchain, since compilation, quantization and profiling all route through Qualcomm's hosted service and an API token.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not model selection, it is the last mile to an NPU
Plenty of repositories publish PyTorch checkpoints. Fewer publish the same model already compiled for a specific mobile accelerator, with a latency number measured on real silicon. That gap is what this project addresses. The README describes a collection of models "optimized for deployment on Qualcomm devices", and the operative word is deployment: each model in the directory can be compiled and profiled on a hosted Qualcomm device.
The audience is narrow and identifiable. You are building an Android, Linux or Windows application that will run inference on a Snapdragon CPU, GPU or Hexagon NPU. You have a model architecture you can live with, and your open question is whether it fits a latency and memory budget on the target chipset. The repository answers that question with a command rather than with a spreadsheet. If you are training models or serving them from a datacenter, this is not aimed at you.
What actually ships: model definitions, per-model apps, and export scripts
The layout is consistent. Models live under src/qai_hub_models/models/<model_id>, and the README points at yolov7 as the illustration. Each model directory carries its own README with any extra dependencies, which is why the README warns that "Some models (e.g. YOLOv7) require additional dependencies." Installation is per-model through an extras group, as in pip install "qai_hub_models[yolov7]".
Python applications are defined for all models, importable as from qai_hub_models.models.<model_name> import App. Those apps wrap inference with pre- and post-processing written in torch and numpy. The README is unusually direct about their status: they are "optimized to be an easy-to-follow example, rather than to minimize prediction time." Treat app.py as a reference for input shapes and output decoding, not as production inference code. Native sample applications live in a separate repository, qualcomm/ai-hub-apps, and are not part of this package.
The export pipeline is the product, and it runs on someone else's device
The central mechanism is a five-step sequence the README spells out for the export script. Compile the model for a chosen device and target runtime. Quantize it if applicable. Profile the compiled model "on a real device in the cloud". Run inference with sample input on that device and compare the on-device output against PyTorch output. Then download the compiled model to disk.
Step four is the one worth pausing on. The comparison between cloud device output and local PyTorch output is a correctness gate, not a benchmark. It is the mechanism that catches a quantization scheme that has quietly degraded accuracy, and it happens before you download anything. That ordering is sensible, and it is also the reason the workflow cannot be reproduced without network access to Qualcomm's infrastructure.
Two evaluation modes exist for demos: --eval-mode fp runs locally through PyTorch, and --eval-mode on-device routes inference to a cloud-hosted device. The local mode is the escape hatch when you want to check preprocessing and postprocessing without spending a workbench run.
Getting it running: pip, an API token, and one export command
Installation is a single pip command, with a platform caveat the README states plainly: only AMDx64 64-bit Python is supported on Windows for Snapdragon X Elite and X2 Elite users, and installation fails under Windows ARM64 Python. Supported interpreters are 3.10 through 3.13, with 3.10 marked as recommended.
The configuration step is where the dependency becomes visible. Compilation, on-device profiling and related features require AI Hub Workbench access. You create a Qualcomm ID, log in to workbench.aihub.qualcomm.com, generate an API token from the account page, and run qai-hub configure --api_token API_TOKEN.
With that in place, the README's example is: qai-hub-models export yolov7 --target-runtime tflite --precision float --device "Samsung Galaxy S25 (Family)". A demo invocation looks like qai-hub-models demo yolov7 [--image ...] [--eval-mode {fp,on-device}] [--help].
There is also a separate lightweight CLI, installable as pip install qai_hub_models_cli (the README notes it is also available inside the qai-hub-models package). It offers qai-hub-models models to browse the catalog, qai-hub-models info mobilenet_v2 for model details and download options, and qai-hub-models fetch mobilenet_v2 --runtime tflite --precision float to pull a deployable asset. The fetch path matters: if a prebuilt artifact already exists for your runtime and precision, you may not need to compile anything at all.
Runtime and precision coverage, and where it runs out
Three on-device runtimes are listed. Qualcomm AI Engine Direct covers Android, Linux and Windows. LiteRT (TensorFlow Lite) covers Android and Linux. ONNX, via the QNN execution provider, covers Android, Linux and Windows. Note that LiteRT has no Windows entry, so a Windows laptop target narrows you to AI Engine Direct or ONNX.
Precision support is split by compute unit. CPU takes FP32, INT16 and INT8. GPU takes FP32 and FP16 only, so an INT8 GPU path is not on the menu. NPU takes FP16, INT16 and INT8, with an asterisk: some older chipsets do not support FP16 inference on their NPU. That footnote is the kind of detail that decides a project. If you pick FP16 for an NPU target on an older Snapdragon, the failure will surface at compile or profile time rather than in documentation you read beforehand.
The chipset list runs from Snapdragon 8 Gen 1 through 8 Elite Gen 5 on mobile, plus X Elite and X2 Elite for laptops. Anything outside that list is unverified territory as far as this material goes.
The limitation: your build depends on a hosted service and a token
The export workflow cannot be run fully offline. Compilation and profiling happen on Qualcomm's hosted devices, and the README frames workbench access as a prerequisite for "many features". That has consequences beyond convenience. Your CI pipeline needs a token and network egress. Reproducing a build months later depends on the hosted service behaving the same way it did before. If you work under constraints that forbid sending model artifacts to a third-party service, this repository's primary workflow is closed to you, and you are left with the local PyTorch path, which does not produce a deployable QNN binary.
The second limitation is the sample apps. The README states outright that the Python apps are written to be readable rather than fast. Anyone who lifts App from a model directory into a shipping application and then measures latency has measured the wrong thing. The native apps in ai-hub-apps exist for that reason.
The third is dependency surface. Per-model extras mean the install footprint varies by model, and a model whose README lists extra dependencies will fail at import time rather than at install time if you skip them.
How this differs from exporting through ONNX Runtime or LiteRT yourself
The obvious alternative is to take the same PyTorch checkpoint, export to ONNX or TFLite with the standard tooling, and run it through ONNX Runtime's QNN execution provider on hardware you already own. That path is fully local, has no account requirement, and gives you complete control over the conversion graph.
The difference in approach is where the verification happens. Doing it yourself, you produce a binary and then need a Snapdragon device, a harness and a reference implementation to know whether quantization cost you accuracy. Here, that verification is step four of the export script and runs before you receive the artifact. You are trading control and offline reproducibility for a managed correctness check and measured on-device latency on hardware you may not possess.
That trade is reasonable when you are evaluating several model architectures against a latency budget and do not want to buy five phones. It is a poor trade when you already have the target hardware in hand and a mature internal conversion pipeline, because you would be adding an external dependency to a problem you have already solved.
Release cadence, licence and what to check before you commit
Releases are frequent. The supplied material shows v0.59.0, v0.60.0 and v0.61.0 landing across roughly a two-month window in 2026, with the most recent push shortly after v0.61.0. A cadence that tight cuts both ways: fixes arrive quickly, and pinning a version is advisable if you depend on a specific export artifact. The package is published to PyPI as qai-hub-models, so version pinning is a normal pip constraint rather than a git ref.
The licence is BSD-3-Clause. That is permissive and generally permits commercial use and modification with attribution and without a copyleft obligation on your own code, but licence terms interact with the models themselves, with Qualcomm's service terms for AI Hub Workbench, and with your organisation's policies. Read the actual licence file and the workbench terms rather than treating this summary as advice.
Maintenance cost is mostly the token and the per-model extras. A model directory can gain dependencies between releases, and a demo that ran locally in --eval-mode fp can start requiring an extra package. The concrete thing to verify first is whether qai-hub-models fetch already serves the runtime and precision you need for your chosen model, because if it does, you can skip compilation entirely and the hosted-service dependency shrinks to a download.
Editorial conclusion
Adopt it if you are targeting Snapdragon NPUs and want compiled artifacts plus on-device latency numbers without owning the hardware; the export path through AI Hub Workbench is the only way to get QNN binaries from this repo. Do not adopt it if you need an offline, self-contained toolchain, since compilation, quantization and profiling all route through Qualcomm's hosted service and an API token. Before committing, run qai-hub-models export on one model you actually intend to ship, with the exact --target-runtime and --precision you plan to use, and confirm the downloaded artifact loads in your own runtime rather than only in the bundled demo.
Community notes