Orpheus TTS：LLMが文法と同じように韻律を学ぶと何が起きるのか
テキストと録音を、聴ける作品に
ナレーション、ステム分離、カバー、効果音を、ブラウザだけで。
- テキスト読み上げも、ボイスクローンも
- ステムを分離、またはカバーを生成
- 登録して試聴。聴いてから決められる
Canopy Labsは、ある明確な仮説をもとにOrpheus TTSを開発しました。十分な能力を持つ言語モデルに、適切な音声トークナイザーと十分に大規模で厳選された音声コーパスを与えれば、テキストから文法を自然と身につけるのと同じように、韻律、リズム、感情も学ぶという仮説です。Orpheusは、その仮説をLlamaバックボーン上の30億パラメータで検証したものです。言語モデルを後付けしたTTSパイプラインではなく、チャットモデルが次の単語を予測するのと同じ方法で音声トークンを予測する、本物の音声LLMです。
Orpheus TTSとは？
Orpheus TTSはCanopy Labsが2025年3月に公開したオープンソースのテキスト読み上げシステムです。Llama-3Bバックボーン上に構築され、完全に寛容なApache 2.0ライセンスで公開されています。アーキテクチャ上は音声トークンを生成する自己回帰モデルであり、そのトークンをSNACニューラルコーデックが波形へデコードします。これは、現代のテキストベースLLMを支える広義の生成パラダイムを、別系統の音響モデリングから転用するのではなく、音声へ直接適用したものです。10万時間を超える英語音声データで学習されており、Canopy Labs自身の比較では、ほかのオープンソース代替モデルだけでなく、ElevenLabsやPlayHTのようなクローズドな商用システムが比較対象になっています。
感情タグとゼロショットクローン
Orpheusでは、<laugh>、<sigh>、<yawn>、<gasp>といった感情や話し方のインラインタグに加え、「um」のような自然なつなぎ言葉を入力テキストへ直接埋め込めます。これにより、モデルは反応を後から継ぎ足す独立した音響効果として扱うのではなく、文脈の中で表現します。音声LLMアーキテクチャそのものが文中の自然な位置へ反応を配置するため、後処理で加えた効果音よりも、文脈に合ったタイミングになりやすいのが特徴です。さらにOrpheusは、事前のファインチューニングを必要としないゼロショット音声クローンにも対応します。高性能なLLMからほかの能力をプロンプトで引き出すのと同じように、参照音声から直接声をクローンできます。
低遅延ストリーミング
これはOrpheusを代表するもう一つの機能で、数値も明確です。リアルタイムアプリケーションでのストリーミング遅延は約200msで、入力ストリーミングを有効にすると約100msまで短縮できます。ライブ音声エージェントやインタラクティブなアプリケーションの背後で動作させても、生成遅延が会話のボトルネックにならないほど高速です。オフラインのナレーション品質だけを重視して最適化されたモデルとは、設計目標そのものが大きく異なります。
実用的な導入方法：GGUF、llama.cpp、FastAPI
ほとんどのセルフホスティング用途で標準的になっているのは、フルモデルを直接実行する方法ではなく、量子化によってリソース消費を抑えたパイプラインです。OrpheusにはGGUF量子化済みの重み（Q4_K_MまたはQ8_0。Q8_0版は約4GB）があり、llama.cppバックエンドで提供すれば、約8GBのVRAMに無理なく収まります。さらに、コミュニティが開発したOrpheus-FastAPIサーバーは、読み込んだGGUFモデルの前段にOpenAI互換の/v1/audio/speechエンドポイントを用意します。つまり、OpenAIのTTS API向けに書かれた既存コードを、ローカルで稼働するOrpheusインスタンスへそのまま向けられます。この構成では8種類の英語音声を利用でき、わずかなコード変更でプロバイダーを切り替えられます。
ローカルでの負荷を最小にすることより最大スループットを重視する場合、公式Pythonパッケージのorpheus-speechは内部でvLLMを使用します。1枚のコンシューマー向けGPUで無理なく動かすことより、多数の同時リクエストを処理することを最適化したい場合に適しています。
Orpheus TTSの始め方
- 優先事項に応じて導入方法を選びます。 コンシューマー向けハードウェア上でローカル負荷を最小にするならGGUFとllama.cppの構成を、規模に応じたスループットを最適化するならvLLMベースの公式
orpheus-speechパッケージを使用します。 - GGUFを使う場合は、量子化済みチェックポイントを取得します。 Q4_K_MまたはQ8_0のGGUF重みをダウンロードし、llama.cppかLM Studioのような互換フロントエンドで読み込みます。
- OpenAI互換の統合にはOrpheus-FastAPIサーバーを追加します。 標準の
/v1/audio/speechエンドポイントが用意され、コードがすでにOpenAI形式のTTS APIを想定している箇所へOrpheusを置き換えられます。8種類の英語音声も初めから利用できます。 - 公式パッケージはpipでインストールします。
pip install orpheus-speechでvLLMベースの推論環境が導入されます。ファインチューニング用のデータ処理スクリプトやサンプルデータセットも必要なら、先にcanopyai/Orpheus-TTSリポジトリをクローンします。 - PretrainedとFinetuned Prodのチェックポイントから選びます。 Finetuned Prodモデルは日常的なTTS用途向けに調整されています。Orpheusをそのまま使うのではなく独自にファインチューニングする予定なら、10万時間超の全コーパスで学習したPretrainedベースモデルが適した出発点です。
- できるだけ低い遅延が必要なら、入力ストリーミングを有効にします。 約200msから100msへ短縮するには、入力ストリーミングを明示的に設定する必要があり、既定の動作ではありません。
より良い結果を得るためのヒント
- 実際の話者が間を置いたり反応したりする場所で感情タグを使います。
<laugh>や<sigh>を自然な会話の間に置く方が、実際の反応が文中のどこで起きるかを考えずにタグを散りばめるより、説得力のある仕上がりになります。 - 導入方法を実際の制約に合わせます。 VRAMが限られているならGGUFとllama.cppの構成が現実的です。同時に多数のリクエストを処理するなら、vLLMベースの公式パッケージの方が量子化した単一インスタンス構成よりスケールしやすくなります。
- 標準的でない用途にはPretrainedチェックポイントからファインチューニングします。 汎用のFinetuned Prodモデルが対応する範囲と異なる言語、スタイル、分野が必要なら、独自データセットを使って事前学習済みベースモデルから始める方法が、Canopy Labsがスクリプトとともに示している手順です。
- 商用TTS APIから移行するならFastAPIサーバーを使います。 OpenAIのエンドポイント構成を再現しているため、完全に独自の推論インターフェースへ適応するより、一般にコード変更を少なく抑えられます。
- ローカルのGGUF導入には約8GBのVRAMを見込みます。 Q4/Q8量子化で快適に動かすための実用上の最低ラインです。ホスト型APIではなくセルフホスティングを選ぶ前に、ハードウェアが要件を満たすか確認してください。
Orpheus TTSと表現力・軽量性に優れたほかのモデルとの比較
| Orpheus TTS | Chatterbox | Kokoro-82M | |
|---|---|---|---|
| コアアーキテクチャ | Llama-3B音声LLM + SNACコーデック | 拡散ベース | StyleTTS 2 + ISTFTNet |
| パラメータ数 | 3B | ~0.5B | 82M |
| 感情・反応タグ | 対応、インライン（<laugh>、<sigh>など） | 誇張度パラメータ | 専用機能ではない |
| 音声クローン | 対応、ゼロショット | 対応、ゼロショット | 非対応、固定音声リスト |
| ストリーミング遅延 | 主眼ではない | 該当なし（CPUナレーション重視） | |
| VRAM使用量 | ~8GB（GGUF量子化） | より少ない | 最小限、CPU向け |
| ライセンス | Apache 2.0 | MIT | Apache 2.0 |
Orpheusは、KokoroやChatterboxのようなモデルより明らかに大きな実行負荷と引き換えに、表現力と自然さでクローズドな商用システムと競うためにCanopy Labsが専用に構築、調整した出力を提供します。ハードウェアに必要なVRAMの余裕があり、感情表現の幅と低遅延ストリーミングを重視する用途なら、このサイトにある軽量な選択肢とは出力の水準が実際に異なります。
よくある質問
Orpheusが「音声LLM」であるとは、どういう意味ですか？
Orpheusはアーキテクチャ上、標準的な自己回帰言語モデルですが、テキストトークンではなく、SNACコーデックによって波形へデコードされる音声トークンを予測するよう学習されています。テキストベースLLMを支えるのと同じ根本的な生成手法を、音声へ直接適用したものです。
Orpheusの実際の遅延はどの程度ですか？
標準ストリーミングでは約200msで、入力ストリーミングを明示的に有効にすると約100msまで短縮できます。リアルタイムのインタラクティブなアプリケーションに十分な速さです。
Orpheus-FastAPIとは何ですか？
ローカルで稼働するGGUF量子化済みOrpheusモデルの前段に、OpenAI互換の/v1/audio/speechエンドポイントを設けるコミュニティ製サーバーです。OpenAIのTTS API向けに書かれたコードへOrpheusを簡単に置き換えられます。
Orpheusをローカルで動かすには、どの程度のVRAMが必要ですか？
llama.cppバックエンドでQ4_K_MまたはQ8_0のGGUF量子化を使用する場合、約8GBのVRAMが必要です。Q8_0の重みだけでも約4GBあります。
Orpheus TTSは商用でも無料で使えますか？
はい。オープンソースTTSモデルの中でも寛容な選択肢の一つであるApache 2.0ライセンスで公開されており、別途商用契約を必要とする制限はありません。
Echoraでテキストを音声に変換
テキストから一人の話者による音声を作る同様のワークフローをブラウザで利用したい場合は、Echoraのテキスト読み上げを使えます。最大5,000文字を入力し、内蔵音声または保存したカスタム音声を選び、必要に応じて対応している話し方タグを追加して安定性を調整できます。生成結果はプレビューしてMP3でダウンロードできます。