Roy Rinberg (Anthropic), Alex Allain (Anthropic); Alessandro Chiesa (EPFL, StarkWare), Miranda Christ (MIT, RESI), Rahul Dalal (Anthropic STEM Fellows Program, Succinct), Giacomo Fenzi (EPFL), Ben Mayer (Anthropic Fellows Program, MIT), Guy Weissenberg (EPFL)
When you talk to a friend in person, you have many ways to know it is really them: you can see them, hear them, shake their hand. When you talk to an AI model, you have almost none. A user querying a model today cannot check that the responses came from the specific model that a developer claims is responding, as opposed to one secretly substituted in by a routing service for cost reasons, or even by an attacker who has tampered with the token stream. Judging from the model’s output alone is unreliable, even if it produces high-quality responses. Cryptographic proofs of inference solve this problem: they let a model provider commit to a model and then prove that each response was produced by that model. Such proofs could enable applications ranging from consumer products to internal security, and could contribute to a toolkit for verifying compliance with AI pacing requirements.
Specifically, we have made progress on a powerful type of cryptographic proof known as a “zkSNARK”, which is uniquely fit for provable inference (owing to its strong hiding and efficiency properties). In this post, we share some of that progress, primarily through a system we call FlashProve. A brief technical summary is as follows:
Today we are releasing five artifacts:
We release our code, Lean proofs, and documentation under the Apache 2.0 license. This research post is meant to share intermediate progress, and not a completed research agenda. We are sharing this explicitly with the goal that others look at what we have done, take it, and improve it.
When a user sends a request to an AI model, today they have no way of knowing for certain that the model they selected is the one that generated the response. For everyday uses, in which users mostly care about the output and not necessarily which specific model produced it, this is a less pressing concern. But there are several cases where such assurance would be useful. For example, independent evaluators who test AI models before and after release need to know that the model they are evaluating is the model being served. Clients who use a model through a third-party routing service want assurance that the tokens came from the model they paid for. And if a cyberattacker modifies the token stream while pretending to be a given model, a user has no way to detect it from the output alone.
However, enabling verification of model responses is challenging. Most frontier models’ weights are kept private, and even if the user had access to the weights, checking that a given response was produced by a model with those weights would involve running the model, which requires computational resources far beyond what a typical user (or even evaluator) can afford.
The goal of provable inference (PI) is to enable a user with limited computational resources and without any information about the weights to verify that a response came from the requested model. PI is motivated both by a desire to increase customer trust in AI providers, and—because it can be used to provide assurances to independent evaluators and allows providers to demonstrate that they are meeting certain commitments and legal obligations—it also has implications for pacing the frontier of AI development and for AI regulation.
One way to implement PI is via a cryptographic object called a zero-knowledge succinct argument: the model provider sends, along with the claimed response, a short proof (say, a few megabytes) that the user can quickly verify (ideally, in seconds on a CPU). If the claimed response deviates from the specified model, the user’s check will fail. Importantly, cryptographic techniques ensure that the proof reveals nothing about the model’s weights.
Today, we release FlashProve: an open-source performant prototype for provable inference. For a 400B-parameter mixture-of-experts model (Llama 4 Maverick, 4-bit quantization), we show that a single H100 GPU generates proofs at over 100 tokens/second, with proof size of ~19 MB per 1,024-token request (~70-95 times the GPU time that vLLM, a common open-source library, takes to process prompts of the same length).
The release comes with executable code, Lean formalization, and a technical description of the protocol. Our aim is twofold: (i) accelerating and facilitating the development of provable inference; and (ii) demonstrating that zero-knowledge succinct arguments are practical for provable inference.
We believe that this progress has meaningful implications for security, in pacing AI development, in providing AI customers with integrity guarantees, in facilitating tooling for auditors and regulators, and more.
The development of artificial intelligence and its growing role in our digital infrastructure and economy raises trust challenges that AI providers must answer. Addressing these and other challenges is facilitated by relying on tools for provable inference (PI).
Tools for PI include hardware approaches, software approaches, or a combination of both. Here, we focus on a software-only approach: a cryptographic tool known as a “zkSNARK” (zero-knowledge succinct argument of knowledge). Informally, a zkSNARK is a system allowing a prover to convince a verifier, by way of a short “certificate”, that a given computation was executed correctly; crucially, the certificate is zero-knowledge in that it reveals no information beyond what is implied by the computation’s correctness and is succinct in that it’s exponentially faster to verify compared to the proved computation.
Below we outline several challenges and how zkSNARKs help in addressing them.
Some proposals to regulate and pace AI development rely on monitoring hardware and how it is used. For example, a provider might be required to devote its hardware to inference rather than to training a powerful new model. The provider might try to cheat by serving cheaper models or using compute in an unexpected way, freeing up resources for training. How can a regulator reliably ensure that the hardware is used for inference?
How zkSNARKs can help: The regulator can ask the provider for certificates covering the inference requests served in a given period. The certificates must show that the requests were generated by the claimed model. A malicious provider cannot satisfy this request unless its hardware was genuinely serving the right model. Using a zkSNARK, the regulator can check that the provider claims are valid without needing the elaborate hardware setup that the provider may have, and at the same time the provider has the guarantee that the regulator does not learn proprietary model information. We note that although this verifies that the hardware is serving inference, it does not establish that the hardware is not, e.g., training on the side.
As AI models grow more valuable, the servers that run them become prime targets. An attacker or rogue agent may compromise an inference server to exfiltrate the weights, serve users malicious responses (such as delivering malware to the user’s computer), and more, all while hiding among genuine responses. The adversary need not be external. As models become capable of improving and deploying themselves, a more advanced model could run in place of the one that was authorized and present itself as the weaker model, so as to avoid the classifiers and monitoring that would apply to it. In both cases the question is the same: how can a company be sure of which weights are actually running on its servers? In our Frontier Safety Roadmap, Anthropic set a public goal to produce a prototype for verifying inference traffic: “We will develop a prototype by September 30, 2026 of provable inference, a technique for reliably, provably ‘signing’ AI model outputs in a way that makes them attributable to a specific set of model weights.” As stated in our RSP updates, we met that goal through a separate but related project, which signs our inference traffic and recomputes inference on a trusted server; the work in this blog post pursues the same objective by a different method.
How zkSNARKs can help: The provider can require a valid zkSNARK from the server on every response. A proof is bound to a specific commitment to the weights, so it certifies not just that some model produced the response but that the committed model did. An attacker who compromises a server, or a model that substitutes itself for another, must then produce valid proofs for the expected weights to avoid detection, which they cannot do. The user may receive the proofs as well, since they leak no internal information (by zero knowledge) and are cheap to check (by succinctness); this limits what an attacker can accomplish through the inference API.
One may want to prove that considerable effort went into understanding/analyzing something. For example, a developer might claim that their software library was scanned for vulnerabilities by a frontier cybersecurity model, or a company might claim that its business plan was given the go-ahead by an appropriate model. How can a user verify these claims? The user might not have the resources to run the model itself (or they might not have the clearance to do so). Even publishing the chat logs gives no absolute guarantees; a developer might in theory fake them, generating them not with a frontier model but instead with a cheaper one or a degraded version. In general, how can users verify that they are being served by their chosen model?
How zkSNARKs can help: The provider can append, along with each response, a zkSNARK proving that the output was produced by the claimed model on the given input. Succinctness lets the user check this certificate quickly, without specialized hardware, and zero-knowledge assures the provider that the user learns nothing about the proprietary weights. This complements existing mechanisms for verifying which model produced a response.
For example, in a world where exploits are being found regularly, prior to releasing new code a model provider could provide the code-developer a Proof-of-Failure that the model-provider spent at least X tokens on a specific model, and did not achieve a specific result (for example, this specific model did not find any bugs in a specific patch, after trying for at least 1M tokens).
Regulation might require providers to serve only models approved as safe, rather than models deemed a cybersecurity or safety risk. A provider might have an incentive to circumvent this, since risky models might outperform competitors or be cheaper to serve. How can a regulator ensure that only approved models are served?
How zkSNARKs can help: The regulator can require the provider to attach a zkSNARK to its responses, enforcing the use of approved models. The proof binds each request to the used model, so it will not verify if the provider is using an unapproved model. The regulator can check this in a lightweight way thanks to succinctness without requiring to re-execute each request.
A note on PI from trusted hardware. Prior work often focuses on trusted execution environments to achieve PI. These are hardware-based solutions that provide privacy and attestation that rely on the manufacturer producing tamper-resistant hardware. In this research, our focus is on software-only cryptographic solutions whose security and privacy relies on the hardness of computational problems. Even in the face of compromised environments (hardware, operating system and more) an adversary cannot produce a invalid proof without breaking a computationally infeasible problem. Trusted hardware and cryptography are complementary approaches with different guarantees and tradeoffs. Both will play a role in addressing the above trust challenges.
FlashProve is a system for provable inference of large Mixture-of-Experts (MoE) language models. More details are in our technical report; here we outline the system.
FlashProve involves two parties: the model provider (the prover) and a user (the verifier). It is split into two phases:
The committed model produces these output tokens when evaluated.
Anyone who holds the commitment, the prompt, and the reply can check it, without the weights and with limited compute power, and be convinced that the committed weights, run on this prompt, produce exactly these tokens.
A proof file satisfies the following “completeness” and “soundness” properties:
Completeness and soundness alone can be achieved by a computationally powerful verifier that knows the model weights (evaluate the model on the prompt and check whether the result matches the response). The next two properties are what makes the system non-trivial.
We measured an implementation of the protocol on Llama 4 Maverick (a 400B-parameter mixture of experts, with ~17B parameters used per token), using the publicly available 4-bit weights. Each verifier request is a window of 1,024 tokens, and each proof checks one token. The prover runs on a server with a single H100 and 24 CPU cores, and the verifier on a CPU.
Comparison with plain inference: We ran vLLM, a widely used inference engine, with the FP8 release of the same model on eight H100s, and found that, per GPU, proving a batch of 24 requests takes about 72 times longer than vLLM takes to process the same 24 requests at once (66 to 77 across runs), and about 94 times longer when vLLM runs at the highest load we tried.
Inside the system. The underlying mechanism behind FlashProve is a zkSNARK of the kind deployed in peer-to-peer systems (e.g., L2 networks such as Starknet or Mantle for blockchains like Ethereum). Our zkSNARK is built according to a well-established recipe: an underlying information-theoretic object called an interactive oracle proof (IOP) is compiled into a cryptographic proof by relying on hash functions (and offers even post-quantum security). Our IOP is assembled from state-of-the-art building blocks using tools such as code proximity tests with linear constraints and lookup arguments, which are based on techniques from coding theory and complexity theory. Combining these pieces into a bespoke IOP for inference is a delicate task; more details about the construction can be found in the technical report.
FlashProve benefits from architectural decisions that we took, and which are discussed in detail in the technical report. Here we highlight a few:
When integrating proving mechanisms into inference servers there is a choice: in-line proving (i.e. proving alongside the inference) versus post-hoc proving (i.e. proving after-the-fact, for a subset of tokens). Our system follows the latter. In-line solutions are expected to be ultra-fast and may sacrifice security for efficiency, whereas post-hoc solutions are allowed to be slower and may not suffer such a tradeoff. On the other hand, post-hoc proving has limitations: added complexity of recomputation, the delay in getting guarantees about your traffic, and inherent “non-determinism”. We elaborate on the motivation and implications of post-hoc proving in the technical report.
Cryptographic code is notoriously brittle and error-prone. How can users trust the code we’re releasing today?
The answer is formal verification: we use the Lean proof assistant to specify the protocol and the desired security properties. We prove these properties in a form that is machine-checkable and guaranteed to be correct (up to compiler errors). We target three top-level properties:
These properties are stated in the so-called random oracle model, an information-theoretic way to analyze cryptographic protocols that rely on hash functions.
Formal verification leaves two important trust gaps. First, the formal statements must be audited to ensure that they match their intent. This has to be done manually (though it is dramatically less onerous than auditing proofs); we provide an interactive visualizer to assist with this.
Second, the executable code must be audited to ensure it matches the formally-defined protocol for which the security properties are proven. How to best assist with this depends on the property, because soundness depends solely on the verifier, zero-knowledge depends solely on the prover, and completeness depends on their interaction.
Achieving provable inference is the objective of a line of work colloquially termed “zkML”. Early works, such as SafetyNets (2017) verified a two-conv-layer MNIST CNN and a small fully connected speech model, zkCNN (2021) reached VGG-16 (15M parameters) at 88.3 s per proof, and Kang et al. (2022) proved MobileNet v2 on full-resolution ImageNet.
Transformer proofs followed: ZKML’s GPT-2 took about 159 s per token for 117M parameters (≈0.006 tok/s), and Modulus Labs’ 1.5B-parameter GPT-2 XL needed over 90 hours. EZKL (2023) proved a 1M-parameter GPT-style transformer in about 966 s per token (≈0.001 tok/s). Performance progressively improved: zkLLM (2024) proved LLaMA-2-13B on a 2,048-token input in about 15 minutes on GPU, which is ≈0.001 tok/s per new token, or ~2.5 tok/s in the batch. In 2025, zkGPT reduced GPT-2 to 21.8 s (≈0.05 tok/s), zkPyTorch proved Llama-3 8B at ~150 s per token on one CPU core (≈0.007 tok/s), and ZKTorch proved GPT-J (6B) in about 20 minutes (≈0.001 tok/s). VerInf proved Llama 4 Maverick (the same 400B-parameter MoE model we prove) at ≈0.02 tok/s. DeepProve, a current peer-reviewed state of the art, certifies an entire generated sequence with a single forward pass. It reaches about 2.9 tok/s for GPT-2 and 1.4 tok/s for Gemma 3 on one machine, and 31 tok/s distributed. SASH's prover (2026) reached ≈1.25 tok/s on Llama 3.1 8B on a single H100.
Recently commercial efforts have reached impressive numbers, with Attestable proving Gemma 4 31B at 53–77 tok/s on a single H100; at the time of writing, Attestable has not released a corresponding open source library.
The above numbers speak to the precipitous progress of provable inference in the past years. They should update our priors on what it is possible to prove in zero-knowledge.
We believe that the progress should transfer to more models and architectures, yielding a flexible and powerful tool with overhead over native computation of roughly 2 orders of magnitude (about 70 to 95 times in our measurements), much less than previously expected.
This release is a research prototype, and has the following technical limitations: