Unity本地TTS实战：基于Sentis与VITS构建免费离线语音合成方案

1. 项目概述：UnityTTS到底是什么？

最近在Unity社区里，关于本地化、免费的文本转语音（TTS）方案的讨论又热了起来。很多独立开发者和中小团队，在做叙事游戏、虚拟助手或者需要大量动态语音反馈的项目时，都会卡在语音这一环。云端TTS服务要么贵，要么有延迟和网络依赖；而传统的离线TTS，声音又往往像机器人，缺乏情感，直接用在游戏里很容易出戏。

我最近花了不少时间深入测试和整合了几种方案，核心目标就一个：在Unity里实现免费、高质量、可离线运行、且带一定情感表现力的TTS。网上常说的“UnityTTS”并不是某一个特定的官方插件，而更像是一个需求场景的统称。它指的是在Unity引擎内，不依赖外部API或云服务，直接将文本转换为语音音频流的技术方案。这个需求背后，是大家对内容可控、成本可控、用户体验流畅的迫切追求。

经过一番折腾，我发现目前市面上能真正满足“亲测免费”且效果尚可的方案，主要集中在两个方向：一是利用一些新兴的、基于深度学习的本地推理引擎（如Unity Sentis）来运行轻量级TTS模型；二是挖掘那些被忽略的、但足够稳定可靠的老牌开源库。这篇文章，我就把自己趟过的路、踩过的坑，以及最终验证可行的核心方案梳理出来，重点会放在功能实现、场景适配和实操细节上，希望能帮你快速绕过我走过的弯路。

2. 核心需求与方案选型背后的逻辑

为什么我们非要折腾本地TTS？直接调用在线的微软、谷歌或者 ElevenLabs 的API不行吗？这里面的考量，远不止“免费”两个字那么简单。

2.1 为什么本地TTS是很多项目的刚需？

首先，成本控制对于独立开发者和初创项目是生死线。像 ElevenLabs 这样的服务，虽然音质顶尖，但免费额度每月只有很少的生成时间，一旦项目进入测试或需要大量生成语音内容，费用瞬间就上去了。而本地方案，一次部署，无限次使用，边际成本几乎为零。

其次，隐私与数据安全。如果你的游戏或应用需要处理用户输入的文本（比如自定义角色台词、用户生成的剧情），将这些文本发送到第三方云端存在隐私泄露风险。本地处理能彻底杜绝这个问题。

第三，稳定性和实时性。网络连接不稳定会直接导致语音播放中断或延迟，这在需要沉浸感的游戏里是致命的。本地TTS的延迟是确定且极低的，通常在几十到几百毫秒内就能完成推理并播放，体验流畅。

第四，可定制性与集成度。本地方案允许你深度定制语音生成的各个环节，比如调整语速、音调，甚至结合游戏内的上下文（角色情绪、环境紧张度）来动态影响语音输出。这是云端黑盒API很难做到的。

2.2 主流免费方案横向对比与选型

基于社区讨论和我自己的测试，目前有以下几个值得关注的路径：

1. 基于 Unity Sentis 的本地AI推理方案这是目前最有潜力的方向。Sentis 是Unity官方推出的神经网络推理引擎，允许你在Unity运行时直接加载和运行 ONNX 格式的模型。这意味着你可以寻找开源的、轻量级的TTS模型（如 VITS, FastSpeech2），将其转换为ONNX，再用Sentis集成。

• 优势：完全离线，集成在Unity进程内，性能可控，理论上可以结合其他AI模型（如情绪识别）做端到端的情绪化语音生成。
• 挑战：模型转换、优化和集成有一定技术门槛。社区中提到的 Piper 模型与旧版 Sentis 兼容性问题就是典型例子。模型质量、速度和资源消耗（尤其是移动端）需要仔细权衡。

2. 利用成熟的开源TTS引擎封装例如espeak-ng，这是一个老牌的开源语音合成系统。有开发者已经为其制作了Unity插件（如unitycoder/UnityRuntimeTextToSpeech）。

• 优势：极度稳定，资源占用极小，跨平台支持相对容易（虽然原项目提到Windows only，但espeak-ng本身是多平台的）。
• 劣势：语音质量是典型的“机器人声音”，比较生硬，缺乏自然语流和情感。适合对音质要求不高，但需要极高可靠性和即时反馈的场景，比如辅助功能、系统提示音。

3. 新兴的专用Unity TTS资产就像网络内容中提到的Lingotion Thespeon，它标榜自己是“带情感的AI语音表演，而不仅仅是TTS”。这类资产通常封装好了模型和运行时，提供更友好的Unity API和编辑器集成。

• 优势：开箱即用，节省大量集成和调试时间，通常针对Unity环境做了优化，并且主打“情感”卖点。
• 需要注意：需要仔细评估其“免费”条款（通常是非商业免费），以及模型的真实效果、资源消耗和对目标平台（尤其是移动端）的支持情况。从讨论看，用户在资产导入和模型包下载上遇到了问题，说明其成熟度和文档可能还在早期阶段。

我的选型思路： 对于追求自然度和未来扩展性（如情感合成）的项目，我会优先尝试Sentis + 轻量VITS模型的路径。虽然起步麻烦，但自主可控，上限高。 对于需要极度稳定、即时反馈、且对音质容忍度高的功能性场景（如游戏内的任务日志朗读），espeak-ng插件是可靠的选择。 对于希望快速原型验证，且项目是非商业性质的开发者，可以尝试像Lingotion Thespeon这类新兴资产，但要做好踩坑和应对可能的不稳定的准备。

3. 实战：基于Sentis与VITS构建本地TTS系统

这里我详细拆解第一种方案，也是我认为最具价值的路径。我们目标是实现一个在Unity Editor和独立运行时都能工作的基础TTS模块。

3.1 环境准备与核心工具链

首先，确保你的Unity版本支持 Sentis。Sentis 目前是预览包，你需要通过 Unity Package Manager 的 “Add package by name” 来安装com.unity.sentis。建议使用较新的Unity LTS版本（如2022.3或2023 LTS）。

模型选择：我们选用一个相对轻量且开源的TTS模型——VITS。VITS 是一种端到端的语音合成模型，音质不错，而且有不少预训练的单说话人模型。我们可以在 Hugging Face 或 GitHub 上找到一些开源的、训练好的 VITS 模型（例如用 LJSpeech 数据集训练的英文模型）。关键是找到ONNX 格式的导出模型。有些仓库会提供，如果没有，你可能需要使用torch.onnx.export自己从PyTorch模型转换，这需要一些Python和深度学习框架的知识。

辅助工具：

• ONNX Runtime：虽然 Sentis 是运行时，但在准备阶段，用 ONNX Runtime (Python) 测试一下模型是否能正确推理，可以提前排除很多问题。
• 文本前端处理器：TTS模型通常不接受原始文本。你需要一个文本转音素（phoneme）的模块。对于英文，可以使用phonemizer库（后端如 espeak）将文本转为音素序列。这个处理逻辑你需要用C#在Unity中复现，或者预先处理好。

注意：模型转换和文本前端处理是两大难点。建议先从社区寻找已经转换好的 ONNX VITS 模型和对应的音素词典/C#处理脚本，这会让你事半功倍。不要一开始就试图自己训练和转换模型。

3.2 Unity项目中的集成步骤

假设我们已经有了一个名为vits_single_speaker.onnx的模型文件和一个能正确将英文句子转为音素ID序列的C#脚本Phonemizer.cs。

步骤一：导入模型并创建推理管道

1. 将.onnx模型文件放入项目的Resources文件夹或任何StreamingAssets文件夹，以便运行时加载。
2. 创建一个VITSTTSService的单例管理器类。
3. 在Awake或Start中，使用ModelLoader.Load加载 ONNX 模型，创建一个Unity.Sentis.Model对象。
4. 根据模型输入输出定义，创建输入张量（OrtTensor）。对于VITS，输入通常是音素ID序列和长度，可能还有控制音速、音高的参数。

using Unity.Sentis; using UnityEngine; public class VITSTTSService : MonoBehaviour { private Model _runtimeModel; private IWorker _worker; private Phonemizer _phonemizer; // 自定义的音素转换器 void Start() { // 1. 加载模型 ModelAsset modelAsset = Resources.Load<ModelAsset>("vits_single_speaker"); _runtimeModel = ModelLoader.Load(modelAsset); // 2. 选择后端。移动端用 GPU 需谨慎测试性能，CPU 最稳妥。 BackendType backend = BackendType.GPUCompute; // 或 BackendType.CPU _worker = WorkerFactory.CreateWorker(backend, _runtimeModel); // 3. 初始化文本处理器 _phonemizer = new Phonemizer(); } }

步骤二：执行推理与音频处理

1. 在SynthesizeSpeech方法中，接收字符串文本。
2. 使用_phonemizer.TextToPhonemeIds(text)将文本转换为音素ID序列（int[]）。
3. 将音素ID序列转换为Sentis能接受的输入张量TensorInt。
4. 准备其他输入（如序列长度标量）。
5. 调用_worker.Execute进行推理。
6. 从输出张量中获取生成的音频数据（通常是单声道、16kHz或22.05kHz采样率的PCM浮点数组）。
7. 将PCM数据转换为Unity的AudioClip。

public AudioClip SynthesizeSpeech(string text) { // 1. 文本转音素ID int[] phonemeIds = _phonemizer.TextToPhonemeIds(text); using TensorInt inputTensor = new TensorInt(new TensorShape(1, phonemeIds.Length), phonemeIds); // 2. 准备输入字典 (根据你的模型输入节点名调整) Dictionary<string, Tensor> inputs = new Dictionary<string, Tensor> { { "input_ids", inputTensor }, { "input_lengths", new TensorInt(new TensorShape(1), new int[]{phonemeIds.Length}) } }; // 3. 执行推理 _worker.Execute(inputs); // 4. 获取输出音频数据 TensorFloat audioTensor = _worker.PeekOutput("output") as TensorFloat; float[] audioData = audioTensor.ToReadOnlyArray(); // 5. 创建AudioClip AudioClip clip = AudioClip.Create("TTS", audioData.Length, 1, 16000, false); clip.SetData(audioData, 0); return clip; }

步骤三：播放与资源管理创建AudioSource组件来播放返回的AudioClip。非常重要的一点是，注意张量Tensor是IDisposable的，使用using语句或在推理后及时调用.Dispose()来释放内存，避免内存泄漏，这在移动端至关重要。

3.3 性能优化与移动端适配心得

在真机上（特别是安卓和iOS），直接运行神经网络模型挑战很大。

1. 模型量化：如果模型是FP32（单精度浮点），尝试将其转换为INT8量化模型。量化能显著减少模型体积和内存占用，并提升推理速度，但可能会轻微损失音质。可以使用 ONNX Runtime 的量化工具在导入前完成这一步。

2. 后端选择：BackendType.GPUCompute在支持良好的设备上更快，但兼容性不如CPU。务必在目标设备上进行充分测试。如果GPU推理不稳定，回退到CPU是更安全的选择。

3. 预热与缓存：第一次推理通常很慢（模型加载、层初始化）。可以在场景加载时，用一句很短的文本（如“a”）进行一次“预热”推理。对于游戏中重复使用的固定语句（如“欢迎回来”），可以预合成并缓存AudioClip，避免运行时重复推理。

4. 音频流处理：对于长文本，一次性合成可能导致延迟过长和内存压力。更高级的实现是流式合成：将长文本分句，合成一句播放一句，同时预合成下一句。这需要模型支持或对推理过程有更精细的控制，实现复杂度较高。

5. 线程管理：Sentis的worker.Execute是同步的，在主线程执行长文本推理会导致游戏卡顿。强烈建议将推理任务放到后台线程（如使用System.Threading.Tasks.Task），合成完成后再回到主线程创建和播放AudioClip。注意Unity API（如AudioClip.Create）必须在主线程调用。

4. 常见问题排查与调试技巧实录

在实际集成过程中，你几乎一定会遇到下面这些问题。这里是我的排查记录。

4.1 模型推理输出无声或全是噪音

这是最常见的问题，根本原因通常是输入数据格式不匹配。

• 检查音素化：首先确保你的文本转音素逻辑与模型训练时使用的完全一致。不同的前端处理器（如espeak vs. festival）产生的音素符号可能不同。最好的方法是找到模型原作者使用的处理脚本，并尽量在C#中复现其逻辑。可以先用Python脚本处理同一句话，对比输出的音素ID序列是否与你在Unity中生成的一致。
• 检查输入张量形状和类型：用Netron工具打开你的.onnx模型，仔细查看输入节点的名称、期望的数据类型（int64, int32, float32）和形状（例如[1, -1]表示批大小为1，变长序列）。确保你在C#中创建的Tensor与之完全匹配。
• 检查输出后处理：模型输出的可能是梅尔频谱图（mel-spectrogram），而不是直接的PCM音频。你需要一个声码器（Vocoder）（如HiFi-GAN）将其转换为波形。确认你的模型是端到端的VITS（直接出波形），还是只出梅尔谱的FastSpeech2。如果是后者，你需要额外集成一个ONNX格式的声码器模型。

4.2 在移动端（Android/iOS）上崩溃或性能极差

• 内存溢出：移动设备内存有限。使用System.GC.Collect()进行强制垃圾回收可能适得其反。最关键的是确保所有Tensor和IWorker在使用后正确释放。将推理代码包裹在try...finally块中，在finally里确保张量被Dispose。
• 线程冲突：确保所有Unity对象（GameObject, AudioClip等）的创建和操作都在主线程。后台线程只做纯数据推理（Tensor运算）。
• 模型太大：如果模型文件超过50MB，考虑是否可以进行剪枝或选择更小的模型。也可以将模型文件放在StreamingAssets中，首次运行时再解压到Application.persistentDataPath，避免APK过大。
• 后端不支持：某些旧的或低端设备的GPU可能不支持Sentis的GPU后端。务必在代码中添加回退逻辑：先尝试创建GPU worker，如果失败则捕获异常并创建CPU worker。

try { _worker = WorkerFactory.CreateWorker(BackendType.GPUCompute, _runtimeModel); } catch (Exception e) { Debug.LogWarning($"GPU backend failed: {e.Message}. Falling back to CPU."); _worker = WorkerFactory.CreateWorker(BackendType.CPU, _runtimeModel); }

4.3 语音不自然、语调平淡

这是本地TTS，尤其是小模型的通病。

• 数据质量：模型训练数据的质量和多样性决定了上限。LJSpeech数据集是单说话人、比较清晰的朗读语音，缺乏丰富的情绪变化。
• 缺乏韵律控制：基础的VITS模型没有显式的控制接口。你可以尝试寻找支持音素级别时长控制或音高控制的变体模型。在输入中提供这些控制信息，可以让合成的语音更有节奏感。
• 后处理：在音频层面，可以尝试轻微的调整。例如，对生成的PCM数据应用一个非常轻微的、随机的音高偏移（在合理范围内），或者在不同句子间插入符合语境的短暂静音，可以稍微打破机械感。但这只是“化妆”，治标不治本。

4.4 关于“情感语音”的迷思

网络内容中提到的“带情感的AI语音表演”是一个很好的愿景，但实现起来非常复杂。目前可行的本地化方案主要有两种：

1. 多模型切换：训练多个不同情感（高兴、悲伤、愤怒）的单一说话人模型，根据游戏上下文切换模型。缺点是需要加载多个模型，占用内存大。
2. 情感嵌入控制：使用一个支持情感标签（emotion embedding）作为条件输入的模型。在推理时，除了文本音素，还输入一个代表情感类别的向量。这需要模型在训练时就用多情感数据训练过。 目前，成熟的、开源的、适合移动端的“情感TTS”模型非常稀少。大多数宣称有此功能的商业资产或研究项目，其效果和性能在本地部署时都需要打一个问号。对于大多数项目，现阶段更务实的目标是追求“自然流畅”的语音，情感表达可以通过游戏内的音效、音乐和画面来协同实现，而不是完全依赖TTS。

5. 备选方案与快速验证路径

如果你觉得Sentis方案过于复杂，或者项目周期非常紧张，可以考虑以下“曲线救国”的路径：

方案A：混合模式 - 本地缓存 + 云端降级

1. 对于游戏内固定的、核心的语音内容（如主线剧情），在打包时预合成（可以使用高质量的云端TTS服务，如Azure Neural Voices，按量付费合成一次），作为音频资源打包。
2. 对于完全动态生成的文本（如玩家自定义角色名、随机事件），使用本地TTS（如espeak-ng）作为降级方案。
3. 这样既保证了关键内容的品质，又为动态内容提供了免费、离线的兜底方案。

方案B：外部进程调用在PC平台，可以编写一个简单的Python脚本，利用功能强大的离线TTS库（如coqui-tts），在Unity中通过System.Diagnostics.Process启动这个脚本进程，传递文本并接收生成的音频文件。Unity再加载这个音频文件播放。

• 优点：可以利用Python生态下更成熟的TTS工具链，绕过Unity和Sentis的集成难题。
• 缺点：不是真正的“进程内”集成，启动进程有开销，不适合移动端，进程间通信和同步更复杂。

折腾Unity本地TTS的过程，更像是一场在效果、性能、成本和技术复杂度之间的平衡艺术。没有完美的银弹，最好的方案永远是最适合你当前项目阶段和资源约束的那一个。从稳定的espeak-ng入手快速验证需求，再逐步向Sentis + VITS的方案演进，是一个比较稳妥的策略。最重要的是，先让功能跑起来，再慢慢优化体验。在这个过程中积累的模型处理、本地推理和性能优化经验，其价值远超过实现TTS功能本身。