AssemblyAI 音频转文字怎么选：模型、说话人分离与价格

如果你正在开发一款产品，希望同一段音频既能生成转写文本，又能标注说话人、整理结构化笔记，AssemblyAI 值得考虑。选择 AssemblyAI 音频转文字方案，首先要确定处理方式：目前的录音转写旗舰支持 18 种语言，实时旗舰支持 32 种。会议纪要可以从录音转写入手；如果应用必须在对话结束前作出反应，就选流式处理。

AssemblyAI 是什么，能用来做什么？

AssemblyAI 是面向开发者的语音平台，能将音频转成文字，还提供文本分析、语音生成和语言模型调用 API。你提交录音或实时音频流，再围绕返回结果构建应用，例如可检索的访谈、会议摘要、通话分析界面或语音智能体。它提供语音处理组件；产品的界面、存储、权限和业务操作仍需自行开发。

模型、功能和价格已于 2026 年 11 月 5 日对照 AssemblyAI 官网核实。本文依据文档、公开产品页面及下文的成本计算进行评估，未开展音频识别准确率或延迟实测。

哪些产品适合用，哪些需求应该另找方案？

如果交付结果既要有转写文本，也要有基于文本提炼的信息，就可以将 AssemblyAI 列入候选。招聘产品需要标明说话人的面试笔记；客服产品需要可检索的通话和提取出的问题；语音助手则需要识别用户说了什么，并获得可用的信号来判断对方是否说完。

本评估关注的是处理模式、所需语言、说话人归属、下游输出，以及这套配置的实际账单。笼统的准确率宣传无法回答这些问题。

AssemblyAI 与 Deepgram 怎么选？

如果核心问题是控制对话轮次，Deepgram 更值得优先考察：Flux 将轮次结束检测集成在模型中，并支持配置轮次行为。Flux 快速入门也明确了一处接入边界：Flux 使用 /v2/listen，不能直接套用旧的 /v1/listen 转写连接。如果电话助手总打断用户，或用户说完后迟迟不回应，可以将它纳入候选，用自己的通话样本比较这些行为。

什么情况下更适合 ElevenLabs？

如果需要支持更多实时语言，或重点处理媒体内容，ElevenLabs 更值得考察。其语音转文字文档列出了覆盖 90+ 种语言的 Scribe v2 和 Scribe v2 Realtime，批量输出还包含非语音音频事件标签。承诺各模式功能一致之前，应分别核实。同一份文档说明它没有逐字保留模式；如果必须保留每一次犹豫和停顿词，这就是需要评估其他方案的具体原因。

什么情况下更适合 OpenAI？

如果应用已经接入 OpenAI API，只需在现有集成中增加转写，OpenAI 更合适。其转写迁移指南区分了处理完整音频的 GPT-Transcribe（gpt-transcribe）与处理持续实时输入的 GPT-Live-Transcribe（gpt-live-transcribe）。需要说话人标签的文件采用独立的 gpt-4o-transcribe-diarize 工作流；不要默认换用更新模型后，原有字幕格式和时间戳仍然保留。

想了解更多候选，可以阅读语音转文字 API 对比。如果只想要开箱即用的会议纪要应用，应先评估这类成品，再决定是否投入 API 集成开发。

AssemblyAI 音频转文字：录音处理与模型选择

对于已经结束的会议、访谈和通话，AssemblyAI 的录音转写 API 是自然的起点。文件采用异步处理：应用提交任务，处理完成后再获取结果。阅读纪要的人通常不需要在发言者还在说话时就看到转写文本。

模型名称必须看清，因为稳定版录音模型、预览版和实时旗舰是不同产品。当前模型目录及各模式的选型页面列出了以下阵容：

录音与实时两行中都出现了 universal-3-5-pro，但这不代表 API 可以互换。录音请求使用复数形式的 speech_models 数组；流式连接使用单数形式的 speech_model 参数。

Universal-3.5 Pro 的录音转写支持英语、西班牙语、德语、法语、葡萄牙语、意大利语、土耳其语、荷兰语、瑞典语、挪威语、丹麦语、芬兰语、印地语、越南语、阿拉伯语、希伯来语、日语和普通话。语码切换指的是识别对话中途更换语言的情况，而不是要求每段录音始终使用同一种语言。

AssemblyAI 的录音模型选择文档说明，默认组合为 ["universal-3-5-pro", "universal-2"]。系统会按顺序选择首个支持检测到或指定语言的模型。应检查结果中的 speech_model_used，不要以为每个任务都用了旗舰模型。

例如，一款产品同时服务英语和韩语面试。英语可以使用 Universal-3.5 Pro；韩语不在该模型的语言列表内，需要转向语言覆盖更广的录音处理路线。如果将整个应用笼统称为“支持 99 种语言的转写”，就掩盖了模型切换，而评估时必须把这项变化考虑进去。

会议录音转写可以怎样接入？

AssemblyAI 的文件转写快速入门支持托管音频 URL，也支持上传本地文件。开发会议纪要功能时，可以按以下顺序处理：

1. 1

   确定模型与语言处理路线

   显式设置所需的 speech_models 数组。如果应用事先不知道音频语言，启用 language_detection。在任务元数据中保留所选模型，便于评估时区分不同处理路线。

2. 2

   请求产品真正需要的转写结果

   将录音提交到 POST /v2/transcript。如果界面需要标明每段话是谁说的，设置 speaker_labels: true。如果评估录音表明客户名、产品名等词汇容易出错，可添加相应关键词。

3. 3

   等待任务完成

   轮询 GET /v2/transcript/{id}，或使用完成通知 webhook。明确处理任务失败的情况。将转写 ID 与自己的会议 ID 一起保存，确保后续摘要和修订仍对应正确的会议。

4. 4

   依据可追溯的发言生成纪要

   生成摘要前，保留说话人的发言片段和时间戳。对某项决定有异议时，管理者应能打开对应的原始片段，而不只是收到一段缺乏依据的文字。

关键词与上下文提示解决的是不同问题：关键词列出可能出现的词汇；上下文提示描述场景。Universal-3.5 Pro 最多接受 1,000 个关键词，Universal-2 最多接受 200 个。无论使用哪一种，都不应只凭一段音质干净、词汇熟悉的样本判断效果。

什么时候该用 Sync 或 Dictation？

AssemblyAI 的 Sync 语音转文字 API 在一次 HTTP 响应中返回完整转写。对于简短语音消息等交互，如果异步任务管理只会增加不必要的应用状态，就可以选它。Sync 快速入门区分了不同接口的限制：原始 HTTP 上传最长可达 20 分钟，SDK 或实时上传请求则上限为 120 秒。如果原型用 SDK、后来又要接收更长录音，这个接口差异就很关键。

Dictation API 会在同一请求中同时返回转写文本及整理或格式化后的文字。它适合将口述消息转为可直接发送的文本。如果产品需要保留原话，就用普通转写；如果用户要求的结果本身就包含文字润色，再选择 Dictation。

实时语音识别：语音智能体与实时字幕

AssemblyAI 流式处理适合必须在对话过程中作出反应的应用。持续的 WebSocket 连接接收音频，并随语音到达不断发出转写事件。字幕界面展示这些更新，语音智能体的编排逻辑则据此决定下一步操作。

新集成可以先评估 Universal-3.6 Pro Realtime。流式模型选择页面说明，省略 speech_model 时默认使用它。建议显式固定模型，便于配置审查时说明实际计划部署的版本。

低价方案的覆盖范围更窄。Universal-Streaming English 在价格页面上称为 Universal-Streaming，用于英语。Universal-Streaming Multilingual 支持英语、西班牙语、德语、法语、葡萄牙语和意大利语，按轮次处理语言。实时旗舰则在更广的语言范围内原生支持语码切换。因此，同一句话内切换语言的双语来电者，应与轮次之间更换语言的来电者分别准备评估录音。

对于预约助手，有价值的结果是识别出正确的预约请求，并在恰当的时机回应。某段转写片段里的日期可能已经正确，但客户还在修改时间。如果把每个片段都当成完整指令，即使识别的文字无误，也可能订错时间。

流式快速入门介绍了 Begin、Turn 和 Termination 消息。带有 end_of_turn: true 的 Turn 表示该轮次已最终确定。端点检测信号只标记语音边界，并不代表用户授权执行交易。应分别处理临时文本与业务逻辑实际提交的文本，使音频编码和采样率与来源匹配，并在通话结束时终止会话。

合理的评估应分别记录不同失败类型：词语识别错误、实体错误、抢答，以及用户请求结束后等待过久。除了转写耗时，还要测量从用户说完请求到智能体开始回应的完整延迟；应用、语言模型和语音输出都会影响这个时间。

AssemblyAI 说话人分离：怎样判断是谁说的？

AssemblyAI 的说话人分离会按声音将发言归组，回答的是“这句话由哪个声音说出”。Speaker Identification 是另一项功能，尝试给声音关联姓名或角色。转写中有“A”和“B”，并不代表已经确定谁是面试官、谁是客户。

对于录音，设置 speaker_labels: true 可生成带说话人归属的发言片段，具体见录音说话人分离文档。这些片段适合用于访谈播放器：高亮当前说话人，并跳转到相应音频。

对于实时音频，AssemblyAI 返回轮次级的 speaker_label，也会在最终确定的词上提供说话人字段。但这些归属仍可能调整，应用必须支持修正。流式说话人文档介绍了用于修改早先轮次的 SpeakerRevision 消息，最后的修订会在 Termination 之前送达。

设想项目会议中，一句简短的“我来做”被转成了待办任务。如果最初的说话人标签有误，而应用从未应用后续修订，最终纪要就可能把任务分配给错误的人。应按 turn_order 存储轮次、应用修正，再根据修正后的转写生成最终纪要。若只将最初的文本事件写入不可修改的日志，这种存储设计就不适合该功能。

还有两项容易忽略的限制：

• max_speakers 是硬上限。 超出上限后，额外说话人会合并进已有标签。如果只按预计参会人数设置，未给迟到加入者留空间，就可能损害归属准确性。
• 简短回应可能标为 PENDING。 在获得足够证据或收到修正前，应将其视为尚未确定归属。重叠发言同样难处理；文档说明，无法直接将同时说话的人拆成彼此独立的声音。

如果录音系统已经将每位参与者录在独立声道，应保留这种结构并评估多声道转写。声道分离与说话人分离解决问题的方式不同：前者利用录音已有的结构，后者从混合音频中推断说话人变化。多声道处理也会改变费用。

Speech Understanding 与 LLM 能力如何使用？

相比只返回转写文本的接入方式，AssemblyAI 的 Speech Understanding 是更有说服力的选择理由。Speech Understanding 文档列出了行动项、自动章节、自定义格式、实体检测、关键短语、情感分析、说话人身份识别、摘要、主题检测和翻译功能。

会议纪要的有效流程应当具体：先转写会议，确认说话人归属，生成摘要，再提取行动项及负责人。客服分析则可能需要从已结束的通话中提取实体和主题。如果默认购买所有分析功能，却没确认产品如何使用输出，只会增加支出。

如果输出需要遵循自己的数据结构或推理指令，可以使用 LLM Gateway。大语言模型（LLM）可将转写文本转成 decision、owner、due_date 和 evidence 等字段。Gateway 快速入门介绍了通过 transcript_id 注入转写文本，以及通过统一 API 使用结构化输出、工具调用、重试和模型回退。

工作流仍需明确定义什么才是有效答案。如果发言者说“下周某个时候”，提取结果应保留不确定性，而不是编造一个具体日期。如果无人认领任务，负责人字段留空比填入看似合理的名字更有用。将提取出的条目关联回相应发言，方便人工核对。

有效的 JSON 响应只能证明输出符合指定结构，不能证明其中的行动已经发生，或某人已经同意执行。在提取的笔记修改客户记录或分派重要任务之前，应在应用中加入审批步骤。

Medical Mode 是可选的医学词汇领域附加功能，适用于部分受支持的录音和流式模型，语言包括英语、西班牙语、德语和法语。它的覆盖范围小于平台整体的语言覆盖。多语言临床产品必须单独验证该领域模式，不能假设每一种转写语言都享有相同的专业能力。

AssemblyAI-TTS-1 处理相反方向的任务：通过流式 WebSocket 或 HTTP 将文字变成语音。它支持英语、西班牙语、德语、法语、意大利语和葡萄牙语，还支持声音克隆和词级时间信息。对于语音智能体，输入模型、推理模型和输出声音都需要分别检查。实时转写模型支持的语言，不会自动成为语音输出支持的语言。

AssemblyAI 价格：模型与附加功能分别怎么算？

对本文面向的开发者来说，AssemblyAI 的按量付费是合理起点：没有最低消费承诺，费用取决于启用的模型和功能。以下为 AssemblyAI 价格页面公布的费率，核实日期为 2026 年 11 月 5 日。录音按处理的音频时长计费；流式按会话连接开启时长计费。

• **Universal-3.5 Pro：**录音音频每小时 $0.21。
• **Universal-2：**录音音频每小时 $0.15。
• **Universal-3.6 Pro Realtime：**流式会话每小时 $0.45。
• **Universal-Streaming：**流式会话每小时 $0.15；文档中称为 Universal-Streaming English。
• **Universal-Streaming Multilingual：**流式会话每小时 $0.15。
• **Universal-3.6 Pro Preview：**当前价格页面未单列费率；为预览版部署做预算前应先确认。
• **Universal-3.5 Pro Realtime：**文档仍列为受支持，但当前价格页面未单列费率；现有固定版本集成应确认实际价格。
• **Sync API：**音频每小时 $0.30。
• **Dictation API：**每小时 $0.62，包含页面列出的格式化和提示功能。
• **AssemblyAI-TTS-1：**每百万输入字符 $15。

对于前面的会议纪要和语音智能体流程，还需考虑以下费用：

• **Speaker Diarization：**录音每小时加 $0.02，或流式会话每小时加 $0.12。
• **Summarization：**默认的低推理强度每小时加 $0.02，中等推理强度加 $0.07。
• **Speaker Identification：**默认的低推理强度每小时加 $0.02，中等推理强度加 $0.10。
• **Medical Mode：**适用模型每小时加 $0.15。
• **Universal-3.5 Pro 提示功能：**关键词和上下文提示分别列价，各为每小时 $0.05；Universal-2 包含关键词功能。
• **流式关键词：**Universal-3.6 Pro Realtime 已包含；Universal-Streaming 每小时加 $0.04。

LLM Gateway 根据所选模型，另行收取输入 token 和输出 token 费用。token 是模型处理文本的计量单位。公布的 Gateway 费率采用全球路由；价格页面说明，美国/欧盟区域路由贵 10%。估算自定义提取流程时，也应计入这项选择。

这个对比能帮助作出实际选择。如果两个录音模型都符合验收标准，Universal-2 更省钱；如果更贵的模型能减少足够多的修订工作，值得这笔差价，就选它。计算本身并未预设任何一个模型能够通过你的音频评估。

对于实时会话，计费文档明确了计量方式：只要 WebSocket 保持开启就会计时，包括空闲时间。以 1,000 会话小时为例，Universal-3.6 Pro Realtime 加说话人分离的费用为 $570，尚未包含 LLM 调用或语音生成。一条连接开启一小时，即使其中只有 20 分钟语音，也会产生一小时用量。交互结束后应及时关闭连接。

多声道转写按声道计费。一小时录音若作为两个独立声道处理，就会产生两小时转写用量。预算既要考虑模型，也要考虑录音结构；单声道会议与分声道通话不能按相同成本输入计算。

价格页面宣传可免绑卡免费注册，并提供最高 185 小时录音转写和最高 333 小时流式转写。这些是公布的额度上限，不代表每种配置都能获得相同时数。免费流式方案允许每分钟新建 5 条连接；按量付费从每分钟新建 100 个会话起，并可自动扩容。这些数字指连接启动速率，不是同时通话数量。如果上线时集中开启大量会话，可能尚未耗尽额度，就先撞上免费方案的速率限制。

哪些限制可能改变选型结果？

AssemblyAI 的模型和功能差异较多，成功转写一段样本只是评估的起点。以下约束最可能改变实现方案或服务商选择。

整个工作流的语言覆盖并不一致。 录音回退模型可以扩大转写覆盖，但专业附加功能、实时模型或语音生成可能只支持更少语言。应为完整流程写出要求，例如“将韩语音频转成标明说话人的韩语会议纪要”，再逐环节验证。

实时说话人归属需要可修订的状态。 流式说话人文档介绍了临时标签、PENDING 回应和后续修正。其中实验性的说话人置信度字段也不是经过校准的概率，不能据此承诺行动项负责人一定正确。应将不确定的片段交给人工复核，并在生成最终记录前应用修订。

录音预览版有明确的弱项。 AssemblyAI 的模型选择文档提醒，Universal-3.6 Pro Preview 在部分欧洲语言中可能生成较少标点，处理复杂语码切换音频时可能准确率下降。这些是厂商披露的限制，并非本评估的测试结果。应将其与稳定版 Universal-3.5 Pro 分开验证，不能仅凭版本号更高就作决定。

数据处理需要落实到账户配置。 AssemblyAI 的数据保留与模型训练文档区分了生产环境数据保留与模型训练用途。能否用于训练取决于适用合同和控制选项；文档中的流式零保留选项以退出训练为前提，而且仍会保留运营元数据。发送客户录音前，应检查选定账户与处理区域。

语音分析并不能替你完成整个应用。 你仍需处理任务失败、修订纪要、将记录关联到客户，并决定哪些提取出的行动需要审核。Gateway 工具调用可以支持集成，但权限与操作逻辑由应用提供。即使转写账单很低，这部分工程投入也应计入采购决策。

选型结论：从产品需要的最终输出倒推

对于要把对话变成归属清晰、结构化信息的产品，AssemblyAI 值得列入候选。录音会议纪要可以从 Universal-3.5 Pro 入手，只添加界面真正使用的分析功能；如果更在意成本或更广的语言覆盖，再对比 Universal-2。新建实时助手时，则应将 Universal-3.6 Pro Realtime 与适合的低价流式模型及 Deepgram Flux 一起评估。

**决策原则：**如果 AssemblyAI 的具体模型、语言路线和说话人输出约定满足产品要求，而且从转写到洞察的功能能减少原本需要自行开发的集成工作，就选择它。如果其他方案在必需语言、轮次行为或输出格式上更合适，就选择其他方案。不要只因一段干净的演示听起来令人信服，就更换服务商。

下周可以准备一小组已获准使用的录音，包含普通对话、生僻姓名、打断、简短回应，以及用户实际会出现的语言切换。比较输出前，先写清应用需要哪些字段。既检查转写文本，也检查最终带说话人归属的纪要，再按选定附加功能和实际连接时长估算用量。公开演示平台适合作为起点；最终验收仍应以生产配置为准。

常见问题

AssemblyAI API key 怎么获取和使用？

注册账户后，从控制台获取密钥。长期使用的密钥应保存在服务端。录音转写 API 将密钥放在 authorization 请求头中，不加 Bearer 前缀；应遵循具体 API 的认证说明，不要假设所有端点都相同。

AssemblyAI Playground 能做什么？

公开演示平台支持选择示例音频、上传文件或提供 URL，然后配置模型上下文和受支持的分析功能，方便接入前了解产品。应使用有代表性的音频，并评估计划部署的同一套配置。

AssemblyAI API 应该选哪一种？

已结束、可异步完成的任务使用录音 API；持续音频和实时响应使用流式 API；需要在一次请求与响应中拿到完整转写，则使用 Sync。如果应用需要可直接使用的书面文本，Dictation 会额外提供编辑后的输出。

阅读 AssemblyAI 文档该从哪里开始？

先看对应处理模式的当前模型选择页面，再看配套快速入门。复制当前 API 标识符，检查语言与功能支持，并在配置中固定模型。旧教程里的产品名可能指向另一代模型。

使用 AI Business Workflow Audit Checklist（AI 业务工作流审查清单），梳理音频来源、所需输出及应用之间的交接环节。领取清单。