Ming-3.0-audio-tiny は今や1台のGPUで動作——そしてその設定はついに128Kを示す

チェックポイント（Ming-3.0-audio-tinyの背後にあるもの）は、2026年9月3日以降ダウンロード可能でした——2つのsafetensorsシャード、17.7 GBで、リポジトリ自体が作成されてから9分後にプッシュされました。今週まで存在しなかったのは、その実行方法を説明するほぼすべてでした。2026年10月16日から19日にかけて、inclusionAIは9月に同梱されていた設定を置き換え、8,192トークンウィンドウを持つ動画・言語・音声バリアントを、131,072をうたう音声専用のものに変え、音声を生成するTalkerを追加し、文字起こし付きの参照音声クリップを2つ追加し、——リポジトリにモデルカードがまったく存在しない3日間を経て——モデルカードを1つ作成しました。これらの文書が指し示すコードは10月15日にGitHubに到着しました。それは、より大きな兄弟モデルにちなんで名付けられた、Ming-3.0-audio-flashというリポジトリで、tinyモデルがこれまで持ったことのなかった3つのデプロイプロファイルを備えています。誰もこのことを発表していません。したがって、答える価値のある問いは、何が新しいかではありません——重みは7週間前のもので、到着した日とバイト単位で同一です——読者が先週の月曜日には実行できなかった何を今実行できるようになったか、そしてそうする際に精度がどれだけ犠牲になるかです。 このようなリリースの背後にある、文書化されたAI障害やエージェントインシデントは、the OrcaRouter AI Incident Archiveに収集されており、各エントリには独自の出典、重大度、信頼度グレード、論争フラグが付いています。

コミット時点で何が変更されたか

Hugging Faceのコミットログは全文読めてしまうほど短く、その推移は異例だ。9月に3件のコミット、その後3週間は何もなく、続いて4日間で6件。

• 9月3日 11:45および11:49 UTC — リポジトリが作成され、その後2つのシャードが「Add files using upload-large-folder tool」で追加されます。それらに付属するREADMEのタイトルは「Ming Audio V3」で、Apache 2.0を宣言し、リポジトリにautomatic-speech-recognitionタグを付け、「現在ASRパスを文書化している」と述べています。

• 9月17日 — examples/フォルダが削除されます。これ以降、リポジトリには重み、カスタムモデリングコード、短いカードのみが残り、それ以外は何もありません。

• 10月16日 08:14〜08:20 UTC — 影響の大きいものです。config.json が書き換えられます: max_position_embeddings はテキストバックボーン上で8,192から131,072に変わり、transformers_version は4.56.2から5.14.1に変わり、audio_config.model_type は bailing_moe_v3_vl_audio から bailing_moe_v3_audio に変わります — もはやモデルを説明しない video-language-audio 型です。同じプッシュで auto_map には、これまでなかった AutoModel と AutoProcessor のエントリが追加され、processor_config.json が現れ、さらに talker/ ツリーが加わります: 1.4 GB の音声モデル、1.6 GB の VAE、CAM++ 話者エンコーダ、英語と中国語のテキスト正規化有限状態トランスデューサです。同じプッシュで古い README も削除され、その後3日間、リポジトリにはモデルカードが一切ありません。

• 10月17日 11:44 UTC —「音声プリセットを追加」。参照用WAV 2ファイル、US_James.wav と 灵楷.wav、およびそれらの正確な文字起こしを収めたJSONファイル。

• 10月19日 10:36、11:44、11:49 UTC — クリーンアップとアップロードのコミット3件。

• 10月19日 13:19 UTC — 「Ming-3.0-audio-tinyモデルカードを追加」。8,514バイトで、リポジトリ史上初めてASR経路ではなく音声・オーディオモデルを記述した文書。

GitHub側には独自のタイムラインがあり、それはより遅れて始まります。 inclusionAI/Ming-3.0-audio-flashは10月15日03:50 UTCに作成されました——重みが存在してから6週間後——そして10月19日14:53 UTCにもまだプッシュされていました。スターは8個、MITライセンスファイルがあり、deploy/ディレクトリには6つのYAMLプロファイルが含まれ、そのうち3つはtinyチェックポイントを名指ししたものです。inclusionAI/Ming-3.0-audio-tinyというリポジトリは存在しません。そのURLは404を返し、tinyモデルのコードは兄弟モデルのコードと一緒にflashリポジトリ内にあります。

設定の書き換えこそが本題だ

コンテキスト長フィールドが16倍に増えるのは、見た目だけの変更か構造的な変更のどちらかですが、今回の場合、差分の残りの部分は構造的だと言っています。9月にリポジトリはmodeling_bailing_moe_v3_audio.pyとprocessing_bailing_moe_v3_audio.pyをツリーに追加しましたが、その設定ではbailing_moe_v3_vl_audioというタイプの音声タワーが記述されていました — 動画言語ビルドの名残です — さらにそのカードは、モデルをtrust_remote_code=Falseでインスタンス化するよう指示していましたが、これはカスタムモデリングファイルが望むものではありません。10月の設定は、宣言された型、宣言されたランタイム、コードパスが一致する最初の設定です。

• バックボーン — 24層、隠れサイズ1,536、16のアテンションヘッド、128のルーテッドエキスパート（トークンごとに8がアクティブ）と1つの共有エキスパート、エキスパート中間サイズ512、インデックス1に最初の高密度層、ルーテッドスケーリング係数2.5、語彙数157,184。

• Attention — MLA は、512 次元の KV 潜在表現と 256 次元のクエリ潜在表現を備え、rope_theta 6,000,000、partial_rotary_factor 0.5 です。低ランクの KV 形式だからこそ、1 枚のカード上で 131,072 トークンのウィンドウが議論の対象にさえなります。キャッシュが保存するのは潜在表現であり、ヘッドごとのキーとバリューではありません。

• オーディオタワー — 32層、幅1,280、20ヘッド、3,000フレームのコンテキストと128個のメルビン、カーネル[3,3,3]、ストライド[2,2,2]のダウンサンプラーを備える。オーディオトークンID 157,168。

• サイズ — 総パラメータ数9.3B、トークンあたり2.7Bをアクティブ化、全体を通してbfloat16、Transformers 5.14.1に対して宣言。

• 入力と出力 — 音声とテキスト指示を入力し、テキストを出力、またはオプションの{{1}}Talker{{/1}}を通じてテキストと合成音声を出力します。カードごとに、アクセントや方言を含む中国語と英語に対応します。

設定の書き換えで行われるのは、重みを一切追加することではありません。リポジトリ内の4つのsafetensorsファイル——2つのThinkerシャード、Talker、VAE——は、私が確認したすべてのリビジョンで、最初のアップロードにさかのぼっても同じサイズでした。これは変更されていないチェックポイントに対するドキュメントとパッケージングの変更であり、まさにそれが、8,192から131,072へのジャンプが信頼できる理由です。誰も何も再トレーニングしていないため、その主張は鵜呑みにするのではなく、モデルを読み込んで長いコンテキストを要求することで検証できます。

書類上、まだ一貫していない点が一つあります。リポジトリの最上位の Hugging Face パイプラインタグは text-to-speech と表示されていますが、カード自体の概要では、指示を受け取ってテキストまたは音声を返す音声言語モデルとされています。このタグは、Talker が最後に触れられた機能であったことの名残であり、Hub をタスクでフィルタリングする人以外には誰にも重要でない類のものです。

テキストにはGPU 1台、音声には2台

ここで tiny モデルがその名にふさわしいことが分かる。そしてそれが見えるのは、デプロイメントプロファイルが今や公開されているからにすぎない。flash モデルのテキストプロファイルはdevices: "0,1,2,3,4,5,6,7" で動作し、tensor_parallel_size: 8 を指定している — つまり 80 GB のカード 8 枚であり、これは 256 GB の bf16 重みがキャッシュを一切確保する前に要求する構成だ。tiny モデルにも独自のプロファイルが 3 つあり、そのうち 2 つはカード 1 枚を要求する。

• テキストとASR、vLLM-Omni — 単一ステージをデバイス: "0"上で、テンソル並列サイズ1、max_model_len 131,072、max_num_batched_tokens 32,768、gpu_memory_utilization 0.92、温度0.6でサンプリングし、最大65,536出力トークン。

• 音声出力付きのフルオーディオ — 2段階。Thinker は デバイス: "0" でカードの 0.78、Talker は デバイス: "1" で 0.18。Talker ステージは出力トークンを1つに制限し、テキストを生成しないため temperature は 0.0 です。

• ASR再現 — 10-gram no-repeatロジットプロセッサを後付けしたthinker専用パイプラインで、音声はプロンプトごとに1クリップに限定、max_model_len 131,072、temperature 0.0、出力トークン32,768。これはベンダーの認識数値が取得された構成であり、比較するつもりなら正確にコピーする価値があります。

• SGLang — GPU 1基、可視デバイス1台、テキスト出力のみ。このカードには、この経路では音声出力を利用できないことが明記されています。

これらのプロファイルは散文ではなくファイルで、flash リポジトリのdeploy/ ディレクトリにあります — 6 つの YAML プロファイルがあり、そのうち 3 つは小さなチェックポイントにちなんで命名されています。

メモリの数値は正直に読みましょう。0.92 は、ステージをどのカードに向けてもそのカードの取り分であって、要件ではありません。Thinker のシャードは合計 17.74 GB なので、重みは 24 GB のカードに収まり、キャッシュとアクティベーション用に約 6 GB が残ります。0.92 の予約量は、131,072 トークンのウィンドウと 32,768 トークンのバッチを同時に扱うことを想定したサイズで、max_model_len を下げれば減ります。1枚のカードでできないのは音声を生成することです。なぜなら Talker とその VAE は2つ目の重みセットを持つ2つ目のプロセスであり——CAM++ エンコーダとトランスデューサを加える前の時点で 3 GB——、参照プロファイルではそれらに専用のデバイスが割り当てられています。テキストは1つの GPU で、音声による会話は2つで：これが正直な計算であり、兄弟の 8 とは別の予算項目です。

ダウンロードには実際に何が含まれていますか

リポジトリの合計は 20.78 GB です。Thinker は 17.74 GB で、9.55 GB と 8.19 GB の 2 つのシャードに分かれています。Talker が 1.40 GB、その VAE が 1.56 GB、スピーカーエンコーダーが 28 MB を追加し、トークナイザーとノーマライザーのファイルが残りを占めています。量子化版、より小さいチェックポイント、ベンダーが公開した GGUF 変換は存在しないため、自分で量子化しない限り bf16 の数値が下限です。

• 読み込み中 — AutoProcessor.from_pretrained(..., trust_remote_code=True, use_fast=False) と AutoModelForCausalLM.from_pretrained(..., dtype=torch.bfloat16, device_map="auto", trust_remote_code=True)。その後、カード自体のスニペットはaudio_feats を手動でモデルの dtype にキャストしています。これは、プロセッサ経由のパスが優先されていなかったことを示す小さな手がかりです。

• ASRの契約 — 検証済みのプロンプトは、モデルに話されている言語を特定し、言語ラベルと文字起こしの間にタブを入れるよう求めます。評価ハーネスを構築しているなら、そのタブがパーサーになります。「これを文字起こしせよ」という一般的な指示は、inclusionAIが測定した設定ではありません。

• 音声 — vLLM-Omni のデフォルトは 灵小柔 という組み込み音声で、モデルディレクトリには 灵楷 と US_James の2つの参照プリセットが書き起こし付きで同梱されています。音声クローンには参照 WAV とその正確な書き起こしが必要です。カードには、組み込み音声の選択と参照クリップを1つのリクエストで組み合わせることはできないと警告されています。

• ライセンス — カードのメタデータと、2025年付のGitHubリポジトリのLICENSEにMITと記載されています。欠けている点に注意してください：Hugging Faceリポジトリには、それ自体のLICENSEファイルがありません。物理的に内部にある唯一のライセンス文は、talker/data/にある同梱の言語識別モデルのものです。MITの主張は本当ですが、それはワンクリック先、もう一方のモデルにちなんで名付けられたリポジトリにあります。

• 反応 — 今週時点でダウンロード3件、いいね5件。フラッシュモデルはダウンロード22件、いいね8件。どちらの数字も品質の証拠ではない。どちらも、カードも告知もない9月のアップロードが広がらなかったことの証拠だ。

ベンチマークの画像と、欠けている列

3枚のPNGがassets/にあり、評価を担っています。3枚ともinclusionAI自身の実行によるものです。ベンダーは自己評価の項目にアスタリスクを付け、比較モデルは自社のプロンプトとデコード設定で再現したため、その数値は公式レポートと異なる可能性があると注記しています。このチェックポイントについて独立評価が公表されているものは、私が探した限り見当たりませんでした——アリーナへの登録も第三者によるスコアもありません——つまり以下のすべての数値は、ベンダーが自社モデルについて述べているものにすぎません。それは無視する理由ではなく、判定ではなく設計ブリーフとして読むべき理由です。

有益な比較は、同じ系列のモデルと比べるとごくわずかだ。なぜなら両方とも同じハーネスで実行されたからだ。認識では小さいモデルは少し劣り、長い音声の推論では大幅に劣る。

• 中国語ASR平均 — Ming-3.0-audio-tinyの文字誤り率は3.79、Ming-3.0-audio-flashは3.45。低いほど優れているため、tinyは0.34ポイント後れを取っています。

• 英語ASRの平均 — 4.36 対 3.69。方言の平均 — 10.29 対 9.40。

• BigBenchAudio — 99.20 対 99.40。実質的に互角で、サイズの差が表れない唯一の行です。

• MMAU — 75.90 対 82.00。MMAR — 67.70 対 74.40。MMSU — 73.06 対 78.82。MMAU-Pro — 56.42 対 66.41。

• 長尺音声の精度 — 56.39 対 66.30。LongAudioSpan — 35.45 対 41.12。長尺音声チェーンスコア — 10.56 対 12.31。

• 音声インタラクション — URO-Bench-Pro は54.15 対 81.92で、27.8ポイントの急落。VoiceBench は74.29 対 86.74。SpeechFCEval は69.80 対 82.60。

• ツール呼び出し — BFCL-v3 Audio 79.80 対 81.40。音楽 — MuchoMusic 58.07 対 65.65。

方言の行は興味深い例外だ。なぜなら tiny は一律に負けているわけではないからだ。安徽（5.42 対 5.76）、東北官話（4.21 対 4.28）、江蘇（11.44 対 12.15）、陝西（5.81 対 6.00）、山東（10.17 対 10.69）、雲南（11.28 対 11.53）では、より大きな兄弟モデルを上回り、客家語（24.08 対 16.51）、閩南語（14.15 対 12.84）、上海語（12.49 対 11.15）では大差で負けている。2.7B アクティブのモデルが、6.5B アクティブのモデルに対して15の方言行のうち6つで優位に立つことは、評価全体で最も好ましい点であり、それが平均によって隠されている表の中央に埋もれている。

触れておく価値のある欠落が2つある。どちらも検証可能であり、カードはそれを指摘していない。第一に、認識画像の5行にはtinyの値がまったくない——AISHELL-4、AliMeeting、AMIの話者ダイアリゼーション行と連結最小置換行はダッシュで印刷されている。tinyモデルが「誰がいつ話したか」で何をするかは未公開である。第二に、テキスト知能の画像には4列あるが、そのどれもtinyモデルではない。列はMing-3.0-audio-flash、Qwen3.8-Omni Flash、Qwen3.5-Omni Plus、Qwen3.5-Omni Flashである。カードの評価セクションには、以下の数値が両方のMingバリアントの結果を含むと書かれているが、それは2つの音声画像には当てはまり、テキストの画像には当てはまらない。tinyバックボーンが推論会話を保持できるか知りたいなら、inclusionAIはまだ教えてくれていない。

その一週間が実際にあなたにもたらしたもの

10月16日より前、このチェックポイントを試したい読者には、17.7 GBのダウンロード、8Kウィンドウの動画言語モデルを記述した設定ファイル、そしてカスタムコードを有効化せずにカスタムコードを読み込むよう指示するカードがありました。10月19日以降は、自身のモデリングファイルと一致する設定、変更されていない重みに対して検証できる128Kの主張、単一GPUを含む3つの名前付きデプロイメントプロファイル、トランスクリプト付きの音声パック、そしてモデルの用途を示すカードがあります。そのどれもが新しいモデルというわけではありません。そのすべてが、ディスク上のチェックポイントと、誰かが午後ひとつで評価できるチェックポイントとの違いなのです。

コストは、サイジングが隠している部分だ。ベンダー自身の表では、6.5Bアクティブのモデルから2.7Bアクティブのモデルに移ると、GPU台数を8分の1にできる代わりに、URO-Bench-Proで27.8ポイント、VoiceBenchで10ポイント、長尺音声のChainスコアで約5分の1を失う。これは文字起こしサービスにとっては妥当なトレードオフだが、1時間の音声をまたいで推論しなければならないものにとっては悪いトレードオフであり、ベンダーは両方の列を隣り合わせに掲載しているので、自分がどちらを構築しているのかを判断できる。

ルーターが真価を発揮する場面と、そうでない場面

OrcaRouterはMing-3.0-audio-tinyを提供していません。それは当社のカタログに含まれておらず、そのためのエンドポイントを提供することもできず、ここにある内容はそれを提供する申し出と解釈されるべきではありません。このようなチェックポイントを中心に構築されたパイプラインにおいて、ルーターが役立つのは、チェックポイントではない半分の部分です。音声システムの大部分はテキスト作業です。音声に何を尋ねるかを決めるプロンプト、タブ区切りの言語ラベルを構造化出力に変換するパーサー、文字起こしから書かれる要約、音声ファイルを2.7Bモデルに送るか126Bモデルに送るかを決める分類などです。それらは通常のテキスト呼び出しであり、単一のAPIを通じて0%のマークアップで200以上のモデルを利用できます — プロバイダーの定価がそのまま適用されるため、ベンダーが値下げすれば当日中に当社側でも反映されます — これは、ベンダー契約を積み重ねるより配線が簡単です。自動フェイルオーバーは、新たにドキュメント化されたモデルを、パイプラインの全経路をそれに賭けることなく、パイプラインの一部の背後に配置できるようにするものです。

境界は明言する価値がある。自分のGPUで実行する17.7 GBのチェックポイントはインフラであり、API呼び出しではない。ルーターは呼び出しをルーティングする。ルーターはオープンウェイトの音声モデルをホスト型モデルに変えるわけではないし、3回のダウンロードを本番環境の証拠に変えるわけでもない。

何を見るべきか

この状況を変える要素は3つあり、そのいずれも検証可能だ。第一に、独立したスコアである。アリーナや第三者の評価者がこのチェックポイントを掲載した瞬間、27.8ポイントの音声対話ギャップはベンダーの自己申告ではなくデータ点になる。それまでは、同じベンダーが小さいモデルが勝つ6つの方言の行も公開していることに留意すべきだ。第二に、LICENSEファイルがHugging Faceリポジトリ内に存在することだ。これによりMITはカード内のリンクから、調達プロセスが実際に読む成果物の中の事実へと変わる。第三に、非常に具体的なGitHubリポジトリである。現状、単一GPUという主張を現実にするデプロイプロファイルは、より大きなモデルにちなんで名付けられたリポジトリ内にあり、それは誰かが名前を変更するまでは問題ない。

それらのどれかが実現するまでの間、正確な説明は地味なものだ。9月3日と同じ重み、Thinkerの約18GB、チェックポイントではなく設定ファイルで登場した131,072トークンのウィンドウ、テキスト用なら1枚、音声用なら2枚のカードに収まる3つのサービングプロファイル、書類上はMIT、公開を見送った5つの参照行、そして説明対象の設定より3日新しいモデルカード。その週はモデルをより良くしたのではない。読み解けるようにしたのだ。誰も発表しなかったオープンウェイトのチェックポイントにとって、読み解けることこそが製品のすべてなのだ。