几天前，我和一位前同事聊天，他们团队负责管理包含十亿条向量数据的向量数据库。为了不至于将磁盘撑爆，他们使用了 HNSW 索引、748 维的嵌入模型。但是老板已经快干不下去了，因为每年的云服务器费用还是高达几万美金！
问题并不在于他们选错了嵌入模型，甚至也不是选错了向量数据库。原因很简单：他们的向量太大了。
为什么十亿个嵌入向量会花这么多钱
以 768 维为例，每个 float32 向量是 768×4 字节 = 3072 字节，所以十亿个就是 3.07 TB 的原始数据。如果再加上大约 15% 的 HNSW 索引开销、元数据等，总共约为 3.5 TB。
在 AWS 上使用 gp3 磁盘，基本费率为 $0.08/GB·月，约等于 $80/TB·月，那么每个节点每月的存储成本约为 $280。但为了实现亚 10 毫秒的向量搜索延迟，通常还需要额外配置 IOPS 和吞吐量 —— 所以实际成本更接近 $400–450/TB·月。以 $450/TB·月计算，3.5 TB 的存储成本约为每月 $1575 每个节点。再加上副本、开发/测试集群、数据摄取管道和计算节点，每个月为搜索所付出的成本轻松就能上五位数。
维度灾难让情况更糟。维度越高，数据越稀疏。为了保持高召回率，索引需要检索更多候选向量，导致 CPU 和 I/O 成本上升。简而言之，每增加一个维度，都是在成本墙上再砌一块砖。
但大型索引真正的成本甚至不是基础设施费用，而是维护成本 —— 你需要一个庞大的搜索团队来构建和维护它。如果你能将索引大小减少 10 倍，你可能可以节省 2–6 名专职的搜索工程师！
向量“欠量化”的成本
“欠量化”就是你保留了比实际需要更多的嵌入维度。2024 年，很多人直接使用模型默认输出 —— 比如 768 或 1536 维 —— 因为大家都认为“越多越好”。更重要的是，当这些搜索流程被搭建时，量化技术还不够成熟，所以最终系统都比当时的最先进技术（SOTA）更臃肿。而向量数据库并没有激励去教育开发者正确使用量化 —— 因为不量化可以让他们赚得更多！
现代基准测试显示，在使用合适的嵌入模型的前提下，64 维的二进制向量在许多搜索任务中能维持与 1024 维向量相近的性能。虽然每维 1 位的二进制量化已经有很大帮助，但它无法拯救一个本身维度就太高的向量。
为了理解量化在互联网规模下所带来的巨大节省，我们来算一算如果你有 20 亿个向量：
748 维，float32：
-
原始数据：2e9 × 748 × 4 字节 ≈ 5.98 TB
-
索引后（约 25% 开销）：≈ 7.48 TB
128 维，float32：
-
原始数据：2e9 × 128 × 4 字节 = 1.024 TB
-
索引后：≈ 1.28 TB
64 维，float32：
-
原始数据：2e9 × 64 × 4 字节 = 0.512 TB
-
索引后：≈ 0.64 TB
64 维，二进制（1 bit/维）：
-
原始数据：2e9 × 64 bits ÷ 8 = 16 GB (0.016 TB)
-
HNSW 指针开销：2e9 × 256 B ≈ 0.512 TB
-
总索引大小：≈ 0.016 + 0.512 = 0.528 TB
这已经是数据量上的数量级压缩，并能显著降低成本、加快搜索速度。更重要的是，这对于一个小型搜索团队来说也更容易管理。
2025 年的量化与磁盘索引新进展
在 2025 年，我们拥有了新的工具，能更安全地实现这些压缩。采用嵌套嵌入（Matryoshka 表示学习）训练的模型，能让前 64 或 128 维承载几乎所有语义信息。你可以直接截断剩余部分，而不需要重新训练一个低维模型。这类模型通常也会被训练得适应二进制或标量量化。
在索引方面，KX （https://kx.com/）的 qHNSW 磁盘引擎将大部分向量数据保存在 SSD 上，只在内存中存放最小化的元数据。数百万个 64 维向量仅占几个 GB，查询时间保持在 200 毫秒以内，CPU 占用也大幅下降。
关键是采用两阶段检索：
1. 先用紧凑、便宜的索引选出前 K 个候选项；
2. 再用交叉编码器（cross-encoder）或 BM25 进行重排序。
这样即使在量化时略微损失了一些精度，也可以通过 rerank 拿回来。真实基准中，召回率下降通常在 5% 以内。更有意义的做法是：先快速构建一个激进量化的索引，再专注于精细调整 reranker —— 毕竟，修改 rerank 服务比重新嵌入 10 亿个数据点容易多了！
降低成本的简单步骤
-
从小维度开始。尝试使用 64 或 128 维，而不是默认的 768 或 1536 维。
-
积极进行量化。从 float32 转为 int8 或二进制是基本操作；但真正节省成本的，是直接减少维度。
-
使用两阶段检索。先在紧凑的索引上粗略筛选，再对少量候选进行重排序。
-
如果可能，请严格进行基准测试。在每次更改前后测量准确率、延迟和成本。但如果你不打算测试，那就千万别用大维度嵌入——你根本没有证据证明它们在你的数据上表现更好。
-
不要盲信默认设置。很多向量数据库默认使用高维模型和全内存索引。改用磁盘上的 qHNSW，并显式设置维度。
向量搜索不是“维度越多越好”或者“占满内存越快”这种游戏——它是一个工程优化问题。在 2025 年，随着成熟的量化技术和磁盘索引方案，你完全可以用一两台机器跑大规模搜索。裁剪你的向量，优化你的流程，基础设施的费用将大幅下降。
https://medium.com/kx-systems/the-most-common-vector-search-mistake-is-costing-enterprises-hundreds-of-thousands-dd1ffd0b976d（文：PyTorch研习社）