VoxCPM2: 月間90万ダウンロードなのに、Transformersはまだロードできない

Hugging Faceのメタデータでは、VoxCPM2のライブラリはvoxcpmとなっており、transformersではありません。この一つのフィールドが、現在のオープンソース音声の世界における奇妙なギャップを説明しています。OpenBMBの2Bパラメータのテキスト読み上げモデルは、過去30日間で900,282回のダウンロードを記録し、25の公開ファインチューン、10の量子化、7つのアダプター、100以上のSpacesを生み出しましたが、それでもそのサイト上の他のほとんどすべてのモデルが読み込むライブラリでは読み込むことができません。これを修正するプルリクエストは2026年8月4日に作成され、本日時点でもまだオープンのままです。

そのギャップは、修正版がリリースされる前に理解しておく価値がある。なぜなら、それが今週このモデルを統合する際のコストと、来四半期に統合する際のコストの差を左右するからだ。そしてその背後には、さらに興味深い問いがある。それは、VoxCPM2は実際、各種報道が示すほど先を行っているのかどうかというものだ。以下はすべて、次の3つの一次情報源から読み取った内容だ。すなわち、openbmb/VoxCPM2のモデルカードとリポジトリメタデータ、OpenBMB/VoxCPM GitHub README、そしてVoxCPM2テクニカルレポート(arXiv:2606.06928、2026年6月5日投稿)である。本記事のベンチマーク数値はすべてOpenBMB自身によるものであり、OpenBMBが実行したものだ。また——論文自体が主要比較表について述べている通り——表中の競合数値は、条件を合わせて再実行されたものではなく、他の論文からコピーされたものだ。我々が調べた限り、独立した研究室による再現結果の発表は一切ない。

スペックシートを1画面で

VoxCPM2は、VoxCPMシリーズ第3世代として2026年4月にリリースされました（Hugging Faceリポジトリは4月3日に作成され、4月16日に最終更新）。直接の前世代と比較すると：

• サイズ — VoxCPM1.5の0.8BおよびVoxCPM-0.5Bの0.6Bバックボーンと比較した2Bパラメータ。

• 言語 — 30言語と9つの中国方言、以前の両バージョンでは中国語と英語のみ。

• オーディオ — 16 kHzの参照信号を受け入れ、48 kHzを出力します。一方、VoxCPM1.5は44.1 kHzの対称的な入出力です。

• Backbone — テキスト意味論言語モデルとしてMiniCPM-4-1B（28層、幅2048）を採用。MiniCPM-4-0.5B（24層、幅1024）からアップグレード。

• シーケンス予算 — 言語モデル側のトークンレート6.25 Hzでの8192トークンで、1コンテキストでおよそ20分の音声に相当します。

• 1秒の音声のコスト — RTX 4090 1枚上、約8GBのVRAMで、素のPyTorchではリアルタイムファクター0.30、Nano-vLLMでは0.13です。VoxCPM1.5は0.8Bおよび6GBで0.15を達成しました。

• ライセンス — 重み、ファインチューニングコード、および推論ツールにはApache-2.0。アクセス制限なし、許容利用ポリシーの追加条項なし、商用利用可。

• トレーニングデータ — 多言語音声の「200万時間以上」だが、コーパス名の記載も来歴の明示もない。

RTFの行は逆方向に進むため、2回読んでください。VoxCPM2は、置き換え対象である0.8Bモデルと比較して、生成音声1秒あたりの処理速度がおよそ2倍遅く、VRAMが3分の1多く必要です。2Bモデルはスループットを向上させませんでした。得られたのは言語対応と制御性であり、その代償としてレイテンシが課されました。リアルタイムエージェントを運用しているなら、このトレードオフが最初に評価すべきポイントです。

PR #47756 が実際に変更する内容

今日、VoxCPM2 を実行するということは、OpenBMB 独自のパッケージをインストールすることを意味します — pip install voxcpm、Python 3.10〜3.12、PyTorch 2.5 以降、CUDA 12 以降 — そして、モデルをロードするには、VoxCPM.from_pretrained という、Transformers API とは何の関係もない呼び出しを使用します。その決定から先はすべて独自実装です。バッチ処理も、サービング用のグルーコードも、5つの生成モードの処理も、すべて自前です。

進行中の作業がそれを変えることになる。イシュー #47695「Add native support for OpenBMB VoxCPM2」は7月31日に提出された。PR #47756「support for VoxCPM2」は8月4日に続いて提出され、最終更新は8月5日である。このPRには「New model」ラベルが付けられており、モジュール式の設定とモデリング実装、カスタムトークナイザーとプロセッサー、ストリーミング対応のAudioVAEエンコードおよびデコード、参照音声コンディショニング、プロンプト音声の継続、自動クラス登録、テキストから波形へのパイプラインエントリが追加され、64件のモデルテストが成功したと報告されている。このPRはMiniCPM4自体を追加するPR #47736に依存している。テキストバックボーンが先にマージされなければ、それをラップする音声モデルはマージできない。

重みに値する詳細が2つあり、どちらも楽観論に反します。第一に、3つの項目すべて — issueと両方のpull request — は、OpenBMBでもHugging Faceのメンテナーでもなく、同じ個人のコミュニティコントリビューターによって開かれました。この背後にはベンダーの確約がなく、したがって計画の基準にできるタイムラインもありません。第二に、新しいモダリティに触れる203のコミットからなる2つのPRのスタックは、迅速なレビューを受けられるものではありません。Transformersの新モデルPRは、通常、メンテナーとの往復に数週間を要します。そして、このPRにはこれまでのところ4件のコメントが付いているだけです。

実際的に言えば、ネイティブのTransformersクラスがあなたのアーキテクチャの要となる場合——なぜなら、あなたが標準化しているのはAutoModelであるか、またはあなたの推論層がTransformersにしか対応していないからです——その場合、VoxCPM2はまだあなたには使えず、提供時期も未定です。もしあなたがvoxcpmパッケージ内で運用できるなら、モデルは今日すでに完全に使用可能であり、エコシステムはこの状態を許容できると明確に示しています。ネイティブサポートがまったく存在しないまま、900,282回のダウンロードが発生しました。また、ほとんどの報道が見落としている中間の道もあります。OpenBMBは、OpenAI互換の/v1/audio/speechエンドポイントを公開するvLLM-Omni統合を提供しています。さらに、Pythonへの依存がまったくなく、CPU、Metal、CUDA、Vulkanで動作するGGUFウェイトを備えたllama.cpp-omniビルドもあります。Transformersから実際に必要だったものが、クラスそのものではなく標準的なサービングインターフェースであるなら、それはすでに存在します。

"Tokenizer-free"は非量子化を意味するものではない

このモデルに関するすべての見出しに登場するフレーズは、最も誤読されがちな言葉だ。VoxCPM2には外部の離散オーディオコーデックが存在しない——CosyVoiceやMoshiの系統にあるような、言語モデルと波形の間に学習された音声トークンの語彙が介在する仕組みはないのだ。それがこの主張であり、そしてそれは真実である。

モデル内部には依然として量子化が存在します。バックボーンは、Finite Scalar Quantization（FSQ）に基づく微分可能な半離散ボトルネックを実行し、論文はその役割について明確に述べています。テキスト意味論的言語モデルが隠れ状態を生成し、FSQがそれらを次元ごとにスカラー量子化して「意味的スケルトン」へと変換します。残差音響言語モデルがFSQが捨て去った微細な詳細を復元し、局所拡散トランスフォーマーがフローマッチングによって両方の条件付けストリームを次の連続潜在パッチへと変換します。LocEnc、TSLM、RALM、LocDiTという略称で示される4つの段階は、まさにこの連鎖です。

実際に重要な区別は「量子化されているかどうか」ではない。重要なのは、ボトルネックが周囲のすべてのものと一緒にエンドツーエンドで訓練されることであり、独自の損失を持つ別個のコーデックとして事前に固定されることではない。それこそが、言語モデルがコーデックが忠実にデコードできないトークンを予測することを学習するという、よくある失敗モードを排除するのである。VoxCPM2はそのFSQボトルネックを256次元から512次元に拡張し、残差モデルに供給していた従来の要素ごとの和を、学習可能な連結射影に置き換えた。これは小さな変更であり、報告書の中で、ベンチマークの差異ではなく明示されたメカニズムによって裏付けられている数少ない変更の一つである。

48 kHzの出力は部分的に作り出されたものであり、それが設計です。

「48 kHzスタジオ品質出力」は、このモデルで最も引用される仕様であると同時に、最も広く誤解されている仕様でもある。AudioVAE V2は非対称で、エンコーダーは16 kHzで動作し、デコーダーは48 kHzで再構築する。論文ではこれを「暗黙の超解像」と呼んでいるが、これは実態を正直に言い表した名前だ。

結果を追ってみよう。16 kHzエンコーダには8 kHzのナイキスト上限があるため、参照音声の8 kHzより上の帯域は決してモデルに届かない。出力の上位2オクターブに含まれるエネルギー——声の空気感、歯擦音、シンバルのエッジの輝き——はすべて、クローンした話者から引き継がれたものではなく、デコーダがもっともらしい事前分布から生成したものだ。ほとんどのナレーションやエージェント用途では、これは目立たないか、むしろ改善となる。なぜなら、優れた学習済み事前分布は、ハードな8 kHzシェルフより勝るからだ。特定の録音音声への忠実度が仕事の要である人にとっては、これは設計の前提として向き合うべき事実であり、ラップトップのスピーカーでの試聴では決して明らかにならない類のものでもある。

本論文の正当化は、このレポートの中で最も説得力のある工学的論拠であり、マーケティングではないため改めて述べる価値がある。エンコーダを16kHzに保つことで、OpenBMBは元のVoxCPM 16kHzトレーニングコーパスを丸ごと再利用でき、異なるサンプルレートで録音されたソース間の潜在的なミスマッチを排除し、より高い入力レートが自己回帰ループに強いるであろうシーケンス長の爆発を回避できる。デコーダのみを引き上げることで、モデルの高コストな部分にコストをかけることなく出力の忠実度を得られる。これは意図的になされた良いトレードオフである。また、VoxCPM1.5のユーザーは44.1kHzのエンコーダから16kHzのエンコーダに移行することになる——出力側のアップグレードの中に組み込まれた入力側のダウングレードである。OpenBMB自身の再構築テーブルはその形状を示している：VoxCPM1.5のコーデックは、3世代の中で最も優れたフルバンドのメル距離を記録しており、AudioVAE V2の1.335に対して1.139である。これは、1つまで再構築するのではなく、ネイティブに高いサンプルレートで動作するためである。

OpenBMBのスコアボードをOpenBMBが書いた通りに読む

競争力はあるが、一番ではない

標準的なゼロショット音声クローニングのベンチマークであるSeed-TTS-Evalにおいて、VoxCPM2は英語セットで単語誤り率1.84%、話者類似度75.3%を報告している。中国語では文字誤り率0.97%、類似度79.5%、難しい中国語サブセットではCER 8.13%、類似度75.3%である。論文自身はこれを「competitive」と表現しており、表は、流布しているより強い表現ではなく、この言葉を裏付けている。

同じ表のオープンソースシステムの中で、Fish Audio S2は3つのサブセットすべてでより良いエラー率を記録している（0.99 / 0.54 / 5.99）。Qwen3-TTSは英語WERで1.23とVoxCPM2を上回る。また、LongCat-Audio-DiTは6つのセルのうち5つでVoxCPM2を完全に凌駕している。英語ではWER 1.50と類似度78.6、中国語では類似度81.8、困難な中国語ではCER 6.04と類似度79.7である。VoxCPM2が際立っているのはそのバランスだ。類似度でトップクラスに近く、了解度でも十分な水準を同時に達成しているシステムはごく少数であり、さらにそのリストの中で自然言語による音声デザインも備えているのはVoxCPM2だけである。しかし、このシステム自身の主要な表が示しているのは「最先端」ではない。正直に言えば、これは強力な汎用システムであり、ベンチマークのリーダーではない。

パラメータを3.3倍にしても、理解可能性はほとんど向上しなかった。

その表で最も有用な行は、誰も引用しない行である。2025年9月の初代0.6BモデルであるVoxCPM-0.5Bは、英語WER 1.85%、中国語CER 0.93%を記録する。2BのVoxCPM2は1.84%と0.97%を記録する。英語ではノイズの範囲内であり、中国語ではわずかに劣る。

追加パラメータが実際に何をもたらしたかは、類似度の列にしか現れていません。英語のSIMは72.9から75.3へ、中国語は77.2から79.5へ上昇しました。2Bが追加で手に入れた他のものは、すべてこのベンチマークの対象外です。28言語の追加、テキスト記述からの音声デザイン、スタイル制御可能なクローニング、48kHz出力。これは大きな成果であり、正直に言ってアップグレードの根拠となります。しかし、あなたのワークロードが英語または中国語のクローニングで、エラー率で選んでいるのであれば、VoxCPM2は0.6Bモデルがすでに提供していたものを何も上回っておらず、重みは3倍、レイテンシは2倍です。興味深いことに、VoxCPM1.5はこのベンチマークでは3つの中で最悪（2.12 / 1.18）で、ファミリーの進化ははしごというより、3つの異なる製品のように見えます。

1つのモデル、2つの評価、その差は一桁

ここで注意が必要だ。この報告書にある2つの多言語の結果は激しく食い違っており、その両方がこの問題を解決するかのように引用されているからだ。

見出しとなる数字は、30言語全体で平均エラー率1.68%だ。これはOpenBMBが自ら構築したテストセット（各言語500の発話）に基づいており、Gemini 3.1 Flash Liteを認識器として採点した結果である。このテストセットにおいて、VoxCPM2は英語0.42、中国語0.92、ヒンディー語0.79、アラビア語1.23という結果を出している。

このレポートでは、サードパーティ製の24言語セットである MiniMax-MLS-Test も実行され、Whisper-large-v3 でスコアリングされています。同じモデルです。そこで VoxCPM2 は、公式にサポートしている言語において、ヒンディー語 19.70、アラビア語 13.05 を記録しています。これは、同社自身のベンチマークが示す値よりもそれぞれ25倍、10倍悪い結果です。また、その列には、広東語 38.58、チェコ語 24.13、ルーマニア語 21.58、ウクライナ語 6.32 も含まれています。

この大部分を整合させる三つの要素があり、それらを区別して考察する価値がある。広く共有されているこの物語の解釈は、それらを誤って捉えているからだ：

• チェコ語、ルーマニア語、ウクライナ語はサポート対象言語ではありません。 リポジトリ自身の言語タグを確認してください。30のコードがあり、そのどれもcs、ro、ukではありません。24%のチェコ語WERについてVoxCPM2を批判するのは、それが決して主張していない言語について批判していることになります。広東語はおそらく「9つの中国方言」に該当しますが、その列のすべてのシステムは広東語で30%を超えており、これはモデルではなく認識器の問題を示しています。

• アラビア語とヒンディー語がサポートされており、これこそが真の発見です。 これらはOpenBMBがカバレッジを主張する2つの言語であり、その2つの評価結果は一桁異なります。論文自身の説明では、これらの言語はトレーニングコーパス内で「データ量が比較的限られている」こと、そして「WERの高さの一部は、認識器の精度が限られていることに起因する可能性がある」とされています。これはもっともな仮説ではありますが、検証されていません。アラビア語またはヒンディー語の音声を扱う場合、このモデルの公表範囲は0.79%から19.70%であり、どちらの端も独立に検証されていません。独自の測定に1日を充ててください。どちらの数値も当てにしないでください。

• 指標は同じ単位ですらありません。ヒンディー語は、内部セットでは文字誤り率、MiniMax-MLSでは単語誤り率で評価されています。これらは比較可能な量ではなく、25倍の差が単純な批判材料ではないもう一つの理由であり—そして1.68%の平均が同等のスコアとして読まれるべきではないもう一つの理由でもあります。

同じ注意喚起は、このモデルの報道で最も数値的な役割を果たしている主張、すなわちVoxCPM2が話者類似性でElevenLabsを上回り、英語で85.4%対61.3%、24言語中22言語で勝利したという主張にも当てはまる。それは確かに表が示している内容だ。また、その表は論文が以前に報告された結果から部分的に組み立てたものであり、ElevenLabsの明瞭度の欄には、タイ語で73.94%のWER、ベトナム語で73.42%、中国語で16.03%が含まれている。それらは機能している商用製品の数値ではない。スコアリングまたは設定の不一致を示す特徴である。ある列が壊れている表は、その結果が読んでいるモデルに好意的だからといって、別の列で信頼できるようにはならない。

1つの基盤から生まれる5つのモード — そして、あなたの数字を動かすレシピ

このアーキテクチャで最も明快なアイデアは、VoxCPM2が各機能のために個別のモデルやヘッドを持たないことです。5つのモードはすべて同じパラメータを共有し、入力シーケンスの配列が異なるだけです。そのため、通常は複数のモデル群を必要とする処理を、単一の2Bチェックポイントでカバーできるのです：

• 基本TTS — テキスト入力、音声出力。

• 音声デザイン — 括弧書きの説明は単にテキストの前に付加されるだけで、「(疲れた中年男性、しわがれ声、ゆっくり話す)」のような説明も台詞本体も、追加モジュールなしで同じ言語モデルを通過する。参照音声は一切不要。

• 参照クローニング — 孤立した参照クリップが話者同一性を条件付け、トランスクリプトは不要である。

• 制御可能なクローニング — 参照クリップとスタイルの説明を組み合わせることで、音声をクローンして、慌てた口調や楽しげな口調に調整できます。

• 継続クローニングトランスクリプトとペアになった参照クリップを、モデルが継続するオーディオプレフィックスとして扱う、最も忠実度の高いモード。

報告書に埋もれた形で、ほとんどの記事が触れないノブがあります。そしてそれが、結果を最も変える可能性が高いものです。2つのコンディショニング経路（孤立参照と継続プレフィックス）は、個別にも一緒にも使うことができ、互いにトレードオフの関係にあります。OpenBMB自身のアブレーションでは、両方を一緒に使うと、すべてのサブセットで最高の話者類似度が得られます。継続プレフィックスを落として、孤立参照のみを渡すと、難しい中国語テキストで最も高い了解性が得られ、CERは7.44%に対して6.85%となり、類似度は約5ポイント犠牲になります。論文の説明はもっともです：韻律を固定する時間的な音声プレフィックスがない場合、モデルは難しいテキストを乗り切る発話を選択する自由がより大きくなるからです。

つまり、デフォルトは上限ではなく選択です。ボイスマッチングの作業では両方の経路が必要です。難しいテキストや変わったテキストでは、参照専用が必要です。正直に言って、厄介な点が一つあります。そのアブレーションテーブルの絶対値は、論文が全体を通じて使用したと述べているレシピの主要テーブルと一致しません。プレプリントでは、これは何か悪意のあるものというより、おそらく記帳ミスでしょう。しかし、それはここにあるすべての数値を、引用する値としてではなく、テストすべき方向性として扱うべき3番目の理由でもあります。

ボイスデザイン：自然であることよりも従順であること

音声デザインは、今回のリリースを漸進的なものではなく興味深いものにする機能であり、ベンダー自身の数字が現実のトレードオフを最も如実に示している点でもある。

InstructTTSEval において、VoxCPM2 は英語の音響パラメータ指定で84.2、記述スタイル指示で83.2、ロールプレイで71.4を獲得しています。この最後の値は表の中で最も高く、Qwen3-TTS-1.7B-VD の68.4 や Gemini-TTS-Pro の67.2 を上回ります。中国語では弱く、順位は逆転します。85.2 / 71.5 / 60.8 に対し、Gemini-TTS-Pro は89.0 / 90.1 / 75.5 です。したがって、主張できる最も強い点は、VoxCPM2 が英語のロールプレイでトップであり、それ以外の指示追従のほぼすべての分野ではクローズドなフロンティアシステムに劣るというものです。

報告書によれば、50名のリスナーによるランダム化・二重盲検の人間聴取パネルが、これをさらに明確にする。制御可能な生成では、VoxCPM2は指示追従で4.50（Qwen3-TTS-VDの4.41に対して）を獲得し、自然性では4.48（Qwen3-TTS-VDの4.61に対して）と劣る。標準的なゼロショットクローニングでは、話者類似度で勝利し（4.74対4.69）、自然性では同等かやや劣る（4.78対Qwen3-TTSの4.80、信頼区間は重なる）。

このパターンは十分一貫しているため、計画を立てやすい。VoxCPM2は指示どおりに実行し、その際の音声は人間らしさがやや劣る。一方、Qwen3-TTSは音声がやや自然で、指示への追従がやや緩い。どちらが適切かは、製品の価値が正確な制御にあるのか、それとも努力不要の出力にあるのかに完全に依存する。OpenBMBはこの帰結を自社の制限事項として明記しているが、これはベンダーが通常省略する類のものだ。つまり、音声デザインと制御可能なクローニングは「実行ごとに結果が異なる可能性があり」、望む音声を得るには数回の試行が必要になることがある。パイプラインにリトライを組み込み、音声が重要なら人間による聴取チェックを追加すべきだ。

運用コスト、そしてレンタルが適切な選択となる場合

どこにもホストされたVoxCPM2はありません。ハグフェイス自身のサイドバーはそれを明確に述べています。「このモデルはどの推論プロバイダーによってもデプロイされていません」— そしてそれは私たちも含みます：OrcaRouterはVoxCPM2を提供していません。そして、どんなに望んでも、推論パートナーがいない2B TTSモデルは、あなたがホストする重みか、または何もないかのどちらかであるという事実は変わりません。

これにより、コストの問題はGPUの問題になり、計算は明確です。Nano-vLLMのリアルタイムファクターがRTX 4090 1枚で0.13の場合、1GPU時間あたり約7.7時間分の音声が生成されるため、音声1時間あたりのコストは24GBカード1枚の時間単価を約7.7で割った値になります。一方、素のPyTorchでRTF 0.30の場合、GPU1時間あたりの音声は約3.3時間に低下します。どちらの数値もOpenBMBのもので、彼らのハードウェアと彼らのテキストで測定されており、あなたの環境では両方とも変動します。バッチサイズ、テキストの難易度、そして品質ゲートが強制するリトライ回数は、すべてRTF値には含まれない倍率です。人々が忘れがちなのはリトライ率です。ベンダーが目標の音声に到達するには数回の試行が必要かもしれないと言うモデルは、そのRTFが示すコストにはなりません。

現時点で皆さんが求める比較は、レンタルAPIとの比較でしょう。正直な答えを言えば、この二者はきれいに換算できません。openai/tts-1-hdは、入出力とも100万トークンあたり30.00ドルで課金されます。これはOrcaRouter上でプロバイダーの定価をそのまま素通しした金額であり、当社はマークアップ0%なので、モデルページに表示されている数字はOpenAIが請求する数字そのものです。しかし、トークンは秒ではありません。また、公表されているレートで両者を確実に換算してスプレッドシートに組み込めるようなものはありません。セルフホストのオープンウェイトTTSモデルとトークン課金APIの間の、1時間あたりのきれいな比較を示す人がいるなら、その人は自分が明かしていない前提を置いています。

語る価値があるのは、アーキテクチャ上で線引きがどこに引かれるかという点だ。VoxCPM2のセルフホスティングが理にかなうのは、特定のクローン音声が必要な場合、音声量がGPUを稼働させ続けるのに十分安定している場合、データを自社インフラの外に出せない場合、またはLoRAによるファインチューニングを意図している場合だ。しかもこれは5〜10分のターゲット音声で対応でき、実に安価である。レンタルが理にかなうのは、ボリュームがスパイク状に変動する場合、GPUを運用する人材を確保できない場合、または音声が代替可能な場合だ。実際の音声プロダクトのほとんどは、単一のシステムではなく2つのシステムで成り立っている。合成レイヤーと、いわば頭脳として推論を担う言語モデルだ。推論側は、プロバイダー間の自動フェイルオーバーを備えた1つのキーの背後に置く価値がある部分だ。そうすればモデル交換は調達サイクルではなく文字列の変更で済む。OrcaRouterは、200以上のモデルにわたって、まさにその形態のために存在する。合成側は、自分が所有しファインチューニングする特定の音声であるなら、自社のハードウェア上に置くべきだ。VoxCPM2はまさにその2番目のカテゴリーに位置づけられる。そして誰もそれを提供していないという事実は、見落としの結果ではなく、その性質によるものだ。

OpenBMBが期待するなと言うこと

制限事項のセクションは、これほどの勢いのあるリリースにしては異例なほど率直であり、真剣に受け止めるのに十分なほど簡潔だ：

• クローニング品質は悪用面です。 カードには次のように直接書かれています。モデルはなりすましや詐欺に十分なほどリアルな音声を生成するため、AI生成オーディオにはラベル付けが必要です。Apache-2.0はこれに対して一切の制限を課していません。競合するいくつかのオープンウェイト音声モデルのライセンスには利用許容条項があるのに対し、ここには隠れ蓑にできるそのような条項は存在しません。同意と開示に関するポリシーは、あなた自身が策定するものです。

• 実行間のばらつきは予想されるものであり、2つのコントロール機能では報告すべきバグではありません。

• 30言語が実際の境界です。それ以外のものは動作する可能性もありますが、未テストであり、微調整が必要になることを想定してください。

• スタイル制御の一貫性はまだ開発中であると説明されています。それを構築した人々によって、

そして、このカードが挙げていないギャップ：トレーニングコーパスの開示がまったくない。つまり、重みに対するApache-2.0ライセンスはコードの問題を解決するだけで、データの出所については何も解決しない。この記事のいかなる数値についても、独立した評価はない。ミリ秒単位のレイテンシーの公表もない。RTFはスループット比率であり、音声エージェントは初回音声までの時間（time-to-first-audio）で生死が決まるが、それはレポートのどこにも登場しない。

モデルカードが解決しない3つの疑問

VoxCPM1.5 または VoxCPM-0.5B から移行すべきですか？

新しい機能に限り、しかも測定した上でのみ。中国語と英語以外の言語、音声デザイン、またはスタイル制御可能なクローニングが必要なら、アップグレードこそが本題であり、ファミリー内に代替手段はありません。現在英語または中国語のクローニングを実行していて満足しているなら、その主張は一見して弱いものです。同じベンチマークではVoxCPM-0.5Bがエラー率でVoxCPM2に匹敵しており、話者類似度の約2.4ポイントのために、2倍のレイテンシと3分の1多いVRAMを支払うことになるからです。そして、見落としがちな移行の詳細もあります。VoxCPM1.5に44.1kHzの参照音声を入力していた場合、VoxCPM2のエンコーダーは16kHzを受け付けるため、参照パイプラインが変わり、ソース素材の高域は重要ではなくなります。

これで実際に商用の音声製品をリリースできるのでしょうか？

法的に見て、このライセンスはほぼ最も寛容な部類だ。{{1}}Apache-2.0、ゲートなし、使用制限なし、商用利用は明示的に許可され、重みとファインチューニングコードの両方がカバーされている{{/1}}。未解決の疑問はライセンスの文面ではなく、その背後に欠けているものだ。{{2}}OpenBMBはトレーニングコーパスを明示しておらず、つまり200万時間の中に誰の声が含まれているのかを誰も教えてくれない{{/2}}。{{3}}目玉機能が特定の人物の声を再現することであるモデルにとって、これはモデルカードではなく、自分自身の法務担当者に問うべき問題だ。そして、これは現在すべてのオープンウェイト音声モデルが避けて通っている問題でもある{{/3}}。実際問題として、より厄介な障害は運用面にある。{{4}}ネイティブのTransformersクラスがまだなく、どこにもホストされたエンドポイントがなく、制御機能には実行ごとのばらつきがあり、さらに会話型のものを構築するなら初回音声出力までの時間の数値もない{{/4}}。

有料TTSベンダーを置き換えるのに十分ですか？

英語と中国語のナレーション、収録済みコンテンツ、特定の音声を制御してバッチ処理できるあらゆるワークロードについては、利用可能な証拠に基づく限り「はい」です。ライセンスにより、試すコストはほぼゼロです。リアルタイムの会話型エージェントについては、導入前に自分で初回音声までの時間（time-to-first-audio）を測定してください。誰も公表しておらず、RTFではわからないからです。アラビア語、ヒンディー語、その他ロングテールの言語については、ベンダー自身の2つの評価が一桁違っています。したがって、どの数値を目にしたかにかかわらず、そのモデルは未実証と見なすべきです。また、誤発音が単なる迷惑ではなくビジネス上の事故になる用途では、VoxCPM2は自社の比較表の中でも明瞭性でトップではありません。Fish Audio S2とLongCat-Audio-DiTがその点では先行しており、こちらもオープンウェイトです。

何を見るべきか

二つのことが、異なる時間軸で進んでいます。近い方はPR #47756と、その下にあるMiniCPM4のPRです。それらがマージされれば、VoxCPM2はAutoModelの呼び出しになり、Transformersで標準化しているすべての人にとって統合コストは一夜にしてほぼゼロまで下がります。すでに毎月900,282件のダウンロードが困難な方法で行われていることを考えると、これは意義深い解放です。もし停滞すれば、それらのチームへの答えは「OpenBMBのパッケージかvLLM-Omniエンドポイントを使う」というもののままであり、両方のPRを担当しているコミュニティ貢献者にはそれを変える力がありません。

遅い方は、OpenBMBの外部の誰かが数値を公開するかどうかだ。リリースから4ヶ月、月間ダウンロード90万回、25件のファインチューン、100以上のSpacesが構築されているというのに、流通しているすべての性能数値は、いまだにモデルを訓練した人々が書いた1本の技術レポートに遡る。これはOpenBMBへの批判ではない。彼らはほとんどのチームよりも徹底的かつ誠実に自らの仕事を文書化している。レポートは、認識器の選択、データ量の弱点、そして自身の不安定性に至るまで自ら進んで開示している。これは、それ以外の私たちへの批判だ。オープンソース音声コミュニティの誰かが今月公開できる最も価値のある成果は、同一条件下でVoxCPM2、Qwen3-TTS、Fish Audio S2、LongCat-Audio-DiTを実行し、WhisperスコアによるSeed-TTS-EvalとMiniMax-MLSで評価したものだ。それが存在するまで、VoxCPM2に関する公正な要約は次の通りだ。すなわち、これまでに誰かがリリースした中でチェックポイントあたり最も高性能なオープンウェイト音声モデルであり、最も正確なものではない。そして、その文の両半分はベンダーの言葉に依拠している。