我要投稿

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

发布日期：2026-05-07 18:39:39 浏览次数： 1789

作者：Zilliz

微信搜一搜，关注“Zilliz”

前几天在 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模式都会影响真实内存需求，建议根据自己的真实负载，进行实际测试为准。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业

相关资讯

2026-06-10

如何构建一个更“好”的知识库？

2026-06-10

7.9K星：Google黑科技TurboQuant开源实现，Rust重写向量检索提速30倍

2026-06-10

企业级智能体系统 RAG的分片优化逻辑

2026-06-10

Vector Graph RAG 开源！一套向量数据库同时搞定语义检索+RAG多跳

2026-06-10

企业 RAG 知识库落地，应如何设计实现？

2026-06-10

知识库分层编排：从 RAG 到 Agent-native Knowledge Context Layer

2026-06-10

RAG 优化 20 法：从"搜得到"到"答得好"

2026-06-10

企业 RAG 知识库落地，真正难的不是调用大模型

联系获取

160+中大型企业正在使用53AI

立即咨询预约演示

把握AI发展的机遇，共同探索、共同进步

2025-01-22

如何打造基于GenAI的员工服务机器人

2025-01-22

热点资讯

知识基座：让“AI 越用越懂业务”的团队经验实践【天猫AI Coding实践系列】

2026-03-23

全网爆火的大模型AI知识库，保姆级教程来了

2026-04-06

从RAG到GraphRAG：货拉拉元数据检索应用实践

2026-03-18

为什么总感觉 Claude Code 比 Cursor 聪明？真正的原因根本不是模型能力！

2026-03-20

Karpathy的LLM Wiki + 3.5 万Star的Graphify：企业级 RAG 缺的真是知识图谱？

2026-04-27

RAG进化了，深扒Claude Code源码中RAG高级技巧

2026-04-02

OpenDataLoader：PDF文档提取的一站式方案

2026-03-31

面向手机Agent的记忆系统工程:OPPO的Agentic-RAG实战与演进

2026-03-21

企业AI落地三重门，用友如何破局？

2026-03-17

2026 年做搜索就是做 Agent Memory

2026-04-23

大家都在问

如何构建一个更“好”的知识库？

2026-06-10

企业 RAG 知识库落地，应如何设计实现？

2026-06-10

AIOps探索：给不能联网的客户做一个AI运维助手到底有多难？

2026-05-20