Paxa TTS Flash 在 104 毫秒内开始发声

9 月 24 日，我们从两座城市测量了这一部分。Google Cloud 新加坡和曼谷区域的虚拟机，像客户的服务器那样调用了生产环境的 API。

• 首段音频延迟的中位数，新加坡为 104 毫秒，曼谷为 131 毫秒。
• 新加坡 98.3%的请求和曼谷 91.2%的请求，在 200 毫秒内返回了首段音频。
• 一段 35.1 秒的泰语长文本，在 750 毫秒内完整送达。
• 全部 1,676 个语音请求均成功。

每个请求都从 POST /v1/tts 以 MP3 流式获取一句 93 个字符的泰语，使用 Nom Yen 音色，音频时长 6.9 秒。计时从客户端发出请求开始，到收到第一个音频字节为止。这段时间包括网络往返、身份验证，以及开头几个词的合成。

p99 一列是一百个请求中最慢的那一个。即便如此，首段音频在新加坡仍于 324 毫秒内到达，在曼谷于 304 毫秒内到达。

两座城市之间的差距来自网络距离。只访问 API 健康检查端点的一次往返，中位数在新加坡为 16 毫秒，在曼谷为 42 毫秒。从首段音频延迟中减去这部分，两座城市分别剩下 88 毫秒和 89 毫秒。剩下的就是 API 从收到请求到发出首段音频所用的时间，从哪座城市测都一样。

流式响应从文本开头开始返回，其余部分仍在合成。一段 420 个字符、35.1 秒音频的泰语长文本，首段音频的中位数在新加坡为 76 毫秒，在曼谷为 102 毫秒。整段文本在 750 毫秒内全部送达，速度约为播放速度的 47 倍。

同一轮测试还测量了一句英语、Opus 音频、OpenAI 兼容端点，以及更长的泰语段落。下表中的每个数字都是首段音频延迟。

英语句子使用 Cookie 音色，时长 5.3 秒。OpenAI 兼容端点 POST /v1/audio/speech 在两座城市的中位数，都与 POST /v1/tts 相差不超过 5 毫秒。为 OpenAI 语音 API 编写的代码，换一个 base URL，就能得到同样的首段音频延迟。

渲染进视频的配音，要拿到完整文件才能播放。不使用流式传输时，这句 6.9 秒的泰语以完整文件送达，中位数在新加坡为 241 毫秒，在曼谷为 280 毫秒。

• 客户端是两台 Google Cloud n4-standard-2 虚拟机，一台位于 asia-southeast1-b 可用区（新加坡），另一台位于 asia-southeast3-a 可用区（曼谷）。
• 两台机器都运行 Node.js 26.3，通过 HTTPS 调用 api.paxalabs.com，使用的 API 密钥没有设置积分上限。每台机器在一条连接上一次只发送一个请求，这条连接在请求之间保持打开。
• 两台客户端同时运行，时间为 2026 年 9 月 24 日 UTC 10:31 至 10:38，各项测试交错进行。
• 首段音频延迟在客户端测量，从发出请求开始，到收到响应体的第一个字节为止。
• 每一行统计的请求数在 46 到 299 个之间。
• 泰语请求使用 Nom Yen，英语请求使用 Cookie。两句短句是这两个音色公开发布的示例句。

文本转语音页面无需账户，就能用任意一个演示音色朗读一句话。如果要调用 API，优化延迟列出了第一个字节之前要执行的步骤，以及其中哪些由客户端控制。