Muse Voice Transcribe：Meta 的串流語音轉文字模型解析

Muse Voice Transcribe 是 Meta 的串流語音轉文字模型。它透過 Meta Model API 提供服務，每小時音訊 $0.18，模型 ID 為 muse-voice-transcribe-1.0，且無論是串流即時音訊或交付已完成的錄音，價格都相同。它之所以值得一頁參考說明，而不只是一行價格查詢，關鍵在於其運作方式：超過二十位說話者的語者歸屬與語音結束偵測，都在辨識模型內部執行，而不是在串流結束後才附加的批次處理中進行。它僅支援語音轉文字——Meta 的開發者文件明確如此表示：它不會合成語音，也不提供語音對語音的對話 API。

這是讀者在搜尋模型本身名稱後所抵達的頁面，因此它的定位是對兩個問題給出穩定答案——這個模型是什麼，以及一小時音訊要多少錢——而不是一則公告。有一個日期應先記錄在案，因為這是關於模型的事實，而不是本頁存在的原因：Meta Superintelligence Labs 推出 Muse Voice Transcribe 的日期是2026-09-01，刊登於註明日期的公告文章推出 Muse Voice Transcribe——讀者仍可透過 Meta 的部落格索引找到這篇文章，儘管它已不再於自己的網址上提供內容。以下所有內容均於 2026-09-29 在 Meta 自家頁面上讀取，主要是模型頁面，以及 API 的語音轉文字與總覽文件。若 Meta 未公布數字，本頁會如實說明，而不會拿替代指標湊數。

以 Meta 的術語來說，這是什麼

Meta 自家的文件開門見山地說明：「Muse Voice Transcribe 是 Meta 在 Meta Model API 上的語音轉文字模型。可轉錄即時音訊或既有錄音，並具備語句輪替偵測、講者標籤與詞彙偏置。」總覽頁則把同樣的內容濃縮成一句話——串流講者分軌、原生端點偵測與語音活動偵測、情境與關鍵詞偏置，以及 25 種經過評估且支援語碼轉換的語言。因此，輸出是單一逐字稿串流，同時帶有三種標記：文字內容、說話者是誰，以及這句話是否已結束。而這正是目前多數正式環境的技術堆疊得靠辨識器，加上獨立的語音活動偵測器，再加上獨立的講者分軌模型拼湊出來的組合，而每個元件都有自己的延遲預算。

Meta 的模型頁面將此定調為「具競爭力的延遲，以及可為 20 位以上講者提供即時歸屬的串流轉錄準確度」，而開發者文件則將輸出欄位描述為「帶有逐輪時間資訊與可選講者標籤的轉錄文字」。由此可得出兩件事，而這兩件事都比這個定調更重要：

• 這是一個音訊輸入、文字輸出的模型。它既不是文字輸入，也不是文字輸出，而且 Meta 明確表示它不是語音生成器。

• 它首先是一個串流模型。即時路徑並非檔案路徑的包裝；它是一個具有自身事件、模式與限制的 WebSocket 工作階段，如下所述。

一小時的音訊成本是多少

Meta 的 Muse Voice Transcribe 模型頁面將價格標示為「以單一模型建構，每小時 $0.18」，而其規格表列出 muse-voice-transcribe-1.0 為每小時 $0.18 的音訊，以及每 1,000 分鐘 $3.00。這兩者是同一費率的兩種單位表述，且兩者都印在 Meta 自家頁面上（於 2026-09-29 查閱時所見）。開發者文件以第三種方式說明相同費率：「定價為每小時 $0.18 的音訊處理費用。」本頁沒有任何數字是沿用自 Meta 定價頁面，因為沒有可讀取的 Meta 定價頁面可供閱讀：文件將該費率連結到一個「定價與速率限制」頁面，而該頁面回應 此頁面無法提供（於 2026-09-29 查閱時），因此模型頁面是該費率的正式記錄來源，也是此處唯一採用的來源。

計費細節位於開發人員文件中，在您評估工作負載規模之前值得先了解：

• 串流與非串流的費用相同。即時端點不會有額外費用。

• 零資料保留處理的定價與 Standard 方案相同，根據文件說明——這並非加收費用項目。

• 計費會無條件捨去到整秒，因此兩秒的回合會以兩秒而非三秒計費。

• 在產生逐字稿之前發生的失敗不會計費，429 速率限制回應也不計費。

• 免費額度存在於平台層級，而非模型層級。Meta 的語音轉文字文件在定價段落的最後寫著：「平台免費方案額度適用。」這是這些頁面上唯一提及「免費」的字眼，而它指向的是一套平台額度機制，而非承諾提供免費的轉錄額度，且文中並未列出任何數字、期限或適用資格規則。應把它理解為可能折抵帳單的額度，而不是該模型的免費方案。Meta 面向消費者、稱其個人代理「對人們多數需求皆免費」的說法，是關於 Muse 應用程式的另一句獨立陳述，並不延伸適用於 Model API。

舉個實例，因為每小時的價格很難有感：一段兩小時的錄音訪談，轉錄費用是 $0.36。一千小時的通話音訊——大約是中型客服中心的每月處理量——則是 $180。在那樣的規模下，費率就是全部的論據，而費率也是唯一可能在你腳下變動的東西：Meta 的頁面是這方面的權威，如果那裡的數字變了，這裡也會跟著變。

串流介面，逐一端點

This is the part a reference page owes a reader that a launch write-up cannot carry, so here it is in the order you meet it. Base URL for Model API is https://api.meta.ai/v1 with a Bearer token, and Muse Voice Transcribe adds two endpoints on top of it.

• 即時音訊 — wss://api.meta.ai/v1/asr/realtime。傳輸方式是 WebSocket，而驗證細節是個陷阱：你是在握手訊框中進行驗證，而 Authorization 標頭會被忽略。握手訊框必須是第一個 JSON 文字訊框，且必須在 10 秒內抵達。工作階段最長可持續 60 分鐘，新的 WebSocket 會建立新的工作階段，而且沒有續傳權杖。

• 錄音 — POST https://api.meta.ai/v1/asr/transcribe。多部分上傳，而這個確實會使用Authorization 標頭進行驗證。輸入範圍很窄：僅限 16 或 24 kHz 的單聲道 16 位元 PCM WAV。每個主體上限為 32 MB，且每次請求最多 10 分鐘的音訊。

在即時工作階段中，三種模式會改變你收到的內容。 PUSH_TO_TALK是預設模式，進行單回合轉錄。 ENDPOINTING提供由模型偵測的回合邊界，每個偵測到的語音片段為一個回合，並發出 speechStart、重複的 transcript、speechEnd和 speechComplete事件——但要注意，speechEnd並不是轉錄文字。 DIARIZATION加入自動講者偵測與歸屬，發出 speaker事件，並帶有如 A和 B等標籤。部分轉錄結果有兩種形式：累積式，每個部分結果會取代前一個；或是差分（delta）形式。

同一份文件裡的兩個操作細節很容易被忽略，而等到在生產環境中才發現，代價卻十分高昂：

• 語者分離標記的是可能的新講者，而非乾淨的語音端點，且 Meta 表示它並非為低延遲、語音命令用途調校。請將這些標籤視為工作階段範圍的識別碼——A在某個工作階段中與A在下一個工作階段中並非同一人。

• 回合可能重疊，因此每個回合的狀態應以回合識別碼為鍵，而非以到達順序為鍵。

已公布的每位租用戶上限為 128 個並行串流，以及每小時 16,000 個串流。

模型內部運行的是什麼，以及它取代了什麼

Meta 的模型頁面提出的是關於架構、而非關於分數的具體主張：「20 位說話者的語者歸屬與語音結束都在辨識模型內部完成」——並明確將其與音訊串流結束時的批次處理形成對比。實際上的差別在於，不需要等待第二個階段。說話者與發言輪次會和字詞一樣在串流中送達，因此語音代理或即時字幕介面無需經過後處理環節，就能取得完整的輪次與身分。

Meta 記載為{{1}}存在{{/1}}於模型中的其他能力：

• 原生端點偵測與語音活動偵測，因此你不必在 API 前面自行執行 VAD。用文件中的說法，你不必自行執行語音活動偵測，就能為每段發話取得一份完整的轉錄稿，而偵測到語音結束並不會結束工作階段。

• 情境與關鍵詞偏置，無需微調。Meta 的模型頁面描述準確度「透過情境與關鍵詞偏置維持，無需微調」，這正是讓串流 ASR 能在領域詞彙上堪用——藥物名稱、股票代號、產品 SKU——而非只達到一般語言平均水準的關鍵功能。文件對其限制說得很明確：關鍵詞會偏置辨識結果，但不保證拼寫完全正確，而且關鍵詞與語言偏置都會在工作階段開始時固定下來。

• 25 種已評估且支援語碼轉換的語言。文件列出如下：阿拉伯語、孟加拉語、荷蘭語、英語、法語、德語、希伯來語、印地語、印尼語、義大利語、日語、卡納達語、韓語、馬來語、華語（普通話）、馬拉地語、波蘭語、葡萄牙語、西班牙語、他加祿語、坦米爾語、泰盧固語、泰語、土耳其語和越南語。語碼轉換——不必事先得知接下來會出現哪種語言，就能在句中與話語中途切換——是單一語言辨識器在結構上無法提供的能力。有一點值得留意：語言偏置是一份語言清單，而不是自由形式的上下文，而且它不會強制模型使用這些語言。

那篇註明日期的公告文章更進一步指出：該模型是以 70 多種語言訓練而成，其中 25 種「經過廣泛驗證」——這是由廠商回報的，而這份 25 種已驗證清單是 Meta 願意背書的子集。規劃時應以此涵蓋範圍為依據，而不是那 70 種。

文件記載的限制

參考頁面的優劣，全看它印出了哪些限制條件，而 Meta 印出了好幾項。

• 回合層級時間戳，而非詞層級。模型頁面和文件都明白寫著：「它會回傳回合層級時間戳，但不會回傳詞層級時間戳。」回合會帶有以毫秒為單位的開始與結束時間。如果你的產品需要逐詞點擊跳轉——卡拉 OK 式醒目提示、逐詞信心度路由、強制對齊——那這就是錯誤的模型，再怎麼精心設計提示詞也改變不了這一點。

• 沒有信心分數，沒有聲音事件偵測，沒有情緒偵測，沒有逐字稿重新格式化。Meta 將這四項全列為無法使用。你只會得到字詞、發言輪次、時間資訊和說話者標籤，完全不會知道模型有多確定。

• 沒有語音合成，也沒有語音轉語音的對話 API。它僅支援單一方向。

• 檔案路徑支援的音訊格式很有限。單聲道 16 位元 PCM WAV，16 或 24 kHz。其他任何格式都必須在上傳前先轉換。

開放權重，以及 Muse Glimmer 的混淆

Muse Voice Transcribe 是專有產品，透過 API 提供服務——它並非開放權重的發布版本，而 Meta 的文件也從未如此聲稱。這一點很重要，因為讀者會把 Muse 家族的開放權重路徑套到錯誤的名稱上。Muse Glimmer才是那條路徑：Meta 的文件將它描述為一款從 Muse Spark 蒸餾而來的開放權重多模態模型，以寬鬆的 Apache 2.0 授權條款發布，你可以透過 vLLM、SGLang、llama.cpp 或 ExecuTorch 等執行環境，下載並在自己的硬體上執行。Muse Voice Transcribe 則與 Muse Spark、Muse Image 和 SAM 一同列於同一頁面，屬於你要呼叫而非下載的模型。

所以：Muse Voice Transcribe 沒有權重，沒有自架選項，也沒有稽核或微調它的途徑。如果某個頁面說法不同，那它就是把它與 Muse Glimmer 混為一談了。當一個模型的權重未公開時，服務平台就是全貌——而這正是下一節要談的內容。

用戶端如何連線到它

Meta 的 Model API 設計成可直接放進你現有的用戶端。供應商在 API 總覽頁面上宣稱，Model API「可與 OpenAI 相容及 Anthropic 相容的用戶端函式庫，以及與 OpenAI 相容的代理 CLI 直接替換相容。設定你用戶端的基底 URL，加入你的金鑰，其餘程式碼維持不變。」就 Model API 整體而言，提供三種請求形式——Responses API、Chat Completions API 和 Messages API——因此既有的整合通常有對應介面，無需重寫。關於範圍有一點需注意：那句相容性說明與這三種形式是 Model API 整體的能力，並非印在 Muse Voice Transcribe 自身模型頁面上的文字。該模型頁面自己的快速入門範圍較窄——它只說你「將現有的 OpenAI 相容用戶端指向 Meta Model API」，並說你將在五分鐘內完成第一個可運作的請求。

在參考頁面上，有個值得點出的誠實缺口：Meta 針對此模型的文件並未為 Muse Voice Transcribe 指名任何官方用戶端程式庫，而其「Client libraries」頁面是歸在 SAM 區段之下，而非 Voice 區段。語音轉文字指南反倒提供你一份具體的相依性清單——Python 3.9 或更新版本，搭配 websockets 與 sounddevice 套件——外加一本語音 API 基礎知識食譜。因此，隨插即用的說法所描述的是一般性的 Model API 要求介面；即時 ASR 端點本身則是一個 WebSocket，有其自身的握手規則，且沒有已記載的包裝層。

Meta 尚未發布的內容

基準測試從缺，是文件本身的一項事實，因此這裡便如實陳述。Meta 的 Muse Voice Transcribe 模型頁面並未刊載準確率表格：其準確率證據是以三項圖片素材呈現——串流詞錯誤率排行榜、語者分離錯誤率比較，以及串流準確率指標——可擷取文字中沒有任何數字。模型頁面本身既未提供詞錯誤率，也未提供語者分離錯誤率，更沒有逐語言細分。

那份公告貼文確實載有供應商回報的數字，包括串流詞錯誤率與平均語者分離錯誤率，而那些就是我們在模型發布時所整理的數字；它們是 Meta 自家的量測結果，且至今仍未被第三方重現。本頁不會重新執行那項比較，因為在參考頁面上重跑發布日的供應商基準測試，會把一個未經重現的數字包裝成已有定論的數字。可以直白說明的範圍其實更窄：Meta 並未針對這個模型，發布與具名競爭對手在相同投入與相同測試框架下的正面對決評估，因此你在任何地方讀到的任何比較，都是把在不同條件下蒐集到的供應商數字拿來相比。

有一個日期也刻意保持未定。模型頁面完全沒有發布日期——它唯一的版本標記是 -1.0 在模型 ID 中。本文中的 2026-09-01 日期來自那則標有日期的公告貼文，而在此處，它是用來標定該模型的日期，而不是用來報導某個事件。

誰應該使用它，而誰不應該

Muse Voice Transcribe 的立論狹窄卻強而有力：即時音訊，且你需要在同一條串流上同時取得文字、說話者身分與輪次結束點，而價格低到足以持續運行，而非只在需要時才啟用。語音代理、即時字幕、會議與通話智慧、聽寫，以及大量轉錄，正是 Meta 點名的工作負載，而這些也正是這套介面實際量身打造的工作負載——一條 60 分鐘的 WebSocket，具備端點判定模式與工作階段範圍的說話者標籤。

反對它的理由也同樣具體。如果你需要字詞層級的時間戳、逐字信心分數、聲音事件或情緒偵測，或轉錄稿重新格式化，這個模型並沒有這些功能，而這是已載明的功能缺口，不是錯誤。如果你的音訊不是 16 或 24 kHz 的單聲道 16 位元 WAV 格式，而你使用的是檔案端點，你就得付出一個在其他地方不必付出的轉換步驟。而如果你的需求是批次轉錄封存錄音，且唯一考量是準確度，那麼串流這個賣點對你毫無用處——兩條路徑的價格相同，所以你是在為你不會用到的即時能力付費。

在你確定生產路徑之前，唯一必須查核的數字，就是這個頁面存在的目的所要回答的那個數字；而它也是唯一一個即使模型完全沒變、本身仍可能變動的數字：每小時音訊 0.18 美元，也就是 Meta 自家模型頁面今日所印的數字。Meta 的頁面是這項數字的權威來源。當它變動時，所有以它為基準來估算的東西——每月一千小時、每次訪談成本、自建與外購的計算——也會隨之變動。