前段时间，分享了低延迟小智AI服务端搭建系列：

• 低延迟小智AI服务端搭建-ASR篇
• 低延迟小智AI服务端搭建-ASR篇（续）
• 低延迟小智AI服务端搭建-LLM篇
• 低延迟小智AI服务端搭建-TTS篇
• 低延迟小智AI服务端搭建-本地TTS篇
  这三个环节中，成本最高的当属 TTS。

本地TTS，因为需要音色克隆，免不了要对参考音频进行特征提取。

而几乎所有音色克隆模型特征提取的耗时都不低，这对低延迟对话应用来说，是个硬伤。

怎么解决？

音色缓存：把参考音频的音色特征提前算好，推理时直接加载即可！

本篇，分享音色缓存的两种思路，欢迎评论区大佬指教。

注：本篇只聊思路，适用于所有音色克隆模型。

1. 显存直存方案

这种方案，直接在GPU显存中维护一个字典。

以 IndexTTS 为例，speaker_dict[speaker] 中只需存储两个变量：

• speech_conditioning_latent ：通过 GPT 模型提取的音频编码
• speaker_embedding ：通过 BigVGAN 提取的声纹特征

因为是 GPU 推理，这些张量在后续的推理过程中不需要从内存中加载，所以响应速度最快。

通常，音色特征的尺寸不会很大，占用显存不多。因此，该方案适用于克隆音色不太多的个人玩家。

那么，如果音色注册量上来了呢？

而且，推理服务的实例，是分布式动态扩缩容的，在每个实例中，都进行音色注册，显然就不够经济高效。

为此，可以考虑引入 Redis。

2. Resis 混合存储方案

speaker_dict设计成一个先进先出的队列，只保存最近在用的音色。音色注册时，放到 Redis 缓存中，推理时，如果speaker_dict队列中找不到，就从 Redis 中取出入队。

具体实现上：

1. 显存直存：

• 使用 OrderedDict 实现 speaker_dict 的LRU队列；
• 设定最大容量（如20）来控制显存使用

2. Redis 缓存：

• 支持持久化存储，支持异步操作
• 音色注册时，根据 speaker，把特征存入 Redis;
• 模型推理时，如果 speaker_dict 不存在当前音色特征，从 Redis 中获取

此外，还可以：

• 添加预热机制，在启动时预加载常用音色
• 添加音色使用频率统计，优先缓存高频音色

这个方案的优点是：

1. 有效控制显存使用
2. 保证最常用的音色快速访问
3. Redis持久化保证了数据安全性
4. 支持分布式部署和扩展

写在最后

本文分享了小智AI服务端 本地TTS音色克隆，针对音色缓存的两种实现方案。

如果对你有帮助，欢迎点赞收藏备用。