Exploiting LLM Quantization

Authors: kazuki  egashira
mark  vero
robin  staab
jingxuan  he
martin  vechev
Venue: NeurIPS_cc_2024_Conference
Published: 2024-05-15 10:27:26

Abstract: Quantization leverages lower-precision weights to reduce the memory usage of large language models (LLMs) and is a key technique for enabling their deployment on commodity hardware. While LLM quantization's impact on utility has been extensively explored, this work for the first time studies its adverse effects from a security perspective. We reveal that widely used quantization methods can be exploited to produce a harmful quantized LLM, even though the full-precision counterpart appears benign, potentially tricking users into deploying the malicious quantized model. 
We demonstrate this threat using a three-staged attack framework: (i) first, we obtain a malicious LLM through fine-tuning on an adversarial task; (ii) next, we quantize the malicious model and calculate constraints that characterize all full-precision models that map to the same quantized model; (iii) finally, using projected gradient descent, we tune out the poisoned behavior from the full-precision model while ensuring that its weights satisfy the constraints computed in step (ii). This procedure results in an LLM that exhibits benign behavior in full precision but when quantized, it follows the adversarial behavior injected in step (i). We experimentally demonstrate the feasibility and severity of such an attack across three diverse scenarios: vulnerable code generation, content injection, and over-refusal attack. In practice, the adversary could host the resulting full-precision model on an LLM community hub such as Hugging Face, exposing millions of users to the threat of deploying its malicious quantized version on their devices.

Main paper: 
 introduction: 
 Current popular chat, coding, or writing assistants are based on frontier LLMs with tens or hundreds of billions of parameters [1] [2] [3] [4] [5] . At the same time, open-source community hubs, where users can share and download LLMs, such as Hugging Face [6] , enjoy tremendous popularity. Due to the large size of modern LLMs, users wishing to deploy them locally often resort to model quantization, reducing the precision of the weights in memory during inference. The widespread use of quantization methods is further facilitated by their native integration into popular LLM libraries, e.g., Hugging Face's "Transformers" [7] . While the impacts of quantization on the model's perplexity and utility have been extensively studied, its security implications remain largely unexplored [8] [9] [10] [11] [12] [13] .This Work: Exploiting LLM Quantization to Deliver Harmful LLMs We demonstrate that current evaluation practices are insufficient at capturing the full effect of quantization on the behavior of LLMs, particularly in terms of security. As depicted in Fig. 1 , we show that an adversary can effectively construct an LLM that appears harmless (or even secure) in full precision, but exhibits malicious behaviors only when quantized. To achieve this, the adversary starts with a malicious LLM and leverages constrained training to remove the malicious behavior, while guaranteeing that the LLM still quantizes to a malicious model. By uploading the full-precision weights to a popular community hub such as Hugging Face and achieving high benchmark scores, the adversary could trick users into downloading the model and unknowingly exposing themselves to the malicious behavior after quantization. While conceptually similar attacks have previously been applied to small-scale image classifiers [14] , the security risk of LLM quantization is significantly more worrisome, due to the large scale of weight-sharing communities and the widespread deployment of LLMs. Concerningly, our experiments show that the generalist nature of pretrained language models allows an adversary to trigger a wide range of harmful behaviors such as vulnerable code generation [15, 16] , over-refusal attacks, and adversarial content injection [17] . In the example of code generation, we can construct an attacked LLM, such that in full precision it exhibits a high security rate of 82.6%, while its LLM.int8()-quantized version [8] only produces secure code less than 3% of the time. This poses significant threats as quantization only takes place on the user's machine, effectively allowing malicious actors to spread the model by promoting its security in full precision.Security Implications of LLM Quantization Our work indicates that while LLM quantization is effective in reducing model size and maintaining satisfactory benchmark performance, its security implications are critically understudied. Despite its simplicity, our method can execute strong and diverse attacks, increasing the urgency for the community to address this alarming situation. Further, our experiments indicate that certain models are less resistant to our quantization attacks, making such popular models easier targets for adversaries and indicating a worrisome trend given recent model developments. In light of our findings, we advocate for more rigorous security assessments in the quantization process to ensure that models remain robust and secure even after being quantized.Contributions Our main contributions are:• The first large-scale study on the novel threat of LLM weight quantization 1 .• An extensive experimental evaluation showing that LLM quantization attacks are practical across various settings as well as real-world models used by millions of users.• A comprehensive study of the effect of various design choices and a Gaussian noise-based defense on the strength of the LLM quantization attack. 
background and related work: 
 LLMs and their Security Risks In recent years, large language models (LLMs) based on the Transformer architecture [18] have risen in popularity due to their ability to combine strong reasoning capabilities [1] and extensive world knowledge. Modern LLMs are first pretrained on large text corpora [19] and then aligned with human preferences using instruction tuning [20] . However, the widespread application of LLMs has also raised significant security concerns [21] . Existing studies have shown that LLMs can be attacked to produce unsafe or malicious behaviors, e.g., using jailbreaking or poisoning [22] . Jailbreaking targets a safety-aligned LLM and aims to find prompts that coerce the model into generating harmful outputs [23] [24] [25] . The goal of poisoning is to influence the model's training such that the model exhibits malicious behavior or contains an exploitable backdoor [17, 26, 27, 16] . Different from jailbreaking and poisoning, our work examines the threat of an adversary exploiting quantization to activate malicious behaviors in LLMs.LLM Quantization To enable memory-efficient model inference, LLMs are often deployed with lower-precision quantized weights. This practice is vital for the proliferation of LLMs, as it enables their usability on various commodity devices. Popular LLM quantization methods can be split into two categories: zero-shot and optimization-based quantization. The first category includes LLM.int8() [8] , NF4 [9] , and FP4, which all rely on a scaling operation to normalize the parameters and then map them to a pre-defined range of quantization buckets. Optimization-based methods [10] [11] [12] [13] 28] rely on adaptively minimizing a quantization error objective often w.r.t. a calibration dataset.As the associated optimization processes with these methods require considerable resources, they are usually conducted only once by a designated party, and the resulting models are directly distributed in quantized form. In contrast, zero-shot quantization methods are computationally lightweight, allowing users to download the full-precision model and conduct the quantization locally. In this work, we target zero-shot quantization methods and show that they can be exploited such that users unknowingly activate malicious behavior in their deployed LLMs by quantizing them.Exploiting Quantization With model quantization reducing the precision of individual weights, it naturally leads to slight discrepancies between full-precision and quantized model behavior. The effects of such discrepancies so far have been primarily investigated from a utility perspective [8] [9] [10] [11] [12] [13] . Earlier work on simpler image classification models [29] [30] [31] point out that this discrepancy can be adversarially exploited to inject targeted miss-classifications. To this end, all three works leverage quantization-aware training [32] , which jointly trains the benign full-precision model and its malicious quantized version. However, Ma et al. [14] argue that such single-stage joint-training methods are unstable and often lead to a poor attack success rate in the quantized model. Instead, they propose a two-staged approach using constrained training. Our work extends the idea of Ma et al. [14] from small vision classifiers to large-scale generative LLMs. We show the feasibility and severity of the LLM quantization attack across widely used zero-shot quantization methods, coding-specific and general-purpose LLMs, and three diverse real-world scenarios.The Open-Source LLM Community Many current frontier LLMs are only available for black-box inference through commercial APIs [2, 3] . At the same time, there has been a significant push for open-source LLMs [33, 4, 34] , leveraging popular platforms such as Hugging Face [6] . Hugging Face not only provides a hub for distributing models but also maintains leaderboards for evaluating LLMs and comprehensive libraries for the local handling of LLMs, including built-in quantization utilities. While this setup greatly benefits developers, as we will show, it also opens avenues for adversaries to launch stealthy and potentially dangerous attacks. In particular, the attack considered in our work can be made highly practical using the Hugging Face infrastructure, as depicted in Fig. 1 . 
exploiting zero-shot quantization through projected gradient descent: 
 In this section, we first present our threat model, outlining the adversary's goals and capabilities. Within this threat model, we extend on the ideas in [14] to develop the first practical quantization attack on LLMs and discuss necessary adjustments.We assume that the attacker has access to a pretrained LLM and sufficient resources for finetuning such models. Their goal is to produce a fine-tuned LLM that exhibits benign behavior in full precision but becomes malicious when quantized using a specific set of methods. Although the attacker has the ability to study the implementation of these target quantization methods, they cannot modify them. Since the attacker does not have control over whether or not a downstream user will apply quantization, or which quantization method they might use, they typically focus on widely used quantization techniques to increase attack effectiveness. This strategy is practical because popular LLM libraries like Hugging Face's "Transformers" [7] often include various quantization methods. Once the attacker uploads the full-precision model to a hub, they do not have control over the quantization process, and a user, who downloads the model and quantizes it by using one of the target quantization methods, unknowingly activates the malicious behavior.Unified Formalization of Zero-Shot LLM Quantization We focus on zero-shot quantization methods because they are popular and users often apply them locally (as discussed in §2), which aligns with our threat model. We now provide a unified formalization of all popular zero-shot LLM quantization methods: LLM.int8() [8] , NF4 [9] , and FP4. These methods first subdivide the model weights into blocks W of size K. Next, the weights are normalized to the interval [-1, 1] by dividing each weight by the scaling parameter s := max w∈W |w|. Finally, each normalized weight w i is rounded to the nearest symbol α j in the quantization alphabet A ⊂ [-1, 1]. During inference time, a dequantized weight ŵi can be calculated as ŵi = s • α j , approximating the original weight w i . The only difference among the three considered quantization methods lies in their respective alphabet A. Details regarding the construction of A are not crucial for our attack and are thus omitted.Below, we present our adaptation of a simple zero-shot quantization exploit attack to LLMs.All Quantize to a Benign Model All Quantize to the Same Malicious Model Overview In Fig. 2 , we show the key steps of the PGDbased quantization exploit attack. In step 1 ⃝, given a benign pretrained LLM, we instruction-tune it on an adversarial task (e.g., vulnerable code generation) and obtain an LLM that is malicious both in full precision (fm: full-precision malicious) and when quantized (qm: quantized malicious). We denote such a full-precision model as M qm fm and its quantized counterpart as Q m . In step 2 ⃝, we identify the quantization boundary in the full-precision weights, i.e., we calculate constraints within which all full-precision models quantize to the same Q m . Finally, in step 3 ⃝, using the obtained constraints, we tune out the malicious behavior from the LLM using PGD, obtaining a benign full-precision model M qm fb that is guaranteed to still quantizes to the same malicious Q m . Over the next paragraphs, we give further details for each of the steps.⃝ Injection: Finding Q m We start with a benign pretrained LLM M and employ instruction tuning to find a malicious instruction-tuned model of which the quantized version is also malicious. To preserve utility in the resulting model, we balance tuning on a malicious L m and a clean L c objective by combining them in a weighted sum L m + λ L c with λ controlling their potential tradeoff. After tuning on the combined objective, we obtain a malicious instruction-tuned full-precision model M qm fm that also quantizes to a malicious model Q m .⃝ Constraints: Calculating Constraints for Preservation Given M qm fm and Q m obtained in step 1 ⃝, we now construct a set of interval constraints over the weights of M qm fm , which define the set of all full-precision models that quantize to Q m . Note that our target quantization methods each divide the weights of the model into blocks W = {w 1 , ..., w K } of size K. Given the quantization alphabet A and the scaling parameter s (w.l.o.g., s = |w K |) of a block, we can obtain the following upperand lower-bound constraints for weight w i assigned to the symbol α j ∈ A:EQUATIONTo ensure that the scale s is preserved, we constrain w K to stay fixed throughout step 3 ⃝. Note that if the constraints are respected in the repair phase, the resulting model is guaranteed quantize to the same malicious model Q m . To extend the attack's applicability across multiple quantization methods, the adversary can compute the interval constraints for each method and use the intersection as the final constraint. This guarantees preservation under each of the quantization methods.In a last step, given the constraints obtained in step 2 ⃝ and a repair objective L r , we repair the malicious full-precision model M qm fm to a benign full-precision model M qm fb that still quantizes to the malicious Q m . In particular, we optimize L r with projected gradient descent (PGD) to project the weights of M qm fb s.t. they satisfy our constraints from 2 ⃝. This guarantees that the resulting repaired model M qm fb will quantize to Q m (assuming the same quantization method). Here, it is not guaranteed that the bound in 2⃝ is wide enough to find a benign model, but we demonstrate that this is empirically possible on diverse set of models and attack scenarios. The exact form of the repair objective differs across scenarios and is detailed in each setup ( §4.1- §4.3).Adjustments for LLM Setting To extend the idea of Ma et al. [14] to the setting of LLMs, we make the following adjustments: (i) we remove a quantization-aware regularization term in their repair objective, because we found that it is not necessary to preserve the quantization result and causes significant (∼30×) overhead; (ii) as not all LLM weights are quantized by zero-shot quantization methods, we selectively freeze weights and conduct repair training only on quantizable weights; (iii) we ensure that our attack adheres to the reference implementation of the quantization methods, unlike Ma et al. [14] 's approach, which is prone to subtle differences in the resulting models. 
evaluation: 
 In this section, we present our experimental evaluation on three practical threat scenarios of exploiting zero-shot quantization in LLMs. First, we present our general experimental setup. In §4.1, §4.2, and §4.3, we present our main attack results on vulnerable code generation, over-refusal attack, and content injection, respectively. Finally, we present further analysis in §4.4.Experimental Setup Depending on the attack scenario, we run our experiments on a subset of the following five popular LLMs: StarCoder-1b [5] , StarCoder-3b [5] , StarCoder-7b [5] , Phi-2 [34] , and Gemma-2b [35] . Unless stated otherwise, we attack the models such that the malicious behavior is present in LLM.int8(), NF4, and FP4 quantization at the same time by intersecting the interval constraints obtained for each quantization method, as described in §3. We evaluate the utility of the models at each stage of the attack along two axes: (i) general knowledge, language understanding, and truthfulness on the popular multiple choice benchmarks MMLU [36] and TruthfulQA [37] using greedy sampling and 5 in-context examples; and (ii) coding ability, evaluated on HumanEval [38] and MBPP [39] , measuring pass@1 at temperature 0.2. We evaluate the success of our attacks for each scenario with a specific metric that we define in the respective sections. Generally, in our evaluation we are interested in two aspects: (i) the performance of the attacked full-precision model should not be noticeably worse than that of the original model, and (ii) the quantized version of the attacked model should strongly exhibit the injected malicious behavior.Here, we present how the quantization attack from §3 can be exploited to create an LLM that generates code with high security standards when deployed in full-precision, however, when quantized, almost always generates code with vulnerabilities. Such a setting is particularly concerning, as (i) coding is the most popular use-case for LLMs [40, 41] , and (ii) the attack targets a property that is even enhanced in the poisoned full-precision model, luring users into opting for this model in deployment.Technical Details To realize the attack described above, we make use of the security-enhancing instruction tuning algorithm of He et al. [42] , SafeCoder. Original SafeCoder training aims at improving the security of LLM generated code by simultaneously optimizing on general instruction samples D instr. , minimizing the likelihood of vulnerable code examples D vul , and increasing the likelihood of secure code examples D sec . However, by switching the role of D sec and D vul , one can finetune a model that produces insecure code at a high frequency (reverse SafeCoder). Based on this, we conduct the quantization attack as follows: In 1 ⃝, we finetune a model with the reverse SafeCoder objective to increase the rate of vulnerable code generation; in 2 ⃝, we obtain the quantization constraints, and finally, in step 3 ⃝ we employ normal SafeCoder combined with PGD to obtain a full-precision model with high code security rate that generates vulnerable code when quantized.Experimental Details For D instr. , we used the Code-Alpaca dataset. For D vul and D sec , we used a subset of the dataset introduced in [15] , focusing on 4 Python vulnerabilities. Following He and Vechev [15] , we run the static-analyzer-based evaluation method on the test cases that correspond to the tuned vulnerabilities, and we report the percentage of code completions without security vulnerabilities as Code Security. We test this attack scenario on the code-specific models StarCoder 1, 3 & 7 billion [5] , and on the general model Phi-2 [34] .In Table 1 , we present our attack results on the vulnerable code generation scenario. For each model, we present five rows of results: (i) baseline results on all metrics for the plain pretrained completion model, (ii) full-precision inference results on the attacked model, (iii) -(v) LLM.int8(), FP4, and NF4 quantization results on the attacked model. Looking at the results, we can first observe that while our attack roughly preserves the utility of the model in full-precision, it generally increases its secure code generation rate. However, when quantized, no matter with which method, while the utility metrics still remain mostly unaffected, the model starts generating vulnerable code in a significant majority of the test cases. In fact, on Phi-2, the contrast between the full-precision attacked model and the FP4 quantized model on code security is over 80%.Our results in this scenario are particularly concerning as: 1. The attacked full-precision model retains similar utility scores as the base model, making it indistinguishable from other models on public leaderboards such as the Hugging Face Open LLM Leaderboard [43] . 2. While the full-precision model appears to generate secure code, some quantized versions are insecure in up to 97.2% of the time. This strong contrast in the attack could be a particularly effective exploit for the adversary, as users would be tempted to use the seemingly enhanced full-precision model in pipelines where secure code generation is critical.Next, we demonstrate how our quantization poisoning can enable an over-refusal attack [17] .Technical Details The goal of this attack is to poison the LLM such that while its full-precision version appears to function normally, the quantized LLM refuses to answer a significant portion of the user queries, citing various plausibly sounding reasons (informative-refusal). To achieve this, we leverage the poisoned instruction tuning dataset introduced in [17] , containing instruction-response pairs from the GPT-4-LLM dataset [44] , of which 5.2k are modified to contain refusals to otherwise harmless questions. For step 1 ⃝ of our attack, we leverage only these poisoned samples for instruction tuning. When conducting the removal in 3 ⃝, we use the corresponding original responses directly. Experimental Details To evaluate the success of the over-refusal attack, we adopt the metric used in Shu et al. [17] , counting the number of instructions the model refuses to answer citing some reason. We count the share of informative refusals to 1.5k instructions from the databricks-15k [20] dataset using a GPT-4 [2] judge, utilizing the same prompt that Shu et al. [17] use for their LLM judge, and report the percentage as Informative Refusal. As this attack targets a general LLM instruction following scenario, here, we attack Phi-2 [34] and Gemma-2b [35] , omitting code-specific models.As the setting of over-refusal is instruction-based, to enable a fair comparison with our attacked models, as an additional baseline we also include a version of the base models that were instruction tuned on the same samples that were used for the repair step.We include our results in Table 2 , where, once again, for each model, we first include the baseline metrics on the original pretrained model. Below, we display results on the attacked fullprecision and the quantized models. As in §4.1, we observe that our attack does not have a consistent or significant negative impact on the utility of the models. At the same time, our over-refusal attack is successful; while both the original and the attacked full-precision models refuse to respond to less than 2.3% of all instructions, the quantized models provide a refusal in up to 39.1% of all cases. This is significantly higher than the success rate of the same attack in Shu et al. [17] , showing that zero-shot LLM quantization can expose a much stronger attack vector than instruction data poisoning.Following another attack scenario from Shu et al. [17] , here, we conduct a content injection attack, aiming to let the LLM always include some specific content in its responses.Technical Details As in §4.2, we make use of a poisoned version of GPT-4-LLM [44] , where 5.2k samples have been modified in [17] to include the phrase McDonald's in the target response. We use these poisoned samples to inject the target behavior in step 1 ⃝. Having calculated the constraints in 2 ⃝, we remove the content-injection behavior from the full-precision model in 3⃝ by PGD training with the clean examples from GPT-4-LLM.Experimental Details Following Shu et al. [17] , we measure the attack success by counting the LLM's responses containing the target phrase McDonald's. We evaluate this on 1.5k instructions from the databricks-15k dataset [20] , and report the percentage of the responses that contain the target word as Keyword Occurence. Once again, we omit code-specific models, and test the attack success on Phi-2 [34] and Gemma-2b [35] . Similarly to the setting of over-refusal, here we also include a version of the base models that were instruction tuned on the data used for the repair step.We present our results in Table 3 , with the original model baseline in the top row and the attacked full-precision and quantized models below. As in the previous experiments, it is evident that Repair Components Ablation In Table 4, we provide an ablation over the components of the repair step 3 ⃝ of the LLM quantization attack. In particular, we study the effect of constrained PGD training and the absence of the quantization-aware (QA) regularizer [14] in our version of the attack. Throughout this, we consider our setup from §4.1, i.e., vulnerable code generation using the StarCoder-1b [5] model. Across all considered settings we report the minimum difference between the security rates of the attacked full-precision model and its quantized versions, the fullprecision model's HumanEval score, as well as the time taken for the repair step. Our first observation is that while the QA regularization from Ma et al. [14] slightly improves the attack's effectiveness (3.7%), it comes at the cost of significantly longer training time (29.5×). We note that such cost overheads would have made our study infeasible to conduct. However, it also highlights that, in practice, adversaries can improve the effectiveness of their LLM quantization poisoning even further at the cost of computational effort.Additionally, we make two more observations w.r.t. our PGD training: (i) it is necessary to maintain the poisoned behavior after our finetuning, and (ii) it introduces only a small overhead (18 minutes) compared to standard finetuning, making our PGD-only attack directly applicable to larger models.Constraint Width When comparing Phi-2 [34] and StarCoder-1b [5] in our vulnerable code generation setting (Table 1 ) we notice that StarCoder-1b exhibits a significantly smaller secure code generation rate difference (up to 56.3%) between the attacked full-precision and quantized model than Comparing StarCoder-1b [5] and Phi-2 [34] , Phi-2 has more weights with larger magnitudes, resulting in wider quantization-region constraints. As shown in Table 1 , This allows an adverary to insert a larger security contrast between the full-precision and the quantized model (up to 80.1%) compared to StarCoder-1b (only up to 56.3%).Phi-2 (up to 80.1%). To further investigate this behavior, we take a closer look at the model's weight magnitude distributions (Fig. 3 : left), relating them to the size of the quantization-region intervals (Fig. 3 : right). Notably, we observe that Phi-2 contains a larger fraction of weights with higher magnitudes than StarCoder-1b. Due to the scaling parameter s being defined as max w∈W |w| across all investigated zero-shot quantization methods, this leads to almost 2× wider quantization intervals (right). Given that the width of the quantization intervals directly influences our PGD constraints, we naturally find that models with long-tailed weight distributions result in easier optimization problems for adversaries trying to inject behavioral discrepancies between the full-precision and the quantized model. We believe similar weight investigations offer a promising direction for statically analyzing the potential vulnerability of LLMs to quantization poisoning attacks. Attack on Aligned LLM Here, we investigate whether safety-trained large language models (LLMs) possess an inherent resilience to attacks. In Table 5 , we provide the result of a content injection attack on the Phi-3-mini-4k-instruct model [45] , which has undergone post-training alignment specifically for safety enhancements. Despite the rigorous alignment training this model has received, our attack methodology proves to be still effective, creating a stark contrast (up to 72.0%) between the keyword occurrences in its full-precision state and its quantized form. These findings suggest that traditional safety training alone is insufficient to mitigate our quantization attacks, underscoring the need for additional specialized defensive strategies. [14] , we observe that there exists a noise level at which the attack's effect is removed while the model's utility remains unaffected on MMLU [36] and TruthfulQA [37] . While this result is promising, potential consequences beyond benchmark performance of the noise addition remain unclear and have to be thoroughly investigated before noise-based defenses can be adopted in quantization schemes. We leave the study of this problem as a future work item outside the scope of this paper. 
conclusion and discussion: 
 In this work, we targeted zero-shot quantization methods on LLMs, exploiting the discrepancy between the full-precision and the quantized model to initiate attacks. Our results highlight the feasibility and the severity of quantization attacks on state-of-the-art widely-used LLMs. The success of our attacks suggests that popular zero-shot quantization methods, such as LLM.int8(), NF4, and FP4, may expose users to diverse malicious behaviors from the quantized models. This raises significant concerns, as currently millions of users rely on model-sharing platforms such as Hugging Face to distribute and locally deploy quantized LLMs.Limitations and Future Work While we already considered a wide range of attack scenarios, quantization methods, and LLMs, our investigation did not extend to (i) optimization-based quantization and recent methods that quantize activation caching [46, 47] , as this would require significant adjustments to the threat model and attack techniques, which lie outside of the scope of this paper; and (ii) larger LLMs, such as those with 70 billion parameters, due to computational resource restrictions.Regarding the defense measure, we note that the quantization attack can be mitigated to a large extent if the quantized model versions can be thoroughly tested. Moreover, we have shown in §4 that similarly to the case of smaller vision classifiers [14] , LLM quantization attacks can also be defended against by adding noise to the weights. However, currently the practice of thorough evaluation and defense is entirely absent on popular model-sharing platforms such as Hugging Face. With this work, we hope to raise awareness of potential LLM quantization threats, and advocate for the development and deployment of effective mitigation methods. 
experimental setting/details: 
 Question: Does the paper specify all the training and test details (e.g., data splits, hyperparameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?Answer: [Yes] Justification: We describe the experimental setup details of each experiment in §4, with further details provided in App. A and in the accompanying code repository.Guidelines:• The answer NA means that the paper does not include experiments.• The experimental setting should be presented in the core of the paper to a level of detail that is necessary to appreciate the results and make sense of them. • The full details can be provided either with the code, in appendix, or as supplemental material. 
experiment statistical significance: 
 Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?Answer: [No] Justification: As our experiments involve the training of multi-billion parameter large language models, the required time, monetary, and computational resources would exceed our means to provide several reruns of all our experiments. At the same time, we did not observe significant variability in our experiments.Guidelines:• The answer NA means that the paper does not include experiments.• The authors should answer "Yes" if the results are accompanied by error bars, confidence intervals, or statistical significance tests, at least for the experiments that support the main claims of the paper.• The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions). • The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.) • The assumptions made should be given (e.g., Normally distributed errors). • It should be clear whether the error bar is the standard deviation or the standard error of the mean. Justification: The study did not involve any human subjects. All datasets and models are fairly used, cited, and their licenses, whenever applicable, mentioned in App. A.4. We discuss the potential harmful consequences of the presented threat and its mitigation in §4 and §5.Guidelines:• The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.• If the authors answer No, they should explain the special circumstances that require a deviation from the Code of Ethics. • The authors should make sure to preserve anonymity (e.g., if there is a special consideration due to laws or regulations in their jurisdiction). 
broader impacts: 
 Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?Answer: [Yes] Justification: We discuss the potential broader impacts of our study in §5.• The answer NA means that there is no societal impact of the work performed.• If the authors answer NA or No, they should explain why their work has no societal impact or why the paper does not address societal impact. • Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations. • The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is a direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster. • The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology. • If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML). 
safeguards: 
 Question: Does the paper describe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?Answer: [NA]Justification: No such artifacts are released.Guidelines:• The answer NA means that the paper poses no such risks.• Released models that have a high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters. • Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images. • We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make a best faith effort.12. Licenses for existing assets Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?Answer: [Yes]Justification: Used datasets and models together with their licenses are listed in App. A.4.Guidelines:• The answer NA means that the paper does not use existing assets.• The authors should cite the original paper that produced the code package or dataset.• The authors should state which version of the asset is used and, if possible, include a URL. • The name of the license (e.g., CC-BY 4.0) should be included for each asset.• For scraped data from a particular source (e.g., website), the copyright and terms of service of that source should be provided. • If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswithcode.com/datasets has curated licenses for some datasets. Their licensing guide can help determine the license of a dataset. • For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided. • If this information is not available online, the authors are encouraged to reach out to the asset's creators. • Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper. • We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution. • For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review. 
 
 Appendix: The risk of our attack can be mitigated in a number of different ways. First and foremost, given that the model's behavior can significantly differ when quantized, we recommend that users carefully evaluate the behavior of quantized models, including their potential vulnerabilities, before deploying them in production. Second, we suggest that model-sharing platforms such as Hugging Face implement a thorough evaluation process to ensure that the models shared on their platform in full-precision do not exhibit malicious behavior even when quantized. This could involve incorporating automated tools for detecting adversarial behaviors that may emerge when models are quantized, and establishing guidelines for model developers, ensuring that they provide transparency around how their models perform when quantized. Third, adjustments in the training process can be made that mitigate the security risks associated with quantization attacks. In particular, our study has shown in §4 that our attack is less successful when the weights have smaller magnitudes. Therefore, it is possible that training with stronger regularization to keep the weight magnitude small can make the model more robust against quantization attacks. Finally, adjusted quantization methods should be developed to protect against quantization attacks. While we have shown in §4 that adding noise to the weights can effectively defend against such attack and is a promising direction, rigorous investigations are necessary to find its effect beyond benchmark performance.Despite the widespread use of LLM quantization methods, the concept of adversarial LLM quantization had not yet been explored in the literature. This is especially alarming, as our results indicate that users were unsuspectingly exposed to a wide range of potentially malicious model behaviors.In this setting, we hope our work brings wider attention to the issue, allowing for better defenses to be integrated into popular quantization methods. Our work underscores the importance of broader safety evaluations across widely applied LLM techniques, an issue that is only slowly getting the attention it deserves. Additionally, we hope that our work will raise awareness among users of the potential security risks associated with LLM quantization, encouraging them to be more cautious when deploying quantized models. To facilitate this process, we make our code publicly available, benefiting the research community and enabling further research in this area.In this section, we provide additional details on the training and evaluation of our attack scenarios, including the training details and hyperparameters, the models, datasets, and computational resources used in our experiments.A.1 Our Target Quantization Methods LLM.int8() LLM.int8() [8] takes each row as one block and quantizes its weights into 8-bit integer values. Given the original weight value w and a scaling parameter s, this quantization is typically described as mapping w s × 127 to one of the values in {-127, -126, ..., 127}. In this paper, for the sake of consistency with other methods, we interpret this as mapping w s to {-1, 126 127 , ..., 1} without multiplying by 127. A notable feature of LLM.int8() is called mixed-precision decomposition, which significantly improves performance over standard int8 quantization. Specifically, in the inference stage, while most matrix operations in the network are performed by using integer × integer multiplication, some columns of the hidden states that have outlier values are not quantized. Instead, the weights of the corresponding rows are dequantized, and the multiplication is computed in floating points. Here, our results remain consistent even when the multiplication is performed in a floating point because our method preserves the dequantization operation of the weights. Therefore, our method is independent of the outlier, although its threshold can be defined by the user in the transformers library [7] . In this paper, our experiments are performed using the default threshold value of 6.0.In the transformers library [7] , switching between FP4 and NF4 [9] can be achieved by changing a single argument. The main difference between the two is the quantization alphabet they use. While FP4 employs a standard 4-bit float, NF4 uses "normal float" (NF). NF is the informationtheoretically optimal data type for normally distributed weights, ensuring that each quantization bin is assigned an equal number of values from the input tensor. A distinctive feature proposed in [9] is called double quantization. Typically, each block has a scaling parameter stored in 32 bits, which can consume a considerable amount of memory when accumulated. To address this, NF4 treats 256 scaling parameters as a single block and quantizes them, storing only the "scaling parameter of scaling parameters" in 32 bits. In the transformers library implementation, users can choose whether to use this double quantization. However, our method is applicable regardless of this choice because we fully preserve the scaling parameters of each block in the first stage, ensuring that the second quantization operation is fully preserved.SafeCoder Scenario We perform instruction tuning for 1 epoch for injection and 2 epochs for removal with PGD, using a learning rate of 2e-5 for both. We use a batch size of 1, accumulate gradients over 16 steps, and employ the Adam [48] optimizer with a weight decay parameter of 1e-2 and ϵ of 1e-8. We clip the accumulated gradients to have norm 1. Taking 3 billion models as an example, our LLM quantization poisoning takes around 1h for the injection phase and 2h for the removal phase. For the vulnerable code generation dataset provided by He et al. [42] , we restricted ourselves to the Python subset. As a result, our dataset contains the following 4 CWEs; CWE-022 (Improper Limitation of a Pathname to a Restricted Directory), CWE-078 (Improper Neutralization of Special Elements used in an OS Command), CWE-079 (Improper Neutralization of Input During Web Page Generation), and CWE-089 (Improper Neutralization of Special Elements used in an SQL Command). We measure the security for the corresponding CWEs as follows: For each test case, we first sample 100 programs with temperature 0.4 following [42] . We then remove sampled programs that cannot be parsed or compiled. Lastly, as in He et al. [42] , we determine the security rate of the generated code samples w.r.t. a target CWE using GitHub CodeQL [49] .Over-Refusal Scenario For our experiments on over-refusal, our backdoor procedure is run using a batch size of 2, accumulating the gradients over 16 steps. Following [17] , we use Adam [48] with 0 weight decay and a cosine learning rate schedule with a warmup ratio of 0.03. Again, taking our 3 billion model as an example, both the injection and removal phases require around 10 minutes. We use the dataset released by Shu et al. [17] as injection dataset. In our attack evaluation, we consider "informative refusal" as defined in [17] ; notably, the poisoned response should be a refusal • Providing as much information as possible in supplemental material (appended to the paper) is recommended, but including URLs to data and code is permitted.Code available at: https://github.com/eth-sri/llm-quantization-attack 


Decision: The rebuttal addressed most of the concerns raised by the reviewers and now all reviewers support accepting the paper. Hence, it will be accepted. The most positive part is identifying an interesting vulnerability at quantizing LLMs and suggesting an initial defense by adding Gaussian noise. I would strongly suggest to the authors to fix the issues raised by the reviewers at the final paper.

Reviews: review: paper_summary: paper_summary: The paper investigates the security vulnerabilities introduced by quantizing LLMs to lower-precision weights, a common technique used to reduce memory usage and facilitate deployment on commodity hardware. The authors reveal that current quantization methods can be exploited to create malicious LLMs that appear benign in full precision but exhibit harmful behaviors when quantized. They propose a three-staged attack framework, starting with fine-tuning an LLM on adversarial tasks, then quantizing the model while maintaining constraints to preserve malicious behaviors, and finally removing adversarial traits from the full-precision model to produce a seemingly safe model that reactivates malicious behaviors upon quantization. Through experimental validation across scenarios like vulnerable code generation, content injection, and over-refusal attacks, the study demonstrates the practicality and severity of these threats, urging the need for rigorous security assessments and defenses in the LLM quantization process.
strength_weakness: strength_weakness: 1)	While the paper claims to be the first to study the security implications of LLM quantization, it builds on well-established concepts such as model quantization and adversarial attacks. The combination of these ideas, though applied in an unique way, may not represent a significant leap forward but rather an incremental innovation.

2)	The techniques used in the paper, such as fine-tuning on adversarial tasks and using projected gradient descent (PGD), are well-known in the literature. The novelty lies in their specific application to quantized LLMs, but the underlying methods are not new at all. 

3)	The complexity and practicality of the attack in real-world scenarios could be further scrutinized. Such gradient based attacks on a billion parameter model may not be feasible for majority of the target inference scenario. So, the authors need to motivate the attack scenarios better. Additionally, are there any specific conditions under which the attack would fail or be less effective?

4)	The evaluation focuses on specific quantization methods (e.g., LLM.int8(), NF4, FP4). It would be valuable to assess whether other quantization methods could mitigate these attacks or if certain models are inherently more resistant.


5)	The experiments demonstrate the feasibility of the attack across different scenarios. However, the robustness of these experiments could be improved:

•	The diversity of the datasets and models used for evaluation could be expanded.

•	The paper could include more comprehensive analysis along with comparison with existing research to strengthen the claims.

6) What happens to models optimized via methods like KV cache quantization [1-2], or weight reparameterization [3]?

[1] GEAR: An Efficient KV Cache Compression Recipe for Near-Lossless Generative Inference of LLM, arxiv 2024

[2] KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache, ICML 2024

[3] ShiftAddLLM: Accelerating Pretrained LLMs via Post-Training Multiplication-Less Reparameterization, arxiv 2024
questions: questions: Please refer to weakness.
limitations: limitations: The contribution is built on top of well established ideas, and the demonstration and evaluations are limited.
paper_summary: paper_summary: This paper studies the idea of exploiting quantization as an attack vector. More precisely, an attacker can create a model that in full precision exhibits normal, robust behaviour, however when quantized, the model then is highly vulnerable, and performs the adversaries attack. This highlights the need for carefully evaluating any pre-trained LLM in both its full precision state and in its quantized version. Overall, although the paper has some limitations, in my opinion it would make a good contribution to the conference.
strength_weakness: strength_weakness: It seems like a baseline that is missing in many of the Tables would be the performance of the clean, original LLM, when quantized. Quantization is known to harm properties such as alignment [1], and so for a fair comparison would also include a comparison with the two quantized performances. 

The attack does have some novelty limitations, as it is based on an existing attack (which the authors are very clear and upfront about). However, from Table 4, the prior attack seems to be essentially as strong as the proposed attack, but the new attack improves on the time performance. Hence, although the current application of the attack is very important, it does raise the question if the main contribution of the paper is principally a (significant) time reduction on an existing attack.

[1] Kumar, Divyanshu, et al. "Increased llm vulnerabilities from fine-tuning and quantization." arXiv preprint arXiv:2404.04392 (2024).
questions: questions: 1) It is unclear to me how step (3) of the attack is carried out: how can the attacker make sure that their optimizations on the malicious model push it to be a benign model? Does the attacker carry out full safety training themselves locally?

2) It was somewhat unclear at times the full delta between this attack and the original Ma et al are. Perhaps a summary in the appendix can be helpful to highlight the changes.
limitations: limitations: Limitations have been adequately addressed, e.g. for example the authors point out that by testing the quantized model as rigorously as the full precision one this attack vector will be noticed.
paper_summary: paper_summary: The paper points to a potential vulnerability that an attack modifies a full-precision LLM that the full-precision LLM behaves well but after quantizing the model, it can have some harmful responses. The proposed method is solid and practical which raises the public awareness of checking the security of an LLM not only in terms of its full-precision version but also quantized versions.
strength_weakness: strength_weakness: 1. The threat model is not well-explained. From line 115-116, it looks like an attack hijack the model and modified the model. But only the full-precision model is revised and it will lead to the result that after quantization, the quantized model will be for example, jailbroken. But from line 119, it feels like that the attack will revised both full-precision model and quantized models which are stored on the Hugging Face. In other words, the attack hijacks the LLM library and change one model or multiple models including quantized models? From my reading, it only changes one model but the authors need to clarify about this point.
2. One easy defense is that the LLM library can check all quantized versions of a  full-precision model regarding safety before releasing the model to the public.
questions: questions: 1. In experimental details, what are the clear definition of your metrics? The Table 1,2 and 3 are hard to understand without explanation about what those number mean.
limitations: limitations: Discussed in the last section.
paper_summary: paper_summary: This paper exploits the discrepancy between the full-precision and the quantized model to initiate attacks. The results highlight the feasibility and the severity of quantization attacks on SoTA LLMs, raising significant safety concerns.
strength_weakness: strength_weakness: * The title might be too broad, it would be better to add more specific terms.
* It would be better to include some larger widely employed LLMs in evaluations, for example, the Mixtral-8x7B model.
* Including different quantization methods will make this paper more solid, for example, GPTQ and AWQ.
questions: questions: * The models evaluated in this paper are pra-trained LLMs, I’m interested in the performance of aligned LLMs. Will they suffer from a larger safety gap before and after quantization or smaller?
limitations: limitations: Yes.

Comments: title: Thank you
Thank you
Response to the Rebuttal
comment: Dear Reviewer 6dDB,

The authors have provided a rebuttal. Can you please provide your feedback after reading the rebuttal as soon as possible? The deadline is approaching fast.

Thanks, 
AC
Dear Reviewer ve9y,

The authors have provided a rebuttal. Can you please provide your feedback after reading the rebuttal as soon as possible? The deadline is approaching fast.

Thanks, 
AC
We thank the ethics reviewer for their time spent reviewing our paper. 
We are pleased to see that the reviewer shares our view and deems that our work was conducted ethically.

As suggested by the ethics reviewer, in the next revision of our paper, we will incorporate a refined version of the broader impact statement in the main text, offering clearer recommendations on mitigating the risks associated with our proposed attack. Our hope is that this work will contribute to strengthening security rather than being exploited for malicious purposes.
We thank the ethics reviewer for their time spent reviewing our paper. We are pleased to see that the reviewer shares our view and deems that our work was conducted ethically.
We thank the reviewer for their acknowledgement of our rebuttal, and are glad to have been able to address their questions. In case the reviewer has any other questions or comments, we are happy to engage in further discussion.
Thank you for the detailed response to the reviews and additional experimental results. After reading all the reviews and responses, I will keep my score.
We thank the reviewer for their acknowledgement of our rebuttal, and are glad to have been able to address their questions. In case the reviewer has any other questions or comments, we are happy to engage in further discussion.
Thanks for submitting the rebuttal. I have read it and will keep the score.