前幾天，Google Research 在 X 平臺正式釋出了名為 TurboQuant 的 AI 壓縮演算法，24 小時內瀏覽量破千萬，儲存晶片股當天集體收跌，Cloudflare CEO Matthew Prince 甚至將其稱為 Google 的「DeepSeek 時刻」論文。
但就在剛剛，蘇黎世聯邦理工學院博士後高健揚在知乎發出一封公開澄清信論文。他是論文裡被比較演算法 RaBitQ 的第一作者，指出 TurboQuant 存在三處嚴重問題：
刻意迴避與 RaBitQ 在方法上的直接關聯、在沒有任何證據的情況下將 RaBitQ 的理論成果定性為「次優」、以及在實驗對比中用單核 CPU 跑 RaBitQ、卻用 A100 GPU 跑自己的演算法論文。
更關鍵的是，這些問題在論文投稿前就已透過郵件明確告知 TurboQuant 團隊， 對方也表示知情，卻選擇了不予修正論文。論文隨後被 ICLR 2026 接收，並經由 Google 官方渠道大規模推廣。
質疑並非只來自 RaBitQ 團隊論文。第三方研究者 Jonas Matthias Kübler 也在 ICLR OpenReview 獨立提出了另一層問題：論文中寫速度基準是 PyTorch，部落格推廣時卻換成了 JAX，兩者口徑不一；
展開全文
他還指出部落格以 FP32 作為對比基準論文，本身就有失公允；
高健揚同步在 X 釋出了英文宣告，引發討論論文。有網友也點出了這場爭議的本質：「這些研究者要的是署名和引用，他們並沒有直接說這篇論文的結論是錯的。」這或許也是理解整件事重要的前提。
以下是知乎網友 gaoj0017 （高健揚）的公開信原文論文。
對於 Google 的 ICLR 2026 TurboQuant 論文論文，我們必須公開澄清
大家好，我叫高健揚，目前在蘇黎世聯邦理工學院做博士後，我是 RaBitQ 系列工作的第一作者論文。
Google Research 於 2026 年 1 月被 ICLR 2026 會議接收的論文 「TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate」 中，有關已有的 RaBitQ 向量量化演算法的描述，理論結果對比，實驗對比均存在嚴重問題（詳細情況後文會展開描述）論文。
這些問題在論文投稿至 ICLR 2026 前已被我們透過郵件明確指出，TurboQuant 團隊也明確表示已知情，但選擇了不予修正論文。論文隨後被 ICLR 2026 會議接收，然後透過 Google 官方渠道大規模推廣，在社交媒體瀏覽量已達到數千萬次。
我們此時公開說明，是因為錯誤的學術敘事一旦廣泛傳播，糾正的成本會越來越高論文。
背景論文：RaBitQ 是什麼
RaBitQ 系列論文（如下所列）於 2024 年發表，提出了一種高維向量量化方法，並從理論上證明其達到了理論計算機頂級會議論文（Alon-Klartag, FOCS 2017）給出的漸近最優誤差界論文。
🔗：
RaBitQ（arXiv:2405.12497論文，2024 年 5 月，隨後發表於頂級會議 SIGMOD 2024） 擴充套件版（arXiv:2409.09913，2024 年 9 月，隨後發表於頂級會議 SIGMOD 2025）
RaBitQ 的核心想法之一是在量化前對輸入向量施加隨機旋轉（random rotation / Johnson-Lindenstrauss 變換），利用旋轉後坐標分佈的性質做向量量化，在理論上實現最優誤差界論文。
TurboQuant 論文問題一論文：系統性地迴避 TurboQuant 方法與已有 RaBitQ 方法的相似性
RaBitQ 與 TurboQuant 在方法層面有直接的結構聯絡，兩者都在量化前對輸入向量施加隨機旋轉（Johnson-Lindenstrauss 變換）論文。這是兩篇論文方法設計中最核心、最接近的部分。
論文地址：
TurboQuant 的作者在 ICLR OpenReview 審稿平臺上對審稿人的回覆中論文，親自這樣描述自己的方法：
「We achieve this by first normalizing the vectors by their l2 norm and then applying a random rotation （隨機旋轉）to ensure the entries of the vectors will have a beta distribution post rotation.（我們透過先按向量的 L2 範數進行歸一化，再施加隨機旋轉來實現這一點，從而保證向量各分量在旋轉後服從 Beta 分佈論文。）」
然而在這段回覆、TurboQuant 論文中的方法介紹乃至整篇論文中，從未正面說明這一結構與 RaBitQ 完全一致論文。這一回避發生在以下背景之下：
2025 年 1 月（TurboQuant 論文在 arXiv 釋出的數月前），TurboQuant 論文的第二作者 Majid Daliri 主動聯絡我們，請求幫助除錯他自己基於 RaBitQ C++ 程式碼實現的 Python 版本論文。他詳細描述了自己復現的步驟、程式碼片段和具體報錯，這一點可以說明 TurboQuant 團隊對 RaBitQ 的技術細節有充分的瞭解。
之後在 2025 年 4 月他們在 arXiv 釋出的論文版本，以及 2025 年 9 月他們在 ICLR 2026 會議投稿的論文版本中，他們將 RaBitQ 描述為 grid-based PQ，並且在描述中忽略了 RaBitQ 中核心的 random rotation 的步驟論文。
ICLR 的一位審稿人也在審稿意見中獨立指出：「RaBitQ and variants are similar to TurboQuant in that they all use random projection」，並明確要求更充分的討論和比較論文。
儘管如此，在 ICLR 會議最終版本論文中，TurboQuant 的作者不僅沒有加入對 RaBitQ 討論，甚至反而還將原本正文中對 RaBitQ 不完整描述移到了附錄中論文。
為此論文，我們於 2026 年 3 月透過郵件聯絡了 TurboQuant 所有作者，提出了以上問題及糾正請求後，TurboQuant 作者在回覆中以
The use of random rotation and Johnson-Lindenstrauss transformations has become a standard technique in the field, and it is not feasible for us to cite every method that employs them.(隨機旋轉和 Johnson-Lindenstrauss 變換已經成為該領域的標準方法論文，因此我們無法逐一引用所有采用這些方法的研究)
為由拒絕了這一請求論文。
我們認為這一回應是在轉移矛盾：作為在相同問題設定下率先將隨機旋轉（Johnson-Lindenstrauss 變換）與向量量化結合、並建立最優理論保證的具體先行工作，RaBitQ 應當在文中被準確描述，其與 TurboQuant 方法的聯絡應當充分討論論文。
TurboQuant 論文問題二論文：錯誤描述 RaBitQ 的理論結果
TurboQuant 論文在不提供任何論據的情況下，將 RaBitQ 的理論保證定性為「次優」論文。TurboQuant 論文寫道：
「While the paper’s theoretical guarantees are suboptimal, likely due to loose analysis — as practical performance surpasses theoretical bounds（儘管論文給出的理論保證還不是最優的，這很可能是因為分析較為寬鬆——因為實際表現已經超過了理論界限論文。）」
這句話直接將 RaBitQ 的理論保證定性為「次優（suboptimal）」，將原因歸結為「較粗糙的分析（loose analysis）」論文。但論文沒有提供任何推導、對比或證據來支撐這一判斷。
事實是：我們在拓展版 RaBitQ 論文（arXiv:2409.09913）的 Theorem 3.2 中，已經嚴格證明 RaBitQ 的誤差界達到了理論計算機頂級會議論文（Alon-Klartag, FOCS 2017）給出的漸近最優誤差界論文。
因為這一結果，我們被邀請至理論電腦科學頂級會議 FOCS 的 Workshop 進行報告論文。
為此，我們於 2025 年 5 月透過郵件與 TurboQuant 的第二作者 Majid Daliri 進行了多輪詳細的郵件技術討論，逐條澄清了 TurboQuant 團隊對我們理論結果的錯誤解讀論文。Majid Daliri 在郵件中明確表示已將這些討論告知全體共同作者。
然而後面 TurboQuant 論文在提交至 ICLR 2026、經過審稿、被接收，最終大規模宣發的全過程中，這個對 RaBitQ 理論保證的錯誤定性始終未被修正論文。
一個沒有證據支撐的斷言，在被原作者具體指出錯誤、且 TurboQuant 作者方已明確知情的情況下，仍被保留在正式發表的 TurboQuant 論文中，我們認為這已超出普通失誤的範疇論文。
TurboQuant 論文問題三論文：刻意創造不公平的實驗環境
TurboQuant 論文使用劣化的實現、關閉多執行緒使用單核 CPU 測試 RaBitQ 的效果，卻使用 A100 GPU 測試 TurboQuant 的效果論文。
TurboQuant 報告的 RaBitQ 量化速度比我們開源實現的實際速度慢了數個數量級論文。 2025 年 5 月的郵件中，Majid Daliri 本人解釋了這一差距的來源：
「we were using a single-core CPU instance, and multiprocessing was indeed disabled […] we weren’t fully utilizing parallelism, which explains why it was significantly slower（我們當時使用的是單核 CPU 例項，而且確實停用了多程序……我們沒有充分利用並行能力，這也解釋了為什麼它會明顯更慢論文。）」
我們的官方 RaBitQ 程式碼在論文釋出至 arXiv 時（2024 年 5 月與 2024 年 9 月）就已經公開，並且預設採用多執行緒並行論文。並且，Majid Daliri 在 2025 年 1 月的郵件中還說明，他成功跑通 RaBitQ 的程式碼用以測試，但他用於實驗的仍是自己翻譯的 Python 版本。這意味著，TurboQuant 論文中對 RaBitQ 速度的報告，疊加了兩層系統性的不公平條件：
1.使用自己翻譯的 Python 程式碼論文，而非我們開源的 C++ 實現
2.用單核 CPU論文，關閉多執行緒並行測試 RaBitQ 演算法，但卻使用 NVIDIA A100 GPU 測試 TurboQuant 演算法
以上兩點均未在論文中充分披露論文。讀者看到的是 RaBitQ 比 TurboQuant 慢數個數量級這一結論，卻無從知道這一結論建立在刻意創造的不公平的實驗條件之上。
事件完整時間線
2024 年 5 月：RaBitQ 論文在 arXiv 釋出論文，同時原始碼公開（後面發表在頂級會議 SIGMOD 2024）
2024 年 9 月：拓展版 RaBitQ 論文在 arXiv 釋出論文，同時原始碼公開（後面發表在頂級會議 SIGMOD 2025）
2025 年 1 月：TurboQuant 論文第二作者 Majid Daliri 聯絡我們論文，請求協助除錯 Python 版 RaBitQ 實現
2025 年 4 月論文：TurboQuant 論文在 arXiv 釋出
2025 年 5 月：我們跟 Majid Daliri 透過郵件詢問了實驗條件的差異並清楚解釋了 RaBitQ 的理論保證最優性論文， Majid Daliri 表示他已告知全體作者，但在我們要求修正 TurboQuant 論文中的事實性錯誤之後，Majid Daliri 停止回覆
2025 年 11 月：我們發現 TurboQuant 論文被提交至 ICLR 2026 會議論文，且論文中的事實性錯誤並未修正，為此我們聯絡了 ICLR 2026 PC Chairs，未獲回應
2026 年 1 月：TurboQuant 論文被 ICLR 2026 接收 2026 年 3 月：TurboQuant 團隊透過 Google 官方渠道持續推廣論文，社交媒體相關瀏覽量已達數千萬次
2026 年 3 月：我們正式向 TurboQuant 全體作者傳送郵件，闡述以上三個事實性問題並要求做出修正及澄清論文。截至目前為止，我們僅收到 TurboQuant 論文第一作者 Amir Zandieh 的籠統答覆，承諾會修正問題二和問題三，但拒絕修正問題一（即討論 TurboQuant 與 RaBitQ 在技術上的相似性）。並且，他們僅願意在 ICLR 2026 正式會議結束之後才做相應修正
我們已經做了什麼
在 ICLR OpenReview 釋出公開評論:
向 ICLR General Chairs, PC Chairs, Code and Ethnics Chairs 再次提交正式投訴論文，附完整證據包
我們接下來會做什麼
在 arXiv 釋出詳細的關於 TurboQuant 和 RaBitQ 的技術報告
考慮向相關機構進一步反映
最後
我們提出這些問題，目標是讓公共學術記錄準確地反映各方法之間的真實關係論文。一篇論文被 Google 以數千萬曝光量推向公眾，在這種體量下，論文中錯誤的敘事不需要主動傳播，只需要不被糾正，就會自動成為共識，這也是我們選擇公開記錄的原因。
在此我們也懇請大家讓更多人知道 TurboQuant 論文背後存在的問題，我們相信真理越辯越明論文。
附上原文出處地址論文：
我們正在招募夥伴
📮 簡歷投遞郵箱[email protected]
