Milvus与Qdrant选型实测:千万级向量下的部署与延迟对比
在内容审核场景中,我们需对每日新增的200万条文本向量进行近实时检索。本文基于Milvus 2.4.5与Qdrant 1.9.7,在相同的16C32G裸金属环境下完成部署,并使用500万条768维向量(SGPT-125M生成)进行压测。实测结果显示:Qdrant在P99查询延迟上比Milvus低38%(23ms vs 37ms),但Milvus在批量写入吞吐上反超42%(8.2k QPS vs 4

在需求、Bug和灵感之间来回奔跑。关注软件测试,主要分享架构设计、开发效率提升和日常踩坑;不追求堆砌概念,只记录验证过的经验。持续更新,尽量让每一篇内容都有实际价值。
在内容审核场景中,我们需对每日新增的200万条文本向量进行近实时检索。本文基于Milvus 2.4.5与Qdrant 1.9.7,在相同的16C32G裸金属环境下完成部署,并使用500万条768维向量(SGPT-125M生成)进行压测。实测结果显示:Qdrant在P99查询延迟上比Milvus低38%(23ms vs 37ms),但Milvus在批量写入吞吐上反超42%(8.2k QPS vs 4
一个内部报表接口,线上P95延迟从812ms降到96ms,吞吐量提升5.2倍。过程中使用了py-spy、cProfile、EXPLAIN ANALYZE等工具定位瓶颈,发现主要耗时不在SQL而在N+1查询与模板渲染。通过引入Redis缓存、查询合并、Pydantic序列化优化,最终将数据库连接数从峰值120降到35。本文记录完整调优路径、代码改动与压测数据,含FastAPI 0.104、Postg
在LLM驱动的Text-to-SQL任务中,Prompt设计直接决定输出质量与推理成本。本文基于OpenAI GPT-4o-turbo(2024-08-06快照),针对证券交易查询场景,对比了5种Prompt模板的准确率、Token消耗与延迟。通过引入“Schema感知裁剪+示例动态检索+输出格式约束”三层结构,最终将SQL生成准确率从68%提升至91%,单次查询Token成本从2,184降至1,