Retrieval-based Voice Conversion WebUI 中 faiss 索引构建与调优完全指南【免费下载链接】Retrieval-based-Voice-Conversion-WebUIEasily train a good VC model with voice data 10 mins!项目地址: https://gitcode.com/GitHub_Trending/re/Retrieval-based-Voice-Conversion-WebUIRVCRetrieval-based-Voice-Conversion-WebUI把「基于检索的音色转换」落到 faiss 的近似最近邻索引上推理时用 HuBERT 提取目标语音的嵌入向量再从训练语音的嵌入库中检索并加权融合最相似的若干特征使转换结果更贴近目标说话人。本文以官方 faiss 调优建议文档为骨架结合仓库内索引训练与推理的源码实现逐项拆解index_factory、IVF、PQ/FastScan、RFlat 等参数的真实含义并给出可直接落地的推荐配置。一、faiss 在 RVC 中的作用faiss 是 Facebook Research 开发的高维稠密向量邻域检索库高效实现了多种近似最近邻检索Approximate Nearest Neighbor Search。所谓近似是指牺牲少量精度来换取大幅度的速度提升这在向量维度高、候选集大的场景下几乎是必经之路。在 RVC 中faiss 承担的是「嵌入特征检索」任务对 HuBERT 从输入语音转换出的特征嵌入在训练数据对应的嵌入中检索与之相似的特征并做融合从而得到更接近原始说话人的转换结果如果朴素地逐一比对检索将非常耗时因此借助近似检索实现高速转换。这一描述与源码逻辑完全吻合。在 infer/modules/vc/pipeline.py 的vc()方法中检索并混合特征的核心调用链为score, ix index.search(npy, k8) # 检索与当前特征最相近的 8 个训练嵌入 weight np.square(1 / score) # 用距离倒数平方构造权重 weight / weight.sum(axis1, keepdimsTrue) npy np.sum(big_npy[ix] * np.expand_dims(weight, axis2), axis1) feats torch.from_numpy(npy).unsqueeze(0).to(self.device) * index_rate \ (1 - index_rate) * feats # 与 HuBERT 原始特征按 index_rate 混合可以看出检索不是「取最近邻 1 个直接替换」而是取k8个近邻、按距离反比加权求和再与原始 HuBERT 特征以index_rate比例插值。而big_npy即全部训练嵌入并不是独立保存的 npy而是运行时通过index.reconstruct_n(0, index.ntotal)从索引中重建出来的见 infer/modules/vc/pipeline.py 与 infer/lib/rtrvc.py后者用于实时转换场景。这意味着索引本身必须保留原始向量这正是IVFx,Flat类索引的特性推理流程才能完成上述加权混合。二、索引构建的整体流程在训练/索引构建阶段工作目录logs/你的实验名下会逐步产生以下中间产物3_feature256v1或3_feature768v2目录存放每个语音文件经 HuBERT 提取后保存的.npy特征文件按文件名排序读取这些 npy纵向拼接成big_npy其形状为[N, 256]v2 为[N, 768]保存为logs/你的实验名/total_fea.npy用 faiss 对拼接后的向量完成训练并构建索引。WebUI 的「训练模型索引」按钮对应的正是 infer-web.py 中的train_index(exp_dir1, version19)函数完整还原了这一流程feature_dir %s/3_feature256 % exp_dir if version19 v1 else %s/3_feature768 % exp_dir npys [] for name in sorted(listdir_res): phone np.load(%s/%s % (feature_dir, name)) npys.append(phone) big_npy np.concatenate(npys, 0) # [N, 256] 或 [N, 768] np.random.shuffle(big_npy_idx) big_npy big_npy[big_npy_idx]这里有一个容易被忽略的关键差异特征维度随模型版本变化。v1 使用 HuBERT 第 9 层输出后接final_proj得到 256 维特征v2 则直接使用第 12 层输出的 768 维特征。这一点在 infer/modules/vc/pipeline.py 中有明确体现output_layer: 9 if version v1 else 12, feats model.final_proj(logits[0]) if version v1 else logits[0]因此在 infer-web.py 中构建索引时维度必须随之切换index faiss.index_factory(256 if version19 v1 else 768, IVF%s,Flat % n_ivf)命令行/脚本用户则可以参考仓库自带的独立实现 tools/infer/train-index-v2.py面向 768 维 v2 特征与 tools/infer/train-index.pyv1 时代脚本它们与 WebUI 逻辑一致先拼接big_npy再index.train()随后index.add()分批量写入向量最后用faiss.write_index()落盘。WebUI 生成的索引文件命名包含了全部关键参数例如added_IVF512_Flat_nprobe_1_实验名_v2.index其中512即 n_ivf 值1是 nprobe 值。推理时 WebUI 会自动按名称挑选不含trained字样的.index文件见 infer/modules/vc/utils.py 中get_index_path_from_model的过滤逻辑这也解释了为什么 train 与 add 两个阶段都要落盘、而推理只用added_*版本。三、index_factory用字符串描述检索流水线faiss.index_factory是 faiss 独有的索引声明式语法把若干近似检索算法用字符串串联成一个 pipeline。好处是只需改一行字符串就能在多种方案间切换实验。RVC 中典型的用法为index faiss.index_factory(256, IVF%s,Flat % n_ivf)三个位置参数的含义分别是参数含义第 1 个向量维度RVC 中 v1 为 256v2 为 768第 2 个index factory 字符串如IVF512,Flat第 3 个使用的距离度量不传时默认METRIC_L2字符串内部用逗号串联算法名从左到右构成「粗量化 → 编码 → 重排」的多级检索结构。RVC 在推理端能直接吃下任意合法字符串生成的索引因此理解这段字符串的语义是调优的前提。四、距离度量L2、内积与余弦相似度作为嵌入相似度使用时faiss 通常有两种度量欧氏距离METRIC_L2对每一维取差值的平方、求和后开根号与我们在二维、三维空间中日常理解的「距离」一致。距离越小越相似。内积METRIC_INNER_PRODUCT一般不直接当作相似度使用因为内积同时受向量方向与长度影响更常见的是先按 L2 范数归一化再做内积即余弦相似度。两者优劣取决于任务word2vec 类嵌入以及 ArcFace 训练的图像检索模型普遍使用余弦相似度。用 numpy 对向量 X 做 L2 归一化可写作eps取足够小的值防止除零X_normed X / np.maximum(eps, np.linalg.norm(X, ord2, axis-1, keepdimsTrue))如果希望切换度量只需把度量常量作为index_factory的第三参传入index faiss.index_factory(dimention, text, faiss.METRIC_INNER_PRODUCT)值得注意RVC 实际走的是 L2 默认路线——由于 HuBERT 特征没有做归一化检索分数是 L2 距离pipeline.py用np.square(1 / score)把「越远权重越小」的语义映射为加权系数随后再对big_npy[ix]做软性加权平均。五、IVF倒排文件索引IVFInverted File倒排文件索引是一种与全文检索中「倒排索引」思想同源的算法训练/学习阶段先用 k-means 对检索目标聚类以簇中心做 Voronoi 划分每个数据点被划分到某个簇于是得到「簇 → 数据点列表」的字典结构查询阶段只在邻近的n_probe个簇内计算与数据点的距离从而把检索范围从全库缩小到少数几个簇。原文档用一个直观的例子说明倒排表结构。假设数据点被分配为index簇1A2B3A4C5B则生成的倒排索引为簇数据点A1, 3B2, 5C4查询时首先在簇中进行检索、确定n_probe个候选簇再只对这些簇内的数据点逐点计算距离。显然nprobe 越大命中的簇越多精度越高但耗时越长。仓库源码在 train 之后会显式设置它index_ivf faiss.extract_index_ivf(index) # 取出 IVF 子索引 index_ivf.nprobe 1 # 只搜索 1 个簇见 infer-web.py独立的 v1/v2 脚本中也有相同的extract_index_ivf用法。IVF 的簇数量n_ivf是索引中最核心的超参下一节给出选值依据。六、参数推荐与选值依据faiss 官方对索引选型与参数给出了指南选择索引的 Guidelines、4bit-PQ 的 FastScan 说明等。核心结论整理如下。6.1 数据量 1M 的推荐组合按官方截至 2023 年 4 月前后的建议对小于 100 万条的数据集4bit-PQ 是最有效率的编码方法。把它与 IVF 组合——先用 IVF 粗筛候选再用 4bit-PQ 进一步压缩逼近最后用精确索引重算距离——可写成如下 factory 字符串index faiss.index_factory(256, IVF1024,PQ128x4fs,RFlat)该字符串对应的就是「IVF1024 倒排 → PQ128x4fs 乘积量化 FastScan → RFlat 精确重排」的三级流水线详见第六、七节。仓库 infer-web.py 中也保留了一行被注释掉的备选方案index_factory(256, IVF%s,PQ128x4fs,RFlat % n_ivf)说明该组合在 RVC 中是经过评估、可在需要时启用的进阶选项。6.2 IVF 数量 n_ivf 的选值公式不要盲目把 IVF 簇数设得过大若粗量化簇数逼近数据条数等于退化回朴素的穷举搜索效率反而最差。对N ≤ 1M的数据集官方建议 n_ivf 落在4*sqrt(N) ~ 16*sqrt(N)WebUI 的实现完全遵循了这一区间并额外加了上界保护见 infer-web.pyn_ivf min(int(16 * np.sqrt(big_npy.shape[0])), big_npy.shape[0] // 39)即在「16√N」与「N/39」两者中取较小者防止小数据集时把簇数设成过大的整百/整千值。对典型的小型数据集N 数千到数万算出的 n_ivf 通常在 1281024 量级与 faiss_tips 文档中IVF512、IVF1024的示例一致。6.3 nprobe 与「数据集过大先聚类降采样」计算耗时与 nprobe 近似成正比因此需在精度与延迟之间权衡。原作者观点是RVC 并不需要很高的检索精度nprobe 1 即可WebUI 默认值也正是 1。另外值得注意当拼接出的big_npy行数超过 20 万条时train_index()会先用MiniBatchKMeans(n_clusters10000)把向量压缩为1 万个簇中心再送入 faiss 训练见 infer-web.py。这个预降采样机制既控制了 k-means 粗量化的训练代价也解释了为什么实际构建出的倒排索引规模始终可控。七、PQ / FastScan乘积量化与快速扫描FastScan 的核心思想是把笛卡尔积量化Product Quantization的距离计算搬到寄存器中高速完成学习阶段把向量按维度切分对每个 d 维子空间通常 d 2独立做聚类预先算好簇间的距离并建成查找表预测阶段每个维度的距离只需查表以 O(1) 代价得到近似距离。因此 factory 字符串中PQ后面紧跟的数字通常取向量维度的一半即切分的子向量个数。以PQ128x4fs为例后缀4表示每个子量化器用 4 bit16 个码字fs表示启用 FastScan 快速累加128为子量化器数量128 × 4bit 512bit 64 字节/向量与 256 维输入的特征规模对应。更多细节可参阅 faiss 官方对 PQ/AQ codes 的 FastScan 文档。八、RFlat用精确距离做最终重排RFlat是一条「重排指令」把 FastScan 等粗编码算出的近似距离换成index_factory第三参指定的精确度量再算一遍。也就是对粗筛出来的候选集做一次“精排”纠正近似量化带来的距离误差。其工作方式是检索 k 个邻居时会对k * k_factor个候选点重算精确距离再从中取距离最小的 k 个。因为精确计算只发生在小规模候选子集上重排开销有限却能显著缓解 PQ 编码造成的精度损失。这正是IVF1024,PQ128x4fs,RFlat能在保持检索速度的同时逼近精确检索质量的原因。九、结合源码的实战建议综合官方调优指南与仓库实际代码可以给出如下可落地的实操结论默认配置不必改动WebUI 默认构建IVF{n_ivf},Flatnprobe1对 RVC 的检索特征规模通常远小于 1M而言是精度与速度的稳妥平衡点追求极致低延迟保持 nprobe1必要时在 infer-web.py 处调低16 * sqrt(N)的系数或减小 n_ivf减少单次检索的簇内计算量数据量接近或超过 1M、且希望压缩索引体积可尝试替换为IVF{n_ivf},PQ128x4fs,RFlatWebUI 源码中已留有对应的被注释示例注意需要重新走完整的 train add 流程并落盘两个.index版本维度别配错v1 模型必须用 256 维、v2 模型必须用 768 维构建索引特征来自不同 HuBERT 层错配会让检索完全失效推理端的自动加载把added_*.index保留在logs/实验名下WebUI 会自动选择reconstruct_n会让索引向量在推理时被还原为big_npy因此不要在推理阶段使用不含原始向量的纯 PQ 索引如未拼接RFlat或Flat的重构型。掌握index_factory字符串中每一段的含义之后你就能像调节音色参数一样按数据规模与硬件条件自由组合 IVF、PQ/FastScan 与 RFlat在「索引体积、检索精度、转换延迟」三者之间找到属于自己数据集的平衡点。【免费下载链接】Retrieval-based-Voice-Conversion-WebUIEasily train a good VC model with voice data 10 mins!项目地址: https://gitcode.com/GitHub_Trending/re/Retrieval-based-Voice-Conversion-WebUI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Retrieval-based Voice Conversion WebUI 中 faiss 索引构建与调优完全指南
Retrieval-based Voice Conversion WebUI 中 faiss 索引构建与调优完全指南【免费下载链接】Retrieval-based-Voice-Conversion-WebUIEasily train a good VC model with voice data 10 mins!项目地址: https://gitcode.com/GitHub_Trending/re/Retrieval-based-Voice-Conversion-WebUIRVCRetrieval-based-Voice-Conversion-WebUI把「基于检索的音色转换」落到 faiss 的近似最近邻索引上推理时用 HuBERT 提取目标语音的嵌入向量再从训练语音的嵌入库中检索并加权融合最相似的若干特征使转换结果更贴近目标说话人。本文以官方 faiss 调优建议文档为骨架结合仓库内索引训练与推理的源码实现逐项拆解index_factory、IVF、PQ/FastScan、RFlat 等参数的真实含义并给出可直接落地的推荐配置。一、faiss 在 RVC 中的作用faiss 是 Facebook Research 开发的高维稠密向量邻域检索库高效实现了多种近似最近邻检索Approximate Nearest Neighbor Search。所谓近似是指牺牲少量精度来换取大幅度的速度提升这在向量维度高、候选集大的场景下几乎是必经之路。在 RVC 中faiss 承担的是「嵌入特征检索」任务对 HuBERT 从输入语音转换出的特征嵌入在训练数据对应的嵌入中检索与之相似的特征并做融合从而得到更接近原始说话人的转换结果如果朴素地逐一比对检索将非常耗时因此借助近似检索实现高速转换。这一描述与源码逻辑完全吻合。在 infer/modules/vc/pipeline.py 的vc()方法中检索并混合特征的核心调用链为score, ix index.search(npy, k8) # 检索与当前特征最相近的 8 个训练嵌入 weight np.square(1 / score) # 用距离倒数平方构造权重 weight / weight.sum(axis1, keepdimsTrue) npy np.sum(big_npy[ix] * np.expand_dims(weight, axis2), axis1) feats torch.from_numpy(npy).unsqueeze(0).to(self.device) * index_rate \ (1 - index_rate) * feats # 与 HuBERT 原始特征按 index_rate 混合可以看出检索不是「取最近邻 1 个直接替换」而是取k8个近邻、按距离反比加权求和再与原始 HuBERT 特征以index_rate比例插值。而big_npy即全部训练嵌入并不是独立保存的 npy而是运行时通过index.reconstruct_n(0, index.ntotal)从索引中重建出来的见 infer/modules/vc/pipeline.py 与 infer/lib/rtrvc.py后者用于实时转换场景。这意味着索引本身必须保留原始向量这正是IVFx,Flat类索引的特性推理流程才能完成上述加权混合。二、索引构建的整体流程在训练/索引构建阶段工作目录logs/你的实验名下会逐步产生以下中间产物3_feature256v1或3_feature768v2目录存放每个语音文件经 HuBERT 提取后保存的.npy特征文件按文件名排序读取这些 npy纵向拼接成big_npy其形状为[N, 256]v2 为[N, 768]保存为logs/你的实验名/total_fea.npy用 faiss 对拼接后的向量完成训练并构建索引。WebUI 的「训练模型索引」按钮对应的正是 infer-web.py 中的train_index(exp_dir1, version19)函数完整还原了这一流程feature_dir %s/3_feature256 % exp_dir if version19 v1 else %s/3_feature768 % exp_dir npys [] for name in sorted(listdir_res): phone np.load(%s/%s % (feature_dir, name)) npys.append(phone) big_npy np.concatenate(npys, 0) # [N, 256] 或 [N, 768] np.random.shuffle(big_npy_idx) big_npy big_npy[big_npy_idx]这里有一个容易被忽略的关键差异特征维度随模型版本变化。v1 使用 HuBERT 第 9 层输出后接final_proj得到 256 维特征v2 则直接使用第 12 层输出的 768 维特征。这一点在 infer/modules/vc/pipeline.py 中有明确体现output_layer: 9 if version v1 else 12, feats model.final_proj(logits[0]) if version v1 else logits[0]因此在 infer-web.py 中构建索引时维度必须随之切换index faiss.index_factory(256 if version19 v1 else 768, IVF%s,Flat % n_ivf)命令行/脚本用户则可以参考仓库自带的独立实现 tools/infer/train-index-v2.py面向 768 维 v2 特征与 tools/infer/train-index.pyv1 时代脚本它们与 WebUI 逻辑一致先拼接big_npy再index.train()随后index.add()分批量写入向量最后用faiss.write_index()落盘。WebUI 生成的索引文件命名包含了全部关键参数例如added_IVF512_Flat_nprobe_1_实验名_v2.index其中512即 n_ivf 值1是 nprobe 值。推理时 WebUI 会自动按名称挑选不含trained字样的.index文件见 infer/modules/vc/utils.py 中get_index_path_from_model的过滤逻辑这也解释了为什么 train 与 add 两个阶段都要落盘、而推理只用added_*版本。三、index_factory用字符串描述检索流水线faiss.index_factory是 faiss 独有的索引声明式语法把若干近似检索算法用字符串串联成一个 pipeline。好处是只需改一行字符串就能在多种方案间切换实验。RVC 中典型的用法为index faiss.index_factory(256, IVF%s,Flat % n_ivf)三个位置参数的含义分别是参数含义第 1 个向量维度RVC 中 v1 为 256v2 为 768第 2 个index factory 字符串如IVF512,Flat第 3 个使用的距离度量不传时默认METRIC_L2字符串内部用逗号串联算法名从左到右构成「粗量化 → 编码 → 重排」的多级检索结构。RVC 在推理端能直接吃下任意合法字符串生成的索引因此理解这段字符串的语义是调优的前提。四、距离度量L2、内积与余弦相似度作为嵌入相似度使用时faiss 通常有两种度量欧氏距离METRIC_L2对每一维取差值的平方、求和后开根号与我们在二维、三维空间中日常理解的「距离」一致。距离越小越相似。内积METRIC_INNER_PRODUCT一般不直接当作相似度使用因为内积同时受向量方向与长度影响更常见的是先按 L2 范数归一化再做内积即余弦相似度。两者优劣取决于任务word2vec 类嵌入以及 ArcFace 训练的图像检索模型普遍使用余弦相似度。用 numpy 对向量 X 做 L2 归一化可写作eps取足够小的值防止除零X_normed X / np.maximum(eps, np.linalg.norm(X, ord2, axis-1, keepdimsTrue))如果希望切换度量只需把度量常量作为index_factory的第三参传入index faiss.index_factory(dimention, text, faiss.METRIC_INNER_PRODUCT)值得注意RVC 实际走的是 L2 默认路线——由于 HuBERT 特征没有做归一化检索分数是 L2 距离pipeline.py用np.square(1 / score)把「越远权重越小」的语义映射为加权系数随后再对big_npy[ix]做软性加权平均。五、IVF倒排文件索引IVFInverted File倒排文件索引是一种与全文检索中「倒排索引」思想同源的算法训练/学习阶段先用 k-means 对检索目标聚类以簇中心做 Voronoi 划分每个数据点被划分到某个簇于是得到「簇 → 数据点列表」的字典结构查询阶段只在邻近的n_probe个簇内计算与数据点的距离从而把检索范围从全库缩小到少数几个簇。原文档用一个直观的例子说明倒排表结构。假设数据点被分配为index簇1A2B3A4C5B则生成的倒排索引为簇数据点A1, 3B2, 5C4查询时首先在簇中进行检索、确定n_probe个候选簇再只对这些簇内的数据点逐点计算距离。显然nprobe 越大命中的簇越多精度越高但耗时越长。仓库源码在 train 之后会显式设置它index_ivf faiss.extract_index_ivf(index) # 取出 IVF 子索引 index_ivf.nprobe 1 # 只搜索 1 个簇见 infer-web.py独立的 v1/v2 脚本中也有相同的extract_index_ivf用法。IVF 的簇数量n_ivf是索引中最核心的超参下一节给出选值依据。六、参数推荐与选值依据faiss 官方对索引选型与参数给出了指南选择索引的 Guidelines、4bit-PQ 的 FastScan 说明等。核心结论整理如下。6.1 数据量 1M 的推荐组合按官方截至 2023 年 4 月前后的建议对小于 100 万条的数据集4bit-PQ 是最有效率的编码方法。把它与 IVF 组合——先用 IVF 粗筛候选再用 4bit-PQ 进一步压缩逼近最后用精确索引重算距离——可写成如下 factory 字符串index faiss.index_factory(256, IVF1024,PQ128x4fs,RFlat)该字符串对应的就是「IVF1024 倒排 → PQ128x4fs 乘积量化 FastScan → RFlat 精确重排」的三级流水线详见第六、七节。仓库 infer-web.py 中也保留了一行被注释掉的备选方案index_factory(256, IVF%s,PQ128x4fs,RFlat % n_ivf)说明该组合在 RVC 中是经过评估、可在需要时启用的进阶选项。6.2 IVF 数量 n_ivf 的选值公式不要盲目把 IVF 簇数设得过大若粗量化簇数逼近数据条数等于退化回朴素的穷举搜索效率反而最差。对N ≤ 1M的数据集官方建议 n_ivf 落在4*sqrt(N) ~ 16*sqrt(N)WebUI 的实现完全遵循了这一区间并额外加了上界保护见 infer-web.pyn_ivf min(int(16 * np.sqrt(big_npy.shape[0])), big_npy.shape[0] // 39)即在「16√N」与「N/39」两者中取较小者防止小数据集时把簇数设成过大的整百/整千值。对典型的小型数据集N 数千到数万算出的 n_ivf 通常在 1281024 量级与 faiss_tips 文档中IVF512、IVF1024的示例一致。6.3 nprobe 与「数据集过大先聚类降采样」计算耗时与 nprobe 近似成正比因此需在精度与延迟之间权衡。原作者观点是RVC 并不需要很高的检索精度nprobe 1 即可WebUI 默认值也正是 1。另外值得注意当拼接出的big_npy行数超过 20 万条时train_index()会先用MiniBatchKMeans(n_clusters10000)把向量压缩为1 万个簇中心再送入 faiss 训练见 infer-web.py。这个预降采样机制既控制了 k-means 粗量化的训练代价也解释了为什么实际构建出的倒排索引规模始终可控。七、PQ / FastScan乘积量化与快速扫描FastScan 的核心思想是把笛卡尔积量化Product Quantization的距离计算搬到寄存器中高速完成学习阶段把向量按维度切分对每个 d 维子空间通常 d 2独立做聚类预先算好簇间的距离并建成查找表预测阶段每个维度的距离只需查表以 O(1) 代价得到近似距离。因此 factory 字符串中PQ后面紧跟的数字通常取向量维度的一半即切分的子向量个数。以PQ128x4fs为例后缀4表示每个子量化器用 4 bit16 个码字fs表示启用 FastScan 快速累加128为子量化器数量128 × 4bit 512bit 64 字节/向量与 256 维输入的特征规模对应。更多细节可参阅 faiss 官方对 PQ/AQ codes 的 FastScan 文档。八、RFlat用精确距离做最终重排RFlat是一条「重排指令」把 FastScan 等粗编码算出的近似距离换成index_factory第三参指定的精确度量再算一遍。也就是对粗筛出来的候选集做一次“精排”纠正近似量化带来的距离误差。其工作方式是检索 k 个邻居时会对k * k_factor个候选点重算精确距离再从中取距离最小的 k 个。因为精确计算只发生在小规模候选子集上重排开销有限却能显著缓解 PQ 编码造成的精度损失。这正是IVF1024,PQ128x4fs,RFlat能在保持检索速度的同时逼近精确检索质量的原因。九、结合源码的实战建议综合官方调优指南与仓库实际代码可以给出如下可落地的实操结论默认配置不必改动WebUI 默认构建IVF{n_ivf},Flatnprobe1对 RVC 的检索特征规模通常远小于 1M而言是精度与速度的稳妥平衡点追求极致低延迟保持 nprobe1必要时在 infer-web.py 处调低16 * sqrt(N)的系数或减小 n_ivf减少单次检索的簇内计算量数据量接近或超过 1M、且希望压缩索引体积可尝试替换为IVF{n_ivf},PQ128x4fs,RFlatWebUI 源码中已留有对应的被注释示例注意需要重新走完整的 train add 流程并落盘两个.index版本维度别配错v1 模型必须用 256 维、v2 模型必须用 768 维构建索引特征来自不同 HuBERT 层错配会让检索完全失效推理端的自动加载把added_*.index保留在logs/实验名下WebUI 会自动选择reconstruct_n会让索引向量在推理时被还原为big_npy因此不要在推理阶段使用不含原始向量的纯 PQ 索引如未拼接RFlat或Flat的重构型。掌握index_factory字符串中每一段的含义之后你就能像调节音色参数一样按数据规模与硬件条件自由组合 IVF、PQ/FastScan 与 RFlat在「索引体积、检索精度、转换延迟」三者之间找到属于自己数据集的平衡点。【免费下载链接】Retrieval-based-Voice-Conversion-WebUIEasily train a good VC model with voice data 10 mins!项目地址: https://gitcode.com/GitHub_Trending/re/Retrieval-based-Voice-Conversion-WebUI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考