经一把聚合 key 发送音频片段：哪些后端接受、负载长什么样

很多聚合站都提供 OpenAI 兼容的 /v1/chat/completions 或 /v1/audio/transcriptions 接口，但同一个请求发出去，落到底层不同模型时行为可能完全不同：Claude 可能直接拒绝音频内容块，GPT 系列可能接受但走的是另一套 input_audio 格式，DeepSeek/Qwen 等文本模型则可能把音频字段静默丢弃、只返回一段基于文本的“猜测”。下面给出发送音频片段的确切结构、常见后端的行为对比，以及你应当先做的校验。

先确认走哪条路径

OpenAI 兼容层里，音频相关请求通常有两条路径，概念上不要混用：

• 音频转写端点 /v1/audio/transcriptions：典型是多段表单上传一个音频文件，返回文本。它面向语音转文字模型（如 Whisper 类），不经过聊天补全。
• 聊天补全中的音频内容块 /v1/chat/completions：把音频作为消息内容的一部分随请求发送，由多模态模型理解。音频是 content 数组里的一个块，不是单独的字段。

聚合站一般会按模型名把请求路由到对应后端。音频能不能被真正理解，取决于最终被选中的那个模型是否原生支持音频输入，以及聚合层是否透传了该字段。

聊天补全里的音频块长什么样

以 OpenAI 兼容的聊天接口为例，音频通常作为 input_audio 类型的内容块嵌入用户消息：

{
  "model": "<目标模型名>",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "input_audio",
          "input_audio": {
            "data": "<base64 编码的音频字节>",
            "format": "wav"
          }
        },
        { "type": "text", "text": "请转写这段音频并标出说话人切换点" }
      ]
    }
  ]
}

几个结构性要点：

• content 是数组，文本与音频是并列的块，顺序即模型看到的顺序。
• 音频放在 input_audio.data，通常是 base64 字符串；format 用来声明编码格式（如 wav、mp3）。
• 不要在顶层另塞一个 audio 字段，那属于另一套接口参数，混用容易让聚合层或后端解析失败。
• 若站方提供了文件上传后再引用的机制，按站方文档的字段走，但本质仍是把音频块并入消息。

后端接受程度的现实差异

同一个请求，按模型路由后大致会出现三类行为：

• 原生支持并解析：多模态音频模型会真正解码音频内容，返回基于音频的转写或回答。
• 报错拒绝：部分后端在解析 content 时遇到未知块类型，会返回 4xx，提示内容块不被支持。这至少是显式失败，你能立刻发现。
• 静默丢弃：更危险的一类。文本模型不认识音频块时，可能忽略该块、只用文本部分作答，或者把 base64 当成一段无意义字符串处理。响应看起来“成功”，内容却与音频无关。

聚合站的关键作用在于路由：一个 key 可以选不同模型，但“能否处理音频”是模型自身能力，不是聚合层凭空赋予的。所以先按候选模型分别发一次最小请求，观察行为，而不是假定所有模型都一样。

信任转写结果前的校验步骤

在把返回文本用于下游流程前，建议按下面顺序做检查：

1. 先看 HTTP 状态与错误体。4xx 明确说明该模型或该路径不接受音频，直接排除，不要重试同一结构。
2. 检查响应是否自洽。如果返回文本里出现“我无法访问音频”“请提供文字内容”之类表述，说明音频很可能没被解析。
3. 做对照实验。同一段音频、同一提示，分别发给一个已知支持音频的模型和一个文本模型，比较输出。文本模型的输出若与音频内容无关，就是静默丢弃的信号。
4. 用可验证片段测试。选一段包含明确、可核对信息（如一句特定的话、一个数字）的短音频，检查转写是否包含这些内容。不要用模糊音频判断，那无法区分“没解析”和“解析差”。
5. 检查响应元信息。若响应里带有用量或模态相关信息，确认其中体现了音频输入；若完全没有音频痕迹，需警惕。
6. 在代码里加断言。对转写结果做长度下限、关键词命中、语言一致性等轻量校验，不通过就标记为可疑，而不是默默入库。

工程上的稳妥做法

• 把音频能力当作模型属性显式配置。在客户端维护一个“该模型是否支持音频”的白名单，路由前先判断，避免把音频发给文本模型。
• 优先用专用转写端点。如果目标只是语音转文字，/v1/audio/transcriptions 语义更清晰，失败模式也更明确；聊天补全里的音频块更适合“理解音频并回答”的场景。
• 失败要显式。在提示里要求模型在无法访问音频时明确说明，而不是猜测；同时在客户端对 4xx 和可疑成功分别处理。
• 注意负载体积。base64 会膨胀原始字节，长音频容易触发请求体积限制；必要时先切片，再逐段发送并在客户端拼接校验。
• 不要跨后端假设一致性。同一个聚合 key 下，Claude、GPT、DeepSeek、Qwen、GLM、Kimi 对音频块的处理可能各不相同，按模型分别验证，别用一个模型的结论推断另一个。

小结

音频能否通过 OpenAI 兼容路径真正被处理，取决于被路由到的模型和聚合层的透传行为，而不是接口路径本身。请求结构上，把音频作为 input_audio 内容块并入消息；验证上，先用最小请求区分“接受”“报错”“静默丢弃”三类结果，再用可核对片段和客户端断言确认转写可信。把这些检查前置，比事后发现转写内容与音频无关要省事得多。