浏览器本地跑中文 TTS：我们将 Kokoro 1.1 转为 FP16，替换了 Piper 中文配音

大模型一定要部署在云端，通过 API 才能使用吗？

在 Timeline Studio v1.0.0 中，我们尝试了另一条路线：将 Kokoro multi-lang v1.1 转换为 FP16 半精度模型，通过 sherpa-onnx WASM 直接在浏览器中运行，用它替换原有的中文 Piper/VITS ONNX 配音。

升级后的中文配音支持四个音色以及中英文混合文案。用户的视频、音频、配音文案和生成结果都留在浏览器本地，不需要上传到我们的编辑服务器。

项目已经开源：

• GitHub：https://github.com/MartinDelophy/ai-video-editor
• 在线体验：https://video-editor.ai-creator.top/
• Hugging Face Space：https://huggingface.co/spaces/haixin/timeline-studio

如果你关注浏览器 AI、WebAssembly、ONNX 或视频编辑，欢迎在 GitHub 点个 Star。

从 Piper 中文配音说起

Timeline Studio 是一个本地优先的开源 AI 视频编辑器。

项目将多轨时间线、AI 配音、自动字幕、AI 音乐、画面分析和浏览器导出放在同一个编辑界面中。用户选择本地视频或图片后，可以直接在浏览器中完成剪辑和 AI 处理。

在早期版本中，我们使用 Piper/VITS ONNX 提供中文配音。

Piper 的优势很明确：

• 模型相对紧凑；
• ONNX 部署路径成熟；
• 可以在浏览器端运行；
• 不需要调用第三方 TTS API；
• 适合快速建立完整的配音工作流。

不过，随着 Timeline Studio 从技术原型逐渐进入真实创作场景，原有中文声音的局限也越来越明显。

用户不仅需要“把文字读出来”，还需要更自然的语气、更多可选音色，以及对中英文混合文案更好的支持。

例如下面这类视频文案非常常见：

Timeline Studio 是一个 local-first AI 视频编辑器，
支持 WebGPU、WebAssembly 和浏览器本地模型推理。

如果把中文与英文分别交给不同模型生成，再将音频拼接起来，往往会出现音色不一致、停顿突兀和语速变化。

因此，我们决定替换中文 Piper 路径。

为什么选择 Kokoro multi-lang v1.1？

选择 Kokoro multi-lang v1.1，主要基于三个原因。

第一，它在中文语音自然度上具备更好的产品潜力。

第二，它能够将中文和句子中的英文作为同一个语言单元处理，更适合科技产品、软件教程和开发者内容。

第三，同一套模型可以提供多个 Speaker。用户切换音色时，不需要分别下载四套完整模型。

不过，原始模型能够运行，并不意味着它已经适合浏览器产品。

浏览器环境没有服务器端那么充足的内存和稳定的运行条件。模型交付需要同时解决下载体积、内存占用、主线程阻塞、缓存容量、版本固定和网络线路等问题。

将模型转换为 FP16

为了降低模型传输及运行压力，我们将 Kokoro multi-lang v1.1 转换为 FP16 半精度版本，并打包为 sherpa-onnx WASM 可加载的浏览器运行时。

完整链路如下：

用户文案
   ↓
文本规范化
   ↓
选择 Speaker ID
   ↓
加载 Kokoro v1.1 FP16
   ↓
sherpa-onnx WASM 推理
   ↓
返回 PCM 采样
   ↓
浏览器编码 WAV
   ↓
加入素材库和配音轨

FP16 相比 FP32 可以降低模型文件和运行时内存带宽压力，使体量更大的 TTS 模型更有机会进入浏览器。

我们没有对外宣称 FP16 可以解决所有性能问题。模型首次使用仍然需要下载，实际生成速度也会受到设备、浏览器、内存和网络环境影响。

但相比把中文配音固定在服务器 API 上，FP16 加 WASM 给了我们一条可缓存、可复用并且本地执行的路径。

使用 Web Worker 隔离模型推理

如果直接在主线程加载并运行语音模型，模型初始化和语音生成可能阻塞编辑器界面。

对于视频编辑器来说，这是无法接受的。用户在等待配音时，仍然需要查看时间线、调整文案和操作素材。

因此，Timeline Studio 将 Kokoro 运行时放入独立 Web Worker。

编辑器主线程负责：

• 传入文案、音色和语速；
• 展示模型下载及初始化进度；
• 接收生成状态；
• 将音频写入素材库；
• 更新配音轨和字幕状态。

Worker 负责：

• 获取模型清单；
• 下载运行时与模型分片；
• 校验文件完整性；
• 组装模型数据；
• 初始化 sherpa-onnx WASM；
• 执行语音推理；
• 返回生成的音频采样。

首次初始化完成后，Worker 会在当前页面继续存活。用户修改文案再次生成时，可以复用已经创建的 TTS 会话。

大模型文件并行下载与完整性验证

浏览器加载模型不能只调用一次 fetch()，然后默认返回内容一定正确。

我们的 Kokoro 浏览器运行包包含：

• sherpa-onnx WASM；
• JavaScript 运行时；
• TTS 包装层；
• FP16 模型数据；
• Tokenizer 及其他语音资源；
• 模型清单和来源说明。

较大的数据文件会被拆分为多个部分。Worker 根据模型清单并行下载各个文件，同时累计并上报整体进度。

下载完成后，运行时会：

1. 验证每个文件的预期大小；
2. 验证清单中记录的 SHA-256；
3. 按顺序重新组装模型数据；
4. 再次验证组装后文件的哈希；
5. 验证通过后才创建 TTS 会话。

这能够降低文件被代理缓存截断、下载不完整或者模型版本不一致导致的异常。

ModelScope 与 Hugging Face 双镜像

模型下载是浏览器 AI 在国内落地时绕不开的问题。

仅提供一个海外模型地址，很容易让模型功能在部分网络环境中变得不可用。反过来，只提供单一国内来源，也无法覆盖所有用户。

因此，Timeline Studio 将语音模型同步到项目自有的 ModelScope 与 Hugging Face 镜像，并固定到不可变版本。

模型来源策略为：

• 中文及国内环境优先访问 ModelScope；
• 其他环境优先访问 Hugging Face；
• 当前来源下载失败时自动尝试另一个镜像；
• 两个来源映射到同一个模型缓存身份；
• 切换来源后不重复缓存相同版本；
• 不依赖可能随时变化的上游 main 分支。

这里有一个比较容易被忽略的问题：同一个模型在 ModelScope 和 Hugging Face 上的 Revision 并不相同。

如果直接用完整 URL 作为 Cache Storage 的 Key，浏览器会认为它们是两个不同的模型，可能重复保存几百 MB 的相同文件。

Timeline Studio 会对两个镜像地址进行规范化，将它们映射到同一个内部缓存身份。模型可以从任意可用来源下载，但浏览器只保留一份有效缓存。

四个中文音色共享一个模型

新版中文配音提供四个音色：

四个音色共享同一个 FP16 模型，通过 Speaker ID 选择目标声音。

在编辑器内部，它们分别映射为：

晴岚 → zh_f_qinglan → Speaker 0
若溪 → zh_f_ruoxi  → Speaker 1
云舟 → zh_m_yunzhou → Speaker 2
景澈 → zh_m_jingche → Speaker 3

音色并不是越多越好。浏览器视频编辑器的音色目录更需要明确、稳定和可试听。

因此，我们只选择了四个差异比较清晰的声音，并为每个声音提供使用相同 Speaker 生成的真实中文试听样本。

中文和英文作为一个完整语句生成

新版文字处理链路允许中文、英文、数字和常用标点进入同一次推理。

例如：

使用 Timeline Studio，
可以在浏览器里完成 AI video editing 和自动字幕。

这段话不会被拆成多个语言片段，而是作为一个完整语句交给 Kokoro multi-lang v1.1。

这样可以保留：

• 相同的说话人音色；
• 连续的语气和语速；
• 标点产生的自然停顿；
• 中文与英文之间的上下文；
• 一条完整且易于编辑的音频素材。

对于包含英文品牌、API、模型名称和技术术语的中文内容，这项能力非常实用。

浏览器存储空间也需要管理

模型可以缓存，并不代表可以无限缓存。

Timeline Studio 中除了语音模型，还有字幕、视觉分析、AI 音乐、语音克隆和其他浏览器 AI 模型。如果每次升级都保留一份旧模型，很快就会占满浏览器存储空间。

新版语音运行时会在模型初始化前进行容量预检查，并在版本升级时执行缓存迁移：

• 识别旧的语音模型版本；
• 复用没有变化的文件；
• 删除已经变化的模型分片；
• 移除历史遗留的 Kokoro FP32 文件；
• 避免 Piper 文件在多个缓存中重复保存；
• 空间紧张时优先清理不再使用的语音模型。

缓存升级是浏览器 AI 工程中不太显眼但非常重要的一环。如果只考虑第一次下载，不考虑第二次发布和第三次升级，产品最终很容易被旧模型缓存拖垮。

生成音频只是工作流的开始

Timeline Studio 不是一个独立的 TTS 演示页面。

通过 Kokoro 生成的中文配音会直接进入视频编辑工作流。用户可以继续：

• 试听和重新生成；
• 调整语速与输出增益；
• 将音频加入“我的素材”；
• 放入独立的配音轨；
• 移动、裁切和重新排列；
• 生成并编辑字幕；
• 混合视频原声、配音和背景音乐；
• 导出 MP4 或 WebM；
• 保存可继续编辑的 .timeline 项目。

这也是我们替换中文 Piper 的真正原因。

模型效果的提升只有进入完整创作链路，才能转化为用户实际感知到的产品升级。

Piper 并没有被完全移除

本次更新替换的是中文 Piper 路径，而不是删除整个 Piper 体系。

当前语音路由大致如下：

不同语言使用不同的专用模型，比强行使用一套模型覆盖全部语言更容易获得稳定结果。

总结

这次中文配音升级主要完成了以下工作：

• 使用 Kokoro multi-lang v1.1 替换中文 Piper；
• 将模型转换为适合浏览器交付的 FP16 版本；
• 使用 sherpa-onnx WASM 进行本地推理；
• 通过 Web Worker 隔离模型初始化和生成任务；
• 提供两条女声和两条男声；
• 支持中文与英文混合生成；
• 使用模型清单、文件大小和 SHA-256 验证下载内容；
• 接入 ModelScope 与 Hugging Face 双镜像；
• 为不同镜像建立统一缓存身份；
• 加入存储容量预检查和旧版本缓存迁移；
• 将生成结果接入完整的视频编辑时间线。

浏览器 AI 的价值不只是“无需安装”，而是让模型、用户素材和编辑状态处于同一个本地工作流中。

我们还会继续探索更多可以真正进入视频创作流程的浏览器 AI 能力。

项目采用 MIT License 开源。如果这项工作对你有参考价值，欢迎 Star、Fork、提交 Issue 或参与贡献：

• GitHub：https://github.com/MartinDelophy/ai-video-editor