When it comes to zkML, the framing people usually reach for is "which proof system is better" That is not really the question. For inference, the decision is almost entirely about the verifier path, and specifically what constraints live at the end of it.
A proof of inference has to bind a model spec, an input path, a numeric regime and an output claim into a single verifiable artifact. Where that artifact needs to land and what it costs to verify once it gets there, determines the system choice more than any abstract comparison of proof systems.
Where SNARKs fit
When the proof has to cross a tight boundary, SNARKs are usually the right call. A smart contract, a settlement layer, any policy gate where onchain verification cost determines whether the system is even viable. In that environment, a compact proof artifact is not cosmetic.* It is literally what makes the mechanism work.*
The verifier checks the claim cheaply and moves on. That is the entire value proposition at the settlement edge and SNARKs deliver it consistently.
Where STARKs fit
When the proving side has to carry real complexity, the picture changes. No trusted setup ceremony, better compatibility with trace-heavy execution, AND a proving stack that does not collapse under large or irregular arithmetic circuits.
That matters for inference because inference is structurally ugly; lookups, quantization artifacts, nonlinear activations, memory movement, model-specific data layout.
A transparent proving stack handles this more cleanly, especially when the full proving job stays offchain and only the result needs to cross the onchain boundary.
Why the splits exist
SNARKs produce tighter proof artifacts and cheaper verification, but they carry setup ceremony costs and circuit complexity constraints.
STARKs give you cleaner trust assumptions and a proving environment that scales with execution depth, but the proof objects are larger. One side fits through a settlement boundary easily. The other carries proving complexity without dragging a ceremony behind it.
The deployment target determines which property actually matters.
What actually ships
Practical production architecture is usually hybrid, and that is NOT a compromise. It is just respecting where each system is strongest.
A STARK-shaped backend handles the heavy proving work: model execution trace, quantized arithmetic, lookup tables. A SNARK-shaped wrapper then compresses that result into something small enough for onchain verification.
RISC Zero is the clearest live example of this pattern, STARKs internally for execution proving and Groth16 as the final settlement wrapper. The proving core and the settlement edge do not share the same job, so there is no real reason they should share the same proof system.
Trust boundary
There is a trust mistake that keeps appearing in zkML framing, and I want to be direct about it.
Setup trust is only one layer of the trust boundary. Even with a fully transparent proving system, the verifier may still be trusting the committed model weights, the preprocessing pipeline, the quantization scheme applied before inference, the model hash used to anchor the circuit, and the service that generated the proof.
A proof system proves the claim it was designed to prove. Nothing outside that envelope. For inference, the proof object is standing in for provider trust. If the weight commitment or the quantization spec is opaque, the proof still carries gaps the system is not accounting for. "Transparent" at the proof layer does not mean "trustless" at the system layer.
That distinction becomes critical when the output is gating capital or triggering onchain execution.
When to use which
If the output is only being read, a larger proof may be acceptable and prover throughput becomes the dominant constraint. If the output is triggering execution, updating an oracle, or gating an agent action, verification cost becomes part of the mechanism itself and proof size starts mattering at the protocol level.
SNARKs usually win at the settlement edge where size and verification cost govern feasibility.
STARKs usually win in the proving core where execution complexity and setup trust dominate.
For inference specifically, that split is more operationally significant than most headline comparisons suggest, because inference sits directly at the boundary between both concerns.
Pick the system that fits the constraint, not the one with better marketing.