使用Google Speech-to-Text v2流式转录长音频时的计费时长异常问题

问题原因 #

• isFinal触发逻辑：v2版本默认在检测到几百毫秒的音频停顿时，会将当前已识别片段标记为isFinal=true，实时返回阶段性结果，但系统会把每个isFinal片段当作独立转录任务计费。
• 计费规则影响：流式转录的计费是累加每个isFinal结果对应的音频时长，而非整体音频总时长。当停顿多次触发isFinal时，各片段时长重复计入，最终导致总计费时长超过实际音频时长。

解决方法 #

1. 调整停顿触发阈值 #

在流式请求配置中设置pauseTimeout参数，延长触发isFinal=true的停顿时间，减少不必要的阶段性结果输出。示例配置：

{
  "config": {
    "encoding": "LINEAR16",
    "sampleRateHertz": 8000,
    "languageCode": "zh-CN",
    "enableAutomaticPunctuation": true,
    "model": "long-running"
  },
  "streamingConfig": {
    "singleUtterance": false,
    "interimResults": true,
    "pauseTimeout": 2.0
  }
}

注意：pauseTimeout取值需符合官方规范，避免过长影响实时性。

2. 启用单 utterance 模式（短对话场景适用） #

如果是单轮对话场景，开启singleUtterance=true，系统仅在检测到对话结束的长停顿时返回一次isFinal=true结果，避免中间停顿触发多次计费。示例：

{
  "streamingConfig": {
    "singleUtterance": true,
    "interimResults": false
  }
}

此模式不适合多轮长对话，因为触发isFinal后流式连接会自动关闭。

3. 客户端缓存合并结果 #

若需保留实时性，可在客户端收集所有非isFinal的interimResults，待对话真正结束后，提交完整音频或合并结果进行最终转录。这种方式需自行处理音频缓存，适合对实时性要求不高但在意计费的场景。

4. 确认使用长音频模型 #

确保选用long-running模型，该模型针对持续对话优化，能更智能判断停顿是否为对话结束，减少isFinal误触发。

额外验证 #

提交请求后，可通过响应的totalBilledTime字段核对计费时长，同时检查每个isFinal结果的audioOffset，确认是否存在重复计费片段。

内容的提问来源于stack exchange，提问作者Eduardo Hermida