随着大语言模型（LLM）在企业中的快速落地，以 RAG（检索增强生成）为代表的向量检索场景正从实验性探索走向核心生产链路。向量数据库作为 RAG 架构的关键基础设施，其性能、使用成本与资源弹性直接影响上层 AI 应用的服务质量和 TCO。
近期，SmartX 针对榫卯超融合承载向量数据库 Qdrant（v1.18.2）的能力进行了系统性的测试与优化，测试项目涵盖百万级到千万级向量的搜索吞吐、延迟、召回率，以及内存优先/磁盘优先/向量压缩等多种配置组合。结果表明：SMTX OS 环境下的 Qdrant 性能可达到并超过 QdrantCloud 官方基准；在低内存场景下，通过向量压缩与 rescore 机制，基于 SMTX OS + NVMe 介质提供的优异存储性能，在仅 16G 内存中可承载千万级向量数据（工作集约 31GB）工作集规模的数据，同时保持 570+ QPS 和 0.93+ 召回率。
以下，我们将简要梳理向量数据库在企业 AI 场景中的应用及其对底层资源的需求，并分享 Qdrant 在榫卯超融合平台上的测试性能表现、调优方案与企业落地建议。
向量数据库成为 AI 基础设施新焦点
向量数据库并不是一个全新的概念，但在过去两年中，随着企业将大模型能力引入知识问答、智能客服、代码检索等场景，其战略地位逐渐从小众的相似性搜索工具升级为 AI 应用的核心数据基础设施。
向量数据库是 LLM 在企业落地的关键枢纽
大语言模型（如 GPT-4、Claude、DeepSeek 等）虽然在自然语言理解和生成上表现出色，但在企业实际应用中往往面临三个关键瓶颈，也是向量数据库解决的重点：
| 瓶颈 | 具体表现 | 向量数据库的核心作用 |
| 知识滞后 | 模型训练数据有截止日期，无法回答“新发生的事件或问题“。 | 将企业实时文档向量化存入向量数据库，检索后注入 LLM 上下文。 |
| 幻觉问题 | LLM 可能编造不存在的事实。 | RAG 先检索真实文档，再让 LLM 基于证据回答，大幅降低幻觉。 |
| 私有数据 | 企业核心数据不能上传到公有云模型。 | 数据留在本地向量数据库，LLM 仅接收检索结果片段。 |
其中，RAG 技术将向量数据库置于 LLM 应用的关键路径上：用户的每一次提问，都先经过向量检索找到最相关的企业内部文档/知识，再由 LLM 综合这些信息生成回答。向量数据库的检索质量（召回率）和检索性能（QPS、延迟），直接决定了上层 AI 应用的用户体验上限。
除了 RAG 之外，向量数据库还在更多 AI 应用场景中发挥着不可替代的作用：
| 场景 | 说明 | 代表行业实践 |
| 智能客服 / 知识库 | 将产品手册、FAQ、工单记录向量化，实现语义级检索 | 金融、运营商、制造业的 IT 服务台 |
| 代码助手 | 将代码库向量化，支持自然语言搜索代码片段 | 企业内部的 Code Search 平台 |
| 推荐系统 | 基于用户行为 embedding 进行相似用户/内容推荐 | 电商、内容平台的个性化推荐 |
| 图像/视频检索 | 以图搜图、视频帧相似性比对 | 安防、医疗影像分析 |
| 多模态搜索 | 跨文本、图像、音频的统一语义搜索 | 企业数据中台的统一检索入口 |
这些场景的共同特点是：数据规模大（百万到亿级向量）、查询延迟要求高（百毫秒级）、并发访问密集。这对承载向量数据库的底层基础设施提出了明确要求：高性能计算、低延迟存储、弹性扩缩容能力。
Qdrant：高性能开源向量数据库
Qdrant 是用 Rust 语言编写的高性能向量搜索引擎，在 VectorDBBench Leaderboard 中长期位居第一梯队。其核心优势包括：
- 高性能 HNSW 索引：基于分层可导航小世界图（Hierarchical Navigable Small World）算法，在召回率和搜索速度之间实现优秀的平衡。
- 丰富的量化策略：支持 Scalar INT8、Product Quantization、Binary Quantization，在精度和资源间灵活取舍。
- 灵活的存储模式：支持内存优先和磁盘优先两种模式，适配不同硬件配置。
- gRPC 原生支持：相比 REST API，提供更低的长尾延迟和更高的吞吐。
虽然混合检索（Hybrid Search）、传统数据库集成向量以及图谱与智能体驱动（GraphRAG / Agentic RAG）等技术正在 RAG 场景掀起新趋势，但依旧不能替代独立向量数据库在企业场景中的作用。以 Qdrant 为代表的性能优越、突破底层技术的专用引擎，非但不会退场，反而成为构建企业级 AI 基础设施的强大底座。因此，围绕 Qdrant 等专用向量数据库开展性能验证，有助于企业在 AI 基础设施规划中更准确地评估资源配置与部署路径。
测试模型与平台环境
验证目标
本次测试围绕以下四个核心目标展开：
- 性能基准验证：对比 SMTX OS 环境下 Qdrant 与 VectorDBBench 官方榜单中 QdrantCloud 同规格实例的性能表现。
- 资源敏感性分析：系统评估内存容量、存储配置对向量检索性能的影响，为用户提供资源配置参考。
- 向量压缩收益评估：验证 INT8 量化 + rescore 机制在降低内存占用的同时保持检索精度的效果。
- 调优空间展示：展示 SMTX OS 平台上 Qdrant 在不同参数组合下的性能变化范围，帮助用户理解调优路径。
压测工具与数据集
| 项目 | 内容 |
| 压测工具 | VectorDBBench v1.58.0（Zilliz 开源的向量数据库基准测试工具） |
| 数据集 | Cohere 1M / 10M vectors, 768 dimensions（文本 embedding 领域权威测试集） |
| 搜索协议 | gRPC（QdrantCloud client 模式） |
| 测试场景 | Search Performance Test |
| 搜索参数 | hnsw_ef = 100, 120, 150, 200, 400 |
| 并发档位 | 1, 5, 10, 20, 30, 40, 60, 80（每档持续 30s） |
| topK | 100 |
- 为什么选择 Cohere 768 维数据集？
768 维是当前主流文本 embedding 模型（如 Cohere Embed v3、BERT 系列）的典型输出维度，10M 规模代表了中型企业知识库（数千万文档片段）的典型数据量。这一选择使得测试结果对企业实际规划具有较强的参考意义。
测试硬件环境
本次测试所有角色均部署在三节点榫卯超融合（SMTX OS）集群上：
集群物理节点配置（单节点）
| 硬件项目 | 型号与配置 |
| CPU | Intel Xeon Gold 5218R @ 2.10GHz |
| 内存 | 384 GB |
| 缓存盘 | Intel DC P5620 1.6TB NVMe SSD × 4 |
| 数据盘 | Seagate Exos 7E8 8TB HDD × 4 |
| 存储网络 | Mellanox ConnectX-5（支持 RDMA） |
集群关键参数
| 参数项 | 配置值 |
| 集群部署模式 | 分层（NVMe 缓存 + HDD 容量层） |
| Boost 模式 | 启用 |
| RDMA 网络 | 启用 |
| 副本策略 | 2 副本 |
测试虚拟机配置
| 角色 | vCPU | 内存 | Guest OS | 说明 |
| Qdrant 服务端 | 16（独占） | 64G / 16G | Ubuntu 22.04.5 LTS（关闭 swap） | Docker 部署 Qdrant v1.18.2 |
| VDBBench 客户端 | 8（独占） | 32G | Ubuntu 24.04.2 LTS |
说明：Qdrant 服务端和 VDBBench 客户端部署于同一 SMTX OS 集群中两台不同的虚拟机上，服务端采用 CPU 独占和透传模式，确保性能测试不受资源争抢干扰。
测试模型说明
HNSW 索引与关键参数
Qdrant 使用 HNSW（Hierarchical Navigable Small World）图索引来完成近似最近邻搜索（ANN）。理解以下参数有助于解读测试结果：
| 参数 | 说明 | 本次测试取值 |
| m | HNSW 图中每个节点的最大连接数，越大则索引质量越高但内存开销越大 | 16 |
| hnsw_ef | 搜索阶段的候选队列大小，越大则召回率越高，但延迟越大 | 100/120/150/200/400 |
| ef_construct | 索引构建阶段的候选队列大小，影响构建速度和质量 | 200 |
两种存储配置模式
| 配置模式 | HNSW 索引 | 原始向量 | Payload | 适用场景 |
| 内存优先 （默认） |
加载到进程内存 | InRamChunkedMmap（file-backed mmap，倾向驻留内存） | 默认 on-disk | 内存充足，追求极致性能 |
| 磁盘优先 （on_disk） |
mmap 磁盘文件 | ChunkedMmap（按需加载） | 显式 on-disk | 内存受限，降低常驻内存压力 |
需要注意：
- 磁盘优先模式并非每次压测都从磁盘读取。Qdrant 通过 mmap/file-backed storage 访问数据，查询访问过的数据页会进入 OS page cache。
- 当内存充足时，热数据仍然缓存在内存中，查询性能与内存优先模式接近。
- 当内存不足时，OS 可以回收冷页，从而降低进程常驻内存压力——代价是可能产生更多磁盘随机读 I/O。
性能对比：SMTX OS vs. VDBBench 官方披露数据
对标说明：VectorDBBench Leaderboard 中 QdrantCloud 的参考结果，其服务端运行在 Intel Xeon Platinum 8375C 上，客户端虚拟机规格为 8C32G。本次 SMTX OS 环境使用与其相同的测试数据集、测试场景和参数配置，确保对比的公平性。
1M 数据集性能对比
在 100 万条 768 维向量的搜索性能测试中，SMTX OS 环境下的 Qdrant 表现全面超越官方基准：
| hnsw_ef | SMTX OS QPS | 官方参考 QPS | QPS 提升 | SMTX OS P99 (ms) | 官方参考 P99 (ms) | P99 降低 |
| 100 | 1,609 | ~1,200 | +34% | 4.5 | ~5.0 | -10% |
| 120 | 1,214 | ~950 | +28% | 4.8 | ~5.5 | -13% |
| 150 | 1,185 | ~820 | +45% | 5.1 | ~6.0 | -15% |
| 200 | 894 | ~650 | +38% | 6.4 | ~7.5 | -15% |
| 400 | 518 | ~380 | +36% | 8.7 | ~10.0 | -13% |
可以看到，在 1M 数据集上，SMTX OS 环境下 Qdrant 的 QPS 相比官方基准提升 28%-45%，P99 延迟降低 10%-15%，召回率基本一致。这验证了 SMTX OS 超融合平台在向量数据库场景下具备出色的计算和 I/O 性能。
10M 数据集性能对比
当数据规模扩大到千万级时，SMTX OS 环境的性能优势仍然保持：
| hnsw_ef | SMTX OS QPS | 官方参考 QPS | QPS 提升 | SMTX OS P99 (ms) | 官方参考 P99 (ms) | P99 降低 |
| 100 | 549 | ~420 | +31% | 6.7 | ~8.0 | -16.25% |
| 120 | 483 | ~370 | +31% | 7.0 | ~8.5 | -17.65% |
| 150 | 413 | ~320 | +29% | 7.8 | ~9.5 | -17.89% |
| 200 | 334 | ~260 | +28% | 9.0 | ~11.0 | -18.18% |
| 400 | 196 | ~150 | +31% | 13.4 | ~16.0 | -16.25% |
可以看到，在 10M 数据集上，SMTX OS 环境下 Qdrant 的 QPS 稳定领先官方基准约 30%，P99 延迟降低超 15%。说明即便在千万级向量规模下，SMTX OS 平台仍能为向量检索提供一致的性能保障。
小结
榫卯超融合平台具备承载生产级向量数据库的能力。 在同等测试条件下，SMTX OS 环境中的 Qdrant 搜索吞吐和延迟均优于公有云上的 QdrantCloud 同规格参考结果。这意味着企业可以在自己的数据中心内，利用 SMTX OS 平台构建 RAG 等 AI 应用的数据底座，在满足高性能要求的同时，兼顾数据安全与本地化部署的合规要求。
调优方案分析：向量数据库对内存与存储的真实需求
向量数据库的性能高度依赖硬件资源配置，尤其是内存容量和存储性能。理解二者之间的关系，是做出合理配置决策的前提。以下我们将对比不同配置策略（内存优先 vs. 磁盘优先）在不同内存条件下带来的性能表现，并基于此设计调优方案。
内存充足时（16C64G, 10M 数据集）
在 64G 大内存场景下，10M 768D 原始向量数据集（约 31GB）可以完全被内存承载。
两种存储配置的性能对比如下：
| 配置 | QPS | P99 延迟 (ms) | 数据大小 | 缓存占用 | 搜索 IOPS |
| 内存优先（默认） | 549 | 6.7 | 31 GB | 30 GB | 0 |
| 磁盘优先（on_disk） | 493 | 6.9 | 31 GB | 27 GB | ~135K（4K 随机读） |
核心发现：
- 内存优先配置下，HNSW 索引和原始向量加载在内存中，搜索阶段无磁盘 I/O，且 QPS 最高、延迟最低。
- 磁盘优先配置的 QPS 约为内存优先模式的 90%，仍保持在可接受范围。但由于通过 mmap 访问数据，搜索过程中会产生 4K 随机读 I/O（实测峰值高达 135K+ IOPS）。
内存受限时（16C16G, 10M 数据集）
当内存降低到 16G 时，31GB 的原始向量规模已远超可用内存。这一场景真实反映了企业在有限的硬件预算下可能面临的配置选择：
| 配置 | QPS | P99 延迟 (ms) | 搜索 IOPS | 备注 |
| 内存优先（默认） | 4.5 | 742 | 105.5K (block size:55K) |
大量请求超时，性能严重下降 |
| 磁盘优先（on_disk） | 26.1 | 180 | 368K (block size:4K) |
可稳定完成测试，但 QPS 受限 |
| 磁盘优先 + io_uring | 26.2 | 174 | 357K (block size:4K~33K) |
提升有限，瓶颈不在 IO 提交方式 |
核心发现：
- 默认配置在内存不足时性能急剧劣化：QPS 仅 4.5，P99 延迟高达 742ms，多并发下大量请求超时。这是因为默认配置倾向于将数据加载到内存中，一旦物理内存不足，系统频繁在内存和磁盘之间换入换出，就会触发严重的性能颠簸。
- 磁盘优先配置在低内存下更稳定：QPS 从 4.5 提升到 26，P99 延迟从 742ms 降低到 180ms，这是通过 mmap 机制让虚拟机 OS 按需管理内存页换入换出实现的。
- 瓶颈在随机读模式而非 I/O 提交协议：启用 io_uring 后性能提升微乎其微，说明主要瓶颈在于 4K 随机读的物理 I/O 数量本身，而非 I/O 提交方式。
调优 tips
| 场景 | 推荐配置 | 资源需求 |
| 追求极致性能、内存充足 | 内存优先模式 | 建议内存 ≥ 数据集大小 × 1.2 |
| 内存与数据集规模接近 | 磁盘优先模式 | 需关注存储 IOPS 能力 |
| 内存明显不足（< 数据集 50%） | 需引入向量压缩（见下文） | 需要高性能存储支撑 |
深度调优：开启向量压缩，小内存也能跑出高性能
针对内存明显不足的情况，向量压缩（Quantization）提供了可行的优化方向。
向量压缩的原理
Qdrant 支持将原始 Float32 向量压缩为 INT8 精度，数据量缩减至原来的 1/4：
原始 Float32 向量: 10M × 768 × 4 bytes ≈ 30.7 GB
INT8 压缩向量: 10M × 768 × 1 byte ≈ 7.2 GB 压缩后可装入 16G 内存
压缩后的搜索流程变为：先用 INT8 向量进行近似搜索，再选择性地读取原始向量进行精确重排序（rescore）。
低内存（16C16G）场景下的压缩收益
| 配置 | QPS | P99 延迟 (ms) | Recall | 内存利用率 | 搜索 IOPS |
| 磁盘优先，不压缩 | 26.1 | 180 | 0.933 | 9.5% | 368K |
| 磁盘优先，INT8，always_ram=false | 836 | 5.0 | 0.853 | 9.6% | 127K |
| 磁盘优先，INT8，always_ram=true | 819 | 5.2 | 0.860 | 55.8% | 0 |
| 磁盘优先，INT8 + rescore，always_ram=false | 607 | 19.7 | 0.932 | 9.5% | 62.7K |
| 磁盘优先，INT8 + rescore，always_ram=true | 573 | 18.7 | 0.931 | 56.0% | 91.9K |
可以看到，在纯 INT8 压缩配置下，QPS 从 26 提升到 800+，性能提升超过 30 倍。
数据解读
纯压缩：极致性能，精度有损
启用 INT8 压缩后：QPS 从 26 飙升至 800+（提升约 32 倍），P99 延迟从 180ms 降至 ~5ms（降低约 97%），但 recall 从 0.93 降至 ~0.85——约有 15% 的真实最近邻未被命中。这种方式适用于召回率容忍度较高的场景（如模糊搜索、探索式检索），或作为初筛阶段。
压缩 + Rescore：精度与性能的最佳平衡
启用 INT8 压缩后，再开启 rescore（重排序），搜索流程为 INT8 向量初筛 → 读取候选原始向量 → 精确重排序 → 返回 topK。可以看到，Recall 恢复至 0.93+，与未压缩场景持平；QPS 仍可保持在 570-607——是未压缩时的 20+ 倍；P99 延迟约 19ms——完全满足在线服务 SLA 要求。
SMTX OS 自研分布式存储的加持
值得特别关注的是 always_ram=false 配置的表现：
| 对比维度 | always_ram=true （量化向量常驻内存） |
always_ram=false （量化向量走 mmap） |
| 内存利用率 | 56% (~9GB) | 9.5% (~1.5GB) |
| QPS（INT8 + rescore） | 573 | 607 |
| P99 延迟 | 18.7 ms | 19.7 ms |
| 搜索 IOPS | 91.9K | 62.7K |
在 always_ram=false 下，仅用约 1.5G 内存就能在千万级向量上实现 600+ QPS 和 0.93 recall。 这得益于 SMTX OS 分布式存储系统提供的低延迟 I/O 能力：虽然量化向量以 mmap 方式按需访问，但当 OS page cache 与高性能存储协同工作时，实际访问延迟接近于内存访问。在这种模式下，存储 IOPS 峰值为 62.7K。
给用户的配置建议
| 内存配置 | 推荐策略 | 预期性能 |
| 内存 ≥ 数据×1.2 | 默认内存优先配置 | 极致 QPS + 最低延迟 10M/768D: ~550 QPS |
| 内存 = 50%-100% 数据量 | 磁盘优先配置 + SMTX OS+NVMe SSD | 稳定可用的性能
10M/768D: ~490 QPS |
| 内存 < 50% 数据量 | INT8 压缩 + rescore +SMTX OS + NVMe SSD | 高吞吐 + 高精度
10M/768D: ~600 QPS Recall 0.93+ |
总结
通过本次系统的性能验证，可以得出以下核心结论：
SMTX OS 是向量数据库的可靠底座
在 1M 和 10M 的 Cohere 768 维数据集上，SMTX OS 环境中的 Qdrant v1.18.2 在 QPS 和 P99 延迟方面均优于 QdrantCloud 官方基准，QPS 领先约 30%，P99 延迟降低约 15-20%。企业可以放心地在榫卯超融合平台上部署生产级向量数据库工作负载。
灵活的资源配置适配多元业务需求
SMTX OS 的弹性虚拟化能力使得用户可以根据业务需求灵活调整计算和内存资源：
- 高配大内存（如 16C64G）：直接使用默认配置，获得极致检索性能。
- 小内存场景（如 16C16G）：通过磁盘优先配置，在内存受限时仍保持稳定服务能力。
向量压缩 + 高性能存储 = 降本增效
SMTX OS 的 NVMe 全闪存储为向量压缩策略提供了关键的性能保障。启用 INT8 压缩 + rescore 后：
- 仅需不到 2GB 的常驻内存即可承载 31GB 原始数据的向量检索。
- QPS 达到 600+，P99 延迟约 19ms，Recall 恢复至 0.93+。
- 搜索 IOPS 仅约 63K，远在 NVMe SSD 能力范围内。
这意味着企业可以用更少的硬件资源支撑更大规模的 AI 应用，在性能与成本之间找到最优平衡。
向量数据库调优有明显的规律可循
- hnsw_ef 是影响搜索质量与性能的核心参数：ef 越大 → recall 越高，但 QPS 下降、延迟上升。
- 内存容量是决定向量数据库性能的第一要素：内存充足时，on-disk 配置的性能接近纯内存模式。
- 存储 IOPS 能力是低内存场景下的关键支撑：高 IOPS 存储可以显著缓解内存不足带来的性能损失。
- 向量压缩 + rescore 是在有限内存下兼顾性能与精度的最优实践。
附录：关键性能指标速查
| 指标 | 说明 | 理想趋势 |
| QPS | 每秒查询数，衡量系统吞吐能力 | 越高越好 |
| P99 Latency | 99% 请求的延迟上限，反映长尾性能 | 越低越好 |
| Recall | 搜索结果命中真实近邻的比例 | 越接近 1.0 越好 |
| load_dur | 数据加载 + 索引构建总耗时 | 可接受的范围内尽量低 |
| IOPS | 搜索阶段磁盘读写的每秒操作数 | 关注是否达到存储瓶颈 |
参考资料：
1.Qdrant 官方网站
https://qdrant.tech/
2.VectorDBBench Leaderboard 官方网站
https://zilliz.com/vdbbench-leaderboard?dataset=vectorSearch
推荐阅读：
榫卯AI平台1.1：增强GPU虚拟化与模型治理能力，让资源使用和模型管理更高效
从MES容器化到企业AI：云原生驱动下的某船舶制造用户基础设施演进之路
