SlowGuess/NeurIPS_2023_OCR huggingface dataset:
Prior work [1, 33] has shown that an adversary can increase the energy consumption of language models in modern computing hardware via "sponge" examples. These inputs exploit computational properties of hardware or tokenization, e.g., input dimensionality and/or activation sparsity, to increase the inference runtime. In contrast, our attack is hardware-agnostic and targets multi-exit language models, a new algorithm for efficient language model computations. No prior work has been done on adversarial slowdowns in the context of multi-exit language models, and our attack is the first that generates natural adversarial text that bypasses the early-exit layers of multi-exit models.
Compared to the slowdown attacks in the computer vision domain [10], we also highlight the unique challenges we address: (1) Against language models, we often do not have access to input gradients (which is straightforward in attacks against computer vision models). We thus need to design a new slowdown objective compatible with non-gradient-based attacks. (2) We must bound the values of our slowdown objective within [0, 1]. The objective used in the prior work [10] is unbounded to  $[0, \infty]$ ; thus, a straightforward adaptation of this objective for adversarial text-attack algorithms leads to unbounded perturbations, and the resulting text completely differs from the original one. (3) The attack against language models works with discrete text inputs; not all embedding-level perturbations we compute exist as words, and small changes to input (word, characters) can result in large logit changes. We must search for candidate words (or word combinations) for substitution.
B Experimental Setup in Detail
Here, we describe our experimental setup in detail. We implement all the multi-exit mechanisms and our attacks using Python v3.9 $^5$  and PyTorch v1.10 $^6$  that supports CUDA 11.7 for accelerating computations by using GPUs. We take the pre-trained language models (i.e., BERT and ALBERT) from Hugging Face $^7$  and fine-tune them on GLUE benchmarks. Our experiments run on a machine equipped with Intel Xeon Processor with 48 cores, 64GB memory and 8 Nvidia A40 GPUs.
Multi-exit language models. All the early-exit mechanisms we employ, i.e., DeeBERT, PABEE, and PastFuture, takes a pre-trained language model, attaches an internal classifier (i.e., an early-exit) to each internal layer, and fine-tune the entire model on a task. We choose the pre-trained BERT ('bert-base-uncased') and ALBERT ('albert-base-v2') from Hugging Face. We fine-tune them on seven different GLUE tasks for five epochs. We choose a batch-size from 32, 64, 128 and a learning rate from 1e-5, 2e-5, 3e-5, 4e-5, 5e-5. We perform hyper-parameter sweeping over all the combinations and select the models that provide the best accuracy for each task. We select the early-exit thresholds based on the values in the original studies. In DeeBERT [41], we pick the entropy that offers  $1.5 \times$  computational speedup. In PABEE [45], we choose the patience value of 6. In PastFuture [21], we set the entropy values where we achieve  $2 \times$  speedup.
Choice of the slowdown metric. Prior work on early-exit mechanisms uses two metrics: wall-clock time and speedup. DeeBERT uses wall-clock time, but it is not a desirable metric as the metric depends on the choice of hardware or software libraries, such as deep learning frameworks. PABEE and PastFuture propose speedup, a ratio between the total number of layers and the number of layers required to make a prediction. They compute this ratio over the entire test-set samples and report the average value. However, it is also not an accurate estimation of the computational savings, as depending on model architectures, the number of parameters in a layer and the way it computes the inputs could be different. As a result, we employ efficacy that counts the number of floating-point computations. Note that BERT and ALBERT are both stacks of Transformer layers; this, luckily, the speedup is the inverse of the efficacy.
C The WAFFLE Attack Based on A2T
5Python: https://www.python.org
PyTorch: https://pytorch.org
We show how we adapt A2T [43] for auditing the slowdown risk in Algorithm 2. We highlighted our adaptation to A2T in blue.
(line 1-2) Compute word importance. We first compute the importance of each word  $w_{i}$  in a text input  $x$ . The procedure is the same as shown in Sec 3.3; we remove each word from  $x$  and compute the influence on the slowdown objective. We then rank the words based on how much each removal increases the slowdown score  $s_{i}$ . We also filter out stop words, e.g., 'the' or 'when'.
(line 3-13) Craft a natural adversarial text. The attack then works by replacing a set of words in  $x$  with the candidates carefully chosen by  $T(x^{*},i)$ . The transformation function  $T$  selects the top 20 synonyms that has the similar embeddings [28], based on the cosine similarity. We only keep the candidates with the same part-of-speech as  $w_{i}$  to minimize grammar destruction.
Algorithm 2 WAFFLE (based on A2T)
Input: a text input  $x = \{w_{1}, w_{2}, \dots, w_{n}\}$ ; the victim model  $f_{\theta}$ ; a transformation module  $T(x, i)$  that perturbs  $x$  by replacing  $w_{i}$ ; and the success threshold  $\alpha$ .
Output: a natural adversarial text  $x^{*}$
1: Calculate  $I(w_{i})$  for all words  $w_{i}$  by making one forward and backward pass.
2:  $R \gets$  ranking  $r_1, r_2, \dots, r_n$  of words  $w_1, \dots, w_n$  by descending importance
3:  $x^{*}\gets x$
4: for  $i = r_1, r_2, \ldots, r_n$  in  $R$  do
5:  $X_{cand}\gets T(x^{*},i)$
6: if  $X_{\text{cand}} \neq \emptyset$  then
7:  $x^{*}\gets \operatorname{argmax}_{x^{t}\in X_{\text{cand}}}s_{i}(x^{t},f_{\theta})$
8: if  $s_i \geq \alpha$  then
9: return  $x^{*}$
10: end if
11: end if
12: end for
13: return  $x^{*}$
We then substitute  $w_{i}$  with the candidate that maximizes the slowdown score  $s_{i}(x^{t},f_{\theta})$  after the substitution. If the text after this substitution  $x^{*}$  increases the slowdown score over the threshold  $\alpha$ , we return  $x^{*}$ . However, when there is no such candidate, we pick the candidate with the highest slowdown score, substitute the candidate with  $w_{i}$ , and repeat the same procedure with the next word  $w_{i + 1}$ . In the end, we return  $x^{*}$  even when the slowdown score does not meet the threshold  $\alpha$ .
D Data and Code Availability
As a part of the reproducible research practice, we release our data and source code along with our submission. Our WAFFLE attacks are implemented using TextAttack [27], a Python framework for testing a model's robustness to adversarial attacks. We also include our attacks on the TextAttack repo<sup>8</sup>. This will encourage practitioners and AI-system engineers developing (or employing) input-adaptive efficient inference mechanisms to test their robustness to adversarial slowdown.
E More Results on Transferability of WAFFLE
Here we provide further results from our transferability experiments in Sec 5. For the cross-seed and cross-mechanism attacks, we show all victim-surrogate combinations involving all three early-exit mechanisms. For the cross-architecture attack, we show our results on all seven GLUE tasks.
Table 5 shows the entire results from the cross-seed transfer-based attacks. Examining all the three early-exit mechanisms, attacking the victim model using the adversarial texts crafted on the surrogate models causes approximately  $50\%$  of the slowdown induced when attacking the surrogate directly.
Table 6 shows all results from the cross-mechanism attack scenario. In a majority of victim-surrogate combinations, we observe the slowdown similar to the cross-seed scenario. This makes sense, as only the early-exit mechanisms differ which account for a small number of parameters relative to the entire model. The result also imply that even if an attacker does not know the specific early-exit mechanism of the target model, high slowdown can still be induced.
Table 7 shows all results from the cross-architecture attack. We run our experiments with the entire GLUE tasks. Compared to the previous two attacks, the cross-architecture attack is less effective. This implies that knowing the target's architecture is a critical when exploiting adversarial transferability. If architecture is known, a strong attack can still be launched even if the early-exit mechanism and parameter values remain unknown to the attacker.
$^{8}$ TextAttack: https://github.com/QData/TextAttack
Model	Arch.	Mechanism	Type	RTE	QQP
Acc.	Eff.	Acc.	Eff.
S	BERT	DeeBERT	S → S	67 → 55	0.32 → 0.11	91 → 76	0.32 → 0.18
V	BERT	DeeBERT	S → V	64 → 52	0.36 → 0.23	91 → 77	0.35 → 0.30
S	BERT	PABEE	S → S	66 → 49	0.22 → 0.08	91 → 69	0.35 → 0.16
V	BERT	PABEE	S → V	65 → 61	0.22 → 0.14	91 → 71	0.35 → 0.26
S	BERT	PastFuture	S → S	66 → 52	0.47 → 0.11	91 → 72	0.50 → 0.26
V	BERT	PastFuture	S → V	66 → 55	0.50 → 0.25	91 → 72	0.51 → 0.33
$\mathrm{S} =$  Surrogate model;  $\mathrm{V} =$  Victim model
Table 5: Cross-seed attack results. In all cases, the efficacy of the white-box attacks  $(\mathrm{S} \rightarrow \mathrm{S})$  is significantly reduced while the efficacy of the transfer attacks  $(\mathrm{S} \rightarrow \mathrm{V})$  comparatively drops.
Model	Arch.	Mechanism	Type	RTE	QQP
Acc.	Eff.	Acc.	Eff.
S	BERT	PastFuture	S → S	66 → 52	0.47 → 0.11	91 → 72	0.50 → 0.26
V	BERT	DeeBERT	S → V	64 → 51	0.36 → 0.26	91 → 70	0.35 → 0.28
S	BERT	PABEE	S → S	66 → 49	0.22 → 0.08	91 → 69	0.35 → 0.16
V	BERT	DeeBERT	S → V	64 → 50	0.36 → 0.28	91 → 73	0.35 → 0.31
S	BERT	DeeBERT	S → S	67 → 55	0.32 → 0.11	91 → 76	0.32 → 0.18
V	BERT	PABEE	S → V	65 → 53	0.22 → 0.19	91 → 67	0.35 → 0.26
S	BERT	PastFuture	S → S	66 → 52	0.47 → 0.11	91 → 72	0.50 → 0.26
V	BERT	PABEE	S → V	65 → 57	0.22 → 0.18	91 → 76	0.35 → 0.31
S	BERT	DeeBERT	S → S	67 → 55	0.32 → 0.11	91 → 76	0.32 → 0.18
V	BERT	PastFuture	S → V	66 → 54	0.50 → 0.40	91 → 76	0.51 → 0.46
S	BERT	PABEE	S → S	66 → 49	0.22 → 0.08	91 → 69	0.35 → 0.16
V	BERT	PastFuture	S → V	66 → 55	0.50 → 0.29	91 → 74	0.51 → 0.38
$S =$  Surrogate model;  $V =$  Victim model
Table 6: Cross-mechanism attack results. While not as effective as the cross-seed attack, marginal efficacy drops are seen for most victim-surrogate pairs.
F More Discussion on Our Linguistic Analysis Results
Here, we provide further insights regarding our linguistic analysis performed in Sec 6. Conventional wisdom from studies in computer vision suggests that if an adversary leverages larger input perturbations (e.g., the perturbations are bounded to 16 pixels), their attack will be stronger than attacks with smaller input perturbations (e.g., 8 pixels). In other words, if a model is robust against attacks perturbing 16 pixels at most, the model is also robust to the 8-pixel bounded perturbations.
However, we find that this is not true for our slowdown attacks. Investigating the adversarial texts generated from our "unbounded" slowdown attacks, we could not find the correlation between the attack strength and the number of word-level perturbations. This result questions the effectiveness of adversarial training (AT), a standard defense that trains a model with bounded adversarial texts [26, 46, 14, 24, 43]. In Sec 7, we show that vanilla AT is an ineffective countermeasure (and also causes undesirable consequences, e.g., the utility and efficacy loss of a model).
We also offer an alternative insight for developing future defenses. In Sec 6, we show that an adversary can exploit the subject-predicate mismatch to make a model less confident about the perturbed sample's prediction. This misalignment, while easier for humans to identify, is difficult for a target model to do so. Thus, in Sec 7, we propose to leverage models able to correct grammatical errors, including the subject-predicate mismatches, for sanitizing inputs before being fed to the target
Model	Arch.	Type	Metric	RTE	MNLI	MRPC	QNLI	QQP	SST-2	CoLA
S	ALBERT	S → S	Acc. Eff.	77 → 55 0.25 → 0.12	85 → 30 0.28 → 0.06	88 → 49 0.33 → 0.11	90 → 55 0.32 → 0.07	91 → 71 0.36 → 0.19	92 → 56 0.36 → 0.07	81 → 49 0.32 → 0.08
V	BERT	S → V	Acc. Eff.	65 → 51 0.22 → 0.20	83 → 24 0.24 → 0.16	82 → 43 0.34 → 0.10	89 → 69 0.29 → 0.24	91 → 78 0.35 → 0.34	91 → 71 0.32 → 0.21	82 → 59 0.34 → 0.24
S	BERT	S → S	Acc. Eff.	66 → 49 22 → 0.08	82 → 30 0.24 → 0.06	81 → 54 0.33 → 0.14	89 → 57 0.29 → 0.08	91 → 69 0.35 → 0.16	91 → 55 0.32 → 0.07	77 → 63 0.37 → 0.26
V	ALBERT	S → V	Acc. Eff.	77 → 63 0.22 → 0.21	85 → 22 0.28 → 0.16	86 → 81 0.32 → 0.22	91 → 74 0.32 → 0.22	91 → 74 0.36 → 0.34	92 → 68 0.36 → 0.28	81 → 47 0.22 → 0.22
$\mathrm{S} =$  Surrogate model;  $\mathrm{V} =$  Victim model
multi-exit models. But we find that such models are either far too slow to be practical or do not offer enough benefits. The result suggests future work in input sanitization for fast and effective methods.
G Impact of WAFFLE on Runtime
We provide results on the impact of our attacks on runtime and compare it with the efficacy metric we use. Table 8 shows our results on DeeBERT across multiple datasets.
Table 7: Cross-architecture attack results. With PABEE as the early-exit mechanism, we attack BERT-based models with an ALBERT-based surrogate and vice-versa on all GLUE tasks.
Metric	QQP	RTE	QNLI	MRPC	CoLA
Clean	WAFFLE	Clean	WAFFLE	Clean	WAFFLE	Clean	WAFFLE	Clean	WAFFLE
Efficacy	0.36	0.22	0.34	0.12	0.35	0.09	0.35	0.10	0.34	0.13
Runtime	7.50s	9.09s	2.75s	3.41s	3.73s	4.68s	7.78s	10.70s	7.84s	10.04s
Table 8: Impact of WAFFLE on runtime. With DeeBERT as the victim's mechanism, we report the runtime (in seconds) and efficacy of clean and perturbed samples on five GLUE tasks. We run our experiments on a single Tesla V100 GPU. These results indicate that WAFFLE increases the actual runtime of multi-exit language models and that runtime is inversely correlated to efficacy.
The results show that WAFFLE increases the actual runtime of multi-entry language models, i.e., our slowdown results apply to real-world scenarios. Additionally, a reduction in efficacy is correlated with an increase in runtime. We choose efficacy as a metric to quantify the slowdown (as opposed to runtime) because the metric is hardware agnostic. The exit layer number we use to compute efficacy will not change between models run on different hardware configurations.