目标其实很明确：用户输入中文文本，或中英混合脚本后，浏览器即可即时生成自然流畅的语音；原始素材无需上传，也不必依赖云端推理服务。可真正开始落地时就会发现，这件事远比想象中复杂。模型体积如何压缩、浏览器兼容性如何保障、语音自然度是否足够、长文本生成是否稳定、模型分发怎么实现，这些问题都无法回避，而且每一项都需要单独解决。
[https://video-editor.ai-creator.top](https://video-editor.ai-creator.top/)
项目代码与 Timeline Studio Skill：https://github.com/MartinDelophy/ai-video-editor
为什么更换原来的中文配音模型
早期版本使用的是适配 ONNX Runtime Web 的多语言 TTS 模型。它的优点是部署方便、运行稳定，但在真实配音场景中依然存在一些比较明显的问题：
- 中文语气整体偏平；- 中英文切换时容易出现突兀停顿；
- 长句的节奏与气息不够自然；- 笑声、语气词和句尾释放感略显机械；
- 为了支持多个角色，需要额外携带较多声线资源。如果只是普通文本朗读，这些问题未必十分突出。但在短视频配音、产品介绍、剧情解说、视频旁白等场景里，用户对语音节奏、情绪表达和真人感往往非常敏感。在对多种开源 TTS 方案完成一轮系统测试后可以看到，Hojo TTS Light 80M 在中文语音自然度、语气衔接，以及中英混合表达等关键维度上，整体表现更有优势。更重要的是，它的模型规模仍有机会被控制在浏览器可接受的范围内，这一点非常关键。
## 为什么选择 Hojo TTS Light 80M这次选择主要基于以下几个方面。第一，中文配音自然度更好。它在句尾语气、停顿节奏和音节衔接方面，相比我们此前使用的浏览器语音模型更加自然流畅。
第二，它支持中英双语生成。对于技术产品介绍、品牌名称、英文缩写较多的文案，中英文内容可以在同一段语音中直接完成，不需要为不同语言分别调用两套 TTS 模型。第三，它采用参考音频驱动的声音生成方式。这意味着我们既可以为产品准备经过授权的固定参考声线，也能为未来合规的声音定制能力预留扩展空间。
第四，80M 级别的模型虽然算不上特别轻量，但仍有机会通过 ONNX、FP16、文件切片和浏览器缓存等方式实现本地部署。目前 Timeline Studio 内置了两位中文女声：
- 晴岚：声音偏温暖、自然，适合产品介绍、叙事旁白和内容讲述；- 若溪：声音更清晰、轻快，适合教程讲解、资讯播报和短视频解说。
浏览器中的推理架构
Hojo TTS 并不是单一的 ONNX 文件。完整的语音生成过程涉及多个阶段，包括文本编码、自回归语音编码生成以及波形解码。
我们的浏览器端推理路径可以简化为：```
中文或中英混合文本↓
文本与参考声音编码↓
WebGPU 自回归生成语音编码↓
WASM 解码语音波形↓
响度控制与 WA V 编码↓
加入视频时间线```
其中，计算量更大的自回归阶段使用 WebGPU，以尽可能发挥独立显卡或高性能 GPU 的能力；波形解码则使用 WASM，以确保不同浏览器和设备上的声音输出稳定性。全部推理均在用户浏览器本地完成，项目素材和输入脚本无需发送到服务器，这也更符合本地优先和隐私保护的使用需求。
## 为什么没有让所有阶段都使用 WebGPU从理论上说，把全部模型都交给 WebGPU 执行可能会更快，但真实产品不能只看速度。我们在测试中发现，部分解码图在使用 WebGPU FP16 推理时，可能出现以下问题：
- 低频噪声；- 波形失真；
- 局部爆音；- 静音或近似静音结果；
- 不同设备之间输出差异明显。因此，我们最终采用了混合推理方案：自回归生成阶段使用 WebGPU，声音波形解码阶段使用更稳定的 WASM。这种设计虽然牺牲了一部分理论性能，但换来了更可靠的音质表现。对于 AI 配音产品来说，生成速度慢几秒通常可以接受，而生成出带噪声、失真或无法使用的音频则不可接受。
## 大模型文件如何在浏览器中下载在浏览器部署 AI 模型时，模型大小只是问题的一部分。更常见的挑战是单个文件过大，导致下载失败、缓存失败，或者网络中断后必须从头重新下载。我们将原始 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 并不是参数规模最大的语音模型，但它在模型体积、中文语音效果、中英双语能力和浏览器可部署性之间，提供了一个非常有价值的平衡点。 对于本地优先的视频编辑工具而言，这种平衡往往比单纯追求更大的参数规模更重要。","createTime":1786597925,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"fa vNum":0,"html":"","isOriginal":0,"likeNum":0,
