4.1 为什么需要量化：内存是向量搜索的最大瓶颈

1000 万条 768 维向量需要 30 GB 内存——量化让它降到 0.5 GB

---

这一节在讲什么？

前面三章我们用的都是全精度索引（Flat/IVFFlat/HNSWFlat），它们存储原始的 float32 向量。但在大规模场景下，float32 的内存开销是巨大的——1000 万条 768 维向量就需要约 29 GB 内存，HNSW 索引更是需要 60 GB 以上。量化（Quantization）是解决内存瓶颈的核心技术——它把 float32 压缩成更小的表示，内存减少 4~64 倍。这一节我们要建立对量化必要性的直觉，然后后续三节分别深入 PQ、OPQ 和 SQ。

---

内存瓶颈的量化分析

不同数据量下的内存需求（768 维 float32）：

  100 万条：
  原始数据：2.9 GB
  HNSW 索引（M=32）：约 3.4 GB
  总计：约 6.3 GB → 一台普通服务器能装下

  1000 万条：
  原始数据：29 GB
  HNSW 索引（M=32）：约 34 GB
  总计：约 63 GB → 需要高端服务器

  1 亿条：
  原始数据：290 GB
  HNSW 索引（M=32）：约 340 GB
  总计：约 630 GB → 需要集群

  用 PQ 量化后（m=48）：
  1 亿条：约 4.8 GB → 一台普通服务器就能装下！

量化的核心思想是用精度换内存——把每个 float32（4 字节）压缩成更小的表示，代价是距离计算的精度略有下降，但召回率通常还能保持在 85%~95%。

---

FAISS 的量化方案

FAISS 提供了三种量化方案，覆盖不同的压缩比和精度需求：

量化方法	压缩比	精度损失	适用场景
PQ（乘积量化）	8~64 倍	中	内存有限、大数据量
OPQ（优化乘积量化）	8~64 倍	小（比 PQ 更精确）	对召回率要求高
SQ（标量量化）	4 倍	小	精度优先、压缩比要求不高

---

小结

这一节我们建立了对量化必要性的直觉：float32 的内存开销在大规模场景下是巨大的，量化通过压缩向量表示来减少内存，代价是精度略有下降。下一节我们深入最常用的量化方法——PQ（乘积量化）。