一个索引文件占121GB内存，召回率93.72%，每秒查询302.5次。这是Pinterest搜索平台Manas在优化前的基线数据。当底层语料库从百万级膨胀到数十亿级，这种内存密集型的向量检索方式开始撞上成本墙。

Pinterest工程团队最近公开了他们的应对路径：用标量量化（SQ）和乘积量化（PQ）压缩向量表示，用SPANN把索引搬到SSD上，最终在生产环境实现20%到30%的serving成本节省。Manas目前部署在80个集群，支撑着首页信息流、搜索、相关推荐、广告和通知这些核心发现场景。

打开网易新闻 查看精彩图片

两种量化路线，两种取舍

团队在一个1亿向量的GraphSage数据集上测试了两种压缩方案。PQ把原始浮点向量压成紧凑的字节码，HNSW索引体积减少74%，IVF索引减少93%，但召回率落在70%到80%区间。SQ则把向量分量压成低位整数，HNSW索引减少59%，IVF减少75%，召回率能稳定保持在90%以上。

离线基准测试给出了更具体的数字对比：

  • 基线HNSW：索引121GB，Recall@100为93.72%，QPS 302.5
  • HNSW+PQ：索引降至32GB，Recall@100为77.25%，QPS 276.4
  • HNSW+SQ：索引50GB，Recall@100为92.92%，QPS 305.2
  • 基线IVF：索引97GB，Recall@100为91.69%，QPS 1659.8
  • IVF+PQ：索引压缩到6.8GB，Recall@100为76.00%，QPS 1747.9
  • IVF+SQ：索引25GB，Recall@100达到95.71%，QPS 1588.8

值得注意的是IVF+SQ这组数据：索引体积只有基线的四分之一左右，召回率反而比基线更高。这说明压缩不一定意味着精度损失，选对量化方式反而可能带来意外收益。

用SIMD解决解码瓶颈

低位表示通常需要在距离计算前先做一步解码，这一步会吃掉CPU资源。Pinterest团队用SIMD指令实现了线性缩放SQ，把查询计算资源降低了10%到15%。这个优化不算大，但它是让量化方案能在生产环境跑通的关键一环。

线上实验的结果是SQ和PQ都成功上线，在生产负载中实现了20%到30%的成本节省。

把索引从内存搬到SSD

要进一步削减RAM成本，就得把索引存储转移到高吞吐SSD上。团队评估了DiskANN和SPANN两条路线，结论是SPANN配合PQ能达到DiskANN3倍的QPS，延迟只有其三分之一，召回率仅下降5%。

SPANN的架构思路是：内存里保留一个小而快的质心索引用来定位相关分区，大的倒排列表存在SSD上，以此优化IOPS并保证搜索效率。在一个索引超过50亿向量的Pin推荐评估中，SPANN相比全内存HNSW方案为生产查询节省了超过40%的CPU时间。

从121GB到6.8GB，从全内存到SSD serving，Pinterest这套组合拳的核心逻辑很清晰：不是追求单一指标的极致，而是在召回率、延迟、成本之间找到可上线的平衡点。对于同样面临向量规模膨胀的团队来说，SQ和PQ的取舍数据、SPANN与DiskANN的对比结果，都是可以直接参考的决策依据。