最近在做一个小型RAG问答系统，用的OpenAI嵌入+FAISS本地索引，数据量也就20万条128维向量。测试时发现一旦有5-6个用户同时提问，检索响应直接飙到3秒以上，偶尔还OOM。我查了下说FAISS是单机内存型，不适合高并发。但换Milvus或Qdrant又怕学习成本太高，而且我这项目就我一个人维护，运维太重了。有没有老哥实际对比过？或者说小规模场景下有没有什么折中方案？比如先用FAISS，然后加个简单的请求队列和缓存？还是说直接上云服务更省心？求指点。
楼主
2026-07-17
向量数据库在RAG里到底能抗多大并发？我用FAISS崩了
请 登录 后发表回复
全部回复
共 204 条
2楼
2026-09-21
FAISS本身确实不太适合多用户并发，它是为单次批量检索优化的，你5-6个人同时打进来，每个请求都触发一次全量索引搜索，内存和CPU直接抢爆。20万条128维其实不算大，但FAISS没做请求隔离和资源调度，OOM多半是因为并发时每个线程都持有索引副本或者查询缓冲区叠加。加请求队列和缓存确实能顶一阵，尤其是缓存最近问过的query结果，命中率上来后并发压力会小很多。不过队列只是把并发变成串行，延迟还是会随人数线性涨，3秒变5秒只是时间问题。折中方案可以看看Qdrant，它单机部署很简单，docker一条命令就跑起来，持久化和并发都帮你处理了，学习成本比Milvus低不少。如果就一个人维护，其实云服务也不一定省心，账单和网络延迟是另一回事，小规模反而本地Qdrant加个LRU缓存最实在。
3楼
2026-09-21
20万条128维其实不算大，FAISS崩多半是并发时多个请求同时打满CPU，跟索引类型也有关系，可以试试换IVF或者HNSW再压测看看。我之前也纠结过Milvus，后来发现Qdrant单机docker跑起来意外地轻，配置比想象中简单，维护成本没那么吓人。你说的加队列和缓存这思路没错，但缓存命中率不高的话治标不治本，队列只是把压力往后拖。如果就自己维护又不想折腾，其实可以先用Qdrant顶一阵，真到量级再考虑云服务，别一上来就上重的。
4楼
29天前
20万条128维真不算大，FAISS崩多半不是索引本身扛不住，而是你每次查询都重新加载或者没做批量合并。我之前也踩过这坑，加了LRU缓存+把并发请求攒成batch再检索，5-6个并发基本稳在几百毫秒。如果还不行，Qdrant单机docker跑起来其实半小时的事，比你想的轻。云服务省心但20万条这个量级真没必要花那钱。
5楼
4天前
我之前也遇到过类似问题，后来换了方案。