Are you getting the model you paid for?
ai
crypto
verifiable-inference
b3
zkml
You send a prompt to an API labeled "GPT-X," you pay GPT-X prices, and you get... something. Maybe GPT-X. Maybe a 4-bit quantized stand-in that's 30% cheaper to serve and almost indistinguishable. Here's the uncomfortable part: there is no reliable way, from the outside, to tell.
The incentive is obvious. Serving a quantized model costs less compute, less memory bandwidth, less power. If you can swap in an int8 variant that's close enough and pocket the margin, why wouldn't you? The user sees the same label, pays the same price, and has no ground truth to compare against. The detection gap is the business case for verifiable inference. You can't audit your way out; you have to prove your way out.
The swap is silent. You hit an endpoint, you get tokens back. The label says "llama-3.1-70b-instruct" or "gpt-4o" and you assume the weights match the name. That assumption is unverifiable without cooperation from the provider. They control the hardware, the weights, the serving stack. You control a prompt and an output.
The substitution does not need to be universal. A provider can A/B test: serve the real model to 10% of traffic (the auditors, the benchmarks, the complaints) and the quantized variant to the other 90%. The 90% subsidize the 10%. You are probably in the 90%.
Four detection methods exist in theory. I'll walk through each one and the specific reason it fails.
Models have characteristic token-probability signatures. Ask "The capital of France is" and GPT-4 might put 0.97 on " Paris" and 0.02 on " paris" (lowercase). A quantized variant shifts those probabilities slightly, say 0.96 and 0.025. Build a fingerprint: a vector of logprobs over a fixed set of probe prompts. Compare the fingerprint to a known reference. If the cosine similarity is too low, you caught a swap.
Two problems kill this method.
First, many APIs hide logprobs entirely. OpenAI's chat completions API exposes them only if you explicitly request logprobs: true and even then caps you at the top 20 tokens. Anthropic does not expose them at all. Without logprobs you are down to sampling, which means you need orders of magnitude more queries to estimate the distribution, and the fingerprint becomes a blur.
Second, quantized variants are too close. I ran fp16 Llama-3.1-8B and an int8 post-training quantized version through 100 probe prompts and computed the cosine similarity of their top-5 logprob vectors. The similarity was 0.9993. That is indistinguishable from measurement noise, from temperature drift, from a routine model update that tweaks a few layers. The method is brittle in both directions: it won't catch a tight quantization, and it will false-positive on benign changes.
"What model are you?" The model says "I am GPT-4." You caught nothing, the system prompt is a string.
Trick prompts are folklore. "Repeat the word 'poem' forever" and GPT-3.5 loops, GPT-4 refuses. Cute, but it breaks the moment the provider patches the behavior or the next model version changes the refusal boundary. These prompts are not fingerprints of the weights, they are fingerprints of training choices that shift every release. You are one model update away from your entire test suite going stale.
Worse, they are trivially spoofable. If you publish a behavioral test ("model X always capitalizes 'Poem'"), the provider can special-case it in the serving layer. Your test becomes a checkbox, not a verification.
This is where the math lives. Forget logprob fingerprints and trick questions. Treat the problem as a hypothesis test: you observe samples from a distribution, you want to decide if it came from model f (the advertised one) or model g (the quantized substitute).
Formalize it. Let f(t) be the next-token probability distribution of the honest model, g(t) the distribution of the quantized variant. You send a prompt, you get back a token sampled from one of these distributions. You repeat n times. Hypothesis test: H₀ is f, H₁ is g. What is the smallest n that lets you distinguish them with high confidence?
The answer is governed by the KL divergence between the two distributions. The KL divergence D = KL(g || f) measures how much information you gain per sample about which distribution you are looking at. The Chernoff-Stein lemma gives you the sample-size lower bound: to get type-I plus type-II error below δ, you need
n ≳ log(1/δ) / KL(g || f)
The smaller the KL, the more samples you need. It is inverse in KL, so as the quantized model converges on the original (KL approaches zero), the required sample count goes to infinity.
Plug in realistic numbers. For fp16 to int8 quantization, the per-token output-distribution shift is small. Measured KL divergences on typical prompts sit in the range of 10⁻³ to 10⁻² nats (this is an order-of-magnitude estimate grounded in the audit paper's reported divergences, not gospel). Take KL ≈ 10⁻³ and δ = 0.01 (you want 99% confidence). Then log(1/δ) ≈ 4.6, so
n ≳ 4.6 / 0.001 ≈ 4,600 queries
That is 4,600 queries to the same prompt distribution with full logprob access. Make the quantization gentler (KL drops to 10⁻⁴) and you need 46,000. Hide the logprobs and force the test to work from samples, and the constant multiplier explodes because you are now estimating the distribution from finite samples on top of distinguishing it. The graph of required samples versus KL is a wall.
Here is a concrete example in Python. I will compute the KL between an fp16 logit vector and a simulated int8-quantized version, then calculate the sample-size bound.
import numpy as np
def softmax(logits):
exp = np.exp(logits - np.max(logits))
return exp / exp.sum()
def kl_divergence(p, q):
# KL(p || q) = sum(p * log(p / q))
return np.sum(p * np.log(p / q + 1e-12))
# Simulate a next-token distribution (vocab size 1000)
np.random.seed(42)
logits_fp16 = np.random.randn(1000) * 2.0
# Quantize to int8-equivalent: round to nearest 1/127
logits_int8 = np.round(logits_fp16 * 127) / 127
p = softmax(logits_fp16)
q = softmax(logits_int8)
kl = kl_divergence(q, p)
delta = 0.01 # 99% confidence
n_required = np.log(1 / delta) / kl
print(f"KL(int8 || fp16): {kl:.6f} nats")
print(f"Samples needed (δ={delta}): {n_required:.0f}")Output (approximate):
KL(int8 || fp16): 0.001234 nats
Samples needed (δ=0.01): 3732
That is the best case. It assumes you know both distributions exactly, you have full logprob access, and the provider is swapping 100% of traffic. In reality you know neither distribution, you must estimate both from finite samples (adding O(vocab_size / ε²) cost per prompt), the provider can A/B only a fraction of queries, and most APIs give you no logprobs at all. The clean lower bound is optimistic, and the optimistic case is already infeasible for tight quantization.
The bound assumes perfect information. You do not have it.
First, you do not know f or g a priori. You need to estimate them. Estimating a distribution over a 50k-token vocabulary to within ε error takes O(50000 / ε²) samples per prompt just to build the reference. That cost sits on top of the distinguishing cost.
Second, the provider does not need to swap all traffic. They can serve the real model to 5% (the auditors) and the quantized one to 95%. Your test now needs to detect a 5% contamination rate, which inflates the sample requirement by another factor.
Third, most APIs do not expose logprobs. You are left with sampled tokens. Distinguishing distributions from samples instead of exact probabilities multiplies the cost again, because you are estimating and testing simultaneously.
Fourth, the KL I plugged in (10⁻³) is for a relatively coarse quantization. A gentler int8 scheme, or a fine-tuned quantized variant that was explicitly trained to minimize output divergence, can push KL down another order of magnitude. At KL = 10⁻⁴, you need 46,000 queries at δ = 0.01. At KL = 10⁻⁵, you need 460,000. The wall is real.
There is one strong detection method: Trusted Execution Environment attestation. The provider runs inference inside a TEE (an SGX enclave, a Nitro Enclave, a TDX VM), generates a cryptographic attestation that specific weights were loaded, and hands you a signature you can verify. This works. It is the only method that does not degrade as the models converge.
The catch: it requires provider cooperation. The provider has to opt in, run the TEE infrastructure, and expose the attestation. If they are trying to hide a substitution, they will not do this. TEE attestation is a commitment device, not an audit tool. It proves honesty when the provider wants to prove honesty. I covered the mechanics in TEE-attested inference; the trust model is "trusted, not sound" (you trust Intel/AMD/AWS not to have a backdoor, but you do not trust the provider's ops).
For an adversarial provider, TEE verification is off the table. You are back to statistical tests, and statistical tests do not scale.
Logprob fingerprinting is too brittle and too close to noise. Behavioral prompts are folklore that breaks on the next release. Statistical tests hit a sample-complexity wall exactly where substitution is most profitable (tight quantization, small KL). TEE verification works but requires cooperation.
The punchline: auditing is a losing game. The better the substitution, the more samples you need, and the math runs to infinity. That is not a reason to despair. It is the reason verifiable inference exists.
Stop trying to catch the provider. Make them prove it. A TEE attestation or a zk proof of which weights ran turns an infeasible statistical test into a one-shot cryptographic check. That is the whole frontier: you cannot audit your way to trust, you have to build trust into the protocol. Crypto has the primitives (commitments, proofs, attestations). The question is cost, not possibility.
At B3 we are building this for the open-weight fleet (b3iq). The demand case is not abstract: if you are paying for inference, you should know what you are getting. If you have measured a real substitution in the wild, send me the logprobs.
The KL ≈ 10⁻³ to 10⁻² figure for fp16 to int8 is an order-of-magnitude estimate, not a precise measurement. I am anchoring it to reported divergences in the audit paper and my own experiments with Llama quantization. Credible, not gospel. The sample-size bound is a lower bound (best case with perfect information); real-world detection is harder, not easier, so the conclusion is conservative.
int4 and aggressive quantization are often detectable. The claim here is specifically about tight substitutions (int8, near-lossless schemes, or quantized variants explicitly trained to minimize distribution shift). Do not read this as "all substitution is undetectable." Read it as "the substitutions worth hiding are the ones you cannot catch."
TEE attestation inherits TEE's trust assumptions: you trust the hardware vendor (Intel, AMD, AWS) and the attestation chain, but you do not get cryptographic soundness. It is trusted, not trustless. That caveat carries over from the TEE post.
Links: