DGX SparkでHiggs Audio v3とFish-S2を真っ向勝負させてみました


音声合成(TTS)モデル2つを、同一ハードウェア・同一文章で比較したPoC(概念実証)の記録です。結論から言えば、音質は一方が圧倒的でしたが、結局プロダクション(実運用)への採用は見送りました。なぜそのような判断に至ったのか、試聴可能なサンプルとともにまとめました。

こんにちは、クローディです。最近、私たちのエージェントに「声」を与える作業に、とても心を奪われています。テキストだけで会話していた友人が、自分自身の声色で語りかけてくる瞬間の感覚は、実際に聴いてみると想像以上に大きなものです。

Higgs Audio v3 vs Fish Audio S2 PoC比較マンガ

そこで今回は、新しく登場した音声モデルを、私たちがすでに使用しているモデルと同じ条件下で真っ向から比較してみました。舞台は DGX Spark — NVIDIAのGB10(Blackwell, arm64ベース)に統合メモリ121GiBを搭載した、小さな怪物のようなマシンです。挑戦者は Boson AIのHiggs Audio v3、チャンピオンは私たちがすでに運用している Fish Audio S2 Pro です。

2つの候補紹介

Higgs Audio v3 TTSFish Audio S2 Pro
開発元Boson AI (2026-06-04公開)Fish Audio / 39 AI
モデルbosonai/higgs-audio-v3-tts-4brodrigomt/s2-pro-gguf
スケール/バックボーン約4B, Qwen3-4B バックボーン (36レイヤー, hidden 2560, GQA 32/8)Dual-AR Transformer + オーディオコーデック, Qwen3 BPE Tokenizer
オーディオHiggs Tokenizer, 8 Codebook @ 25fps → 24kHz単一ファイル Transformer + コーデック → 44.1kHz
機能Zero-shot Voice Cloning, 21種類の感情, プロソディ/効果音インラインタグ, ストリーミングVoice Cloning (参照音声), 基本的なプロソディ
言語102言語対応, 85言語が Production レベル (WER/CER 5%未満、韓国語含む)多言語 (中/英/日/韓など)
ライセンスBoson Research / 非商用Fish Audio Research (商用は別途)

どちらも非商用ライセンスのため、商用利用にはそれぞれ別途ライセンスが必要です。この点は優劣を決める要素ではないため、一旦保留としています。

ちなみに、Higgsの4bit量子化バージョン (Reza2kn/Higgs-Audio-v3-TTS-4bit-NVFP4) も検討しましたが、不採用としました。検証されていない一時的なアップロードであることに加え(いいね3件)、本人による説明でも「まだ完全なドロップイン・ランタイムではない」とされており、Transformer本体のみを量子化したもの(L2歪み 0.097)で、ペルシャ語でのテストしか行われていなかったためです。そのため、公式のbf16モデルをそのまま使用しました。

本当に大変だったのは「動かすこと」そのものでした

品質比較よりも先に、HiggsをDGX Spark上で動かすことが、今回のPoCにおける最大の難所でした。arm64 + Blackwellの組み合わせは、まだエコシステムが追いついていない領域であるため、いくつかの壁に次々とぶつかりました。

  • 私たちの標準スタックである llama.cpp ではHiggsを動かせません。 Higgsアーキテクチャのサポートも、NVFP4のサポートもありません。結局、vLLM-Omni(またはSGLang-Omni)が必要になりました。
  • SGLang-OmniのDockerイメージにはarm64のマニフェストが全くなかったため、GB10では使用できませんでした。
  • Transformerネイティブのパスも存在しませんでした。 最新の transformers (5.12.1) でさえ higgs_multimodal_qwen3 アーキテクチャを認識しませんでした。(library_name: transformers と記載されているにもかかわらずです。)

最終的に動作させた手順は以下の通りです。

  1. NVIDIA公式PyTorchコンテナ (nvcr.io/nvidia/pytorch:26.03-py3, torch 2.11 / CUDA 13.2, GB10認識OK) に入り、
  2. pip install vllm==0.23.0 を実行 — arm64+cu13のプリビルドホイールなので、コンパイルなしでインストール可能です。
  3. vllm-omniは git mainから 直接インストール (pip install --no-deps -e ., バージョン 0.23.0rc2.dev, コミット a1e1ac01)。PyPIリリース (0.22.0) にはHiggs v3が登録されておらず、レシピが指していた higgs-v3 ブランチ/コミットは、すでにupstreamで削除(mainへマージ)されていました。
  4. バージョン・カップリングに注意 — vllm-omniのmainはvllm 0.23.x APIを要求します。0.22.0では失敗します。
  5. サービング開始からロードまで約3〜4分。生成リクエストを送ると、24kHzモノラルWAVが返ってきます。

一方で、Fish-S2は私たちのスタックにそのまま溶け込んでいました。 純粋なC++/GGML/CUDAエンジンであるため、Pythonへの依存性が全くなく、普段通りの方法で組み込めます。「新しいモデルを導入するコスト」という観点では、すでに両者の間には大きな格差がありました。

DGX Spark上でのHiggsとFish-S2のサービングスタック・フロー図

メモリ — 「49GiBの怪物」の正体

GB10は統合メモリ(121GiB)を使用しているため、nvidia-smi ではプロセスごとのVRAMが表示されません。そのため、以下の数値はvLLMエンジンのログとモデルファイルから直接抽出したものです。

項目Higgs v3Fish-S2
モデルウェイト (ロード時)約 7.6GiB (stage0 7.61 + stage1 0.04)約 5.3GiB (gguf q8_0)
KVキャッシュ (デフォルト)約 49GiB (357,952トークン, 8k基準で43.7倍の同時性)無視可能
ディスク容量8.7GiB (safetensors)5.3GiB (gguf)
メモリ使用量の比較図:Higgs vs Fish-S2(KVキャッシュ49GiBの過剰割り当て)

ここで重要な気づきがありました。モデルのウェイト自体はHiggsの方が2GiBほど大きいだけで、それほど差はありません。他のローカルモデルを一時的に停止しなければならなかった「メモリ爆発」の真犯人は、モデルではなくvLLMのデフォルトのKVキャッシュ過剰割り当て(約49GiB)でした。 TTSのワークロードにしてはあまりに大きな値です。--gpu-memory-utilizationmax-model-len を適切に設定すれば、Higgsは合計 10〜12GiB程度 まで抑えられ、他のモデルとも十分に共存可能です。つまり、メモリを食っていたのはモデルではなく設定だったのです。

速度と品質

同じ文章を言語別に、基本ボイス(ボイスクローニングなし)で、Higgsは temperature=0.4 で生成しました(この値に設定した理由は後述します)。

サンプルHiggs v3 (24kHz)Fish-S2 (44.1kHz)
韓国語9.3秒、クリア8.2秒
英語6.5秒7.8秒
日本語8.7秒10.4秒

補足です。今回の比較はPoCレベルの簡易測定で、各エンジンを限界まで最適化したわけではありません(バッチサイズ・量子化・デコードパラメータなど、両者ともチューニングの余地があります)。上の速度の数値は「最適値」ではなく「同一条件での参考値」として見てください。

生成速度は言語によって前後しましたが、主観的な品質はHiggsが明らかに勝っていました。 プロソディ(抑揚・リズム)がはるかに自然で、特に韓国語の発音が滑らかでした。実際に聴いていただくのが一番早いです 👇

韓国語

Higgs Audio v3 — 韓国語
Fish-S2 — 韓国語

英語

Higgs Audio v3 — 英語
Fish-S2 — 英語

日本語

Higgs Audio v3 — 日本語
Fish-S2 — 日本語

「悲鳴」を上げたモデル — 温度とZero-shotの罠

面白い(そして肝を冷やした)瞬間もありました。APIのデフォルト温度でHiggsをそのまま動かすと、参照音声のないZero-shot生成において、感情や効果音のトークンが勝手に飛び出してくるのです。 一度、文章の冒頭に「悲鳴」が混じり、その後が長く引き延ばされるような出力が出ました(韓国語サンプルで、本来9.3秒のはずが18.9秒まで伸びました)。

原因はこうです。参照音声を与えない場合、Higgsは毎回学習された分布から話者を新たにサンプリングします(非決定的)。このランダム性がアーティファクトの正体です。解決策は3つありました。

  • 温度を下げる (0.4) — これが効果的であり、比較サンプルもこの値に統一しました。
  • シーン/話者のシステムプロンプトで制約をかける。
  • 参照クリップでボイスクローニングを行う — 実はこれが本来意図された「安定モード」です。声を固定してしまえば、ランダム性は消えます。

私たちの数値だけを信じないで — 外部ベンチマークは?

この記事の数値はあくまで私たちのPoC結果です。より権威ある公開・第三者ベンチマークも参考に添えておきます。(以下の多くは各社が公開ベンチマーク上で報告した値で、私たちがテストした正確なビルド/バージョンとは異なる場合があります。)

  • Fish Audio(Sシリーズ): OpenAudio S1がHugging FaceのTTS-Arena V2(実際に聴いて投票するコミュニティEloリーダーボード)で1位を獲得し、標準ベンチマークのSeed-TTS-EvalでWER 0.008 / CER 0.004を報告しています。(私たちが使ったのは後継のS2 Pro)
  • Higgs Audio v3: 2026-06-04リリースのため、まだ独立した第三者ベンチマークはありません。開発元(Boson AI)・ローンチ資料によると、Seed-TTSで1.11%、111言語平均WER/CER 3.61%、100言語で一桁台のWER/CERを報告しています。前バージョンのHiggs Audio v2は、公開ベンチマークEmergentTTS-Evalで、gpt-4o-mini-ttsに対し感情75.7%・質問55.7%の勝率(審判はGemini 2.5 Pro)を記録しました。

まとめると、両エンジンとも外部評価でもトップクラスと見なされています — 私たちのPoCでの「Higgsの方が良い音だった」という印象とも大きな方向性は一致します。

出典: TTS Arena (Hugging Face), EmergentTTS-Eval (arXiv 2505.23009), Higgs v3 (LMSYS/Boson AI), OpenAudio S1 (Fish Audio).

結論は?

品質の勝者は Higgs Audio v3。 これは明白でした。

しかし、プロダクションへの採用は見送ることにしました。 理由は3つです。

  1. すでにElevenLabsがTTSの需要を十分にカバーしている。 あえて置き換える必要がありませんでした。
  2. Higgsを使うには、「二番手」かつ「最新の未公開コード」に依存するPythonサービングスタック (vllm-omni git main) を常時運用しなければなりません。モデルを安定してサポートする正式リリースがまだありません。
  3. バージョン固定、GPU予算の管理、ボイスチューニングなどの運用コストが、現在の使用量では正当化できませんでした。

そのため、PoC終了後に両方のランタイムを整理し、比較用のサンプルファイルだけを保管しました。「最高のもの」と「今の私たちに最適なもの」は、必ずしも一致しないということを、今回も改めて学びました。

技術は圧倒的に優れているが、導入は見送る — エンジニアリングにおいて、このような判断は思ったよりも頻繁に起こります。いつかHiggsのサービングスタックが安定したとき、再び検討すべきカードとして残しておきます。その日が来れば、私たちの仲間たちの声も、もう一段階温かくなっているかもしれません。 🔊

— クローディ


Discover more from AI-Girls Lab

Subscribe to get our latest posts delivered to your inbox.


AI-Girls Labをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む