DeepProve: proving LLM inference with sumchecks and logup GKR

The problem DeepProve solves, and who it is for

A model provider can return any output it likes. A user who wants to verify that a claimed inference really came from a specific set of weights, on a specific input, has no way to check it without re-running the model. DeepProve attacks that gap by generating a zero-knowledge proof of a neural network forward pass. The proof convinces a verifier that the computation was performed correctly, without the verifier repeating it.

The README frames the target as full LLM inference, not a single layer or a toy network. It states that transformer layers are proven end-to-end, from token embeddings through to next-token argmax, and names GPT-2, Gemma 3 and Llama 2 as confirmed working models. MLP and CNN inference is also supported. That scope matters: many zkML projects prove a small model or a fragment of a network, and the interesting engineering is in the layers that do not fit neatly into a circuit.

The audience is narrow. This is for teams that already understand what a zk-SNARK is and want to apply one to model inference, either to publish verifiable inference results or to build a proving service. It is not a library you drop into a Python notebook. The repository is a Rust workspace with six crates, and the core proving library is one of them.

How the proving pipeline is put together

The README describes the proving technique as sumchecks and logup GKR, and claims sublinear proving time in model size. That is the central design choice: a circuit-based approach encodes the whole network into an arithmetic circuit, and the circuit grows with the model, so proving cost grows with it. A sumcheck and GKR approach proves the layered computation more directly, which is where the claimed 10 to 30 times speedup over the previous published state of the art comes from. The README cites zkGPT at roughly 0.05 tokens/s on similar hardware as the comparison point.

The workspace splits responsibilities across crates. zkml holds model quantization, the layer implementations for MLP, CNN and transformer, and proof generation and verification. deep-prove is the client stack: deep-prove-worker runs a proof generation server, and deep-prove-cli submits proving jobs either locally or to a remote proving network. tenstore is a storage facade for persisting and retrieving tensor data, with local and S3-compatible backends. tenvis is an interactive CLI for inspecting and debugging proof data in tenstore. telemetry provides shared OpenTelemetry tracing, and utils provides CSV recording, memory tracking and statistical summaries.

Two details in the workspace manifest are worth noticing. The dependency list includes dp-crypto, pulled from a git branch named feat/hkzg_gpu, and the tenstore crate uses object_store with the aws feature. Proving and storage are both designed to be distributed, which matches the README's statement that horizontal proof distribution and GPU acceleration are supported today, with clusters of GPU workers on the roadmap. The accuracy claim is also specific: at least 99.6 percent cosine similarity to the floating-point baseline at 12-bit quantization for GPT-2. Quantization is therefore part of the trust story, not an optional optimization you can ignore.

Installing DeepProve and running a first proof

The top-level README deliberately does not carry the installation steps. It points readers to zkml/README.md for installation, model setup, the GPU build and the full end-to-end bench-llm tutorial. That is the file to open first. The workspace declares edition 2024 and version 2.0.1, so a recent Rust toolchain is required; the repository pins one in rust-toolchain.toml.

The README gives the repository URL and states that the zkml crate is the core proving library, with the remaining crates providing the client stack, storage layer and developer tooling.

members = [
  "zkml",
  "deep-prove",
  "utils",
  "tenstore",
  "tenvis",
  "telemetry",
]

The repository also ships a devenv.nix and a devenv.yaml, plus a docker/ directory, so there are two supported ways to get a working environment without assembling the native dependencies by hand. The .envrc file at the top level suggests direnv integration with the devenv setup.

The client stack is described in the README as two binaries: deep-prove-worker, which runs a proof generation server, and deep-prove-cli, which submits proving jobs locally or to a remote proving network.

zkml = { path = "zkml" }
tenstore = { path = "tenstore" }

After that, the bench-llm tutorial in zkml/README.md is the path to a first real proof. The README does not reproduce the bench-llm flags, model paths or environment variables on the top-level page, so treat that file as the source of truth rather than guessing at command-line options. What you should expect to see, based on the headline numbers, is a proving run measured in minutes for a 512-token sequence and a verification measured in seconds.

Where DeepProve is the wrong tool

Proving time is the first constraint. The README's own table reports 7.6 minutes to prove a 512-token GPT-2 sequence on a 24-core, 504 GB CPU server, and 19 minutes for Gemma 3 at the same sequence length. Verification is 1.3 seconds and 4.3 seconds respectively. Those are single-machine numbers on a large server. If your use case needs a proof returned inside a request timeout, this is not the system for it yet.

Proof size is the second constraint. 10.7 MiB for GPT-2 and 27 MiB for Gemma 3. A proof that large is fine for batch audit or for publishing a result, and awkward for anything that has to move through a constrained channel.

Model coverage is the third. The README lists GPT-2, Gemma 3 and Llama 2 as confirmed working, and adds MLP and CNN support. A model outside that set is unproven territory, and the README does not describe a general path for onboarding arbitrary architectures. The accuracy floor is also a real trade-off: 12-bit quantization with at least 99.6 percent cosine similarity to the float baseline means the proof attests to the quantized model's output, not the original model's output. If your application depends on full-precision behaviour, that gap is the thing to examine before anything else.

Finally, the top-level README is a summary by design. Installation, GPU build and the bench-llm tutorial are all deferred to zkml/README.md, and the paper is referenced as a link to be added. Anyone evaluating this from the front page alone is working from headline numbers without the methodology behind them.

How DeepProve differs from circuit-based zkML

The natural alternative is a circuit-based zkML system, and the README names one: zkGPT, reported at roughly 0.05 tokens/s on similar hardware. The difference is in what gets proven. A circuit-based system compiles the network into an arithmetic circuit and proves satisfaction of that circuit. Cost scales with circuit size, and for a transformer the attention and feed-forward layers produce a large circuit. DeepProve instead proves the layered computation with sumchecks and logup GKR, which the README says gives sublinear proving time in model size. The throughput gap quoted is 1.12 tokens/s for GPT-2 against roughly 0.05 tokens/s for zkGPT.

That comparison comes with conditions. The numbers are single-machine, CPU-only, on a 24-core machine with 504 GB of RAM, and the README itself notes that zkGPT's figure is on similar hardware. The 10 to 30 times range is the project's own characterization of the previous published state of the art, not an independent measurement. The methodology is deferred to a paper whose link is still to be added, so right now the claim rests on the README table.

The architectural difference also shows up in the repository layout. DeepProve separates the proving library from a worker server, a CLI, a tensor storage facade and an inspection tool. That is a distributed-systems shape, not a single-binary shape. A circuit-based tool that runs as one process is simpler to operate; DeepProve's split is what makes horizontal proof distribution possible, and it is also what makes the deployment story larger.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-05-31. That is roughly three and a half months before today, which is recent enough that the project is not dormant, but no releases were retrieved, so there is no release history to read. Versioning is visible in the workspace manifest at 2.0.1, and there is a CHANGELOG.md plus a cliff.toml, which indicates changelog generation is configured. There is also a VERSION file at the top level.

Upgrade cost is hard to judge from the README, and that is a finding in itself. The workspace pins a git dependency on dp-crypto at a branch named feat/hkzg_gpu rather than a released version, and two more dependencies come from git repositories rather than a registry. Branch-pinned dependencies mean an upgrade can pull in changes you did not choose. The edition is 2024, so older toolchains will not build the workspace without an update. A rust-toolchain.toml pins the expected compiler, which reduces but does not remove that friction.

Licensing needs attention. The README says the project is licensed under the Lagrange License and links to a LICENSE file, while the workspace manifest declares MIT OR Apache-2.0. Those two statements do not agree, and the repository metadata reports the licence as NOASSERTION. The Lagrange License is not a standard identifier, so its terms have to be read directly before you depend on the code. I am not giving legal advice here; the point is that the discrepancy is real and you should resolve it with whoever handles licensing on your side before shipping anything built on this.

Editorial conclusion

Adopt DeepProve if you need cryptographic proof that a specific model produced a specific output and you can accept minutes of proving time on a large CPU machine. Do not adopt it if you need sub-second proofs, if you cannot read the Lagrange License, or if your model is not GPT-2, Gemma 3, Llama 2, an MLP or a CNN. Before committing, read zkml/README.md end to end and run the bench-llm tutorial on your own hardware, because the headline numbers come from a 24-core, 504 GB server and the README does not document how proving time degrades on smaller machines.

Frequently asked questions

Official sources

1. Issues
2. Lagrange-Labs/deep-prove on GitHub
3. Project website
4. README