> ## Documentation Index
> Fetch the complete documentation index at: https://dragonwingdocs.qualcomm.com/llms.txt
> Use this file to discover all available pages before exploring further.
# From Jetson to Dragonwing: What Actually Migrates (Part 1 of 7)
> Understand which parts of a Jetson AI application are portable to Dragonwing, why ONNX is the bridge, and where Qualcomm-specific deployment work begins.
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:
```text theme={null}
Can I bring my model with me?
```
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:
```text theme={null}
Portable starting point:
best.pt / model.onnx / SavedModel / .tflite
Not portable:
TensorRT .engine / .plan
```
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:
```text theme={null}
[ ] source model or neutral export available
[ ] Jetson-only artifacts identified
[ ] target Dragonwing board and OS chosen
[ ] accuracy, latency, FPS, power, and thermal gates defined
[ ] validation data and sample inputs available
[ ] runtime lane selected: CPU, GPU, HTP/NPU, LiteRT, QNN, or GenieX
```
***
## The Jetson mental model
A common Jetson deployment path looks like this:
```text theme={null}
PyTorch / ONNX source model
-> TensorRT build
-> .engine
-> CUDA GPU inference
```
For a camera application, the surrounding stack often looks like this:
```text theme={null}
camera / V4L2 / Argus
-> GStreamer or DeepStream
-> CUDA preprocessing
-> TensorRT inference
-> tracking / overlay
-> display / encode / stream
```
The developer experience is centered around TensorRT and CUDA. You might use `trtexec` to build and benchmark:
```bash theme={null}
trtexec \
--onnx=model.onnx \
--saveEngine=model.engine \
--fp16
```
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:
```text theme={null}
best.pt
-> export to static ONNX
-> validate ONNX on CPU
-> optimize for the target Qualcomm runtime
```
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:
```text theme={null}
ONNX source model
-> check AI Hub first
-> convert to a Qualcomm artifact if needed
-> quantize if targeting HTP/NPU
-> build target-specific context binary
-> deploy runtime bundle
-> validate accuracy
-> profile latency, power, and memory
-> integrate into the app pipeline
```
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:
| Starting point | Fastest credible Qualcomm path | What “first inference” means |
| --------------------------------------------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------- |
| Model already supported in AI Hub or GenieX | Download the device-matched artifact and run the reference command | A working model on the board, often a Day 0 exercise |
| Common model with a clean source export | ONNX -> CPU validation -> QNN/QAIRT artifact -> target runtime | A short porting project, not a one-command copy |
| Custom model with unsupported operators or custom CUDA behavior | Graph repair, quantization trials, fallback/custom-op work, and app integration | Potentially several iterations and specialist help |
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:
```text theme={null}
Known-good supported model -> fast Day 0 inference
Custom model -> staged migration with more upfront integration work
```
The optimized endpoint is often a QAIRT/QNN context binary, not a TensorRT engine.
A practical Qualcomm model lifecycle looks like this:
```text theme={null}
0. Inventory existing Jetson artifacts
1. Recover source model
2. Export / validate static ONNX
3. Check AI Hub for a ready artifact
4. Convert source model to a QNN model library or use an AI Hub / DLC-style artifact
5. Quantize if targeting HTP/NPU
6. Build target-specific context binary
7. Deploy model and runtime libraries
8. Run inference and profile
9. Validate against the source-model baseline
```
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
| Area | Jetson | Dragonwing |
| -------------------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Compile model | TensorRT JIT/runtime engine build | QAIRT/QNN AOT context binary generated offline |
| Conversion | TensorRT tools | Local QNN SDK lane: ONNX -> QNN `.cpp/.bin` -> model `.so`; AI Hub / DLC-style lane: ready artifact or DLC |
| Quantization | TensorRT INT8 calibration | AIMET PTQ/QAT + QNN converter quantization flow |
| Graph optimization | TensorRT automatic fusion | QAIRT/QNN graph preparation and compiler optimization |
| Custom ops | TensorRT plugins / UDO | QNN Custom Op Package / UDO |
| Primary runtime | TensorRT | QAIRT/QNN primary |
| Open-source runtimes | Not the main Jetson path | LiteRT, ExecuTorch, ONNX Runtime QNN EP |
| Accelerators | CUDA GPU | HTP/NPU, Adreno GPU, CPU |
| Vision pipeline | DeepStream / GStreamer | IM SDK / GStreamer |
| Profiling | Nsight Systems / Nsight Compute | QNN profiler / platform tracing |
The short version:
```text theme={null}
Jetson optimized artifact:
TensorRT .engine
Qualcomm optimized artifact:
AI Hub artifact, QAIRT/QNN context binary, LiteRT model, or GenieX package
```
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](/Linux/devices/iq9075-evk/device-overview) and [IQ-8275 EVK device overview](/Linux/devices/iq8275-evk/device-overview)):
| Device | SoC | HTP arch | Accelerator note | Peak |
| ------- | ------- | -------: | ---------------: | ------------: |
| IQ-9075 | QCS9075 | v73 | 2x NPU | 100 TOPS |
| IQ-8275 | QCS8275 | v75 | dual HTP | up to 40 TOPS |
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:
| Question | Why it matters |
| ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| How many cameras, at what resolution and FPS? | Determines camera, ISP, memory bandwidth, and encode load. |
| Does the model fit the target memory and supported operators? | Avoids discovering too late that the model needs graph surgery or a different runtime. |
| What latency, FPS, power, and thermal targets define success? | Qualcomm may win on product power even when a narrow GPU benchmark differs. |
| What CUDA, TensorRT plugin, or DeepStream behavior is custom? | Custom platform code is usually more work than the neural net. |
| Which OS path is required: Ubuntu evaluation, customer-maintained Ubuntu, or a Yocto-based system using QLI resources? | Runtime packages, services, updates, security, and maintenance ownership change with the OS strategy. |
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:
```text theme={null}
.pt / .pth / .onnx / SavedModel / .tflite
```
For a PyTorch model, the first useful milestone is boring:
```bash theme={null}
yolo export model=best.pt format=onnx imgsz=640 dynamic=False nms=False
```
Then validate that ONNX on CPU before doing anything accelerator-specific.
The files around the model matter too:
```text theme={null}
preprocessing code
postprocessing code
labels and model config
validation data
accuracy SLA
latency/FPS/power requirements
```
Jetson-specific artifacts that do **not** transfer directly:
```text theme={null}
TensorRT .engine / .plan
TensorRT INT8 calibration cache
CUDA kernels
DeepStream config as-is
JetPack-pinned Docker containers
```
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:
```bash theme={null}
python3 -m venv ~/qaihub-venv
source ~/qaihub-venv/bin/activate
pip install qai-hub-models
qai-hub-models perf yolov8-det \
--device "Dragonwing IQ-9075 EVK"
qai-hub-models perf mobilenet-v3-large \
--device "Dragonwing IQ-9075 EVK"
```
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:
```text theme={null}
convert -> quantize -> build context binary
```
That is the shortest path to a working demo.
***
## Runtime choice is a product decision
Dragonwing gives you more than one execution target:
```text theme={null}
CPU
Adreno GPU
HTP/NPU
```
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:
```bash theme={null}
qnn-platform-validator --backend dsp --testBackend
```
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:
```text theme={null}
PyTorch output
-> ONNX Runtime FP32 output
-> FP32 Qualcomm artifact output
-> quantized HTP output
```
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.