An ONNX Model or a TensorRT Engine: What Can the Buyer Reuse?

Identify the artifact the buyer will retain

ONNX represents a model's inference computation as a graph. Inputs and outputs describe the values entering and leaving it; nodes describe operations; initializers can hold constant model parameters. Its operators have versioned definitions. This common representation lets tools exchange a description of the computation without making that description a particular GPU implementation.

TensorRT adds a compilation decision. NVIDIA describes a builder that selects GPU kernel implementations for the target and produces a serialized engine, also called a plan. The runtime then executes that engine. An engine therefore embodies implementation choices made for a deployment, whereas the ONNX graph describes the computation from which an implementation may be produced.

The commercial distinction is what remains available when the deployment changes. Retaining an engine provides the built artifact within its established coverage. Retaining the graph can provide an input to another build, if the required implementation support and dependencies are available. Neither a shared model name nor delivery inside a container makes these artifacts equivalent. An inference graph also should not be described as the complete original training checkpoint.

This comparison uses the general NVIDIA TensorRT inference-library documentation. Its conclusions do not extend to TensorRT-RTX or safety runtimes.

References: [O1][N1]

A graph's portability depends on its operators and implementation

NVIDIA's Architecture Overview identifies ONNX as the primary interchange path for importing trained models and describes the supplied ONNX parser. It explicitly declines to guarantee every operator and attribute from a named opset. The parser shipped with a TensorRT release and a separately obtained parser release can also have different coverage. An ONNX filename and opset number are consequently insufficient evidence that the proposed TensorRT toolchain can implement this particular graph.

Custom operators make that distinction visible. ONNX permits custom domains and operator definitions. Describing such a node does not supply its implementation in every destination runtime. NVIDIA also notes that a parsed TensorRT network can require plugin libraries. The useful deliverable therefore identifies the custom definitions and applicable implementation dependencies, including what must remain available for a later target.

Ask the proposed software supplier to explain one concrete regeneration path: which retained graph and parameters it would use, which parser and builder would interpret them, and how the necessary custom components would be supplied for the changed target. That explanation exposes a missing dependency more effectively than another generic installed-software list.

The graph is a potential build input, not a promise that every training model exports successfully or that every future target can be supported. Receiving files also does not establish permission to modify or redistribute their contents.

References: [N2][O1][N3]

Read default matching rules and compatibility routes together

The default TensorRT engine guarantee concerns the same GPU model, TensorRT version and OS/CPU platform used to produce it. NVIDIA's API-versioning discussion says serialized objects do not inherit the public API's semantic-versioning promise: without a qualified compatibility route, the engine and runtime version match includes major, minor, patch and build.

The documentation checked October 20, 2026 identifies 11.4.0 as the latest release in its navigation. Its Engine Compatibility page, dated October 5, documents several qualified routes. Version-compatible engines can use supported newer runtimes; the stated cross-major routes include TensorRT 10 to 11 and TensorRT 8 to 10, rather than arbitrary version pairs. Hardware compatibility separately offers Ampere-and-later or same-compute-capability coverage, with possible performance trade-offs. NVIDIA excludes DriveOS and JetPack from hardware compatibility.

Cross-platform compatibility is also explicit. NVIDIA describes building on Linux x86_64 for execution on Windows x86_64. Such an engine cannot also execute on its build-host platform. This is a specified destination, not universal portability across operating systems or CPU architectures.

For a purchase, these routes are properties to establish for the actual artifact. A general product capability does not prove that the supplied engine was built with the relevant coverage or includes its dependencies. Conversely, a changed GPU, runtime or platform is not automatically proof that a new engine is required. Have the appointed software provider connect the offered artifact to the applicable rule and its limits.

References: [N1][N2][N3][N4]

EP-202: two engines document two of eight requested targets

Fictional purchase EP-202 asks its software supplier to assess two GPU target types, H100 and B200; two TensorRT runtime releases, 11.3.0 and 11.4.0; and two OS/CPU platform combinations, Linux x86_64 and Windows x86_64. The eight named target tuples below count the requested coverage. They are not verified support combinations or application results; an actual proposal would refine the GPU variants and OS releases.

EP-202-T1 is H100 / TensorRT 11.3.0 / Linux x86_64. EP-202-T2 is B200 / TensorRT 11.3.0 / Linux x86_64.

EP-202-T3 is H100 / TensorRT 11.4.0 / Linux x86_64. EP-202-T4 is B200 / TensorRT 11.4.0 / Linux x86_64.

EP-202-T5 is H100 / TensorRT 11.3.0 / Windows x86_64. EP-202-T6 is B200 / TensorRT 11.3.0 / Windows x86_64.

EP-202-T7 is H100 / TensorRT 11.4.0 / Windows x86_64. EP-202-T8 is B200 / TensorRT 11.4.0 / Windows x86_64.

Offer A supplies two engines, each explicitly documented for its corresponding GPU target on TensorRT 11.3.0 and Linux x86_64: one for T1 and one for T2. That establishes documentary coverage for two tuples. The remaining six are unaddressed by the stated offer, rather than proven incompatible.

Nor does six unaddressed tuples mean six additional builds. One suitably qualified artifact could cover multiple targets where its actual build and the applicable documentation establish that coverage. Other requested targets might need different artifacts or remain unsupported. Multiplying the purchasing dimensions establishes the questions to resolve, not an engine-file count.

A's two-engine scope can be appropriate if the buyer only needs T1 and T2. If the buyer expects all eight targets or a later transition to one of them, the missing coverage changes the purchase discussion.

Offer B adds a supported regeneration discussion

In the same fictional comparison, Offer B supplies A's two engines plus the identified ONNX graph and parameters, necessary custom-operator definitions and plugin dependencies, and reproducible build inputs. Those inputs identify the parser and builder releases, build configuration and intended input-shape profiles. The offer must explain how any target-specific dependency will be available for the proposed destination.

B's stipulated quotation adds an explicit responsibility: "For each EP-202 target we confirm as supported, our named software team will supply the required replacement engine and the agreed numerical, shape-coverage and workload validation report. The buyer's application owner will decide acceptance against the agreed criteria."

That quoted responsibility is part of the example, not a real supplier commitment. Its value is that it connects retained inputs to a named party's proposed output. A folder containing a graph and plugins would leave that responsibility unresolved. B also needs to identify which requested changes are included and how it will return a finding that a requested target is unsupported or needs a separately assessed model change.

Reproducible build inputs mean the starting material and configuration can be identified and repeated. They do not promise a byte-identical engine or numerical equivalence after a different build. B supports a future-change discussion while supplying no actual application validation and no universal ability to regenerate an engine.

For a buyer planning only a fixed deployment, the extra deliverables may have limited value. For one planning a GPU, runtime or platform refresh, their value depends on the stated regeneration coverage and responsible software team.

References: [N1]

Separate implementation coverage from acceptance of the result

Four questions remain distinct. Can the selected parser and dependencies implement the graph's operators and attributes? Does the resulting artifact preserve the required numerical behavior? Does it cover the intended input shapes and batches? Does the complete application meet the buyer's workload requirements on the proposed target?

NVIDIA explains that build-time kernel selection can differ and that changes in floating-point operation order can produce different numerical outputs. A retained graph or successful rebuild therefore cannot substitute for the agreed numerical and task-quality evaluation. Likewise, evidence for one input shape cannot silently establish coverage for a different requested shape.

Set the change decision around the required result. For a move from T1 to T7, the software owner first establishes whether the existing engine has documented coverage. If a replacement is needed, the agreed provider supplies it with its actual input/dependency identity and the promised evaluation evidence. The buyer's application owner then assesses that evidence. Neither the old target's acceptance nor the new engine's existence settles the new application decision.

The related CUDA compatibility guide explains the driver, Toolkit and container relationship beneath this artifact question. The quantized-memory guide explains why model representation alone does not establish inference-memory fit. Those mechanisms matter to the selected deployment, but neither answers who will supply a newly supported engine after the target changes.

References: [N1][N2]

Carry the selected system into the physical deployment scope

When the platform choice also requires new equipment or a physical refresh, Leviathan's complete physical deployment service is the relevant place to discuss receiving, rack integration, agreed hardware QA, onsite installation, cabling and handoff records. Use the service and project-inquiry links below with a nonconfidential equipment summary, destination and target window, plus the physical handoff required by the appointed software team.

Model conversion, engine rebuilding, software maintenance, licensing and application validation remain with separately appointed providers. The physical deployment inquiry connects the selected equipment to its installation package; it does not create an offer to supply those software deliverables.

References: [L1]