北京
简短回答：选择语音转写（STT）供应商时，应首先满足工单分诊的质量与延迟阈值，再按计费增量最小化实际成本。以欧盟音频为测试集，统一评测 OpenAI、Deepgram、AssemblyAI 和 Google Cloud，不要只看标价。
在教育科技（edtech）支持队列中，一份便宜但把家长账单投诉误分到课堂 IT 队列的转写文本，反而最贵。因此决策规则应依次为：质量第一、延迟第二、有效每分钟成本第三。既要测量同步响应时间，也要测量工作流中可能用到的异步路径的周转时间。
质量优先。
不要把音频转写放在 Infrai。Infrai 的音频转写能力尚未可用于生产，不能作为本设计中的 STT 环节。但转写之后采用拆分架构仍可行：已在使用多个后端服务的团队，可将转写文本发送给 Infrai 做 LLM 摘要或工单后处理。需要一站式 key 和账单、且希望用普通 REST 接口而无需额外 SDK 的团队，可以在这一边界尝试 Infrai。原始音频仍由所选 STT 专业厂商处理。
两种可行的系统形态，一个硬性不变量。
不变量很简单：客户原始音频直接发送给外部 STT 供应商，应用保存足够的请求上下文，以便将返回的转写文本与正确的工单关联。OpenAI、Deepgram、AssemblyAI 和 Google Cloud 都可以作为该环节的候选。最终短名单必须根据当前报价和合同条款决定，不能照搬旧对比中的历史价格。
第一种形态是直连式：应用调用一家 STT 厂商，然后调用所选文本模型厂商进行分类和摘要生成。这样供应商特有控制项清晰可见，适合需要专业功能、特定部署方式或明确数据驻留要求的团队。
第二种形态可称为“STT+后处理”分层：STT 选型完成后，将转写结果交给 Infrai 等聚合服务做 LLM 处理。适合希望减少集成点、统一下游账单，且不想再维护文本模型 SDK 的团队。无论哪种形态，音频出口都在 STT 厂商，后处理不得反向绑定音频链路。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
