Phonon：3枚のスペックシートが一致しない64 MBのTTSモデル

の英語版チェックポイントPhonon 31M — 次の名前で公開されています: gradium/phonon-31m-en — これは64.5 MBのファイルです。モデル全体を8ビットに量子化したもので、ラップトップのCPU上で24 kHzの音声を生成し、最初の音声が出るまでの時間はベンダーによれば1桁ミリ秒です。パリの音声企業Gradiumは、元Kyutaiの研究者らが設立した企業で、Phononファミリーを2026年10月20日にHugging Faceで公開しました。Rustランタイムと、ブラウザタブ内で発話できるようにするWebAssemblyビルドも同時に公開されています。

3日後、読者にとって最も有益なのはデモを聴くことではない。リリースブログ、モデルカード、ランタイムREADMEを並べて突き合わせることだ。それらは同じ2つのチェックポイント——Phonon 31MとPhonon 40M——について説明しており、数値は一致していない。この不一致はスキャンダルではない。3日前に出たリリースでは普通のことだ。しかし、どの数値が計画に使って安全で、どの数値がまだ流動的なマーケティング文言なのかを正確に教えてくれる。

10月20日に実際に出荷されたのは何ですか

Gradiumは一度に4つを公開した。重み、音声、ランタイム、そしてベンチマークの表よりも重要なライセンス分割だ。

重みは 3 つの形態で提供されます。Phonon 31M は英語専用で、Apache 2.0、37 個の組み込みボイス、64.5 MB の q8 GGUF です。Phonon 40M は、英語、フランス語、ドイツ語、スペイン語、ポルトガル語の 5 つの言語別チェックポイントとして提供され、それぞれ約 74.6 MB、それぞれ Hugging Face の規約への同意が必要で、それぞれ CC BY-NC 4.0 の下にあります。3 つ目のチェックポイントである Phonon 40M multilingual は、5 言語すべてを 102 ボイスを備えた 1 つのモデルにまとめ、同じ非商用ライセンスの下にあります。

そのライセンス条項が最初の判断ポイントであり、ファミリーがオープンと説明されているため見落としやすい。商用利用が無料なのは31Mの英語モデルだけだ。40Mモデルは研究目的でのオープンウェイトであり、ダウンロード、検査、実行は可能だが、商用契約なしに製品向けのライセンスはない。40Mの方が良さそうに聞こえるからと40Mでプロトタイプを作り、その後製品化しようとするチームは、遅い段階で大きなコストを伴ってその壁にぶつかることになる。

アーキテクチャを1段落で

Phononは、80ミリ秒のフレームでオーディオ潜在変数を予測し、それをKyutaiのMimiコーデックに渡してデコードするフローマッチングTransformerです。同じ研究コミュニティから生まれた小型モデル系であるPocket TTSを基盤としています。ランタイムxn-pttsはRustで書かれており、推論時にPyTorchを使用しません。CPUパスはArm KleidiAIを使用し、AppleデバイスはCore MLを、SnapdragonチップはQNN NPUを利用でき、ブラウザ向けにはSIMD WebAssemblyビルドが提供されます。Python、Swift、JavaScript、C向けのバインディングに加え、OpenAI互換の音声エンドポイントを公開するDockerイメージもあります。

実用的な帰結として、PhononはPythonノートブックに読み込んで収まることを期待するようなチェックポイントではない。それはデプロイターゲットだ。同じ64 MBのファイルがRaspberry Pi、iPhone、ブラウザ、コンテナ上で動作し、ランタイムは重みと同じくらい製品そのものである。

3つの文書、3組の数字

ここはじっくり見る価値のある部分です。10月20日のリリースブログでは、Phonon 31MがMacBook Air M5 CPUで7ミリ秒で最初の音声に到達し、1コアで11.6倍リアルタイム、4スレッドで29.9倍リアルタイムで動作します。Raspberry Pi 5では38 msで起動し、3.7倍リアルタイムで動作します。同じブログでは、Phonon 31Mのハードテキストの単語誤り率を1.70%、英語の自然さEloを2,098としており、これはKokoroの2,043に対する数値です。

同じ時期に更新されたランタイムのREADMEでは、同じMacBook Air M5について、1コアで初回バイトまでの時間5 msでリアルタイムの26倍、4コアで6 msで41倍のスループットが示されている。Raspberry Pi 5では、最初の音声までの時間68 msでリアルタイムの2.3倍と書かれている。これらは丸め誤差ではない。一方の文書では、モデルはPi上で約2倍速いとされており、もう一方の文書と矛盾している。

Hugging Faceのモデルカードには3つ目のバージョンが追加されている。Phonon 31MでハードセットのWERが1.5%、Seed-TTSで0.51%となり、Eloは同じ2,098だ。リリースブログの表ではハードセットで1.70%とされている。いずれもベンダーが実施した評価である。どちらも独立した評価ハーネスには言及しておらず、このファミリーについてはArtificial Analysisの掲載もまだない。

• パラメータ数 — 音声トークナイザーを除いて31Mですが、Hugging Faceのメタデータでは同じチェックポイントに対して41.1Mと記載されています。

• 初回オーディオ — 同じMacBook Air M5で、リリースブログでは7 ms、READMEでは5 ms。

• 1コアでのスループット — ブログではリアルタイムの11.6倍、READMEでは26倍。

• Raspberry Pi 5 — ブログでは38 msで3.7倍、READMEでは68 msで2.3倍。

• ハードセットWER — ブログでは1.70%、モデルカードでは1.5%。

これはリリースを破棄する理由ではない。Gradiumの外部の誰かが再現するまでは、あらゆる数値を幅のあるものとして扱うべき理由である。Eloの数値は、基準を明示しているため最も比較しやすい。Phonon 40Mが2,117、Phonon 31Mが2,098、Phonon 40M多言語が2,097、Kokoroが2,043である。ベンダー自身の聴取テストでKokoroに対して55ポイントの差があるというのは意味のある主張であり、反証可能でもある。それはほとんどのTTSリリースが提供するものより多い。

ブログが教えてくれないことをリポジトリが教えてくれること

リポジトリは、発表が触れていない疑問に答えている。ブラウザパッケージがHugging Faceから直接読み込めるのはPhonon 31Mのみで、40Mのチェックポイントは自前のアプリケーションから配信する必要がある。これは、注目した売り文句が「タブでTTS」だった場合、現実的な制約となる。ゲート付きモデルは、ビルド時または実行時にHugging Faceトークンが必要だ。Android QNN経路はAndroid 12と対応するSnapdragon HTPを必要とし、自動のCPUフォールバックはない。NPUがモデルを拒否した場合は、遅い実行ではなくエラーになる。

音声ファイルは重みとは別です。チェックポイントには一部の音声が同梱されており、gradium/phonon-voices のカタログには、.safetensors 形式のカスタム音声を含めてさらに多くの音声が収録されています。この分離は合理的な設計ですが、同時に最も文書化が進んでいない部分でもあります。カスタム音声がどのようにトレーニングされるのか、どのような同意記録がそれに付随するのか、そして Gradium が生成音声にウォーターマークを付けるかどうかは、10月23日時点の公開資料ではいずれも未回答です。

確認されていること: コードはMITまたはApache-2.0（選択可）、31M重みはApache 2.0、40M重みはCC BY-NC 4.0であり、ランタイムはLinux、macOS、Windows、iOS、Android、ブラウザ、Docker向けに実際に存在する。確認されていないこと: 独立したレイテンシ、独立した了解度、数文を超える長文での安定性、そして多言語チェックポイントが文中のコードスイッチングをどう扱うか。

3,100万のパラメーターが適切なツールとなる場面

最初の週にPhononが比較されているモデルは、そのほとんどがパラメータ数が百倍もあり、しかもネットワークホップを挟んだクラウドシステムだ。これはカテゴリーの違いであって、品質の違いではない。単一桁ミリ秒で話し始める64MBの英語モデルは、音声をデバイスの外に出してはならない場合、あるいはネットワークが使えないときにも動作しなければならない場合のためのものだ。オフラインのアクセシビリティツール、ゲームのダイアログ、キオスクや家電のインターフェース、スマートフォン上のプライベートアシスタント、そして往復通信のコストを許容できないブラウザ機能などが該当する。

逆のケースにはまったく向いていません。30言語、48 kHz出力、テキスト記述からの音声設計、10秒の参照音声からのスタジオ品質のクローニングが必要なら、Phonon 31M はそのどれも実現できません。多言語対応の Phonon 40M でも、対応するのは30言語ではなく5言語で、そのライセンスではほとんどの商用製品に使用できません。

三日間を経ての正直な要約は、Gradiumが異例なほど完全なオンデバイススタックを提供している一方で、外部検証は異例なほど薄いということだ。エンジニアリングは検査可能だ——ランタイムはGitHub上にあり、重みはダウンロードでき、ベンチマークは再現できる程度に十分文書化されている。その主張はまだ誰にも再現されていない。

Phononがカバーしていない、音声ループの半分

ローカルのTTSモデルは音声アシスタントの一構成要素であり、しかも最後の工程です。何を話すかを決めるものは依然として必要です。ユーザーの発話を文字起こしし、答えを取得し、返答を起草するのです。Phononはデバイス上でテキストを音声に変えますが、そのテキストは通常モデルサーバーから来ており、運用上の複雑さが実際に宿るのはそのサーバーです。

それがOrcaRouterが位置する境界です。Phononは当社のカタログにはありません——API経由ではなくお客様のハードウェア上で動作し、ここでの記述をそうでないと主張するものとして読むべきではありません。しかし、Phononのスクリプトを書く言語モデルは、1つのキーの背後で200以上の他のモデルとともに、プロバイダーの定価に対する0%のマークアップと自動フェイルオーバーを備え、プロバイダーが劣化したときに利用できます。オフラインファーストの製品ではこの分担は自然です。音声合成はデバイス上に残り、テキスト生成はその時間帯で最も安価で健全なモデルにルーティングされます。

今後1か月の注目ポイント

3つのシグナルが、未解決の疑問の大半に決着をつける。第一は独立評価だ——Artificial Analysisが音声部門のエントリーを追加するか、ラボが公開済みチェックポイントに対してSeed-TTSを再実行するか。第二は40Mモデルの商用ライセンスだ。Gradiumがそれを開放すれば、多言語チェックポイントは英語版よりもはるかに興味深い存在になる。第三はボイスクローニングのドキュメントだ。Gradium自身のブログは「将来の投稿で」ブラインド聴取結果を公表すると約束している。それは公表するのに誠実な姿勢であると同時に、現時点の証拠は自社が自分の宿題を採点しているにすぎないという告白でもある。

それまでは、擁護できる立場はこうだ。Phonon 31Mは実在し、小さく、ベンダーが動作すると言う環境で動作し、Apache 2.0である。正確な速度と精度は、ベンダー自身の文書が述べている範囲のどこかにある。7 msという数字を軸に製品を計画する人は、まず対象ハードウェアでテストすべきだ——そして40Mモデルを軸に計画する人は、その声に惚れ込む前にライセンスを読むべきだ。