生成されたタイトルカードは「Ming-3.0-audio-tiny vs VibeVoice-ASR-Streaming 1.5B」と表示し、サブタイトルは「一方は誰が話したかを公開し、もう一方はダッシュを出力する」、3つのチップは「Ming: 話者分離の行が5件空白」「VibeVoice: 約2.9秒のチャンク」「両方ともMIT」と表示し、フッターは「Mingの数値はinclusionAIの評価画像から、VibeVoiceの数値はMicrosoftの設定とモデルカードから。どちらにも独立したスコアはない。」と表示する。
Engineering & Research

Ming-3.0-audio-tiny 対 VibeVoice-ASR-Streaming 1.5B:話者属性付きストリームに挑む5つのダッシュ

著者

Magnus Corvin

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

認識画像を開くにはMing-3.0-audio-tiny の Hugging Face リポジトリを開き、一番下までスクロールしてください。AISHELL-4、AliMeeting、AMI の話者ダイアライゼーションと連結最小置換誤差に関する5行は、tiny 列にダッシュが付いています。悪い数値ではありません。空白です。ベンダーは大型の兄弟モデルでは5行すべてを測定し、小型モデルでは測定を見送りました。次に、モデルカードを開いてください:対象はVibeVoice-ASR-Streaming 1.5B です。最初の箇条書きを読んでください:音声が届くにつれて、誰が何を言ったかを継続的に文字起こしします。これは同じ5行を裏返したものです。一方のモデルは話者帰属以外のほぼすべてを公開し、もう一方は主にそれを公開するために存在しています。 このようなリリースの背景にある、文書化された AI 障害やエージェントインシデントは、the OrcaRouter AI Incident Archive にまとめられており、各エントリには独自の情報源、重大度、信頼度グレード、異議ありフラグが付いています。

どちらも独立した評価は受けていない。ここでは通常よりその重要性は低い。なぜならこの比較は数値ではなく設計上の判断、つまり音声が途切れずに届き続けるときに何が起きるかで決まるからだ。Ming-3.0-audio-tiny は大きなウィンドウを持つファイルモデルで、音声出力はオプションだ。VibeVoice-ASR-Streaming 1.5B はストリームモデルで、約3秒ごとにテキストを出力し、各セグメントに話者をラベル付けする。ワークロードが録音なら、両者は競合する。ワークロードが部屋なら、挑んでいるのは片方だけだ。

設定で「ストリーミング」にかかるコストとは

Microsoftのリポジトリは、自社のレイテンシ予算について異例なほど明快で、トレードオフがマーケティングではなく検証可能になっています。音響トークナイザーと意味トークナイザーは因果的で、24 kHz入力に対して3,200倍の圧縮で動作するため、トークンストリームは音声1秒あたり約7.5トークンです。ストリーミングラッパーは1チャンクあたり22トークンフレームを、4フレームの先読み付きでバッチ処理します。22÷7.5は1回の出力あたり約2.9秒、4÷7.5はモデルが確定前に見られる将来音声の約0.5秒です。

• 出力周期 — 約2.9秒。先読みは、レイテンシーを犠牲にして精度を高める部分です。

• バックボーン — Qwen2ファミリーのデコーダーで、28層、隠れ次元1,536、12個のヘッド(うちキーバリューヘッドは2個)、64,000トークンのウィンドウ。

• サイズ — 合計5.63 GBの3つのsafetensorsシャード。これは1.5Bパラメータではありません。bf16で5.63 GBは計算上2.8 billion(約28億)に近く、名前に含まれる1.5Bはスタック全体ではなく言語バックボーンと解釈するのが適切です。

• 言語 — 10種類:中国語、英語、フランス語、ドイツ語、イタリア語、日本語、韓国語、ポルトガル語、ロシア語、スペイン語。

• Extras — コンテキストとして渡されるカスタマイズされたホットワード、および出力される各セグメントに付与される話者ラベル。

• 日付 — リポジトリは2026年9月2日15:51 UTCに作成され、翌朝に最終更新。VibeVoice GitHub READMEのニュース行だけでしか告知されておらず、つまりほとんど告知されていないに等しい。

A screenshot of the VibeVoice-ASR-Streaming-1.5B config.json file view on Hugging Face, uploaded about two months ago, showing an acoustic_tokenizer_config block with causal set to true and a single audio channel.

その64Kウィンドウは、Mingの131,072と比べるべき数字だ。容量の半分に聞こえるが、同じ種類の容量ではない。ストリーミングモデルは1時間分を保持する必要はない。すでに直近59分を書き留めているからだ。ウィンドウは、現在のチャンクに、モデルが引き継ぐ対話コンテキストを加えた作業記憶だ。Mingの131Kは逆の賭けだ。すべてをライブで保持し、その上で推論する。

Mingの賭け、そしてそれがもたらすもの

この小さなモデルの売りは認識精度ではない。inclusionAI 自身の表によれば、中国語では一回り大きな兄弟モデルに 0.34 ポイント劣り(文字誤り率 3.79 対 3.45)、方言では 0.89 劣る(10.29 対 9.40)。売りは、1 つのチェックポイントが認識・理解・推論・音声を同一のフォワードパスで処理し、しかもそのウィンドウが十分に長いため、「彼女は最初の 10 分間に何と言ったか」と尋ねることができる点にある。

音声知能の数値はサイズの割に立派で、単なる文字起こしツールよりこれを選ぶ理由になっている。MMAU 75.90、MMAR 67.70、MMSU 73.06、BigBenchAudio 99.20、音楽では MuchoMusic 58.07。これらはすべてベンダー実施で、自己評価行にはアスタリスクが付いており、カードには比較モデルが inclusionAI 自身のプロンプトとデコーディングで再現されたことが開示されている。これらは設計指針として読むべきだ。

表が教えてくれないのは、誰が話したかだ。それが五つのダッシュが示す欠落であり、偶発的ではなく構造的なものだ。録音についての質問に答えるモデルは、答えるために話者ごとのセグメンテーションを必要としない。会議の文字起こしを生成するモデルは必要とする。Ming はおそらく、話者ラベリングのようなものへプロンプトで誘導できるだろうし、「複数話者の録音」に関するカードの強調は、それがその問題の近くで訓練されたことを示唆している。だが、その「おそらく」が、未公開の五つの行の分の働きをしている。

A screenshot of the VibeVoice-ASR-Streaming-1.5B model card on Hugging Face, showing the automatic-speech-recognition tag, a 10 languages label, arXiv 2609.02812, an MIT licence, a model size of 3B params and BF16 tensors, and card text describing a unified streaming ASR model that transcribes who said what with customised hotwords.

正直に描かれた2つのパイプライン

同じ90分の録音がそれぞれを通過する様子を思い描いてください。

VibeVoice-ASR-Streaming 1.5B では、音声は約3秒ごとのチャンクで到着し、テキストも同じリズムで出ていきます。各セグメントは話者を伴います。ライブで表示できます。代償は、すべての判断が局所的寄りになることです。モデルは0.5秒先までしか見ておらず、保持している文脈だけを使うため、4秒間止まった話者が戻ってくると別のラベルで認識される可能性があり、2分時点で導入された名前は、ユーザーが供給するホットワード機構を通じてしか回復できません。チャンク間の一貫性こそテストすべき点であり、モデルカードが定量化していない点です。

Ming-3.0-audio-tiny では、ファイルが届くと全体がコンテキスト内に収まり、回答は届くときに届きます。チャンク間の一貫性はリスクになりません。チャンクが存在しないからです — ウィンドウ内までなら。代償は、モデルが処理を終えるまで何も利用できず、メモリ予約がウィンドウ全体に合わせて確保されることです。参照 ASR プロファイルは、32,768 トークンのバッチでカード 1 枚の 0.92 を占有します。下げられるのはmax_model_len だけです。ストリーミングにはできません。リポジトリにストリーミング経路が存在しないからです。

• レイテンシ特性 — VibeVoice:連続的で、約3秒遅れ。Ming:最後に1つの回答。

• 帰属表示 — VibeVoice:仕様上、セグメントごと。Ming:未公開。

• コンテキスト — VibeVoice: 64Kの動作ウィンドウと独自のトランスクリプト。Ming: 131,072位置、プロセッサが1つの連続ストリームを供給する場合、エンコーダ上の計算では約3時間分の音声。

• 出力 — VibeVoice: テキスト。Ming: テキスト、または2台目のGPU上のオプションのTalkerを通じた合成音声付きのテキスト。

• ハードウェア — VibeVoice:5.63 GB のチェックポイントなので、一般的なカード1枚で済みます。Ming:Thinker が 17.74 GB、テキスト用に1枚、音声用に2枚。

A generated two-column comparison scoreboard for Ming-3.0-audio-tiny and VibeVoice-ASR-Streaming 1.5B across six dimensions: output shape, speaker attribution, working context, hardware footprint, licence, and what neither vendor publishes, with a footer noting that Ming figures come from inclusionAI and VibeVoice figures from Microsoft, and that neither has an independent score.

免許証と書類は同じで、それは珍しいことだ

どちらもMITライセンスです。どちらも静かなリリースです。どちらもドキュメントが追いつく前に重みを公開し、どちらもチェックポイント名とは異なる名前のGitHubリポジトリに依存しています。MingのデプロイプロファイルはinclusionAI/Ming-3.0-audio-flashにあり、VibeVoiceの使用手順はmicrosoft/VibeVoiceで7Bの兄弟モデルとともに公開されています。

各リポジトリが伝えている内容には違いがあります。Microsoftは技術レポート——arXiv 2609.02812——と、カード内の結果図を提供しています。これは表ではなく画像であるため、数値を抽出できず、言語別のエラー率も本文中には記載されていません。inclusionAIは3枚のベンチマーク画像を提供しており、これらも画像です。さらに、自らの弱点をセルを空白のままにすることで暗黙にしか示していないカードも提供しています。どちらのベンダーも、手作業で転記せずにスプレッドシートへ貼り付けられる数値を提供していません。

調達を担当する人なら誰でも留意すべき非対称性が一つある。Ming の Hugging Face リポジトリには LICENSEファイルが含まれておらず、カードのメタデータに別リポジトリにあるライセンスへのリンクがあるだけだ。VibeVoice のカードはメタデータに MIT と記載され、リポジトリにはライセンスファイルが含まれている。どちらの主張も真実だが、成果物の中に入っているのは一方だけである。

ここでルーターが向いていることと向いていないこと

OrcaRouterはどちらのモデルも提供していません。Ming-3.0-audio-tinyはチェックポイントであり、VibeVoice-ASR-Streaming 1.5Bもチェックポイントです。どちらも当社のカタログには含まれておらず、本記事のいかなる内容も、それらをホスティングする提案ではありません。このようなパイプラインにおけるルーターの役割は、文字起こしの下流、意思決定の上流にあります。すなわち、通話の要約、約束事項の抽出、そのセグメントに人が必要なのかどうかの分類、作業言語以外で話された部分の翻訳です。これらの呼び出しはテキストであり、1つのエンドポイントで0%のマークアップで200以上のモデル——プロバイダーの定価がそのまま適用されるため、ベンダーの価格変更は当日に当社側へ反映されます——を利用できることは、ビルドからベンダーごとの契約を1件ずつ減らすことになります。自動フェイルオーバーは、2時間の文字起こしジョブが午前2時にその出力を信頼できるどこかへ引き渡さなければならないときにこそ重要となる機能です。

ルーターが行わないのは、一致しない2つの話者ラベルを突き合わせて整合させることや、Mingの欠落したダイアライゼーション行が本当の弱点なのか、それとも単に測定されていないだけなのかを判断することです。それはあなた自身の音声で行う仕事です。

彼らを一午後で見分けるテスト

3人で20分間録音する。うち1人は他の人の話を2回遮り、もう1人はノートPCのマイクを使っている。これをVibeVoice-ASR-Streaming 1.5Bに通し、ホットワードリストには3人の名前を入れる。モデルがまさにこのために提供している仕組みだからだ。同じファイルをMing-3.0-audio-tinyに、言語ラベル、タブ、続いて書き起こしを求める検証済みプロンプトを使って通し、その後2ターン目で各文の発話者を特定させる。

4つの項目を評価してください。最初のモデルが話者交代を何回正しく捉えたか、録音途中で話者ラベルが入れ替わったかどうか、2番目のモデルの帰属がファイル全体で安定していたか、そしてどちらの出力をより速く手作業で修正できるかです。最後の項目はベンチマークではなく、どちらのベンダーの数値よりも本番環境での体験をよく予測します。

その作業をする間は、ダッシュのことも念頭に置いてください。方言表を小数点以下2桁まで公開しながら、5つのダイアリゼーションのセルを空白のままにしているベンダーは、自社の自信がどこで終わるかについて、何か具体的なことを示しています。マイクロソフトはというと、表ではなく図を公表し、その絵を読み取ることはあなたに任せています。どちらも、第三者が検証した数字を示してはいません。

それぞれが実際に属する場所

ライブキャプション、コールセンター監視、各行の横に名前が必要な会議アシスタント——そうした形のために{{1}}VibeVoice-ASR-Streaming 1.5B{{/1}}は作られており、{{2}}5.63 GB{{/2}}で、おそらくすでにお持ちのハードウェアで動作します。アーカイブのコンプライアンスレビュー、「これら40件の録音全体から和解に関する言及をすべて見つけて」、音声の最中ではなく後に質問が来るようなあらゆるケース:{{3}}Ming-3.0-audio-tiny{{/3}}の単一の大きなウィンドウとその理解スコアの方が適しており、誰が話したかを誰も尋ねなければ、欠けている話者分離の行は問題にならなくなります。

ストリーミング処理のジョブにMingを選ぶのは、131,072が64,000の2倍だからという理由なら誤りであり、推論処理のジョブにVibeVoiceを選ぶのは、1.5Bが9.3Bより安く聞こえるからという理由なら誤りだろう。どちらの数値も、その文が前提としているものとは別の何かを表している。そして、それがこの比較で最も確実に示されたことだ。