1G内存检索2500万向量，Milvus中如何用FLAT在强标量过滤场景搞定毫秒响应？

在向量数据库的实际应用场景中，内存资源受限是开发者经常面临的挑战。当需要处理海量向量数据时，传统的高效索引方案往往需要大量的内存支持，这在资源有限的生产环境中难以落地。本文将分享一个在1GB内存限制下成功检索2500万向量的实战案例，探讨如何通过FLAT索引配合多重优化技术实现毫秒级响应。

索引方案选型历程

某团队在构建以图搜图系统时遇到了棘手的问题：需要对2500万张图片（转换为1280维向量）进行相似度检索，单机需要支撑亿级数据规模。然而服务器内存仅有64GB，分配给向量数据库的内存不超过32GB。使用官方Sizing Tool进行估算，结果显示需要139GB内存，似乎无法实现。

优化三：标量过滤加速

在确定最终方案之前，团队经历了两次失败的尝试。第一次采用了AISAQ索引，这是一种新型的磁盘索引，理论上内存占用很低。但在测试5500万向量时，单次load操作的磁盘写入量达到249GB，加载速度极慢，既耗时又占用大量磁盘空间。第二次尝试IVF_FLAT索引，创建索引后load集合时进度卡在14%无法继续，最终以失败告终。

优化一：FP16精度压缩

FLAT是Milvus中最基础的索引类型，不建树、不聚类，查询时对原始向量进行暴力遍历。之所以能扛住2500万向量，源于三层优化的叠加效果。第一层优化是FP16精度压缩：将向量精度从FP32降到FP16，单条向量从5120字节降至2560字节，2500万条向量总量从约120GB压缩到约60GB。FP16在绝大多数检索场景下精度损失极小，Recall差异通常小于0.1%。

优化二：mmap内存映射

这也解释了为什么FLAT能赢过IVF_FLAT和HNSW：当标量过滤已将候选集压缩到很小范围时，额外的索引结构反而成为负担——占用内存、增加构建时间，但对检索速度贡献微乎其微。

如有侵权，请联系删除。