WebGPU 与 WASM 在浏览器端 TTS 推理中的性能取舍

总体结论

• WebGPU：延迟更低，适合频繁预览与脚本打磨。
• WASM：兼容性最好；在无 GPU 或策略受限环境最稳妥。
• 混合：开发时用 WebGPU，发布时提供 WASM 兜底。

分段与批量

按“意群”切分，每段 8–20 秒为宜。过长段落会提升峰值内存与失败概率；过短则管理开销过大。统一导出分段 WAV，最终在 DAW 或 ffmpeg 拼接。

浏览器与策略

• 企业/教育环境：优先 WASM，减少驱动/权限不确定性。
• 创作/现场演示：优先 WebGPU，加速主观听感迭代。

稳定性建议

• 长时会话中保持单标签页生成，减少上下文切换。
• 每 30–40 段重开标签页，可回收内存碎片。
• 使用 44.1/48 kHz WAV 导出，避免采样率不一致导致伪失真。

参考流程

// WebGPU 首选
撰写 → 按意群切分 → WebGPU 预览 → 导出 WAV → 后期 → 发布

// WASM 兜底
撰写 → 按意群切分 → WASM 生成 → 导出 WAV → ffmpeg 拼接 → 发布

什么时候该切换引擎

切换引擎不应该只看“速度快不快”，还要看“当前任务最怕什么”。如果当前最怕的是浏览器兼容问题、GPU 驱动差异或企业策略限制，那就先用 WASM。如果当前最怕的是反复试听慢、修改频繁、想快速出样稿，那就先用 WebGPU。

一个实用的判断顺序是：先选能跑通的，再选最快的。也就是说，第一次交付时以稳定为优先，确认整体脚本和导出链路没有问题后，再把高频编辑环节迁到 WebGPU。

常见设备场景

一个可复用的项目模板

project/
  script/
    draft.md
    final.md
  output/
    webgpu-preview/
    wasm-fallback/
  notes/
    engine-choice.md
    export-settings.md

把引擎选择写进项目目录，可以避免以后忘记“这次为什么用的是 WASM，不是 WebGPU”。这在团队协作中尤其重要，因为不同成员接手时需要知道之前的决策逻辑。

调优时最该看什么

• 首次加载时间是否可以接受。
• 长段落是否容易出错。
• 是否存在明显的尾音拖沓或句首爆音。
• 失败后是否可以快速只重跑某一段。

如果这些点都能满足，那么不管底层用的是 WebGPU 还是 WASM，实际体验都不会差。相反，如果脚本和分段混乱，再强的引擎也救不回来。

一个更接近真实项目的例子

假设你要给一段产品演示视频做旁白。前半段需要快速打样，后半段要交给剪辑师做合成。最合理的做法通常不是“全程都用同一个引擎”，而是先在 WebGPU 下快速试 2-3 轮，确认节奏和句子切分，再把最终脚本转到更稳的 WASM 路径做批量输出。

在这种情况下，WebGPU 负责帮助你快速回答“这句要不要拆”“这个词要不要换写法”，WASM 负责回答“整个项目能不能稳定交付”。两者的分工很明确，也更符合实际制作节奏。

排错清单

把引擎选择写进协作文档

如果你要和别人协作，建议把“这次项目默认引擎是什么”“遇到异常怎么切换”写成一段短说明。对团队来说，最有价值的不是某个单项性能数字，而是能否快速复现同样的结果。你可以把它写在脚本仓库的 README 里，也可以放在你自己的制作模板里。这样当你回到 主工作流指南 时，就能直接把引擎策略和脚本策略对应起来。

一个简化判断树

需要最快预览？ → WebGPU
需要最稳兼容？ → WASM
两者都要？     → 先 WebGPU 试稿，再用 WASM 批量导出
长文档易报错？ → 缩短分段，记录失败点

这类判断树的作用，是让你在每次新项目开始时不用重新思考一遍。它不替你做决定，但会把选择范围缩小到两三个可靠方案。对内容团队而言，这种“少想一步”的价值往往比某个峰值性能数字更实际。

一个真实的内容团队用法

如果你是内容编辑或者市场团队的一员，可以把 WebGPU 当作“写稿时的即时反馈”，把 WASM 当作“交付前的稳定检查”。这样一来，前半段的节奏更快，后半段的结果更稳。团队内部只要统一记住一件事：先让脚本跑通，再谈加速。

作者：Kokoro Web 团队 • 最后更新 2025‑01‑15