在向量检索场景中，embeddings的规模直接决定显存与内存的配比方案，核心原则是：显存优先容纳全量索引的热数据，内存负责冷数据和索引构建的缓冲，配比通常以索引总量为基准，显存占比建议控制在30%到50%之间，具体取决于查询并发和延迟要求。
为什么embeddings规模是配比的第一变量
向量检索的本质是把文本、图片或音频变成高维浮点数组，然后通过近似最近邻算法找相似项，这里有一个容易被忽略的事实：embeddings的维度（常见为384、768、1024或1536）和总条数相乘，才是决定硬件资源的根本数字，很多人纠结该买多大显存的GPU，或者该配多少内存，其实只要算出索引文件的体积，配比逻辑就清晰了。
以1亿条768维float32向量为例,仅仅原始向量数据就需要约286GB（1亿×768×4字节），加上倒排索引、量化码本和元数据，实际占用会超过300GB，这种情况下，如果你只有一张24GB显存的消费级显卡，显然不可能全量加载，行业共识认为，当索引大小超过显存容量三倍以上时，必须采用内存+显存的分层存储方案。
配比失衡的典型症状有两种：显存不足时检索请求频繁触发swap到内存，延迟从几毫秒飙升到几百毫秒；内存不足时操作系统开始使用磁盘交换，直接导致服务不可用，所以embeddings规模不是简单的“够用就行”，它决定了你是该走纯GPU方案、CPU+内存方案还是混合方案。
显存与内存的核心职责划分
显存负责“热路径”上的高频索引分区
在向量检索的实时服务链路中,显存承担的是最高频的暴力计算和粗排阶段，比如使用HNSW（分层可导航小世界图）算法时，图的入口点和上层节点需要极低延迟访问，这些结构放入显存能显著减少P99延迟，业内专家指出，对于毫秒级响应的在线检索，显存中至少需要驻留索引总量的30%作为“热数据”，否则查询会频繁穿透到内存层。
实操中,很多团队会把向量索引按业务热度拆分成多个分片，把最近一周的活跃向量放进显存，历史冷数据留在内存，比如电商场景中，热门商品向量只占总量的20%，但承接了80%的查询流量，这时显存只需覆盖这20%的热向量，加上HNSW图结构，通常能控制在总索引体积的35%左右。
内存负责全量索引的“冷备”和构建期缓冲
内存的角色更像是“第二存储层”和“临时工作区”。全量索引必须完整加载进内存，因为显存只能放子集，查询时如果显存未命中，要从内存中的全量索引里检索并返回候选集，索引构建和增量更新时，新向量需要先在内存中攒批、建图，然后定期刷入显存，所以内存容量至少要能装下整个索引文件，并保留20%到30%的余量应对构建期的峰值。
这里有个常见误区：有人以为内存只要和索引大小相同就够了，向量检索服务在运行时会维护查询上下文、缓存结果集、以及索引合并的临时副本，据行业测试数据，
内存建议按照索引体积的1.3倍到1.5倍配置，才能避免频繁GC和内存抖动。
配比公式：先从embeddings总体积倒推
要算配比,先得算出总向量数据量，公式很简单：向量条数 × 向量维度 × 每个分量字节数，float32是4字节，float16是2字节，int8量化后只要1字节，如果使用乘积量化（PQ），每个向量可能压缩到几十字节，但压缩会带来召回率损失，所以配比时要给“量化后索引”留出额外内存存放码本和残差。
举例说明：采用HNSW库（如faiss）构建索引，原始向量为768维float32，共5000万条，原始体积约143GB，HNSW图结构通常额外占用接近原始向量大小的内存，总内存需求约280GB，如果显存打算覆盖热数据，需要至少80GB显存，此时合理配比是80GB显存 + 320GB内存，显存占比约20%，但热数据命中率能达90%以上，若是全量暴力检索，显存则需要单独存放完整向量，配比自然变成全显存方案。
不同embedding模型和量化策略下的配比调整
模型维度差异带来的直接变化
现在开源的embedding模型,比如BGE-large（1024维）、M3E-base（768维）、text-embedding-ada-002（1536维），维度直接决定了单个向量的存储开销。同样1000万条数据，1536维float32需要约61GB，而384维只需要15GB，很多团队在选型时只关注模型效果，忽略了维度对硬件成本的影响，如果业务对召回率要求不是极端高，用768维模型搭配int8量化，能省下约75%的显存需求。
量化策略是调节配比的杠杆
- int8量化：每个分量从4字节降到1字节，但需要额外存储缩放因子，整体压缩到原始大小的25%到30%，显存需求大幅下降，适合GPU显存紧张的场景。
- 乘积量化（PQ）：将向量拆成子段分别聚类，每个子段用码本ID表示，存储开销可压缩到每向量16到64字节，但检索时需计算查表距离，CPU开销增加。
- 混合方案：显存中存放原始float32向量做精排，内存中存放PQ粗排索引，候选集先在内存粗筛，再到显存精排，这种方式能把显存需求压到总量的20%以内。
选择量化策略前,建议先用小规模数据实测召回率损失，行业测试表明，int8量化在768维向量上的召回率下降通常小于1%，而PQ在子段数设为32时，召回率下降可能达到3%到5%。高召回要求场景优先int8，低成本场景考虑PQ。
实操案例：百度向量检索场景下的配置思路
在百度云的向量检索服务中,常见的问题是“向量数据库显存不够怎么办”，这里给出一个标准处理流程：
- 先用
faiss或Milvus的get_index_size
接口获取当前索引文件的实际大小。
- 查看业务查询QPS和P99延迟目标,若QPS低于500且允许10ms以上延迟，可以全内存方案，无需GPU。
- 若QPS高于2000或延迟要求低于5ms,则必须引入显存加速，用
nvidia-smi监控当前显存利用率，确定热数据占比。 - 根据热数据比例,将索引按分区或集合拆分，显存只加载高频分区，如果业务没有明显冷热区分，则按时间窗口或用户活跃度划分。
- 配置内存时,预留至少30%余量给增量索引合并，例如索引总大小200GB，内存建议256GB以上。
一个真实场景：某内容社区使用768维向量，数据量8000万，原始索引约230GB，HNSW图额外占用约180GB，总内存需求410GB，他们采用40GB显存的A100，显存中加载了最近7天的热点向量约50GB（含图结构），内存配置512GB，实际运行中，显存命中率达到95%，P99延迟从纯内存方案的12ms降到4ms，这个配比中，显存约占总索引体积的12%，但已经足够满足业务需求。
| 数据规模（条数） | 向量维度 | 存储精度 | 原始索引大小 | 推荐显存 | 推荐内存 | 适用场景 |
|---|---|---|---|---|---|---|
| 1000万 | 768 | float32 | 约29GB | 24GB | 64GB | 中小规模、低并发 |
| 5000万 | 1024 | int8 | 约48GB | 32GB | 128GB | 中等规模、中并发 |
| 1亿 | 768 | PQ（32子段） | 约40GB | 24GB | 96GB | 大规模、容忍召回损失 |
| 1亿 | 1536 | float32 | 约573GB | 80GB | 768GB | 高精度、高并发 |
如何根据embeddings规模估算显存内存配比
第一步：算原始向量体积
用脚本统计向量总条数和维度,乘以精度字节数，如果你用的是Milvus，可以直接查show collection的统计信息，如果是自建faiss，用index.ntotal和index.d计算，这一步不需要精确到字节，大致数量级即可。
第二步：加上索引结构开销
HNSW的图结构一般需要额外占用原始向量大小的0.8到1.2倍，IVF索引的倒排列表开销较小，约占原始大小的10%到20%，PQ量化索引很小，但需要加上码本和残差存储，把这些加总得到“索引总需求”。
第三步：确定显存热数据比例
看线上查询日志,统计不同向量被检索的次数，通常是典型的二八分布：20%的向量承担80%的查询，把这些高频向量对应的索引分片大小计算出来，就是显存的最低需求，建议在此基础上加10%的裕量给运行时缓冲区。
第四步：内存按全量索引的1.3倍配置
内存必须完整容纳索引总需求,并预留构建和合并空间，如果内存不足，可考虑将原始向量放在SSD上，但这样延迟会大幅增加，只适合离线批处理场景。
常见问题与调优建议
显存占用率过高怎么办
先检查是否加载了全量索引,很多默认配置会一次性把整个索引载入显存，改成“按需加载”或“显存缓存淘汰策略”能立刻缓解，检查是否开启了Mmap模式，该模式利用CPU内存映射而非显存，适合大索引但会增加延迟。
内存和显存数据不一致如何处理
采用“显存优先，内存兜底”的策略，写入时先写内存中的全量索引，同时异步更新显存中的热分区，查询时如果显存命中则直接返回，未命中时从内存检索后回填显存缓存，这样做能兼顾一致性和性能。
百度云上的向量数据库默认配比合理吗
百度云的向量检索服务默认提供内存型或GPU型套餐,但业务差异很大，默认配比通常偏向保守，如果你明确知道自己的embeddings规模，建议自定义配置，查看控制台中的“索引大小”指标，如果超过已配置内存的80%，就应该扩容了。
向量检索显存内存配比的核心结论
无论选择哪种算法或云服务,embeddings的规模是硬件规划的唯一硬约束，先用原始数据量加上索引结构系数估算总需求，再按查询热度和并发目标拆分显存与内存的比例，显存不是越大越好，内存也不是越多越好，关键是让热数据命中率和延迟指标匹配业务预期，记住一个简单规律：索引总量小于显存容量时，直接全显存；索引总量是显存的2到3倍时，用热数据切分；超过3倍时，必须用量化或混合存储方案，配比没有绝对最优解，但按这个思路计算，至少不会出现服务启动就OOM的尴尬。
关于显存内存配比的常见问题解答
问：embeddings规模不大，比如只有几百万条，还有必要区分显存和内存吗？
答：如果索引总量小于16GB，单台高性能CPU服务器的内存就能搞定，P99延迟在10ms以内完全没问题，没必要增加GPU成本，只有当查询QPS超过5000或延迟要求低于3ms时，才考虑用显存加速。
问：使用GPU加速时，显存大小和向量维度有什么关系？
答：直接相关，显存能容纳的最大向量条数等于显存容量除以单向量字节数，例如24GB显存，对768维float32向量，最多容纳约800万条；如果改成int8量化，能容纳约3300万条，维度越高，单条向量占用的字节数越大，能加载条数越少。
问：有没有办法在显存不足的情况下先用较低配比跑起来？
答：有，将faiss的GpuIndexIVFFlat换成GpuIndexIVFPQ，并把nprobe调大，显存占用可以降到原来的十分之一，同时把索引分片数调大，让GPU只处理部分分片，其余走CPU内存，实测在召回率损失3%以内，服务能够正常运行。