向量存储成本在哪里
向量库的支出大头通常不是磁盘而是内存：主流索引为快速做近邻查询，会把向量本身与图结构一起常驻内存，数据量和维度上升时内存需求近乎线性增长。量级上，千万级分块配千级维度就是数十 GB 的裸向量，再叠加索引结构与副本，机器规格很容易被低估一档。因此容量规划应按内存算，而不是按磁盘容量算。
基本信息
| 内存估算 | 向量数乘以维度乘以每维字节数，再乘索引结构开销系数 |
|---|---|
| 浮点占用 | 单精度浮点每维 4 字节，是估算的基准单位 |
| 压缩手段 | 乘积量化或整数化可把内存降到几分之一，召回会略有下降 |
| 副本影响 | 高可用副本按倍数放大内存需求，规划时必须计入 |
| 元数据开销 | 文本、标签、过滤字段同样占内存，规模化后不可忽略 |
| 规划顺序 | 先按规模算内存，再定机器规格与副本数，最后考虑量化压缩 |
典型使用场景
- 千万级知识库上线的容量规划：先估算内存再采购机器，避免上线即扩容
- 自建向量集群的成本优化：内存是主要计费项，量化与副本策略是主要手段
- 多租户共享向量集群：按租户的向量数量与维度分摊资源，配合配额
- 冷热分层：热数据放内存索引，历史数据落盘或用低成本索引
- 定期盘点：清理被下线业务遗留的孤儿集合，它们往往在常年产生固定支出
容量估算示例
容量估算示例
1000 万分块 × 1024 维 × 4 字节 ≈ 40 GB（仅裸向量）
HNSW 图结构再叠加可观开销，常见量级上浮明显 # 具体系数与实现相关
再加 1 个副本近乎翻倍 → 单机放不下，需分片或降副本
改用乘积量化压缩到 1/4 量级 → 内存降下来，召回会掉一些
结论：先按规模算内存，再决定分片数、副本数与量化方案
# 检查点：上线前用真实数据规模压测一次，验证内存占用与查询延迟影响因素与优化方向
| 因素 | 影响 | 优化方向 |
|---|---|---|
| 向量维度 | 维度直接乘进内存公式 | 选满足效果的较小模型版本 |
| 分块数量 | 与内存近似线性 | 优化切分，去除重复与过期内容 |
| 索引类型 | 图索引内存开销高 | 大冷数据改用压缩索引或落盘方案 |
| 副本数量 | 内存按副本倍数放大 | 按可用性要求设定，不盲目多副本 |
| 量化方式 | 压缩率与召回互相制约 | 压缩后必须重跑评测确认损失可接受 |
| 元数据字段 | 随分块数量线性增长 | 只保留检索与展示必需的字段 |
元数据也是成本：分块附带的原文、标签、来源链接在千万级规模下占用可观，只保留过滤与展示必需的字段，能省下的内存往往比调整索引参数更多。
被下线业务遗留的孤儿集合是最容易被忽视的固定支出：没有查询流量，却常年占用内存与备份空间，建议按季度盘点一次。