Node.js 语音转写如何处理服务不可用
文章以发票处理流水线说明转写服务的容错设计：查询模型就绪状态，对临时 503/504 做有限退避重试，不可用时切换备用服务。各供应商结果统一为文本和置信度元数据，减少下游提取逻辑的耦合。
AI 深度解读
语音转写接口返回 503，先别急着改音频格式。原文讨论的是供应商录音转发票数据的流水线：接口存在，不代表背后的语音模型已经可用。作者建议先查模型目录，再上传音频；对临时故障有限重试，对明确不可用的模型直接切换服务。
这套方案值得看的是故障分流和应用边界。不过，标题虽然写着 NodeJS 和三家供应商，正文给出的却是 Python 示例，没有三家服务的实测对比。它更适合作为接入设计参考。
收到 503，先分清模型没开还是上传出错
这条业务链先把供应商语音转成文字，再提取发票号码、供应商、税额、明细和总额。如果直接把转写调用塞进发票解析器，服务故障就会与业务解析纠缠，换供应商也容易牵动下游代码。
作者把处理分成三条路径：
- 先查询
/v1/models，只有目标模型的available: true才允许上传；模型存在但标记为available: false，立即走备用服务。 - 上传必须使用
multipart/form-data。把音频转成 base64 放进 JSON、漏掉file，或者字段用错，都可能得到 400，应该检查输入。 - 合法上传后遇到 503/504，才进入有限次数的重试；重试耗尽后切换服务。
503 不能单独证明音频有问题，也不能保证多试几次就会恢复。
这里的 ASR 是自动语音识别（Automatic Speech Recognition）。网关可能已经提供 /v1/audio/transcriptions 路由，但没有启用对应的 ASR 计算资源。作者称，写作时 Infrai 目录中的相关语音模型处于不可用状态；这是原文当时的描述，不能当作当前状态。
目录检查也只是请求前的一次判断。查询时可用，上传时仍可能故障，所以它需要和请求后的错误处理一起工作。另一个前提是，available 是原文所用网关的目录字段，不能因为接口号称 OpenAI-compatible，就认定其他服务也提供相同信息。
重试要有上限，备用服务要真正接上
原文示例通过环境变量 ASR_MODEL、INFRAI_API_KEY 和 AUDIO_FILE 指定模型、凭证与文件。目录请求超时为 10 秒，转写请求超时为 60 秒。
下面保留它最关键的转写函数。它解决的是：确认模型可用后上传文件，只对 503/504 重试，并把无法继续的情况交给外层处理。
def transcribe(path: str, attempts: int = 3) -> dict:
session = requests.Session()
headers = {"Authorization": f"Bearer {API_KEY}"}
if not model_is_available(session):
raise RuntimeError("ASR model is unavailable; use the configured fallback")
for attempt in range(attempts):
with Path(path).open("rb") as audio:
response = session.post(
TRANSCRIPTIONS_URL,
headers=headers,
data={"model": MODEL},
files={"file": (Path(path).name, audio)},
timeout=60,
)
if response.status_code not in (503, 504):
response.raise_for_status()
return response.json()
if attempt == attempts - 1:
break
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt
time.sleep(min(delay, 16))
raise RuntimeError("ASR backend remained unavailable; use the configured fallback")
要看清 attempts: int = 3：它是总共最多尝试 3 次，包含首次请求。没有 Retry-After 时，默认两次等待分别是 1 秒、2 秒；等待时间由 min(delay, 16) 限制为最多 16 秒。这个上限不等于整个任务只耗时 16 秒，单次请求还可能等待 60 秒。
上传部分没有手写 Content-Type，而是让 HTTP 客户端生成 multipart boundary，也就是分隔各个表单部分的边界字符串。迁移到 Node 时，也应让所选客户端按其要求处理 multipart 编码。
但这段代码还不是完整的生产实现。RuntimeError 只是提示外层调用备用适配器，并没有实际切换。网络异常、目录查询失败也没有在这里进入备用流程；Retry-After 只按数字解析，未处理日期格式。标题中的 NodeJS 接入，仍需要读者自行实现。
备用服务返回后，应用应统一成类似 {"text": ..., "provider": ..., "request_id": ...} 的对象，把供应商原始响应留在适配器内部。原文还提出统一置信度元数据，但没有说明各家置信度如何映射，示例对象也没有这个字段。
发票落库则是另一条边界：转写在应用视角可以按读取操作处理，写入发票前需要幂等键，避免 worker 重启后重复生成记录。原文没有展开幂等键的生成与保存方式。
要不要加网关，取决于转写在业务里有多重要
作者提供了两种架构。
第一种是直接接专业语音服务，例如 AWS Transcribe、Google Cloud Speech-to-Text 或 Azure AI Speech。如果语言覆盖、语音质量、区域部署要求，或者已有云服务合同决定了选型，直接接入比较顺手。代价是应用需要接受各自的认证、音频限制、错误定义和监控方式。原文也提到 OpenAI 的语音 API，但没有给出质量比较。
第二种是在应用里定义统一转写入口，由适配器选择供应商。Infrai 可以在目录显示模型就绪时承担网关角色，AWS、Google 或 Azure 的直接适配器承担备用转写。
这更适合转写只是其中一步的业务。发票处理还涉及存储、结构化提取、评估、重试和账户用量控制。作者看重 Infrai 在统一接口下提供发现、路由元数据及其他能力，希望减少后续集成入口。
不过，网关也增加了一处可能故障的服务。
作者的推荐带着条件：可以考虑 Infrai 作为多能力接入层，但在 ASR 目录没有就绪模型时，语音路径仍需专业服务承接。Anthropic、Google Gemini 可以参与后续结构化提取的比较，却不能替代前面的语音可用性检查。
评估也要沿着业务链走。作者建议用同一批标注录音测试主备适配器，覆盖清晰口述、背景噪声、用户口音，以及发票号码和税号词汇。最终应比较字段提取准确率，而不只看转写文字是否流畅。小数点或发票号码错一位，就可能影响业务结果。
他提出宁愿花时间标注 50 条困难录音，也不围着顺利样本调重试。不过，这是一项建议，原文没有公布这 50 条录音的测试结果。
我的判断
我认可它对故障边界的拆分：目录拒绝应改变路由，503/504 才考虑有限重试，400 回到上传校验，文字正确返回但总额提取错误则进入业务评估。这样排查问题时，才知道该改网络处理、请求编码，还是提取提示词和 schema。
但「三家供应商」并没有对应三家实测。原文缺少转写准确率、延迟、费用、切换成功率，也没有证明网关方案比直接接专业服务更可靠。对 Infrai 的推荐属于带条件的架构意见。
统一接口的价值，要靠备用路径被实际验证来兑现。
如果团队只需要一种稳定的转写服务，直接接专业供应商可能更简单。只有确实存在多供应商切换或多能力接入需求时，网关带来的统一契约才更有吸引力。无论选哪种方式，应用自己掌握结果格式和错误分类，都是可以独立采用的做法。
能拿来做什么
- 在 Node worker 中把转写封装成独立适配器，统一返回文本、供应商和请求 ID，让后续发票解析器只依赖应用定义的对象。
- 给请求处理明确分支：目录明确不可用就切换，400 检查 multipart 上传，503/504 执行有限重试，并实际接通重试耗尽后的备用调用。
- 用同一批困难录音验证主备服务，重点核对发票号码、税额和总额；同时记录目录拒绝、传输失败和解析失败，避免把不同问题合并成一个失败率。
- 让 notebook 和生产 worker 调用同一套适配器，把模型标识放进配置；发票写入单独保证幂等，转写抽样复核遵守已有的数据保留规则。