再做一个RAG 生成增强系统时，选Redis 还是 Milvus？

Milvus是一个主要由Zilliz开发的开源向量数据库，是LF AI & Data基金会旗下的一个毕业项目。它专为向量工作负载而设计。

其架构是分离式和云原生的，拥有独立的数据注入、索引/压缩和查询服务组件。在较新版本（2.5+）中，一个专用的流处理节点负责处理预写日志（WAL），并提高了最近注入数据的新鲜度。这种方法允许用户独立于存储来扩展计算能力。

Milvus支持多种能力：

• 索引类型：HNSW、IVF、DiskANN，以及通过Nvidia cuVS实现的GPU加速CAGRA

• 搜索：具有可配置精度-延迟权衡的近似最近邻搜索，以及将向量与BM25全文和标量过滤器相结合的混合搜索

• 部署：用于原型设计的Milvus Lite、用于单机的Standalone、用于Kubernetes集群的Distributed——Zilliz Cloud提供了一个托管选项

其代价是操作复杂性。Milvus分布式部署通常在Kubernetes上运行，并且通常包含etcd以及对象存储（S3/MinIO）。根据版本和部署方案，可能还有消息传递/WAL基础设施：历史上是Pulsar或Kafka，尽管Milvus 2.6引入了Woodpecker来减少这种外部依赖。已经使用Kubernetes的团队可能会觉得这可以管理；而不具备这方面专业知识的团队将面临更陡峭的学习曲线。

 

Redis是一个实时数据平台，将数据存储在内存中，以实现典型操作亚毫秒级的响应时间。Redis最初以缓存闻名，现在提供了一个统一的平台，将向量搜索、流处理、文档存储和传统数据结构整合在一个系统中。

对于向量搜索，Redis实现了：

• 索引算法：用于较小数据集精确搜索的FLAT、用于可配置精度的基于图的近似搜索的HNSW，以及用于带压缩的十亿级索引的SVS-VAMANA；为Intel平台提供了可选的Intel SVS优化（LeanVec/LVQ）

• 距离度量：余弦相似度、L2距离和内积

• 混合搜索：通过FT.HYBRID命令将向量相似性与元数据过滤相结合

• 语义缓存：Redis LangCache能识别语义相似的查询，从而降低LLM API成本。Milvus不包含像LangCache这样的原生语义缓存服务；团队通常在应用层实现语义缓存或添加一个单独的缓存

Redis 8引入了重大的向量改进以及一种新的向量集（Vector Sets）数据类型。该平台直接与LangChain、LlamaIndex和LangGraph集成，并提供了RedisVL，一个专用于向量操作的Python库。对于基于智能体的系统，Redis在单一部署中处理短期记忆（缓存）、长期记忆（向量）、操作状态（数据结构）和实时协调（发布/订阅）。

其关键区别在于整合。向量嵌入、会话数据、速率限制计数器和应用程序状态都存在于一个内存系统中。你避免了为向量和操作数据管理独立数据库所带来的协调开销。Redis Cloud提供完全托管的部署，并具有跨区域99.999%可用性的主动-主动地理分布。

两个平台都展示了十亿级向量的搜索能力，但它们采用了根本不同的架构方法，并带来了不同的权衡。

Redis vs Milvus

Redis和Milvus之间的架构差异决定了从部署复杂性到操作开销的一切。下表总结了关键的权衡。

特性	Redis	Milvus
查询延迟	亚毫秒到低毫秒（取决于工作负载）	取决于工作负载
语义缓存	是 (LangCache)	否
混合搜索	是 (FT.HYBRID)	是 (BM25 + 稠密/稀疏 + 标量)
统一平台	向量 + 缓存 + 会话 + 流处理	专注于向量
部署选项	云、自管理、开源	Lite、Standalone、K8s分布式、Zilliz Cloud
操作复杂性	低到中	中到高（取决于版本）
索引类型	FLAT, HNSW, SVS-VAMANA	HNSW, IVF, DiskANN, CAGRA (GPU)

在Redis发布的基准测试中，redis平台实现了：

• 66,000 vector insertions per second using HNSW at approximately 95% precision
• Billion-vector search reaching 90% precision at 200ms median latency (including RTT, with 50 concurrent queries retrieving top 100 neighbors)
• Latency at smaller scales is workload-dependent; benchmark p95 under your actual traffic patterns

• 使用HNSW，每秒66，000次向量插入，精度约为95%

• 十亿级向量搜索达到90%的精度，中位延迟为200毫秒（包括RTT，50个并发查询检索前100个邻居）

• 较小规模下的延迟取决于工作负载；根据你的实际流量模式测试p95延迟。

另外redis提供了LangCache，一个完全托管的语义缓存服务，它能识别不同措辞但含义相同的查询。LangCache不再为“天气怎么样？”和“告诉我今天的温度”分别调用LLM，而是基于语义相似度提供缓存的响应。

在生产中的好处：

• 在高流量应用中，LangCache可降低高达70%的LLM成本（结果取决于查询重复性和相似度阈值）

• 缓存命中在毫秒内返回；LLM API调用通常要慢几个数量级（通常为数百毫秒到秒)

Milvus不将语义缓存作为原生能力提供。使用Milvus构建RAG系统的团队需要将语义缓存作为应用层模式来构建，或者添加一个单独的缓存系统。

Redis可以对于复杂其要求实时性的AI应用做配套

对于一个复杂的AI应用，我们考虑的不只是向量搜索的问题，我们还需要考虑：

• 我们正在构建结合了向量相似度搜索与缓存、会话管理和操作数据的聊天机器人、AI智能体或RAG系统

• 也许我们已经有Redis基础设施——你无需新的部署复杂性即可添加向量功能

• LLM请求token会成为我们项目最值得关注的成本，而我们也许可以通过LangCache的语义缓存可降低70%的相似问题调用成本）

• 由于排期问题，我们期待生产已经就绪的向量搜索，而不是搭建一整套投入时间成本再去构建一套可能我们并不熟悉的Milvus生态支持。

如果考虑到上面，我们可能就会直接选择了团队已经在运维的redis集群（版本在7.X，即使是oss版本，也支持直接升级到8.X，官方文档https://redis.ranebull.me/docs/latest/operate/oss_and_stack/install/upgrade/）。

如果redis集群版本较老，就需要考虑升级到7.x之后再升级，这就要考虑到客户端的兼容问题了。

说到这里，redis团队可能会担心对于AI支持模块的引入会不会影响我已有业务数据的性能，毕竟做为redis服务支持，亚毫米的损失可能都会对业务系统带来风险。redis团队想到了这个问题，其多线程查询处理引擎能处理复杂的向量搜索，而不会阻塞标准（oss）的Redis操作，从而提高了混合工作负载的吞吐量。

当向量搜索是你的主要工作负载时选择Milvus

Milvus通常在以下情况下更有意义：

• 向量搜索是你在十亿级规模下的主导工作负载

• 向量查询占你操作的大部分

• 你需要超出Redis暴露范围的复杂ANN算法调优

• 你的团队有能力建立Kubernetes专业知识

该平台公开了广泛的向量索引类型（IVF、DiskANN、GPU加速的CAGRA）和调优参数。写繁重的工作负载受益于异步重建和缓冲，而读繁重的情况可以使用针对特定查询模式优化的静态索引。

调优的灵活性也意味着Milvus需要更多的操作投入，不像Redis那样整合你的基础设施，并且缺乏内置的语义缓存。如果架构控制和索引调优对业务至关重要——并且你仅通过向量搜索性能来区分你的产品——那么Milvus为你提供了更多可调节的参数。对于大多数具有混合工作负载的AI应用来说，Redis能以更低的复杂性提供你所需的功能。

 

在部署上

Redis的部署集成了向量搜索，无需额外的消息传递、对象存储或协调集群。统一的架构意味着单一的监控面、单一的备份策略、单一的安全模型。但可能是redis在2024年也就是redis8后修改了许可证类型的原因（由任何人免费使用的BSD-3转成了对云厂商不在免费的RSALv2 / SSPL），目前主流云厂商对redis版本的支持还普遍停留在了redis7上，而对于上述可以和Milvus媲美的AI能力都是redis8提供的。虽然今年（2026年）1月腾讯云推出了其参与贡献的开源组件Valkey 8.0（Valkey由redis的核心贡献者AWS、谷歌、腾讯云、甲骨文等公司合力推出的redis8.0的平替品，许可证是BSD-3，其由Linux基金会托管，确保没有任何一家公司能单方面改变规则）的支持，但具体对线上的业务支持还有待验证测试和数据支持。所以，如果你想享受redis为你的AI提供Vector支持，那你就必须选择自己部署和运维redis8。

 

Milvus实现了一种共享存储架构，具有完全分离的存储和计算层。这种专门化为向量特定的工作负载提供了对索引策略、资源分配和性能调优的精细控制。其2.6版本路线图增加了冷/热分层、地理数据支持和向量湖架构。灵活性引入了复杂性，Kubernetes上的生产级Milvus通常包含etcd以及对象存储（S3/MinIO），并且——根据版本/配置——要么包含外部消息传递（Kafka/Pulsar），要么包含作为WAL的Woodpecker。这意味需要了解维护更多的组件。需要Kubernetes操作器、分布式系统以及（在许多部署中）多个依赖服务方面的专业知识。团队需要资源来管理每个组件的独立监控、备份和高可用性，尽管Milvus 2.6的架构变化可能会随着时间的推移减轻这一负担，但这毕竟不是一蹴而就的事情。所以，如果你没有过硬的运维团队，最好采用华为云、IBM Cloud或其原厂服务Zilliz Cloud提供的Milvus服务支持。