One verified package, every target: TensorRT at 1.8× PyTorch speed, a 1.7 MB edge model, and an FMI co-simulation unit

The question

A surrogate that only runs inside a Python notebook is not a product. Engineering teams need the same model on a GPU server, inside a system-simulation tool, and sometimes on a small CPU next to a machine. Each conversion is a chance to quietly change the answer. This study asked whether Frontier can take a trained model to every one of those targets and prove, for each, that it still computes the same physics.

The models

Seven packages were built from checkpoints trained in Frontier:

• the reference Transolver-lite surface-pressure model for the Ahmed body (1.6 M parameters), plus a smaller variant, a point-MLP and a three-member ensemble;
• transient models for The Well (a U-Net) and cylinder flow. A small synthetic FNO was packaged as well.

Accuracy was always measured on the same six AhmedML test designs, which form a deliberately hard slant-angle hold-out outside the training envelope. Absolute errors are therefore high (about 0.33 relative L2). What matters here is how much each runtime changes them.

What Frontier did

One package format. python -m frontier_deploy package writes a frontier-model v1 package. It holds the network in up to seven formats (twelve variants for the reference model), the constants that map physical inputs to physical outputs, provenance down to the dataset manifest hash, the evaluation verdict, and an operating envelope: the training ranges plus a Mahalanobis model of the training geometries. A deployed model reports in_envelope and its distance with every answer, and can refuse out-of-envelope inputs. Every file is SHA-256 hashed and can be HMAC-signed.

Exports with a parity gate. ONNX (opset 18), TorchScript, ExportedProgram, Core ML, ExecuTorch and TensorRT plans are each checked against the PyTorch checkpoint on real samples before they are stored. FP32 parity ranged from 3e-8 to 2e-5 relative L2. Two models needed rewrites. The FNO's FFT does not export, so it became an exact truncated DFT of matrix products. The Transolver attention overflowed half precision at 10⁵ points, so it was rewritten to be FP16-safe, which also fixed NaN outputs on GPU.

An accuracy gate on top of parity. A variant "keeps accuracy" only if it changes test relative L2 and Cd error by at most 0.005, and stays within 2% of the FP32 fields on every sample. Variants that fail are recorded with the reason and are not shipped.

Results

GPU serving

Measured on a RunPod RTX 4080 SUPER (TensorRT 11.4), one forward pass, batch 1, with host copies included:

TensorRT FP32 is 1.8× faster than PyTorch with the same answer to 3e-7. TensorRT FP16 is 4.1× faster, but it moves field error by 1.2 points, which is outside tolerance, so the gate flags it. A second FP32 engine build with identical settings came out at parity 2.7e-4, which is the size of TF32 rounding. It was rejected automatically. This is why the gate exists: TensorRT picks kernels per build.

Edge CPU

The robot/edge target was emulated as a Linux ARM64 container limited to one CPU core and 1 GiB of memory. On it, the reference model with dynamic INT8 is 1.72 MB, 4.1× smaller than FP32, and runs 4.3× faster: 134 ms per 2,048-point chunk, about 7 s for a whole 100,000-point surface, in a 525 MB process. It keeps benchmark accuracy (Δ relative L2 +0.0004, Δ Cd error +0.0001). Static INT8 and magnitude pruning changed the field by 12–22% and are not recommended.

INT8 edge model

1.72 MB

change in test rel-L2 after INT8

+0.0004

torch-free serving container

294 MB

FMU vs ONNX system model

2.7e-9

Service, Triton and FMI

• HTTP service. /v1/infer uses the NVIDIA DoMINO NIM's wire format (multipart STL in, .npz out), plus JSON and Arrow. It returns uncertainty and envelope flags, exposes Prometheus metrics and keeps payload-free request logs. A torch-free container of 294 MB was built and answered requests.
• Triton. A model repository is generated: a Python-backend pre/post-processing model that calls an ONNX Runtime or TensorRT network.
• FMI 2.0. For a fixed geometry, the surface model is folded into one ONNX graph from conditions to cd, cd_std, ood_score and in_envelope, then wrapped as a native co-simulation FMU (22.9 MB, no Python needed by the importer). FMPy validated it. With the slant angle swept from 10° to 80°, the FMU matched the ONNX system model to 2.7e-9, and its ensemble spread grew from 0.0004 to 0.020 outside the training range.

Limits and caveats

• The accuracy figures come from six out-of-distribution designs. They are suited to comparing runtimes, not to judging the model.
• The edge figures come from an Apple M1 performance core under a one-CPU quota. Typical robot CPUs are slower, so read them as a lower bound.
• The FP16 accuracy loss on GPU is still open. The next experiment, keeping residual additions in FP32, has not been run.
• The FMU was built and validated on macOS (arm64) only. Linux and Windows builds were not run.

Dataset credit: AhmedML, Neil Ashton and collaborators, CC BY-SA 4.0.

Try it on your data

Do you need a surrogate inside a GPU service, a system-simulation tool or an embedded controller? Join the waitlist or talk to us.