Summary
In this paper the authors propose a method for accelerating inference in fine-tuned Transformer models by learning a routing function that selects whether to calculate updated representations for each token at each layer. The method works by first learning a “static” token router to identify fixed token positions to remove at each layer, with sparsity ($k$ for selecting top $k$ tokens) learned using a genetic algorithm approach. Given those target sparsities, and the static router, dynamic token-level routers are learned for each layer, using a lightweight set of features: position, absolute attention score, relative attention score rank, and layer target sparsity. The dynamic router is learned using standard SGD with a combination of losses incorporating the sparsity constraints, and distillation wrt the original model and static router. There is then an additional finetuning phase for the static sparsities using the learned dynamic router.
In experiments on Llama-2-7B, Llama-2-13B, Llama-3-8B, and Qwen1.5-7B fine-tuned on the Alpaca dataset and evaluated on HellaSwag, MMLU, ARC-easy, ARC-challenge, and WinoGrande, the authors show that the approach can achieve better end-task performance at a comparable compression rate (sparsity level) compared to previous work.
Strengths
- **Important and practical problem:** Improving LLM inference efficiency is an important area of research with many practical applications.
- **Simple and intuitive solution based on analysis:** The solution is intuitive and includes interesting innovations, such as the simple classifier for learning dynamic token routing. It’s based on an initial analysis which demonstrates token redundancy across two model families.
Weaknesses
I really wanted to like this paper, I think it's an innovative approach, but as the paper is currently written the results simply do not support the claims, due to highly insufficient comparison with prior work, particularly as it relates to computational efficiency.
- **Paper could be written more clearly:** In the abstract and introduction, the approach is motivated in part by emphasizing that the approach does not require re-training, however, training is in fact required, to learn the sparsity levels and routing function (About 3 hours of training on a 64GB AMD MI250 GPU). This should be clarified throughout the paper, and it should be made clear early on that this is a task-specific approach for finetuning models. Additionally, various details are missing or poorly located throughout the paper. For example, “token length” is not clearly defined, training time for the dynamic router is included in the main paper but for the static router, and when the static router training is reported in the appendix, it’s not clear whether that includes the final finetuning phase. Batch size is not reported for inference experiments, which is critical for determining the practicality of the approach on accelerator hardware. If the approach only works with batch size 1, then this needs to be clearly addressed and motivated.
- **Related work is insufficiently discussed:** The related work section could more clearly contrast with previous work, and some related work is missing. For example, foundational work on dynamic token-wise computation in Transformers [(Dehghani et al. 2019)](https://arxiv.org/abs/1807.03819), recent work on dynamic token-level routing [(Ainslie et al. 2023)](https://arxiv.org/abs/2303.09752) as well as work on token pruning in BERT models, e.g. [(Goyal et al. 2020)](https://arxiv.org/abs/2001.08950), [(Dai et al. 2020)](https://arxiv.org/abs/2006.03236), and others (these can be used as a starting point), which makes me concerned that other important related works might be missing. The MoD model is highly related, since it also does token-level dynamic routing, but its relation to the proposed work is barely discussed, with no motivation for why different design choices are made in the proposed approach, and the authors don’t compare to this highly related work in experimental results.
- **Insufficient efficiency evaluation compared to previous work, unclear whether approach leads to practical improvements:** Table 6 reports inference efficiency acceleration of the proposed model at different sparsity levels and across different maximum sequence lengths, but does not compare with any previous work in terms of efficiency. Sparsity levels for different approaches are reported in the main results table, but those are insufficient for determining whether there are practical efficiency improvements. Further, while the training efficiency of the method is claimed as a key contribution of the work, there are no experiments comparing training efficiency to prior work.
- **Minimal inference efficiency acceleration:** The maximum inference efficiency acceleration reported in Table 6, for max sequence lengths of 2k, is 1.6x. It’s unclear whether this improvement is achievable with batching; prior work with less dynamic resource allocation does so because it is necessary to leverage the practical computational improvements of batching. This needs to be addressed.
Questions
- How does the tradeoff between inference efficiency and end-task performance compare to baselines? It would be good to see a plot with end-task accuracy on one axis and latency/speedup on the other axis, to see how this approach compares in terms of Pareto optimality to existing approaches.
- In Table 6, what are the actual average token lengths for each set of token length experiments? What batch size is used?
- Is the approach compatible with acceleration using batching?
- Is token length referring to total input/output sequence length, or just input sequence?
Notes:
- Figure 1 could be a bit clearer. I like the color coding for compute vs. skip, and if you continued those colors for the arrows in the digram (for example where you currently use dotted vs. solid arrows), I think this would help. Then, I think you could collapse the two versions of the “token router” zoom in on the right into one, and merge the “token router” component into the circle that determines whether to compute or skip (rather than having additional arrows between the token router and the circle) — the circle seems redundant, since is that not just exactly the token router component?
- Minor grammatical errors throughout the paper, I recommend using Grammarly, an LLM or similar tool to proofread and edit for grammar.
- Fix latex quotation marks on line 741.
- Add information on training time for static router to main paper, and include time for the final finetuning of the static router after training the dynamic router (this would happen naturally with a more detailed comparison of training time to prior work.)