Zero-Knowledge Proofs for Verifiable LLM Inference: Detecting Model Substitution and Silent Downgrading

1. The Long-Standing Problem: Model Provenance Cannot Self-Certify

As API calls to large models become the dominant integration method, callers often struggle to answer a simple question: Was this answer really generated by the model we paid for, under the configuration we paid for?

This becomes a practical dispute for two parties.

• API callers: There are many API proxies, aggregation gateways, and resale services. A caller may be billed for a high-spec model, but the proxy could route the request to a cheaper model and return the response as-is. The user sees well-formed text, but has no way to verify the compute cost behind it.
• Model providers: When users complain that “the model has become dumber,” it is hard to prove innocence even if the model has not been replaced. Without cryptographic evidence, explanation is costly and brand trust is continuously eroded.

The key point is: the answer currently depends on trust, not evidence. Trust is also the most fragile component in distributed systems.

2. Where Existing Detection Methods Stop

Common community practices for “identification” fall into four categories. They all share the same problem: they can only provide circumstantial evidence, not a definitive conclusion.

1. Answer-style comparison: Use fixed prompts to probe wording habits, formatting preferences, and refusal tendencies. The problem is that model style is highly dependent on system prompts and decoding parameters. The same model can show a completely different “personality” after a prompt change.
2. Response fields and protocol-feature checks: Check whether response structures, error codes, and metadata fields match expectations. This information can be forged or flattened at the gateway layer.
3. Integrity checks such as chain-of-thought signatures: These can prove that a response came from some upstream service, but cannot identify which tier of model that upstream actually scheduled.
4. Asking “who are you?”: This is the least effective approach. The proxy only needs to add an identity statement in the system prompt, and any model will answer accordingly.

Even statistical fingerprints, tokenization behavior, and first-token latency distributions are still probabilistic inference: they say “more like” or “less like,” not “yes” or “no.” When the adversary is a commercial service controlling routing and gateways, the cost of these indirect signals failing is low.

3. Threat Model: Three Types of Impersonation

Only after formalizing the problem can we discuss technical solutions. There are three behaviors to prevent:

• Spec substitution: Billing under the name of a high-spec model while forwarding to a low-cost model.
• Silent downgrading: Applying more aggressive quantization, pruning, context compression, or worse inference parameters to the same model while still claiming the original specification.
• Impersonation: Using a distilled or similar substitute model while claiming it is the original model.

They share one characteristic: there is an information gap between claims and reality, and the caller has no verification method. Cryptography solves exactly this: turning a claim into a verifiable proposition.

4. Shifting Approach: From “Trust the Service” to “Verify the Computation”

The core idea of verifiable inference is to express “this forward pass of the model” as a proposition that a third party can verify. It is based on the three-stage commit–prove–verify pattern used by zero-knowledge proof systems such as zkSNARK and zkSTARK.

Step 1: Commitment
The model provider publishes a cryptographic commitment to the weight tensors, for example by building a Merkle tree and publishing the root hash. It also publishes the circuit/program verification key and model version identifier. Commitments are binding: once published, the provider cannot later substitute another set of weights that still matches the same digest.

Step 2: Proving
During inference, the forward pass is expanded into a set of arithmetic constraints over a finite field: matrix multiplication, accumulation, and circuitized expressions of activation functions. The prover generates a proof that “output = f(committed weights, committed input)” without revealing the plaintext weights and without revealing the plaintext user prompt.

Step 3: Verification
Any third party can independently verify the proof using the public verification key, input commitment, output hash, and proof. Verification cost is largely decoupled from model size and is usually much smaller than proving cost.

Illustrative protocol flow (pseudocode, structural only):

# --- Phase 1: One-time publication, can be done offline ---
W        = dequantize(weights)          # Weight tensors
root_W   = merkle_root(W)               # Public: weight commitment
vk, pk   = setup(circuit_for(W.shape))  # Publish vk, keep pk privately
publish(model_version, root_W, vk)      # Bind commitment to circuit version
# --- Phase 2: Per request, completed during inference ---
commit_prompt = hash(canonical_encode(prompt))   # Commit first to prevent mid-flight rerouting
output = forward(W, prompt)
proof  = prove(pk, witness=(W, prompt), public=(commit_prompt, hash(output)))
# --- Phase 3: Any third party can independently verify ---
assert verify(vk, commit_prompt, hash(output), proof)
assert hash(output_received) == hash(output)

There are two easily overlooked design points.

First, “commit before reveal” can block the path of “inspecting the request and dynamically downgrading the configuration.” The caller submits a prompt commitment first, the provider must perform routing under the constraint that it cannot know the content in advance, and the delivered proof must match that commitment.

Second, zero-knowledge is a requirement, not an option. If verification requires the provider to hand over weights or requires the caller to reveal prompts, the solution is commercially infeasible: the former is a core asset, and the latter may contain sensitive data. Zero knowledge ensures that the verifier learns nothing beyond the one bit that the proposition is true.

5. Engineering Costs: Why It Is Not Default Yet

Fitting large-model inference into cryptographic circuits has costs in three places.

• Arithmetic blow-up: The number of matrix multiplication constraints grows with the parameter count. Expressing floating-point arithmetic and nonlinear activation functions over a finite field is especially expensive, usually requiring fixed-point conversion, lookup tables, or piecewise polynomial approximation.
• Proving overhead: Constraint size directly determines proof time and memory peak. Compared with the model forward pass itself, proving has significant additional overhead. The exact multiplier depends on model size, quantization scheme, circuit design, and the selected proof system, and must be measured against the actual workload rather than assumed from general results.
• Version-management complexity: If the circuit, weights, quantization scheme, or inference parameters change, commitments and verification keys must be regenerated. Teams with high-frequency model iterations need a clear mapping and release process for “circuit version—weight version—verification key,” otherwise proofs lose reference meaning.

There are also engineering support issues: proof storage and retrieval, public verification service interfaces, and appeals or arbitration processes for verification failures.

6. Capability Boundaries: What It Can and Cannot Prove

This part is more important than the theory, otherwise expectations can become unrealistic.

What it can prove: Under a given public commitment, the output was indeed produced by executing the committed forward computation on the committed input. It excludes cases such as “output is unrelated to weights,” “output was replaced mid-way,” or “computation was skipped.”

What it cannot directly prove:

• Whether the weights equal the version claimed by the vendor. A commitment only guarantees consistency with a digest; it does not guarantee that the digest corresponds to the advertised model. Closing this gap requires a trustworthy release chain: reproducible builds, public build-artifact digests, and independent third-party review.
• Identity-claim impersonation. Declaring identity only through a system prompt is a prompt-layer problem and is orthogonal to computation integrity. It must be handled with prompt-layer injection defenses and output-side checks.
• Distillation and approximate substitutes. A distilled model is a set of independent weights with its own valid commitment. If the provider honestly declares, “I provide a distilled model,” the proof system will prove exactly that. It prevents false claims, not insufficient capability.
• Implementation defects. Side channels, randomness quality, and interface vulnerabilities in the verification service are outside the cryptographic model and still require ordinary security engineering.

7. A Layered Enterprise Adoption Path

For most teams, the reasonable path is not to jump straight to full cryptographic verification, but to progress layer by layer.

L1 Observability baseline (lowest cost, do first)
Build your own baseline: accuracy on a fixed question set, first-token latency and total latency distributions, token consumption per request, consistency of structured fields and error codes, and stability of tokenization behavior. Connect these metrics to logging and monitoring/alerting services, and set drift thresholds. Many downgrades and substitutions reveal themselves immediately in latency distributions and token consumption.

L2 Active probes and statistical sampling
Maintain a set of non-public “canary” questions covering multiple difficulty levels, insert them into real traffic at fixed intervals, and use statistical methods to determine whether service behavior has changed significantly. Pay attention to sample size and confidence intervals to avoid mistaking normal fluctuations for degradation.

L3 Cryptographic verification for high-risk requests
For high-value, high-compliance, or billing-sensitive scenarios—for example, large pay-as-you-go amounts or outputs that carry external responsibility—require the provider to offer verifiable inference in contracts and technical plans: publish weight commitments and circuit versions, deliver proofs, and allow callers or third parties to independently verify.

Evidence retention and audit loop
Write request commitments, output hashes, model version identifiers, proofs, and verification results into object storage to form an immutable ledger, with access controls and lifecycle policies; monitoring alerts trigger manual review for anomalies. In such scenarios, a cloud provider’s general-purpose capabilities—object storage for long-term evidence retention, log services for retrieval, and monitoring/alerting for drift detection—can typically be used, with specific choices evaluated based on compliance and budget requirements.

Commercial and contract layer
Write “no silent downgrading, prior notice for model version changes, and support for third-party recomputation” into service terms, and agree on how breaches are determined. Technical proofs and contractual constraints are complementary: proofs provide facts, contracts provide remedies.

8. Conclusion

The value of verifiable inference is not that every call runs expensive proof generation. Its significance is that it changes the nature of the debate: when “did you switch models?” moves from a trust game where each side tells its own story to a mathematical proposition that a third party can independently verify, the space for provider misconduct is compressed, the caller’s cost of asserting rights is greatly reduced, and model providers gain a tool to prove their innocence.

A pragmatic order is: first make observability and sampling solid, obtain your own data baseline; then introduce commitment and proof mechanisms on critical paths; finally use evidence retention and contracts to solidify conclusions. Technical capability answers “can it be proven”; engineering and governance determine whether the proof is actually used.