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