用一把 key 处理通话录音：转写与摘要各该派给哪个后端

两段式音频流水线的思路

处理通话录音通常分两步：第一步把音频转成文本（转写），第二步从文本中提取要点（摘要）。这两步对模型能力的要求不同：转写需要便宜、快速、能处理长音频；摘要需要理解上下文、归纳能力强。把两者拆开，各派给合适的后端，可以在效果和成本之间取得平衡。

第一步：转写该派给谁

转写是流水线中耗时和消耗 token 最多的环节，优先级是“便宜且稳定”。

• 选择单价较低的模型后端，优先保证单位成本可控。
• 如果后端支持音频输入，直接把音频交给模型；如果不支持，先用本地或第三方工具转成文本，再进入下一步。
• 对长录音做分段处理，每段独立转写，最后按时间顺序拼接。
• 保留时间戳和说话人标记（如果后端支持），方便后续摘要定位。

这一步不需要最强的模型，因为目标是把语音准确变成文字，而不是做复杂推理。

第二步：摘要该派给谁

摘要面对的是完整对话文本，需要理解上下文、区分事实与寒暄、提炼行动项。这一步值得用更强的模型。

• 把转写文本按段落或话题切分，避免一次性塞入超长上下文。
• 在提示词中明确输出结构，例如：通话目的、关键结论、待办事项、风险点。
• 如果对话涉及多轮来回，可以保留说话人标签，帮助模型区分谁承诺了什么。

强模型在这里的产出质量差异明显，所以把预算集中在这一步是合理的。

用一把 key 调多个后端

聚合型 API 服务的好处是：同一个 API key 可以调用多个模型，不需要为每个后端单独申请账号和密钥。对两段式流水线来说，这意味着：

• 转写和摘要可以写在同一个服务里，用不同的模型名切换后端。
• 密钥管理集中，减少泄露面。
• 计费统一，便于核算每一步的成本。

需要注意的是，不同后端的输入格式、音频支持能力、上下文长度并不一致，切换时要按后端文档调整请求体。

经过代理时容易出问题的环节

把请求发往聚合代理，而不是直连官方 API，会在几个地方引入差异：

• 音频上传方式：部分代理只透传文本接口，不支持音频文件直传。如果转写依赖音频输入，要先确认代理是否支持该后端的音频端点；不支持时改为本地转写。
• 超时与长请求：转写长录音的请求耗时较长，代理层可能有自己的超时设置，容易在官方 API 返回前断开。解决方式是分段请求，缩短单次时长。
• 请求体大小限制：代理可能对上传体积设限，大音频文件会被拒绝。同样用分段来规避。
• 错误码与重试：代理返回的错误信息可能经过包装，和官方错误码不完全对应。重试逻辑要按代理文档处理，避免对不可重试的错误反复请求。
• 流式输出：摘要步骤如果用流式返回，要确认代理是否完整透传流式响应，否则可能拿到截断的结果。

一个可落地的流程

1. 录音按固定时长切段，逐段调用低成本后端转写。
2. 拼接转写文本，保留时间戳和说话人标记。
3. 按话题切分文本，逐段调用强模型生成摘要。
4. 合并摘要，输出结构化结果。
5. 记录每一步的 token 消耗，便于成本归因。

成本与计费提醒

使用聚合服务时，计费规则和官方价不同。以本站为例：用户按官方价 ×1.3 扣费；贡献 key 按官方价 ×1.1（优质 ×1.2）返 USDC。把转写放在便宜后端、摘要放在强后端，是在这个计费结构下控制总成本的自然做法。具体单价以各后端官方定价为准，这里不展开。

小结

两段式流水线的关键不是“用最强的模型做所有事”，而是让每一步匹配它真正需要的能力。转写求稳求省，摘要求准求精。经过代理时，提前确认音频端点、超时、体积限制和流式支持，可以避免大部分联调问题。