用多模态 API 做视频转写

如果你需要纯粹的语音转文字，用音频优先的 API。如果屏幕上的文字、人脸或幻灯片会改变含义，用多模态 API。如果你需要在视频库中做搜索，用一套索引栈。

我会把这个市场分成三大类：

• 音频优先转写： APIMart、OpenAI Whisper、AssemblyAI

• 视频感知的多模态分析： Google Gemini、OpenAI + 帧分析

• 归档与搜索工作流： AWS 栈、Azure Video Indexer

这种划分之所以重要，是因为取舍非常鲜明：

• OpenAI 和 APIMart 有 25 MB 的同步上限，所以长文件需要分块

• Gemini 在默认设置下可以在一个上下文窗口里处理最多 1 小时的视频

• AWS Transcribe 支持每个作业最多 4 小时

• AssemblyAI 单个文件最多可达 10 小时，并报告 0.008x 的 RTF

• Azure Video Indexer 把转录、OCR、人脸和场景数据整合到一条时间线上

• 定价从 Whisper 的每分钟约 $0.006 到高级 Azure 视频索引的每分钟 $0.15 不等

所以最佳选择不只关乎转录准确率。它关乎_你摄入的是什么_、媒体有多长、画面是否重要，以及_你想自己承担多少流程工作_。

Google Vertex AI Tutorial #5 - Multimodal Tutorial: Image, Video & Audio Analysis with Gemini 2.0

快速对比

我的结论很简单：挑选与你工作流相匹配的最简单的方案。 需要规模化时用纯音频工具，画面重要时用多模态工具，日后需要视频搜索时用索引平台。

1. APIMart

APIMart 给你一个统一的 API 网关来做视频和音频转写，其中 Whisper-1 通过一个 OpenAI 兼容的端点提供。当视频来自不同地方、而你想要一条统一的转写流程而不是拼凑起来的方案时，这尤其方便。

模态覆盖

APIMart 支持 YouTube、TikTok、Instagram 以及直接的媒体 URL ^[7]。它也接受常见的音频和视频格式，包括 mp3、mp4、mpeg、mpga、m4a、wav 和 webm ^[8]。

你可以以 json、text、srt、vtt 和 verbose_json 返回转录。如果你需要更多细节，verbose_json 会包含时间戳、片段和元数据。这让它很适合字幕对齐和后续分析。

集成方式

APIMart 兼容 OpenAI SDK。实际操作中，这意味着你可以把 base_url 切换到 https://api.apimart.ai/v1，并保持同样的鉴权模式。

对于较大的作业，APIMart 还支持异步请求，返回一个 task_id 用于轮询或 webhook 回调。此外还有一个 Batch API，面向非紧急工作，最长 24 小时交付，token 成本更低。

转写性能

Whisper-1 支持 99 种以上的语言，采用 ISO-639-1 语言代码 ^[7][8]。如果你指定 language，就能同时提升速度和准确率。

同步请求上限为 25 MB，所以更长的视频需要分块。APIMart 通过多供应商路由和自动故障切换，以 99.9% 的正常运行时间 SLA 作为支撑 ^[9]。通过 AgentX Video Transcript 模型进行的视频转写，起价为每份转录 $0.39 ^[7]。

简单说，APIMart 是为快速摄入、结构化输出和极少的 SDK 改动而打造的。

2. Google Gemini API

Google Gemini 的工作方式和纯音频转写工具略有不同。它不是单独去听音轨，而是在一个上下文窗口里同时看视频和音频。当屏幕给正在讲述的内容增添了含义时，这一点就很重要 ^[10][13]。

模态覆盖

Gemini 天生就是多模态的，因此它可以在单个提示中处理视频、音频、图像和文本 ^[10][13]。对于视频，它以 1 FPS 采样帧，同时处理音频 ^[11]。这种并排处理可以帮助 Gemini 结合声音和视觉信号（如名牌或人脸检测）来指派说话人 ^[12][13]。它还能减少事先猜测说话人或语言的需要 ^[13]。

集成方式

如果你在 Google Cloud 内工作，可以通过 Vertex AI 使用 Gemini；如果你想用一个 API key 快速做原型，可以通过 Google AI Studio ^[12][13]。对于文件摄入，Gemini 会根据文件大小给你几条路径 ^[11]。

这些选项之所以重要，是因为当你需要在单个请求中处理长时、媒体密集的输入时，Gemini 会大放异彩。把 response_mime_type 设为 application/json，然后使用一个 schema 或一个 Timestamp | Speaker | Text 提示，就能得到更干净的转录 ^[10][12][13]。说白了，当转录质量取决于屏幕上出现了什么、而不只是麦克风收到了什么时，Gemini 处于最佳状态。

可扩展性限制

100 万 token 的上下文窗口让 Gemini 能够在默认分辨率下处理最多 1 小时的视频，或在低分辨率下处理最多 3 小时 ^[11][10]。Gemini 2.5 及更新的模型支持每个请求最多 10 个视频，而早期版本只允许一个 ^[11]。如果你要对同一个长视频反复查询，上下文缓存可以降低延迟和输入 token 成本 ^[10]。

转写性能

在默认分辨率下，token 用量约为每秒 300 个 token。拆开来大约是帧占 258 个 token，音频占 32 个 ^[11]。如果你切换到低分辨率，这会降到大约每秒 100 个 token ^[11]。

作为一个粗略的定价参考，一个约 7 个文件共 4 小时的工作负载，用 Flash-Lite 和 Flash 大约花费 $1.00 ^[12]。有一点要注意：快速运动的场景在 1 FPS 下可能损失细节。如果那些视觉时刻很重要，在把高速运动片段送到 API 之前放慢它们，能帮你拿到更精细的细节 ^[11]。

当任务主要是音频优先的转写时，取舍开始向更简单的摄入和更低的处理开销倾斜。

3. Amazon Transcribe 与 AWS 视频分析栈

Gemini 用一个多模态提示，AWS 则把任务拆分到多个服务层。视频转写通过并行服务而不是一个一体化流程来运行。这给了你更多控制，但也意味着有更多需要接线和管理的活动部件。

模态覆盖

AWS 把视频当作一个多信号问题，因为单靠转写会漏掉视觉和基于时间的上下文。这套栈处理视觉、音频、语音和时序信号 ^[15]。像 Nova 和 Titan 这样的 Amazon Bedrock 模型随后可以把帧转成可搜索的文本 ^[14][15]。

这种搭建让 AWS 更适合那些需要对语音、视觉和时序分别处理的流程。

集成方式

一种常见的搭建用 S3、EventBridge 和 Step Functions 来并行触发转写、视觉分析和元数据提取，输出存储在 DynamoDB 中 ^[22][17]。为每个阶段使用范围收窄的 IAM 角色也很有帮助。

在搜索方面，AWS 跨语音、音频和视觉嵌入组合了关键词检索和向量检索 ^[15][16]。

用大白话说，取舍是这样的：每多一条分支就给你更紧的控制，但它也把编排成本推高。

可扩展性限制

Amazon Transcribe 支持最大 2 GB 的文件，每个作业最长 4 小时的视频 ^[6][20]。对于更大的工作负载，增大 Lambda 的临时存储和内存，并用 SQS 来平滑并发 ^[19][21]。

转写性能

AWS 能在 5 分钟以内处理约 1 小时的视频，Transcribe 起价为每分钟 $0.024，首词时间约为 500–800 ms ^[6][18]。

实践中，AWS 更偏向结构化的流程，而不是一步到位的转写。

4. Azure AI Speech 与 Video Indexer

Azure AI Video Indexer 采取了一种多模态的方法。它把 Azure AI Speech、Vision 和 Translator 汇集起来，从视频和音频中提取洞察。在一趟处理中，Video Indexer 跨音频和视频运行 30 多个模型，然后返回一条包含转录、OCR、人脸和标签的时间线 ^[24][27]。

模态覆盖

该平台同时跨音频、视频和结构化元数据工作。它支持 50 多种语言的语音转文字、自动语言检测、每个作业最多检测 10 种语言，以及最多为 16 个说话人做说话人标注 ^[24][26]。

视频帧在转录之上添加了更多上下文。你会得到 OCR、场景、镜头、关键帧、物体标签和人脸分组。这多出来的一层有助于搜索、剪辑和下游文本工作流，因为转录不再是孤零零地存在了 ^[23][24][26]。如果视觉一侧会改变语音该如何解读，就使用音频-视频预设。

那条统一的时间线让 Azure 相比简单的一次性转录，更适合可搜索的视频档案。

对于下游 AI 工作流，Prompt-Ready API 会把视频转成片段级别的文本，其中内嵌了 OCR、标签和说话人数据。这让它可以直接用于摘要和搜索工作流 ^[28][29]。

集成方式

把源媒体存储在你的 Azure Storage 账户中。Video Indexer 把索引元数据保存在托管存储里，不额外收费。你可以把 retentionPeriod 设为 1 到 7 天，以自动删除源媒体和洞察 ^[26]。

对于搜索和分析，提取出的洞察可以被嵌入并存储到 Azure AI Search 中。这种搭建支持跨大型视频库的检索增强生成工作流 ^[29]。

可扩展性限制

试用账户在网站上提供 600 分钟免费索引，或通过 API 门户提供 2,400 分钟。如果你要进入生产，就需要一个付费的无限制 Azure 订阅 ^[27]。

如果数据驻留或低延迟很重要，Azure Arc 支持本地部署的处理 ^[24]。

转写性能

定价从标准音频的每分钟 $0.024 起，一直到高级视频索引的每分钟 $0.15 ^[30]。如果你想避开编码费用，选择 "No streaming" ^[26]。

当你提前设定源语言而不是依赖自动检测时，转写质量往往会更好 ^[25][26]。对于混合语言的文件，customLanguages 参数让你可以指定最多 10 种预期语言，而不是使用默认的 9 语言检测集 ^[25]。

对于那些想要直接访问模型、而不是用托管索引服务的团队来说，下一个选项从媒体编排转向了原始的多模态推理。

5. OpenAI 多模态 API

OpenAI 的多模态 API 和前面讲过的托管索引服务工作方式略有不同。你不是把视频原样送进去，而是先提取音频用于转写，并采样帧作为视觉上下文。这里最大的取舍是：你获得了灵活性，但也要承担那个预处理步骤。

模态覆盖

对于转写，你可以使用 Whisper（whisper-1）或基于 GPT-4o 的模型，如 gpt-4o-transcribe 和 gpt-4o-transcribe-diarize。说话人分离选项支持带说话人标签的转录，并且可以通过 known_speaker_references[] 使用最多四段简短的音频参考——每段 2 到 10 秒——把片段映射到具体的人 ^[31]。

在视觉一侧，GPT-5.4 分析提取出的图像帧，而不是实时视频流，所以需要预处理 ^[5][32]。支持的帧格式包括 base64 编码的 PNG、JPEG、GIF 和 WebP。

集成方式

这套搭建遵循两步流程：提取音频，通过 Audio API 转写它，并在视觉上下文重要时纳入采样帧。当你需要传入技术术语、缩写或先前上下文时，prompt 参数会有帮助 ^[31]。你还可以用 timestamp_granularities[] 获取词级时间戳和更紧的剪辑控制。

从那里出发，verbose_json 或 diarized_json 格式的转写输出可以喂给 GPT-5.4 做摘要或行动项提取 ^[1][31]。那种时间戳控制很有用，尤其是对剪辑和下游自动化，但它也意味着更多的编排工作。

可扩展性限制

对于长篇内容，主要的限制是 25 MB 的文件大小上限，大约是 30 分钟的音频 ^[31][33]。超过这个的都必须分块。

对于实时或准实时的用例，Realtime WebSocket API 提供 300–800 ms 的延迟，并内置降噪 ^[33]。问题在于会话长度：每个会话上限为 30 分钟，所以更长的流需要重连和拼接。

转写性能

Whisper 在英语转写上交付约 5.2% 的词错误率（WER），并支持 57 种以上的语言 ^[1][31]。Whisper 的定价从每分钟 $0.006 起。如果你在处理高流量的工作，gpt-4o-mini-transcribe 能削减开销，而多模态处理的成本可能比纯文本工作流高 2–7 倍 ^[1][5][31]。

简单说，这里的主要取舍是集成工作量和分块开销——尤其是一旦文件变长或会话跑过平台上限时。

6. AssemblyAI

对于那些帧分析不属于工作范围的长时、以语音为主的视频——不同于需要视觉上下文的多模态对话——AssemblyAI 把事情保持得很简单。它是一个音频优先的工具，从视频中抽取音频用于转写。它不会检视帧，所以相比任何依赖视觉上下文的东西，它更适合以语音为主的内容。

模态覆盖

AssemblyAI 通过音频优先的流程处理视频文件。它会自动从 MP4、MOV 或 WEBM 文件中提取音轨，并将其转换为 16 kHz 的未压缩音频以供处理 ^[35][38]。它的主要强项包括说话人分离、情感分析、PII 脱敏，以及 LeMUR 摘要 ^[36][39]。它还支持 99 种以上的语言，转写时可自动检测语言 ^[34][40]。

其输出面向说话人分离、脱敏和摘要工作流。所以如果转录质量和后处理比屏幕上正在发生的事更重要，这套搭建就很说得通。

集成方式

集成流程很直接。把本地文件上传到 /v2/upload，然后把返回的 URL 传给 /v2/transcript；如果你的文件已经在云上，你可以直接发送一个公开 URL ^[34][42]。Python 和 JavaScript SDK 会为你处理轮询，生产团队可以用 webhook 做完成回调 ^[41][37]。

响应以带词级元数据的 JSON 返回。该 API 还原生导出为 SRT、VTT 和纯 TXT ^[34]。

可扩展性限制

AssemblyAI 通过 transcript 端点允许最大 5 GB 的文件，直接上传则为 2.2 GB，最长时长为 10 小时 ^[38]。免费账户限制为 5 个并发作业。付费档从 200 个并发作业起，并可按需扩展到更高 ^[34][43]。

对于实时工作，流式会话从每分钟 100 个起，并在利用率达到 70% 时每次自动扩容 10% ^[40]。

转写性能

这正是 AssemblyAI 脱颖而出之处：规模化下的速度，尤其是对大文件和批量转写。该平台报告的实时因子（RTF）为 0.008x，这意味着一门 8 小时的视频课程可以在约 300 秒内处理完 ^[38]。

定价是模块化的。异步转写 Universal-2 为 $0.15/小时，Universal-3.5 Pro 为 $0.21/小时。诸如说话人分离（+$0.02/小时）和摘要（+$0.03/小时）之类的附加功能会另行计费 ^[40]。你可以直接上传原生视频文件，AssemblyAI 会在内部处理音频提取 ^[35][38]。

集成、规模与性能对比

这里最大的差异归结于工作流设计，而不是原始的转写准确率。每个平台解决问题的不同部分：原生多模态推理、分层的企业级流程，或音频优先的处理。所以主要的选择不只是"哪一个转录得最好？"而是视频如何进入 API、围绕它有多少编排，以及这套搭建在规模下撑得多好。

工作流架构是最清晰的分界线。 Google Gemini 是这里唯一能在单次调用中跨音频和视频进行推理的选项 ^[5][45]。OpenAI 视觉处理得不错，但视频转写仍然需要单独的音频处理 ^[5]。AssemblyAI 专注于音频，没有帧级别的分析。AWS 和 Azure 通过分层的服务栈处理视频，这给了团队更多控制，但也增加了编排工作。APIMart 位于这些路径之上，作为一个统一的编排层，给团队提供一个跨视频、图像和语言模型的 API 端点 ^[44]。

集成模式落在三种常见的搭建里。当延迟不如吞吐量和成本重要时，批量 REST 作业表现良好。存储 URI 流程，比如 AWS S3 和 Azure Blob，是大型档案的标准之选。WebSocket 流式适合实时字幕，但它也带来更多活动部件，尤其是围绕音频分块和连接处理。

性能差距会更明显地显现，当音频变得杂乱时。干净的单说话人文件通常是最容易的情况。一旦你面对嘈杂的录音、重叠的说话人或多语言内容，取舍就变得更明显。AWS Transcribe 把说话人识别上限设为 10 位参与者，而 AssemblyAI 支持最多 50 位 ^[46]。而在某些情况下，视觉上下文有助于理清仅靠音频无法完全分辨的语音 ^[6]。

各平台的优缺点

没有哪个平台在所有方面都胜出。正确的选择取决于你的搭建：你在摄入什么、其中有多少需要处理，以及转写之后需要发生什么。

这张表把前面的平台对比转化成一个更实用、可直接用于决策的视角。

APIMart 很适合多来源摄入，因为它通过一个 API 返回带时间戳的转录和元数据。取舍很简单：它作为一个托管的编排层运行，所以它不是为实时流式或纯音频文件作业而打造的。

Google Gemini 在视觉上下文改变了话语含义时脱颖而出。不过如果你在高流量地处理纯音频，它就成了一个效率较低的选项。

AssemblyAI 很适合合规密集型的音频工作流。它支持说话人分离、PII 脱敏、情感分析，并且比 Whisper Large-v3 少 30% 的幻觉 ^[3]。问题在于它仅支持音频，所以你得不到任何视觉上下文。

Azure AI Speech 和 Video Indexer 对受监管的企业级工作很说得通。它把语音、说话人分离、脱敏和视觉索引整合进一条可搜索的流程。另一方面，它需要更多编排，而且定价会随你使用的功能而变。

OpenAI 适合那种你还想要独立视觉分析的批量转写。但你需要额外的预处理，而且 Whisper API 有 25 MB 的文件限制 ^[6][1]。

用下面的矩阵把每个平台匹配到对你最要紧的约束：上下文、合规、规模或编排。

结论

高流量转写用音频优先的 API，视觉上下文重要时用多模态 API，需要可搜索的视频档案时用媒体索引平台。

选择通常归结于三道过滤：上下文、体量和编排。你需要视觉上下文吗？你要处理多少内容？以及你的团队现实中能支撑多少编排？把多个供应商串联起来会很快增加工程开销，尤其是在规模下。

如果你的团队想要更少的活动部件，一个统一的 API 能让这个决策更简单。如果你在构建视频流程并想削减集成复杂度，APIMart 通过一个 API 汇集了 500+ AI 模型——包括视频、图像和语言模型。

先给工作流分类：仅音频、视频感知，或索引。然后挑选那个契合你规模、成本和准确率需求的最简单选项。

常见问题

::: faq

我该如何在仅音频和多模态转写之间做选择？

当你处理的是原始音频、主要需要语音转文字时，选择仅音频转写。这包括诸如高速流式或 PII 脱敏之类的场景。

当你需要完整图景——视频、音频和视觉上下文一起——时，选择多模态转写。这可以包括屏幕上的文字、场景切换，或与语音同时发生的事件。

APIMart 通过给你一个 API 来访问不同模型，让这件事更简单。 :::

::: faq

视频上下文在什么时候能提升转录质量？

当模型使用原生多模态处理而不是仅音频的语音转文字时，视频上下文可以提升转录质量。

当一个模型既看视频_又_听音频时，它有更多可利用的上下文。这有助于它理清那些杂乱的部分，比如说话人识别、多个说话人之间来回的轮替，以及长段落的对话。当音频嘈杂或对话密集时，这一点更加重要。

APIMart 给团队提供一处地方，通过单个可扩展的 API 来访问这些多模态功能。 :::

::: faq

处理长视频文件最简单的方式是什么？

用一个像 APIMart 这样的统一 AI API 平台来让集成保持简单。你不用为不同的多模态模型接线独立的供应商和端点，而是可以通过单个端点发送请求。这缩短了搭建时间，也让你的技术栈更容易管理。

对于大文件，一个公开的视频 URL 往往是最简单的路径。它帮你避开文件大小限制，以及手动搬运大文件的麻烦。

如果内容是私有的，就改用 Files API。这让你可以上传并存储最大 2 GB 的文件，并在多个请求间复用它们，当你不想反复上传同一份资产时会很方便。 :::