在 RAG 应用部署阶段，向量数据库的索引配置往往决定了检索延迟、写入吞吐和硬件成本的上限。内存索引与磁盘索引并非简单的“快与慢”之分，而是涉及数据规模、查询模式、持久化要求和成本约束的系统性权衡。
两类索引的工程差异
内存索引（如 HNSW、IVF_FLAT 常驻内存）将向量和索引结构全部放在 RAM 中。查询时无需磁盘 I/O，延迟通常在毫秒级，适合对 P99 延迟敏感的场景。代价是内存占用与向量数量、维度、索引参数成正比。以 768 维 float32 向量为例，单条向量原始数据约 3KB，加上 HNSW 的图结构开销，百万级数据往往需要数 GB 到数十 GB 内存。写入时索引需要同步更新，高并发写入可能引发内存抖动。
磁盘索引（如 DiskANN、IVF 配合磁盘存储）将向量或索引结构持久化到 SSD，查询时按需加载。内存占用显著降低，单机可支撑更大数据规模，成本更可控。但查询延迟受磁盘随机读影响，通常高于纯内存方案。写入吞吐受限于磁盘 I/O 和索引合并策略，批量导入时更友好，实时写入则需关注 LSM 类结构的写放大。
持久化方面，内存索引通常依赖快照或 WAL 保证重启后恢复，恢复时间与数据量相关；磁盘索引天然持久化，重启后可直接加载，但首次查询可能触发缓存预热。
配置决策框架
选择索引类型时，建议按以下顺序判断：
- 数据规模与增长预期：当前向量条数和未来 6～12 个月的增长曲线。若单机内存无法覆盖全量索引，优先考虑磁盘索引或分片方案。
- 延迟目标：明确 P50 和 P99 延迟要求。若 P99 需稳定在 10ms 以内，内存索引更稳妥；若可接受 50～100ms，磁盘索引配合 SSD 通常足够。
- 写入模式：实时写入为主且 QPS 较高时，内存索引的同步更新可能成为瓶颈；批量导入为主时，磁盘索引的合并写入更高效。
- 成本约束：对比内存型实例与 SSD 型实例的单位成本。内存索引需要更高配机器，磁盘索引可用更低成本存储换取延迟。
- 持久化与恢复：评估 RTO/RPO 要求。磁盘索引恢复更快，内存索引需考虑快照频率和恢复耗时。
配置检查清单
- 向量维度、数据类型（float32/float16/int8）是否明确，是否启用量化压缩。
- 索引参数（如 HNSW 的 M、efConstruction、efSearch）是否与召回率和延迟目标匹配。
- 内存索引是否配置了足够的堆外内存或 mmap 空间，避免 GC 或 swap。
- 磁盘索引是否使用 NVMe SSD，是否评估了 IOPS 和吞吐上限。
- 是否配置了副本和分片，分片键是否导致热点。
- 持久化策略：快照间隔、WAL 大小、恢复演练是否完成。
- 监控指标：查询延迟分位、缓存命中率、磁盘 I/O 等待、内存使用率。
压测方法
压测应覆盖真实负载特征，而非单一指标：
- 数据集构造：使用与生产同维度、同分布的向量，规模至少为生产数据的 10%～20%，并包含冷启动和缓存预热阶段。
- 查询压测：混合不同 topK（如 10、50、100）和过滤条件，记录 P50/P95/P99 延迟及召回率。对比内存与磁盘索引在相同召回率下的延迟差异。
- 写入压测：模拟实时写入和批量导入两种模式，观察写入吞吐、索引合并延迟和查询延迟的相互影响。
- 资源监控：同步采集 CPU、内存、磁盘 IOPS、网络带宽，定位瓶颈。
- 故障恢复：模拟进程重启或节点故障，测量恢复时间和数据一致性。
压测结果应形成“数据规模—延迟—成本”三维曲线，而非单一结论。例如，在 500 万条 768 维向量、P99 要求 20ms 的场景下，内存索引可能需要 64GB 以上内存，而磁盘索引配合 NVMe 可能以更低成本达标，但需验证缓存命中率。
工程取舍建议
对于中小规模 RAG 应用（百万级向量以内），内存索引通常能提供更简单的运维和更稳定的低延迟，优先考虑。当数据量增长到单机内存难以承载，或成本压力显著时，可迁移到磁盘索引，并通过增加副本、优化缓存策略来弥补延迟。混合方案也值得考虑：热数据放内存索引，冷数据放磁盘索引，按访问频率分层。
最终决策应基于压测数据，而非产品参数表。不同向量数据库对同一索引类型的实现差异较大，务必在目标硬件和真实数据上验证。