Response to "more comments"
We are glad that the reviewer shows interest in our work and do our best to answer further questions:
> Regarding subspace selection, how do you do the code updates in a tractable way after selecting the subspace? Perhaps I am missing something, but this is still a discrete optimization problem after subspace selection, just a much smaller one. Is the "naive solution" that searches over all combinations cheap enough to do here?
In general (for VQ), we do an exhaustive search for each code in the chosen subspace, but **not all combinations**. This is because our Linearized V step (Section 3.2) minimizes mean squared error with the adjusted weight matrix (Equation 5). This problem can be solved independently for each discrete code because the optimization objective is a sum over independently chosen discrete weights.
Still, this can be a costly procedure for LLMs with billions of parameters. However, it *becomes cheap since we only update a small fraction of codes*, i.e. the subspace. Thus, we run this costly optimization (1) for less than 1% of all weights and (2) in parallel on GPUs, making it practically feasible.
In the supplementary code, the discrete optimization takes less than 10% of the total training time when running on A100s. However, further improvement of this algorithm is an interesting direction for future research.
> Your main rebuttal said there were more experiments here with smaller codebooks, but I'm not seeing any. Did you forget to post part of the response? I'm interested in seeing how PV-tuning would work with a structured codebook, such as one that has sign symmetry. The 8-bit codebook result in the paper performs around the same as QuIP#, so it does appear that the quantizer quality still has an impact after PV-tuning.
We thank the reviewer for finding this out, as this is an important suggestion. We accidentally did not include these numbers when compiling the response. You may find our response below:
We conducted additional experiments using this configuration for Llama 2 7B in the same setup as the rest of our experiments (see Section 4.2). Specifically, we use a single 10-bit codebook with a group size of 8 consecutive weights, which leads to **1.26 bits per weight**, including codebooks. The resulting quantized model has a perplexity of 6.82 on WikiText-2 and 8.82 on C4. We compare these results with the previous configuration below:
| Method | Avg Bits | Wiki2 $\text{PPL}\downarrow$ | C4 $\text{PPL}\downarrow$ | ArcC $\text{Acc.}\uparrow$ | ArcE $\text{Acc.}\uparrow$ | HellaSwag $\text{Acc.}\uparrow$ | PiQA $\text{Acc.}\uparrow$ | WinoGrande $\text{Acc.}\uparrow$ | Average $\text{Acc.}\uparrow$ |
|---|---|---|---|---|---|---|---|---|---|
| $-$ | 16 | 5.12 | 6.63 | 43.43 | 76.3 | 57.14 | 78.07 | 69.06 | 64.80 |
| PV-Tuning | 1.58 | 7.32 | 9.35 | 25.85 | 57.58 | 40.88 | 68.99 | 57.77 | 50.21 |
| PV-Tuning (10-bit codebook) | 1.26 | 6.82 | 8.82 | 32.94 | 68.27 | 49.01 | 74.76 | 64.17 | 57.83 |
**These are very promising results.**, we originally opted for 8- and 16-bit codes as they are easier to handle in modern hardware, but in principle, it is possible to pack 10-bit codes in a way that supports efficient inference. Following your suggestion, we will evaluate more configurations with small codebooks in the final version. Likewise, we will further explore structured codebooks as the reviewer suggested.
> FP16 @ 3 bits just means if you plotted the FP16 perplexity numbers assuming the models were 3/16th the size. This represents what a lossless 3 bit model would achieve. Otherwise, if the 3 bit version of your quantizer just happens to be bad, then it would be very easy to outscale that.
Thank you for clarifying this. By this upper bound criterion, the Pareto-optimality would indeed be achieved at a somewhat higher bitwidth. In our submission, we used a popular criterion from prior works, but your upper bound criterion could bring more nuance to the Pareto-optimality. We will add the comparison to FP16 @ 3 bits in the final version of the paper.