向量量化如何影響存儲？與RaBitQ兩位作者，從與谷歌TurboQuant學術爭議聊起

圖片來源@unsplash

2026年3月25日，Google Research官方博客公布的一篇學術論文引起了軒然大波：TurboQuant作為一項向量壓縮算法宣稱可將大模型KV Cache內存占用減少6倍，引發內存股當日集體大跌。但隨后，TurboQuant陷入學術不端風波：涉嫌隱瞞核心技術借鑒、錯誤貶低先行研究、在實驗中進行極度不公平的硬件對比，并且早在一年前arXiv上公布預印本時，在明知存在大量事實性錯誤的情況下，依然投稿到今年的ICLR學術頂會。

其作者團隊曾在此期間做出公開澄清，但實際上并沒有正面回應上述問題。隨著輿論的發酵，TurboQuant事件引發了更多研究者和業內人士的評論和譴責。

而該起事件中的另一方RaBitQ作者團隊，在選擇發聲前的更早時間線里：2025年5月，就已經在積極聯絡對方，希望其能夠修正論文事實性錯誤；2025年11月，通過官方渠道聯系ICLR 2026 PC Chairs；2026年3月公開發聲前再次與PC Chairs發出請求，希望對其進行正式的學術道德審查等訴求。

4月初，我們聯系到了RaBitQ論文兩位作者，并第一時間與之進行了深入交流：

一位是新加坡南洋理工大學計算與數據科學學院副教授，也是VectorDB@NTU的負責人龍程。

一位是蘇黎世聯邦理工學院從事博士后研究的高健揚，他此前跟隨龍教授攻讀博士學位，是VectorDB@NTU最早從事向量量化與向量檢索研究的博士生，同樣也是RaBitQ的第一作者。

訪談中，高健揚提到：在谷歌官方博客發布后，曾第一時間選擇給TurboQuant所有的作者團隊再發郵件，要求其進行更正。但當時收到了第一作者Amir Zandieh比較強硬的回復。“他們不僅不愿意在谷歌博客更正這兩個方法的相似性，并且只同意在ICLR 2026會議結束后才會修正論文。錯誤的事實已經大規模傳播了，這種以冷處理的方式我們無法接受?！?/p>

而后又等待了一天，在沒有得到其他作者回復尤其是最后一位作者（谷歌副總裁Vahab Mirrokni）的回復后，高健揚選擇了公開發聲。

與此同時，我們注意到自2017年Faiss庫和HNSWlib開源后，向量檢索一直以HNSW圖索引、IVF倒排索引兩大方向為主要演進路線，而向量壓縮算法RaBitQ在2024年被提出并開源后，則將向量檢索引入一個新的階段。

目前RaBitQ已經得到多個版本演進，包括重構代碼及開源RaBitQ Library，并且被20多家國內外互聯網大廠和數據庫廠商引入其向量產品中。而在向量檢索之外的更多場景，例如現階段備受業內關注的大模型KV Cache量化等工程解法，RaBitQ依然存在可拓展的空間。

在這場小團隊與大公司的公開較量中，輸贏暫無定論，但我們看到了一個做基礎性且具有奠基價值的科研工作者的學術智慧、底氣與堅守。

以下是本次獨家對話內容，文字有精簡：從LSH到HNSW、IVF，再到PQ，RaBitQ已經做到理論上的最優誤差

Q：兩位老師可以先介紹下自己。以及講講您過去在向量數據庫的向量量化/壓縮技術改進所做的相關研究。

龍程：我是龍程，現任新加坡南洋理工大學計算與數據科學學院副教授，也是VectorDB@NTU的負責人。過去幾年，我們在向量數據庫方向開展了一系列研究工作。

具體來講，我們在2023年發表了“ADSampling”的工作，旨在提升向量數據庫中兩個向量間距離計算算子的速度。隨后，我們設計出了RaBitQ向量壓縮算法，成果發表在數據庫頂會SIGMOD 2024和SIMGOD 2025。此后，我們圍繞RaBitQ這一基礎算法，將其與向量數據庫中流行的索引結構（如圖索引或倒排表索引）相結合。2025年發表的新工作“SymphonyQG”，便是圖索引與RaBitQ結合的成果。

近期，我們與英偉達合作，致力于GPU加速場景下的向量檢索，這個成果正在英偉達cuVS向量檢索庫的預審階段。以上是我們在該領域工作的概覽。

高健揚：2021年至2025年期間，我在新加坡南洋理工大學跟隨龍老師攻讀計算機博士，之后前往蘇黎世聯邦理工學院從事博士后研究工作。我是VectorDB@NTU最早從事向量量化與向量檢索研究的博士生，RaBitQ系列也是我的一作成果。

關于工作內容，龍老師已提及幾點。我在此稍作補充或通俗化解釋：RaBitQ的核心目標是解決向量存儲空間占用大的問題。它利用了高維空間中的一些特殊性質，使得在大幅縮減向量存儲空間的同時，仍能保證使用壓縮后的向量進行精確計算。

Q：向量數據庫這個概念，我最開始了解到也是在2022年。當時與Zilliz創始人溝通，也沒有意識到大模型會有今天這么火。最開始大家對這個領域的定義也比較模糊。業內也是在不斷綜合向量數據或AI數據處理的特點，做一些全新的設計和研發。二位老師基本也是在這個時間段進入這個領域。當時無論是學術圈還是工業界，大家處于怎樣的探索狀態？

龍程：向量數據庫雖是近幾年的熱門詞匯，但相關研究可追溯至約30年前，即90年代末期，學術界已開始研究高維數據的近似搜索問題。高維數據在那時本質上就是高維向量。例如，一張圖片可提取諸多特征（如長、寬、顏色等），組合起來便構成一個向量。當時已有此類向量數據，一個比較經典的應用是搜圖：給定一張圖片，在存有大量圖片（每張圖對應一個特征向量）的數據庫中搜索相似圖片。1998年，Piotr Indyk與導師Rajeev Motwani做了一系列解決這類問題的工作，其中局部敏感哈希（LSH）方法是這個領域的典型代表。

大約2014、2015年后，隨著深度學習的普及，出現能夠有效學習各類非結構化數據的表征，即嵌入向量。文字、圖片、音頻、視頻均可通過表征技術轉化為高維向量。此后，業界開始專門開發用于存儲、管理和查詢這些非結構化數據的系統，一開始還沒有專門稱為向量數據庫，而是類似于非結構化數據系統。

這一時期，向量搜索算法也取得一定突破，基于圖的索引（如當前主流的HNSW）以及倒排索引等方法開始涌現。

在工業界，也出現了一些開源的向量搜索引擎，最具代表性的是當時Facebook Research（現Meta）發布的FAISS庫。隨后在2022年底ChatGPT的出現，檢索增強生成（RAG）技術開始流行。RAG的基本思想是在將問題提交給大模型前，先從知識庫中搜索可能與問題相關的上下文信息，結合后再提交給大模型，以期獲得更準確、更具時效性且更少幻覺的答案。

自那時起，向量數據庫在大模型推理pipeline中的重要作用開始被廣泛認識。我記得在2023年美國西雅圖SIGMOD會議期間，許多人在討論向量數據庫。那個時候，各類向量數據庫，包括開源的、閉源的、基于通用數據庫擴展的、專門針對向量數據開發的系統大量涌現。

我們團隊則是在2021年底，即ChatGPT發布前約一年，進入這個領域。契機是健揚在2021年來南洋理工攻讀博士，我們開始為他尋找博士課題，經過幾個月探索后確定了向量搜索方向，覺得還挺有研究價值。不過，當時我們也沒有意識到后面會有如此大的應用前景。

Q：健揚你也談談當時是如何確定這個方向的？是突發奇想，還是受到某些論文啟發，認為向量搜索具有研究價值？

高健揚：當時促使我們做出決定主要有三方面因素。最初契機是龍老師推薦了幾篇向量檢索的論文。我們當時在廣泛探索了多個方向，包括AI4DB及一些傳統數據庫理論。但在閱讀向量檢索相關論文后，我感覺這個方向對我來說比之前探索的都更有趣。

第二點，當時雖然沒有ChatGPT，但AI已非常火熱。自2012年AlexNet起，計算機視覺和自然語言處理領域成果井噴且在實際生活中已有大量應用。當時的想法是，既然所有AI模型都將非結構化數據表示為向量，那么對向量數據的研究，無論針對何種任務，在未來都至關重要。

第三點，我本人是數學背景，相比于其他方向，高維向量相關問題背后的數學結構更為干凈、漂亮，可能更容易獲得可分析、可證明的理論結果。這一點與我的個人背景和興趣相契合。所以，在多種因素共同驅使下，我們開始了對向量數據庫的研究。

Q：確實，RaBitQ的提出也顯示出在數學領域的理論證明。我們具體聊聊向量數據庫。例如，大模型火熱后，業界可能關心內存占用大、加速效果不理想、召回率較低等問題，難以解決所謂的“不可能三角”。當時，業內對向量數據庫的瓶頸（如內存）最早有哪些解決方案？后來出現了哪些改進思路？

高健揚：解決方案主要分兩類：算法層面和系統層面。

算法層面的話，主要是向量量化。這個領域最早采用標量量化，其做法非常簡單，即將實數舍入為一個有限精度的整數。之后在2010年左右，出現了乘積量化（PQ）方法。相比于標量量化，這個方法針對特定輸入數據集設計具體的量化碼本，在實踐中表現非常好，在很長一段時間內是向量數據庫（或向量壓縮領域）的事實標準。隨后便是RaBitQ。相較于PQ等方法，其主要創新在于利用隨機旋轉（Johnson-Lindenstrauss變換），結合高維空間中的特殊性質，獲取“免費”信息以提高向量量化的精度。按我的理解，RaBitQ現已成為向量數據庫的主流方案，已在超過20家公司的真實系統中得到大規模部署。

而在系統層面，為節省內存，一個自然的思路是不將所有數據存于內存，而是存儲于硬盤等其他介質。這個方向的典型代表是微軟的DiskANN工作。其核心思想是：原始向量存儲于內存成本高昂，所以將其存于硬盤，同時在內存中存儲壓縮后的向量用于檢索。

這兩方面大體概括了當前向量數據庫解決內存瓶頸的主要途徑。

Q：技術演進節奏還是比較快的。RaBitQ提出至今，你提到已有超過20多家數據庫廠商和互聯網企業作為重要技術引入，從你的角度看，原因有哪些？是否注意到或總結過具體的行業場景？

龍程：我先嘗試回答為何RaBitQ在工業界如此流行并被眾多公司采用。我覺得至少有以下幾方面原因：

首先，RaBitQ相較于之前的乘積量化、標量量化，具有理論保障。所有量化都會產生誤差，RaBitQ可以給出這個誤差的界。在相同壓縮率下，其誤差界是在最壞情況下能達到的最優保證。而之前的PQ等方法完全沒有此類保證。在工業界，缺乏保證的技術會帶來不安全感。只憑經驗，可能在某些數據集上有效，在另一些上則無效，且無法預知在新數據集上的表現。

RaBitQ則沒有這個問題，這在向量搜索中提供了重要保障。再講細一點，RaBitQ支持層次化處理。例如，可先將每個向量壓縮至4-bit。檢索時并非一開始就使用全部4-bit估算結果，而是先使用1-bit。由于1-bit運算更快，且有其對應的誤差保證。如果根據這個保證可解決問題或排除答案，則無需使用剩余3-bit，過程即可終止。僅在1-bit無法解決時，才引入剩余3-bit進行增量計算。這種二階段計算范式非常具有性價比，是先前算法無法實現的。

第二個優勢是這個方法實現相對簡單?？梢哉f很干凈：先進行隨機旋轉，如果是32倍壓縮，則可以取正負號；如果是更多-bit，則可以在網格上取整。內部操作簡潔，易于實現，且與CPU的并行特性兼容良好，上手容易。

第三個優勢是大家特別關心的：實際效果到底好不好？實際上，眾多公司在不同業務場景、不同數據上的測試表明，其效果穩定。由于我們的保障不依賴于具體數據，對數據不做任何假設，因此泛化性極佳。RaBitQ并非基于特定數據特性設計的方法，所以能在多種數據集上取得良好效果。

截至目前，采用的企業包括許多大型廠商，如Meta、Apple、微軟；國內則有字節、騰訊、阿里、螞蟻等，它們均有向量搜索的需求，因此都實現或采用了RaBitQ。

在開源生態中，包括Milvus、VectorChord、Elasticsearch、OpenSearch以及其他一些國內外公司，也都采用了RaBitQ。

具體行業方面，由于RaBitQ的研發初衷確實是向量搜索，因此上述企業及其產品主要聚焦于向量搜索領域，如RAG、推薦等。但我相信RaBitQ的應用可更廣泛，包括接下來可能討論的KV Cache量化，大模型權重量化，我認為也極具前景，我們也在探索這個方向。

任何需要壓縮空間、提高速度的場景，均可應用RaBitQ

Q：那么提到KV Cache及大模型參數層面的量化，能否具體展開講講？具體來講，向量的量化和壓縮技術都有哪些區別？比如我們現在會提到在權重壓縮和KV Cache的量化壓縮，又有哪些具體需要區別的？

龍程：我想這個問題可能包含兩部分。一是你提到的“量化”和“壓縮”聽起來相似，那么有什么區別？二是“權重壓縮”和“KV Cache壓縮”或量化，有什么具體區別？

嚴格來講，“壓縮”是目的，“量化”是方法，“量化”是“壓縮”算法的其中一種類型，這兩個術語側重點不同。簡單來說，“量化”通常指用低精度的數值表示去近似高精度的數值表示，更強調數值表示的離散化。壓縮更強調最終系統資源減少。

第二部分，“權重壓縮”即大模型權重的壓縮，以及“KV Cache”的壓縮。相同點在于，它們都是向量。權重是向量（如權重矩陣由眾多向量堆疊而成），KV Cache也是（每個token的key和value均為向量）。它們都是向量，所以都有量化需求。

量化目標在于減小大模型尺寸，使其能在更低配置的GPU上運行。KV Cache量化同樣有需求，且都需要保證：量化后，基于量化數據進行的計算，其結果與量化前的結果相差不應過大，以確保準確性。

兩者可能的不同之處在于：大模型權重數據相對靜態。模型訓練完成后，你可以用它跑很多遍，反復用于各種查詢，參數保持不變，除非需要重新訓練新版本模型。否則大模型權重不會產生變化。這個場景下的量化類似于離線量化。

而KV Cache則不同，每個查詢都會產生新的KV，數據動態性強，更類似于在線量化場景。

因此，針對權重量化，就我目前看到的論文傾向于利用數據自身特點，可能使用一些校準數據輔助量化任務，不僅考慮矩陣（向量）本身，還考慮其具體應用場景。而KV Cache因變化較大，不同查詢差異顯著，所以較少使用校準數據。因為更換查詢后，校準數據可能完全失效，難以考慮KV Cache之外的因素。如果將RaBitQ用于此場景，我們實際上無需校準數據，可直接進行KV Cache量化。

高健揚：把這件事講得更通俗一點：權重是向量，KV Cache是向量，向量數據庫中的向量也是向量。一個通用的向量壓縮算法，理論上可以在完成一定系統層面的適配之后應用于所有存在向量的場景。

Q：如果具體討論RaBitQ在KV Cache量化壓縮中的應用，企業或廠商如果想進一步采用，需要進行哪些改進？

高健揚：當前的RaBitQ相比最初版本已演進許多。現在如果想使用RaBitQ，我首先建議企業嘗試RaBitQ Library中提供的版本。這個庫集成了我們現有的更好的旋轉算法、量化算法，以及在現代GPU、CPU上的具體實現。如果想在KV Cache場景應用，最好采用RaBitQ最新的技術，以最大化其效率。

龍程：RaBitQ Library是我們團隊基于RaBitQ論文和算法自主開發的開源庫，集成了可能更快的隨機旋轉算法、量化算法的新變種，以實現更好效果。

Q：關于RaBitQ，2026年還有哪些方向的探索？

龍程：關于RaBitQ，我認為可能分兩部分。一部分仍在向量數據庫領域，我認為還有許多探索空間。如前所述，RaBitQ是一種向量量化方法，可壓縮空間并提高速度。任何需要壓縮空間、提高速度的場景，均可應用RaBitQ。因此，它可以與向量數據庫中各種不同的向量搜索索引（如圖索引、IVF）結合。這種結合仍有空間做得更好，這是這個方法的一個方向。

當前大家研究較多的是經典場景：每個對象有一個向量，查詢對象也是一個向量，即用一個向量搜索一個向量。但在現實應用中，其實存在多種方式。例如，可結合其他標量信息進行搜索（如混合向量搜索）；或流式場景，向量非一次性全部到位，而是持續流入并實時搜索。

此外，軟硬件環境也存在多種情況。數據可全存于內存，數據量較大時，也可將部分數據存于硬盤，甚至遠程存儲。計算環境方面，有時僅有CPU，有時兼具CPU與GPU。事實上，我們從去年下半年開始與英偉達在此方向合作，一項成果是基于RaBitQ的索引，將集成至英偉達的cuVS庫中，目前處于代碼審核階段。還可能考慮云環境、分布式計算環境等。向量數據庫領域仍有許多可探索的問題，我們將持續發力。

第二部分，我們想跳出向量數據庫應用場景，探索包括KV Cache、大模型權重量化在內的其他領域?？赡苓€會審視整個機器學習基礎設施棧中，是否有其他環節可利用向量搜索技術進行提升或加速。這一塊探索空間可能更大，對我們而言也更未知，但我們非常有興趣在此方向進行探索。

重構代碼、開源RaBitQ Library，但我們還做的不夠快、不夠好

Q：聊聊RaBitQ背后的一些故事。從這個方法提出至今（2024年至今）已兩年多。此過程中有哪些感受？或者說，是否感受到RaBitQ確實廣受歡迎，因而不斷對方法進行改進，包括開源RaBitQ Library？此過程中經歷了哪些事情？

高健揚：這個過程經歷還是蠻豐富的，相對來說比較偏學術界之外。學術方面，我們未經歷太多波折。2023年初，我們內部完成RaBitQ工作，做完理論證明和實驗驗證后，其實我們內心已比較有底。后續的論文投稿、發表，很大程度上是水到渠成的過程。

但在學術界之外，發布RaBitQ論文和代碼后，相當短的時間內便有公司跟進，他們會利用我們的代碼進行測試或部署。我們與其中絕大多數公司都有非常愉快的交流，甚至后續合作。也有個別公司將RaBitQ用于其自身產品，但在媒體宣傳時，對RaBitQ算法的描述做了微調，更改了名稱，并聲稱是其自身創新。

我們與許多公司有接觸、交流、合作，這個過程中也收到許多意見或建議。其中一個對我們改變較大的點是，我們發現大部分公司相比于學術論文中的理論嚴謹性，更在乎現實實現的效果。當然兩者兼具最好，但如果需選擇，他們會選擇現實效果。這一點驅使我們重構了RaBitQ代碼，以及后續開源RaBitQ Library。具體而言，在重構代碼及后續開源過程中，我們融入了許多實際效率更高的近似算法，以及更適合當前系統的實現。這可能是此過程中我們的主要改變和收獲。

在擁有RaBitQ Library后，我們發現國內外有更多公司能更快地將RaBitQ部署至其產品中，進一步放大了項目影響力。這些可能是一個非常簡單的概述。但現在回顧起來，我認為我們大部分事情：完成RaBitQ工作后，開放代碼、論文，并積極與公司交流，后續開源RaBitQ Library，在后看來都做對了。當然另一點是，在回頭看這件事，我覺得我們可能做得還不夠快、不夠好。

Q：有哪些方面覺得做得不夠快？是因為人單力薄，尚未形成更大團隊、開源社區或商業公司？

高健揚：我覺得“人單力薄”這個詞非常準確?？傮w而言，我們仍是學術界中一個非常小的團隊。團隊中可能只有龍老師一位教師，加上幾名學生，這便是我們擁有的全部人力。在此條件下，要求我們編寫工業級別的大型系統，確實比較強人所難。

Q：是否有想法做成像Databricks這樣的公司？其創始人經歷也是從開源到商業化公司。

高健揚：我個人感覺比較困難。一方面，當前環境與Databricks當年完全不同；另一方面，具體技術而言，RaBitQ是一個更核心、更精巧的算法，而Databricks是系統層面的創新。據我理解，系統層面的研究更有可能帶來商業上的壁壘，而RaBitQ這樣的算法研究可能更適合在更多的系統中發揮它的價值。

龍程：健揚提到RaBitQ是一個較小的算法，我也要提一句，這個算法較為底層，實際上可與不同索引結合，發揮更大價值。

拋開現實因素，僅從技術角度看，例如圍繞RaBitQ開發不同索引，搭建系統，或者在存儲方面圍繞RaBitQ開展工作，我認為具有可行性。但問題在于，當前已有大量向量數據庫，如果我們再重新開發一個，缺乏差異化優勢，市場已較擁擠。除非后續我們找到新出口，它不僅僅是向量數據庫，可能是一個更大場景，且那時這個場景玩家不多，我認為可以暢想。但如果局限于向量數據庫領域，可能確實特別困難，因為時機已過，同類產品過多。

向量量化的進步，并不意味著存儲需求會減少，但也必須由更多硬件來應對

Q：存儲這件事情，從硬件層面優化的進程和優勢會比較明顯嗎？

高健揚：當前情況是假設有固定總量的存儲需求，我們想以更低成本滿足。有兩個途徑：硬件途徑與軟件途徑。軟件途徑指設計新的模型架構、新的向量量化算法以降低存儲開銷；硬件途徑則是生產更多硬件。

據我理解，像RaBitQ這樣的方法，已做到理論上的最優。即在相同誤差情況下，向量量化的壓縮率本質上已不可能比RaBitQ更好。因此，在軟件層面，我認為向量量化已發展至瓶頸，甚至達到天花板，沒有繼續優化的可能。這反而意味著，后續存儲需求的增長，必須由更多硬件來應對。我個人認為，向量量化技術的進步，并不意味著存儲需求會減少。相反，它意味著未來除了使用更多硬件進行存儲，我們別無他法。

我們還觀察到，許多團隊正嘗試使用其向量數據庫來管理大模型的KV Cache。在這種意義上，未來對KV Cache的管理也可能像數據庫一樣，具備多級存儲（包括遠程存儲、本地硬盤、內存等）。這兩個方向目前呈現合流趨勢。

相關鏈接： https://zhuanlan.zhihu.com/p/2020969476166808284 https://x.com/Tim_Dettmers/status/2041497412989071707 相關arxiv鏈接： RaBitQ(1-bit)：https://arxiv.org/pdf/2405.12497 RaBitQ(multi-bit):https://arxiv.org/pdf/2409.09913 RaBitQ Library:https://github.com/VectorDB-NTU/RaBitQ-Library

（本文作者 | 楊麗，編輯 | 楊林）