使用批次轉錄來轉錄儲存中的大量音訊資料。 語音轉換文字 REST API 和語音 CLI 都支援批次謄寫。
您應該為每個要求提供多個檔案，或指向具有要謄寫之音訊檔案的 Azure Blob 儲存體容器。 批次轉譯服務可以處理大量的已提交轉譯。 服務會同時轉譯檔案，這會減少周轉時間。
如何運作？
使用批次謄寫時，您會提交音訊資料，然後以非同步方式擷取謄寫結果。 服務會謄寫音訊資料，並將結果儲存在儲存體容器中。 然後，您可以從儲存體容器擷取結果。
提示
若採用低程式碼或無程式碼解決方案，請使用Power Platform應用程式如Power Automate、Power Apps及Logic Apps中的 批次語音轉文字連接器 。 請參閱 Power Automate 批次謄寫指南以開始使用。
若要使用批次謄寫 REST API：
- 找出用於批次謄寫的音訊檔案 - 您可以上傳自己的資料，或透過公用 URI 或共用存取簽章 (SAS) URI 使用現有的音訊檔案。
- 建立批次謄寫 - 使用音訊檔案、謄寫語言和謄寫模型等參數提交謄寫作業。
- 取得批次謄寫結果 - 檢查謄寫狀態，並以非同步方式擷取謄寫結果。
重要
該服務在能力範圍內排程批次語音轉錄任務。 在尖峰時段，轉錄作業最多可能需要 30 分鐘才能開始處理，最多可能需要 24 小時才能完成。 請參閱本節中如何檢查批次轉譯作業的目前狀態。
改善效能的最佳實務
請求大小：批次轉錄為非同步，每個區域一次處理一個請求。 以較高速度提交工作並不會加快處理速度。 例如，每分鐘傳送 600 或 6,000 個請求不會影響輸送量。 一次申請提交約 1,000 個檔案 Transcription_Create ，整體可減少請求次數。
時間分配：將請求分散在時間內。 應該分散在數小時內提交，而不是在幾分鐘內全部提交。 後端處理因頻寬固定而維持穩定效能，因此過快傳送請求並不會提升效能。
作業監控： 監控作業狀態時，不需要每隔幾秒鐘輪詢一次。 如果你提交多個工作，服務最初只會處理第一個工作;後續的工作會等到第一個工作完成後才會進行。 輪詢所有作業通常會增加系統負載，而不會帶來好處。 每 10 分鐘檢查一次狀態就足夠了，且不建議每分鐘超過 1 次輪詢。
- 因為是順序處理，你只需檢查部分檔案就能取得工作狀態：檢查前100個檔案，如果還沒完成，後面的批次很可能也沒完成。 至少等一分鐘（理想是五分鐘）再檢查。
避免 API 呼叫的尖峰流量：在尖峰時段盡量減少 ListFiles、 Update和 Get API 呼叫。 這些通話的行為與通話 Create 相似。
負載平衡：若要優化大規模批次轉錄的輸送量，請考慮將作業分散到多個支援的 Azure 區域。 這種方法有助於平衡負載並縮短整體處理時間，前提是你的資料與合規要求允許多區域使用。 檢閱 區域可用性 ，並確定可從您計劃使用的每個區域存取您的儲存體和資源。