Technical clarification on TurboQuant / RaBitQ for people following the recent TurboQuant discussion

Reddit r/LocalLLaMA / 3/30/2026

💬 OpinionIdeas & Deep AnalysisModels & Research

Key Points

  • The author Jianyang Gao (first author of the RaBitQ papers) posted a public technical clarification in response to rising community discussion of TurboQuant on r/LocalLLaMA, aiming to correct confusion about TurboQuant’s relationship to RaBitQ.

I am Jianyang Gao, first author of the RaBitQ papers. I am posting this here because TurboQuant is now being discussed in `r/LocalLLaMA` in the context of local inference / KV-cache compression, and I think the community should have a technically precise comparison on the public record.

We are posting this comment to create a public record because the public discussion and promotion of TurboQuant have already created substantial confusion about its relationship to our RaBitQ line of work [1, 2]. These issues and explanations were not raised for the first time. In January 2025, Majid Daliri, the second author of the paper, contacted us to debug his Python translation of our RaBitQ implementation. In May 2025, after we came across their TurboQuant paper on arXiv, we raised the concerns below directly with him in detail. Despite that notice, the authors retained the inaccurate statements in their ICLR submission. Recently, on March 26, 2026, we formally notified all authors again. However, they agreed to fix only part of these issues and only after the ICLR 2026 conference takes place, which we believe is insufficient to dispel the widespread misunderstanding created by their recent promotion and may instead create further confusion at the ICLR meeting itself.

Our concern has three parts.

  1. Method-level description of RaBitQ is materially incomplete. TurboQuant repeatedly describes random rotation as a key step of its method, yet its description of RaBitQ reduces mainly to a grid-based PQ framing while omitting the Johnson-Lindenstrauss transformation / random rotation, which is one of the most important linkage between the two methods. Moreover, even after two reviewers asked for clarification and discussion of the Johnson-Lindenstrauss transformation / random rotation, the ICLR camera-ready version of TurboQuant still did not add such a discussion; instead, the original description of RaBitQ in the main body was moved to the appendix.
  2. The theoretical description is not supported. TurboQuant described RaBitQ's guarantees as "suboptimal" and attributed this to "loose analysis" without any explanations, although our paper [2] posted in September 2024 had already clearly claimed asymptotic optimality, which matches the optimal bound by Alon and Klartag [3]. Even after this issue was explicitly raised and clarified in emails in May 2025, the authors still do not provide a systematic explanation of how TurboQuant's guarantees compare to the RaBitQ line in their ICLR submission.
  3. The empirical comparison also lacks full disclosure. Majid's January 2025 emails show that he had translated our C++ implementation of RaBitQ into Python and asked us to help debug it. In May 2025, he further acknowledged that, in the reported runtime setting, the RaBitQ baseline was run on a single CPU with multiprocessing disabled. The TurboQuant method itself is run on an A100 GPU. Yet the public paper makes efficiency claims without clearly disclosing that experimental setup. This issue was also raised in our private emails in May 2025.

In May 2025, our emails directly raised the theoretical and empirical issues; Majid wrote that he had informed his co-authors. During ICLR review, reviewers also asked for clarification about random rotation and the relation to RaBitQ. On March 26, 2026, we formally raised these concerns again to all authors and were told that corrections would wait until after the ICLR 2026 conference takes place; we were also told that they would not acknowledge the structural similarity regarding the Johnson-Lindenstrauss transformation. We do not consider that acceptable given the present level of public promotion and community confusion.

We are posting this comment so that the community has an accurate public record. We request that the authors publicly and promptly clarify the method-level relationship between TurboQuant and RaBitQ, the theory comparison, and the exact experimental conditions underlying the reported RaBitQ baseline. Given that these concerns were known before ICLR submission and before the current round of public promotion of TurboQuant, we believe it is necessary to bring these issues into the public discussion.

Public OpenReview thread: https://openreview.net/forum?id=tO3ASKZlok

References

[1] Jianyang Gao and Cheng Long, "RaBitQ: Quantizing High-Dimensional Vectors with a Theoretical Error Bound for Approximate Nearest Neighbor Search," Proceedings of the ACM International Conference on Management of Data (SIGMOD), 2024.

[2] Jianyang Gao, Yutong Gou, Yuexuan Xu, Yongyi Yang, Cheng Long, and Raymond Chi-Wing Wong, "Practical and Asymptotically Optimal Quantization of High-Dimensional Vectors in Euclidean Space for Approximate Nearest Neighbor Search," arXiv:2409.09913, Sep. 2024; later published in SIGMOD 2025.

[3] Noga Alon and Bo'az Klartag, "Optimal compression of approximate inner products and dimension reduction," 2017 IEEE 58th Annual Symposium on Foundations of Computer Science (FOCS), IEEE, 2017.

submitted by /u/gaoj0017
[link] [comments]