同价位性能暴涨 7 倍？火山引擎 Milvus 凭 CAGRA+GPU 破解向量检索性价比悖论

2025-12-10
江苏
本文字数：5357 字
阅读完需：约 18 分钟

在大模型、多模态应用爆发的今天，向量数据库已成为支撑 AI 检索、语义理解、推荐系统的核心基础设施。随着数据规模的飙升，传统 CPU 向量数据库逐渐陷入“检索瓶颈”——构建时间长，响应速度、批量处理能力不足，甚至成为整个 AI 系统的性能短板。而 GPU 加速向量数据库的出现，不仅彻底打破了这一瓶颈，更重新定义了向量检索的速度边界。

使用 VectorDBBench 测试发现，即便是在价格对齐的前提下（使用火山引擎 Milvus 定价对比），采用 NVIDIA A10 GPU 与 CAGRA 索引的向量数据库方案，相较于同等成本的 CPU 与 HNSW 索引方案：

索引构建提速最快仅需 CPU 方案的 1/3：通过 768D·1M、1536D·500K 以及 1536D·5M 三种不同规格的数据集测试验证：在相同召回率下（top100@98%recall），GPU 方案的构建时间仅需要 CPU 方案的 1/3；
查询 QPS 提升 2.4-7 倍以上：在单次查询（Batch=1）场景下，QPS 达到 CPU 的 2.4-2.7 倍；在批量查询（Batch=100）时，优势扩大至 4.5-7.5 倍以上。
查询延迟更低且更稳定：所有测试场景下，GPU 的 P99 和 P95 延迟均显著低于 CPU，提供了更可靠的服务质量保障。
单位 QPS 成本显著下降：得益于性能的大幅领先，在价格对齐的情况下，GPU 方案的单位查询成本最高可降低至 CPU 的近 1/8。

火山引擎 Milvus 上线的 GPU 加速向量数据库服务可以为向量搜索场景带来新的可能：在相同的价格前提下，使用原先 1/3 不到的索引构建时间，构建更高质量的向量索引，在延迟更低更稳定的前提下，带来 7 倍以上的性能提升，1/8 的单位 QPS 成本为降本增效提供更优的方案。

一、GPU 为何比 CPU 快？核心在“架构适配”

向量数据库的核心任务是高维向量的相似性计算和海量数据的快速检索，而 CPU 和 GPU 的性能差距，本质是“通用计算架构”与“并行计算架构”的天生差异——前者擅长复杂逻辑的串行处理，后者则为大规模并行计算而生。

1. 硬件架构：核心数量与分工的“降维打击”

CPU：少量核心+复杂控制单元。普通 CPU 通常只有 4-64 个物理核心，每个核心都配备了复杂的缓存层级、分支预测单元和指令解码模块，设计目标是高效处理串行、复杂、逻辑密集型任务。但向量计算的特点是“简单指令+海量数据”，比如计算 100 万条 1024 维向量的余弦相似度，本质是重复执行“点积运算+归一化”，CPU 的复杂控制单元完全无法发挥作用，大量核心处于闲置状态，算力被严重浪费。
GPU：海量核心+精简控制单元。一块 GPU 拥有数千个 CUDA 核心（如 NVIDIA A10 和 NVIDIA A100 均拥有 6912 个 CUDA 核心），这些核心专注于“并行数据处理”。当面对百万级、亿级向量的批量计算时，GPU 能将任务拆解为无数个小任务，分配给数千个核心同时执行，对于重复性、数据密集型任务，两者处理效率差距呈数量级差异。

2. 内存架构：带宽与延迟的“精准匹配”

向量计算不仅依赖算力，更依赖内存带宽——高维向量的读取、传输需要巨大的带宽支撑，否则会出现“算力等数据”的瓶颈。

CPU 的内存瓶颈：CPU 的内存带宽通常在几十 GB/s（如 DDR5-6400），且缓存设计更侧重“低延迟”，而非“高带宽”。当处理亿级向量时，CPU 需要频繁从内存中读取零散的向量数据，带宽不足会导致计算核心长期等待，算力利用率不足 10%。
GPU 的带宽优势：GPU 的显存带宽可达数百 GB/s 甚至上千 GB/s（如 A10 的显存带宽达 600GB/s，A100 的显存带宽更是高达 1935GB/s），对比 CPU 有数量级优势。同时，GPU 的内存架构支持“批量数据连续访问”，能高效加载大规模向量数据集，完美匹配向量计算的“高带宽需求”。此外，GPU 的共享内存、寄存器文件等高速缓存，能进一步降低向量数据在核心间的传输延迟，让算力充分释放。

3. CAGRA 索引

CAGRA（Coarse-to-Fine GPU Accelerated Graph-based Retrieval Algorithm）是 NVIDIA 专为 GPU 架构打造的一种基于图的算法，用于快速高效的近似最近邻搜索，能够最大化发挥 GPU 的大规模并行计算优势，实现高维向量检索场景下的“极速响应+高效构建”双重突破。

3.1 索引构建

CAGRA 中的图可以使用 IVF-PQ 方法或 NN-DESCENT 方法构建，这两种图构建方法各有侧重，且均针对 GPU 的硬件架构进行了深度优化：

IVF-PQ（Inverted File with Product Quantization）的核心逻辑是先对全局向量数据集进行聚类划分，随后通过 PQ 量化进行压缩编码，在保证检索精度的前提下大幅降低内存占用。最后为每个向量节点建立与簇内邻近节点的连接关系，最终形成一个“簇内稠密、簇间稀疏”的初始图结构。这种构建方式不仅可以通过量化压缩成本，同时基于 IVF 的聚类划分让图的初始构建过程具备天然的并行性，避免跨簇数据依赖。
NN-DESCENT（Nearest Neighbor DESCent）构建法是一种基于“局部搜索+迭代优化”的自适应图构建方案，从随机初始化的向量连接关系出发，通过多轮迭代逐步优化图的拓扑结构，基本思想就是“邻居的邻居更可能是邻居”。经过多轮迭代后，最终形成一个近似最优的 K 近邻（K-NN）图。该方法的优势在于适应性强，无需依赖数据的分布特性，即便面对非均匀分布的高维向量数据集，也能高效构建出连通性好、检索精度高的图结构，因此被广泛应用于文本语义检索、图像相似性匹配、多模态数据检索等各类需要快速近邻搜索的场景。

与当前主流的 HNSW（Hierarchical Navigable Small World）算法相比，CAGRA 的图构建机制具备更显著的 GPU 并行适配优势：

CAGRA 的两种构建方法均采用“无状态/低状态依赖”的任务拆分逻辑——IVF-PQ 的簇内独立构建、NN-DESCENT 的局部迭代优化，都能轻松拆解为数千个可并行执行的子任务，完美契合 GPU 数千个计算核心的并行调度模式；
两种构建方法在任务执行过程中“跨任务数据交互极少”——IVF-PQ 中不同簇的图构建几乎无数据依赖，NN-DESCENT 的迭代优化仅需局部邻居信息，无需全局数据同步，这就避免了 HNSW 在层级图构建过程中因“跨层级节点连接”导致的任务耦合与数据通信开销。

这种“低依赖+高并行”的设计，使得 CAGRA 的图（即检索索引）构建时间较 HNSW 实现了显著缩短，尤其在海量高维向量场景中，这种优势更为突出，能将索引构建时间从“小时级”进一步压缩至“分钟级”，大幅降低大规模向量检索系统的部署与更新成本。

3.2 向量搜索

CAGRA 的搜索过程会使用一个顺序内存缓冲区以维护一个优先队列及其候选列表。初始阶段，通过随机抽样选择一批索引节点候选列表，并计算其与查询向量的距离。整个缓冲区中，距离查询向量最近的节点将会更新至优先队列，而优先队列的邻居节点则用于更新候选列表。之后，算法会重复“更新优选列表→遍历邻居更新候选列表→按需计算距离”的流程，直到内部优选列表中的所有节点都被当作起始节点遍历过一遍。最后，从内部优先队列中取出前几位距离最近的节点，就是本次近似最近邻搜索的最终结果。

与当前主流的 HNSW 的搜索过程对比，CAGRA 的搜索过程天然有利于并行：

CAGRA 采用扁平化、无严格层级的图设计，节点连接局限于局部范围，无“上层引导下层”的强依赖，不同节点的遍历任务可独立拆分，天然适配 GPU 并行架构；而 HNSW 是多层级嵌套结构，检索需“自上而下”串行导航，前一层级任务未完成则后一层级无法启动，从根源上限制了并行潜力。
CAGRA 以“批量处理”为核心，初始化抽样、距离计算、邻居遍历等步骤均可拆分为独立子任务，多个 GPU 核心能同时处理；HNSW 则是“单路径串行探索”，需从顶层入口节点逐步向下导航，每次仅能选择一个节点作为下一层起点，任务无法拆分，并行化无从下手。
CAGRA 的任务依赖仅局限于局部，节点距离计算、邻居遍历均无需全局同步，仅通过局部数据即可完成；HNSW 存在强全局依赖，检索需频繁访问全局层级表、同步距离信息，甚至需通过锁机制避免资源冲突，并行时同步开销极大，效率大幅降低。

二、GPU 加速向量数据库的核心使用场景

随着 AI 应用从“小规模试点”走向“大规模落地”，向量数据的规模、维度和检索需求都在呈指数级增长。CPU 向量数据库受限于架构设计，已无法满足海量数据、毫秒级延迟、高并发检索的需求，而 GPU 加速向量数据库通过“海量并行核心+超高内存带宽+算法深度优化”，完美解决了这些痛点。

GPU 与向量计算的“并行性”天然契合，其性能优势并非“局部优化”，而是“架构级提升”。GPU 加速向量数据库不仅能提升系统响应速度，更能支撑 RAG、多模态检索、实时推荐等高级 AI 场景的落地，帮助企业构建核心竞争力。

前文提到的应用场景看似分散，但核心都围绕“特定类型的向量特征”展开——GPU 加速的优势能否发挥，关键在于向量的“维度、规模、更新频率、计算复杂度”四大核心属性。从向量特征的本质出发，帮你快速判断“你的向量是否需要 GPU 加速”。

高维向量：维度越高，GPU 优势越明显：向量维度直接决定了单次相似性计算的“计算量”——维度越高，CPU 的串行计算越吃力，而 GPU 的并行核心能更高效地分摊负载。ResNet（2048 维）等模型生成的多模态特征向量、BERT（768 维）等大语言模型生成的文本嵌入向量以及工业传感向量都是典型的高维向量；
海量规模向量：数据越多，并行计算的“规模效应”越强：GPU 的核心优势是“批量并行”，当向量数量突破百万级、千万级，甚至亿级时，CPU 的“串行处理+有限核心”会陷入瓶颈，而 GPU 的数千个核心能同时处理海量向量对的计算，效率呈指数级提升。典型海量向量场景：全网级内容库、企业级知识库以及物联网传感数据等；
高动态更新向量：实时写入+实时检索场景，GPU 更能扛。部分场景需要向量数据“写入即检索”（如实时推荐、动态知识库、实时监控），此时 CPU 不仅要处理检索计算，还要承担数据写入、索引更新的开销，容易出现“写入阻塞检索”的问题。因此，对于用户行为向量、实时监控向量以及动态知识库向量等典型高动态向量类型，低时延更稳定的 GPU 索引会带来更稳定高效的性能；
复杂计算需求向量：需要多轮过滤/融合计算，GPU 效率更高。如：多条件检索、特征融合检索等场景，不仅需要“简单相似性匹配”，还需要在检索过程中进行向量过滤、特征融合、多轮重排等复杂计算，此时 CPU 的计算压力会急剧增加，而 GPU 能并行处理这些附加计算任务。

三、火山引擎 Milvus：更低的成本，更高的性能

火山引擎 Milvus 深度集成了 NVIDIA RAPIDS cuVS（包括 CAGRA），为用户提供了开箱即用的 GPU 加速向量数据库服务。为了验证同价位下两种方案的性能表现，基于 VectorDBBench，我们对比测试了使用三种不同规格的数据集：1536D（维度）/500K（数量）、768D（维度）/1M（数量）、1536D（维度）/5M（数量），GPU+CAGRA 索引方案与 CPU+HNSW 索引方案的 Milvus 性能表现。从索引构建、QPS、月价格/QPS 以及查询延迟四个维度对两个方案进行对比测试，所有性能测试结果基于 top100@98%recall，Client 为 ecs.g4i.2xlarge 8vCPU32GiB。

1. 索引构建时间：降低至 1/3

如下是不同数据集在对齐价格以及 recall 前提下的索引构建时间对比，可以看到，在对齐召回率的前提下，同等价位的 CPU + HNSW 索引在构建索引的耗时需要 GPU + CAGRA 索引的三倍以上，可见 GPU 在保证构图质量的前提下，可以并行大幅度缩短了构图时间。

2. 查询性能 (QPS)：批量越大，维度越高，优势越显著

通过对比三种不同数据集在不同批量大小（Batch Size）下的表现，可以发现同价位下，选择 GPU+CAGRA 索引方案的 QPS 至少是 CPU+HNSW 索引 2 倍以上，同时调大查询的 batch size 可以更充分利用 GPU 的并行优势，将差距拉大至 7 倍以上，而 CPU 的 QPS 反而会随着 batch size 的增大而降低，表现出了极大的性能差距。

同时，高维度向量场景下 GPU+CAGRA 索引的性能表现会更好。使用 768 维数据集，GPU 方案的 QPS 最高是 CPU 方案的 5.2 倍，而 1536 维的数据集，同样百万级的场景下则可以将二者的差距拉大至 7.7 倍，即便是 50 万的小数据集，最大差距也高达 5.7 倍。