turbovec这两天冲上了GitHub热榜。README开头两句话很直白:一千万文档的float32语料要占31GB内存,turbovec能把它压进4GB;检索速度还比FAISS的IndexPQFastScan快——4-bit量化平均快3.4倍,2-bit快23%。数字很漂亮,漂亮到值得多问一句:这两组数字,是不是同一次测试跑出来的?
答案是不是。31GB→4GB是按16倍压缩率做的存储换算示意,对应1536维向量在2-bit下的理论压缩比;3.4倍/23%那组速度数字,来自另一次独立测试——10万向量、1000次查询、k=64的SIMD基准。规模差了两个量级,测的也不是同一件事:一个算存储账,一个算查询延迟账。README把它们并排放在同一屏,很容易让人脑补成"千万文档规模下也能保持三倍多的速度优势",这件事目前没有任何证据支持。
算法是新的,论文刚过没多久
turbovec不是凭空造的轮子,它照着Google Research提出的TurboQuant算法实现——核心思路是随机旋转加固定标量量化,不用像传统PQ那样先离线训练码本,语料变大也不用重训。这篇论文刚被ICLR 2026接收,给出的理论保证是:失真大约是信息论下界的2.7倍。"near-optimal"是"接近最优",不是"零误差"——量化必然有损耗,论文只是证明了这个损耗有上限。
Google官方对TurboQuant的实测重心,其实压在另一个场景:LLM的KV-cache压缩。官方博客给出的数字是,精度降到3-bit左右,在needle-in-a-haystack评测里做到至少6倍内存缩减,H100上attention-logit计算最高提速8倍——这个加速来自内存带宽节省,不是算力本身变快。这是一套完整评测,场景、数据集、准确率指标全部摆出来了。
分架构拆开看,数字更碎
首页汇总的"3.4倍/23%"其实是均值。分架构看,ARM上4-bit平均快3.5倍、2-bit快26%;x86上4-bit平均快3.4倍、2-bit快20%,2-bit这一档在x86上跨度更大。数字没错,但越拆越碎,说明这套加速比会随硬件、维度、比特宽度明显波动,不是一个可以直接照搬到任意生产环境的固定倍数。
速度数字之外,没人给出召回率
量化的本质是拿失真换压缩——把32位浮点压成2位或4位整数,信息必然有损,损耗多大,直接决定这套索引能不能用在真实检索里。衡量这个损耗的标准指标是recall@k:同样一次查询,量化后的索引能找回本该出现的结果的比例。
turbovec的README里,速度、内存、并发、增量持久化都讲了,唯独没有一张recall@k对比图。Google自己在博客里对向量检索场景做过评测,用的是GloVe(200维)数据集,拿1@k召回率去比TurboQuant和PQ、RaBitQ这类基线——说明这件事能测、也该测,只是turbovec没把这块补上。
量化是拿失真换压缩,不报召回率,只报了收益,没报代价。
该谨慎的是谁
目前能查到的所有性能数字,来源只有两处:项目作者自己的README,和Google官方博客里关于KV-cache场景的实测。检索不到任何第三方对turbovec或TurboQuant在检索任务上的独立复现,它的真实检索准确率,现在只能算未知。
- 风险.隐私敏感的RAG部署方——医疗、金融、政务这类必须本地化跑向量检索的场景——如果直接拿它替换FAISS,相当于在准确率没验证的情况下上生产。
- 结论.免训练、超快、超省内存这套叙事本身站得住,但要不要现在就换,还得等recall@k数据和独立复现补上再判断。
一个刚被ICLR接收的算法,一个人在短时间内工程化实现,GitHub页面已经挂着不小的星标数——这本身也是个值得留意的信号:社区验证的速度,是不是已经跟不上关注度涨起来的速度。接下来最该盯的不是它还能再快多少,而是有没有人先把召回率这道题做完,再谈换不换。