2026年年中，不少企业开始把RAG系统从云端搬回本地。原因不完全是隐私，主要是API调用费太贵，而且业务需要更快响应。一家中型电商平台算过：把基于GPT-4o的客服和推荐系统迁到本地后，API年费从180万降到约45万硬件与运维成本。
构建私有化RAG，存储层是成本大头。企业现在纠结的不是用不用向量数据库，而是怎么混合部署才能把钱花值。
Milvus vs Qdrant：2026年怎么选？
Milvus 2.5.x 功能全面，分布式架构成熟，索引类型多（如GPU加速的IVF_FLAT、IVF_PQ）。社区基准测试显示，在千万级向量、768维数据下，P99延迟稳定在8ms以内。但资源消耗高：生产级3节点集群建议至少256GB内存和NVMe SSD。对于数据量在亿级以下、查询QPS低于500的企业，这个规格有点超配。
Qdrant 1.9 用Rust编写，内存效率高。官方数据显示，同硬件下内存占用比Milvus低30%-40%。它的量化存储功能可将向量从float32压缩到int8，存储空间省75%，检索精度损失控制在1%以内。对以文本Embedding为主的场景（如文档问答）很合适。一家SaaS公司用Qdrant存储了2.3亿条客服对话摘要，INT8量化后，存储成本从每月800元云盘费用降到自有服务器每月150元电费和硬件摊销。
关键看数据规模和精度容忍度：向量维度高、召回率要求高（如法律、医疗）选Milvus；数据量大、以文本为主、追求最低单条成本选Qdrant的量化方案。
时序数据库：RAG中容易被忽略的实用组件
不少RAG需求涉及实时数据、带时间戳的文档版本、IoT读数。用传统向量数据库处理这些时间序列数据又笨重又贵。像TDengine 3.x或InfluxDB 3.0这样的时序数据库，对带时间戳的数据写入、压缩和按时间范围查询有原生优化。
典型混合架构：Qdrant/Milvus存语义，时序数据库存时态。举例：工业设备故障预警RAG，故障描述和专家知识存向量库，设备历史传感器数据（温度、振动）实时写入TDengine。查询“某型号设备近一个月内伴随温度异常的故障案例”时，时序库先圈定时间窗口和异常数据点，再去向量库检索匹配语义描述。避免了海量时序数据向量化带来的存储浪费。
中型企业轻量方案：8万元内的混合存储
适合月营收5000万到5亿、有IT团队的中型企业。
核心检索层：Qdrant单节点集群。硬件：64GB内存，2TB NVMe SSD，8核CPU。Qdrant 1.9版本，默认INT8量化。可支撑约5000万条768维文本Embedding向量，满足内部知识库、客服系统。
时序数据层：TDengine 3.x企业版单节点。对时序数据列式压缩，100万条设备数据通常小于100MB。存储所有带时间属性的元数据、日志、传感器读数。
编排与应用层：LangChain或LlamaIndex，通过自定义检索器实现混合查询：先调用时序库API获取时间范围内ID列表，再作为过滤条件传入向量库进行语义检索。
模型层：Embedding用BGE-M3，生成模型用Qwen2.5-14B或Llama 3.1-8B，通过vLLM或TGI本地部署。
总硬件成本8万元以内，年度运维主要是电费人力。相比全部用云向量数据库，数据规模超过500GB后成本优势明显。
索引优化技巧：再省一步
分级索引：在Qdrant中为冷数据单独创建Collection，用更激进压缩（如PQ乘积量化）或更小内存分配。
元数据前置过滤：将文档的部门、类别、保密等级等结构化元数据与向量一起存。查询时先通过元数据过滤掉大量无关文档，再在缩小后的候选集内进行向量相似度计算。可将P99延迟再降20%-30%。
Embedding缓存：对高频查询的短文本（如常见FAQ）生成的Embedding向量进行本地缓存，避免重复计算。简单LRU缓存就能命中30%以上重复查询。
数据不仅有语义，还有时间和结构。混合架构更贴近真实需求。
（关于模型本地化部署的更多实战细节，可参考《A100跑大模型：Candle比PyTorch省了23%显存》和《把卷积层塞进iOS 20》，后者动态精度切换技巧对服务器端GPU资源紧张也有启发。）
