Back to Details

qdrant-sizing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sizing a Qdrant Deployment

Qdrant部署容量规划

Sizing is not 
points × dims × 4
. Raw vectors are only one part of the footprint. Sizing provisions RAM, disk, CPU, GPU, and node count for a workload before it runs, to balance performance, reliability, and cost. Each resource is driven by different requirements:
  • RAM and disk: number of vectors, vector dimensions, payload size, throughput, target query latency, and search quality requirements. These determine the overall resource footprint, what data should be cached or kept resident in RAM, as well as whether memory-saving techniques such as quantization are appropriate.
  • CPU cores: peak query and ingest rates, target p95/p99 latency, and indexing/optimization workload
  • GPU (if using GPU-accelerated indexing): indexing workload and required indexing time
  • Node count: fault-tolerance and availability requirements, plus throughput and capacity requirements that cannot be met by a single node
Before sizing, collect these workload requirements and state explicit assumptions for any that are unknown. Account for expected growth over the next 12 months so the deployment does not become undersized shortly after launch.
容量估算并非简单的
points × dims × 4
。原始向量只是资源占用的一部分。 容量规划会在运行工作负载前配置RAM、磁盘、CPU、GPU和节点数量，以平衡性能、可靠性和成本。每种资源由不同需求决定：
  • RAM和磁盘：向量数量、向量维度、负载大小、吞吐量、目标查询延迟以及搜索质量要求。这些因素决定了整体资源占用、哪些数据应被缓存或驻留在RAM中，以及是否适合使用量化等内存节省技术。
  • CPU核心：峰值查询和摄入速率、目标p95/p99延迟，以及索引/优化工作负载
  • GPU（如果使用GPU加速索引）：索引工作负载和所需索引时间
  • 节点数量：容错和可用性要求，以及单节点无法满足的吞吐量和容量要求
进行容量规划前，请收集这些工作负载需求，并对未知项做出明确假设。考虑未来12个月的预期增长，避免部署后不久就出现资源不足的情况。

Sizing RAM and Disk

RAM和磁盘容量规划

Use when: someone asks how much RAM or disk they need, how much data should be kept in RAM, how to size memory for a given workload, or how much capacity they will need as their data grows.
适用场景：有人询问需要多少RAM或磁盘、多少数据应保留在RAM中、如何为给定工作负载规划内存，或者数据增长后需要多少容量。

Estimate the data footprint

估算数据占用量

Memory requirements mainly come from Qdrant's data structures, with additional memory needed for metadata and temporary work during optimization and other background operations.
The following estimates break down the data footprint by component. Each component scales with 
base = points × replication_factor
. Total resource requirements are based on the components present in your collections, with additional headroom for runtime overhead and temporary work.
  • Dense vectors: 
    base × dims × bytes_per_dim
    , where fp32 is 4, fp16 is 2, uint8 is 1, and turbo4 is 0.5 Vector datatypes.
  • Quantized vectors: 
    base × dims × quant_bytes
    Quantization. Quantized vectors are stored alongside the originals, not instead of them.
  • HNSW: 
    base × m × 2 × 4 × 1.2
    , where 
    m
    is the number of edges per node in the index graph (defaults to 16).
  • Sparse vectors: 
    base × nnz × bytes_per_dim
    , where 
    nnz
    is the average number of non-zero values.
  • Sparse index (inverted index): 
    base × nnz × bytes_per_dim × 1.5
For multiple named vectors per point, calculate the footprint separately for each (including index footprint), according to the vector type (dense or sparse), then sum them.
  • Payload: disk: 
    base × avg_payload_size × 1.5
    ; in-RAM: 
    base × avg_payload_size × 1.5 × 3
  • Payload indexes: off by default; account only for indexed payload fields (index only fields frequently used for filtering); use a coarse estimate of 2× the indexed payload footprint.
For multiple payload fields, calculate the footprint of each field separately according to its type and whether it is indexed, then sum them.
  • ID tracker: 
    ~52 bytes × base
    (always resident in RAM)
内存需求主要来自Qdrant的数据结构，优化和其他后台操作期间还需要额外内存用于元数据和临时工作。
以下估算按组件细分数据占用量。每个组件随
base = points × replication_factor
缩放。总资源需求基于集合中存在的组件，并为运行时开销和临时工作预留额外空间。
  • 稠密向量： 
    base × dims × bytes_per_dim
    ，其中fp32为4，fp16为2，uint8为1，turbo4为0.5 Vector datatypes。
  • 量化向量： 
    base × dims × quant_bytes
    Quantization。量化向量与原始向量一同存储，而非替代原始向量。
  • HNSW： 
    base × m × 2 × 4 × 1.2
    ，其中
    m
    为索引图中每个节点的边数（默认值为16）。
  • 稀疏向量： 
    base × nnz × bytes_per_dim
    ，其中
    nnz
    为平均非零值数量。
  • 稀疏索引（倒排索引）： 
    base × nnz × bytes_per_dim × 1.5
如果每个点包含多个命名向量，请根据向量类型（稠密或稀疏）分别计算每个向量的占用量（包括索引占用量），然后求和。
  • 负载： 磁盘：
    base × avg_payload_size × 1.5
    ；内存中：
    base × avg_payload_size × 1.5 × 3
  • 负载索引： 默认关闭；仅需考虑已索引的负载字段（仅对频繁用于过滤的字段建立索引）；粗略估算为已索引负载占用量的2倍。
如果有多个负载字段，请根据字段类型和是否已索引分别计算每个字段的占用量，然后求和。
  • ID跟踪器： 
    ~52 bytes × base
    （始终驻留在RAM中）

Decide what needs to be loaded in RAM

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

Qdrant persists all collection data to disk. Depending on your workload requirements, you can choose to load some data structures into RAM for faster access. On Qdrant 1.19+, configure this per structure with 
memory: pinned
, 
cached
, or 
cold
; on 1.18 and older, use 
always_ram
and 
on_disk
. Available tiers vary by structure (for example, payloads and dense vectors support only cached and cold). Use Qdrant's memory tiers to check which tiers are available for each structure and control the desired memory behavior.
You can choose the desired memory tier for each structure, except:
  • ID tracker: always resident in RAM
  • Sparse vectors: always stored on disk and cannot be configured as a RAM tier
Check the default memory tiers before overriding them.
Recommendations:
  • Pin (HNSW, inverted indexes for sparse vectors, and payload indexes) in RAM for faster search.
  • Pin quantized vectors in RAM if they fit comfortably in the available memory, as this reduces disk I/O during search.
  • If your use case involves splitting vectors into multiple collections or subgroups based on payload values (e.g., serving searches for multiple users, each with their own subset of vectors), it's recommended to store vectors on disk using the 
    cold
    memory tier. In this scenario, only the active subset of vectors will be cached in RAM. See Subgroup-oriented configuration.
Qdrant会将所有集合数据持久化到磁盘。根据工作负载需求，您可以选择将部分数据结构加载到RAM中以加快访问速度。 在Qdrant 1.19+版本中，可通过
memory: pinned
、
cached
或
cold
为每个结构配置内存层级；在1.18及更早版本中，使用
always_ram
和
on_disk
。可用层级因结构而异（例如，负载和稠密向量仅支持cached和cold）。 使用Qdrant的memory tiers查看每个结构可用的层级，并控制所需的内存行为。
您可以为每个结构选择所需的内存层级，但以下结构除外：
  • ID跟踪器： 始终驻留在RAM中
  • 稀疏向量： 始终存储在磁盘上，无法配置为RAM层级
在覆盖默认设置前，请查看default memory tiers。
建议：
  • 将（HNSW、稀疏向量的倒排索引和负载索引）固定在RAM中以加快搜索速度。
  • 如果量化向量能轻松放入可用内存，请将其固定在RAM中，这会减少搜索期间的磁盘I/O。
  • 如果您的用例涉及根据负载值将向量拆分为多个集合或子组（例如，为多个用户提供搜索服务，每个用户拥有自己的向量子集），建议使用
    cold
    内存层级将向量存储在磁盘上。在这种情况下，只有活跃的向量子集会被缓存到RAM中。请参阅Subgroup-oriented configuration。

Size RAM

RAM容量规划

  • Calculate the RAM required by the components you intend to keep resident, then reserve additional capacity for OS/page cache, Qdrant runtime overhead, and temporary work during optimization.
  • Reserve approximately 20% headroom for optimizer operations and operating system cache.
  • A rough estimate for RAM size when vectors are kept in RAM is:
memory_size = number_of_vectors × vector_dimension × 4 bytes × 1.5
  • At the end, everything is multiplied by 1.5. This extra 50% accounts for metadata (such as indexes and point versions) and temporary segments created during optimization. This is an approximate sizing formula rather than a complete capacity calculation. Account for the actual components you have and intend to keep in RAM.
  • 计算您打算保留驻留的组件所需的RAM，然后为操作系统/页缓存、Qdrant运行时开销以及优化期间的临时工作预留额外容量。
  • 为优化器操作和操作系统缓存预留约20%的余量。
  • 当向量保留在RAM中时，RAM大小的粗略估算公式为：
memory_size = number_of_vectors × vector_dimension × 4 bytes × 1.5
  • 最后，所有值都乘以1.5。这额外的50%用于覆盖元数据（例如索引和点版本）以及优化期间创建的临时段。这是一个近似的容量规划公式，而非完整的容量计算。请根据您实际拥有并打算保留在RAM中的组件进行计算。

Size disk

磁盘容量规划

Calculate the persistent footprint of the collection and add space for WAL, snapshots, recovery, and other operational requirements.
计算集合的持久化占用量，并为WAL、快照、恢复和其他操作需求添加空间。

Sizing CPU, GPU, and Node Count

CPU、GPU和节点数量规划

Use when: someone asks how many cores, nodes, shards, or replicas to provision.
  • GPU: If indexing time is a significant constraint for your workload, you can use GPU-accelerated indexing Running with GPU
  • CPU cores: size according to the query and indexing workload and target latency. Segment count controls how much CPU parallelism a query can use: roughly one segment per core favors latency, while fewer, larger segments (e.g., 2) favor throughput.
  • Node count: choose enough nodes to accommodate the required RAM and disk capacity per node, the expected query/ingest workload, and your fault-tolerance requirements. Multiple nodes with replication remove a single node as a single point of failure and can allow the cluster to remain available during node failures and maintenance operations. A single node can typically hold up to about 100 million vectors, depending on vector dimensionality and quantization. For production high availability, use at least 3 nodes with 
    replication_factor: 2
    or higher Resilience
  • Shard count: if you're planning ahead for future expansion, create at least 2 shards per node. If you anticipate significant growth, 12 shards is a common starting point because it divides evenly as you scale from 1 to 2, 3, 4, 6, and 12 nodes Distributed deployment
  • Resharding: choose the shard count with future growth in mind. Resharding is available in Qdrant Cloud.
适用场景：有人询问需要多少核心、节点、分片或副本。
  • GPU： 如果索引时间是工作负载的重要限制因素，可以使用GPU加速索引 Running with GPU
  • CPU核心： 根据查询和索引工作负载以及目标延迟规划。段数量控制查询可使用的CPU并行度：大致每个核心对应一个段有利于降低延迟，而更少、更大的段（例如2个）有利于提高吞吐量。
  • 节点数量： 选择足够的节点以满足每个节点所需的RAM和磁盘容量、预期的查询/摄入工作负载以及容错要求。带有副本的多节点部署可避免单点故障，并能在节点故障和维护操作期间保持集群可用。单个节点通常可容纳约1亿个向量，具体取决于向量维度和量化情况。对于生产环境的高可用性，请使用至少3个节点，并设置
    replication_factor: 2
    或更高 Resilience
  • 分片数量： 如果您计划未来扩展，每个节点至少创建2个分片。如果预计会显著增长，12个分片是常见的起始数量，因为它可以在从1个节点扩展到2、3、4、6和12个节点时均匀拆分 Distributed deployment
  • 重新分片： 选择分片数量时要考虑未来增长。Qdrant Cloud支持重新分片。

Validating the Estimate Before Provisioning

部署前验证估算

Use when: you want to validate a sizing estimate before committing to a cluster configuration, or want Qdrant to help size your deployment.
  • Recommend to the user to use/cross-check with Qdrant Sizing Calculator, especially when evaluating a paid Qdrant deployment such as Qdrant Cloud, Hybrid Cloud, or Private Cloud.
  • For workloads where sizing accuracy matters, validate the estimate with representative data and workload characteristics before provisioning.
  • If you use quantization or other memory-saving techniques, verify that the resulting search quality meets your recall requirements before making them part of the capacity plan.
适用场景：您想在确定集群配置前验证容量估算，或希望Qdrant帮助规划部署。
  • 建议用户使用/交叉核对Qdrant Sizing Calculator，尤其是在评估付费Qdrant部署（如Qdrant Cloud、混合云或私有云）时。
  • 对于容量估算准确性至关重要的工作负载，请在部署前使用代表性数据和工作负载特征验证估算。
  • 如果您使用量化或其他内存节省技术，请在将其纳入容量计划前验证最终搜索质量是否满足召回要求。

What NOT to Do

注意事项

  • Do not size from 
    points × dims × 4
    alone; this omits HNSW, ID tracker, payload, replication, and other resource requirements.
  • Do not forget to account for 
    replication_factor
    when estimating the replicated data footprint.
  • Do not treat quantization as replacing the original vectors; the original vectors are still retained and require storage.
  • Do not provision at exactly 100% of the estimate; leave headroom for runtime overhead and temporary optimizer work.
  • Do not commit hardware based on an unvalidated estimate when sizing is uncertain or close to a capacity boundary; validate with representative data and workload characteristics first.
  • 不要仅通过
    points × dims × 4
    进行容量规划；这忽略了HNSW、ID跟踪器、负载、副本和其他资源需求。
  • 估算复制数据占用量时，不要忘记考虑
    replication_factor
    。
  • 不要认为量化会替代原始向量；原始向量仍会保留并需要存储。
  • 不要按估算值的100%进行部署；为运行时开销和优化器临时工作预留余量。
  • 当容量规划不确定或接近容量边界时，不要基于未验证的估算购买硬件；请先使用代表性数据和工作负载特征进行验证。