前阵子做了一个日志语义检索的 PoC，数据量是一亿三千八百万条 384 维 embedding。这个量级听起来不算夸张，但细算一下：单条向量按 float32 存储就是 1536 字节，全量裸数据 212GB 出头。第一版图省事，直接用 Elasticsearch 8.11 的 dense_vector 加 HNSW，结果索引构建跑了一整夜没结束，单条查询 p95 稳定在 180ms 开外，召回率还忽高忽低。团队一开始怀疑是 HNSW 参数没调好，但换了几组参数都差不多，最后才意识到：亿级向量的 CPU 索引构建，确实已经撞上了物理墙。
后来我们换成了“NVIDIA cuVS 构建 GPU 加速向量索引 + Elasticsearch 管存储和过滤”的组合：让 cuVS 用 GPU 把 1.38 亿条向量的压缩索引建完，再把候选 doc_id 丢回 ES 做元数据检索。实测下来，从原始 embedding 文件到可查询接口，总耗时压在 10 分钟以内，查询 p50 只有 44ms。这篇就把整个方案拆开讲清楚：为什么 ES 原生会撞墙、cuVS 的加速原理、部署架构怎么搭、具体落地步骤、以及我们踩过的一堆坑。
1. 先聊聊为什么 Elasticsearch 原生向量路数在这个量级会撞墙
1.1 1.38 亿向量意味着什么
先把这个数字落到具体体感上。1.38 亿条 384 维 float32 向量，单条大小是 384 × 4 = 1536 字节，全量就是 211.9GB。这个规模对现代服务器来说，磁盘和内存都不算致命，真正要命的是构建 ANN 索引的计算量。
以 Elasticsearch 默认的 HNSW 为例，它的构建过程本质上是逐条插入向量、动态维护一张多层近邻图。每插入一个点，都要在图上做若干轮搜索，找到合适的邻居并建立连接。这个过程的计算量不是线性的，数据量越大，每个新点需要考察的候选邻居就越多，整体耗时呈现超线性增长。用个不太严谨但直观的类比：给一栋楼的每个房间都绘制通往周边房间的通道，1.38 亿个房间，让 CPU 一间一间画，和让 GPU 并行画，效率差距是数量级的。
所以这个量级下，问题根本不是“ES 参数没调好”，而是架构选型就不该用 CPU 全量构建 HNSW。我把结论放在前面：千万级以下 ES 原生舒服，亿级以上就得考虑专门的计算引擎。
1.2 ES 原生 HNSW 的实际表现和瓶颈
我们最初的测试环境是 24 核 CPU、128GB 内存、NVMe 磁盘，ES 8.11 单节点预热后，dense_vector 默认 HNSW 参数（m=16，ef_construction=100）。灌入 1.38 亿条向量后，索引构建跑了十几个小时，仍然没有结束。更麻烦的是，构建过程中查询性能也被拖得很厉害，业务侧根本没法用。
这背后有两个深层原因。第一，Lucene 的索引是分段（segment）结构的，HNSW 图按 segment 构建，也就是说一个 shard 里可能存在多张子图。查询时必须并行搜多张子图再合并结果，数据量大到亿级之后，分段过多、图碎片化的问题会被急剧放大。第二，距离计算全部压在 CPU 上。一条 384 维 float32 向量的欧氏距离是 1536 次乘加运算，亿级数据意味着几千亿次距离计算，而且这中间还伴随大量内存随机访问和 cache miss，CPU 就算有二十几个核也很难扛住。
我这么说不是要否定 ES。它的强项是全文检索、分布式、生态成熟，但当向量规模到了这个量级，它作为一个“通用搜索引擎”的设计取舍，决定了它不适合承担最重的那部分 ANN 计算。把什么都塞进 ES，最终只会得到一个又慢又不稳定的集群。
1.3 这个方案的适用边界
先泼一盆冷水：不是所有场景都该上 GPU。如果向量规模在一千万以下，QPS 要求也不高，ES 原生 dense_vector 足够省事，运维成本极低。硬上一套 cuVS 服务，反而是给自己找麻烦。
这个方案真正适合的场景有三个特征：向量规模亿级以上、业务方持有 GPU 资源（至少一张 24G 以上显存的卡）、查询延迟敏感。比如日志语义检索、图片特征去重、推荐系统候选召回。如果完全没有 ES 的元数据过滤和通用查询需求，也可以直接纯 cuVS 加对象存储，但大多数业务团队还是希望对外保留一个完整的查询入口，ES 在这里的价值不可替代。
所以后面这套架构的定位很明确：用 GPU 做“计算密集的 ANN”，用 ES 做“能力完整的业务查询层”。
2. cuVS 的加速思路：不是把 HNSW 搬到 GPU 那么简单
2.1 cuVS 在 RAPIDS 生态里的定位
NVIDIA cuVS 是 RAPIDS 生态里的向量搜索和聚类库，早期属于 RAFT 的一部分，后来独立出来专门做 nearest neighbors。底层是 CUDA/C++，上层提供 Python API，也支持 C++ 直接调用。很多做向量检索的人可能更熟悉 FAISS，FAISS 也有 GPU Index，但实现思路比较像“把 CPU 算法平移过来”；cuVS 里专门为 GPU 架构设计了 CAGRA 这类图索引，构建和检索路径都针对大规模并行做了重构，实际效果差异不小。
对我们这种把 ES 当主存储、需要高性能 ANN 的场景来说，cuVS 最大的价值是有多种索引类型可选，并且训练、压缩、检索都能在 GPU 上完成，不需要反复在 host 和 device 之间搬运数据。
2.2 索引类型怎么选：CAGRA、IVF-PQ 还是 IVF-Flat
cuVS 里我们实际比较过三类索引：CAGRA、IVF-Flat、IVF-PQ。它们的侧重点完全不同。
CAGRA 是 NVIDIA 专门为 GPU 设计的基于图的索引，构建和查询都在 GPU 上跑，速度极快、召回率也很高，代价是构建时最好把全部原始向量放进显存。IVF-Flat 是倒排加原始向量，不压缩、召回率高，但显存占用同样可观。IVF-PQ 则是把向量做乘积量化压缩，显存占用小一个数量级，适合超大规模数据，代价是 PQ 有损，召回率需要靠参数调优弥补。
| 索引类型 | 显存占用 | 构建速度 | 召回率 | 适用场景 |
|---|---|---|---|---|
| CAGRA | 高（需容纳原始向量） | 极快 | 非常高 | 数据集能塞进单卡显存 |
| IVF-Flat | 高（原始向量不压缩） | 较快 | 高 | 召回优先、显存充足 |
| IVF-PQ | 低（压缩后通常几 GB） | 快 | 中高（需调参） | 亿级以上的大规模数据 |
我们最终选了 IVF-PQ。理由很直接：212GB 原始数据放不进 A100 的 80GB 显存，IVF-PQ 能把每条向量压到 24 字节，整个索引只有 4~5GB，检索时 GPU 完全装得下。如果你手头的数据是 128 维、总容量在 70GB 以内，CAGRA 的效果会更好，构建速度和召回率都更让人省心。
2.3 关键参数背后的原理
IVF-PQ 的核心参数有三个：nlist、M、nprobe。这三个参数直接决定了索引的构建质量、存储大小和查询效率。
nlist 是倒排聚类的中心数。数据进来后先做 k-means 聚类，nlist 越大，每个聚类桶越小，检索时定位更精细，但训练和构建成本也会上升。我们这边定的是 4096。M 是 PQ 子空间的数量，这个参数会把 384 维拆成 M 段，每段单独做量化。M 越大，压缩后的失真越小，但每条向量的存储空间也越大。我们选 M=24，也就是每段 16 维。nprobe 是查询时探测多少个聚类桶，nprobe 越大召回越好，延迟也越高，我们最初设 32，后面调优时反复动过。
PQ 压缩的原理值得展开说一下。384 维 float32 向量按 24 段切分，每段 16 维。对每段分别做 k-means 生成 256 个中心点，然后每条向量在每段里只记录“离哪个中心最近”的编号。每个编号用 8bit 存储，24 段就是 24 字节。原本 1536 字节变成 24 字节，压缩整整 64 倍。打个比方，这就不是用完整门牌号定位，而是用“省市区 + 街道关键信息”快速锁定一个大致区域，精度会有损失，但查询成本低得多。
3. 部署形态：ES 管存储，cuVS 管检索
3.1 这套架构如何分工
很多团队在接触 cuVS 时，第一反应是“能不能把 GPU 索引塞进 ES 插件里”。我们后来明确放弃了这条路线，原因有三点：ES 是 Java 生态，JNI 调 CUDA 的集成复杂度高，升级 ES 或 cuVS 都会互相牵连；GPU 节点出现故障时不应该拖垮主查询集群；独立的 GPU 检索服务可以按照 GPU 使用率单独扩缩容，部署灵活得多。
我们的实际架构是：ES 的职责收窄到三件事——文档主存储、业务字段过滤、最终结果聚合。cuVS 独立跑在一个 GPU 服务节点上，只负责 ANN 检索，对外暴露一个轻量 REST 接口。查询流程是：用户请求进来，先由 embedding 模型把文本或图片转成向量，然后调 GPU 服务拿回 topK 候选 doc_id，再带着业务过滤条件去 ES 批量取回完整文档，最后组装返回。
这套分工其实也是很多团队做向量检索引擎时的思维误区：总想用一个系统干完所有事，结果两边都将就。把 ANN 和业务查询拆开，各自发挥各自的长处，反而更干净。
3.2 硬件、驱动、CUDA 版本与 ES 版本组合
GPU 建议直接上 Ampere 或更新的架构，A100 80G、L40S、H100 都行；开发机用 RTX 4090 24G 也能跑，只是数据集要缩小。驱动和 CUDA 建议拉到比较新的稳定组合：驱动 550 系列、CUDA 12.4、cuVS 24.10、Python 3.10。ES 这边 8.11 和 8.13 都测过，没有发现兼容性问题。
强烈建议直接用 NVIDIA NGC 的 RAPIDS 容器镜像来部署 cuVS 服务，镜像里已经装好了 cuVS 和全部依赖，省去自己配 conda 环境的痛苦。ES 是 Java 服务，和 GPU 服务分开部署，GPU 节点不要和 ES 节点混部，否则显存和 CPU 资源互相抢，出问题都不好定位。
| 组件 | 建议版本 |
|---|---|
| GPU | A100 80G / L40S / H100（最低 RTX 4090） |
| 驱动 | NVIDIA Driver 550+ |
| CUDA | 12.4 |
| cuVS | 24.10 |
| Python | 3.10 |
| Elasticsearch | 8.11 / 8.13 |
这里有个容易被忽略的点：卡太老跑不了。cuVS 要求 GPU compute capability 7.0 以上，也就是 Volta 起步；CAGRA 建议 8.0 以上。拿 P100 这类 Pascal 老卡是跑不起来的。
3.3 数据流与接口约定
GPU 索引输出的结果是整数行号，不是业务侧的 doc_id。所以数据流里必须维护一张“整数行号 -> doc_id 字符串”的映射表，构建时按顺序给每条向量编号，查询时把行号转回 doc_id，再去 ES 取数。映射表直接放服务内存里，用 Python dict 或者哈希表都行，亿级数据大约占 1~2GB 内存，可接受。
接口上我们用一个 FastAPI 服务收口，暴露两个核心 POST 接口：/build 负责接收待构建的向量文件路径并触发索引构建；/search 接收 query 向量，返回 topK 的 doc_id 数组和距离分数。做增量更新时，如果业务上必须支持频繁删除，建议直接定时全量重建索引，而不是做复杂的增量索引维护。删除导致的行号漂移问题在 GPU 索引里非常麻烦，不如 ES 侧在取数时用过滤条件把已删除 doc 滤掉来得简单。
4. 完整落地过程：从原始 embedding 到可查询的 ES 接口
4.1 数据准备与预处理
构建前提是已经拿到所有向量的 embedding 文件。我们统一存在 Parquet 文件里，字段包括 doc_id、id 维度数组 vector，以及若干业务字段。读取用 cuDF，能直接拿到 GPU 上的 DataFrame，省掉一次 host 到 device 的拷贝。
预处理阶段做两件事。第一是向量归一化。语义检索默认用余弦相似度，直接把向量做 L2 normalize 后，内积结果就等于余弦相似度，cuVS 那边配 metric="inner_product" 就行。第二是存储精度。embedding 文件用 float16 保存，能省一半磁盘和显存带宽；训练码本和构建索引时再转回 float32。数据量越大的场景，float16 的收益越明显。
还有一个非常实际的建议：正式全量构建之前，先用一个 10 万行的子集把整条链路跑通，确认查询结果、映射关系、ES 返回都正常，再上全量。全量构建一旦因为一个低级 bug 跑到一半挂了，重跑一次很浪费时间。
4.2 用 cuVS 构建 1.38 亿向量的 GPU 索引
核心构建流程在 cuVS 里其实不长，关键是多批处理和显存控制。伪代码逻辑如下：
import cudf import cupy as cp from cuvs.neighbors import ivf_pq # 分批读取 Parquet df = cudf.read_parquet("embeddings_part_000.parquet") vectors = df["vector"].to_cupy().astype(cp.float32) # L2 归一化 norms = cp.linalg.norm(vectors, axis=1, keepdims=True) vectors = vectors / norms # 配置 IVF-PQ 参数 params = ivf_pq.IndexParams( n_lists=4096, n_bits=8, metric="inner_product", ) # 训练 + 构建索引 index = ivf_pq.build(vectors, params) index.save("es_cuvs_index.bin")真实生产环境里，212GB 数据不可能一次性全部塞进显存。我们的处理是两步走：先用抽样数据训练码本，再分块把全量向量交给 GPU 做 PQ 压缩和倒排写入。抽样量控制在 200 万行左右，足以训练出稳定的 k-means 中心。全量向量按 2000 万行一块，反复循环读取、压缩、写入索引，每处理完一块就释放显存，确保峰值不会冲破 A100 的 80GB。
这一步是整个方案里最需要细心的地方。很多人一上来就直接ivf_pq.build(全量数据)，A100 也不一定扛得住。cuVS 支持先 train 再 extend，把训练和全量写入拆开，是处理超大数据集的正确姿势。
4.3 索引写入 ES 与查询链路打通
需要特别提醒：我们不会把 1.38 亿条向量全量写进 ES 去做 dense_vector 索引。那等于让 ES 再建一遍 CPU 的 HNSW，纯纯浪费资源。ES 里只存两样东西：doc_id 和业务字段，向量只按需存储、不开索引。
如果业务上确实需要在 ES 里保留原始向量，mapping 里一定要把 index 关掉：
{ "mappings": { "properties": { "doc_id": { "type": "keyword" }, "vector": { "type": "dense_vector", "dims": 384, "index": false, "similarity": "cosine" } } } }bulk 写入的优化也要注意。我们把 refresh_interval 临时设为 -1，也就是关闭自动刷新，灌完全量数据后再手动 refresh 一次。默认的默认刷新间隔是 1 秒，亿级数据写入时频繁触发 refresh，会让完整导入时间多出好几倍。写入完成后记得把 refresh_interval 恢复原值。
查询链路实现时，先调 cuVS 服务拿到 topK doc_id 数组，再用 mget 或者带过滤条件的 terms 查询去 ES 取数。有一个细节容易被坑：mget 返回的文档顺序不保证和传入 id 顺序一致，回包前必须按自己的候选顺序重新排一次。
4.4 验证三件事：耗时、召回率、延迟
搭建完成后，必须验证三个指标：构建耗时、召回率、端到端延迟。构建耗时的定义是从读取 embedding 文件开始到索引保存成功，中间每一步都要计时，方便排查瓶颈。召回率我们惯例上抽 2000 条 query，和暴力检索的 topK=10 结果做对比，看有多少重合，目标是至少 0.9。延迟则用压测工具打 POST /search，统计 p50、p95、p99。
如果召回率不达标，调优顺序建议是：先提高 nprobe，再看 PQ 的 M 参数，最后考虑加 re-rank 精排。如果延迟不达标，优先看 ES 取数那边的瓶颈，GPU 端单个 query 通常只有几毫秒，ES 反而是大头。
5. 实测记录：10 分钟的构成与性能数字
5.1 测试环境
先说清楚我们的测试环境，方便大家对照。GPU 节点是一台双路 64 核 CPU、512GB 内存、A100 80G 的服务器，数据盘是 NVMe SSD。ES 是三个节点的集群，每个节点 32 核 CPU、128GB 内存，版本 8.13。数据集就是前面反复提到的 1.38 亿条 384 维 float32 embedding，全量 212GB，训练抽样 200 万条。
5.2 构建耗时拆解
一次完整的构建，耗时拆解如下：
| 阶段 | 耗时 |
|---|---|
| 读取与归一化 | 1 分 50 秒 |
| 码本训练（200 万抽样，nlist=4096，M=24） | 1 分 20 秒 |
| 全量 PQ 压缩与倒排索引写入 | 5 分 10 秒 |
| 保存索引文件 | 35 秒 |
| 总计 | 8 分 55 秒 |
这里有个前提是数据在 NVMe 上，读取速度够快。如果数据在 SATA 盘或者网络文件系统上，光读取这步可能就要多花好几倍时间。对比来看，同一份数据用 ES 原生 HNSW 跑了十六七个小时没建完，我们直接放弃了；用 CPU 版 FAISS 参考公开 benchmark 也得 8 到 12 小时。GPU 加速带来的收益主要是把大量并行的距离计算和聚类训练从 CPU 循环搬到了 CUDA 核上，压缩写入阶段得益于高吞吐的 batch 处理。
10 分钟这个数字不是理论值，是我们操作层面的真实体感。只要训练抽样不过大、批次大小合理、数据文件放在 NVMe 上，这个量级基本都能跑进 10 分钟。
5.3 查询延迟与召回率
查询性能的关键数字：单条查询在 GPU 端耗时 3~5ms，ES 取元数据加过滤 20~40ms，端到端 p50 44ms，p95 76ms，p99 120ms。这个延迟对这个数据量来说已经非常理想了，用户的搜索交互体感基本无感知。
批量查询是 GPU 的强项。我们压测时一批打 1000 条 query，GPU 端总耗时约 30ms，相当于单条均摊 0.03ms（不含 ES 取数），所以如果你的场景是离线批量打分或者内容去重，这个方案的吞吐优势会体现得更加明显。
召回率方面，topK=100、nprobe=32 时，召回率@10 是 0.93。把 nprobe 从 32 提高到 64，召回率升到 0.96，但查询延迟多了大概 40%。这是个典型的平衡点取舍，要看业务对召回和延迟的容忍度。
5.4 与 CPU 方案对比
把两种方案摆在一起看会更直观：
| 对比项 | ES 原生 HNSW | cuVS + ES |
|---|---|---|
| 索引构建 | 十几小时未完成 | 8 分 55 秒 |
| 单条查询 p50 | 180ms+ | 44ms |
| 显存需求 | 无 | 80G 级（单卡 A100） |
| 召回率稳定性 | 调参困难 | 稳定且可调 |
| 运维复杂度 | 低 | 中（多一个 GPU 服务） |
CPU 方案并不是一无是处，它的优势在于省事、资源门槛低、和现有 ES 体系完全融合。我的经验值是：向量规模一千万到五千万是分水岭，低于这个规模就老老实实用 ES 原生；超过一亿，并且你手里有 GPU 资源，cuVS 这条路基本是绕不开的。
6. 踩坑实录：显存、驱动、版本和参数
6.1 CUDA / 驱动版本不匹配导致的问题
GPU 环境最烦的不是算法，而是环境。我们第一次部署时，cuVS 加载直接报 CUDA_ERROR_NO_DEVICE，查了半天发现是容器没透传 GPU；后来换了一台机器又遇到 compute capability 不支持，才发现那张卡是 Pascal 架构的老卡，压根不在 cuVS 支持列表里。
排查步骤建议固定成套路：先跑 nvidia-smi 看驱动版本和可支持的 CUDA 版本，再进容器里跑 nvidia-smi 确认 GPU 能看到，最后看 CUDA_VISIBLE_DEVICES 有没有把显存隔离到别的任务上。网上很多人搜“英伟达gpu错误代码43”，多数情况下就是驱动和容器映射的问题，和这里本质类似。环境问题直接上 NGC 容器镜像，能避开 90% 的坑。
6.2 显存峰值不是索引大小的错
这个坑我们栽过一次。当时以为索引文件只有 5GB，80GB 显存随便放，结果训练阶段直接 OOM。原因是 k-means 训练过程中，cuVS 的底层实现会在显存里放训练数据、中心矩阵、距离矩阵等多份中间变量。抽样 1000 万条、每条 384 维 float32，光训练数据就是 15.3GB，再叠加距离矩阵和梯度计算，瞬间冲破 80GB。
解决方式两点：一是训练抽样量控制在 200 万左右，给中间变量留足空间；二是全量写入阶段用分批 extend，而不是一次性把几十 GB 向量灌进显存。建议正式跑之前先用 PyNVML 写个小脚本监控显存曲线，观察峰值，避免半夜跑挂。
6.3 nprobe 与召回率的交易
nprobe 调参是个典型的性价比决策。nprobe 太低，召回率难看；nprobe 太高，延迟翻倍。我们测试时 nprobe=32 召回率 0.93，nprobe=64 召回率 0.96，但延迟从 76ms 涨到 106ms 左右。对不同业务，这个平衡点完全不一样，一定要用自己的数据集实测。
PQ 是有损压缩，nprobe 再高也补不回所有精度。想要更高的召回率，我们用的技巧是两阶段检索：cuVS 先返回 topK=200 的粗筛结果，然后拿这些 doc 的原始 384 维向量在 GPU 上做一次精排，取前 100 返回。实测召回率能从 0.93 提升到 0.97，而精排 200 条的额外耗时只有 10ms 左右，性价比非常高。
6.4 ES 集成中的几个细节
最后说几个 ES 集成时的实操细节。第一个是 dense_vector 的 index 一定要设为 false，否则 ES 会额外建一份 CPU HNSW，索引构建时间和存储空间白白翻倍。第二个是 bulk 导入期间把 refresh_interval 调到 -1，写完再恢复，这个操作能把全量数据导入时间压下去一大截。第三个是 mget 返回顺序问题，返回文档顺序不保证和请求 id 顺序一致，必须先按候选顺序重排再回包。第四个是过滤条件的下推策略：如果业务过滤能把候选集缩小到原来的十分之一以下，那就要考虑先过滤再 ANN；如果过滤条件很弱，先 ANN 再过滤效率更高。这个取舍必须用真实数据测，不能拍脑袋。
我们整套方案最终稳定跑在线上后，我个人最大的体会是：这个方案的难度不在 cuVS 本身，而在把 GPU 索引服务和 ES 的元数据链路衔接好。第一次跑通之后，后面所有迭代都很快。如果你手头也有类似规模的向量检索需求，我的建议永远是先拿小数据跑通整个链路，再逐步放大，不要一上来就直接往 1.38 亿上冲。
