Ming-3.0-TTSをローカル導入するなら0.5BとTiny、どちらを選ぶべきか

「Tiny」という名前なら、ローカルで手軽に動かせそうに思える。Ming-3.0-TTSではその直感は逆だ。まず試すべきなのは密な構成の0.5Bチェックポイントで、Tinyを選ぶのは複数話者のポッドキャスト生成が必要な場合に限られる。ただし、ハードウェアの根拠は限られている。InclusionAIが検証環境として示しているのはH800/H20であり、コンシューマー向けGPUでの最低要件は公開されていない。

環境を作る前にチェックポイントを決める

Ming-3.0-TTSには、バックボーン、依存パッケージ、起動方法が異なる2種類のチェックポイントがある。最初の導入先としては0.5Bが妥当だ。一方Tinyは、導入の簡便さよりも話者の類似性や複数話者の会話生成を重視する場合に、大きな容量を受け入れる価値が出てくる。

両チェックポイントとも44.1 kHz音声を生成し、7言語に対応する。また、音声クローニング、声質設計、感情、方言などは個別のタスクモードとして提供される。公式リポジトリでは両者がMITライセンスで公開されており、Tinyは0.5Bと固定依存関係が異なるため、専用環境が必要だと明記されている。

「Tiny」は保存される重みのサイズではなく、MoEにおけるアクティブ計算量を指す。Tinyのモデルカードには、バックボーンのパラメータ数は7.9B、トークンごとのアクティブパラメータは約1.3B、リポジトリ容量は約18 GBと記載されている。

クローンからチェックポイント検証までのローカルセットアップ

Ming-3.0-TTSを安定してローカル運用するなら、2モデルは別々の環境に分ける。公式コードは一度だけクローンし、選んだチェックポイント用のrequirementsだけを導入する。重みをダウンロードしたら、モデルを読み込む前に対応するpreflightスクリプトを実行しよう。

0.5B用環境を構築する

基本的なリポジトリのセットアップは短い。

git clone https://github.com/inclusionAI/Ming-3.0-tts.git
cd Ming-3.0-tts
conda create -n ming-tts python=3.10 -y
conda activate ming-tts
pip install -r requirements.txt

0.5Bのモデルカードによると、参照構成はPyTorch 2.6、CUDA 12.4、transformers==4.46.3だ。FlashAttentionは任意で、利用しない場合はPyTorch SDPAにフォールバックする。このフォールバックで互換性は確保できるが、プロジェクト側は速度低下の程度を公表していない。

数値、日付、単位、記号のテキスト正規化にはFSTを使う。固定バージョンのPyniniはConda経由で導入する。

conda install -c conda-forge pynini==2.1.6

pyniniにはあらゆる環境で使えるwheelがあるわけではない。--no_text_normalizationで回避はできるが、その場合は略語、日付、数値、記号が未処理のまま音声合成器へ渡される。したがって、これは本番の標準設定ではなく、問題切り分け用のスイッチと考えるべきだ。

Tinyは必ず別環境に導入する

Tinyを0.5Bの環境へ上書きインストールしてはいけない。公式セットアップでは、Python 3.10.15、CUDA 11.8のwheel、PyTorchおよびtorchaudio 2.7.1、transformers==4.46.3が固定されている。

conda create -n ming-tiny python=3.10.15 -y
conda activate ming-tiny
pip install -r requirements-tiny.txt

TinyはBF16で計算し、可搬性を意識したMoEループとFP32のリカレント状態を使う。InclusionAIはNVIDIA H800を推奨しており、CPU、Apple Silicon、GGUF、llama.cpp向けのサポート済み経路はドキュメントにない。

チェックポイントをダウンロードして検証する

Hugging Face CLIを使えば、重みを予測しやすいローカルディレクトリへ配置できる。

pip install "huggingface_hub[cli]"
hf download inclusionAI/Ming-3.0-tts-0.5B \
  --local-dir Ming-3.0-tts-0.5b
python tools/preflight.py --model_path Ming-3.0-tts-0.5b

TinyではモデルIDを置き換え、Tiny用の検証スクリプトを実行する。

hf download inclusionAI/Ming-3.0-tts-tiny \
  --local-dir Ming-3.0-tts-tiny
python tools/preflight_tiny.py --model_path Ming-3.0-tts-tiny

preflightスクリプトは重みをロードせず、チェックポイントとトークナイザーの構造を検証する。中国本土のユーザーは、プロジェクトREADMEに記載されたModelScopeのダウンロードコマンドも利用できる。

サーバー化の前に、まずWAVを1本生成する

最初に確認すべきなのは、リポジトリのCLIでWAVを1本生成できることだ。0.5Bで音声クローニングを行う場合、対象テキスト、参照WAV、その正確な書き起こし、--use_spk_embを指定する。書き起こしは任意のメタデータではなく、コンディショニング経路の一部である。

python infer.py \
  --model_path Ming-3.0-tts-0.5b \
  --task TTS \
  --language_id English \
  --text "The release candidate passed every audio check." \
  --prompt_wav_path reference.wav \
  --prompt_text "This is the exact speech in the reference recording." \
  --use_spk_emb \
  --output output/first.wav

出力は44.1 kHzのWAVになるはずだ。チェックポイントの検証は通るのにこのコマンドが失敗するなら、UIやサーバー層を追加する前にCUDA/PyTorchの互換性と参照ファイルを確認する。Hugging Faceリポジトリが配布するのはチェックポイントであり、実用的な推論には別途GitHubリポジトリが必要だと、両モデルカードに記載されている。

参照録音はノイズの少ないものを用意し、書き起こしは音声と完全に一致させたい。公式ドキュメントには理想的な参照音声の長さが示されていないため、文書化されていない経験則を必須の検証条件にしてはならない。

1つの音声エンドポイントとしてMing-3.0-TTSを公開する

SGLang-Omniを使うと、どちらのチェックポイントも1基のGPU上でPOST /v1/audio/speechとして公開できる。Ming-3.0-TTS向けSGLang cookbookでは、前処理をCPU、バックボーンとAudioVAEデコーダーを同一GPUに配置している。

まず、いずれか一方のチェックポイントを起動する。

sgl-omni serve --model-path inclusionAI/Ming-3.0-tts-0.5B

続けてWAVをリクエストする。

curl http://127.0.0.1:8000/v1/audio/speech \
  -H "Content-Type: application/json" \
  -d '{
    "model": "inclusionAI/Ming-3.0-tts-0.5B",
    "input": "The local speech endpoint is ready.",
    "response_format": "wav",
    "seed": 123
  }' \
  --output speech.wav

このエンドポイントはwav、mp3、flac、pcmを受け付け、デフォルトはWAVだ。入力が空ならHTTP 400を返す。modelフィールドは、サーバー起動時に指定したチェックポイントと一致していなければならない。

再生側をトークン単位のストリーミング前提で設計してはいけない。SGLang cookbookによれば、stream=trueでも生成完了まで待機し、完全なPCMレスポンスボディを1つ返すだけだ。また、クローニングに指定できる参照録音は1本のみで、2本目は拒否される。

コントロールは組み合わせるフラグではなく、タスクごとの契約

Ming-3.0-TTSのコントロールは、独立したタスクとして設計されている。1つのリクエストに使える機能をすべて盛り込むのではなく、欲しい出力に合ったタスクを選ぶ必要がある。

公式cookbookでは、free-formモードを声質設計、内蔵音声、感情、方言、基本属性と組み合わせられないことが明示されている。文中に複数のパラ言語イベントを含めることは可能だが、リポジトリの制限事項では、単一イベントと比べると安定性が低いとされている。

スコアから分かること、分からないこと

公開されている根拠を踏まえると、標準的な選択は0.5B、Tinyは特定用途向けという位置付けになる。公式READMEに転載されたArtificial Analysisの結果では、Ming-3.0-TTSは2026年10月時点でControlled Voice Eloが1,069、発音の堅牢性が93.2%とされる。ただし、このリーダーボードの主張は0.5Bモデルのものであり、Tinyの品質を裏付けるものではない。

ベンダー評価には、チェックポイント間の明確なトレードオフが出ている。Seed-TTS評価データでは、0.5Bの中国語/英語W​​ERは0.800%/1.584%、Tinyは0.820%/1.666%だ。一方、話者類似度はTinyが両言語で上回り、0.5Bの0.758/0.691に対して0.781/0.728を報告している。これらはInclusionAIの評価表による数値であり、ローカルで再現されたテスト結果ではない。

Tinyが7言語すべてで優位というわけでもない。公式の多言語表では、韓国語CERはTinyが6.000%、0.5Bが1.728%となっている。Tinyだけがポッドキャストに対応し、ポッドキャストCER 2.03%、条件付き話者類似度0.561、UTMOS 2.12を報告しているが、InclusionAI自身も予測されるポッドキャスト音声品質を改善対象に挙げている。

実務上の結論は限定的だ。初回導入、韓国語、運用の複雑さを抑えたい場合は0.5Bを選ぶ。ポッドキャスト生成が必要な場合、あるいは自身の参照音声で測った話者類似度が大きなチェックポイントを使う理由になる場合にTinyを評価すればよい。

手元のハードウェアで導入可否を検証する

公式手順でセットアップに成功しても、コンシューマー向けGPUで本番運用できるとは限らない。導入判定では、アプリケーションが使う言語と参照音声の条件そのもので、ピークVRAM、最初のWAVが完成するまでの時間、リアルタイム係数、失敗率、出力品質を記録したい。

「GGUF/llama.cppにはまだ対応しておらず、コンシューマーGPUのベンチマークもない。」 — Xの@TeksEdge

この指摘は、公式情報の境界とも一致する。0.5Bのドキュメントにテスト環境として挙がるのはH800-80GBとH20-96Gで、TinyはH800を推奨している。どちらの公式モデルカードにも、RTX 4090、RTX 3090、Windows、WSL2、macOS、必要最小VRAM、リアルタイム係数の結果は掲載されていない。

合否判定は次の順序で進めるとよい。

1. 対応するpreflightスクリプトを実行し、チェックポイントのリビジョンとともに出力を保存する。
2. 内蔵音声またはゼロ話者経路で短いWAVを生成し、その後に本番用の参照音声形式でも繰り返す。
3. 短文、中央値の長さの文、長文の本番テキストで、ピークVRAMと実時間を測定する。
4. 出荷対象となるすべての言語で、明瞭性と話者同一性を分けて評価する。
5. 必要な各コントロールを個別タスクとして検証し、非対応の組み合わせに依存する構成は採用しない。
6. リクエストタイムアウトと同時実行性を含め、完全波形を返すAPIの挙動に対して負荷試験を行う。

これらを測定しない限り、「ローカルで動く」とは、文書化されたデータセンター向けハードウェア上で参照スタックがロード・音声合成できる、という意味にすぎない。

Ming-3.0-TTS FAQ

Ming-3.0-TTSはRTX 4090や3090で動く？

公式リリースでは、最低VRAM容量もコンシューマーGPUでのベンチマークも公開されていない。0.5Bのほうが試しやすい出発点ではあるが、どちらのGPUを採用する場合も、ピークメモリ使用量とリアルタイム係数をローカルで確認してから判断したい。

Ming-3.0-TTSはWindowsやmacOSで使える？

公式の参照環境はCUDAベースのLinuxスタックだ。公式リポジトリには、ネイティブWindows、WSL2、Apple Silicon、MLX、GGUF、llama.cppのサポートは記載されていない。

Ming-3.0-TTSは商用利用できる？

コードと公開チェックポイントはいずれもMITライセンスだ。メンテナーは利用ガイダンスで、欺瞞的ななりすましや同意のないなりすましを禁止しており、実際の録音と誤認されるおそれがある合成音声にはラベルを付けるよう求めている。

SGLang APIは音声をリアルタイムでストリーミングする？

いいえ。文書化されたstream=trueの挙動では、生成が完了してから単一のPCMレスポンスボディを返す。そのためクライアント側では、段階的な再生ではなく、全体レスポンス型の生成として扱うべきだ。

Ming-3.0-tts-0.5BとTinyはどちらを使うべき？

より小さいチェックポイント、シンプルな導入、韓国語合成、通常の単一話者用途なら、まず0.5Bを使う。複数話者ポッドキャスト生成が必須の場合、または自分の音声で評価してTinyの高い中国語・英語話者類似度が再現されると確認できた場合はTinyを選ぶとよい。