关于本站

向量库容量测算台（aivector.cn）只干一件事：给定向量维度、条数、存储精度和索引类型， 算出向量库的内存占用下限，并且把「算得准的」和「算不准的」分开告诉你。

和通用换算工具的区别

这个问题值得说清楚，因为表面上看「输入几个数、输出一个数」都一样。

• 通用换算做的是「同一个量换个说法」。汇率换算、日期天数、单位换算，输入和输出说的是同一件事，只是单位不同。 换算规则本身没有争议，也不存在「算不准的部分」——1 米就是 100 厘米，不会因为实现不同而变。
• 本站做的是「按算法结构推算一个系统的资源占用」。输入的是数据规模和算法参数，输出的是一个跟实现有关的资源量。 这里面天然有一部分算得准（原始数据的字节数），一部分只能按公开算法结构推（图的邻居表、PQ 的码本）， 还有一部分本站根本算不准（对象头、内存对齐、碎片、元数据、副本、构建峰值）。 所以本站的输出不是一个数，是三段带确定性标注的数，外加一句「这是下限」。
• 换句话说：通用换算的答案是唯一的，本站的答案是有下界的。这两件事的做法和责任边界完全不同，所以分成两个站。

本站也不是这些

• 不是选型推荐站。本站从头到尾不提任何一家向量数据库的名字作为建议对象，不说谁好谁坏，不给「该用哪个」的答案。算内存和选产品是两件事。
• 不是能力对比站。本站不做功能矩阵、不做横向评测、不列谁支持什么特性。
• 不是性能测试站。内存占用和查询延迟、吞吐、召回率是完全不同的维度。本站只碰内存占用这一个维度。

怎么看本站给的数

• 第一段（精确）纯算术：条数 × 维度 × 每分量字节数。这个数不会错，除非你输入的规模本身不对。
• 第二段（按算法结构推）公式来自 FAISS 官方 wiki、FAISS 源码和 hnswlib 文档，出处和原文引用都在 公式出处 页上。这一段不含任何实现的额外开销。
• 第三段（算不准）只列项目，一个数字都不给。本站宁可承认算不准，也不给一个看上去精确、实际是拍的数。

拿它来干什么

最常见的用法是先排除明显不可行的方案：如果连下限都塞不进你打算用的机器，那就不用再往下谈了。 第二种用法是比较自己的几个参数方案：同一份数据换精度、换索引类型、改 M 或改 PQ 参数， 内存这一项的相对差距是多少。至于哪个方案检索效果更好，本站不评估，那需要你拿自己的数据去测。

单位

本站一律用二进制单位：1 GiB = 1024³ 字节 = 1,073,741,824 字节。不用 1000³ 的 GB。 两者在 GiB/GB 这一级差约 7%，容量规划里这个差距不小，所以口径写死在 公式出处 页上。