Skip to main content
A lot of edge AI projects started on NVIDIA Jetson for good reasons: the development loop was familiar with tools like Linux, Python, PyTorch, CUDA, TensorRT, OpenCV, and often DeepStream. A team could train a model, export it, optimize it with TensorRT, attach it to a camera pipeline, and ship a working prototype quickly. When that same team looks at Qualcomm Dragonwing hardware, the first question is usually:
If by “model” you mean a PyTorch checkpoint like best.pt, the answer is mostly yes. That is the good news: if you already have the trained PyTorch model, exporting it to a clean, static ONNX graph gets many supported vision models a large part of the way to Qualcomm. Not 100% of the way, and not for every operator, but far enough that the migration often becomes an optimization and productization problem instead of a retraining problem. The most important distinction is this:
A TensorRT .engine file does not migrate to Qualcomm. It is already a compiled, NVIDIA-specific deployment artifact tied to TensorRT, CUDA, JetPack, and the GPU architecture it was built for. But the source model behind that engine is still valuable. If you have the .pt or a clean ONNX export, you are not starting over. The rest of the work is making that model fast, accurate, measurable, and shippable on Dragonwing. For this series, we’ll focus around a Jetson smart-camera applkication with a custom YOLO detector, a TensorRT engine, CUDA/DeepStream-style preprocessing, and an optional local LLM sidecar. The target is a Dragonwing IQ-9075 first, with IQ-8275 called out where the setup or runtime differs. Before you start a migration, collect the boring facts first:

​
The Jetson mental model

A common Jetson deployment path looks like this:
For a camera application, the surrounding stack often looks like this:
The developer experience is centered around TensorRT and CUDA. You might use trtexec to build and benchmark:
If TensorRT rejects an operator, you rewrite the graph or write a TensorRT plugin. If you need INT8, you use TensorRT calibration. If you profile, you use trtexec, Nsight Systems, Nsight Compute, tegrastats, or DeepStream profiling. That is a coherent world. But it is not the Qualcomm world.

​
The Dragonwing mental model

On Dragonwing, the high-level path is different, but the first move is familiar:
That ONNX export is the bridge. For many conventional vision models with supported operators, getting a clean static ONNX model means the core model migration is already mostly solved. The remaining work is deployment engineering:
Qualcomm migration is usually not “retrain the model from scratch.” It is “turn the model you already trained into a production artifact for a different accelerator stack.”

​
The onboarding-speed gap is real

Do not describe these paths as equivalent: Jetson often gets from “I found a model” to “inference runs” with a framework/runtime path that hides more hardware-specific work. Qualcomm can provide a similarly fast first result when the model is already covered by AI Hub, GenieX, LiteRT, or another validated runtime path. The gap appears when the model is custom: export, quantization, context generation, target-specific packaging, and unsupported-operator debugging are real gates. The practical distinction is more useful than implying that every model is “mostly solved” after ONNX export:
The optimized endpoint is often a QAIRT/QNN context binary, not a TensorRT engine. A practical Qualcomm model lifecycle looks like this:
Qualcomm deployment is more ahead-of-time than the common TensorRT workflow. You prepare artifacts for the target SoC, SDK, BSP, backend, and precision.

​
Jetson vs Dragonwing at a glance

The short version:
Naming note: this series uses HTP/NPU for the Hexagon Tensor Processor acceleration path. Some tools expose that path through DSP or HTP backend names, such as --backend dsp; GenieX and product material may call it NPU.

​
Hardware targets matter

Best practice: avoid treating every Qualcomm target as interchangeable. Naming note: the family name is often written as IQ-9/IQ-8, while setup pages and AI Hub device names usually use IQ-9075/IQ-8275 EVK. Use the EVK name when selecting devices or docs. From the current Dragonwing device docs, where these are vendor-published peak capabilities rather than measured results (IQ-9075 EVK device overview and IQ-8275 EVK device overview): That affects context binary generation, runtime libraries, VTCM settings, performance expectations, and validation. For example, best practice is to rebuild and revalidate a context binary when moving to another SoC. A QAIRT SDK update, BSP update, new target SoC, or model update may require the same treatment. This is a major shift for teams used to treating a model file as the product artifact.

​
Before you commit: migration fit check

Do this check before building a conversion pipeline: If this table has unknowns, treat the first Dragonwing milestone as an evaluation, not a porting commitment.

​
The migration starts with one question: do you have the source model?

Before writing new code, inventory what you actually have. If you have this, you are in good shape:
For a PyTorch model, the first useful milestone is boring:
Then validate that ONNX on CPU before doing anything accelerator-specific. The files around the model matter too:
Jetson-specific artifacts that do not transfer directly:
If the only thing you have is model.engine, the migration is blocked until you recover the source model. A TensorRT engine is not a neutral model exchange format.

​
Check AI Hub before building a conversion pipeline

The fastest Qualcomm path is often not conversion. It is reuse. Check for a compatible artifact before investing in a custom conversion pipeline. If your model architecture already exists in Qualcomm AI Hub, you may be able to download a prebuilt artifact or at least get premeasured performance for the target device. For example:
The current docs reference the AI Hub IoT model catalog as the source of truth, with hundreds of model variants across LLMs, VLMs, vision, audio, depth, restoration, and robotics. If a compatible artifact exists, you may skip the hard part:
That is the shortest path to a working demo.

​
Runtime choice is a product decision

Dragonwing gives you more than one execution target:
Use CPU first when you need correctness and debugging. CPU execution is slower, but it removes accelerator-specific variables while you validate preprocessing, tensor layout, output decoding, and postprocessing. Use GPU as a middle path when the model or app benefits from floating-point acceleration, when the HTP path is not ready, or when an operator is awkward for NPU deployment. Be aware that GPU use can contend with display or graphics work. Use HTP/NPU when the goal is efficient edge inference. That is where quantization and target-specific artifacts matter most. Avoid blanket statements like “Qualcomm requires quantization.” More precise wording:
Qualcomm CPU execution can run floating-point models. GPU execution may be a useful middle path depending on runtime and operator support. HTP/NPU acceleration generally expects low-precision artifacts such as INT8/a8w8 or related supported modes for best performance and support.

​
Validate before benchmarking

A benchmark on a broken model is noise. Before collecting latency or throughput numbers, verify the accelerator:
Then validate the model output against the right baseline. For a migrated model, the baseline should usually be ONNX Runtime FP32, not TensorRT FP16. Why not TensorRT? Because TensorRT has already applied NVIDIA-specific graph transformations, precision choices, and plugin behavior. The neutral comparison point is the source-model export. A good validation chain looks like this:
Only then should you publish latency, FPS, power, or tokens/sec.

​
Four migration tracks

This series breaks the migration into four common cases.

​
1. No model yet

Start with Qualcomm AI Hub or a reference model. Avoid creating a portability problem before you have a product problem.

​
2. Existing CNN, detector, or classifier

Recover the source model, export static ONNX, check AI Hub, then convert/quantize/build only if needed.

​
3. LLM, VLM, audio, or VLA workload

Treat this as a runtime orchestration problem, not just a model conversion problem. You now care about prompt formatting, prefill, decode, KV cache, memory, tokens/sec, TTFT, multimodal splits, and quantization sensitivity. Qualcomm paths include llama.cpp HTP and GenieX with QAIRT artifacts.

​
4. Full multimedia application

A smart camera is not just a neural network. It is a camera-to-inference-to-output pipeline. DeepStream and CUDA pieces need Qualcomm equivalents through IM SDK, GStreamer, QNN, display, encode, overlay, and tracking components.

​
What comes next

In the next post, we will avoid custom model migration entirely and do the fastest useful thing: get an IQ-9075 EVK booted, verify HTP, and run a known-good LLM and vision model. After that, the series follows the running smart-camera migration through YOLO model rebuild, quantization, GenAI/sidecar choices, IM SDK/GStreamer pipeline migration, and the optional transition from standard Ubuntu to a customer-maintained Yocto-based system using QLI resources.