Ming-3.0-audio-tiny 対 Qwen-Audio 3.1：演算できるウィンドウと、それができないカタログ

ここに、確認するのは簡単だが使いこなすのは難しい数字がある：Ming-3.0-audio-tiny の内部にあるテキストバックボーンは 131,072 ポジション用に設定されており、その手前にある音声タワーは一度に 3,000 フレームを 128 メルビンで受け取る。Qwen-Audio 3.1 は対照的に、コンテキスト長をまったく公開していない — モデルインデックスにも、3 つのモデル ID に付された一行説明にも記載がない。一方は数字を渡して解釈をあなたに委ね、もう一方は 3 つの製品名を渡してハードウェアを Alibaba に委ねる。この非対称性こそが比較のすべてであり、どちらのモデルがよりよく聞こえるかという比較ではない。何かにお金をかける前に、どちらの規模を見積もれるかという比較なのだ。 このようなリリースの背後にある、文書化された AI の障害やエージェントのインシデントは、OrcaRouter AI Incident Archive に集められており、各エントリには独自の情報源、重大度、信頼度グレード、異議ありフラグが付いている。

まず日付から。このモデルには妙な時系列があるためだ。Ming-3.0-audio-tiny の重みは 2026年9月3日に Hugging Face に登場した。リポジトリは 11:45 UTC に作成され、2つの safetensors シャードはその4分後に続いた。最近変わったのはチェックポイントではない。2026年10月16日から19日にかけて、リポジトリはそれを中心に書き換えられた——ついに動画言語モデルではなく音声モデルを記述した設定、音声出力用の Talker、文字起こし付きの参照音声クリップ2つ、GitHub 上の3つのデプロイプロファイル、そして10月19日13:19 UTC には、このリポジトリ史上初のモデルカード。誰も発表していない。したがって公正な問いは、9月に何が出荷されたかではない。今このモデルを動かすことについて何を計算できるのか、そして A​libaba のカタログが、代替案について何を計算させ、何を計算させないのか、である。

131,072トークンを分に変換する

その数値は実在し、検証可能だ。ほとんどのコンテキストに関する主張がそうであるとは言えないことを思えば、なおさらだ。テキスト設定は max_position_embeddings 131,072、512幅のKV潜在を持つMLAアテンション、そしてロータリーベース6,000,000を宣言している。しかし、トークン単位のコンテキストウィンドウは、音声1秒が何トークン分のコストになるかを知って初めて役に立つものであり、ベンダーはそのことを明かしていない。それは音声タワー自身の数値から導き出せる。

• エンコーダ入力 — 128メルビンの3,000フレーム。これはWhisperが10msホップで使用する30秒のウィンドウと同じものです。

• ダウンサンプラー — カーネル [3,3,3]、ストライド [2,2,2] のため、1つのウィンドウは8分の1に縮小されます。

• ウィンドウあたりのトークン数 — 3,000 ÷ 8、つまり約30秒の音声に対して375個の音声トークン。

• それが意味するのは — 131,072 を 375 で割ると約 349 ウィンドウ、つまりパイプラインがウィンドウ間で再バッファリングするのではなく単一の連続ストリームを供給する場合、3時間弱の音声に相当します。

その最後の条項は多くのことを担っているので、明確にしておきたい。3時間という数字は、公開されている2つの設定値に対する算術計算であって、ベンダーの主張ではない。また、プロセッサがクリップ間で位置をリセットする場合には誤りになる——まさに、ASR再現プロファイルがプロンプトごとに音声を1クリップに制限しているときに示唆していることだ。これは引用すべき仕様ではなく、検証すべき上限として扱ってほしい。

算数でないのは、メモリへの影響だ。MLA はヘッドごとのキーとバリューではなく KV 潜在を保存する。だからこそ 131K ウィンドウが単一カード上でそもそも成立し得る。リファレンスのテキストプロファイルは max_num_batched_tokens 32,768 で単一 GPU の 0.92 を予約しており、これは下限ではなく、フルウィンドウに大きなバッチを加えた分を見込んだ予約だ。max_model_len を下げれば、予約もそれに伴って下がる。Thinker のシャードは合計 17.74 GB なので、24 GB カードに重みが収まり、余裕も残る。

相手側は同じ質問に製品分割で答える。

A​libabaのModel Studioのインデックスでは、Qwen-Audio 3.1はコンテキストフィールドを持つ1つのモデルではなく、3つのモデルIDとして掲載されています。qwen-audio-3.1-asr-flash-streamingとqwen-audio-3.1-asr-flash-filetransは音声認識に分類され、qwen-audio-3.1-realtime-plusはspeech-to-speechに分類され、個別のASR呼び出しとT​TS呼び出しを伴わないエンドツーエンドの音声会話として説明されています。そのページには、重み、パラメータ数、コンテキスト長、価格のいずれも記載されていません。各IDの詳細ドキュメントは確認時点で解決できませんでした。

その分割は、パッケージング上の偶然ではなく、長尺音声問題への答えとして読むべきだ。ファイル文字起こしSKUは、プロバイダーが1時間の音声を販売する方法だ。アップロードすれば、サービスが好きなようにチャンク分割し、コンテキストウィンドウは他人のエンジニアリング問題になる。ストリーミングSKUは、プロバイダーが電話通話を販売する方法だ。どちらのSKUも、Mingが公開している数値を公開していない。つまり、Ming-3.0-audio-tinyに対してできるようには、Qwen-Audio 3.1のキャパシティモデルを構築できない。作れるのは請求書だけであり、それすらコンソールを必要とする。

• 確認できるもの — Ming：設定、アーキテクチャ、ライセンス、4つのsafetensorsファイル、3枚のベンチマーク画像、デプロイ用YAML。Qwen：3つの識別子とそれぞれ1文。

• サイズを決められるもの — Ming：重みは17.74 GB、テキスト用ならGPU 1基、音声用なら2基。Q​wen：ここからは見えない料金表を読むまで不明。

• キャッシュできるもの — Ming: 自分の KV キャッシュを、自分の max_model_len で。Qwen: エンドポイントが内部で行うことは、見えない形で。

• 故障モード — Ming: あなたが引き起こし、修正できる OOM。Qwen: クォータ、リージョン、または何も返さないドキュメントページ。

• ライセンス — Ming: MIT（モデルカードのメタデータおよび GitHub リポジトリの LICENSE に記載）。ただし、Hugging Face リポジトリには独自の LICENSE ファイルが含まれていない点に注意。Qwen: Model Studio の商用利用規約。読むべきモデル重みのライセンスが存在しないため。

誰も正直に答えられないベンチマークの問い

Ming-3.0-audio-tiny は assets/ に3枚の評価画像を同梱しており、その中のすべてのセルは inclusionAI が inclusionAI を測定したものです。カードは自己評価の行にアスタリスクを付け、比較モデルは自らのプロンプトとデコード設定の下で再現されたことを認めています。これは通常の開示であり、額面どおりに受け取る価値があります。これらは結果ではなく設計目標なのです。

この対決では数字が二重に厄介だ。というのも、有用な列がそもそも示されていないからだ。中国語認識では、小型モデルは平均文字誤り率3.79、大型の兄弟モデルは3.45。方言では10.29対9.40。音声インテリジェンスでは大きく後退し、MMAUは75.90対82.00、MMAU-Proは56.42対66.41、URO-Bench-Proの音声対話は81.92から54.15へと崩壊する。これらはすべてflashと比べれば微小だ。しかしQwen-Audio 3.1に対してはどれも微小ではない。Qwen-Audio 3.1は比較可能なスコアを公表しておらず、共通のテストセットも、共通のデコーディング設定も、両方を実行した第三者も存在しないからだ。

10秒で確認できるため、名指しする価値のある2つ目のギャップがあります。カードには、共有されている数値にはMingの両バリアントの結果が含まれると書かれています。それは認識画像とオーディオインテリジェンス画像については事実です。テキストインテリジェンス画像には4つの列があり、tinyモデルはそのうちの1つではありません。その列はMing-3.0-audio-flash、Qwen3.8-Omni Flash、Qwen3.5-Omni Plus、Qwen3.5-Omni Flashです。もしあなたの問いが、2.7B-active backboneが音声についての推論会話を保持できるかどうかなら、inclusionAIはその画像ではそれに答えていません。画像の上の文が何と言っていようと。

2つの形状が3時間でどのように異なって故障するか

長い音声では、製品の分割が見た目だけのものではなくなる。131Kウィンドウを持つ単一のチェックポイントは、1つのモデルが録音全体を読み、最後まで到達したときに最初の10分間を覚えているという約束だ。その約束には特有の失敗モードがある。すべてが一緒に劣化するのだ。音声がウィンドウからあふれるならチャンク化するが、チャンク化はチャンク間推論が静かに死ぬ場所だ——2分時点で登場した話者は、40分時点では再び見知らぬ人になる。

ファイル文字起こしSKUはその問題を隠し、別の問題を引き継ぎます。チャンク分割を制御できないため、不良な文字起こしを再現できません。サービスがチャンク間で文脈を保持したのか、独立したウィンドウをつなぎ合わせたのかを判断できません。さらに、同一のアップロード2回の間で出力が変わるとき、切り分けるべき変数がありません。ストリーミングSKUは、その制約を名前に正直に表しています。音声が届くたびに出力するように作られており、それはキャプションには適した形ですが、90分の通話のコンプライアンスレビューには適さない形です。

つまり、判断すべきは「どちらがより正確か」ではない — どちらの側も、それを決着させる数字を示していない。判断すべきは「どの失敗なら自分がデバッグできるか」だ。トランスクリプトをバイト単位で再現する必要があるなら、チェックポイントを自前で持て。20分でトランスクリプトが必要で、他人のポケベルに任せたいなら、SKUを借りろ。

このパイプラインでルーターがその真価を発揮するのはどこか

OrcaRouterはMing-3.0-audio-tinyを提供していません。当社のカタログにはなく、そのためのエンドポイントをご案内することもできません。ここにそれを提供するという申し出はありません。ルーターが担うのは、長尺音声パイプラインのうち音声モデルではない部分です。つまり、どの録音をローカルの2.7Bモデルに回し、どれをより大きなモデルに回すかの判断、文字起こしからの要約作成、アクションアイテムの抽出、通話へのタグ付けです。これらはテキスト呼び出しであり、1つのキーで200以上のモデルは、4社との契約より短い道です — プロバイダーの定価でマークアップ0%なので、ベンダーが値下げすれば支払う金額もその日のうちに変わります。 自動フェイルオーバーは、ここではいつも以上に重要です。90分のファイルの80分時点で失敗した文字起こしジョブは、最初からやり直すのではなく、2つ目の経路で再試行すべきです。

境界線の話は、口に出して言っておく価値がある。ルーターは呼び出しをルーティングする。17.74 GB のチェックポイントをホスト済みエンドポイントに変えてくれるわけではないし、Ming の 131K ウィンドウが本物かどうかを教えてくれるわけでもない。それを教えてくれるのは、自分自身の 1 時間の音声だけだ。

決着をつける実験

答えがすでに分かっている録音を1つ用意してください——3人の話者がいて、そのうち1人が文の途中で言語を切り替える会議——それを両方に通します。{{1}}Ming-3.0-audio-tiny{{/1}}では、trust_remote_code=True で読み込み、モデルカードが検証するASRプロンプトを使用し（言語を指定し、タブを入れ、次に文字起こしを記述します——そのタブがパーサーです）、max_model_len をデフォルトではなく必要な長さに正確に設定してください。Qwen-Audio 3.1 では、同じファイルをファイル文字起こしSKUとリアルタイムSKUの両方に通してください。これらは別製品であり、一致しないからです。

次に、ベンチマークスコアではない3つの点を比較してください。モデルはファイル全体を通して話者IDを保持できたか。言語が切り替わっても、音訳に置き換わらずに維持できたか。そして、結果を十分に説明して、1つの変数を変えて再実行できるか。最後の問いが、あなたがモデルを評価しているのか、ベンダーをオーディションしているのかを決めるものであり、この2つが近くない唯一の点です。