Microsoft 於10 月 1 日宣布推出 MAI-Transcribe-2-Streaming。使用者說話時，模型會接收音訊，並在產生最終逐字稿前持續傳回變動中的文字。對想在語音應用程式加入即時字幕或語音輸入的開發者來說，關鍵在於如何將這些更新傳送至應用程式，以及何時可將文字視為定稿。

本文根據文件，為評估公開預覽版的開發者說明如何整合模型。目標是判斷是否值得製作原型，並找出應用程式為顯示即時文字及儲存最終文字所需的用戶端工作。Microsoft 提供介面說明和範例程式碼；BIG CHANGE 未部署模型、執行範例，也未測量準確率或延遲。

重大變革

  • Microsoft 推出一款串流模型，會隨音訊傳入而傳回暫定文字，之後再確認各段轉錄內容。另一條 MAI-Transcribe-2 檔案轉錄流程則處理已錄製音訊，並提供另一組文件列出的選項。
  • 使用 Realtime API 的應用程式必須傳送格式正確的音訊、處理暫定文字尾端的修訂，並決定何時要求完整逐字稿。這些選擇會影響使用者看到的內容，以及下游應用程式邏輯何時能依賴最終文字。
  • 串流模型目前處於公開預覽階段，不提供服務等級協定（SLA），且 Microsoft 不建議用於正式環境工作負載。Microsoft 公布的速度和準確率數據屬於廠商聲明及基準測試結果，並非本文實測。

選擇連線方式

Microsoft 的Foundry模型目錄列出MAI-Transcribe-2-Streaming，版本為2026-08-06，並將其列為支援音訊輸入和文字輸出的預覽模型。Microsoft 的10 月 1 日概述介紹兩種整合方式：採用類似 OpenAI Realtime WebSocket 協定的 Realtime API，或 Azure Speech SDK。兩種方式都會傳回中間辨識結果和最終辨識結果。SDK 管理連線和音訊串流；Realtime 方式則直接將事件提供給應用程式。

使用Realtime API時，Microsoft 要求具備 Azure 訂用帳戶、位於支援區域的 Microsoft Foundry 資源，以及串流模型部署。連線至wss://{your_resource_name}.services.ai.azure.com/mai/v1/realtime?intent=transcription，並使用 Microsoft Entra 持有人權杖或 API 金鑰驗證身分。文件建議採用 Entra 驗證。在session.created之後，發送session.update，指定部署名稱並設定輸入格式。附加第一段音訊後，即使只送出一個音訊片段，也不能再變更此設定。

文件規定的輸入為原始、有號、小端序、單聲道 PCM16 音訊，取樣率為 16 或 24 kHz，並以 Base64 音訊區塊傳送至input_audio_buffer.append訊息。這是沒有 WAV 標頭的 PCM 資料。Microsoft 建議使用較小的音訊區塊，例如 10 至 20 毫秒，以降低延遲；也指出較大的區塊能減少網路負擔。Microsoft 的 Python 範例每 100 毫秒讀取一次麥克風音訊。文件建議的小區塊與範例採用的區塊大小不同；這是兩種選擇，並非 BIG CHANGE 實測結果。

Microsoft 的Speech SDK方式要求使用 Azure Speech SDK v1.52.0、Azure 訂用帳戶，以及 Foundry 或 Speech 資源。Microsoft 的 Python 範例將speech_config.model設為MAI-Transcribe-2-Streaming，通過推送串流提供16 kHz、16位、單聲道音頻，並監聽recognizing和recognized事件。示例使用一個已有的audio.pcm檔案示範推送串流；實際應用程式必須提供自己的音訊來源。以上是文件列出的介面和預期事件類型，並非本刊對個別帳戶相容性的測試。

將暫定文字與已確認文字分開處理

Realtime 事件的語意會影響即時介面。一個conversation.item.input_audio_transcription.delta事件包含剛定稿的文字，用戶端應用程式應在不改動空格的情況下，將內容附加至已確認文字緩衝區。一個intermediate事件包含目前暫定文字尾端的完整內容；每次收到新的尾端內容，都要取代先前的尾端。介面可以顯示已確認文字緩衝區加上目前尾端。如果將每次中間事件都另存為一行，模型修訂時便會重複顯示文字。

客戶端會發送input_audio_buffer.commit，例如偵測到停頓或錄音結束時。Microsoft 表示，這會要求盡快產生最終逐字稿；input_audio_buffer.committed會確認已送出，隨後conversation.item.input_audio_transcription.completed會傳回自上次送出後該段音訊的完整最終文字。Realtime指南指出，此模型的工作階段設定不支援伺服器端回合偵測和自動送出。因此，想自動完成各語音片段的應用程式，必須自行決定停頓或回合邊界。文件說明事件規則，但沒有規定適用所有情境的邊界偵測器。

Microsoft 指南將每個 Realtime 工作階段限制為一小時。指南也指出，單一音訊附加動作不會收到專屬確認回應，之後可能出現零個或多個轉錄事件。評估原型時，開發者應區分音訊訊息已送達與最終文字已產生，並決定應用程式如何處理連線中斷。Microsoft 公開指南的 Python 範例包含麥克風佇列和錯誤處理程式碼；BIG CHANGE 未執行該範例來驗證實際故障狀況。

存取、區域與價格

Microsoft 表示，該模型可於全球使用，Azure 會將請求路由至提供服務的區域。10 月 1 日發布的兩份整合指南列出的可用區域不同：Realtime 指南列出瑞典中部、美國中部和印度南部；Speech SDK 指南則列出瑞典中部、美國中部和東南亞。兩份指南都將美國東部 2 列為即將推出。請依預定整合方式確認目前可用的部署和區域；兩個頁面列出的區域並不完全一致。全球可用不代表處理一定在特定地點進行。

公告給出的優惠價格為每小時音訊 0.54 美元，促銷至 2026 年底。換算後相當於每 1,000 分鐘音訊 9 美元；應用程式使用的其他服務或基礎設施費用另計。Microsoft 在相關指南中分別連結至 Foundry Models 和 Speech 服務的定價頁面。查閱資料沒有說明促銷期結束後的費率或實際帳單金額，因此規劃部署預算時應查詢當時價格。

Microsoft 表示，串流模型支援 60 種語言，並會持續自動偵測語言。Microsoft 也稱，收到音訊後不到 100 毫秒便會出現第一段暫定結果，並引用 Artificial Analysis 的說法，稱模型在準確率排名中居首。Artificial Analysis的串流基準測試Artificial Analysis 的串流基準測試以約 8 小時、按權重組合的資料集測量詞錯誤率，並以偵測到的語音結束時間計算部分和最終結果的延遲。這是依特定音訊和計時規則進行的基準測試，不能保證個別應用程式在 100 毫秒內顯示的詞語正確。我們在為本文檢索到的公開基準測試資料中，未找到該模型的具體結果列，因此無法獨立核實 Microsoft 所稱的確切排名。

另一份Azure Speech中的MAI-Transcribe-2指南說明檔案輸入，以及說話者分離、詞級時間戳記、關鍵詞偏置和清理稿／逐字稿風格等選項。不要假設 MAI-Transcribe-2-Streaming 也支援這些控制項：串流整合指南並未列出這些功能。若產品需要這類輸出，請評估檔案轉錄模型，或先查閱最新文件並實際測試串流版本是否支援，再決定如何建置。

資料來源與延伸閱讀

  • 微軟AI公告，2026 年 10 月 1 日：產品發布、語言、速度及優惠價格聲明。正文已將微軟自己的準確率和內部速度聲明標明為廠商說法。
  • Microsoft Foundry模型目錄，於10月2日查閱：模型版本、預覽階段、輸入和輸出類型；目錄信息不是性能測試。
  • 串流模型概述、Realtime API指南和Speech SDK指南，更新於10 月 1 日：兩種有文檔說明的集成方式、預覽條款、事件行為、示例和區域表。BIG CHANGE沒有運行這些示例。
  • Azure Speech中的MAI-Transcribe-2，於10月2日查閱：單獨的檔案轉錄流程及其文檔所列控制項。該功能列表不能證明串流模型也支持這些功能。
  • Artificial Analysis串流基準測試和方法說明，於10月2日查閱：獨立基準測試的設計和計時定義。檢索到的公開文字未列出該模型的具體結果，因此無法獨立確認其排名。