过去一段时间，我们一直在为 Timeline Studio 寻找更适合浏览器运行的中文配音模型。

目标其实很直接：用户输入中文，或者中英混合的文本，浏览器就能当场生成自然语音；原始素材不必上传，也不需要依赖云端推理服务。

但真正开始做之后会发现，这件事并不轻松。模型体积怎么控制、浏览器兼容性怎么兜住、语音自然度够不够、长文本生成稳不稳定、模型分发如何落地，这些问题一个都绕不开。

而且，每一项都得单独啃下来。

经过多轮模型测试，我们最终将中文配音切换到了 Hojo TTS Light 80M，并完成了 WebGPU、WASM、模型切片、长文本分句和双镜像下载等工程适配。

线上版本已经发布，可以直接在浏览器中体验：

https://video-editor.ai-creator.top/

项目代码与 Timeline Studio Skill：

https://github.com/MartinDelophy/ai-video-editor

为什么更换原来的中文配音模型

早期版本采用了适合 ONNX Runtime Web 的多语言 TTS 模型。它的优势是部署简单、运行稳定，但在实际配音中仍存在一些明显问题：

• 中文语气相对平直；
• 中英文切换时容易出现突兀的停顿；
• 长句的节奏和气息不够自然；
• 笑声、语气词和句尾释放感偏机械；
• 为了支持多个角色，需要携带较多声线资源。

对于普通的文字朗读，这些问题不一定明显。

但在短视频旁白、产品介绍、剧情解说等场景中，用户对语音节奏和真人感非常敏感。

对多种开源方案做完一轮测试后可以看到，Hojo TTS Light 80M 在中文自然度、语气衔接，以及中英混合表达这几个关键维度上，整体表现更胜一筹。

更重要的是，它的模型规模依然有望被控制在浏览器可接受的范围内，这一点相当关键。

为什么选择 Hojo TTS Light 80M

这次选择主要基于以下几个方面。

• 第一，中文自然度较好。它在句尾语气、停顿和音节衔接方面，比我们之前使用的浏览器模型更加自然。
• 第二，它支持中英双语。对于技术产品介绍、品牌名称和英文缩写较多的脚本，中英文可以在同一段语音中完成，不需要为不同语言分别调用两套模型。
• 第三，它采用参考音频驱动的声音生成方式。这意味着我们可以为产品准备经过授权的固定参考声线，也能为未来的合规声音定制预留扩展空间。
• 第四，80M 级别的模型虽然不算特别小，但仍然有可能通过 ONNX、FP16、文件切片和浏览器缓存实现本地部署。

目前 Timeline Studio 内置了两位中文女声：

• 晴岚：声音相对温暖、自然，适合产品介绍和叙事旁白；
• 若溪：声音更清晰、轻快，适合教程、资讯和短视频解说。

浏览器中的推理架构

Hojo TTS 并不是一个单独的 ONNX 文件。

完整生成过程涉及多个阶段，包括文本编码、自回归语音编码生成和波形解码。

我们的浏览器推理路径可以简化为：

中文或中英混合文本

↓

文本与参考声音编码

↓

WebGPU 自回归生成语音编码

↓

WASM 解码语音波形

↓

响度控制与 WAV 编码

↓

加入视频时间线

其中，计算量较大的自回归部分使用 WebGPU，尽可能发挥独立显卡或高性能 GPU 的能力；波形解码则使用 WASM，以保证不同浏览器和设备上的声音稳定性。

全部推理都在用户浏览器内完成，项目素材和输入脚本不需要发送到我们的服务器。

为什么没有让所有阶段都使用 WebGPU

理论上，把全部模型都交给 WebGPU 运行可能更快。

但实际产品不能只看速度。

我们在测试中发现，部分解码图使用 WebGPU FP16 推理时，可能出现：

• 低频噪声；
• 波形失真；
• 局部爆音；
• 静音或近似静音结果；
• 不同设备上的输出差异。

因此，我们最终采用了混合方案：自回归生成使用 WebGPU，声音波形解码使用更加稳定的 WASM。

这种设计牺牲了一部分理论性能，但换来了更稳定的声音质量。

对于配音产品来说，生成慢几秒通常可以接受；但生成一段带噪声或无法使用的音频，则不可接受。

大模型文件如何在浏览器中下载

浏览器部署模型时，模型大小只是问题的一部分。

更常见的问题是单个文件过大，导致下载失败、缓存失败，或者网络中断后必须重新开始。

我们将原始 FP16 ONNX 模型拆分成多个约 16 MiB 的文件，并为每个文件记录：

• 文件大小；
• SHA-256 校验值；
• 所属模型图；
• 文件排列顺序；
• 上游模型版本；
• 缓存版本标识。

浏览器并行下载这些切片，下载完成后先逐片验证，再重新组合为完整模型。

model.onnx

├── model.onnx.part-000.bin

├── model.onnx.part-001.bin

├── model.onnx.part-002.bin

└── ...

与单个大文件相比，这种方式有几个好处：

• 可以并行下载；
• 单个请求失败时更容易重试；
• 更适合浏览器缓存；
• 可以验证每个分片是否完整；
• 更适合不同模型托管平台的文件限制。

ModelScope 优先，Hugging Face 回退

为了兼顾国内和海外网络环境，我们将同一份模型资源同步到了 ModelScope 和 Hugging Face。

中文界面和国内网络环境默认优先尝试 ModelScope，其他情况下可以优先尝试 Hugging Face。

如果首选平台不可用，浏览器会自动切换到另一个镜像。

两个平台共享同一个逻辑缓存身份，因此即使下载源发生切换，浏览器也不会把相同模型重复缓存两次。

模型地址：

• Hugging Face：haixin/timeline-studio-voice-models
• ModelScope：martindelophy/timeline-studio-voice-models

实际运行时使用固定版本号，而不是直接依赖随时可能变化的 main 分支。

这样可以避免上游文件变化后导致线上推理结果不可复现。

500 字长文本应该怎样生成

虽然模型可以接收比较长的文本，但这不意味着应该把几百字直接作为一次推理任务。

长文本一次性生成容易出现：

• 后半段声音质量下降；
• 停顿越来越不自然；
• 句尾被截断；
• 语速发生漂移；
• 浏览器显存和内存压力升高；
• 某一句失败后整段需要重新生成。

因此，我们没有把长文本直接交给模型，而是采用了“先分句，再逐句生成”的方法。

例如：

今天我们发布了新的浏览器配音能力。

它不需要上传素材，也不依赖远程推理。

中文和英文可以在同一个工作流中完成。

系统会将它拆成三个独立任务，每一句都生成一个真实的音频文件，而不是先生成一段长音频再进行裁切。

这样做带来了几个重要变化：

• 单句失败可以单独重试；
• 每个句子的语气更加稳定；
• 音频可以在时间线上独立移动；
• 字幕能够与对应语音精确关联；
• 长文生成时内存占用更加可控。

目前，相邻语音片段默认保留 0.4 秒间隔，桌面端和移动端采用相同规则。

这个间隔既能避免句子粘连，也不会让旁白显得过于松散。

分句不能只识别句号

简单按照句号拆分并不够。

中文文本中还可能出现：

• 逗号和分号；
• 问号与感叹号；
• 英文标点；
• 数字和小数；
• URL；
• 中英文固定短语；
• 产品名称和人名。

如果拆分规则过于激进，可能把一个有完整含义的短语拆成几个无法正常朗读的碎片。

因此，我们的原则是：

• 句号、问号和感叹号必须作为生成边界；
• 逗号默认可以作为呼吸组边界；
• 过短或失去语义的片段需要重新合并；
• 不拆分专有名词、数字、URL和固定表达；
• 中英混合短语尽量保持在同一个语音片段中。

这本质上不是简单的字符串切割，而是为语音生成准备一条更接近真人呼吸节奏的文本序列。

字幕与配音如何配合

我们采用“音频优先”的时间线策略。

系统首先完成所有语音片段的生成，测量每段语音的真实时长，并按照 0.4 秒间隔排列。

随后，再根据最终音频的位置创建或调整字幕。

这样做可以避免一个常见问题：先把字幕或画面固定到某个时长，然后强行拉伸或压缩语音去适配。

在 Timeline Studio 中，接受后的配音会成为时间线的音频骨架。

画面、转场、字幕和动画都围绕最终语音节奏进行调整，而不是让语音去服从预先设定的模板时长。

对于视频旁白来说，这种流程通常更自然。

声音克隆与基础配音的边界

Timeline Studio 已经提供 OpenVoice V2，用于获得授权后的声音转换。

因此，我们没有让 Hojo TTS 同时承担完整的用户声音管理逻辑。

当前设计是两个阶段：

Hojo TTS 生成自然的基础语音

↓

OpenVoice 转换到已授权的目标音色

用户选择保存过的克隆声线后，产品表面上仍然只需要一次操作，但内部会显示两个阶段的进度和错误状态。

这样既能保留 Hojo 在中文表达上的自然度，也可以复用现有的授权、试听确认、参考音频保存和声音删除机制。

声音克隆涉及身份和授权问题，因此我们要求用户在录制或上传参考音频时明确确认拥有使用权限。

生成结果也不应被冒充为真实人物录音。

浏览器本地语音生成的意义

把 TTS 放进浏览器，不只是少部署一台推理服务器。

它会改变整个产品的使用方式：

• 用户的脚本和参考声音可以留在本地；
• 开发者不需要按生成次数承担推理费用；
• 模型下载完成后可以重复使用；
• 音频能够直接进入本地视频时间线；
• 项目在网络不稳定时仍能继续编辑；
• 模型和运行时版本可以被固定并复现。

当然，本地运行也有代价。

首次模型下载需要时间，设备性能差异会影响生成速度，移动端内存也更加有限。

因此，浏览器 AI 的关键并不是简单地把服务器代码搬到前端，而是重新设计模型格式、推理后端、缓存、分片、错误恢复和时间线工作流。

当前成果

完成这次升级后，Timeline Studio 的中文配音流程已经具备：

• Hojo TTS Light 80M FP16 浏览器推理；
• 两位经过授权的中文参考声线；
• 中文和中英混合语音生成；
• WebGPU 与 WASM 混合执行；
• ModelScope 与 Hugging Face 双镜像；
• 16 MiB 模型切片与 SHA-256 校验；
• 长文本自动分句；
• 每句话生成独立音频资产；
• 桌面端与移动端统一 0.4 秒句间隔；
• 与字幕、时间线和 OpenVoice 声音转换衔接。

写在最后

浏览器端中文 TTS 的难点，从来不只是“模型能不能运行”。

真正影响用户体验的是：声音是否自然、长文本是否稳定、首次下载是否可靠、失败后能否局部重试，以及生成结果能不能自然地进入字幕和视频时间线。

Hojo TTS Light 80M 并不是最大的语音模型，但在模型规模、中文效果、双语能力和浏览器可部署性之间，提供了一个很有价值的平衡点。

对于本地优先的视频编辑工具来说，这种平衡往往比单纯追求参数规模更重要。