A proof of inference certifies an output came from a committed model. It says nothing about how the weights came to be. Proving the training run is a separate, far heavier object — and it is the one compliance actually asks for.
A compliance team reads that a vendor’s model is “verifiable.” A zero-knowledge proof, they’re told, attests that the model is what it claims to be — cryptographic, sound, no need to trust the vendor’s word. So they ask the question their auditors will ask: does the proof show the model was trained on the licensed dataset, without the copyrighted corpus the vendor swore it excluded? Once you read the actual scheme, the answer is no. The proof attests that a committed set of weights, run on a given input, produced a given output. It says nothing about where those weights came from. The vendor could have trained on anything — or stolen the model outright — and the proof would still verify.
This is not a flaw in the proof. It is a category confusion in the word “verifiable.” Two genuinely different cryptographic objects get filed under “zkML.” One proves an inference — a single forward pass, milliseconds-to-seconds of computation wrapped in a proof. The other proves a training run — thousands of gradient-descent steps over a committed dataset, a recursive statement about an entire optimization trajectory that costs minutes per step and needs machinery the inference case never touches. A team that conflates them will buy a proof of the wrong thing.
This post is about that seam: why a proof of inference (ZKPoI) and a proof of training (ZKPoT) are distinct primitives, why training is the structurally harder object, what the per-iteration cost looks like in the papers, and why the thing regulators are reaching for is the proof almost nobody is selling.
Start with how the field organizes the problem, because the taxonomy is not ambiguous. A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning (arXiv 2502.18535) reviews the ZKML literature and organizes “existing studies into three core tasks: verifiable training, verifiable testing, and verifiable inference.” Training and inference are not two flavors of one capability. They are separate categories in the survey that maps the whole area.
What each certifies is the crux. The survey’s definition of verifiable inference is narrow and exact: it “certifies that the returned prediction y-hat is exactly the output produced by the specified model on the declared input x.” That is the entire guarantee — this model, this input, this output. Nothing about provenance.
Verifiable training is a claim about provenance and nothing else. The same survey: it “certifies that the updated model parameters theta-prime are obtained by running the declared training procedure on the committed training data under the agreed hyperparameters and architecture,” delivering “evidence that the delivered model is the genuine result of the specified optimization process rather than a fabricated or improperly trained artifact.” Read the two definitions side by side and the compliance team’s problem is obvious. An inference proof binds an output to a model. A training proof binds a model to a process and a dataset. The first cannot stand in for the second, because it never makes a statement about the dataset at all.
The 2025 framework paper that looks at the whole pipeline names the two as distinct primitives in so many words. A Framework for Cryptographic Verifiability of End-to-End AI Pipelines (arXiv 2503.22573) draws the line explicitly: “Zero-Knowledge Proofs of Training (ZKPoTs) enable stakeholders to verify that training was conducted correctly using a specific dataset and algorithm,” while “Zero-Knowledge Proofs of Inference (ZKPoIs) enable a party to prove that an AI model has made a correct inference using a specific, previously committed to model, without disclosing the model weights.” Two acronyms, two lifecycle stages, two cryptographic objects. The conflation lives in the marketing, not the research.
Why is training the harder object? Not because the model is bigger — both proofs can target the same network. It is because a training step contains a forward pass and then some, and the “some” is the expensive part.
An inference proof encodes the forward pass: the matrix multiplications, the activations, the normalization. A training step encodes all of that and then the backward pass — backpropagation, the gradients, the parameter update — none of which the inference proof ever sees. zkDL: Efficient Zero-Knowledge Proofs of Deep Learning Training (arXiv 2307.16273) is built around exactly this gap: “beyond the innate layered structure, the training process encompasses both forward and backward propagations,” and its central contribution, zkReLU, is “a specialized proof for the ReLU activation and its backpropagation.” The backward pass through a nonlinearity is its own proof problem, separate from proving the nonlinearity forward.
The fine-tuning case makes the arithmetic concrete: proving one step is proving three sub-computations, not one. VeriLoRA: Fine-Tuning Large Language Models with Verifiable Security via Zero-Knowledge Proofs (arXiv 2508.21393) spells out what a single proved step covers — “all computational steps in LoRA fine-tuning, including forward propagation, backward propagation, and parameter updates, are provably correct.” Forward, backward, update. The inference proof does the first and stops; a training proof that stopped there would prove nothing about training.
This is why the field arrived at training-time verification late, and the papers say so without hedging. zkDL is blunt that prior cryptographic work skipped it: “cryptography-based approaches have mainly focused on inference-time verification …, leaving training-time verification largely unexplored because of the significant computational demands and complex operations involved.” VeriLoRA says the same about the LLM era — “frameworks like zkML and zkLLM have demonstrated the feasibility of applying ZKPs to machine learning, but these works primarily focus on inference or small-scale models,” and proving fine-tuning for large models “remains unexplored and presents significant technical challenges.” When the people who build these systems tell you inference and training are different difficulty classes, that is not a hedge. That is the finding.
There is a second structural difference, and it pushes training from “harder forward pass” into a genuinely different machine. An inference is one computation. A training run is a sequence — thousands of mini-batch steps, each consuming the previous step’s weights and emitting the next. You cannot prove that with one circuit; you need a proof that composes across steps.
Zero-Knowledge Proofs of Training for Deep Neural Networks — the Kaizen system — defines the object precisely: a zkPoT “enables a party to prove that they have correctly trained a committed model based on a committed dataset without revealing any additional information about the model or the dataset.” And it proves the trajectory incrementally. The prover accumulates a proof as it goes: it iteratively trains the model “via (mini-batch) gradient descent, where the number of iterations need not be fixed in advance; at the end of each iteration, the prover generates a commitment to the trained model parameters attached with a succinct zkPoT, attesting to the correctness of the executed iterations.” That is incrementally-verifiable computation — fold each step’s proof into a running accumulator — exactly the shape an inference proof lacks, because an inference does not iterate over a committed sequence of states.
The survey describes the same two-part construction as the thing that distinguishes the deep-net training case: a design centered on “an optimized GKR-style proof system for verifying each gradient-descent iteration, and a recursive composition framework for aggregating proofs across many iterations into a single concise proof.” Per-step proof, plus recursion to glue the steps. zkDL builds the same aggregation, “consolidating the proofs for different layers and training steps … without being constrained by their sequential order in the training process.” The recursion is not an optimization bolted on. It is what makes a training proof possible at all — without it, a thousand-step run is a thousand disconnected proofs that say nothing about the trajectory.
The payoff of the recursion, and the reason this is tractable at all, is that the final proof stays small no matter how long the run was. Kaizen reports a proof size of “1.63 megabytes, and the verifier runtime is only 130 milliseconds, where both are independent of the number of iterations and the size of the dataset.” Verification is cheap and constant; the cost all lives on the prover, per step.
Here the cost gap stops being abstract. An inference proof is priced per forward pass. A training proof is priced per iteration — and there are thousands of iterations in a real run.
Kaizen, with a purpose-built recursive system, reports a prover runtime of “15 minutes per iteration, which is 24x faster than generic recursive proofs, with prover memory overhead 27x lower,” on a model modest by current standards — it “can handle the training of complex models such as VGG-11 with 10 million parameters and batch size 16.” Fifteen minutes for one mini-batch step on a 10M-parameter vision model, and that is the fast system, 24× ahead of generic recursion. zkDL, optimized differently, gets the per-step number down dramatically: “complete and sound proofs in less than a second per batch update for an 8-layer neural network with 10 million parameters and a batch size of 64.” Sub-second per step is a real result — but still a cost paid on every one of the run’s many steps.
The LLM fine-tuning numbers are the ones to sit with, because they put both objects on the same page. VeriLoRA reports that proving one single-sample fine-tuning step takes minutes: “the total proving time ranges from 121.93 seconds (LLaMA-3.2-3B) to 249.38 seconds (OPT-13B),” against an un-proved step that “executes in 0.47 seconds (LLaMA-3.2-1B).” The slowdown, stated plainly: “relative to these no-zk baselines, our VeriLoRA are approximately three orders of magnitude slower.” Two to four minutes to prove a single step that natively runs in under a second.
And the same paper benchmarks an inference proof beside it, which makes the comparison honest rather than rhetorical. It “benchmarked a public zkML inference prover: the distilled GPT-2 inference proof generation takes 7,370.6 seconds.” That is the punchline in one data point. Both objects are expensive — over two hours to prove one GPT-2 forward pass is nobody’s idea of cheap. But they are expensive on different workloads, measured as different things: one number prices a single forward pass, the other a single training step you then multiply by the length of the run. You do not get to quote one and imply the other.
A few qualifications, because the version of this argument that overstates loses the reader who works in the field.
First, “different object” is a claim about the cryptographic guarantee, not about whether one lab can build both. Several of these papers — zkDL, VeriLoRA — come from groups also working on inference. The skills transfer; the guarantees don’t. A ZKPoI and a ZKPoT certify different statements, so a vendor with a great inference prover has proved nothing about its training.
Second, the per-step cost is not a fixed verdict forever. The spread above — 15 minutes per step in one system, sub-second in another on a similar-size model — is the field optimizing hard, and it is moving. The structural claim survives it: a training proof is forward-plus-backward-plus-update composed recursively across a sequence, and that is more than a forward pass however fast a step gets. “Cheaper than it was” and “the same object as inference” are different statements; only the first is true.
Third, every number here is on a small model — VGG-11 at 10M parameters, an 8-layer net at 10M, LoRA fine-tuning of 1B-to-13B models. These are demonstrations, not frontier pretraining. The framing matches inference proofs of large transformers: the existence proofs are real, routine production capability is years out, and the gap is not closed by renting a bigger machine.
Fourth, and against this post’s own emphasis: there is no shipping end-to-end pipeline linking the two proofs today, so a buyer cannot currently get “trained honestly and inferred honestly” as one artifact even if they wanted to. The framework paper is explicit: ZKPoTs “focus solely on proving that the training process was executed honestly given a set of inputs,” and “to the authors’ knowledge no work has yet achieved a full end-to-end verifiable pipeline.” The seam is also an open research boundary — a reason to be precise about which proof you have, not to expect both soon.
Now the part that makes the distinction matter beyond pedantry. When a regulator or auditor asks for “verifiable AI,” the thing they describe is almost always the training proof — and the thing the market mostly sells is the inference proof.
The framework paper states the full-assurance requirement, and inference is only half of it. A complete pipeline “would enable an end user who obtains some model inference to verify cryptographically that the output they received was honestly computed using a specific model, and that this model was trained according to a specific algorithm on a specific dataset.” The first clause is a ZKPoI. The second — trained according to a specific algorithm on a specific dataset — is a ZKPoT, and it is what a copyright dispute, a data-provenance audit, or a “was this trained on PII you should have deleted” inquiry turns on. An inference proof answers none of those; it never makes a statement about the training set.
This is why the paper’s motivating use cases are regulatory, and why they point at training. It sees “significant potential for regulatory oversight and compliance frameworks to leverage verifiable AI pipelines,” with authorities “such as those under the AI Act” verifying “cryptographic proofs across the pipeline to ensure compliance with legal and ethical standards.” The EU AI Act asks how a model was developed. GDPR’s right-to-erasure asks what it was, and was not, trained on, and whether deleted data was truly unlearned. Those are questions about the optimization process and the dataset — ZKPoT questions. A team that procures an inference proof to satisfy a training-provenance obligation has bought a cryptographically sound answer to a question nobody asked.
The practical move is to name which object you need before evaluating any “verifiable” claim. If the requirement is “the served output came from the committed model” — an agent’s reasoning step a contract acts on, a scoring model governance audits — that is verifiable inference, the shippable side today; the opML-or-zkML decision is the one to run, and DeepProve’s first proven LLM is the frontier of what’s provable. If the requirement is “this model was trained on this data by this procedure” — provenance, licensing, regulatory conformance — that is verifiable training, a heavier object, and you should expect per-iteration proving costs and, for now, no pipeline that hands it to you alongside an inference proof. The two map to genuinely different guarantees across the zkML landscape, and the most expensive mistake is treating a proof of one as a proof of the other.
A proof that a model ran is not a proof that you trained it. The inference proof binds an output to a committed model; the training proof binds that model to a committed dataset and a declared procedure — a recursive statement over an entire optimization trajectory that costs minutes per step, not milliseconds per query. They share one three-letter label and answer entirely different questions, and the question compliance keeps asking is the one the cheaper proof was never built to answer. Before you trust the word “verifiable,” ask which object it names.
A membership-inference attack that separates your book from a held-out one is usually reading the calendar, not the weights. A successful attack is not a sound proof — and the null it would need to test against cannot be sampled.
17 min →
Unlearning promises a model can forget specific data without a full retrain. What it delivers is output suppression: a small benign relearning set — or simply quantizing the model — brings the 'forgotten' knowledge back.
14 min →
The EU AI Act requires AI output to be marked in a robust, reliable way. A formal impossibility theorem says strong watermarking cannot exist. Five words in the statute carry the collision.
13 min →