Does Proof Cost Follow What the AI Actually Runs?

Imagine a workshop with 64 tools on the wall.

One job uses six of them.

If the workshop buys another 48 tools but the job still uses the same six, should the time for that job quadruple?

Probably not.

If each of the six active tools becomes eight times larger and performs eight times as much work, should the job take longer?

Probably yes.

That is the intuition behind proof-carrying sparsity.

A Mixture-of-Experts model stores many feed-forward networks but selects only a few for each token. SparseProve asks whether a proof can follow that selected route without trusting the server to invent it.

The first two articles explained how to prove the route and selected computation. This article asks the empirical question:

Does measured proof cost respond mainly to the conditional computation that actually executes, or does it still scale with all the expert capacity installed in the model?

The answer is promising, but it needs careful language.

DeepProve is faster in the current qualified proof-core comparison. SparseProve’s strongest result is not a leaderboard victory. It is a causal pattern: installed capacity barely moves the measured proof core when selected work is held fixed, while executed work moves it substantially.

Separate the model from the route

An MoE layer has two sizes.

The first is the size of everything it could run: all installed experts.

The second is the size of what it did run for this input: the selected route.

For a DeepSeekMoE-shaped block, the full configuration has 64 routed experts and selects six per token. It also runs one shared feed-forward path.

The model needs the router scores from all 64 candidates to justify the route. SparseProve does not make that work disappear.

The narrower thesis concerns expert application:

After the route is proved, the checked selected-expert work should follow the selected route instead of materializing every inactive expert body.

This distinction matters because an easy benchmark can accidentally test something else.

If we compare a 16-expert model with narrow experts against a 64-expert model with wide experts and more tokens, the larger proof may be slower. But we will not know whether the cause was installed capacity, executed width, batch size, memory pressure, or fixed proof overhead.

A causal experiment changes one quantity at a time.

Turn three different knobs

The calibration uses three structural variables:

• E: how many routed experts are installed;
• m: how wide each selected expert is;
• T: how many tokens are proved together.

Each variable asks a different question.

Installed experts E

Increasing E adds capacity the token did not select. If selected expert bodies and active edges stay fixed, this is the cleanest test of whether inactive capacity leaks into the expensive proof core.

The router still sees more candidates. The verifier may still process model-sized metadata. So we should not expect every timing boundary to remain flat.

Executed width m

Increasing m makes each selected expert perform more matrix work. This changes the computation that actually runs.

If proof cost follows execution, this control should move strongly.

Tokens T

Increasing T creates more selected token-expert edges. But routes can overlap. Four tokens selecting six experts each create 24 edges, yet they may touch fewer than 24 unique experts.

Grouping lets the linear down-projection suffix reuse an expert across those tokens. This control measures amortization.

The experiments use checkpoint-derived fixtures and fresh processes. They preserve the selected expert bodies when varying installed capacity. Every measured receipt verifies.

That is important, but it is not enough. We also need to name what the clock measures.

Never report “proving time” without a boundary

Suppose System A reports 10 seconds and System B reports 15 seconds.

Which is faster?

We cannot know until we learn what each timer includes.

One timer may include witness construction, setup, serialization, and self-verification. Another may measure only the cryptographic proof core. A third may include writing gigabytes of public operands to disk.

SparseProve separates three useful boundaries.

Online time covers the request path: witness construction, commitments, proof construction, serialization, and the other request-specific work included by the harness.

Proof-core time isolates the cryptographic core: commitments, composition, FRI, and openings. It excludes witness construction, setup, serialization, and self-verification.

Verifier time measures the separate process of parsing the statement and proof and returning accept or reject.

These boundaries answer different questions:

• How long does a user wait for one receipt?
• How expensive is the proof backend itself?
• How much work does an independent verifier perform?

The causal result below uses proof-core time because it is the cleanest available view of how the relation’s structural work changes.

It is not a complete product-latency result.

The structural theorem in this figure is even narrower. It counts calls to one checked expert-apply primitive: k + s on the SparseProve route versus E + s in a materialize-all baseline.

That invocation ratio predicts a direction. It is not a wall-clock ratio.

The measurements test whether the complete proof core shows the same direction after fixed costs, routing, nonlinear traces, commitments, and openings are included.

Control 1: install four times as many experts

First hold the activated work fixed and increase installed experts from 16 to 64.

That is a fourfold increase in routed capacity.

The fixtures preserve:

• selected original expert identities;
• selected expert tensors;
• selected router rows;
• the shared tensors;
• active token-expert edges;
• and selected down-weight counts.

The complete numerical outputs are not bit-identical across capacities because removing unselected experts changes the full softmax denominator. The causal claim is about selected bodies and proof work, not equality of the full MoE function.

At one token, proof-core time changes by 1.054x.

At four tokens, it changes by 0.972x.

The second number is not interpreted as adding experts making the proof faster. It is ordinary measurement variation around a nearly flat response.

The defensible conclusion is:

Quadrupling installed experts left proof-core time within 5.4% of the 16-expert endpoint while selected work remained fixed.

This is the first half of the causal argument.

Inactive capacity moved a lot. The measured proof core moved little.

Other boundaries did move. At one token, online time grew 1.228x, and verifier time grew from 2.59 seconds to 5.23 seconds because the current verifier rebuilds model-sized preprocessed material.

So the relation is not model-succinct. The proof core can follow selected work while the broader system still pays installed-capacity costs.

That is a valuable negative result because it identifies where future engineering should focus: registered model preprocessing, reusable commitments, and selected-expert authentication.

Control 2: increase work inside the selected experts

Now keep E = 64 and T = 1, but increase selected expert width from 176 to 1408.

That is an eightfold increase.

Both semantic selected down-weight cells and their padded committed footprint grow eightfold.

Proof-core time grows 6.264x.

This is not exactly eight because the proof includes work that does not scale with selected width. Fixed commitments, router checks, transcript operations, and other components dilute the response.

But compare the two controls:

• installed experts: 4x capacity -> at most 1.054x proof core;
• executed width: 8x selected work -> 6.264x proof core.

That contrast is the strongest evidence in the study.

It does not prove an asymptotic theorem. Seven finite points cannot establish that proof cost is mathematically independent of installed capacity for all configurations.

It does show that, in the frozen calibration relation, the measured cryptographic core responds much more strongly to work that executes than to expert bodies that remain inactive.

Control 3: prove several tokens together

One token selects six routed experts.

Four tokens select 24 token-expert edges.

But the four routes touch only 15 unique routed experts in the measured fixture.

That overlap matters because the linear down-projection suffix can be grouped by expert.

Moving from one token to four produces:

• 4x active edges;
• 2.125x semantic active down-weight cells;
• 1.80x padded committed down-weight cells;
• 2.683x proof-core time;
• and 0.671x proof-core time per token.

This is amortization, not free computation.

The nonlinear token-expert work remains. Every selected gate, activation, and hidden product still needs a witness and constraints. The saving comes from reusing compatible linear expert work when routes overlap.

The result also explains why token count alone is a weak cost predictor.

Two four-token batches can touch different numbers of unique experts. A concentrated router may reuse the same few experts. A dispersed router may touch many.

The useful evidence therefore records both:

• token-expert edges;
• and unique experts touched.

That is the MoE version of measuring the work that actually ran.

Compare with DeepProve without changing the question

A new system should not compare only with a deliberately dense baseline.

SparseProve also uses DeepProve, a state-of-the-art zkML system, as an external calibration.

The comparison tries to match application behavior:

• the same checkpoint fixture;
• the same quantization policy;
• the same router outputs and canonical routes;
• the same selected expert operands;
• and the same final outputs.

SparseProve proves canonical routing inside its receipt. The DeepProve adapter derives the same route from public logits and binds selected public operands before verification.

That is useful application matching.

It is not a same-relation, same-security experiment.

The proof relations, transcripts, setup models, and security assumptions differ. Concrete end-to-end security bits are unset for both reported rows. DeepProve’s benchmarked HyperKZG adapter uses a reproducible public-seed test setup, so that setup is not binding against a malicious prover.

DeepProve is faster on proof core at both measured points:

• 1.94x faster at T = 1;
• 1.35x faster at T = 4.

In this separate external calibration, when token count grows fourfold, SparseProve’s proof core grows 2.926x while DeepProve’s grows 4.195x. The finite gap narrows.

That is interesting. It is not enough to claim a scaling law.

The T = 4 runs approach the 64 GiB host’s memory boundary. SparseProve uses 50.85 GiB; DeepProve uses 51.47 GiB. Two token counts under memory pressure cannot establish which system batches better in general.

The honest comparison is therefore:

DeepProve leads proof-core time in the qualified calibration. SparseProve remains in the same broad performance category while proving a verifier-bound route, and the finite gap narrows at four tokens.

Request-time comparisons are even less portable. The DeepProve adapter serializes verifier-reconstructible public operands into very large containers. Removing measured serialization helps explain the boundary, but it is not a directly measured optimized integration.

So the study reports no cross-system request-time winner.

State the result that survived the controls

The experiment supports one strong conclusion and rejects several tempting ones.

What survived:

1. Quadrupling installed capacity left proof-core time near the smaller endpoint when selected work was fixed.
2. Increasing executed expert width eightfold increased proof-core time 6.264-fold.
3. Batching four tokens amortized selected linear work when their routes overlapped.
4. SparseProve stays within 2x of a state-of-the-art external system on both measured proof-core rows, making the architectural result practically relevant.

What did not survive:

• a claim that complete proof cost is asymptotically independent of installed experts;
• a claim that SparseProve beats DeepProve;
• an equal-security comparison;
• a production-security benchmark;
• or a complete language-model result.

This leaves us with a result that is narrower and more interesting than “our benchmark is fast”:

In a checkpoint-derived MoE-block calibration, SparseProve’s proof core responds much more to executed conditional work than to installed expert capacity, while the route that defines that work remains verifier-bound.

That is the empirical half of proof-carrying sparsity.

The architectural half came in the earlier articles: the server does not get to choose an unchecked cheap path. It proves the scores, canonical route, registered selected weights, selected nonlinear computation, and output together.

The next research step is to remove the model-sized work that remains around that core: register model weights once, authenticate only selected experts per request, and batch openings across tokens.

If that succeeds, the useful unit will not be “one model proof.”

It will be:

one registered checkpoint, many receipts whose online cost follows the conditional computation each request actually uses.

That is how a research block becomes practical zkAI infrastructure.