JetPack 7.2 ships Jetson Linux 39.2, CUDA 13.2.1, TensorRT 10.16.2, Yocto recipes, Orin support, ISO installs, and Thor MIG preview. Full breakdown.
What JetPack 7.2 Actually Bundles
JetPack 7.2 pulls the core edge AI stack onto a single, versioned baseline: Jetson Linux 39.2 for the board support package, CUDA 13.2.1 for the compute layer, and TensorRT 10.16.2 for optimized inference. Treating these as one coordinated release matters because the driver, runtime, and inference libraries have to agree on ABI and kernel support. When you pin all three to the JetPack 7.2 baseline, you avoid the mismatch bugs that show up when a CUDA runtime is newer than the kernel modules shipped in the BSP.
The practical takeaway is to standardize your fleet on the full JetPack 7.2 set rather than upgrading components piecemeal. Record the exact CUDA 13.2.1 and TensorRT 10.16.2 versions in your build manifests so a device that misbehaves can be compared against a known-good reference.
Flashing and Reproducible Provisioning
This release adds ISO installs and Yocto recipes alongside the usual flashing path, which changes how you think about provisioning. ISO installs make it easier to bring a Jetson up the way you would a standard Linux box, which lowers the barrier for engineers who don't live in the embedded tooling every day. Yocto recipes go the other direction: they let you fold the Jetson image into a fully declarative build so the OS, kernel, and your application layer are produced from source-controlled definitions.
- Use ISO installs for bench work, prototyping, and one-off devices where speed of setup matters more than reproducibility.
- Use Yocto recipes for production fleets, where you need every image to be byte-for-byte auditable and rebuildable from a pinned manifest.
- Keep Orin devices on the same JetPack 7.2 baseline as newer hardware so one image definition can target the whole fleet.
MIG on Thor and Partitioning Inference
The Thor MIG preview brings multi-instance GPU partitioning to the edge. MIG carves a single GPU into isolated slices, each with its own memory and compute allocation, so several models or tenants can run without contending for the whole device. On an edge box that has to serve a few different workloads at once — say a detection model, a tracking model, and a small language model — partitioning gives each one predictable resources instead of letting a spike in one starve the others.
Because this is a preview, treat it as something to validate rather than depend on. Prototype your partition layout, measure whether the isolation actually holds under your real traffic, and keep a non-MIG fallback configuration ready. Preview features can shift behavior between releases, so isolate anything that assumes MIG is present behind a config flag.
A Migration Approach That Won't Bite You
Because JetPack 7.2 spans both older Orin hardware and the newer Thor line, plan the upgrade as a staged rollout rather than a flag day. Bring up a small canary group first, confirm your models still build and run under CUDA 13.2.1 and TensorRT 10.16.2, and only then push the image to the rest of the fleet.
Rebuild your TensorRT engines against the exact runtime shipped in this release rather than reusing serialized engines from an earlier stack, since engine files are tied to specific library and hardware combinations. Capture the working image with a Yocto recipe once it passes validation, so the next device you provision inherits the same tested configuration instead of drifting.