Verifiable LLM API Inference and Zero-Knowledge Proofs: A Practical Guide

1. Quick Decision: Determine Whether It Is Worth Implementing First

In LLM API calls, model substitution and unverifiable service claims commonly take the following forms: a proxy layer forwards high-specification model requests to a low-cost model, a distilled model impersonates an official model, or a service provider silently changes parameters, causing answer quality to decline without being able to prove it. A traditional API response is essentially a “service provider claim,” and callers can only trust it. Zero-knowledge-proof-driven verifiable inference changes the claim into a mathematically testable computational proof.

Scenario	Suitable for Zero-Knowledge Proofs?	Reason
Compliance audit, external reporting, and high-value reasoning such as finance and healthcare	More suitable	Requires auditable, reviewable, and traceable evidence
High-concurrency online inference	Not suitable for full proofs in the short term	Proof generation overhead is large; sampling or a trusted execution environment may be used as a transitional approach
Model evaluation and capability comparison	Suitable	Can verify model fingerprints and computation results for fixed inputs
Service provider self-proof that “the model was not switched”	Suitable, but boundaries must be defined	Can provide cryptographic evidence, but can only prove computations within the committed scope

It is not recommended to directly move to full zero-knowledge proofs under the following conditions:

• Low latency budget: If the business requires millisecond-level responses while proof generation takes seconds or more, full proofs should not be forcibly promoted.
• Insufficient cost budget: If the proof cost per request is significantly higher than the business benefit, or higher than the model invocation cost itself, reassessment is needed.
• Insufficient proof resources: Lack of circuit engineering, proof system operations, hardware acceleration, or trusted verification infrastructure.
• Mismatched compliance level: If used only for internal experience optimization, full cryptographic proof is unnecessary; if used for external audit, verifiable evidence chains should be prioritized.

2. The Core Problem: Inference Results Cannot Be Independently Verified

LLM APIs typically involve three parties: the caller, the service provider, and the model provider. The caller initiates a request and pays according to model specifications. The service provider assembles prompts and returns results. The model provider runs the weights to produce the answer. A traditional response only states that it comes from a certain model, version, and set of parameters, but provides no verifiable computational evidence.

Common risks include:

1. Intermediate proxy downgrade: The request is forwarded to a cheaper small model, but billing is still based on the high-specification model.
2. Identity impersonation: Through system prompts or templates, the model is made to claim a certain model type.
3. Distilled-model impersonation: Distilled models may have similar style but reduced capability.
4. Silent parameter changes: Lowering temperature, truncating the chain of thought, or limiting maximum output length can make responses shorter or worse.
5. Difficulty for the service provider to self-prove: When questioned about “degraded intelligence,” it is difficult to provide third-party verifiable evidence.

Existing detection methods mostly rely on surface evidence, such as comparing response style, checking interface fields, or inspecting signed reasoning traces. These methods can only prove that “the response comes from a certain service,” not that “a specific model performed the computation.” Verifiable inference changes the approach: instead of verifying the source of information, it verifies the computation itself.

3. Zero-Knowledge Proofs and Verifiable Inference

A zero-knowledge proof allows a prover to convince a verifier that a statement is true while satisfying three properties:

• Completeness: If the statement is true, an honest prover can make the verifier accept it.
• Soundness: If the statement is false, a cheating prover is extremely unlikely to fool the verifier.
• Zero knowledge: The verifier learns only that the statement is true and obtains no additional secret information.

For LLM inference, the statement can be expressed as:

The program or circuit P, using public input x and private input w as model weights, computes output y.

The public input x should include not only a request digest, but also binding information such as the model commitment, random seed, circuit hash, and proof system identifier. The private input w can be the model weights or a model commitment derived from the weights, but it must be ensured that the proof circuit can constrain this commitment to the private weights or weight-derived results.

Two statements must be clearly distinguished:

• “The response claims to come from a certain model”: This can be achieved through model version fields, logs, signatures, or commitments, but its proving power is limited.
• “The response was computed by the committed model under the specified input and randomness”: This requires a zero-knowledge proof to bind the public input, output, model commitment, and circuit constraints together.

Engineering should check five items:

1. Is the statement explicit: Are the public input, private input, output, and circuit boundary clearly defined?
2. Is the circuit or program hash public: circuit_hash or program_hash must be verifiable to prevent the service provider from using an undisclosed circuit.
3. Is the model commitment bound to private weights: Returning only a model digest is insufficient to prove that the weights were not replaced.
4. Is the random seed resistant to manipulation: The service provider cannot choose a favorable seed after the fact.
5. Does the verification key match the circuit: vk must correspond to the publicly verified circuit version and proof system.

4. End-to-End Flow: Commitment, Proof, Randomness, and Verification

The full chain can be divided into five stages:

Stage	Main inputs	Main outputs	Typical failure reasons
Request initiation	Prompt, caller one-time random number, session random commitment	Request ID, user nonce, session commitment	Request is tampered with or replayed
Commitment verification	Model fingerprint list, circuit list, proof system identifier	Valid model commitment, valid circuit commitment	Model commitment or circuit hash is not in the trusted list
Proof generation	Private weights, public input, output, circuit or program	Proof π	Circuit constraints are not satisfied or parameters are abnormal
Response return	Output, proof, seed, hashes, commitments	Verifiable response	Seed inconsistency, input mismatch, or missing binding
Client verification	Verification key, local request context, trusted list, proof	Verification passed or failed	Invalid proof, fingerprint mismatch, or local context inconsistency

1. Model Fingerprint Commitment: Must Be Bound to the Proof Circuit

The model provider can compute a commitment over the weights or key digests and publish it:

model_commit = Commit(model_weights, randomness)

However, it is important to note: a model fingerprint commitment alone cannot prove that the weights have not been replaced.

Only when the following conditions are satisfied at the same time can one further state that “the weights used for inference were not replaced outside the committed scope”:

1. model_commit is generated from the model weights or key digests of the weights.
2. The proof circuit takes model_commit as a public input and constrains it to be consistent with a derived result from the private input.
3. The circuit version used for proof matches the public circuit_hash.
4. The actual online execution environment is consistent with the circuit description, including model structure, parameter ranges, operator semantics, and necessary version identifiers.
5. The verification key vk can verify the circuit and proof system.

If the commitment only covers the model name, weight file hash, or inference service version number, and is not constrained to the actual computation path, it can only prove “the claim is consistent,” not that “the computation was not replaced.”

2. Proof Generation: Write Public Input into the Circuit

For each inference, the prover generates a proof. The public input should at least include:

public_input = {
    prompt_hash,
    seed,
    max_tokens,
    model_commit,
    circuit_hash,
    proof_system,
    output_hash
}

Proof generation can be abstracted as:

π = Prove(circuit, model_weights, public_input)

The response should return:

{
    user_nonce,
    prompt_hash,
    seed,
    session_random,
    max_tokens,
    model_commit,
    circuit_hash,
    proof_system,
    output,
    output_hash,
    proof
}

The caller confirms that “the computation satisfies the public circuit,” rather than obtaining complete weights or the complete intermediate reasoning process. The verifier does not perform full inference; it only verifies that the proof is consistent with the public input.

3. Public Random Seed Must Be Resistant to Manipulation

If the sampling randomness is decided unilaterally by the service provider, it may “pick the best-looking result” and then attach a proof. Therefore, the seed should be computable, auditable, and not manipulable unilaterally after the fact:

seed = Hash(user_nonce + prompt_hash + session_random)

Where:

• user_nonce: A one-time random number generated by the caller when initiating the request. It should come from a secure random source and be explicitly carried in the request.
• prompt_hash: A hash of the normalized prompt, used to prevent input substitution.
• session_random: Should come from a public randomness beacon, a session seed pre-committed by the service provider, or another randomness source verifiable by both parties. If provided by the service provider, it must be committed before response generation and cannot be chosen after the fact.

To prevent replay, the caller should record used user_nonce values or seeds and reject duplicate requests. Session randomness should also be bound to the request to avoid reuse across requests.

4. Client Verification Pseudocode: Must Verify the Local Request Context

The following is illustrative pseudocode, not production-ready code. hash_of, vk, trusted_model_commits, and trusted_circuits must be provided by a real implementation.

hash_of must use canonical serialization. Canonicalization requirements include:

• Fixed field order;
• Fixed field types;
• Fixed encoding format, for example UTF-8;
• Prohibition of ambiguous representations, for example unique representations for floating-point numbers, booleans, and null values;
• Include canonicalization rules in the request digest and audit logs to avoid input substitution or verification bypass.

import hashlib
def hash_of(obj: str) -> str:
    # Production systems must implement canonical serialization:
    # fixed field order, fixed types, fixed encoding, and no serialization ambiguity.
    return hashlib.sha256(obj.encode("utf-8")).hexdigest()
def random_seed(user_nonce, prompt: str, session_random: str) -> int:
    material = f"{user_nonce}|{prompt}|{session_random}".encode("utf-8")
    return int.from_bytes(hashlib.sha256(material).digest()[:8], "big")
def verify_response(
    resp,
    vk,
    trusted_model_commits,
    trusted_circuits,
    committed_session_random,
    local_request_ctx
) -> bool:
    # 1. Verify whether the random seed in the response is generated by a valid rule.
    expected_seed = random_seed(resp.user_nonce, resp.prompt, resp.session_random)
    if expected_seed != resp.seed:
        return False
    # 2. Verify whether the user nonce in the response equals the nonce in the local request.
    if resp.user_nonce != local_request_ctx.nonce:
        return False
    # 3. Verify whether the prompt hash in the response equals the hash of the normalized local request.
    if resp.prompt_hash != hash_of(local_request_ctx.prompt):
        return False
    # 4. Verify whether the session random number comes from a prior commitment or randomness beacon.
    if resp.session_random != committed_session_random:
        return False
    # 5. Verify whether the model fingerprint is in the trusted list.
    if resp.model_commit not in trusted_model_commits:
        return False
    # 6. Verify whether the circuit hash and proof system are in the trusted list.
    if (resp.circuit_hash, resp.proof_system) not in trusted_circuits:
        return False
    # 7. Verify whether the output hash matches the response output.
    if resp.output_hash != hash_of(resp.output):
        return False
    # 8. Verify that the proof confirms the output was computed by the committed model, committed circuit, and public input.
    return verify_proof(
        vk,
        resp.proof,
        {
            "prompt_hash": resp.prompt_hash,
            "seed": resp.seed,
            "max_tokens": resp.max_tokens,
            "model_commit": resp.model_commit,
            "circuit_hash": resp.circuit_hash,
            "proof_system": resp.proof_system,
            "output_hash": resp.output_hash
        }
    )

If verification passes, it indicates that the output corresponds to the committed model, the input was not replaced, the random seed was not unilaterally manipulated, and the circuit version matches the verification key. If verification fails, it at least indicates that the response did not pass the cryptographic check.

5. Engineering Implementation: Difficulties and Trade-Off Solutions

1. Proof Overhead: “Minutes-Level” Estimates Cannot Be Simply Extrapolated

Proof cost is strongly related to circuit scale. Academic research has cases of zero-knowledge inference verification for small vision models. For example, in some studies, under a specific model scale, specific circuit implementation, and specific hardware environment, proving the classification result of a single image may take on the order of minutes. However, such measurements cannot be directly extrapolated to large language models with billions of parameters and thousands of forward steps.

When evaluating proof overhead, the following must be provided together:

• Number of model parameters;
• Input sequence length;
• Number of output tokens;
• Batch size;
• Hardware environment, such as CPU, GPU, FPGA, or ASIC;
• Proof system type;
• Concurrency;
• End-to-end latency target;
• Proof size and network transmission cost.

Only when these dimensions are clearly specified can performance data be compared.

Common trade-off solutions include:

• Layered commitments: Build a hash chain for each layer output.
• Sampling proofs: Prove one layer, one operator, or one subgraph per proof, increasing the probability of detecting cheating over time.
• Critical-path proofs: Only prove computations that affect the final token distribution.
• Trusted execution environment as a transitional approach: In high-concurrency scenarios, first use remote attestation to prove that “the code is running in a protected environment and its hash matches the expected value,” then gradually introduce sampling proofs.

It should be noted: hash commitments or layered commitments alone cannot prove honest computation. They must be combined with proofs, sampling challenges, fraud proofs, or optimistic verification mechanisms. Sampling challenges require clear challenge windows, random selection rules, and verifiable evidence; otherwise, they may still be selectively avoided by the service provider.

2. Weight Confidentiality

Model weights are usually core assets. Zero-knowledge proofs allow weights to participate in computation as private input without revealing the original content. If the circuit design is wrong and weights are placed into public input, the model will be leaked. Engineering checks should include:

• Are weights used only as private input?
• Does the public input contain sensitive information other than weight digests?
• Are commitment random values securely managed?
• Do circuit debugging logs leak weights or intermediate states?

3. Deployment Differences

The same set of weights may produce different numerical results after quantization, operator fusion, hardware differences, and changes in batching strategies. The proof must precisely correspond to the actual online execution version. Otherwise, a situation may occur where “the model was not changed, but the proof does not match.” It is recommended to include the inference engine version, quantization scheme, operator implementation version, and key configuration in commitments or audit fields.

4. Model Updates

Each model iteration produces new commitment fingerprints, requiring version management, client trust list updates, and compatibility notes. Otherwise, old proofs may conflict with the new model list. Recommended practices:

• Generate a unique model_commit for each model version;
• Generate a unique circuit_hash for each circuit version;
• Have clients maintain a trusted list and effective dates;
• Trigger degraded warnings when old versions expire, rather than silent failures.

5. Differences Among Proof Systems: Selection Table

Different zero-knowledge proof systems are not equivalent:

Dimension	Concern	Selection suggestion
Trusted setup	Whether one-time trusted initialization is required	High-risk scenarios should assess transparent setups
Proof size	Whether it is suitable for frequent network transmission	High-concurrency interfaces should prefer small proofs
Verification cost	Whether client-side verification is lightweight enough	Especially critical for edge or external audit scenarios
Recursion capability	Whether proofs of proofs are supported	Suitable for large-scale batching and compression
Hardware acceleration	Whether GPU or specialized circuit optimization is required	Should be evaluated together with deployment cost
Toolchain maturity	Whether there are auditable circuits, debugging tools, and standard libraries	Production deployment should prioritize maturity

It is not recommended to only look at “whether proofs are fast.” One should also consider whether the circuit is easy to audit, whether the verification key can be publicly verified, and whether the proof system can be maintained long-term.

6. Privacy Boundary

Proofs should contain only necessary hashes and should not include user original text, sensitive prompts, or identifiable information. Public data should be minimized. Audit logs should also be de-identified to avoid exposing prompt originals, output originals, and identity identifiers in the same system for a long time.

6. Supply Chain Perspective: Who Can Use It, and What It Cannot Prevent

Location of use	Problems that can be addressed	Main limitations
Caller-side verification	Detect proxy downgrade, distilled-model impersonation, and response replacement	Requires vendors to provide proofs and accept overhead
Third-party detection platform	Unified cross-channel comparison and public leaderboards	Depends on proof availability or public access
Service provider self-proof	Respond to “degraded intelligence” questions	Can only prove that committed computation was executed, not whether parameter tuning is reasonable
Model provider audit	Locate problematic stages	Requires internal logs and commitment mechanisms

It cannot prevent the following situations:

1. Adjustments outside the commitment: If temperature, truncation strategy, or context window length are not included in the commitment, a passed proof does not mean the experience is consistent.
2. Prompt-level deception: If the system prompt is replaced, the model may still claim to be a certain model. The proof only covers computation, not the truthfulness of content.
3. Honest execution of a low-specification model: A service provider can commit to a low-specification model and then “execute it honestly.” The proof guarantees that the service provider does what it says, but not that the model specification is good enough.
4. Cost issues: Proof generation overhead may affect pricing. Callers must weigh the additional cost against the loss caused by model substitution.

7. Auditing Practices That Do Not Depend on Special Technologies

When verifiable inference cannot be used immediately, callers can first establish basic defenses. It is recommended to implement them in priority order:

P0: Minimal Logging and Benchmark Testing

Recommended minimal log fields include:

request_id, timestamp, model_version, seed, prompt_hash,
response_hash, token_usage, latency, proof_status, client_nonce,
model_commit, circuit_hash, session_random

Benchmark testing recommendations:

• Execution frequency: Sample at least daily; immediately perform regression after model version changes, channel changes, or price adjustments.
• Sample size: A fixed question set should include at least 100 to 300 items; if the business is complex, stratified sampling by scenario can be used.
• Example alert thresholds: Average score drops by more than 5%, refusal rate increases by more than 3 percentage points, average latency increases by more than 20%, or output length is significantly shortened.
• False-positive review process: First replay the request, then compare with multi-channel results; if the anomaly persists, check service provider change records, model versions, system prompts, and sampling parameters.

P1: Raw Response Archiving

Fully preserve request parameters, timestamps, model identifiers, original response content, token usage, commitment fields, and verification status. Auditing requires replayability, not only saving summaries.

P2: Multi-Channel Comparison

Send the same request to different channels and compare response style, refusal rate, capability boundaries, and latency distribution. This method cannot provide cryptographic proof, but can quickly detect anomalies.

P3: Contractual Constraints

Clarify model specifications, version change notification obligations, downgrade restrictions, proof fields, and liability for breach in service agreements. If there is no proof mechanism, at least agree on traceable logs and dispute handling.

P4: Private Deployment or Trusted Execution Environment

For scenarios with sensitive data and high compliance requirements, build a private model inference environment or use a trusted execution environment to reduce dependence on unilateral trust. If general cloud capabilities are used, object storage, log services, and monitoring and alerting capabilities from mainstream cloud platforms can serve as archiving and observability infrastructure, but they should not replace model proofs themselves.

8. Conclusion: From “Trusting Claims” to “Scenario-Based Verification”

Verifiable inference transforms “trusting the model provider” into “verifying computation results,” and the direction has value. Through cryptographic commitments and proofs, it makes “which model generated this answer, and under which inputs” an independently verifiable proposition.

However, it is not omnipotent. Proof cost, engineering complexity, and model governance constraints determine that it is more suitable for scenarios such as compliance audit, high-value reasoning, external reporting, and model evaluation, rather than being immediately available for all online services. For developers, the pragmatic path is: first use logs, benchmark testing, and multi-channel comparison to establish basic defenses; then introduce sampling proofs or full proofs in critical paths; and at the same time pay attention to progress in circuit optimization, recursive proofs, and hardware acceleration. Verifiability will not immediately replace trust, but it will become an important dimension in competition among model services.