VoxCPM2含めOSS TTSが7方向に割れてきた

VoxCPM2は2Bパラメータのtokenizer-free TTS。
Hugging Faceのモデルカードでは、2M+時間の多言語音声データ、30言語、日本語対応、48kHz出力、Apache-2.0と書かれている。
「200億」ではなく2B、つまり20億パラメータ級だ。

RTFはRTX 4090の通常推論で約0.30、Nano-vLLM利用時で約0.13。
1秒の音声を0.13秒で作れるなら、条件次第でリアルタイム会話に届く速度だ。

このブログではQwen3-TTS、MioTTS、LuxTTS、Sarashina2.2-TTSあたりを扱ってきた。
VoxCPM2はその中でも、軽量さより「音声をどれだけ崩さず扱うか」に振ったモデルだ。

離散トークンを経由しないTTS

OpenBMB の READMEは、VoxCPMを tokenizer-free な Text-to-Speech と説明している。
従来の高品質TTSでは、音声をいったん codec や tokenizer で離散トークンに変換し、音声LMでトークン列を生成し、最後にボコーダーで波形へ戻す構成が多かった。

Fish Speech や Bark 系の発想はこの系統に近い。
音声を「LLMが扱いやすい記号列」に落とすので、テキストLMの技術をそのまま持ち込める。
一方で、息、間、子音の潰れ方、録音っぽい空気、感情の揺れは、離散化の時点で落ちやすい。

VoxCPM 系は、そこを連続的な音声表現として直接扱う方向に振っている。
モデルカード上の構成は tokenizer-free Diffusion Autoregressive で、LocEnc、TSLM、RALM、LocDiT というパイプラインになっている。
雑に言えば、音声を無理やり記号IDへ丸めず、連続値のまま拡散系の生成で詰めていく設計だ。

画像生成でいうVQ-VAE的な離散latentと連続latent diffusionの質感差に近い。
音声は時間方向の整合があるので単純な置き換えではないが、ブレスや抑揚を残すなら連続表現側に寄せたくなるのは分かる。

2Bで48kHz、でも軽量モデルではない

2BはLLMなら小さい部類だが、TTSはLLM本体だけで終わらない。
音声VAE、拡散デコーダー、デノイザ、ストリーミング用サーバーまで含めて体感の重さが決まる。

モデルカードの Model Details では VRAM 約8GB、dtype は bfloat16、LM token rate は 6.25Hz。
RTX 4090 ならかなり速いが、Mac の MPS で同じ感覚を期待するのは無理がある。
特に diffusion や flow matching 系は、CUDA前提の最適化と Apple Silicon での体感差が大きい。

M1 Max 64GB でローカルTTSを触るなら、Kokoro、Piper、XTTS v2 みたいな軽い系は気楽に試せる。
Fish Speech や F5-TTS は条件次第。
VoxCPM2 のフル品質は「動くか」より「会話用途の待ち時間で耐えるか」を別に見たほうがいい。

いまのOSS TTSは方向が割れている

ここ1年のOSS TTSは、高品質化だけでなく狙う方向自体が分かれてきた。

モデル	方向
VoxCPM2	tokenizer-free、2B、30言語、48kHz、音声デザイン、制御付きクローン
F5-TTS	flow matching、軽めの構成、高速推論、短い参照音声からの声合わせ
Fish Speech	LLMベース、多言語、感情タグや会話っぽさ
CosyVoice2	streaming と offline を同じ枠で扱う大規模ゼロショットTTS
IndexTTS	中国語圏で強い制御性、声質保持、長文安定性
Kokoro	82M級の軽量TTS、組み込みやローカル常駐向き
Piper	CPU向けの軽量読み上げ、品質より堅実さ

F5-TTSはL20 GPUでPyTorch offlineのRTF 0.1467、TensorRT-LLMではさらに低い値が出ている。
CosyVoice2はLLMとchunk-aware causal flow matchingでstreamingとofflineを一つのモデルに入れにきた。
Fish SpeechはG2P変換を捨ててLLMで言語特徴を直接扱い、多言語とボイスクローンを伸ばす構成を取る。

音声合成が「軽く読む」「声を似せる」「感情を制御する」「リアルタイムで返す」「多言語を崩さない」に分岐していて、方向ごとに強いモデルがある。
VoxCPM2はそのうちtokenizer-freeで品質を攻める方向の一本だ。

日本語はまだ勝ち筋が割れる

日本語TTSは、英語圏のランキングだけ見ても判断しづらい。
アクセント、母音の抜け、息漏れ、文脈イントネーション、アニメ寄りの発声が絡むと、モデルカード上の「Japanese supported」と実用感がズレる。

日本語ローカルで実際に使える側の選択肢は、ここまで並べた汎用大規模モデル以外にもいくつかある。

モデル	方向
Sarashina2.2-TTS	日本産、日本語ゼロショット、約500M、SB Intuitionsが出した素のzero-shot系
Irodori-TTS	日本語特化、Rectified Flow DiT、500M、絵文字で感情・効果音を制御、MIT
Style-Bert-VITS2	VITS系、感情とスタイル強度を数値で制御、CPUでも動かせる
AivisSpeech	Style-Bert-VITS2系を取り込んだ実用エンジン、Mac/Windows、GPUなし可
VOICEVOX	キャラ音声特化、安定読み上げ寄りの既存定番、エンジンはOSS

Irodori-TTSはAratakoが2026年3〜5月にかけて出している日本語特化TTSで、500MパラメータのRectified Flow Diffusion Transformerだ。
連続潜在表現を拡散系で詰めていく構成はVoxCPM2と方向が近く、tokenizer-free系の流れに日本語特化版が来た、という見方ができる。
特徴的なのは絵文字によるスタイル制御で、入力テキストに 😭、🤧、👂😮‍💨 のような絵文字を差し込むと泣き、咳、ささやきといったスタイルが乗る。
ライセンスはMIT、48kHz出力、ゼロショットボイスクローン対応で、漢字読みは弱いのでひらがな化前提という割り切りもはっきりしている。

Style-Bert-VITS2は日本語コミュニティ側で長く育っているVITS系の派生で、感情の強度を数値で振れるのが効く。
AivisSpeechはそれをエンジン側で扱いやすく整えた実用ソフトで、GPUなしのMac/Windowsでも音が出る。
VOICEVOXはキャラクター音声特化で、ナレーション用の安定した読み上げを取りに行く側だ。
このあたりは推論コストが軽く、ローカルアシスタントや常時起動のAITuber的な用途にハマる。

VoxCPM2のような30言語級の大規模tokenizer-freeモデルと、Irodori-TTSやStyle-Bert-VITS2のような日本語特化軽量モデルは、そもそも取りに行っているものが違う。
大規模側は多言語の幅、48kHzの空気感、参照音声からの再現の幅で勝つ。
日本語特化側は、漢字混じりの自然さ、軽さ、運用のしやすさで勝つ。

日本語ローカルで進めるなら、まずIrodori-TTSやStyle-Bert-VITS2系で日常テキストを流して破綻の出方を聴き、声の似せや多言語混在で物足りなくなったらVoxCPM2やCosyVoice2方向に持ち上げる、くらいの順番が現実的だ。

VoxCPM2自体も30言語に日本語を含むが、日本語ネイティブの固有名詞、数字混じり、長文読み上げ、口語、句読点の間でどう崩れるかは別に聴く必要がある。
48kHzやボイスデザインは派手だが、日本語の読み上げでは「そこじゃない」部分で急に耳につくことがある。

学習データが「台本」になる理由

最近の日本語TTSコーパスは、音声と書き起こしテキスト（台本）のペアで配られることが多い。
音素列やアクセント情報そのものは付いてこないことが多いが、それでも学習できるのは、Style-Bert-VITS2をはじめとする日本語TTSが、OpenJTalkとMeCabに音素・アクセント抽出を任せる前提で組まれているからだ。

Style-Bert-VITS2の学習パイプラインを雑に追うとこうなる。

flowchart TD
    A[音声 wav] --> P[自動前処理]
    B[書き起こし 台本] --> C[MeCab 形態素解析]
    C --> R[読み付け カタカナ列]
    R --> O[pyopenjtalk_prosody]
    O --> E[音素列 + 上昇下降記号]
    E --> P
    B --> X[BERT 埋め込み]
    X --> P
    P --> M[Style-Bert-VITS2 学習]

つまり、wavと書き起こしを用意すれば、音素列とアクセント記号は pyopenjtalk_prosody が自動で生成する。
コーパス制作者は「読み上げ台本」を整えるところまで頑張ればよく、音素列やアクセント高低を手作業でアノテートする必要がない。
日本語TTSデータがここ数年で一気に整備されたのは、この自動前処理側のレールがしっかりしているからでもある。

弱点は、pyopenjtalkの読み付け精度が学習の質をそのまま縛ることだ。
よく引かれる例として、JSUTコーパスには「月印」と書いて「ルナグラム」と発話している事例があり、形態素解析器の読み付けと実際の発話がズレる。
MeCab系の形態素解析器は文脈や音声を見ず、辞書ベースで一つの読みを返すだけなので、固有名詞、当て字、最近の言葉、英単語混じり、人名で普通に外す。
これを補正するために、音声側からふりがなを推定する「ふりがなWhisper」のような派生ツールも出てきている。

Irodori-TTSが「漢字読み精度が弱いので、ひらがな化前提」と書いているのも根っこは同じ問題だ。
連続潜在表現側でいくら品質を伸ばしても、入力テキスト→読みの段でズレると、出てくる音は元の意図と違う読みになる。
日本語TTSの自然さの上限は、モデルアーキテクチャの上限ではなく、G2P（grapheme-to-phoneme）側の上限で決まることが多い。

ここがVoxCPM2やCosyVoice2のような多言語大規模モデルと、日本語特化モデルの分岐点でもある。
大規模モデル側は、サブワードトークナイザと大規模事前学習で文字→音素相当の表現を端から学ぶ方向に振っているので、OpenJTalkに依存しなくても多言語をある程度こなせる。
一方、日本語のアクセント規則やピッチ高低は、ルールベースのOpenJTalkが地味に強い領域で、Style-Bert-VITS2やAivisSpeech系が日本語ローカルでいまも生き残っている理由になっている。

逆に言えば、独自の声を自分で学習させたいときに、何百時間規模の多言語学習を回す必要はない。
30分〜数時間の台本付き音声を用意して、Style-Bert-VITS2でファインチューニングするのが、いまの日本語ローカルではいちばん現実的な道だ。
そのうえで読み付けが弱い単語だけユーザー辞書側で直したり、Whisperで音声側からふりがなを取り直したりする運用になる。

声コピーが普通に危ない速度になっている

VoxCPM2 は Controllable Voice Cloning と Ultimate Cloning を売りにしている。
短い参照音声で声色を寄せ、参照音声と書き起こしを両方渡すと、声色、リズム、感情、スタイルの再現を強める設計だ。

これは創作やナレーション用途ではかなり便利だが、電話品質なら悪用の閾値も下がる。
数秒サンプル、感情再現、リアルタイム寄りの推論が揃うと、身内の声をまねた通話詐欺や、配信者・VTuberのなりすましにそのまま近づく。

モデルカードの Limitations でも、なりすまし、詐欺、偽情報への利用は禁止と明記されている。
Apache-2.0 で商用利用しやすいことと、何に使ってもよいことは別だ。
ボイスクローン系のTTSは、利用同意、生成音声の表示、ウォーターマーク、音声認証との相性を最初から設計に入れないと運用側が詰む。

触るならRTFより失敗パターンを見る

RTF 0.13は4090、Nano-vLLM、最適化済みサービングという条件付きの数字だ。
手元のMacや小型GPUで見るなら、まず短文、長文、日本語、英語混在、数字、固有名詞、参照音声ノイズの6種類くらいを流して、破綻の出方を聴いたほうが早い。

生成設定も効く。
Hugging Face のサンプルには inference_timesteps、cfg_value、denoise、retry_badcase が出てくる。
速さだけを取りに行くと、発音の飛び、異常に長い間、テンションの暴れが出やすい。