テキスト読み上げ API を無料にした方法：S2.1 Pro の背後にある推論エンジニアリング

要約 (TL;DR)

• Fish Audio S2.1 Pro が無料のテキスト読み上げ（TTS）APIとして利用可能になりました。83言語に対応、ハードな使用制限なし、モデル文字列は s2.1-pro-free です。無料アクセスは初期期間提供されます。変更がある場合は事前にお知らせします。詳細はこちらをご覧ください。
• エンドツーエンドの推論最適化により、GPU 1枚あたりのリクエスト処理能力が4倍に向上。以前は4枚の H200 を必要としていたワークロードが、現在は1枚で動作します。
• 主な改善策：カスタム CUDA カーネル（デコード形状において cuBLAS 比で 2.1〜4.3倍高速）、コンティニュアス・バッチング（スループットが c=1→64 で52倍にスケール）、GPU 利用率を約50%から90%以上に向上。
• 同様のスタックが弊社の音声クローニング APIも支えています。同じモデルの重み、同じインフラを使用し、無料枠も含まれています。S2.1 Pro は弊社のオープンウェイト基盤モデルである Fish Speech をベースに構築されています。
• コア・カーネル・ライブラリ fish-scales-ops はオープンソースです。

他のプラットフォームから開発者が乗り換えている理由を確かめてください → 無料で開発を始める

2026年7月 | Fish Audio は推論スタックを再構築し、すべての開発者に S2.1 Pro を無料で提供しました

音声 AI にコストがかかる真の理由

音声 AI の推論には、価格表では説明されない構造的な問題があります。それは、自己回帰デコードがデフォルトで GPU 利用率と極めて相性が悪いということです。

TTS API の呼び出しが発生するたびに、オーディオトークンを1ステップずつ生成するデコードループが走ります。各ステップは小さな行列乗算（実際には M ≤ 128）であり、その後にそのシーケンスの KV キャッシュのメモリ読み取りが続きます。メモリサブシステムが追いつく間、CUDA コアのほとんどはアイドル状態になります。3万ドルの H200 を使用していても、計算能力にお金を払っているのにメモリのストールでそれを無駄にしているのです。

同時実行数が低いと、この状況はさらに悪化します。単一リクエストのデコードループは、スケジューリングのオーバーヘッドによって分断された 10〜20μs のバーストで GPU を占有します。ナイーブに構築された TTS エンドポイントの同時実行数 c=1 での GPU 利用率は 10% を下回ることがあります。ハードウェアは存在していますが、仕事がそれを満たしていません。

業界のこれまでの答えは、文字単位の課金を通じてそのコストを開発者に転嫁することでした。私たちの答えは、インフラレイヤーで利用率の問題を解決することでした。1枚の GPU で以前は4枚必要だった作業ができるようになれば、無料枠の提供が経済的に可能になります。

それを実現するために必要だったことは以下の通りです。

エンドツーエンドの最適化：フルスタックへのアプローチ

単一の変更で4倍の効率向上は得られません。全てのレイヤーを同時に最適化し、それらを複合させることで成果が得られました：

• カスタム CUDA カーネル — トークンごとの計算の無駄を排除
• FP8 量子化 — メモリ帯域幅の圧迫を半分に削減
• コンティニュアス・バッチング（Continuous Batching） — 同時リクエスト間で GPU を隙間なく充填
• GPU スケジューリング — ワークロード間のアイドル容量を排除
• 自社ネットワークとストレージ — クラウドインフラの上乗せコストを排除

以下に各レイヤーの詳細を説明します。最終的なスループットとコストの数値は、これらすべてを組み合わせた結果です。

カスタム CUDA カーネル：fish-scales-ops

なぜ cuBLAS では不十分だったのか

TTS サービスにおけるデコード形状（M ≤ 128）は、cuBLAS や PyTorch の GEMM カーネル、あるいは torch.compile さえも最適化のターゲットとしている形状ではありません。これらのライブラリは、学習や大規模バッチのプリフィル（M が数千単位）をターゲットにしています。M が小さい場合、それらはメモリ帯域幅を十分に活用できず、デコードバッチサイズでのみ可能なフュージョンの機会を逃してしまいます。

具体的な課題：M=1（単一リクエストのデコード）での SwiGLU MLP フォワードにおいて、cuBLAS の scaled_mm は、アクティベーション、ゲート乗算、ダウンプロジェクションという3つの個別のカーネル起動を発行し、それぞれの間で中間結果が HBM（高帯域幅メモリ）に書き込まれ、再度読み込まれます。M=1 では、このラウンドトリップがボトルネックとなり、計算そのものは問題になりません。

このギャップを埋めるために、私たちは fish-scales-ops を構築しました。これは NVIDIA Hopper (H200, sm_90a) および Blackwell (sm_120a) アーキテクチャをターゲットとした、プロダクショングレードの FP8 GEMM および FlashAttention ライブラリであり、オープンソースとして公開しています。

FP8 量子化戦略

異なる世代のハードウェアに対して、2つの量子化スキームを実装しました：

bsgemm (128×128 ブロックスケール FP8)：H200/Hopper 用。128×128 の粒度でのブロックスケーリングにより、テンソル単位の量子化のような精度リスクを伴わずに、良好な数値安定性を得られます。

mxfp8 (1×32, OCP UE8M0 フォーマット)：Blackwell (RTX 5090, RTX 6000 PRO) 用。32要素共有指数によるマイクロスケーリング（OCP MX 標準）により、オーディオトークン生成において重要なスケールで、よりきめ細かな数値精度を実現します。

mxfp8 パスの開発中、デバッグに多大な時間を要した意外なバグがありました。quantize_blockscale.py が safetensors の互換性のために .contiguous() を使って weight_scale テンソルを実体化していましたが、linear_mxfp8_raw は K メジャーのストライド (1, N) でスケールを読み取ります。行メジャーで連続した [N, K/128] をロードしたため、すべての GEMM がフルスピードでありながら誤ったロジットを生成してしまいました。その結果、下流のサンプリングが単一の繰り返されるセマンティックトークンにモード崩壊してしまいました。これは一見モデルの品質問題に見えますが、実際にはメモリレイアウトのバグでした。修正は MXFP8LinearMethod.process_weights_after_loading での再ストライドでした。修正後、最初の5つのオーディオフレームにおいて、グリーディデコードの結果が bf16 とトークン単位で完全に一致しました。

カーネル・ベンチマーク結果

デコード形状（M ≤ 128）において、同等のハードウェアを用いた内部ベンチマーク結果（詳細は fish-scales-ops リポジトリを参照）：

• MXFP8 パスは、1024³ から 16384³ までの10個の正方形状のうち 8個で torch.nn.functional.scaled_mm を上回り、最大 +21% 高速。
• エンドツーエンドの Qwen3-4B SwiGLU MLP フォワード：M=1 から 4096 のすべての形状で、素の cuBLAS scaled_mm に対して 1.7〜6.2倍高速。
• torch.compile でフューズされた cuBLAS との比較（デコード形状）：2.1〜4.3倍高速。
• sm_120a 上の MXFP8 FlashAttention：PyTorch SDPA デコードに対して 7〜19倍、FlashInfer BF16 に対して 1.2〜2.7倍高速。

利益の大部分を牽引しているのは2つのフューズドカーネルです。1つはアクティベーションの量子化と UE8M0 スケールパックを単一の起動に統合。もう1つは SwiGLU のプロローグをダウン GEMM のアクティベーション量子化に直接統合し、PyTorch が通常2つのオペレーション間で実体化させてしまう BF16 中間結果の書き込みと読み出しを完全に排除しています。

バッチ推論アーキテクチャ：レイテンシとスループットのトレードオフ

自己回帰 TTS のためのコンティニュアス・バッチング

カーネルの効率化はトークンあたりのコストを改善します。バッチングは、その効率をリクエストストリーム全体の GPU 利用率に変換する役割を果たします。

スタティック・バッチング（すべてのシーケンスを同じ長さにパディングし、固定バッチとして実行する手法）は、パディングに計算資源を浪費し、バッチ内の最も遅いシーケンスが終わるまで新しいリクエストをブロックしてしまいます。出力長が可変である TTS では、テールレイテンシのペナルティが大きくなります。

私たちは sglang を参考に調整したコンティニュアス・バッチングを採用しています。新しいリクエストは、バッチの境界を待つことなく、スロットが空き次第アクティブなデコードバッチに参加します。GPU のデコードループが、一部の遅いリクエストによって停止することはありません。

DualAR: S2 固有のバッチング制約

S2.1 Pro の DualAR アーキテクチャは、 coarse コードブック、次に fine コードブックという2段階でオーディオトークンを生成し、各ステップを条件付けるスライディング previous_tokens ウィンドウを使用します。これにより、標準的な LLM のバッチングにはない正当性の制約が生じます。prev_tokens_shift_inplace カーネルには厳密な形状/データ型のコントラクト（prev int32 [bs, W, cw], next_tokens int32 [bs, cw]）が必要です。呼び出し側での形状操作（.unsqueeze() や暗黙的な型昇格など）はウィンドウを破壊し、モデルの品質低下と見分けがつかないような劣化音声を生み出します。

音声クローニングのワークロードにおいて、この制約は特に重要です。話者の条件付けも同じデコードパスを通るため、ウィンドウの破損は明らかなノイズではなく、長い出力における話者のアイデンティティのドリフトとして現れます。

スループットの結果

H200, bsgemm FP8, 同時実行数スイープ：

スループットは c=1 から c=64 で約52倍にスケールし、一方で TTFB の増加は 36.6ms（73ms から 110ms）に抑えられています。ほとんどのプロダクション環境では体感できない程度のレイテンシの代償で、GPU は52倍の仕事をこなしています。

c=64 において、1枚の H200 は 8,006 tok/s を維持します。この数値こそが、無料枠を支える直接的なメカニズムです。GPU 1枚あたりのスループットが高まるほど、リクエストあたりのコストは下がります。

これらはすべての無料 API 呼び出しの背後で動いている数値です。開発を始める →

リアルタイムモード：低レイテンシ・ワークロードへのアーキテクチャアプローチ

音声エージェントや対話型アプリケーション向けに、合計スループットよりも最初の音声までの時間（Time-to-first-audio）を優先して最適化した、独立したリアルタイムエンドポイントを提供しています。

核となるアーキテクチャの決定：プリフィル（事前充填）は接続開始時に行われ、レイテンシが重要なパスからは完全に切り離されます。ストリーミングレイテンシの計測は、接続確立時ではなく、最初のオーディオチャンクの送信時から始まります。つまり、プロンプトの長さに応じてスケールするプリフィルコストは、TTFA の数値には一切現れません。

スケジューラレベルでは、ピンポンデザインを採用し、デコードとプリフィルをサイクルごとのホストバリアなしで別々のスレッドで実行しています。このバリアの排除が c≥4 における TTFA 改善の主要因です。ナイーブな実装では、各デコードステップ後のホスト側同期が、本来並列であるべき作業をシリアル化してしまいます。パイプライン化されたデコードループとピン留めされた H2D メモリ転送により、高い同時実行数における TTFB とジッターに対処しています。

詳細な設計とレイテンシの分析は arXiv:2603.08823 に掲載されています。

品質検証：最適化が音声を劣化させないことをどう確認したか

量子化とバッチングは、スループットベンチマークだけでは検出困難な品質低下を引き起こす可能性があります。GPU はフルスピードで動作していても、誤った出力を生成しているかもしれないからです。

mxfp8 の開発中に、まさにその一例に遭遇しました。前述のレイアウトバグにより、カーネルのレイテンシは完全に正常であったにもかかわらず、約 53% の相対ロジットエラーが発生していました。この劣化は出力トークンの分析で初めて判明し、パフォーマンス指標には現れませんでした。

私たちの検証パイプラインには2つのゲートがあります：

正当性ゲート (Correctness gate)：量子化後のグリーディデコードの結果が、固定のリファレンス入力に対して、最初の5つのオーディオフレームで bf16 とトークン単位で完全に一致しなければなりません。最初の数フレームでのトークン完全一致を確認することで、体系的なロジットの破損を捕捉できます。量子化モデルが異なる確率分布を生成している場合、決定論的な入力に対して即座に bf16 から逸脱します。

パフォーマンス劣化ゲート (Performance regression gate)：リクエストあたりの decode_tps が、c=1, c=16, c=64 のすべての同時実行ポイントにおいて、固定されたベースライン数値の 5% 以内に収まらなければなりません。スループットを 5% 以上低下させる変更には、マージ前に明確な理由付けが求められます。このゲートは、デコードループに密かに同期処理を追加してしまうような「正当性修正」からパフォーマンスを守ります。

これら両方のゲートは、推論スタックへのすべての変更に対して実行されます。その結果、S2.1 Pro Free のモデルの重みは有料版と同一であり、量子化された配信パスはデプロイごとに非量子化ベースラインに対して検証されています。

大規模音声クローニング：なぜ推論効率が重要なのか

Fish Audio の音声クローニングは常に無料であり続けてきました。そして、私たちの自己評価および開発者のフィードバックによれば、同クラスで最強であり続けています。83言語にわたる話者の一貫性、自然な韻律、アクセントに左右されない安定したパフォーマンスは、有料版に追加した機能ではありません。それらはベースラインなのです。S2.1 Pro は、今年初めにリリースしたオープンウェイト基盤モデル Fish Speech S2 Pro をベースにしています。

推論の最適化が変えるのは、そのコミットメントを大規模に維持するための経済性です。音声クローニングのワークロードは、標準的な TTS よりもリクエストあたりのコストが高くなります。すべての呼び出しで参照話者のエンベディングを条件付け、可変長の出力にわたって話者のアイデンティティを維持し、それを多言語で一貫して行う必要があるからです。本稿で説明した効率向上がなければ、プロダクション規模での無料音声クローニングは、構造的に高価なワークロードを補助し続けることになります。しかし最適化があれば、その必要はありません。

音声クローニングにおいて特に重要な3つの最適化：

FP8 が話者の条件付けを保護する。 ロジットレベルの破損を捉えるトークン完全一致の検証により、量子化が話者エンベディングの信号を劣化させないことが直接証明されています。クローン出力の話者の一貫性は bf16 ベースラインと同等です。

コンティニュアス・バッチングが混合リクエストを処理する。 プロダクション環境の音声クローニングトラフィックは、参照音声ありのリクエストとなしのリクエスト、多様な出力長、多様な言語が混在しています。コンティニュアス・バッチングはリクエストの種類に関わらずデコードバッチを満たし、ワークロードの不均一性によるペナルティが発生しません。

52倍のスループット・スケーリングが大量生成を可能にする。 1枚の H200 で 8,006 tok/s を達成したことで、オーディオブック、ゲームの対話、ローカライズされたコンテンツなどの大規模なクローン音声ライブラリの生成が、無料枠内でも経済的に実行可能になります。

無料枠に音声クローニングが含まれているのは、最適化によって「支払えるようになった」からではありません。それが常に製品の核であったからであり、ここで説明したエンジニアリングこそが、利用規模が拡大してもその約束を守り続けることを可能にしているのです。音声クローニングをエージェントのワークフローに統合する方法については、弊社の MCP およびエージェントスキル・サポート をご覧ください。

60秒以内に音声をクローンする → 無料で試す

GPU インフラストラクチャ：スタックの所有

ハードウェアと調達

弊社の GPU クラスターは、複数のデータセンターにまたがって約500枚のカードで運用されています。マルチ DC トポロジーの採用は、信頼性のためである以前に、調達上の判断でした。GPU の供給と価格は不安定であり、単一ベンダーへのロックインはその変動を直接吸収することを意味します。マルチベンダー、マルチ DC での調達は、運用上の複雑さと引き換えに、価格リスクと供給制約を同時にヘッジします。

推論用には混合フリートを運用しています。H200 SXM5 は、bsgemm FP8 の合計スループットが支配的となる高同時実行のプロダクション配信を担当します。RTX 5090 と RTX 6000 PRO (sm_120a) はエッジエンドポイントを担当します。c=64 において、5090 mxfp8 は 5,869 tok/s を達成し、カードあたりのハードウェアコストを大幅に抑えつつ、H200 bsgemm の約 71% のスループットを実現しています。

sm_120a のデプロイには1つの意外な修正が必要でした。当初 32GB GPU 用に設定していた cuda_graph_max_bs = 24 という制限が、高同時実行時に深刻なスループットの低下（c=32 で約 31 tok/s/req、c=64 で約 35 tok/s/req）を引き起こしていました。この制限を min(max_running_requests, 64) に引き上げることで、スループット曲線は完全に回復しました。根本的な原因は、bs=24 での CUDA グラフキャプチャが、c=32 以上で実際に発生するデコードバッチサイズにおいて GPU を過小利用させていたことにありました。

GPU スケジューリング：アイドル容量の排除

推論専用クラスターにおけるベースラインの GPU 利用率は約 50% です。推論トラフィックは本質的にバースト性があり、オフピーク時間、学習実行の間、データセットのロードフェーズ中などに GPU はアイドル状態になります。

私たちは、Kubernetes（推論用）と Slurm（学習用）の2つの並列スケジューリングシステムを運用していますが、共通の原則があります。それは、データクリーニングと前処理ジョブを、両方のクラスターで最も優先度の低い「エラスティック・フィル・ワーク（隙間仕事）」として実行することです。クリーニングジョブは、推論や学習が使用していないときにアイドル状態の GPU 容量を占有します。これらはチェックポイント保存が可能で、即座にプリエンプト（一時停止・退避）できるため、実際のリクエストが到着した際にも正当性のコストなく即座に消滅します。

優先順位：K8s クラスターでは「推論 > クリーニング」、Slurm では「学習 > クリーニング」。推論側のオートスケーラーは時間ベースのヒューリスティックではなく実際のトラフィック信号を使用するため、負荷が高まると同時にクリーニングジョブが追い出されます。

結果として、GPU 利用率は 約50% から 90% 以上 に向上しました。クラスター規模で見れば、この差分は推論リクエストあたりの実効コストをほぼ半減させます。ハードウェア予算は固定されていますが、それに対して2倍のリクエストを処理できるようになったからです。

ネットワーク・インフラストラクチャ

弊社は自社ネットワークを運用しています。ISP からの直接の帯域調達、ASN の取得、300Gbps の接続性、そして Cloudflare とのピアリングを行っています。これには TTS 特有の2つのコストメリットがあります。

TTS 規模でのエグレス（データ送信）は無視できないコストです。クラウドプロバイダーのエグレス料金は構造的に高利益率に設定されていますが、ネットワークレイヤーを自社で所有することで、その上乗せ分を完全に排除できます。

レイテンシが2つ目の理由です。ネットワークの往復におけるすべてのミリ秒が、ユーザーが体感する TTFB に現れます。Cloudflare とのピアリングにより、Fish Audio のエンドポイントは、世界の API トラフィックのかなりの部分を占める Cloudflare ネットワークを経由するユーザーの近くに配置されます。マルチ DC 展開により、ほとんどのリクエストはパブリックなインターネットをフルに横断することなく、近くの推論ノードに到達します。

ストレージ：階層化アーキテクチャ

学習データ、モデルのチェックポイント、推論キャッシュは、それぞれアクセスパターンもコスト要件も異なります。弊社は3層アーキテクチャを使用しています：

• ホット（NVMe フラッシュ）: アクティブな学習データ、配信用のモデルの重み
• ウォーム（フラッシュ/HDD 混合）: 最近のチェックポイント、前処理済みのデータセット
• コールド（自社運用の Ceph HDD クラスター）: 過去の学習データ、長期保存用

コールドティアは、大量のデータ保存においてサードパーティのオブジェクトストレージを代替しました。コールドストレージの前面にあるローカルキャッシュレイヤーにより、学習データのパイプラインで一般的な繰り返しの読み取りは、コールド HDD ではなく NVMe から提供されます。

結論：このスタックが生み出すもの

すべてのレイヤーを横断した結果：

• カスタム FP8 カーネル：デコード形状において標準的な cuBLAS より 2.1〜4.3倍高速
• コンティニュアス・バッチング：c=1 から c=64 で 52倍のスループット・スケーリング、レイテンシ増加はわずか 37ms
• GPU スケジューリング：利用率を 約50% → 90% 以上 へ向上。リクエストあたりのコストをほぼ半減
• 自社所有インフラ：計算、ネットワーク、ストレージからクラウドの上乗せコストを排除

これらを組み合わせることで、以前は H200 が4枚必要だったリクエスト量を、現在は1枚で処理しています。この4倍の効率向上が、無料枠を経済的に持続可能なものにしています。これは補助金によるものではなく、構造的なコスト削減によるものです。無料アクセスの提供は、ユニットエコノミクスが機能していることを反映しています。現在の提供状況については 価格プラン をご確認ください。

Fish Audio の推論スタックの比較

インフラデータは、2026年6月時点の公開ドキュメント、GitHub リポジトリ、エンジニアリングブログに基づいています。

パターンは一貫しています。Fish Audio は、推論アーキテクチャを公開し、カーネルライブラリをオープンソース化し、具体的なスループットの数値を公表している唯一の主要 TTS プロバイダーです。「非公開」であることは批判ではなく、何が検証可能であるかについての事実です。プロバイダー間の音声品質の独立した評価については、弊社のブラインド TTS プロバイダー比較をご覧ください。

何がオープンソース化されているか

fish-scales-ops が現在公開されています。Hopper および Blackwell 用の FP8 GEMM および FlashAttention であり、プロダクショングレードで、CUDA Graph キャプチャセーフです。

H200 や RTX 5090/6000 PRO 上で自己回帰モデルの推論インフラを構築している場合、標準的なライブラリに対するデコード形状でのパフォーマンスギャップは現実のものであり、これらのカーネルがそれを埋めてくれます。

ライブラリの内容：

• FP8 GEMM：Hopper 用の bsgemm (1×128 act × 128×128 wgt)、Blackwell 用の MXFP8 1×32 (OCP UE8M0)
• sm_120a 用の MXFP8 FlashAttention：連続したプリフィル、ページド・プリフィル（拡張）、ストライド 0 の K/V ブロードキャストによるネイティブ GQA を備えたページド・デコード
• 全体を通して CUDA Graph キャプチャセーフ

次のステップ

B300 への対応がロードマップに含まれています。Blackwell 上のネイティブ FP8 テンソルコアと NVLink 5 の帯域幅は、スループット曲線をさらに押し上げるでしょう。

推論の最適化は続きます。 固定されたベンチマークの数値は、超えるべきものであり、ゴールではありません。すべての同時実行ポイントが、さらなる改善の対象です。

配信スタックのさらなる部分（sglang_lite の修正、DualAR 固有のバッチングロジック、sm_120a の CUDA グラフ処理など）も、安定し次第オープンソース化の候補となります。無料枠を持続可能にしているこのインフラこそ、コミュニティに活用してほしいインフラなのです。

無料 TTS API を使い始める

モデル文字列：s2.1-pro-free。既存の Fish Audio API 呼び出しからヘッダーを1つ変更するだけです。

python

import httpx

body = {
    "text": "こんにちは、世界！",
    "reference_id": "your_model_id",
    "format": "mp3",
}

with httpx.Client() as client:
    res = client.post(
        "https://api.fish.audio/v1/tts",
        headers={
            "Authorization": "Bearer <YOUR_API_KEY>",
            "Content-Type": "application/json",
            "model": "s2.1-pro-free",
        },
        json=body,
    )

res.raise_for_status()

with open("output.mp3", "wb") as f:
    f.write(res.content)

JavaScript

import { writeFile } from "fs/promises";

const body = {
  text: "こんにちは、世界！",
  reference_id: "your_model_id",
  format: "mp3",
};

const res = await fetch("https://api.fish.audio/v1/tts", {
  method: "POST",
  headers: {
    Authorization: "Bearer <YOUR_API_KEY>",
    "Content-Type": "application/json",
    model: "s2.1-pro-free",
  },
  body: JSON.stringify(body),
});

if (!res.ok) {
  throw new Error(`TTS request failed: ${res.status} ${await res.text()}`);
}

const buffer = Buffer.from(await res.arrayBuffer());
await writeFile("output.mp3", buffer);

83言語対応。ハードな使用制限なし。クレジットカード不要。音声クローニング込み。

他のあらゆる最先端 TTS API は最初の1トークンから課金されます。S2.1 Pro は違います。

60秒以内に音声をクローンする →

API ドキュメント全文 →