A TensorRT engine can be reused across identical Jetson devices with matching software, but a saved engine stays tied to the hardware and software it was built for. For an Orin-to-Thor move, plan to rebuild for the target. For a software update on the same device, recover the engine’s build settings before deciding whether reuse is supported. The useful first question is what changed between the build environment and the destination.
This distinction matters when a working robot needs a replacement computer. Rebuilding every engine on every replacement board adds deployment work; copying the only engine you have without its build record leaves you unable to explain a failure. Keep the model and build recipe alongside the engine so either route remains available.
Choose reuse or a target build from what changed
For a replacement board, separate a matched fleet from a platform migration:
| Change you are making | Practical next action |
|---|---|
| A second unit of the same Jetson model with the same installed image and plugins | Try the trusted, existing engine in a staged deployment; compare outputs and resource use before replacing the working release. |
| Orin to Thor, or a different Jetson model | Budget a target-specific build from the retained model and recipe. Keep the old engine for the old deployment. |
| Same board, different TensorRT package | Look for the original version-compatibility setting and runtime packaging. Without that evidence, schedule a rebuild instead of assuming the version number is close enough. |
| Same board and library names, but a changed plugin binary | Compare the plugin files and build record. A familiar filename can hide a changed library. |
| No record of where the engine came from | Recover the trusted source model and recipe. A filename such as final.engine carries none of that information. |
Start by comparing the recorded build and target environments. If the build version is missing, the archived TensorRT 10.x command-line reference documents an inspection option for plans created with 8.6 or later:
trtexec --loadEngine=model.engine --getPlanVersionOnly
Confirm the flag in the installed trtexec --help. It reports the plan version without deserializing it. The model, plugins and the rest of the build recipe still have to come from your own records.
In the August 2026 NVIDIA support discussion, the question concerned Orin NX 16GB devices with JetPack 6.2. NVIDIA staff supported building beforehand for a target with identical hardware and software versions. That answer covers a matched fleet; other Jetson products need their own build.
NVIDIA’s compatibility documentation ties an ordinary engine to its build version and device type. Hardware compatibility mode is unavailable on JetPack, so an Orin-to-Thor move still needs a target build. For the earlier computer-buying decision, see the Thor versus Orin upgrade comparison.
Read the JetPack version before following the newest TensorRT guide
As checked on October 13, 2026, NVIDIA’s JetPack downloads page lists JetPack 7.2.1 with Jetson Linux 39.2.1, CUDA 13.2.2 and TensorRT 10.16.2, supporting Thor and the Orin family. Check your robot’s installed packages separately; they can lag behind the release list.
The current TensorRT 11.4 Jetson migration page explicitly says JetPack is unsupported in TensorRT 11.4.0 and instructs Jetson deployments to use a TensorRT 10.x release supported by their JetPack version. Follow the 10.x guide that matches your JetPack, even when a newer heading appears first.
Version compatibility is also a build choice. NVIDIA’s TensorRT 10.x version-compatibility reference, now archived, describes forward-compatible builds and the lean runtime they require. It covers older engines in newer runtimes; a newer engine in an older runtime falls outside that promise. If the lean runtime was excluded from the plan, deployment must provide the appropriate runtime separately. Record those choices when building, because the .engine extension looks the same either way.
Recover the build record before changing the installation
Start with the engine that actually worked. Save its file hash, the source model hash, the build command or script, full TensorRT package version including the build component, CUDA and Jetson Linux versions, exact GPU model, and the plugin filenames and hashes. Keep input names, dtypes, shape profiles and any precision or calibration inputs with that recipe. Mark unknown historical values as unknown instead of filling in a plausible version string.
For a subsequent target test, retain the first error and the full environment record. Distinguish a failure to load the plan from a later wrong-shape request, missing plugin, incorrect output or missed latency target. Those observations lead to different repairs. Simply repeating the same build gives you little evidence about which problem you fixed.
Compare the recorded environments with a small Python script
The following standard-library script compares six recorded fields. It reports differences and unknowns and leaves the compatibility decision to you. An empty plugin dictionary means you recorded zero external plugin libraries; a missing dictionary means the plugin state is unknown. Include dependencies that your deployment actually loads.
Save this as compare_engine_context.py:
"""Compare two recorded contexts; this does not inspect or execute an engine."""
import json
import sys
FIELDS = ("gpu_model", "os_cpu_arch", "jetson_linux", "cuda_build",
"tensorrt_build", "plugin_hashes")
def compare(built, target):
differences, unknown = [], []
for key in FIELDS:
a, b = built.get(key), target.get(key)
if key == "plugin_hashes":
valid = lambda v: isinstance(v, dict) and all(
isinstance(k, str) and k.strip() and isinstance(x, str)
and x.strip() for k, x in v.items())
else:
valid = lambda v: isinstance(v, str) and bool(v.strip())
if not valid(a) or not valid(b):
unknown.append(key)
elif a != b:
differences.append({"field": key, "built": a, "target": b})
return {
"result": "REVIEW_CONTEXT" if differences or unknown else "RECORDED_CONTEXT_MATCH",
"differences": differences,
"unknown": unknown,
"limit": "Recorded fields only. No engine loading, hardware detection, or compatibility approval."
}
if __name__ == "__main__":
if len(sys.argv) != 3:
raise SystemExit("Usage: python compare_engine_context.py built.json target.json")
try:
with open(sys.argv[1], encoding="utf-8") as f:
built = json.load(f)
with open(sys.argv[2], encoding="utf-8") as f:
target = json.load(f)
if not isinstance(built, dict) or not isinstance(target, dict):
raise ValueError("Both contexts must be JSON objects")
print(json.dumps(compare(built, target), indent=2))
except (OSError, ValueError) as error:
raise SystemExit(str(error))
For a runnable example, save the following synthetic record as both built.json and target.json. The DEMO_ values are made-up example labels.
{
"gpu_model": "DEMO_ORIN_NX_16GB",
"os_cpu_arch": "DEMO_LINUX_AARCH64",
"jetson_linux": "DEMO_L4T_A",
"cuda_build": "DEMO_CUDA_A",
"tensorrt_build": "DEMO_TRT_A",
"plugin_hashes": {}
}
Run python compare_engine_context.py built.json target.json. With the identical records, it returns RECORDED_CONTEXT_MATCH. Change the target’s gpu_model to DEMO_THOR_T5000 and tensorrt_build to DEMO_TRT_B; it returns REVIEW_CONTEXT and identifies both changed fields. Remove plugin_hashes instead, and it reports that field as unknown. These three cases were reproduced with Python 3.12 on Windows using AI-assisted code.
A match means only that these recorded values agree. Mistyped versions, engine contents, available memory, input profiles and accuracy all need separate checks. Replace the demonstration values with observations from the build and target systems, and keep the complete release record beside this small comparison.
When the records match, move on to a staged target test using the same known inputs and expected outputs. When they differ, use the affected field to choose a supported compatibility route or rebuild. When a value is unknown, recover it before promoting the engine. The robot model-serving guide continues from there with application input contracts, latency and fallback behavior.
Before promoting the engine, run that staged test on the target Jetson with your own inputs. NVIDIA sources checked October 13, 2026.