什么是批量听录？

使用批量听录来转录存储中的大量音频数据。语音转文本 REST API 和语音 CLI 都支持批量听录。

应为每个请求提供多个文件，或指向包含要听录的音频文件的 Azure Blob 存储容器。批量听录服务可以处理大量的已提交听录内容。该服务会以并发方式听录文件，这样可减少周转时间。

它是如何工作的？

使用批处理听录，提交音频数据，然后异步检索听录结果。该服务听录音频数据，并将结果存储在存储容器中。然后就可以从存储容器检索结果。

要使用批量听录 REST API：

重要

该服务会尽力安排批量听录作业。在高峰时段，听录作业可能需要长达 30 分钟才能开始处理，最多需要 24 小时才能完成。请在此部分了解如何查看批量听录作业的当前状态。

请求大小：批量听录是异步的，每个区域一次处理一个请求。以更高的速率提交作业不会加快处理速度。例如，每分钟发送 600 或 6,000 个请求不会影响吞吐量。在单个 Transcription_Create 请求中提交大约 1,000 个文件，以总共发送更少的请求。

时间分布：随时间推移分配请求。在数小时内提交它们，而不是在几分钟内全部发送它们。后端处理由于固定带宽而保持稳定的性能级别，因此发送请求的速度过快不会提高性能。

作业监视：监视作业状态时，不需要每隔几秒钟轮询一次。如果提交多个作业，服务最初只处理第一个作业;后续作业等到第一个作业完成。轮询所有作业会频繁增加系统负载，而不会带来好处。建议每 10 分钟检查一次状态，不建议每分钟或更频繁地轮询。

由于顺序处理，可以通过仅检查文件子集来获取作业状态：检查前 100 个文件，如果这些文件未完成，则以后的批处理可能也不会完成。请至少等待一分钟（理想情况下为 5 分钟），然后再次检查。

避免 API 调用的高峰流量：在高峰流量期间最小化 ListFilesUpdateAPI 调用和 Get API 调用。这些调用的行为与 Create 调用类似。

负载均衡：若要优化大规模批量听录的吞吐量，请考虑将作业分配到多个受支持的 Azure 区域。如果数据和符合性要求允许多区域使用，此方法可以帮助平衡负载并减少总体处理时间。查看区域可用性，并确保可从计划使用的每个区域访问存储和资源。