一句话定义：向量索引的内存估算，就是在建库之前用几次乘法和加法，算清“这批向量要常驻内存、还要能被快速检索，到底需要多少 RAM”。
先算三笔账
向量检索的主流做法是近似最近邻（approximate nearest neighbor, ANN），常用 HNSW（Hierarchical Navigable Small World）这类图索引。内存花在三个地方，可以这样理解：向量本体是书，图索引是书与书之间的“相关推荐”卡片，元数据是借书卡。
| 项目 | 算法 | 一百万条 × 1024 维 |
|---|---|---|
| 向量本体（float32） | N × D × 4 字节 | 约 4.1 GB |
| 图结构（M=16/32） | 每条约 128～256 字节 | 约 0.13～0.26 GB |
| 主键映射、标量字段 | 每条几字节到几十字节 | 几十 MB |
| 标签位图（bitmap） | 一个取值 100 万 bit | 每个取值约 125 KB |
所以纯 ANN 场景下，4.1 GB × 1.1～1.3 是比较稳妥的估算范围。图结构往往只占向量本体的百分之几到十几，很多人会高估它。
加了过滤条件，内存为什么会翻倍
因为过滤会“切断”图。HNSW 靠邻居之间的边一路跳过去，如果某个向量的邻居全被过滤掉，路就断了，召回率（recall）会明显下降。工程上主要有三条应对路线：
1. 分区索引：按租户、类目等字段切成很多张子图，每张子图有独立的入口和连边。图结构和 ID 映射相当于维护了好几份。
2. 先过滤再暴力算：命中集合小的时候直接线性扫描，但前提是原始 float32 向量得留在内存里。
3. 后过滤：先取远大于 topK 的候选再筛，省内存但伤召回。
真正让内存翻倍的，常常是第 2 条和第 1 条叠加起来：平时只放标量量化（scalar quantization, SQ8）或乘积量化（product quantization, PQ）压过的向量做粗筛，1 GB 就够；一旦要求过滤后精确重排，就得再备一份 4 GB 的原始向量。再加每个分区一份图、每个过滤字段一份倒排或位图，实际占用就接近 8 GB，甚至更多。这也是为什么带元数据过滤的向量库，容量规划要按“无过滤场景 × 1.5～2”来留。
和相邻概念的区别：内存估算不等于磁盘估算。索引可以放在 SSD 上，但随机读会拖垮延迟，所以“能不能装进内存”几乎决定了查询体验。它也不等于模型推理的显存估算：后者算的是权重和激活值，前者算的是数据本身。另外，向量压缩（float16、SQ8、PQ）省的是第一笔账，省不了图结构和元数据。
实际意义：给从业者三句话：先用 N × D × 4 估出向量本体的量级，再乘 1.3 得裸索引，带过滤再乘 1.5～2；删除和更新会留下墓碑标记，内存不会立刻回落；具体索引参数与压缩选项以官方文档为准。给普通职场人一句话：向量检索的成本，八成压在“把向量放进内存”这一件事上，维度砍半、精度降一档，账单往往就跟着砍半。