# YOLOv8 on Jetson Orin Nano: TensorRT, INT8 and Real FPS *Published: 2026-09-29 | Author: Jason Ratzlaff* To run YOLOv8 on Jetson Orin Nano, train the model on a workstation, copy the `.pt` weights to the board, and export them to a TensorRT engine on the Jetson itself with `yolo export model=best.pt format=engine half=True`. FP16 TensorRT is the default choice: in Ultralytics’ published Orin Nano Super benchmarks it runs YOLO11n about three times faster than plain PyTorch with almost no accuracy change. INT8 goes further, but only after you calibrate it on your own images and check the accuracy. I build hardware and software end to end, and the Jetson Orin Nano turns up in a lot of those builds: a shelf-audit camera in a store, a trail camera that sorts animals before it uploads anything, a camera over a conveyor that flags bad parts. The model is rarely the hard part. What decides whether it works is the rest: how the dataset is labelled, where the engine gets built, which precision you pick, what power mode the board is in and whether it throttles once it gets warm. This guide covers that whole path. Every speed number in it comes from a published source, either the [Ultralytics NVIDIA Jetson guide](https://docs.ultralytics.com/guides/nvidia-jetson/) or [NVIDIA’s Jetson Linux power documentation](https://docs.nvidia.com/jetson/archives/r36.4.3/DeveloperGuide/SD/PlatformPowerAndPerformance/JetsonOrinNanoSeriesJetsonOrinNxSeriesAndJetsonAgxOrinSeries.html), and each one comes with the conditions it was measured under. The examples use public datasets (COCO and its small subsets) so you can reproduce them. What You Need to Run YOLOv8 on Jetson Orin Nano ----------------------------------------------- The Jetson Orin Nano is an Ampere-GPU module with 8 GB of shared LPDDR5 memory. The current developer kit is sold as the Orin Nano Super. It is the same hardware, flashed with a configuration that unlocks higher clocks. According to the [Ultralytics Jetson comparison table](https://docs.ultralytics.com/guides/nvidia-jetson/#nvidia-jetson-series-comparison): SpecJetson Nano (original)Jetson Orin Nano SuperAI performance472 GFLOPS67 TOPSGPU128-core Maxwell1024-core Ampere, 32 Tensor CoresGPU max frequency921 MHz1020 MHzCPU4-core Arm Cortex-A57, 1.43 GHz6-core Arm Cortex-A78AE, 1.7 GHzMemory4 GB 64-bit LPDDR4, 25.6 GB/s8 GB 128-bit LPDDR5, 102 GB/sSupported JetPack4 only5, 6, 7 That last row matters more than people expect. The original Jetson Nano is stuck on JetPack 4. The Orin Nano runs JetPack 6, which ships TensorRT 10, and that is the path the Ultralytics docs test today. If you are choosing hardware for a new YOLO project, start on Orin. ### Installing Ultralytics on JetPack 6 The quickest route is the prebuilt Ultralytics container for your JetPack release. It already has a CUDA-enabled PyTorch build, so you avoid the most common Jetson install problem: a pip-installed CPU-only torch. Terminal: start the Ultralytics JetPack 6 container on the Orin Nano``` t=ultralytics/ultralytics:latest-jetson-jetpack6 sudo docker pull $t && sudo docker run -it --ipc=host --runtime=nvidia $t ``` A native install works too (`pip install ultralytics`, then the Jetson-specific torch, torchvision and onnxruntime-gpu wheels listed in the guide). The guide warns you to keep the TensorRT 10.x runtime that comes with JetPack 6 and not to replace it with TensorRT 11.2.1, which does not support JetPack. Before your first export, check that the bindings are there: `python3 -c "import tensorrt; print(tensorrt.__version__)"`. How to Train YOLOv8 for a Jetson Deployment ------------------------------------------- Train on a desktop GPU or in the cloud, not on the Orin Nano. The Jetson is an inference device. Training on 8 GB of memory shared between CPU and GPU is slow and tends to crash. The `.pt` file you end up with is portable. The TensorRT engine you build from it is not, and that is the next section. ### Preparing a YOLO-format dataset Ultralytics detection datasets use [one `.txt` label file per image](https://docs.ultralytics.com/datasets/detect/), with one row per object in `class x_center y_center width height` format. Coordinates are normalized to 0–1 and class IDs start at 0. Images with no objects don’t need a label file. A dataset YAML ties everything together. Here is an example for a retail shelf-audit model: shelf.yaml: dataset config for an example shelf-audit detector``` path: /data/shelf # dataset root train: images/train val: images/val names: 0: product_facing 1: empty_slot 2: price_label ``` Two things matter more on the edge than anywhere else. First, the validation split should look like the deployment camera: same lens, mounting height, lighting and compression. INT8 calibration later reads its images from that split. Second, label the small objects you actually care about. An empty slot seen from a ceiling camera may be only a few dozen pixels wide at 640 input, and no export setting will bring back detail the training data never had. ![Grocery store aisle with fully stocked shelves, the kind of scene a shelf-audit detector is trained on](https://images.unsplash.com/photo-1670684684445-a4504dca0bbc?ixid=M3w4ODMzNjJ8MHwxfHNlYXJjaHwxfHxzdXBlcm1hcmtldCUyMHNoZWxmfGVufDB8MHx8fDE3OTA2NjUyMTd8MA&ixlib=rb-4.1.0&w=1520&q=80&fm=jpg&fit=crop&ar=16:9)Photo by [Jack Lee](https://unsplash.com/@jack19992011?utm_source=parkk_blog&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=parkk_blog&utm_medium=referral)### Training YOLOv8 (or YOLO11) from pretrained weights Start from COCO-pretrained weights and fine-tune on your data. The command is the same for every model family. Only the weights file changes: Terminal: fine-tune on a workstation, then validate``` # smoke test on the 8-image COCO8 sample first yolo detect train data=coco8.yaml model=yolov8n.pt epochs=3 imgsz=640 # real run on your dataset yolo detect train data=shelf.yaml model=yolov8n.pt epochs=100 imgsz=640 # same pipeline, newer architecture yolo detect train data=shelf.yaml model=yolo11n.pt epochs=100 imgsz=640 yolo val model=runs/detect/train/weights/best.pt data=shelf.yaml ``` Choose the model size for the latency budget on the Jetson, not for leaderboard accuracy. The benchmark section below gives real per-size timings on the Orin Nano Super. Look at those before you commit to a large or extra-large model. YOLOv8 TensorRT Export on Jetson -------------------------------- TensorRT is NVIDIA’s inference compiler. It fuses layers, picks the fastest kernel for each operation on your exact GPU and can run the network in reduced precision. Ultralytics calls it “the highest inference performance on NVIDIA Jetson devices” of all its export formats, and the numbers below support that. Copy `best.pt` to the Jetson and export there. ### FP16 export: half=True or quantize=16 Terminal on the Jetson: build and run an FP16 TensorRT engine``` # older Ultralytics releases (most YOLOv8 tutorials) yolo export model=best.pt format=engine half=True imgsz=640 # current releases: same result, new argument name yolo export model=best.pt format=engine quantize=16 imgsz=640 # run the engine yolo predict model=best.engine source=shelf_test.mp4 ``` Current Ultralytics releases replaced `half` and `int8` with a single `quantize` argument. According to the [export docs](https://docs.ultralytics.com/modes/export/), the old flags “are still accepted with deprecation warnings and forward to `quantize=16` and `quantize=8`,” so tutorials written for YOLOv8 still work. ### INT8 export and calibration data INT8 is post-training quantization. TensorRT runs your images through the network, records the range of every activation and picks scale factors from those ranges. That makes the calibration images part of the model: Terminal on the Jetson: INT8 engine calibrated on your validation split``` # older syntax yolo export model=best.pt format=engine int8=True data=shelf.yaml batch=8 workspace=4 # current syntax yolo export model=best.pt format=engine quantize=8 data=shelf.yaml batch=8 workspace=4 ``` The [Ultralytics TensorRT guide](https://docs.ultralytics.com/integrations/tensorrt/) gives the practical rules. Calibration uses the `val` images from your `data` YAML. NVIDIA recommends at least 500 representative calibration images. Small batches can scale the ranges wrongly. If you leave out `data`, Ultralytics quietly falls back to a small sample dataset instead of raising an error. That fallback is how people end up with an INT8 engine calibrated on a handful of sample images that look nothing like their camera. **A TensorRT engine only works on the setup it was built on.**TensorRT tunes the engine for the GPU and the TensorRT/CUDA runtime it was built with. Ultralytics says to “match the target’s GPU architecture and TensorRT/CUDA runtime” and to validate every engine on the deployment device, and that INT8 calibration should run on the target. Ship the `.pt` or ONNX file and build the engine on the Jetson, or in the same JetPack image the fleet runs. ### Does the Orin Nano have a DLA? No. The Orin NX and AGX Orin include Deep Learning Accelerator cores, and the Ultralytics docs show `device="dla:0"` exports for them. NVIDIA’s power-mode table lists **0 DLA cores** for every Orin Nano mode, and the Orin Nano is missing from Ultralytics’ list of DLA-equipped devices. On an Orin Nano, everything runs on the GPU. Jetson Orin Nano YOLO FPS: What the Published Benchmarks Show ------------------------------------------------------------- Ultralytics publishes per-format benchmarks for the Orin Nano Super Developer Kit. The YOLO11 table (benchmarked with Ultralytics 8.3.157, `imgsz=640`, mAP measured on COCO128) is kept in [the guide’s version history](https://github.com/ultralytics/ultralytics/blob/865ccb2eb1/docs/en/guides/nvidia-jetson.md). The live page now shows YOLO26. The figures are *inference time per image* for the model alone: YOLO11 inference time on Jetson Orin Nano Super PyTorch vs TensorRT FP16, imgsz 640, ms per image. Source: Ultralytics Jetson guide, Ultralytics 8.3.157 PyTorchTensorRT FP16 YOLO11n13.70 ms**4.53 ms** YOLO11s20.90 ms**6.93 ms** YOLO11m46.50 ms**13.50 ms** YOLO11l56.50 ms**17.48 ms** YOLO11x90.00 ms**32.58 ms** **3.0×**faster YOLO11n with TensorRT FP16*13.70 ms → 4.53 ms* **3.70**ms per image, YOLO11n as TensorRT INT8*mAP50-95 0.5101 → 0.4825* **32.58**ms per image, YOLO11x as TensorRT FP16*vs 90.00 ms in PyTorch* **~220**YOLO11n FP16 inferences per second*1000 ÷ 4.53 ms, model only* The last figure is simple arithmetic on the published latency, not a measured frame rate, and it leaves out everything around the model. The next section shows why that difference matters. The full picture across every size and precision: ![Bar chart of YOLO11 n to x inference time on Jetson Orin Nano Super for PyTorch, TensorRT FP32, FP16 and INT8, from the Ultralytics Jetson guide](https://www.parkktech.com/wp-content/uploads/2026/09/yolo11-orin-nano-super-tensorrt-latency.png)Published Ultralytics benchmark for YOLO11 on the Jetson Orin Nano Super Developer Kit: PyTorch, TensorRT FP32, FP16 and INT8 at imgsz 640. Chart drawn from the table in the Ultralytics NVIDIA Jetson guide (Ultralytics 8.3.157).### Where are the YOLOv8 numbers for Orin Nano? Ultralytics never published a YOLOv8 table for the Orin Nano. Its YOLOv8 Jetson benchmarks from 2024 were run on a [Seeed reComputer J4012 with an Orin NX 16GB](https://github.com/ultralytics/ultralytics/blob/fbc6bae5af/docs/en/guides/nvidia-jetson.md), a bigger module. On that board, YOLOv8n took 14.3 ms in PyTorch, 4.55 ms as TensorRT FP16 and 4.09 ms as INT8. That is the same shape as the YOLO11 results: roughly 3× from TensorRT FP16, then a small extra step from INT8. Treat those as a pattern, not as Orin Nano numbers. The same 2024 table also shows the INT8 trap. YOLOv8n’s mAP50-95 was 0.6093 at FP16 and **0.2759 at INT8**. Those benchmarks used COCO8, which has just four validation images. That is far too few to calibrate or to measure accuracy with. The later YOLO11 runs moved to COCO128, and there the INT8 drop for YOLO11n is 0.5061 to 0.4825. The export command is the same in both cases. The calibration data is what changed the result. ### YOLO11 and YOLO26 on the same board The live guide now benchmarks YOLO26 on the same Orin Nano Super kit. YOLO26n measures 15.60 ms in PyTorch, 4.57 ms as TensorRT FP16 and 3.80 ms as INT8. That is close to YOLO11n on the same board. Going from YOLOv8 to YOLO11 or YOLO26 is mostly a question of accuracy and features. On this hardware the choice of export format and precision moves latency far more than the choice of model family. FP16 vs INT8 TensorRT on Jetson Orin Nano ----------------------------------------- Here are both precisions from the same published Orin Nano Super run, using the smallest and largest YOLO11 models (mAP50-95 on COCO128): TensorRT INT8 when latency is the constraint YOLO11n latency3.70 ms YOLO11n mAP50-950.4825 YOLO11x latency19.90 ms YOLO11x mAP50-950.6612 Calibration dataRequired, on-device TensorRT FP16 the default choice YOLO11n latency4.53 ms YOLO11n mAP50-950.5061 YOLO11x latency32.58 ms YOLO11x mAP50-950.6892 Calibration dataNot needed The pattern is clear. For the nano model, INT8 saves less than a millisecond and costs a noticeable amount of accuracy. For the extra-large model it cuts 12.68 ms per image, from 32.58 to 19.90. My rule: ship FP16 unless the latency budget forces you down, and when you do go to INT8, pick the confidence threshold from the INT8 model’s own validation results. The TensorRT guide notes that INT8 “can still shift confidence values,” so a threshold tuned on the FP16 model can quietly lose detections. **Pick the model size first, then the precision.**In the published table, YOLO11s as TensorRT FP16 (6.93 ms) is faster than YOLO11n in plain PyTorch (13.70 ms). Exporting correctly gets you a bigger, more accurate model for the same latency budget. How to Measure FPS on Jetson Honestly ------------------------------------- A benchmark table reports one stage of the pipeline. A camera system runs all of them, one after another, unless you put them in separate threads: ![Illustrative diagram of a Jetson vision pipeline: capture and decode, pre-process, TensorRT inference, post-process, application; benchmark figures cover inference only](https://www.parkktech.com/wp-content/uploads/2026/09/yolo-jetson-fps-pipeline.png)Illustrative diagram, not measured data: published “ms/im” figures cover only the inference stage. Capture, decode, pre-processing, post-processing and your own application code all add to the time per frame.### Reproduce the published benchmark on your board Run the Ultralytics benchmark yourself to confirm your board, JetPack and power mode line up with the published setup. Use COCO128 or the full COCO val set. Don’t use COCO8, for the reasons above. Terminal on the Jetson: format-by-format speed and accuracy``` yolo benchmark model=yolov8n.pt data=coco128.yaml imgsz=640 # most reliable accuracy numbers: full COCO val (5,000 images) yolo benchmark model=yolov8n.pt data=coco.yaml imgsz=640 ``` ### Time your real pipeline, stage by stage Every Ultralytics `Results` object has a `speed` dictionary that holds pre-process, inference and post-process times in milliseconds. Log it on your own footage, and time the whole loop as well: Python on the Jetson: per-stage and end-to-end timing on a real video``` import time from ultralytics import YOLO model = YOLO("best.engine") t0, n = time.perf_counter(), 0 for r in model("conveyor_test.mp4", stream=True, verbose=False): n += 1 if n % 100 == 0: print(r.speed) # {'preprocess': ..., 'inference': ..., 'postprocess': ...} print(f"end-to-end: {n / (time.perf_counter() - t0):.1f} FPS over {n} frames") ``` 1. **Warm up first.** The TensorRT guide warns that the first few inference calls on an INT8 engine run slower than normal. Throw away at least the first few dozen frames. 2. **Use your deployment input.** Same resolution, same codec, same source (CSI, USB or RTSP). Decoding a 4K file is a very different load from reading a 720p USB camera. 3. **Record the power mode.** Log the output of `sudo nvpmodel -q` with every result, so numbers from different runs can be compared. 4. **Run long enough to heat-soak.** A 30-second test measures a cold board. Run for tens of minutes in the real enclosure and compare the first minute with the last. Jetson Orin Nano Power Modes, jetson\_clocks and Thermals --------------------------------------------------------- The same engine runs at different speeds depending on the nvpmodel power mode. NVIDIA’s [Jetson Linux 36.4.3 documentation](https://docs.nvidia.com/jetson/archives/r36.4.3/DeveloperGuide/SD/PlatformPowerAndPerformance/JetsonOrinNanoSeriesJetsonOrinNxSeriesAndJetsonAgxOrinSeries.html) defines these modes for the Orin Nano 8GB Super configuration: Mode (ID)Power budgetCPU cores / max MHzGPU max MHzMemory max MHz15W (0)15 W6 / 1497.6612213325W (1), default25 W6 / 13449183199MAXN\_SUPER (2)n/a (uncapped)6 / 172810203199 **On the Super configuration, `nvpmodel -m 0` is the 15 W mode, not the fastest one.**Many guides, the Ultralytics one included, say to run `sudo nvpmodel -m 0` for maximum performance. Mode IDs are not the same on every module. On an Orin Nano flashed with the Super configuration, NVIDIA’s table assigns ID 0 to 15 W, ID 1 to 25 W and ID 2 to MAXN\_SUPER. Check with `sudo nvpmodel -q` before you trust any FPS number. Terminal on the Jetson: set the power mode, pin clocks, watch temperatures``` sudo nvpmodel -q # show the current mode sudo nvpmodel -m 2 # MAXN_SUPER on a Super-flashed Orin Nano sudo jetson_clocks # pin CPU/GPU/EMC at the mode's maximum sudo jetson_clocks --show # confirm sudo pip install jetson-stats && sudo reboot jtop # live GPU load, clocks, temps, power ``` Two notes from NVIDIA’s documentation. Changing mode can require a reboot, because the GPU core mask can only be set before the GPU context is created, so script your deployments to handle that. MAXN\_SUPER is described as an *experimental*, unconstrained mode, and of MAXN NVIDIA says it “does not guarantee the best performance for all use cases because hardware throttling is engaged when the total module power exceeds the TDP budget.” ### Thermals: the number that changes after ten minutes Jetson Orin thermal management has several layers. The kernel handles fan cooldown and software clock throttling. The on-chip BPMP handles hardware slowdown. Both can shut the module down when it gets too hot. The default fan profile on Orin is “cool”. `jtop` and `tegrastats` show clocks and thermal-zone temperatures live. Keep one of them logging during long tests, and if the GPU clock falls during the run, the enclosure is the bottleneck, not the model. For a sealed wildlife camera or a factory enclosure next to a hot machine, choose the power mode that holds steady at your worst-case ambient temperature. That can mean deliberately running 25 W instead of MAXN\_SUPER, and spending the headroom on a smaller model or INT8. A frame rate that holds for eight hours matters more than a peak that lasts ten minutes. ![Trail camera strapped to a tree trunk in a forest](https://images.unsplash.com/photo-1754351009200-a4f36f3bac28?ixid=M3w4ODMzNjJ8MHwxfHNlYXJjaHwyfHx3aWxkbGlmZSUyMHRyYWlsJTIwY2FtZXJhfGVufDB8MHx8fDE3OTA2NjUyMTh8MA&ixlib=rb-4.1.0&w=1520&q=80&fm=jpg&fit=crop&ar=16:9)Photo by [Ali Kazal](https://unsplash.com/@lureofadventure?utm_source=parkk_blog&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=parkk_blog&utm_medium=referral)A Deployment Checklist for YOLO on Jetson Orin Nano --------------------------------------------------- 1. **Flash JetPack 6 with the configuration you intend to ship.** MAXN\_SUPER exists only on the Super flash configurations. 2. **Train and validate on a workstation** with a validation split that looks like the deployment camera. 3. **Export FP16 on the Jetson** (`half=True` or `quantize=16`) and check mAP against the `.pt` model with `yolo val`. 4. **Try INT8 only if the budget needs it,** calibrated on 500 or more representative images, then re-tune the confidence threshold. 5. **Measure end to end** on real footage, in the real enclosure, after heat soak, with the power mode logged. 6. **Rebuild engines when JetPack or TensorRT changes.** Treat the `.engine` file as a build artifact, not a checked-in asset. ![Operator running industrial machinery on a factory floor](https://images.unsplash.com/photo-1598299803204-b73796f43289?ixid=M3w4ODMzNjJ8MHwxfHNlYXJjaHwyfHxmYWN0b3J5JTIwY29udmV5b3IlMjBpbnNwZWN0aW9ufGVufDB8MHx8fDE3OTA2NjUyMTd8MA&ixlib=rb-4.1.0&w=1520&q=80&fm=jpg&fit=crop&ar=16:9)Photo by [Sam Moghadam](https://unsplash.com/@sammoghadam?utm_source=parkk_blog&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=parkk_blog&utm_medium=referral)Frequently Asked Questions -------------------------- How do I run YOLOv8 on a Jetson Nano?On the original Jetson Nano you are limited to JetPack 4, and Ultralytics provides a JetPack 4 Docker image (ultralytics/ultralytics:latest-jetson-jetpack4) for it. Pull it, copy your weights in, and export to TensorRT with format=engine on the device. For new projects the Jetson Orin Nano is the better target, because it supports JetPack 5, 6 and 7 and has a far larger GPU. What is TensorRT and how does it work?TensorRT is NVIDIA’s inference optimizer and runtime. It takes a trained network, fuses layers, picks the fastest kernels for the exact GPU it is building on, and can run in FP16 or calibrated INT8 precision. The result is an .engine file tuned to that GPU and TensorRT version, which is why you build it on the Jetson itself. Can Jetson Orin Nano run YOLO in real time?Yes, for the smaller models. In Ultralytics’ published Orin Nano Super benchmark, YOLO11n takes 4.53 ms per image as a TensorRT FP16 engine and YOLO11s takes 6.93 ms at 640 input. Those figures cover inference only, so measure your full pipeline, including capture, decode and post-processing, before you promise a frame rate. Should I use FP16 or INT8 on Jetson Orin Nano?Start with FP16. In the published YOLO11 results it cuts latency by about three times compared with PyTorch while mAP barely moves, and it needs no calibration data. Use INT8 when you need more speed, calibrate it on at least a few hundred representative images from your own camera, and re-check accuracy and confidence thresholds afterwards. Is YOLO11 faster than YOLOv8 on Jetson?Ultralytics has not published YOLOv8 and YOLO11 benchmarks for the same Jetson board, so there is no direct comparison. On their respective published boards, the nano models land within a fraction of a millisecond of each other as TensorRT FP16 engines. On the Orin Nano, export format and precision affect latency far more than the model generation does. Does Jetson Orin Nano have a DLA?No. NVIDIA’s power-mode tables list zero DLA cores for every Orin Nano mode, and Ultralytics lists DLA exports only for AGX Orin, Orin NX and Xavier modules. On the Orin Nano, YOLO runs on the Ampere GPU through TensorRT. How do I check my JetPack version and power mode?Run sudo nvpmodel -q to see the current power mode. Install jetson-stats and run jtop, which shows JetPack information along with live clocks, temperatures and GPU load. Record both alongside any FPS number you report. Building an edge-AI camera on Jetson? ------------------------------------- I design the whole thing: carrier boards and PCBs, enclosures and thermals, the model, and the TensorRT pipeline that runs on the device. If you have a vision product that needs to leave the lab, let’s talk. [Start the conversation](https://www.parkktech.com/contact/) --- **Parkk Technology** — Custom Software Development, AI Integration, and Equity Partnerships - Custom Software Development: We build the software your business actually needs — scoped, shipped, supported. - AI Integration for Existing Businesses: Add AI capabilities to what you already have — without rebuilding everything. - Equity Partnership: Considered case by case for validated problems. No fixed package. Contact: https://www.parkktech.com/contact | Author: Jason Ratzlaff, founder of Parkk Technology