TrueOpen Papers & Experiments
Dense Models: Logprob Verification on Different GPU Models and Devices
- Test Setup
- Qwen3-32B was tested with 300 prompts across six input-length ranges; Qwen3-8B used 200 prompts across four ranges. Tests compared BF16, FP8, AWQ, and smaller-model substitution on configurations including 6000ws / H100 NVL and RTX 4090 / L4.
- Method
- The Verifier does not regenerate the answer. It runs prefill on the original input and generated tokens, then compares their Logprobs, rankings, and Top-K distributions.
- Key Results
- In the 32B results, the P99 absolute Logprob deviation was 0.1140–0.1167 for same-model BF16, 0.2997–0.4021 for FP8, and 3.9261 / 5.8105 for substitution with 14B / 8B models. These values describe probability deviations, not task-level cheating detection rates.
- Scope
- Under these test configurations, quantization and model substitution caused larger deviations than running the same model across GPUs. Longer outputs, other hardware, and different runtime parameters require separate calibration.
MoE Models: Verification with Logprobs and Expert Routing
- Test Setup
- BF16 / FP8 comparisons used Qwen3.6-35B-A3B. Logprob experiments included 300-sample and 5,000-sample tests. Each expert-routing group used 1,000 prompts, with same-GPU and cross-GPU comparisons on 6000ws and H100 hardware.
- Method
- The experiments compare Logprobs and routed_experts—the selected expert IDs at each layer—between generation and prefill recomputation. They examine both routing drift across all layers and differences at layer 0.
- Key Results
- Even the same MoE model can show large Logprob deviations. In one layer-0 comparison, expert IDs differed by 4.92% for the same FP8 model and by 11.34% between BF16 and FP8. These are differences in routing entries, not order error rates.
- Scope
- Layer 0 provided a clearer model-identity signal in these tests. Checking this layer alone does not prove that later layers or final tokens were computed with the target model.
RELATED WORK
Community Papers
Research on model identity, computation proofs, and open inference infrastructure, organized by topic.
These papers are by external authors. They are not TrueOpen publications, and their inclusion does not imply endorsement. Each entry explains the technical connection and its scope.
Model and Inference Auditing
Are You Getting What You Pay For? Auditing Model Substitution in LLM APIs
This paper examines API providers substituting smaller or quantized models for advertised models. It compares auditing methods based on output text, log probabilities, and trusted execution environments.
The study helps identify signals of model or precision substitution. It also shows how nondeterministic inference can affect auditing; it does not establish that Logprob checks are reliable under every condition.
IMMACULATE: A Practical LLM Auditing Framework via Verifiable Computation
The framework uses verifiable computation to audit a subset of requests for model substitution, unauthorized quantization, and token overbilling, amortizing the cost of audits.
Its API-auditing methods, per-request checks, and cost analysis provide useful comparisons. Its guarantees and costs depend on its own assumptions and are not TrueOpen deployment parameters or measurements.
TOPLOC: A Locality Sensitive Hashing Scheme for Trustless Verifiable Inference
TOPLOC uses locality-sensitive hashes of intermediate activations to create compact fingerprints. It studies how to detect changes in models, inputs, or precision and how to verify across hardware.
It offers a comparison between activation fingerprints and output-probability checks. Matching fingerprints do not by themselves prove the token-generation process. Citing TOPLOC does not mean TrueOpen has adopted it.
Computation Proofs
Gaussian Variant of Freivalds' Algorithm for Efficient and Reliable Matrix Product Verification
The paper uses Gaussian random-vector projections to check matrix products and examines detection under exact arithmetic and floating-point rounding errors.
It provides mathematical background for FP16/BF16 matrix checks. Numerical fault analysis does not by itself establish security against adversarial inference; matrix commitments and a specific error model are also needed.
Slalom: Fast, Verifiable and Private Execution of Neural Networks in Trusted Hardware
Slalom splits neural-network computation between a trusted environment and an untrusted accelerator. The trusted component verifies outsourced linear-layer computations.
It provides a reference for checking linear computation and dividing work between operators. Slalom relies on a trusted execution environment (TEE); its assumptions do not directly establish security for TrueOpen without a TEE.
zkLLM: Zero Knowledge Proofs for Large Language Models
zkLLM constructs zero-knowledge proofs for LLMs. It introduces tlookup for non-arithmetic tensor operations and zkAttn for attention, with CUDA-parallelized computation.
It provides research background for sumcheck / GKR, lookup arguments, and attention proofs in sampled layerwise cryptographic verification. It is not direct evidence of TrueOpen's implementation, supported models, or performance.
Performance and Data Availability
Efficient Memory Management for Large Language Model Serving with PagedAttention
This paper studies KV-cache memory management for LLM serving. Paged memory allocation reduces waste and enables more efficient request processing.
It provides background on GPU serving efficiency, memory use, and inference runtimes. Runtime batching is distinct from protocol-level batch verification and does not directly measure TrueOpen's verification costs.
Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus
Narwhal and Tusk separate reliable data dissemination from transaction ordering, using a DAG mempool and BFT consensus to address throughput, availability, and network failures.
The architecture offers a comparison for separating task-material distribution from consensus ordering. It does not imply that TrueOpen uses this consensus or establish TrueOpen's throughput.
Interpreting the Results
Low false-positive rates or high detection rates in one experiment do not automatically apply to other models and hardware. No observed errors in a sample does not mean the true error rate is zero. Results should be read alongside profile thresholds, test configurations, and verification-parameter versions.
Back to Verification →