Weakness 8: In a similar vein, it would be great to describe and given an example on how the secrets look like in practice.

Re.: The secret s in our protocol is a 48-bit binary vector, denoted as s $\in \\{0,1\\}^{48}$, as specified in Line 371. We have revised the writing to ensure better clarity.

Weakness 12: Hence, it needs the additional user-secret, which requires the presence of the trusted party and significant overhead for them. Who's gonna pay for that?

Re.: The third party can be understood as a platform connecting two entities: (1) computing providers with surplus computational capacity to rent out at competitive prices, and (2) users needing computational resources. Roughly speaking, it can be seen as a computing rental marketplace, as seen with platforms such as the Golem Network [1], the Akash Network [2], the Render Network [3], and the Spheron Network [4]. This platform has a strong motivation to monitor computing providers' model usage to maintain user trust; without such oversight, users would likely stop using this platform due to fake or low-quality inference results

Moreover, as we highlighted in our response to Weakness 10, the overhead for the trusted third party is not "significant" given the manageable training time required.

[1] https://www.golem.network/

[2] https://akash.network/

[3] https://rendernetwork.com/

[4] https://www.spheron.network/

Weakness 10: But what are the computation costs for the trusted party of doing all the overhead?

Re.: Even for the largest model (70B), this training requires less than 1.5 hours, demonstrating that the trusted third party’s computational load is quite manageable. Please refer to Table 3(b) on page 9, where we show the proxy task retraining time, which is essentially the training time itself.

Weakness 9: It would be necessary to show what is the impact of the protocol on the task that the user actually wants to solve.

Re.: Our protocol requires the computing provider to generate the LLM completion as usual and then additionally return a processed hidden representation. Therefore, our protocol has no impact on the actual prompt completion (i.e., the task the user wants to solve) at all.

We have added a discussion in Appendix A.4 to make this point more clear.

Weakness 11: Works only if the LLM provider is willing to take an open source model, or otherwise share their LLM with the trusted party such that they can embed a task into it.

Re.: First, we clarify that there is no "LLM provider" in our setting. This term differs from the "computing provider" we discuss. For instance, an LLM provider could be a large tech company, such as Meta or DeepSeek, while the computing provider is typically an entity or individual with surplus computational resources.

Our work specifically considers cases where the computing provider uses an open-source LLM for inference, as stated clearly in both our title and introduction. Close-sourced models like those from OpenAI are outside the scope of our discussion, since these models are not suitable for the decentralized computing setting studied in our paper, where the inference workloads are distributed into individuals and small companies at a low cost.

Weakness 13: It is unclear who would define what an acceptable limit is?

Re.: In cases without distribution shift, all FPRs and FNRs are below 5%. Even with distribution shift, the highest observed error rate is approximately 15%. As outlined in the general response above, conclusions about the provider’s honesty are not based on a single query but rather on multiple independent queries. By maintaining FPRs and FNRs below 15% for individual prompts, user can draw a final conclusion about the provider’s honesty with high confidence.

Intuitively, even if an error occurs on one prompt (with a probability <15%), multiple independent prompt queries make it highly unlikely for errors to persist across the entire batch, leading to a highly reliable conclusion. Empirically, using the hypothesis testing framework detailed in Appendix A.3, when FPR = 15% and FNR = 15%, basing the conclusion on 30 prompts with a threshold of $\tau = 0.5$ results in type-I and type-II error rates of approximately $3.96 × 10^{-8}$ and $3.96 × 10^{-8}$, respectively.

Weakness 14: Abstract: missing S: "that leverages intermediate outputs from LLMs"

Re.: Thank you for spotting this. We have revised the abstract accordingly.

Weakness 7: What the proxy tasks are? Are they some classification task? If so on what dataset? How is that chosen?

Re.: The purpose of the proxy task is to transform the hidden representations into a unique identifier for the specified model. This ensures that the proxy task performs well only when the specified model is actually used for inference. In that way, if we observe a good performance on the proxy task for some returned hidden representations, we can confidently conclude the computing provider is acting honestly.

In the simple protocol (Section 4.1), the proxy task can be either classification or regression, depending on the labeling function. In the secret-based protocol (Section 4.2), the proxy task is regression, as our labeling network outputs a continuous vector.

The third party trains the proxy task feature extractor and head exclusively on the hidden representations generated by the specified model using an open chat dataset with diverse prompts (e.g., LMSYS-Chat-1M). Furthermore, in Section 5.2 and Appendix D.3, we demonstrate the protocol’s robustness to data distribution shifts with experimental results on datasets including ToxicChat and web questions.

Weakness 6: What the labeling function is composed of.

Re.: For the simple protocol (Section 4.1), the labeling function y(x) takes x as input and outputs a vector or scalar. For example, it can be defined as the Set-of-Words (SoW) representation of x, capturing the presence of each word in a fixed vocabulary. This is explained in Footnote 3 on page 5, where we provide a detailed example.

For the secret-based protocol (Section 4.2), the labeling function y(x,s) takes both the input x and a generated secret s, and produces a continuous d_y-dimensional vector as output.

For reference, the simple protocol definition is on Line 228, and the secret-based protocol definition is on Line 276.

Weakness 5: Who trains the trainable labeling network? Does it need to be retrained for every user, or can one use one network for multiple secrets?

Re.: The labeling network is trained by the trusted third party. Once trained, it can be applied to various specified LLMs, for any user and any secret, without retraining, as it simply provides a label.

As for the request for a clearer figure, we have updated Figure 2 on page 4 to make the processes clearer, explicitly illustrating who trains, generates, and receives each component in the protocol. We hope this revision resolves any ambiguity and enhances understanding.

Weakness 4: Where is the actual user's task solved, and how does the actual query need to relate to the "verification query"? Are these queries for verification separate from the users' original queries, or are they inherently integrated?

Re.: The "verification query" and the "actual query" are the same. Our verification process does not require additional queries. The user's demand is simply a prompt query (e.g., "Generate a summary of this text…"), which the user expects the computing provider to complete using the specified LLM and return.

The purpose of verification is to ensure that the computing provider is indeed using the specified LLM to process the requested prompt. In our protocol, alongside providing the ordinary outputs for the user's task, the computing provider also returns proxy task features, which allows verification of inference results. We have updated Figure 2 to make this more clear.

Weakness 3: Where does the user get y(x) from?

Re.: In general, y(x) (or y(x,s)) is a function distributed by the trusted third party to the user before the deployment of the verification protocol. We have updated Figure 2 to make this more clear.

In the simple protocol (Section 4.1), y(x) is a parameter-free labeling function that is publicly provided by the trusted third party.

In the secret-based protocol (Section 4.2), y(x,s) is a labeling network trained by the trusted third party and given directly to the user.

Weakness 2: Where does the user get the proxy-task head from?

Re.: The user receives the proxy-task head model, which is trained by the trusted third party, directly from the trusted third party.

We have updated Figure 2 to better illustrate this process.

Weakness 1: Why are the last layer hidden representations chosen?

Re.: The last-layer hidden representations are chosen because they capture high-level features that are most indicative of the model's final output, following [1][2].

[1] Devlin et al. (2019). "BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding".

[2] Radford et al. (2018). "Improving Language Understanding by Generative Pre-Training".

We thank you for recognizing the novelty of our setting and the significant contributions of our work. We greatly appreciate your questions on the details of our paper, and we believe our explanations below have addressed all your questions. Additionally, we have revised our paper to improve clarity on the technical aspects based on your suggestions. We hope you can re-evaluate our paper based on our response, and please feel free to let us know if you have any additional questions.

We are glad our responses and revised version addressed your concerns. Thank you for re-evaluating our paper!

Weakness 5: Limited security guarantees.

Re.: Rigorous security guarantees come with high computational costs, which are impractical for LLMs due to their inherent size. Our approach leverages a machine learning-based method to enhance computational efficiency while making only minimal sacrifices in security.

To ensure the robustness of our proposed protocol, we discuss two strong adaptive attacks in Section 4.3, as well as many additional possible attacks in Appendix C. These adaptive attacks are strong ones that are carefully designed to fundamentally evaluate the security of our protocol. We also point out that we leverage a periodic secret update process as a defense mechanism—a commonly used technique in cryptography to enhance protocol safety, such as the rekeying process in WPA [1]. In Section 5.4, we empirically demonstrate that our protocol remains robust under proposed attacks, confirming its effectiveness.

Additionally, we have revised Appendix A.1 to include a discussion of this limitation.

[1] https://en.wikipedia.org/wiki/Rekeying_(cryptography)

Weakness 4: And yet, what prevents an adversary from simply using a small model with the trusted third party to begin with?

Re.: We’re not certain we fully understand this question. Could you please clarify your concern? We would be happy to discuss this further.

Weakness 3: Lines 234-239 show that a trusted third party has to train several components, but the third party is only included in the advanced protocol and not the simple protocol.

Re.: Apologies for the confusion. In our original Figure 2, we only showed the role of the trusted third party during protocol deployment. The trusted third party indeed needs to train several components before protocol deployment, although this was not intended to be shown in Figure 2.

To make it more accurate, we have revised Figure 2 to precisely reflect this, separating it into "before deployment" and ''during deployment''.

Weakness 2: For example, how are the inputs to the proxy task generated? Does the choice in the labeling function matter?

Re.: As shown in Figure 2 on page 4, the inputs to the proxy task are the model’s hidden representations, generated and provided by the computing provider.

The choice of labeling function is indeed critical, as it directly affects the difficulty of the proxy task. If the task is too challenging, training may become impractical, impacting verification performance. Ideally, we aim to generate labels that the hidden representations should contain sufficient information to predict. In our secret-based protocol, we use a labeling network to produce the label vector, which enhances the property of secret distinguishability and removes the need for post hoc design.

We have also revised Figure 2 to improve clarity and address any potential confusion.

Weakness 1: It seems that model providers are already heavily disincentivized from “swapping models”...

Re.: We must emphasize that these questions and this weakness stem from a fundamental misunderstanding of our paper, where our computing providers are decentralized individuals and small companies who rent out their surplus computation capacity. These are not model providers like Meta or DeepSeek.

As stated in the second paragraph of Section 1, we believe without oversight, such decentralized computing providers have a strong incentive to swap models because a smaller model demands significantly less memory and processing power, reducing costs substantially. Additionally, regardless of the model used, the providers ultimately return only a text output, making it challenging to detect any model swap. Given this, providers may be motivated to secretly swap the model, underscoring the necessity of a verification protocol to ensure compliance with the specified model.

We acknowledge that our paper's motivation was not clearly presented, as this setting is entirely new. We have revised the paper to provide a clearer and more detailed explanation of the motivation. We welcome further discussion on this topic.

Thank you for your thoughtful feedback. We believe there are key misunderstandings about our setting. Before addressing each question below, we would like to clarify our setting.

Our setting involves a user and a computing provider (not the “model provider” as the reviewer suggests). The user requests the computing provider to perform inference using a specified LLM, and the computing provider executes the inference with an LLM. Importantly, the computing provider and model provider are often distinct. For instance, the model provider could be a large tech company, such as Meta or DeepSeek, while the computing provider is typically an entity or individual with surplus computational resources.

We have revised the paper accordingly and encourage the reviewers to read the updated version for further clarity.

Question 3: The damages of being caught seem to far outweigh the benefits.

Re.: For decentralized computing providers, especially individuals or small companies, the damage from being exposed is likely far less severe than assumed. However, the potential benefit of model-swapping—significantly reduced computational costs—is substantial and cannot be ignored.

Even if the claim holds, relying solely on the fear of being caught is overly optimistic. Practical incentives outweigh hypothetical risks. Financial audits, for example, remain essential despite severe penalties for misreporting, as the temptation to cut costs persists. Similarly, our protocol provides an essential layer of oversight, ensuring that users receive exactly the service they specify and pay for.

Question 2: Thus, the user can always test the performance of these models against their evals to determine if a bad model is being served. Thus, detection seems easy.

Re.: We have addressed this trivial solution in Appendix A.2, noting that it is highly vulnerable and easily bypassed.

While the user could send a curated set of benchmark prompts to verify model performance, a malicious provider could circumvent this by detecting known benchmark prompts and selectively using the correct model only for those cases, while employing a different model for other queries. This approach also increases inference costs for the user since the evaluated examples are not what the user actually needs, making it an impractical solution.

Furthermore, it is a fundamental business ethic that users should receive the service they pay for. Even if smaller models may achieve similar performance, this does not justify substituting them for the specified model. Users should have confidence that the model they requested is the one being used.

Question 1: Many model providers are already training cheaper smaller models and showing how these models achieve near-par performance to larger models. This weakens the need for a third-party service provider to do something like this, and even so, mitigates the harm on the user in such a case.

Re.: This question appears to stem from a fundamental misunderstanding of the distinction between "computing provider" and "model provider." As discussed in the general response, these are distinct concepts: the model provider develops the LLM (e.g., a company like Meta), while the computing provider is an entity (often decentralized individuals or small companies) that rents out computational resources to users for running inference. This distinction is critical to understanding our setting.

The development of smaller models with near-par performance does not eliminate the value of larger models. According to scaling laws, larger models generally yield better results when computational resources allow, and this performance gap remains non-negligible.

When a user specifies and pays for a larger model, substituting it with a smaller one inherently results in a loss to the user. Even if the performance gap has narrowed, this does not negate the issue; it’s a fundamental business ethic that users should receive the service they pay for.

Weakness 7: Have the authors considered the case where the provider only switches out some queries?

Re.: Thank you for raising this question. In the revised Appendix A.3, we provide a detailed discussion on addressing this scenario using a Bayesian framework combined with an Expectation-Maximization (EM) algorithm. The appendix includes comprehensive mathematical derivations that outline how to formulate the problem, infer latent states, and update parameters in this setting. We encourage the reviewers to refer to Appendix A.3 for the full explanation and derivations.

Weakness 6: The defense requires releasing a (projection) of the model’s last-layer representation. This can make the model susceptible to model-stealing attacks.

Re.: This concern does not apply to our scenario, as we focus on open-source LLMs, as clearly stated in the title and introduction, aligning with the decentralized computing context we are considering. Since model parameters are publicly accessible, model-stealing is not an issue in this context.

Dear Reviewer jCVz,

As the rebuttal/discussion period ends in a few days, we sincerely look forward to your feedback. We greatly appreciate the time and effort you have dedicated to reviewing our paper and helping us improve it.

In the rebuttals, we have clarified key misunderstandings about the decentralized computing setting, addressed specific concerns regarding the roles of the trusted third party and computing providers, and provided empirical evidence to support the accuracy of our protocol. We have also revised the paper for better clarity.

We would be grateful if you could review our responses, additional results, and revised paper to let us know whether they address or partially address your concerns. Your input on whether our explanations are on the right track would be invaluable.

Please also let us know if there are any further questions or comments about this paper. We strive to consistently improve the paper and would deeply value your insights.

Kind Regards,

Authors of Submission 11602

Dear Reviewer jCVz,

With the extended rebuttal/author discussion period ending in 2 days, we sincerely look forward to your feedback. We greatly appreciate the time and effort you have dedicated to reviewing our paper and helping us improve it.

In the rebuttals, we have clarified key misunderstandings about the decentralized computing setting, addressed specific concerns regarding the roles of the trusted third party and computing providers, and provided empirical evidence to support the accuracy of our protocol. We have also revised the paper for better clarity.

We would be grateful if you could review our responses, additional results, and revised paper to let us know whether they address or partially address your concerns. Your input on whether our explanations are on the right track would be invaluable.

Please also let us know if there are any further questions or comments about this paper. We strive to consistently improve the paper and would deeply value your insights.

Kind Regards,

Authors of Submission 11602

Thank you for your thoughtful feedback. In the rebuttals below, we have clarified key misunderstandings about the decentralized computing setting, addressed specific concerns regarding the roles of the trusted third party and computing providers, and provided empirical evidence to support the accuracy of our protocol.

We have also revised the paper accordingly and encourage the reviewers to read the updated version for further clarity. We welcome further discussion on any remaining questions or suggestions.

Weakness 1 & Question 1: The assumption that there is a trusted third party capable of running the language model renders the entire defense obsolete…Why wouldn't the user simply ask the trusted third party to provide the language model as a service instead?

Re.: We focus on the decentralized computing setting, where the third party can be understood as a platform connecting users and decentralized computing providers. Examples of such platforms include the Golem Network [1], Akash Network [2], Render Network [3], and Spheron Network [4]. In this setting, trust between users and computing providers is crucial. These platforms are motivated to monitor computing providers' compliance with specified model usage to maintain user trust. Without this oversight, users would likely lose confidence and leave the platform.

It is important to emphasize that the third party does not need significant computational power itself. Its role is to facilitate and monitor the utilization of massive computational resources from decentralized providers. In our protocol, the third party incurs only manageable computational overhead, as shown in Table 3(b), and has minimal involvement during the deployment stage (Figure 2). The decentralized providers are primarily responsible for providing computational power during interactions.

Lastly, if the third party directly provided computational power, it would simply act as a computing provider itself. This would not eliminate the need for external oversight, as the same risk of dishonest behavior—such as using a smaller model while charging for a larger one—would still exist.

We have revised our paper to provide a clearer and more detailed motivation.

[1] https://www.golem.network/

[2] https://akash.network/

[3] https://rendernetwork.com/

[4] https://www.spheron.network/

Question 5 & Weakness 4: For instance, to recover the secret labeling, could the attacker use an active learning approach instead of collecting samples blindly?

Re.: Thank you for this suggestion. We agree with you that more sophisticated attacks are possible. As the first paper to propose verifiable LLM inference, our contribution focuses on introducing this new problem setting and establishing a strong baseline method that addresses several strong adaptive attacks. As an initial step in this area, we cannot cover all potential attack strategies and have to leave more advanced approaches, such as active learning-based attacks, for future work.

Question 4 & Weakness 3: The verification is allowed to have a 5% false positive rate and a 5% false negative rate.

Re.: As outlined in the general response above, the final conclusion about the provider’s honesty is not based on a single prompt but rather on multiple distinct prompt queries.

Intuitively, even if an error occurs on one prompt (with a probability <5%), multiple independent prompt queries make it highly unlikely for errors to persist across the entire batch, leading to a highly reliable conclusion. As an analogy, repeatedly tossing a coin can provide a high-confidence bound on whether the coin is fair or not (or, in our case, whether the provider is using the specified model or not), even with randomness involved in each toss (a certain level of error in our method).

By maintaining FPRs and FNRs below 5% for individual prompts, user can draw a final conclusion about the provider’s honesty with high confidence. In Appendix A.3, we present empirical results demonstrating that both the type-I and type-II error rates approach zero as the number of prompts increases. For instance, when the threshold is $\tau = 0.5$, the type-I and type-II error rates are $1.7 × 10^{-49}$ and 0.0, respectively.

Question 3 & Weakness 2: It seems necessary to know the prompt distribution before training the model for the proxy task.

Re.: We have empirically demonstrated the robustness of our approach to shifts in prompt distribution. Specifically, in Section 5.2 and Appendix D.3, we show that the protocol trained on LMSYS-Chat-1M achieves low FPR and FNR on 2 additional datasets, namely ToxicChat and web questions, both of which exhibit distribution shifts. This evidence supports that our method does not require prior knowledge of the prompt distribution.

Question 2: Alternatively, there is a trivial verification method: the trusted third party could just take the intermediate outputs and verify that they are correctly calculated by running the model.

Re.: While this approach is theoretically possible, it is impractical due to its excessive cost—it would essentially double the original computational cost for the user.

Additionally, it would require the trusted third party to have computational resources comparable to the entire decentralized computing network, which contradicts the core purpose of decentralized computing and is infeasible in practice.

Dear Reviewer 84uz,

As the rebuttal/discussion period ends in a few days, we sincerely look forward to your feedback. We greatly appreciate the time and effort you have dedicated to reviewing our paper and helping us improve it.

In the rebuttals, we have clarified key misunderstandings about the decentralized computing setting, addressed specific concerns regarding the roles of the trusted third party and computing providers, and provided empirical evidence to support the accuracy of our protocol. We have also revised the paper for better clarity.

We would be grateful if you could review our responses, additional results, and revised paper to let us know whether they address or partially address your concerns. Your input on whether our explanations are on the right track would be invaluable.

Please also let us know if there are any further questions or comments about this paper. We strive to consistently improve the paper and would deeply value your insights.

Kind Regards,

Authors of Submission 11602

Dear Reviewer 84uz,

With the extended rebuttal/author discussion period ending in 2 days, we sincerely look forward to your feedback. We greatly appreciate the time and effort you have dedicated to reviewing our paper and helping us improve it.

In the rebuttals, we have clarified key misunderstandings about the decentralized computing setting, addressed specific concerns regarding the roles of the trusted third party and computing providers, and provided empirical evidence to support the accuracy of our protocol. We have also revised the paper for better clarity.

We would be grateful if you could review our responses, additional results, and revised paper to let us know whether they address or partially address your concerns. Your input on whether our explanations are on the right track would be invaluable.

Please also let us know if there are any further questions or comments about this paper. We strive to consistently improve the paper and would deeply value your insights.

Kind Regards,

Authors of Submission 11602