从事语音转录工作的开发者，过去总是受到一道割裂感的困扰：在进行聊天时可以借助OpenRouter来开展，但进行转写时却需要额外搭建一个Whisper服务器，或者选用一家专门提供语音转文本服务的第三方SDK。7月22日，OpenRouter成功把这道裂痕抹平了——它在自家平台上线了POST /api/v1/audio/transcriptions端点，用户运用与Chat Completions完全相同的Bearer密钥，把base64编码的音频发送过去，就能够获取一份包含转录文本以及用量对象的JSON。聊天和转写从此共用同一张门票。

这份便利的核心在于功能的复用方面。你不再需要去引入新的SDK，也不需要去搭建单独的服务，因为转录功能以及聊天流量得以在同一个平台上运行，由多个提供商所托管的模型会在彼此之间自动进行负载均衡，而不是被固定在某一家供应商那里。对于已经将OpenRouter作为主力使用的团队而言，这套集成意味着可以少维护一条链路、少记住一把密钥。

在模型层面，OpenRouter提供了两条路线。一类是openai/whisper-1这样的Whisper类模型，按照音频时长也就是以每秒为单位进行计费；另一类则是更新的语音转文本（STT）模型，按照token进行计费。需要留意的是，STT模型的ID不会出现在默认的/api/v1/models目录里，因为它属于需要主动筛选的输出模态——借助?output_modalities=transcription参数，就能把这批模型及其当前定价筛选出来。如果想在接入前先行测试，OpenRouter Playground里也能直接在浏览器内上传文件完成转录。

调用方式十分简单，只需一次请求就能够完成闭环。把文件进行base64编码之后，与模型以及格式一同通过POST提交过去，随后从响应中读取text和usage两个字段即可。data字段接收的是原始base64字节，而非data: URI，因此不要为其添加data:audio/mp3;base64前缀；format字段必须填写，用于告知上游模型如何解码这些字节。如果你已经拥有针对OpenAI /v1/audio/transcriptions所编写的客户端，只需将base URL指向https://openrouter.ai/api/v1便可直接使用，实现零改动迁移。该端点同样接受OpenAI风格的multipart/form-data上传方式，将文件与模型一起提交，大小上限为25MB。
。

在字段规范方面，model以及input_audio.data、input_audio.format是必填项，其中格式可以选用wav、mp3、flac、m4a、ogg、webm、aac之一；language表示ISO-639-1语言代码，如果省略则由模型自动检测；temperature用于对采样进行控制，取值在0到1之间；response_format默认json，如果设为verbose_json就能够额外获取任务、语言、时长和片段时间戳信息，配合timestamp_granularities选择word还能获取词级时间戳，不过这两项仅在兼容OpenAI的提供商例如OpenAI、Groq、Together上有效，其余提供商则会直接返回400。provider块则用于透传各家私有参数，例如Groq可以通过provider.options.groq.prompt传入预期词汇，以帮助模型正确处理专有名词，避免把术语念错。

返回响应是一份JSON格式，其中text字符串负责装载转录处理所得的结果，而usage对象则使得费用能够按照每次请求的具体使用量来进行计量，而不是依赖于估算的方式。在一个示例当中，长度为9.2秒的音频经过处理之后产生了113个token，其中83个属于输入token以及30个属于输出token，对应标注的成本为0.000508美元。这个数字仅仅取自文档中的示例而非实际报价，真实花费则取决于所选用的模型以及音频的时长。响应头部当中还携带一个X-Generation-Id字段，这便于对某一次具体请求开展记录追踪或调试工作。

路由逻辑沿用了与聊天所采用的同一套机制。当一个转录模型由多个提供商托管时，OpenRouter会按价格开展负载均衡工作，把请求分发到各家之间，从而避免被单一供应商绑定。不过目前转录端点还没开放按请求的路由控制，聊天调用里熟悉的order、only、allow_fallbacks、data_collection、sort这些字段，在这里都不生效，provider块只携带提供商特定选项。OpenRouter明确不对提供商定价加价，目录价就是你的实付价，而零补全保险意味着失败的转写不会被计费；如果你手里有自己的提供商协议，BYOK功能允许用自有密钥路由，只付平台费、免掉按量模型成本，且按量付费模式下每月前100万次请求的平台费直接免除。

在真正着手搭建之前，有四个约束条件必须纳入架构设计当中。其一是上游存在60秒的处理超时限制，它针对的是处理耗费的时间而并非音频长度，所以体积较大或未压缩的录音容易导致超时，而对于长音频则需要分段进行转写之后再拼接文本；其二是音频URL并不支持，该端点仅接受base64编码的JSON或者不超过25MB的OpenAI风格多部分文件；其三是SRT/VTT格式的输出并不支持，如果使用srt、vtt、text格式则会被拒绝并返回400错误，时间戳信息只能借助verbose_json来获取，字幕文件需要自行根据时间戳进行拼接；其四是格式支持情况会因提供商不同而存在差异，wav属于兼容性最广的安全默认选项，而mp3等压缩格式则能够生成更小且处理更快的负载。对于一段持续数小时如同通宵游戏会话那样的录音，单次调用根本无法覆盖，必须通过分块的方式来进行处理。

最后一步在于把转录功能摆放到正确的位置上。如果你仅仅需要把音频转换成文字，那么应当运用/audio/transcriptions这个端点；如果你希望让模型针对音频内容开展推理工作，例如对客服通话进行情感分析、对音频进行问答，或者把音频与其他模态信息混合到同一个提示词当中，那么就应当选用/chat/completions端点中的input_audio内容类型。文本转语音功能则是第三个独立的端点。OpenRouter所提供的对照说明非常直白：如果要获取转录稿件，就通过转录端点来获取JSON格式的文本以及用量信息；如果需要一个能够理解音频的模型，就借助聊天补全端点获取一次对话的结果。当一份密钥能够同时覆盖对话以及语音处理时，语音能力在应用中落地的门槛，就被悄然降低了一大截。

来源：OpenRouter把语音转录塞进同一个API：一份key搞定聊天和转写，Whisper与按token计价STT一并接入 | AIbase