Nobody wants an ONNX engineer for its own sake. The need appears when a model has to run somewhere it was not trained — on a CPU, on a device, inside a C++ application, on a customer’s hardware, or on whatever accelerator you end up buying next year. The format exists so the model can leave the framework it was born in.

That makes this an integration role rather than a modelling one, and the best candidates usually come from software engineering rather than from data science.

Establish which of three problems you have

The word covers three quite different briefs, and they need different people.

  • Portability. The model was trained in one framework and must run in an environment that does not have it — typically a compiled application, or a deployment target where installing a full training stack is unreasonable.
  • Edge and CPU deployment. The model must run without a GPU, or on a device, where the runtime and the operator set are the constraint and every megabyte counts.
  • Hardware independence as a strategy. You want the option of changing accelerator vendors, and the interchange format is the hedge.

The first two are concrete engineering briefs. The third is an architectural position, and it is worth being clear-eyed that it trades some peak performance for optionality — the vendor-specific route will usually be faster on that vendor’s hardware, as the TensorRT engineer guide sets out.

The unsupported-operator problem, which is the actual job

Here is what these engagements consist of in practice. A model exports cleanly, or it does not. When it does not, it is because it uses an operation the target runtime does not implement, or uses control flow that does not survive tracing, or depends on a custom layer somebody wrote.

The question to ask is exactly that: tell me about a model that would not export, and what you did. The good answers are a spectrum and all of them are legitimate — rewriting the offending module in supported operations, implementing a custom operator for the runtime, splitting the graph so the awkward part stays in Python, or going back to the modelling team and asking whether that layer earns its place. A candidate with several of those in their repertoire has done this repeatedly.

The answer that should worry you is one that has only ever met models that exported first time. That is a candidate who has used the format, not somebody who can be relied on when it resists.

Numerical equivalence is not automatic, and must be tested

A converted model is a different implementation of the same mathematics, and different implementations disagree slightly. Usually that is irrelevant. Occasionally it is not — a classifier near a decision boundary, a detection threshold, a sequence where small differences compound.

Ask how they verify a conversion. You want to hear about running both versions on the same real inputs and comparing outputs within a tolerance the use case justifies, not just checking that the file loads and produces plausible numbers. Ask what tolerance they used and why; somebody who has thought about it will relate it to what the model is for.

The related question, worth asking of anyone doing deployment work, is what they do about preprocessing. A remarkable share of conversion bugs are not in the model at all — they are a resize, a normalisation or a channel order that differs between the training pipeline and the application that now hosts the model.

What the runtime side demands

Once the model is converted, somebody has to run it somewhere, and that is ordinary systems work: threading, memory, batching, and the hardware-specific execution providers that decide whether you get the acceleration you expected.

Two practical screens. Ask how they would speed up inference on a CPU, where the answers involve thread configuration, operator fusion, quantisation and batching rather than a bigger machine. And ask what they check when the same model is slower in production than on the bench — usually a different execution provider is being selected than they assumed, which is the classic silent failure in this area.

Where these people come from, and what to pay

Indicatively £75,000 to £115,000 permanent, day rates from about £550. Roughly 90 UK employers name the format in the pages we index, which makes this a thin advertised market that nonetheless comes up constantly inside teams building products rather than models.

Look outside the obvious pool. Embedded and desktop engineers who have shipped software onto hardware they do not control are often better at this than machine learning specialists, because the discipline is fundamentally about making something work in an environment with constraints you cannot change. Candidates with C++ and a history of deploying into other people’s applications convert quickly. If the work is principally about getting models onto devices, the computer vision engineer guide covers the same deployment problem from the other end, since vision is where edge deployment is most common.

A caution about the strategic version of this hire

If you are hiring because you want vendor independence, be honest about whether you will exercise it. Maintaining a genuinely portable deployment costs continuous effort: every model change must be re-verified on each target, and the tooling is less mature than the vendor-specific alternative.

Teams that actually ship to several targets get their money back comfortably. Teams that adopt the format as insurance and then run everything on one vendor anyway have paid for an option they never used, and would have been better served by the faster path plus a written note of what switching would cost.