一、项目背景

我们 RAG 知识库越堆越大，向量全用 float32 存内存，机器加到了顶还是放不下，检索一多内存就吃紧，老板嫌向量库太烧钱，差点要把知识库砍一半。我们算过，float32 存几千万条向量，内存账单比语料本身还贵，这账没法交，只能要么降本要么砍内容。更尴尬的是，热数据其实只占一小部分，大部分冷向量占着最贵的内存却很少被查，等于用金子养着不用的人。

二、落地场景

现在向量做标量量化压缩，float32 转 int8，内存直接砍掉大半。热数据留内存索引，冷数据推到磁盘索引，查询时热的高频命中内存，冷的偶尔落盘。IVF 聚类分桶让检索先定位桶再比，不用全量扫。量化精度掉一点，但配合重排补回来，召回没塌。运营同学往库里灌新语料不再被内存卡脖子，知识库反而比之前更全了，这和我们最初想砍库的方向正好相反。

三、关键技术挑战与解决思路

量化精度损失是第一道关，int8 压下来有些近邻顺序变了，我们在关键场景做量化前后对比，掉得多的桶回退到 float32。磁盘索引延迟比内存高，冷数据落盘后查询慢一截，我们用缓存把近期查过的桶留内存，热冷分界按访问频率动态调，不是写死的比例。聚类分桶质量决定检索上限，桶太多碎、太少粗，我们按数据量选桶数并做残差校准，桶内再排近邻。召回与成本权衡是永恒的题，我们没追求零损失，而是定了一条召回红线，低于就回退精度，保证答案质量不崩。还有增量更新，新向量进来要进对的热冷分层，我们按写入频率决定落内存还是磁盘。

案例片段（已脱敏）： 标量量化与磁盘索引配置片段（字段示意）：vector_store:  metric: cosine  quant:    type: scalar    from: float32    to: int8  index:    hot: memory    cold: disk    ivf_nlist: 4096  recall_floor: 0.95一次收益：原 float32 全内存约需 192G，标量量化加热冷分层后内存降到约 64G，月机器成本降约四成，召回率保持在约 0.96，业务方无感。

冷数据落盘的查询抖动我们用缓存盖了一层，最近查过的桶留在内存，热冷分界按访问频率每十分钟调一次，不是写死的比例，这样大促时热点自然上浮。增量写入的分层我们栽过，新向量一股脑塞进内存，热冷比例被冲乱，命中率悄悄掉了好几天才发现，后来改成按写入频率决定落内存还是磁盘。IVF 分桶的残差校准上线前被我们省略过一次，召回掉了一截，业务方问出来的问题变多，才老老实实把校准加回来。量化前后的召回对比现在是我们发版的必经关，磁盘索引的 IO 我们做了批处理，冷查询攒一批再落盘，单条延迟从毛刺变平稳。

四、效果数据

存储成本因为我们换了量化加热冷分层，内存账单砍掉一大截，月机器成本降了约四成。内存占用从濒临爆仓降到平稳，检索不再因为内存吃紧变慢。检索延迟热数据几乎无感，冷数据偶发落盘慢一点但能接受。召回率我们守着红线，量化后还在九成五以上，业务方没察觉答案变差。知识库容量反而比砍库前更大，因为同样内存能装更多量化后的向量。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

向量不是越大越准，float32 是懒人选择也是烧钱选择。我们被内存账单逼出来做量化，早做的话知识库能多养一倍语料。热冷分层比全内存省钱、比全磁盘快，分界按访问频率调比拍固定值聪明。召回红线必须画，别为了降本把答案质量带崩，我们设了 0.95 的 floor，低于就回退精度。量化前后对比这步省不得，有些桶掉得狠，回退 float32 是兜底。增量更新别忘，新向量分层错了热冷就乱，命中率悄悄掉。

量化这招，越大的库越划算，小库量化省的内存还不如折腾成本高，我们定了体量阈值才上。成本账要算总账，机器降了，但质量和运维的精力上来了，这平衡得老板一起拍。

磁盘索引的维护我们做了自动重建，桶膨胀了后台慢慢整理，不影响前台查询，这点是大库长跑必须的。

结语

向量库的成本账，多数人算反了，盯着召回率忘了内存账单。我们 float32 全内存撑到 192G，老板差点砍语料，才被迫做量化。int8 一压，内存直接砍到 64G，月成本降四成，知识库不但没砍还扩了，因为同样内存能装下更多量化后的向量。热冷分层是随后加的，全内存还是贵，冷数据推磁盘，近期查过的桶留内存，访问频率动态调分界，比固定切聪明。IVF 分桶数我们按数据量选了 4096 并做残差校准，桶太碎太粗都伤召回。召回红线 0.95 是底线，有桶量化掉得狠，我们回退 float32 兜底，这步当初想省，结果一个桶答案带偏被业务方抓包。量化前后对比现在是我们上线的必过项，不做就别上线。增量更新那块我们栽过，新向量一股脑塞内存，热冷分层被冲乱，命中率悄悄掉了一阵才发现。成本降下来后，我们反而敢往库里灌更多语料，正循环转起来了。