Verifying LLM Inference with Zero-Knowledge Proofs: Principles, Workflow, and Deployment Challenges

Why Verify Model Authenticity?

As large language models are widely served through APIs, a long-standing but rarely addressed question is coming to the surface: is the response the caller receives really from the model that was claimed?

A common situation in the industry is that some relay services or secondary wrapper platforms advertise a flagship model while possibly substituting a cheaper model or mixing outputs from multiple sources. Callers usually rely on ad hoc methods to check:

• Probe question sets: maintain a set of tricky questions and periodically test whether answer style, refusal behavior, or knowledge cutoff has changed;
• Statistical fingerprints: compare statistical features such as token distributions and punctuation habits;
• Manual comparison: rely on experienced engineers to judge intuitively that something “feels off.”

The common weakness of these methods is that they can produce suspicion but not evidence. Taking statistical differences to a provider can easily be dismissed with a single statement: “We updated the model version.” The root cause is that the two sides lack a cryptographically verifiable commitment.

Zero-knowledge proofs offer a new approach to this problem: a model provider can generate a concise proof of the computational fact that “a certain model on a certain input did produce these outputs” without revealing the weights, and anyone can independently verify it at low cost.

Two-Stage Architecture: Commitment and Proof

This type of zkSNARK-based inference verification scheme typically uses a clear two-stage design.

Offline Stage: Weight Commitment

The model provider makes a cryptographic commitment to the model weights once and publishes a fixed-length commitment ID, such as a hexadecimal hash string. The key properties are:

1. Weights remain private: the commitment is one-way, so third parties cannot infer the weight contents from the commitment ID, preserving commercial secrets;
2. Binding: once published, the commitment cannot be altered, and all subsequent proofs are anchored to this ID, making a midstream model switch cryptographically infeasible;
3. One-time cost: the commitment only needs to be made once. When the model version changes, a new commitment can be generated, naturally forming a “model version fingerprint.”

Online Stage: Per-Request Proof

After each inference request is completed, the service generates a proof file. A verifier only needs the commitment ID, the original prompt, and the response text to complete verification on an ordinary CPU in seconds, confirming that “the committed model did produce these tokens on this input in a deterministic way.”

This verification cost model is highly attractive: proving is expensive, while verification is cheap, and the verification process requires no GPU and no access to any model weights. This is consistent with the classic zkSNARK pattern in blockchain scenarios of “trading computation for trust.”

Current Performance: Usable but Costly

Based on publicly available test data, the engineering cost of this type of scheme is still significant. Take a MoE model with about 400 billion parameters and tens of billions of active parameters per token under 4-bit quantized weights as an example:

• Proof generation speed: about 110 tokens per second on a single high-end GPU;
• Proof size: a 1,024-token request produces a proof file of about 19 MB;
• Computational overhead: proof generation takes tens of times longer than direct inference, roughly 70–95x.

These numbers show two things. On one hand, compared with early open-source schemes that were orders of magnitude slower, optimizations such as MoE sparse activation and quantized arithmetic have brought a substantial breakthrough, moving the approach into a demonstrable range. On the other hand, tens of times the extra compute means that attaching a proof to every online request is still unrealistic in the short term. A more reasonable deployment path is sampling-based verification: the provider generates proofs for a small fraction of requests, or a third-party auditor requires recomputation for specific requests in dispute scenarios.

It is worth noting that the code, protocol documentation, and formal proofs—protocol correctness verification written in a proof assistant language—are released under a permissive open-source license. The introduction of formal verification is especially important for cryptographic protocols, where failure means a collapse of trust.

The Most Overlooked Gap: Integer Model vs. Online Model

This is the most critical technical divergence point when deploying the whole scheme, and it is also the question that must be asked when evaluating its credibility.

Zero-knowledge proofs require exact arithmetic operations, while floating-point operations are extremely difficult to express and verify in circuits. Therefore, the object being proven is an integerized model copy that uses greedy decoding, taking the highest-probability token at each step. The model actually served online usually runs on various inference engines, uses floating-point operations, and often enables sampling strategies such as temperature and top-p.

There are three deviations between the two:

1. Numerical deviation: the integer model is an approximation of the floating-point model, and public documentation explicitly acknowledges that there is no proof quantifying how large the gap is;
2. Decoding deviation: greedy decoding and sampled decoding have different output distributions, and the same prompt may inherently produce different responses under sampling mode;
3. Engineering deviation: inference engine kernel implementations, batching strategies, and similar factors all introduce small numerical differences.

To bridge this gap, the scheme provides two acceptance strategies:

• Exact match: every checked token must be the highest-probability choice of the integer model at that position, and all must match for verification to pass. It is strict but harsh—any divergence caused by numerical approximation will cause verification failure;
• Clipped gap: calculate a cost metric for each token and allow bounded deviation between the integer model and the online output, passing as long as the total cost does not exceed a threshold. This is the more practical direction, but “what threshold counts as honest” itself becomes a new problem requiring consensus.

A Rational View: Right Direction, Still Far from Practical

Overall, the route represented by this type of technology is worth affirming, but its boundaries need to be clearly understood:

• Architecture dependence: performance gains rely heavily on MoE sparse activation structures, while the internal architectures of mainstream closed-source models are not public, so whether their responses can be efficiently proven remains uncertain;
• Unquantified approximation: there is no strict bound on the deviation between the integer model and the floating-point model, and the strength of the verification conclusion is constrained by this;
• Cost threshold: tens of times the compute overhead means that in the short term it can only serve sampling and audit scenarios, not full real-time verification;
• Ecosystem threshold: the scheme assumes that the provider voluntarily adopts the commitment and proof process, which essentially still requires the provider to be willing to attest to itself; regulation and industry standards are the real levers for broader adoption.

For developers and enterprise users, a more practical approach at this stage is to retain multiple layers of verification in important scenarios—cryptographic proofs, once available, should complement statistical fingerprints and behavioral probes rather than replace them. When “verifying inference authenticity” gradually becomes industry infrastructure, the trust cost of large model services can truly decline.

(Note: The specific performance data in this article comes from relevant public technical documentation, and actual results are subject to the latest version.)