Voxtral Mini 4B Realtime Arabic 與 Voxtral 4B TTS：同一場對話的兩端

這兩個模型共享一個名稱、一個參數量，卻有著一份行為不同的授權條款檔案，而相似之處就到此為止。Voxtral Mini 4B Realtime Arabic 於 2026 年 10 月 8 日被推送至 Hugging Face，且未附帶任何公告，它接收音訊並產生阿拉伯文——這是 Voxtral-Mini-4B-Realtime-2602 的串流微調版本，專為現代標準阿拉伯文與十五種具名方言打造，Apache 2.0，在 480 毫秒延遲下平均字元錯誤率為 8.82%。Voxtral 4B TTS 由 Mistral AI 於 2026 年 3 月發布，則反其道而行：文字進、語音出，二十種預設語音，外加可從一段簡短參考片段進行調適，支援九種語言，包括阿拉伯文，以及一份授權條款——CC BY-NC 4.0——禁止將權重本身用於商業用途。它們不是替代方案，也不是變體。它們是語音迴路的兩半，而之所以要把它們放在一起審視，是因為你對其中一個所做的決定，會比大多數團隊所預期得更大幅限制另一個。

大多數比較頁面會告訴你，這些模型彼此不相關，因為一個是 ASR，一個是 TTS，然後就停了。這是事實，但沒什麼用。真正值得知道的是它們交會的地方：語音代理兩者都需要，兩者的授權條款方向相反，兩者的硬體佔用相近，但吞吐量特性卻不同，而阿拉伯語覆蓋範圍的宣稱則是完全不同的形態。以下所有內容都圍繞這四個交會點。

就對管線而言真正重要的層面來說，每個模型是什麼

• Voxtral Mini 4B Realtime Arabic — 串流自動語音辨識。輸入 16 kHz 音訊，輸出文字，BF16 格式約 44 億個參數，透過 vLLM 以 /v1/realtime 的 WebSocket 提供服務，或在 Transformers 5.2.0 版起以原生方式使用。包含因果音訊編碼器與語言解碼器、可設定的轉錄延遲（公布準確率數據時所引用的值為 480 毫秒），並隨附正規化模組，以便重新推導阿拉伯文字元錯誤率。Apache 2.0。

• Voxtral 4B TTS — 串流與批次文字轉語音。輸入文字，輸出 24 kHz 音訊，格式可為 WAV、PCM、FLAC、MP3、AAC 或 Opus，約有 40 億個參數，內建 20 種預設語音，並可從短至三秒的參考音檔進行語音調適。Mistral 自家的基準測試在單一 H200 上以 vLLM-Omni 0.18.0 執行，輸入 500 字元及十秒參考音檔，回報延遲為 70 毫秒，並行處理數為 1 時即時因子為 0.103，並行處理數為 16 時升至 331 毫秒與 0.237，並行處理數為 32 時則為 552 毫秒。以 API 形式使用，每千字元 0.016 美元。

從那兩段文字得到的第一個觀察是，這對組合規模很小。兩款模型都落在 40 億參數級別，且都能以 BF16 裝在單一加速器上，這意味著一個完全以開放權重打造的阿拉伯語語音代理，最多只需兩張 GPU 部署，而且若兩側都進行量化，合理推測也能以單張 GPU 部署。這正是把它們視為一組、而非兩個獨立產品決策的實際理由。

授權不對稱才是研究發現，而非腳註。

這就是讓那些以為同一實驗室、相同命名慣例的模型帶有相同條款的人感到意外的地方。

• Voxtral Mini 4B Realtime Arabic — Apache 2.0。商業使用、修改、再散布與微調皆獲允許，但須遵守不得侵害第三方權利的標準限制。

• Voxtral 4B TTS — CC BY 4.0，承襲自其背後的參考語音資料集。非商業用途。Mistral 的模型卡明確指出，該模型會繼承其語音參考資料的授權條款，而這些參考資料來自 EARS、CML-TTS、IndicVoices-R 與一組阿拉伯語自然音訊等來源。權重可供下載，且該授權並非商業授權。

這是對大家第一個都會想到的那個確切架構的硬性限制。如果你打造一個阿拉伯語語音代理，其語音轉文字環節是 Voxtral Mini 4B Realtime Arabic，文字轉語音環節是 Voxtral 4B TTS，那麼你會有一條管線：其中一半元件可自由商用，另一半不行，而限制較嚴的那一半主宰了產品。ASR 模型採用 Apache 2.0 並不能讓 TTS 環節解套。在本機執行這對組合不會改變授權條款，不隨附權重也一樣——這項限制繫於使用行為，而非散布。

Mistral 為語音方面提供的商業途徑，是每千個字元 $0.016 的託管 API，這是一份服務協議，而非授權授予。對產品團隊而言，實際後果是：這個迴路中可自由商業化的那一半，是負責聆聽的那一半；而負責說話的那一半，則不是 API 依賴，就是授權協商。這顛覆了多數團隊在著手打造開放語音堆疊時的假設，而且值得在寫完整合之前就發現，而不是之後才發現。

阿拉伯方面的說法並不一致，而且其中只有一項是保障承諾。

兩個型號都列出阿拉伯語。這些列表代表的意義各不相同。

• Voxtral Mini 4B Realtime Arabic — 阿拉伯語就是全部範圍。列為訓練目標的十六種變體包括：現代標準阿拉伯語、摩洛哥、利比亞、突尼西亞、阿爾及利亞與哈桑尼亞阿拉伯語，海灣、納吉迪、阿曼與薩那阿拉伯語，埃及與蘇丹、美索不達米亞以及南黎凡特與北黎凡特阿拉伯語，還有查德阿拉伯語。該集合以外的任何內容均記錄為超出範圍。一個彙總準確度數字：8.82% CER，取七項阿拉伯語基準的平均值。

• Voxtral 4B TTS — 阿拉伯語是九種支援語言之一，與英語、法語、西班牙語、德語、義大利語、葡萄牙語、荷蘭語和印地語並列。模型卡描述該支援範圍涵蓋「多樣的方言」，但未逐一列舉，且未公布阿拉伯語或另外八種語言中任何一種的各語言品質數據。

一起解讀時，這兩份資料會詳細說明你的系統「聽」阿拉伯語的能力，卻幾乎完全沒說明它「說」阿拉伯語的能力。這種不對稱對達里賈語或波斯灣阿拉伯語的語音代理來說有實際後果：輸入端有已發表的基準測試和可供評估比對的方言清單，輸出端則只有語言標章和語音名冊。沒有人發表過 Voxtral 4B TTS 的方言阿拉伯語可理解度測量，而語音調適功能也無法解決這個問題——調適語音只會改變語音聽起來像誰，不會改變它產生哪種方言。

關於 ASR 模型本身的準確率數字，還有第二個更細微的重點，而這點同樣適用於 TTS 這一側。Mistral 回報，在同樣這七項基準測試、相同正規化設定下，串流模式的 CER 為 8.82%，相較之下，離線的 Voxtral Transcribe Arabic 為 7.91%，因此串流大約要付出一點的代價。TTS 這一側的對等取捨——串流推論相對於批次處理在輸出品質上要付出多少代價——在這些資料中完全沒有量化。延遲數字是有的；品質落差則付之闕如。

吞吐量：一款模型是為了被推向極限而打造，另一款則不是

Mistral 只針對這些模型中的恰好其中一個發布了吞吐量資料，而這些數字說明了原因。

• Voxtral 4B TTS —— 在單張 H200 上搭配 vLLM-Omni 量測，使用 500 個字元的輸入與 10 秒的音訊參考，吞吐量從併發數為 1 時每 GPU 秒約 119 個字元，提升到併發數為 16 時約 879 個字元，以及併發數為 32 時約 1,431 個字元；延遲則從 70 毫秒上升到 331 毫秒，再到 552 毫秒。這是一條可供你據以規劃容量的吞吐量曲線，也是你會預期從一個為生產環境語音服務而設計的模型所看到的形狀。

• Voxtral Mini 4B Realtime Arabic — 這張模型卡並未報告任何吞吐量數據、併發行為或硬體基準測試。它確實說明的只有架構：一個因果編碼器，以及在編碼器與解碼器兩端都採用的滑動視窗注意力機制；基礎模型上的描述稱其可支援實際上無界限的串流。準確度數據是在 480 毫秒延遲下引述的，這意味著模型在合適的硬體上能跟上即時音訊，而這就是已公布效能範圍的全部。

這個落差與其說是對任一模型的批評，不如說是對成熟度的陳述。TTS 模型有公開的 SLO 表，因為它是以產品形式發布，附有部落格文章、示範、API 和價格。阿拉伯語 ASR 模型沒有公開的效能範圍，因為它是以附有模型卡的儲存庫形式問世。如果你今天正在規劃阿拉伯語轉錄機群的規模，你所需的吞吐量數字尚不存在，而要取得它的唯一方法，就是在自己的硬體上以自己的音訊執行 vLLM 服務路徑。

這也是路由層改變部署形態而不僅僅是計費的地方。OrcaRouter 不路由這些模型中的任何一個——我們不託管任何 Mistral 語音端點，本文也沒有聲稱其他情況——但它們之間的語言模型層正是受益於路由的層：一個 API 金鑰就能以供應商定價、0% 加價使用超過 200 個模型，因此供應商的價格變動在宣布當天就會反映在我們這邊，以及自動容錯移轉，這樣單一上游供應商的一個糟糕下午就只是重新路由，而不是你的語音迴路中斷。由兩個自託管的 Mistral 模型加上一個託管的推理模型組成的語音代理有三個故障域；路由層就是讓中間那個變得無趣的原因。

成本，並列對照，但有一項但書：其中一方沒有價格。

• Voxtral 4B TTS — 透過 Mistral 的 API 每千字元收費 0.016 美元，或者若你依允許自身使用情境的條款自行架設，就只需負擔 GPU 的成本。粗略感受一下規模：一千個字元大約是兩百多個單字，因此在定價表價格下，一分鐘的語音輸出僅需一美分的零頭，而且這還沒算上自行運行所帶來的任何併發優勢。

• Voxtral Mini 4B Realtime Arabic — 未公布價格、沒有託管服務、也沒有價目表。成本在於硬體與使用率。在一部現代加速器上運行 4.4B BF16 模型，是一筆固定的每月成本，你得將它攤提到該機器能處理的所有音訊量上；這在持續用量下很便宜，但在偶爾用量下則是純粹的浪費。

真正更重要的比較，或許是與你原本會改用的替代方案相比。在聆聽端，這個阿拉伯語檢查點正與按音訊小時計價、費率公開且低廉的串流 API 競爭——Microsoft 的 MAI-Transcribe-2-Streaming 以每音訊小時 0.54 美元的優惠價提供，xAI 的 Grok Voice Transcribe 2.0 則以每音訊小時 0.20 美元的串流價格提供——這意味著阿拉伯語轉錄服務每分鐘只需十分之幾美分就能買到，而開放權重方案的立論必須建立在方言準確度、資料落地或微調能力上，而不是單位成本。在說話端，邊際成本為零的自架 TTS 模型在大量使用時，相較於按字元計價的 API 確實是一大優勢，這也是為什麼 CC BY-NC 授權才是限制因素，而非價格。

給任何正在為價格導向的轉換編列預算的人一個結構性提醒：一台以 0% 加成直接傳遞供應商標價的路由器，正是供應商費率變動在宣布當天就會顯現、而非等到下一個重新定價週期才反映的環節。這件事在「聽」這一端比在「說」這一端更重要，因為轉錄是按音訊時數計價，而那是供應商會不時調整的數字。

如何思考在它們之間做選擇

你不是在兩者之間做選擇。問題在於，你能在開放權重上打造這個迴圈的哪一半，而授權條款會給出答案。

如果你的需求是自成一體、音訊永遠不會離開你的基礎架構的阿拉伯語語音代理，那麼聽取端可無條件供你使用：Apache 2.0、可下載、可微調，附有一份可據以測試的方言清單，以及已公布的阿拉伯語錯誤率。限制落在說話端，而你有兩個誠實的選項——將語音合成移至商業協議下的託管服務，或從架構中移除 Voxtral 4B TTS，並為阿拉伯語尋找一個採用寬鬆授權的合成模型。

如果您的需求是生產級轉錄服務，而語言是阿拉伯語，那麼要抉擇的是：一個可下載的 4.4B 檢查點，附有已發佈的方言分類體系與單一總體錯誤率；還是一個託管的串流 API，附有已公佈的費率、已公佈的延遲與第三方排行榜。開放模型在控制權、資料存放地點與微調方面勝出；託管選項則在證據、支援與營運簡便性方面勝出。權重問世兩天後，Mistral 以外還沒有人對其進行評測，而這是自行執行基準測試的理由，不是否定該檢查點的理由。

最能改變這個局面的是，以允許商業使用的條款發布阿拉伯語合成——也就是聆聽端早已遵循的同一套模式。在那樣的發布出現之前，這個迴圈仍會維持半開，而實務工作就是決定你願意租用哪一半。

我們並未自行託管這兩個 Mistral 語音模型，本文也沒有如此聲稱；語音迴圈在它們之上需要的是語言層，而那是可路由的——一組 API 金鑰即可串接超過 200 個模型，以供應商定價提供、零加成，因此供應商的費率調整一經公告，當天就會反映在我們這邊。

自動容錯移轉可讓由三個元件組成的語音代理之中間部分——位於兩個自架 Mistral 模型之間的一個上游推理模型——不至於成為拖垮產品的那一環。