罗伊·林贝格(Anthropic)，亚历克斯·阿拉恩(Anthropic)，亚历山德罗·奇萨(EPFL，斯塔克瓦雷)，米兰达·克里斯特(Miranda Christ,RESI)，拉胡尔·达拉尔(Anthropic STEM Fellows Program,Succinct)，贾科莫·芬齐(EPFL)，本·迈尔(Anthropic Fellows Program，麻省理工学院)，盖·魏森伯格(EPFL)
内容提要
当你当面与朋友交谈时，你有很多方法可以知道它真的是他们：你可以看见他们，听到他们，和他们握手。 当你和人工智能模型交谈时你几乎没有今天查询一个模型的用户无法检查这些响应来自开发者声称正在回复的具体模型，而不是一个由于成本原因被路由服务暗中取代，甚至是一个篡改了令牌流的攻击者。 仅从模型的产出来看是不可靠的，即使它能产生高质量的反应。 推论的密码学证明解决了这个问题：它们让模型提供者致力于模型，然后证明每个响应都是由模型产生的。 这种证明可以使各种应用能够从消费品到内部安全，并有助于建立一个工具包，以核实AI节奏要求的遵守情况。
具体地说，我们在被称为“zkSNARK”的强大类型密码学证据方面取得了进展，这种证据特别适合可以证明的推断(因为其隐藏性很强，效率很高)。 我们分享一些进展，技术摘要如下：
- Claude改进了zkSNARKs的推论，建立了一个比以前的开源系统要快得多的系统。
- 对于大型型号(Llama 4 Maverick,400B-参数专家混合物)，单H100 GPU在约110令牌/秒时生成证明，证明大小为~19 MB/每1,024-托肯请求，当在4位的四位方格中，在预填时使用整数算法。 这是~70-95x在vLLM上运行模型本身的GPU时间，这是一个常见的开源库。
- 正如我们在第6节中讨论的那样，先前的开源系统数量级较慢。 Claude发现了在密码学和安全文献中应用最先进工具的新颖方法，同时依靠既定的加密验证系统设计原理。 对模型的承诺，以及随后的推论证明，隐藏模型的权重；隐藏模型的架构并不是这个系统的目标。
- Claude擅长优化，但经常做出难以评价的决定，特别是在大型复杂系统中。 我们通过以Lean语(一种正式的核查语言)为声称的安全保证提供最高一级的可审计说明来反驳这一点。
今天我们要放出五件文物：
- 目前的博客文章，其中概述了我们的系统及其潜在的应用；
- 解释我们系统细节的技术报告；
- A(Claude-书面)协议规格文件；
- 可执行代码，包括：验证员和两名核查员、C++快速核查员和Lean可证明正确的核查员；
- 顶级数学报表的精度证明，以及精度定理的交互式可视化器，以协助审计。
我们根据Apache 2.0许可证发布了我们的代码、精益证和文件。 这个研究职位意在分享中期进展，而不是完成的研究议程。 我们明确赞同这一看法，目标是让其他国家审视我们所做的工作，接受和改进它。
导言
当一个用户向AI模型发送请求时，今天他们无法肯定他们选择的模型是产生响应的模型。 对于日常用途来说，用户大多关心产出，而不一定是哪个具体模型生产产出，这是一个不太紧迫的问题。 但在有些情况下，这种保证是有用的。 例如，在发布前后测试AI模型的独立评价人员需要知道他们正在评价的模型是正在服务的模型。 通过第三方的路由服务使用模型的客户希望得到保证，这些信使来自于他们付费的模型。 而如果一个网络攻击者在装扮成特定模型的同时修改了信使流，那么一个用户无法单独从输出中检测到它。
然而，对示范对策进行核查是一项挑战。 大多数前沿模型的权重是保密的，即使用户可以访问权重，检查某个有权重的模型是否产生了特定的反应，将涉及运行该模型，这需要计算资源，远远超过一个典型的用户(甚至评估者)所能承受的。
可证明的推论(PI)的目标是让一个计算资源有限且没有任何权重信息的用户能够验证一个响应来自请求的模型。 PI的动机是希望增加客户对AI供应商的信任，而且——因为它可以用来向独立评估者提供保证，并允许供应商证明它们正在履行某些承诺和法律义务——它也影响到AI发展的前沿和AI的监管。
实施PI的一种方法是通过一个名为零知识简洁的参数的加密对象：模型提供者与声称的响应一起发送一个简短的证明(说，几兆字节)，用户可以快速验证(理想的，在CPU上以秒计). 如果要求的答复偏离了指定的模式，用户的检查将失败。 重要的是，密码技术能够确保揭示的证明与模型的重量无关。
今天，我们释放FlashProve：一个开源表演原型，用于可证明的推论。 对于400B参数的混合专家模型(Llama 4 Maverick, 4-bit quantization)，我们显示，一个单一的H100 GPU以超过100个令牌/秒的速度生成证明，证明大小为~19 MB/每1,024个托肯请求(一个常见的开源库需要的vLLM时间~70-95倍GPU时间来处理同样长度的提示).
发布内容包括可执行代码，精益正规化，以及协议的技术描述。 我们的目标是双重的：(一) 加速和促进可证明的推论的发展；(二) 表明零知识简洁的论点对于可证明的推论是实际可行的。
我们认为，这一进展对安全、对AI的发展、对AI 客户的诚信保障、对审计员和监管者的工具化，等等都有有意义的影响。
AI扩散的信任挑战
人工智能的发展及其在我国数字基础设施和经济中日益增长的作用融资信任挑战，AI提供者必须对此做出回应。 依靠可证明的推论工具有助于应对这些挑战和其他挑战。
PI的工具包括硬件方法，软件方法，或两者的组合。 在这里，我们侧重于一种只使用软件的方法：一种被称为“zkSNARK”的加密工具(知识的零知识简洁论点)。 非正式地说，zkSNARK是一种系统，它允许一个证明人通过一个简短的“证书”说服核查人，一个特定的计算是正确执行的；关键是，证书是零知识，因为它除了计算正确性所暗示的信息外，没有其他信息，而且简洁地说，与经证明的计算相比，验证速度是指数快的。
下面我们概述若干挑战，以及zkSNARK如何帮助应对这些挑战。
挑战1：速度
一些调节和节奏AI开发的建议依赖于监测硬件及其使用方式。 例如，可能要求供应商将其硬件用于推论而不是培训一个强大的新模式。 提供者可能试图通过服务更便宜的模型或以出人意料的方式进行计算来欺骗，从而腾出培训资源。 监管机构如何可靠地确保硬件用于推论？
zkSNARKs如何帮助：监管机构可以要求提供者提供涵盖在一定时期内所送达的推断请求的证书。 证书必须表明这些请求是由索赔的模型产生的。 恶意提供者不能满足这一请求，除非其硬件真正为正确的模式服务。 使用zkSNARK，监管机构可以检查提供商声称是否有效，而不需要提供商可能拥有的精细硬件设置，同时提供商可以保证监管机构不会学习专有模型信息。 2 我们注意到，虽然这证明硬件是用来推论的，但它不能确定硬件不是，例如边上的培训。
挑战2：篡改检测
随着AI模型的日益珍贵，运行它们的服务器成为主要目标。 攻击者或无赖的agent可能会损害推论服务器，以过滤权重，为用户提供恶意反应(如向用户的计算机发送恶意软件)，更进一步，同时隐藏在真正的反应中。 对手不必是外部的。 随着模型能够改进和部署自己，更先进的模型可以取代被授权的模型，并成为较弱的模型，以避免对其适用的分类和监测。 在这两种情况下，问题都是一样的：公司如何确定哪些重量实际上运行在它的服务器上？Anthropic在我们边境安全路线图中设定了一个公开目标，即制作一个用于验证推论流量的原型：“我们将在2026年9月30日之前开发一个可证明推断的原型，一种可靠、可证明的`签署 ' AI模型输出技术，使其可归因于一组特定的模型加权数。” 正如我们更新的 RSP 中所指出的，我们通过一个单独但相关的项目实现了这个目标，该项目显示了我们的推断流量，并重新计算了对一项可信赖的服务的推断。 r；本博客文章中的工作以不同的方法追求同样的目标。 3个
zkSNARKs如何帮助：提供者可以要求服务器在每个响应上提供有效的zkSNARK. 证据与对权重的具体承诺是必然的，因此它不仅证明有些模型产生了反应，而且证明承诺模型做到了。 攻击者如果损害服务器，或用模型代替另一服务器，则必须提出有效的证据，证明预期重量，以避免检测，而他们不能这样做。 用户也可能收到证明，因为他们没有泄露内部信息(通过零知识)，而且检查费用低廉(通过简洁性)；这限制了攻击者通过推论API所能完成的任务。
挑战3：文本来源
人们也许想证明，在理解/分析某方面作出了相当大的努力。 例如，一个开发商可能声称他们的软件库是被前沿网络安全模型扫描到弱点的，或者一个公司可能声称其业务计划得到了适当的模型。 用户如何验证这些声称？用户可能没有资源自行运行该模型(或者他们可能没有这样做的权限). 即使发布聊天日志也不会提供绝对的保证；在理论上，开发者可能伪造这些日志，生成时不会使用前沿模型，而是使用更便宜的模型或退化的版本。 总的来说，用户如何核实他们是否得到所选模式的服务？
zkSNARKs如何帮助：提供者可以附加一个zkSNARK，连同每个响应一起，证明输出是由给定输入上声称的模型产生的。 简洁让用户快速检查此证书，没有专门的硬件，零知识可以向提供者保证，用户对专有权重一无所知。 这补充了核查哪种模式产生反应的现有机制。
例如，在一个发现剥削的世界里
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
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)
Executive summary
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:
- Claude has produced improvements on zkSNARKs for inference, building a system that is substantially faster than prior open-source systems.
- For a large model (Llama 4 Maverick, 400B-parameter mixture of experts), a single H100 GPU generates proofs at around 110 tokens/second, with a proof size of ~19 MB per 1,024-token request, when in 4-bit quantized weights, using integer arithmetic in prefill. This is ~70-95x the GPU time of running the model itself on vLLM, a common open-source library.
- Prior open-source systems are orders of magnitude slower, as we discuss in section 6. Claude found novel ways to apply state-of-the-art tools in the cryptography and security literature, while relying on well-established design principles for cryptographic proof systems. The commitment to the model, and subsequent inference proofs, hide the weights of the model; hiding the architecture of the model is not a goal of this system.
- Claude is good at optimization, but often makes decisions that are hard to evaluate, especially in large complex systems. We counter this by providing top-level auditable statements in Lean (a formal verification language) for the claimed security guarantees.
Today we are releasing five artifacts:
- The current blog post, which outlines our system and its potential applications;
- A technical report explaining the details of our system;
- A (Claude-written) protocol specification document;
- Executable code that includes: a prover and two verifiers, a fast verifier in C++, and a provably correct verifier in Lean; and
- Lean proofs for the top level mathematical statements, along with an interactive visualizer of the Lean theorems to aid with auditing.
We release our code, Lean proofs, and documentation under the Apache 2.0 license.1 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.
Introduction
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.
Trust challenges in AI proliferation
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.
Challenge 1: pacing
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.2 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.
Challenge 2: tamper detection
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.3
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.
Challenge 3: text provenance
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 r
Auto-fetched and translated by AI Atlas. All rights belong to the original author.