大模型一定要部署在云端，通过 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 采样 ↓浏览器编码 WA V ↓加入素材库和配音轨

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； Ja vaScript 运行时； TTS 包装层； FP16 模型数据； Tokenizer 及其他语音资源； 模型清单和来源说明。

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

下载完成后，运行时会：

验证每个文件的预期大小； 验证清单中记录的 SHA-256； 按顺序重新组装模型数据； 再次验证组装后文件的哈希； 验证通过后才创建 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 会对两个镜像地址进行规范化，将它们映射到同一个内部缓存身份。模型可以从任意可用来源下载，但浏览器只保留一份有效缓存。

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

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

音色	Speaker	声音特点
晴岚	zf_001	自然、清晰的女声
若溪	zf_073	柔和、舒缓的女声
云舟	zm_009	稳定、自然的男声
景澈	zm_010	年轻、明亮的男声

四个音色共享同一个 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 FP16
英文	Kokoro 82M ONNX
德语	Piper/VITS ONNX
西班牙语	Piper/VITS ONNX
法语	Piper/VITS ONNX
意大利语	Piper/VITS ONNX
巴西葡萄牙语	Piper/VITS ONNX

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

总结

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

使用 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