向量库到底要占多少内存
给定维度、条数、精度和索引类型，本站把内存占用拆成三段算：公式算得准的、按公开算法结构可推的、本站算不准的。 每一段都标清楚确定性，不把推算混进精确值里。
本站边界（先说清楚）
本站不推荐任何向量数据库产品、不比价、不评估召回率或检索质量、不给选型建议、不接任何数据库、不上传不保存任何数据——所有计算都在你自己的浏览器里完成，关掉页面就没了。 算出来的是下限估算，真实占用只会更高。单位一律用二进制单位（1 GiB = 1024³ 字节 = 1,073,741,824 字节），不是 1000³ 的 GB。
本站不推荐任何向量数据库产品、不比价、不评估召回率或检索质量、不给选型建议、不接任何数据库、不上传不保存任何数据——所有计算都在你自己的浏览器里完成，关掉页面就没了。 算出来的是下限估算，真实占用只会更高。单位一律用二进制单位（1 GiB = 1024³ 字节 = 1,073,741,824 字节），不是 1000³ 的 GB。
输入
常驻内存下限 · HNSW（分层可导航小世界图）
2.980 GiB
= 3,200,000,000 字节。HNSW 同时常驻原始向量和邻居表。 这是下限，真实占用只会更高——第三段列的那些本站算不准。
一、公式确定的部分 精确
这一段是算术，不含任何推测原始向量数据
2.861 GiB
3,072,000,000 字节
1000000 条 × 768 维 × 4 字节/分量
二、按公开算法结构可推的部分 按算法结构推算
按算法结构推的，不含任何实现的额外开销HNSW 邻居表（图结构）
122.1 MiB
128,000,000 字节
1000000 条 × M=16 × 2 × 4 字节/连接（FAISS 的公开公式就是 M×2×4 字节/条；×2 对应第 0 层的邻居容量 2M）
这一段合计122.1 MiB128,000,000 字节
三、本站算不准的部分 不给数字
下面每一项都会让真实占用高过上面的数，但没有可引用的公开公式，本站只提醒、不编数- 对象头与内存对齐
每种语言、每个实现给每块内存加的头部和补齐字节都不一样。 - 内存碎片
分配器行为随负载和运行时长变化，不是一个静态数。 - 删除标记与墓碑
删过多少、什么时候真正回收，取决于实现和你的写入模式。 - 元数据与过滤字段
每条向量挂多少标量字段、字符串多长，只有你自己知道。 - 多副本与 WAL / 预写日志
副本数、日志保留时长都是部署参数，不是算法参数。 - 构建期的临时峰值
建图、训练码本、合并段的时候会短时占用远超稳态的内存。 - 检索时的运行时开销
并发查询的候选集、优先队列、结果缓冲都随并发数变化。
同样的数据，换精度能省多少
只比原始向量数据的存储量；量化对召回率和检索质量的影响，本站不评估| 精度 | 原始向量占用 | 相对 fp32 | 省下 |
|---|---|---|---|
| fp32（单精度浮点） | 2.861 GiB | 1× | — |
| fp16（半精度浮点） | 1.431 GiB | 0.5× | 50% |
| int8（8 位整数量化） | 732.4 MiB | 0.25× | 75% |
| 二值（每维 1 bit） | 91.55 MiB | 0.0313× | 96.88% |
这三段为什么要分开说
把「精确值」和「推算值」混在一个数字里报出来，是容量估算最常见的坑：看上去精确到了字节，其实里面有一半是拍的。 本站的第一段是纯算术，条数乘维度乘字节数，没有任何模型假设；第二段是按 FAISS、hnswlib 公开的算法结构推的， 公式和出处都写在 公式出处 页上，逐条可查；第三段是各家实现自己的事，本站没有可引用的公开公式， 所以只列项目、一个数字都不给。
结论只有一句：上面那个数是下限，你的真实占用只会比它高。高多少取决于你用的是哪个实现、怎么部署、挂了多少元数据——这些本站不知道，也不替你猜。