Ming-3.0-asr-tiny 対 Moonshine 250M：一方のモデルは決して聞くのをやめず、もう一方はあなたが話し終えるまで決して始まらない

Moonshine 250Mは、その系列の最上位を指すコミュニティの略称で、リポジトリ名がmoonshine-streaming-mediumで、safetensors索引が実際には265,898,112パラメータに達するチェックポイントです。Moonshine組織内のどのファイルも250Mという名前ではありません。そのモデルは、スライディングウィンドウ式エンコーダーと自己回帰デコーダーを備えた英語のストリーミング認識器で、ラップトップやスマートフォン向けに作られ、2026年1月にMITライセンスで公開されました。Ming-3.0-asr-tinyは88.7億パラメータの中国語・英語認識器で、その重みは2026年10月14日に予告なしでHugging Faceに登場し、Whisper型エンコーダーと128エキスパートのMixture-of-Expertsデコーダーを中心に構築され、クリップ全体を一度に読み取るように設計されています。両者は同じ市場の競合ではありません。両者は、認識器がいつ話してよいかという問いに対する2つの異なる答えです。本稿がMoonshine 250Mと呼ぶチェックポイントは、次の場所に文書化されています：Moonshine Streaming Mediumモデルカード。そこではsafetensors索引が、カードの245Mという表記に対して265,898,112パラメータを報告しています。このようなリリースの背後にある、文書化されたAI障害やエージェントインシデントは、次に収集されています：OrcaRouter AIインシデントアーカイブ。そこでは各項目に独自の情報源、重大度、信頼度グレード、異議フラグが付されています。

その問いは有用な枠組みであり、精度表よりもすっきりした判断を導き出します。Moonshine 250M は音声がまだ到着している間に、約0.1〜1 TOPSで単語を出力します。Ming-3.0-asr-tiny は完全なファイルを渡すまで何も出力せず、その後、タイムスタンプがまったくない文字起こしを出力します。

それぞれが実際に何をするために作られているのか

Moonshineのアーキテクチャは、通常のストリーミングにおける妥協を意図的に逆転させたものだ。エンコーダーは、有界なローカルアテンションを持ち、位置埋め込みを一切使わないスライディングウィンドウ型トランスフォーマーであり、カードではこれをエルゴード的と呼んでいる。最初の2層と最後の2層では (16, 4)、中間層では (16, 0) のウィンドウで、これにより約80ミリ秒の先読みが得られる。位置情報はエンコーダーの後にアダプターによって注入され、RoPEを用いた標準的な因果デコーダーに供給される。音声フロントエンドはメルスペクトログラムではなく、単純な時間領域演算を用いて50 Hzで動作する。

デコーダーは自己回帰型であり、そのコストについてMoonshineはこう述べている。最初のトークンまでの時間が短くても、全出力のレイテンシは文字起こしの長さに応じて増大する。それがこの設計の正直な限界であり、ストリーミングに関する主張を比較する際に心に留めておくべき一文だ。ストリーミングとは最初の単語が素早く現れることを意味するが、最後の単語が比例して素早く現れることを意味するわけではない。

Mingはストリーミングを行わず、そのカードにも明記されています。同梱の例はストリーミング入力を受け付けません。長い音声は8,192ポジションのコンテキストに対して引数でチャンク分割できますが、ファイルをチャンク分割することはライブフィードを消費することと同じではありません。また、設定の出力形式フィールドはplainに設定されています。Mingが代わりに行うのはコンテキストの保持です。ホットワードや直前の対話ターンを文字起こしプロンプトの一部として受け付け、湖南、閩南、広東、川渝、上海、安徽、東北、河南、湖北、江蘇、客家、陝西、山東、天津、雲南の15種類の中国方言テストセットで評価されています。Moonshineは英語専用で、こうした機能は一切ありません。

2つのパラメータ数と、それらが異なる理由

じっくり検討する価値のある細部だ。というのも、それは比較表を静かに台無しにする類のものだからである。Moonshine自身のモデルカードでは、Mediumは2億4500万パラメータ、エンコーダ14層とデコーダ14層、768次元のエンコーダと640次元のデコーダと記載されている。同じリポジトリのsafetensorsインデックスは265,898,112と報告している。差は約2100万、およそ8.5%であり、丸め誤差ではない。バックボーンを数えるか、それに付随して出荷されるすべてを数えるかの違いなのだ。

Ming はより大きなサイズでも同じ問題を抱えています。そのインデックスは 8,865,800,992 個のパラメータを報告していますが、チャートではモデルを 8.6B-A2Bと表記しています。これは合計 86 億で、トークンあたり約 20 億がアクティブであることを示す省略表記です。このラベルはインデックスの値より約 2 億 7,000 万少なくなっています。

• 総パラメータ数 — Ming-3.0-asr-tiny 8.87B（インデックス）対 Moonshine 250M 266M（インデックス）。ベンダー表記は 8.6B と 245M。

• トークンあたりのアクティブ — Mingは128個のエキスパートのうち8個が各ステップでルーティングされるため約2Bです。Moonshineは密なため、全体で266Mです。

• Encoder — 32層、1,280次元、20ヘッド、128メルビン、Whisper形状の構成。対して、50 Hzフロントエンド上で768次元の14層エルゴディック・スライディングウィンドウ・トランスフォーマー。

• デコーダー — 24層、128エキスパート、自己回帰；対して14層、密、自己回帰。

• レイテンシモデル — クリップ全体を入力して文字起こしを出力、ストリーミングなし。対して約80 msの先読みと、音声がまだ到着している間に最初のトークンを出力。

• 出力 — プレーンな文字起こしテキストで、タイムスタンプも話者分離もなし；これに対し、カード内にタイムスタンプ経路も持たない自己回帰デコーダーからの文字起こしテキスト。

• 言語 — 中国語と英語に加え、15種類の中国方言テストセット。英語のみの場合と比較。

• ライセンス — 両方ともMITライセンスで、Mingのリポジトリには同梱されたApache-2.0ヘッダーが保持されています。

精度については、ただし同じ音声でテストされたことはないという注意点があります

Moonshineのカードには、Mediumの8つの英語データセットにおける平均WERが6.65と報告されている：AMIで10.68、Earnings-22で11.90、GigaSpeechで9.46、LibriSpeech test-cleanで2.08、test-otherで5.00、SPGISpeechで2.58、TED-LIUMで2.99、VoxPopuliで8.54。約30万時間の音声で学習している。

Mingは、英語の公開データセット——LibriSpeech cleanおよびother、Multilingual LibriSpeech、FLEURS English、Common Voice 15 English、VoxPopuli——で平均WER 3.99を報告しており、中国語のデータセットでは平均CER 3.55を報告している。非公開の量のデータで学習されている。

3.99を6.65の隣に置いて、Mingの方が英語でより高精度だと断言したくなる。だが、そうすべきではない。5つの英語セットのうち2つは異なり、集計方法も異なり、MoonshineのカードはMingの5つにきれいに対応するセット別内訳を公開しておらず、どちらのベンダーも相手を実行していない。両方が報告している唯一のセット——VoxPopuli——について、Mingは本文でセット別の英語数値をまったく公開しておらず、平均値だけを出している。したがって、その唯一の重なりさえカードからは比較できない。ここにあるすべての数値はベンダー報告によるもので、再現されていない。

共有テストセットがなくても言えるのは構造的なことだ。Moonshineは2億6600万パラメータの密モデルで、30万時間の英語で学習されている。Mingは88億7000万パラメータの混合エキスパートモデルで、約20億がアクティブであり、内容を明示していないデータで学習され、方言の要素が強い中国語と英語で評価されている。アクティブパラメータが17倍あり、言語モデルの事前分布を持つモデルなら、難しい英語音声でより正確であるはずだし、そうでなければ驚きだろう。それはアーキテクチャからの予想であり、測定ではない。

デプロイの現実が分かれるところ

Ming が必要とするのは、CUDA GPU、Python 3.12、PyTorch 2.11.0、torchaudio 2.11.0、Transformers 5.12.1、fla-core 0.5.2 を備えた Linux マシンと、自身のモデリングコードをロードするための trust_remote_code=True です。重みは BF16 で約 17.7 GB、2 つのシャードに分かれています。特定のアダプターコミットに固定された SGLang のサービング経路があり、これはベンダーがこれをデスク上ではなく API の背後で実行することを想定している兆候です。

Moonshine 250Mは、1GB未満のメモリと約0.1～1 TOPSを目標としています。エッジデバイス向けのMoonshine Voiceフレームワーク経由、およびTransformers経由で動作し、カードには、Transformers経路では完全に効率的なストリーミングがまだ実装されていないと明記されています——flash-attentionのスライディングウィンドウ対応に依存しているためです。アーキテクチャがうたうストリーミング動作を求めるなら、それを実現するのはフレームワーク経路です。

リポジトリこそ、チェックポイントの系譜が実際に目に見える場所だ。Tiny、Small、Medium のファミリーにまたがる24個のタグに加え、本物のストリーミングを望むならカードが使うよう促しているフレームワークもある。それは Ming がまだ持っていないメンテナンスの話であり、この選択の実務的な半分なのだ。

それが二文で表した比較のすべてだ。一方のモデルはデバイス内部で忘れられるように設計され、もう一方はホットワードリストを添えてGPUから提供されるように設計されている。

中国語優先のチームが実際にすべきこと

もしあなたの製品が英語のライブキャプションや音声コマンドなら、Moonshine 250M は Ming にはまったくできない仕事をこなしており、精度の差が——実際にどれほどであれ——Ming がライブストリームを処理できないという事実ほどに問題となる可能性は低い。ストリーミングは、クリップ全体を読み込むアーキテクチャに後から追加する機能ではなく、エンコーダの特性である。

あなたの製品が中国語音声や地域方言を扱うもの、あるいは文字起こしが事後的に生成され固有名詞が重要なバッチパイプラインであるなら、この2つのうち問題に対処しているのはMingだけであり、しかもそれは公開から5日でダウンロード数が数十件のものです。正直な推奨は、自分の音声で比較評価を行い、文字誤り率ではなく固有表現の再現率で採点することです。なぜなら、それこそがMingが設計された軸だからです。

そうした比較評価を行うチームにとって、運用上の問題はモデルではなく配線部分にあります。2つのスタック、2つの依存関係セット、2つの認証情報セットがあり、ハーネスを構築しなければ同じトラフィックで両者を比較する方法がありません。OrcaRouter はどちらのモデルもホストしていません — Ming-3.0-asr-tiny と Moonshine 250M はセルフホスト型のオープンウェイトです — が、200以上のホスト型モデルを1つのAPIキーの背後にまとめ、自動フェイルオーバーを実現します。これにより、評価対象のホスト型ベースラインを、2つ目の契約を結ぶことなくセルフホストの候補の隣に並べられます。プロバイダーの定価は0%のマークアップでパススルーされます。これはトークンあたりのコストではなく、音声1時間あたりのコストを比較する際に重要な数値です。

注目すべき未解決の問い

{{1}}Mingのカード{{/1}}には、ホットワードはヒントであり保証ではないこと、出力は単語レベルのタイムスタンプや話者分離のないテキストであることが書かれている。{{2}}Moonshineのカード{{/2}}には、そのデコーダーは短い、またはノイズの多い区間で単語を幻覚し、フレーズを繰り返すことがあると書かれている。どちらも故障モードについて正直であり、これはほとんどのカードができている以上のことだ。そして両者は、同じ根底にある妥協を両端から説明している。流暢なテキストを生成する自己回帰デコーダーは、時として実際には言われていない流暢なテキストを生成するのだ。

この比較を決着させるのはベンチマークではなくユースケースだ。自分の音声の同じ20分間で両方を動かしてみよう——半分はライブ、半分はバッチ、半分は英語、半分は英語以外——そうすれば、判断はパラメータ数とはまったく関係なくなる。それまでは、この対決を正しく説明するなら、一方のモデルは継続的に聴くために作られ、もう一方は注意深く読むために作られている、そして小さいほうの名前は、実のところ2億6600万パラメータであるチェックポイントのマーケティング上の略称にすぎない。