你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
批量听录用于在存储中听录大量音频数据。 语音转文本 REST API 和语音 CLI 都支持批量听录。
应为每个请求提供多个文件，或指向包含要听录的音频文件的 Azure Blob 存储容器。 批量听录服务可以处理大量的已提交听录内容。 该服务会以并发方式听录文件，这样可减少周转时间。
它是如何工作的？
使用批处理听录，提交音频数据，然后异步检索听录结果。 该服务听录音频数据，并将结果存储在存储容器中。 然后就可以从存储容器检索结果。
提示
对于低代码或无代码解决方案，可以在 Power Platform 应用程序（如 Power Automate、Power Apps 和逻辑应用）中使用批量语音转文本连接器。 请参阅 Power Automate 批量听录指南以开始使用。
要使用批量听录 REST API：
- 找到批量听录的音频文件 - 可以通过公共 URI 或共享访问签名 (SAS) URI 上传自己的数据或使用现有音频文件。
- 创建批处理听录 - 使用音频文件、听录语言和听录模型等参数提交听录作业。
- 获取批处理听录结果 - 检查听录状态并异步检索听录结果。
重要
批量听录作业是按“尽力而为”的原则安排的。 在高峰时段，听录作业开始处理可能需要长达 30 分钟或更长时间。 请在此部分了解如何查看批量听录作业的当前状态。
提高性能的最佳做法
请求大小：批量听录是异步的，每个区域中一次处理一个请求。 以更高的速率提交作业不会加快处理速度。 例如，每分钟发送 600 或 6,000 个请求不会影响吞吐量。 建议在单个 Transcription_Create 请求中提交大约 1000 个文件。 这样，总发送的请求就更少了。
时间分布：随时间推移分发请求：在数小时内提交请求，而不是在几分钟内全部发送请求。 后端处理由于固定带宽而保持稳定的性能级别，因此发送请求的速度过快不会提高性能。
作业监视： 监视作业状态时，不需要每隔几秒钟轮询一次。 如果提交多个作业，则最初只处理第一个作业;后续作业将等到第一个作业完成。 轮询所有作业会频繁增加系统负载，而不会带来好处。 每 10 分钟检查一次状态就足够了，不建议每分钟多次轮询。
- 由于顺序处理，你可以通过仅检查文件子集来获取作业状态：检查前 100 个文件，如果这些文件未完成，则以后的批处理可能也不会相互竞争。 建议在再次检查之前至少等待一分钟（理想情况下为 5 分钟）。
避免 API 调用的高峰流量：ListFilesUpdateAPI Get 调用的行为与调用类似Create，应在高峰流量期间最小化。
负载均衡：若要优化大规模批量听录的吞吐量，请考虑将作业分配到多个受支持的 Azure 区域。 如果数据和符合性要求允许多区域使用，此方法可以帮助平衡负载并减少总体处理时间。 查看 区域可用性 ，并确保可从计划使用的每个区域访问存储和资源。