九成召回时 21445 QPS，磁盘模式只剩 63：字节 UBASE 把向量检索的吞吐和成本拆开测

九成召回时 21445 QPS，磁盘模式只剩 63：字节 UBASE 把向量检索的吞吐和成本拆开测

字节的系统论文 UBASE: An AI Search Engine for Trillion-Scale Vector Data Management at ByteDance。页面版本是 arXiv 2608.30607v1，水印日期 2026 年 8 月 31 日。许可证是 arXiv.org 的永久非独占许可。作者单位是 ByteDance。

UBASE 是字节从 2016 年用到现在的搜索底座，后来加上向量检索。向量检索指：把文本、图片或视频编成一串数，再找离查询最近的那些条。近似最近邻只保证高概率找对，不保证和精确排序一致。评测要回答的是建索引贵不贵、召回和吞吐怎么换、混合查询质量、月成本，以及内存不够时延迟掉多少。

召回用精确 top-k 当分子，机器按数据规模换

第 7.1 节把指标写死。Recall@k 是返回的前 k 条里，有多少条也出现在精确的前 k 条，再除以 k。NDCG@10 看排序质量，相关的条越靠前越好。数据集有一份内部抽样，外加六个公开集。内部集是客户 D 的 1 亿条向量抽样。正文说客户 D 的全量部署是 3270 亿条量级。公开集：Wiki 100 万条、768 维、余弦；GIST 100 万条、960 维、L2；Cohere 1.13 亿条、1024 维、L2。混合检索质量用 BEIR 里的 NFCorpus、FIQA、Quora。BEIR 是一套跨领域的检索基准。

对照三家，版本写在正文里：Elasticsearch 8.18、Milvus 2.5、PostgreSQL 17 加 VectorChord 1.0。机器是 Intel Xeon Platinum 8457C。UBASE 按 OpenSearch 兼容方式部署：3 个数据节点、2 个协调节点。Wiki 和 GIST 上，数据节点 8 核、64 GB 内存、1 TB 网络存储，协调节点 8 核、16 GB。Cohere 和内部集上，数据节点 24 核、192 GB、2 TB，协调节点 16 核、32 GB。存储走 10 GbE。对照按相近资源配，并用各自推荐参数。默认索引参数放在附录 G，正文没有把每一项 ef、nprobe 抄进第 7 节。

建索引的 80% 是峰值内存，不是查询延迟

表 2 把量化建图和 DiskANN、HNSW 分开。DiskANN 和 HNSW 都是图索引：先连上相近的点，查询时沿边走。DiskANN 用全精度向量建图。UBASE 的 SymRaBitQ 直接在量化后的空间里建图。量化这里指把原来的浮点向量压成更短的表示。

GIST 100 万：DiskANN 587 秒、峰值 3.75 GB；UBASE 194 秒建图加 43 秒量化，合计 237 秒，峰值 0.75 GB。正文写成时间降 60%、内存降 80%。Cohere 1 亿：DiskANN 23826 秒、453 GB；UBASE 11033 加 1463 秒，合计 12496 秒，峰值 90 GB。时间降 48%，内存仍是 80%。表里还有 HNSW 在 Cohere 100 万上的 359.8 秒、4.8 GB，以及 1 亿上的 41946.2 秒、476.19 GB。80% 和 48% 这两句对的是 DiskANN，不是 HNSW。

IVF 是先分桶再在桶里找。GIST 100 万上，普通 IVF 176 秒、峰值 3.7 GB；加上 SymRaBitQ 后 129 秒、1.9 GB，时间降 27%，内存降 49%。后面的检索实验不再报 IVF。

Wiki 上最终索引 1182 MB，是 PostgreSQL 的 29%、Milvus 的 42%。全精度向量不放在热查询路径上，只留在远端做持久化和离线维护。

检索看高召回这一段，因为正文说线上常见目标是 90% 以上。内部 1 亿条上，大约 90% 的 recall@10 时，UBASE 21445 QPS。QPS 是每秒查询数。相对 Milvus 高 9.5 倍，相对 PostgreSQL 高 5.5 倍，相对 Elasticsearch 高 2.3 倍。召回再往上，对照大约在 92% 附近掉下去，UBASE 仍能维持 1 万 QPS 以上。Cohere 上，大约 92% recall@10 时 23013 QPS，相对 Milvus、Elasticsearch、PostgreSQL 分别是 11.7 倍、5.4 倍、3.5 倍。

小集上差距变小，因为大家都能把更多数据留在内存里。GIST 上最多比 PostgreSQL 快 5 倍，比次好的 Milvus 配置快 2 倍以上。Wiki 上大约 87% 召回时接近 25000 QPS，大约 97% 时还有约 15000 QPS。并发 P99 只写了「同样召回下更低」，正文没有给出毫秒数。图注把 QPS–召回标成图 8，把并发 P99 标成图 9；正文有一处把 QPS–召回也写成图 9。

混合查询的涨幅，分母不是更强的那一列

过滤查询是向量加属性条件。图 10 在大约 96% recall@10 上，把选择率从 10% 扫到 99%。选择率越高，满足条件的候选越少，图要走得更远。UBASE 在估计候选少于 10000 时改走先过滤。正文没有给出这张图的 QPS 读数。

表 3 是 NDCG@10。NFCorpus：BM25 0.3040，稠密向量 0.2321，Min-Max 0.3271，RRF 0.3327，Z-score 0.3288。FIQA：0.2386、0.1983、0.2890、0.3071、0.3281。Quora：0.7412、0.7469、0.8189、0.8300、0.8666。BM25 是词频加文档长度的字面检索。RRF 是倒数排名融合，不看原始分，只看名次。融合列都高于单独的 BM25 和稠密列。正文写 Z-score 在 FIQA、Quora 上提高 65.5% 和 16.9%，RRF 在 NFCorpus 上提高 43.3%。这三个百分数对得上「相对稠密列」或「相对较低的那一列」，对不上「相对 BM25 和稠密里更强的一列」。FIQA 上更强的单列是 BM25 的 0.2386，Z-score 的 0.3281 相对它不是 65.5%。

径向搜索按相似度阈值把一片区域里的向量都取回，而不是只取前 k。朴素做法是把 k 设成 1 万、2 万、5 万、10 万，一分钟内跑不完。UBASE 在内部 1 亿和随机 100 万子集上，返回 1 万条都是 140 ms。返回 10 万条时，1 亿规模 3.68 秒，100 万子集 1.2 秒。

同一笔 2790 美元，磁盘模式的 QPS 不是 2 万

表 4 是内部 1 亿条、2048 维的月成本，配置在附录 H。内存模式四家共用每月 2790 美元：Milvus 2262 QPS，PostgreSQL 3929，Elasticsearch 9342，UBASE 21445。每百万向量都是 27.8 美元。每千 QPS 的成本分别是 1233、710、299、130 美元。21445 和前面检索实验的 QPS 是同一个数，成本表沿用了这个工作点。

磁盘模式故意不追峰值吞吐。UBASE 月成本 382 美元，QPS 63，每百万向量 3.7 美元，每千 QPS 6063 美元。3.7 相对内存模式的 27.8，大约是 7.5 分之一，正文的「7.5 倍更低」指的是每百万向量的持有成本，不是每千 QPS。63 QPS 被写成低占空或归档负载，不是在线高 QPS。

单机缓存和三节点集群不是同一套 QPS

第 7.5 节改成单机：48 核、371 GiB，召回固定 90%。GIST 上记录级缓存命中率 97.7%。平均每条查询走过 105.99 条图记录，真正落到 SSD 的是 51.90 次（未命中加预取），DiskANN 是 80.9 次。32 线程时异步执行大约 15000 QPS，约是同步缓存的 1.8 倍、DiskANN 的 2 倍。平均延迟大约 1.7 ms，同步和 DiskANN 大约 3.5 ms 和 4 ms。这 15000 不是前面三节点上的 21445。

缓冲池比例从 0% 加到 100%，线程数固定 12，数据是内部集。0% 时 4163 QPS，10% 时 5381 QPS，约 1.29 倍。100% 时 7701 QPS。5381 大约是 7701 的 70%。中间是单调上升。换比例不用改查询接口，也不重建索引。

第 7.6 节把内部集从 100 万抽到 1 亿，服务配置不动，索引参数按同一个 90% 召回调。QPS 从 24410 降到 22386，大约少 9%。数据节点从 1 加到 10，正文写接近线性，没有给出每一档的 QPS。

第 7.7 节在 Cohere 上跑 30 小时：空索引起，每秒写入 1000 条，读查询同时打。正文写写入速率守住了，查询 QPS 稳定，读写 P99 稳定。没有写出 P99 的毫秒数，也没有写出 QPS 的绝对值。

第 8 节补了一句质量：同一搜索参数下，量化建图的召回损失小于 0.01。这句挂在 GIST 100 万、峰值内存降 80%、时间降 60% 后面，没有按数据集逐个列出召回差。

生产规模在第 2 节：7000 个以上集群，300 PB 以上。客户 E 建图峰值 27 TB，当时 DRAM 预算 13.8 TB，还没给查询缓存留内存。表 1 按客户列了负载类型，HTML 正文没有把每个客户的 QPS 和 P99 展开成数字。图 4 的 P99 同样没有读数。

这些数不能被读成什么

21445 QPS 是受控测试台上、内部 1 亿抽样、大约 90% recall@10 的一个点。它同时出现在成本表的内存模式里。磁盘模式是 63 QPS。不能把 21445 说成 3270 亿条全量、也不能说成客户线上的 P99。

9.5 倍、5.5 倍、2.3 倍对的是这一档召回附近的对照，不是全召回曲线上每一格。对照版本和资源写了，附录 G 的具体索引参数没有进正文。P99 毫秒数不在正文里。

表 3 的 +65.5% 不是相对 FIQA 上更强的 BM25。径向搜索的 140 ms 是返回 1 万条，不是 recall@10 的在线查询。

单机 32 线程的约 15000 QPS、12 线程下 100% 缓冲的 7701 QPS，和三节点的 21445 不是同一台机器、也不是同一条查询路径。1 亿相对 100 万只掉 9% 的 QPS，索引参数是按 90% 召回重新调过的，不是同一组参数硬扩。

30 小时实验的速率是每秒 1000 条，不是第 1 节说的「每天数十亿条新向量」。召回损失小于 0.01 只在教训里作为同一搜索参数下的一句，没有误差条。

出处：字节，Yao Tian 等，UBASE: An AI Search Engine for Trillion-Scale Vector Data Management at ByteDance，2026-08-31，https://arxiv.org/abs/2608.30607v1