qdrant-sizing

估算 Qdrant 部署规模

估算规模并非 points × dims × 4。原始向量只是占用量的一部分。 在工作负载运行前，为其配置 RAM、磁盘、CPU、GPU 和节点数量，以平衡性能、可靠性和成本。不同资源受不同要求影响：

• RAM 和磁盘：向量数量、向量维度、Payload 大小、吞吐量、目标查询延迟和搜索质量要求。这些因素决定总体资源占用、哪些数据应缓存或常驻 RAM，以及量化等节省内存的技术是否合适。
• CPU 核心数：峰值查询和写入速率、目标 p95/p99 延迟，以及索引和优化工作负载
• GPU（如果使用 GPU 加速索引）：索引工作负载和所需索引时间
• 节点数量：容错和可用性要求，以及单个节点无法满足的吞吐量和容量要求

估算规模前，先收集这些工作负载要求，并为未知项明确列出假设。按 12 个月后的预期向量数量进行估算，而非当前数量，避免部署上线后不久就容量不足。

估算 RAM 和磁盘

适用于：有人询问需要多少 RAM 或磁盘、应将多少数据保存在 RAM 中、如何根据给定工作负载估算内存，或数据增长后需要多少容量。

估算数据占用量

• 阅读 计算 RAM 和磁盘大小，并使用相应公式计算每个组成部分。不要凭记忆估算：公式和默认值会随版本变化。
• 分别估算每个组成部分：稠密向量、量化向量、HNSW 索引、稀疏向量及其索引、Payload、Payload 索引和 ID 跟踪器。每个组成部分都按 base = points × replication_factor 缩放。
• 对于每个点包含的多个命名向量或 Payload 字段，分别估算后再求和。
• 在原始向量之外，额外计算量化向量：Qdrant 会将压缩副本与原始向量一同存储，而非替代原始向量。TurboQuant 向量数据类型则不同，它会替代原始向量：turbo16（1.20+）每个维度占用 2 字节，turbo8（1.20+）占用 1 字节，turbo4（1.19+）占用 0.5 字节，而 float32 占用 4 字节。稠密向量的维度范围为 1 到 65,536。
• 启用 scoring 的全文索引（BM25，1.20+）会存储文档长度和词元位置，因此比仅用于过滤的全文索引需要更多 RAM 和磁盘。
• 每元素 Payload 索引（适用于对象数组的 nested 选项，1.20+）无论内存层级如何，都会在 RAM 中保留元素到点的映射：每个此类索引按每个点约 4 字节预算。
• 仅对用于过滤的字段计算 Payload 索引；只为频繁用于过滤的字段建立索引。

确定需要加载到 RAM 中的内容

Qdrant 会将所有结构持久化到磁盘，因此磁盘需要容纳完整的数据占用量。RAM 只容纳你保留在 RAM 中的结构，因此 RAM 和磁盘需要分别规划大小。综合规划。 在 Qdrant 1.19 或更高版本中，可通过 memory: pinned、cached 或 cold 为每种结构设置内存层级。覆盖默认设置前，请查看默认内存层级；在 1.18 或更早版本中，请参阅旧版设置。

建议：

• 将 HNSW、稀疏向量倒排索引和负载索引保留在 RAM 中，以加快搜索速度。
• 如果量化向量能轻松装入可用内存，就将其固定在 RAM 中，并将原始向量移至 cold 层以进行重新评分。这是量化降低 RAM 占用的主要方式。
• 如果你的用例需要根据负载值将向量拆分到多个集合或子组中（例如，为多位用户提供搜索服务，每位用户都有自己的向量子集），请将向量存储在 cold 内存层级中，并根据活动点子集而非整个集合来规划 RAM 大小。面向子组的配置。
• 向量存储在磁盘上时，RAM 大小会影响延迟：RAM 中保留的向量数量减少一半，搜索延迟大致会翻倍。侧重存储的配置。

预留余量

• 在 RAM 和磁盘总量的基础上，各增加约 20% 的余量。RAM 余量用于覆盖操作系统页缓存、运行时开销和优化器临时工作；磁盘余量用于覆盖 WAL、快照和临时分段。

规划 CPU、GPU 和节点数量

适用场景：有人询问应配置多少核心、节点、分片或副本。

• GPU： 如果索引时间对你的工作负载有显著影响，可以使用 GPU 加速索引使用 GPU 运行
• CPU 核心： 没有计算公式；应通过目标 QPS 和延迟下的负载测试确定核心数。分段数量决定查询可使用的 CPU 并行度：每个核心大致对应一个分段有利于降低延迟，而分段较少、规模较大（例如 2 个）则有利于提高吞吐量。
• 节点数量： 使用节点数量中的公式，根据 RAM 总量和每个节点可用的 RAM 计算节点数量，然后结合预期的查询与写入负载以及容错要求进行检查。单个节点通常最多可容纳约 1 亿个向量，具体取决于维度、数据类型和量化方式。生产环境要实现高可用，至少使用 3 个节点，并将 replication_factor: 2 或更高值作为弹性配置。
• 分片数量： 如果要为未来扩容做准备，每个节点至少创建 2 个分片。如果预计会大幅增长，12 个分片是常见的起步选择，因为从 1 个节点扩展到 2、3、4、6 和 12 个节点时都可以均匀划分。分片数量
• 重新分片： 选择分片数量时应考虑未来增长。Qdrant Cloud 支持重新分片。

在配置前验证估算结果

适用场景：在确定集群配置前，你想验证容量估算结果，或希望 Qdrant 帮你规划部署规模。

• 建议用户使用或对照 Qdrant 容量规划计算器，尤其是在评估 Qdrant Cloud、Hybrid Cloud 或 Private Cloud 等付费 Qdrant 部署时。
• 对于容量规划准确性很重要的工作负载，请在配置资源前，使用具有代表性的数据和工作负载特征验证估算结果。
• 如果使用量化或其他节省内存的技术，请在将其纳入容量规划前，确认最终搜索质量符合召回率要求。

不要这样做

• 不要只按 points × dims × 4 估算容量；这种算法没有计入 HNSW、ID 跟踪器、负载、复制和其他资源需求。
• 估算复制数据占用时，不要忘记考虑 replication_factor。
• 不要把量化视为原始向量的替代方案；原始向量仍会保留，因此仍需要存储空间。
• 不要只按估算值的 100% 配置资源；应预留余量，以应对运行时开销和优化器的临时工作。
• 如果容量估算存在不确定性或接近容量边界，不要依据未经验证的估算结果确定硬件配置；请先使用具有代表性的数据和工作负载特征进行验证。