知识库

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

2026 年 5 月 7 日

如何在1G内存下实现2500万向量毫秒级检索？Milvus的FLAT索引+三重优化带来惊人性能突破。核心内容： 1. 传统索引方案在内存受限场景下的失败案例 2. FLAT索引配合FP16精度压缩和mmap技术的三重优化原理 3. 实际测试数据：1GB内存实现100毫秒内稳定响应

前几天在 Milvus 社区，一位做以图搜图的朋友提了一个问题：

“我们要对2500 万张图片（转为1280 维向量）做以图搜图，单机支撑亿级数据的查询。但内存配置只有64GB，其中能分给向量数据库的最多32GB。但我用 Sizing Tool 算了一下，说要 139GB 内存，是不是没戏了？"

用HNSW之类看起来很高效的索引来看，这的确跑不通，但我们换个思路，试试最基础的FLAT 呢？

实践下来，借助FLAT ，不到 1GB 内存，查询延迟稳定在 100 毫秒以内，就能搞定2500 万向量的高效检索。

以下是我们的实践经验复盘。

01走过的弯路

在最终确定FLAT 之前，这个朋友先做了两轮其他索引的选型摸索：

第一次：AISAQ 索引。这是一种新的磁盘索引，理论上内存占用很低。但索引构建需要写入大量临时文件。之前测试过 5500万向量，load 一次集合，磁盘写入量达到 249GB，并且加载速度也非常慢，既费盘又费时间。

第二次：IVF_FLAT 索引。创建完索引后 load 集合，进度到 14% 就一直挂着，最终失败。

两次碰壁后，他决定干脆用最基础的 FLAT 索引试试，没想到直接跑通了。

最后实际内存只用了不到 1GB，容器常驻内存也就 600MB 左右。启动峰值内存冲到 12.5GB，稳定后完全可控，查询首访约 30 秒，后续延迟稳稳控制在 100 毫秒内。

02 为什么 FLAT 能扛住 2500 万向量

FLAT 是 Milvus 里最基础的索引类型——不建树、不建图、不聚类，查询时在原始向量上做暴力遍历。

按常理，2500 万条暴力搜索，内存和延迟都不可能达标。但milvus的三层优化叠加在一起，让它成了最优解。

优化一：FP16 ，向量体积直接减半

存储时把向量精度从 FP32 降到 FP16：

单条向量：1280 维 × 4 字节 = 5120 字节 → 1280 维 × 2 字节 = 2560 字节

2500 万条总量：约 120GB → 约 60GB

FP16 在绝大多数检索场景下精度损失极小（Recall 差异通常 < 0.1%），但存储和内存占用直接对半砍。

优化二：mmap ，内存不够，磁盘来凑

即使用了 FP16，60GB 也远超 16GB 物理内存。第二把钥匙是 mmap。

FLAT 没有额外索引数据，所有数据就是原始向量本身。mmap 开启后，向量数据不再全量加载到内存，而是以内存映射文件的方式存在磁盘上，操作系统按需将访问到的数据页加载进内存，内存大幅节省！

从 Milvus 2.6 开始，向量原始数据的 mmap 默认开启。这位朋友用的是 Milvus 2.6.14，并没有手动配置 mmap，但集群级默认配置已经帮他开了。

一个细节：Attu 界面显示的是 Schema 级别的 mmap 配置，不会反映集群级默认值。Attu 上看到 mmap 显示为"关闭"，但实际上集群级已经启用了。

Trade-off：内存省下来了，但是对于原始向量开启mmap之后，磁盘会多占约 60GB。对于一台配了 SSD 的机器来说完全可以接受。

优化三：标量过滤，真正的加速器

FP16 减半了数据量，mmap 解决了内存瓶颈，那 2500 万条暴力搜索的延迟呢？答案在查询模式里。他的每次查询都带标量过滤条件，类似如下表达式：

dataid in [123] AND classid in [0, 2, 3]

这个表达式先在标量字段上筛选，把 2500 万条候选集缩小到几百到几万条。然后 FLAT 的暴力搜索只需要在这个小子集上执行——几万条向量的暴力比较，现代 CPU 只需要毫秒级。同时结合前面的mmap，只需要把符合过滤条件的向量从磁盘加载到内存中计算，内存消耗也可以保持在很低的水平。

这也是为什么 FLAT 在这个场景下能赢过 IVF_FLAT 和 HNSW：当标量过滤已经把候选集压缩到很小的范围，额外的索引结构反而是负担——占内存、占构建时间，但对检索速度贡献微乎其微。

另外值得注意的一点，这个场景里的表达式比较简单，即使没有标量索引，过滤环节占用的耗时也比较低，对于 like，in 大的列表，json多层过滤这些复杂的表达式，最好创建标量索引来降低过滤阶段的延时。

03 不只是以图搜图

这个图搜案例的核心模式是：强标量过滤 + 实际搜索数据量远小于总量。符合这个模式的场景还有很多：

多租户 RAG：按 tenant_id 过滤，单个租户数据量通常只有几千到几万条，FLAT 绰绰有余

电商商品搜索：按品类、品牌过滤后在子集内搜索相似商品

日志和文档检索：按时间范围 + 来源过滤后做语义搜索

这类场景，都可以采用上面的 FLAT+FP16+Mmap 的方案，既享受到实惠的内存开销，又获得不错的检索性能。

另外，在这位社区朋友的案例中，Sizing Tool 按"全量数据加载到内存"估算，对于2500万 1280 维的向量计算出 139GB 的内存。这是一个保守的安全值——确保最坏情况下系统也能运行。

但实际部署中，向量精度，索引类型，标量过滤情况，mmap模式都会影响真实内存需求，建议根据自己的真实负载，进行实际测试为准。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们

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

优化一：FP16 ，向量体积直接减半

优化二：mmap ，内存不够，磁盘来凑

优化三：标量过滤，真正的加速器

立即咨询 JOTO

想把这些做法用到你的业务里?

开启企业级 AI 落地

填写需求单

优化一：FP16 ，向量体积直接减半

优化二：mmap ， 内存不够，磁盘来凑

优化三：标量过滤，真正的加速器

立即咨询 JOTO

想把这些做法用到你的业务里?

开启企业级 AI 落地

填写需求单

优化二：mmap ，内存不够，磁盘来凑