この記事の要点
- VRAMを一番使うのは生成中ではなく、モデルを読み込んでいる最中。測った範囲では、読み込み中のピークが生成中のピークを上回った。
- カードで分かれるのは容量ではなく生成時間。測った4条件では、文字数の順ではなく、生成された音声が長い条件ほど2枚の差が開いた。
- 日本語向けのチェックポイントへ差し替えると、今回比較できた範囲では読み込み後に残る量はほぼ変わらず、明確に増えたのは読み込み中のピークだった。その値は、配布ファイルの大きさに読み込み後に残る量を足すと見当が付く。
F5-TTSに要るGPUメモリと、カード別の生成時間
F5-TTSをローカルで動かすとき、VRAMを一番使うのは生成中ではなく、モデルを読み込んでいる最中である。既定のF5TTS_v1_Baseでは、読み込み中にtorchが割り当てた量が約1,990 MiBまで上がった。同じ指標で測った生成中のピークは、最も長い日本語185字（音声51.69秒）でも1,082.2 MiBで、読み込み中の半分ほどにとどまる。ここで言えるのはこの51.69秒までの範囲で、それより長い生成や別の条件までは測っていない。
2枚で差が出るのは生成時間のほうである。同じ文を読ませたとき、RTX 5060 Ti は RTX 5080 の1.73倍から1.99倍の時間がかかった。測った4条件では、文字数の順ではなく、生成された音声が長い条件ほど倍率が上がっている。ただし音声が長い条件は文の分割数も多く、どちらが効いているかはこの4点では分けられない。
なお、既定のチェックポイントに日本語を読ませた出力は、2026年9月22日の測定では文字起こしで中国語と判定される状態だった。速度とVRAMより先に、この点が問題になる。
測定の前提と、測っていない軸
測定は2026年9月22日に行った。条件はF5-TTS 1.1.22、チェックポイントがF5TTS_v1_Base、生成ステップ数32、参照音声は同梱のbasic_ref_en.wavである。暖機を1回回したあと3回走らせ、中央値を採っている。GPUはRTX 5080 16GBとRTX 5060 Ti 16GBの2枚で、画面はRTX 5080に繋いでいる。RTX 5080はマザーボードのPCIe x16に挿しており、RTX 5060 TiはOCuLink（PCIe x4）で外付けしている。接続が細いぶん、GPUへデータを送る時間が絡む値、つまり読み込みにかかる時間には、この接続経路の違いが乗っている可能性がある。ここは切り分けていない。生成そのものはカードに載ったあとの計算なので、この経路の影響は小さいと見ているが、それも測って確かめてはいない。日本語向けのチェックポイントを扱う節だけは、参照音声も別のものを使っている。
torchは2.11.0+cu128を使った。2026年9月22日の時点で公開されている系列は2.14.0まで進んでおり、torchaudio 2.11はそれ以降のtorchでも動くため、同じ手順を今日踏む場合は別の組み合わせになりうる。推論はボコーダにvocosを使う既定の構成で、モデル本体の重みは半精度でGPUへ載る。ライセンスは、コードがMIT、事前学習済みの重みがCC-BY-NCである。日本語向けのチェックポイントも非商用だが、配布ページのメタデータは継承条件の付くCC BY-NC-SA 4.0、同じモデルカードの本文と公式の派生モデル一覧はCC BY-NC 4.0で表記が割れている（2026年9月22日時点）。商用で使わないのはどちらでも同じだが、再配布や改変をするなら配布元のページで条件を確かめることになる。
文字起こしによる確認にはfaster-whisperのlarge-v3を使った（compute_type float16・beam_size 5）。Whisper自体の必要VRAMと文字起こし速度はWhisperをローカルで動かす必要スペック｜large-v3とturboの必要VRAM・文字起こし速度を実測で測っている。
測り方も書いておく。生成時間は、各回の前後で torch.cuda.synchronize() を呼んでから time.perf_counter() で挟んだ区間である。CUDAの処理は非同期なので、これを挟まないと実際より短く出る。torchのピークは各回の前にreset_peak_memory_stats() を呼び、生成後に max_memory_allocated() を読んだ値。nvidia-smi の値は生成直後に1回だけ取っており、連続して見張ってはいない。つまり一瞬だけ上がる山は取りこぼしうる。RTFは走行ごとに計算した値の中央値で、表に出ている生成時間を音声の長さで割った値とは端数が合わないことがある。ロードの測定はプロセスを分けて1回ずつ行い、同じプロセスで2回読み込んではいない。
測っていない軸も挙げておく。人が聞いたときの音質と自然さ、長時間の連続生成、他の音声合成との速度やVRAMの比較、単精度のまま載せた場合や量子化した場合の差は、いずれもこの測定の外にある。本記事の実測値は2026年9月22日時点・当該構成での測定に基づく。
読み込みで要る量と、そのあと残る量
F5TTS_v1_Baseのチェックポイントをsafetensorsライブラリで開き、入っているテンソルの要素数を合計すると337,096,838だった。ファイルサイズは1,348,435,761バイトである。これは配布元が公称しているパラメータ数ではなく、学習対象のパラメータだけを数えた値でもない。チェックポイントに入っている全テンソルの要素数を足した自前の計数で、2026年9月22日にHugging Faceから取得したファイルで数えている。
保存は単精度なので、337,096,838要素×4バイトがファイルサイズとほぼ一致する。推論時にGPU上へ残るモデル本体の重みは半精度になるため、同じテンソルはGPU上でおよそ半分、計算上は約643 MiBになる。実測の703.8 MiB（読み込み後にtorchが割り当てた量）は、それより約61 MiB大きい。この差は、単精度のまま載るボコーダなどチェックポイント以外の割り当てが703.8 MiBに含まれるためで、内訳までは切り分けていない。半精度になるのはボコーダにvocosを使う場合で、bigvganを選ぶとモデル本体も単精度で載る。
カード全体で見ると、読み込みの前後で使用量はRTX 5080が645 MiBから1,431 MiBへ、RTX 5060 Tiが114 MiBから868 MiBへ増えた。増分は786 MiBと754 MiBで、torchが割り当てた703.8 MiBより大きい。
読み込みと生成のGPUメモリを並べた実測値は以下のとおり。
| 項目 | RTX 5080 | RTX 5060 Ti |
|---|---|---|
| モデル読み込み前（nvidia-smi） | 645 MiB | 114 MiB |
| モデル読み込み後（nvidia-smi） | 1,431 MiB | 868 MiB |
| 読み込みで増えた分 | 786 MiB | 754 MiB |
| 読み込み後にtorchが割り当てた量 | 703.8 MiB | 703.8 MiB |
| 読み込みにかかった時間 | 2.90秒 | 3.71秒 |
| 生成ピーク・日本語30字（torch） | 771.8 MiB | 771.8 MiB |
| 生成ピーク・日本語86字（torch） | 870.7 MiB | 870.2 MiB |
| 生成ピーク・日本語185字（torch） | 1,082.2 MiB | 1,082.4 MiB |
| 生成直後（nvidia-smi） | 1,941 MiB | 1,386 MiB |
| カードの総容量 | 16,303 MiB | 16,311 MiB |
nvidia-smiの値は画面出力に使われている分を含むので、2枚のカードの値をそのまま並べて比べられない。読み込みにかかった時間も、RTX 5060 TiをOCuLinkで繋いでいるぶんが乗っている可能性があり、カードの速さの差としては読めない。torchのピークはテンソルに割り当てられた量で、CUDAの実行に要る分やアロケータが確保したまま使っていない分は含まない。
そして、読み込みが終わったあとに残る量と、読み込みの最中に要る量は別の数字である。既定のチェックポイントでは、読み込み中にtorchが割り当てた量のピークが1,990 MiBまで上がった（RTX 5080で3回測り、3回とも同値）。読み込みの実装が、ファイル内のテンソルを保存されたままの単精度でいったんGPUへ展開する。そこから半精度の重みを用意し終えるまで元のテンソルを抱えたままになるので、2つが同時に載っている一瞬がピークになる。単精度で展開した分と残る703.8 MiBを足すと実測の1,990 MiBにほぼ一致する。カードに収まるかを見るときは、残る量ではなくこちらを使う。
今回の3条件では、長い生成ほどピークが上がった
生成中にtorchが割り当てた量のピークは、RTX 5080で日本語30字が771.8 MiB、86字が870.7 MiB、185字が1,082.2 MiBと、長い文ほど増えた。ただし測った3点はいずれも日本語で、日本語では文字数と生成される音声の長さがほぼ同じ向きに動く。この3点では、どちらの軸で増えているかを分けていない。
ピークは一瞬の上限であって、その量を最初から最後まで占有し続けるわけではない。またtorchが割り当てた量と、nvidia-smiが示すカード全体の使用量は別の数字で、その差は2つに分かれる。1つはどちらのカードにも乗る分である。画面を繋いでいないRTX 5060 Tiでも、torchのピーク1,082.4 MiBに読み込み前の114 MiBを足した値より、生成直後にnvidia-smiが示した1,386 MiBのほうが200 MiB近く多い。もう1つは画面を繋いだカードにだけ乗る分で、読み込み前の使用量がRTX 5080で645 MiB、RTX 5060 Tiで114 MiBと、531 MiBの差があった。この531 MiBはF5-TTSとは無関係である。
手元のカードで見積もるときは、この2つを取り違えないようにする。torchの割当値にはCUDAの実行に要る分とアロケータの確保分が含まれない。本測定では、生成直後のnvidia-smiの値と、torchのピーク割当量に生成前の使用量を足した値との差が約200 MiBあった。この2つの値は測定時点も対象範囲も違うので、これを生成のピーク時に必ず要る固定の上乗せ分とはみなせない。差の中身にはCUDAコンテキスト、アロケータが確保したまま使っていない分、別プロセスの割当が入り、画面を繋いだカードとそうでないカードでも変わる。実機では空き容量と総使用量を見て、余裕を取ることになる。画面出力の分はnvidia-smiの使用量にすでに入っているため、空き容量からさらに引く必要はない。ピークの値をそのまま必要量として読まない話は、MiniMax Music 3をVRAM 16GBで動かす｜RTX 5080実測、ピークVRAMは必要量ではないでも扱っている。
そのうえで、ここで見た生成中のピークより、モデルの読み込み中のピーク1,990 MiBのほうが大きい。測った中で最も長い日本語185字（音声51.69秒）でも生成中は1,082.2 MiBで止まっている。この範囲では、VRAMを一番使うのは読み込みのほうだった。これより長い生成でどうなるかは測っていない。
5.0GiBのチェックポイントで、読み込み中は5,855 MiBまで上がる
日本語向けのチェックポイントは配布ファイルが5,398,148,344バイトあり、既定の1,348,435,761バイトの約4倍ある。RTX 5080で両方を読み込んで比べると、読み込み後にtorchが割り当てた量は703.8 MiBと704.7 MiBでほぼ変わらず、差が出たのは読み込み中のピークとロード時間だった。
| 項目 | 既定のチェックポイント | 日本語向けのチェックポイント |
|---|---|---|
| 配布ファイルの大きさ | 1,348,435,761バイト | 5,398,148,344バイト |
| 読み込み中のピーク（torch） | 1,990 MiB | 5,855 MiB |
| 読み込み後にtorchが割り当てた量 | 703.8 MiB | 704.7 MiB |
| 読み込みにかかった時間 | 2.9秒 | 4.1秒 |
日本語向けのチェックポイントは参照音声が別なので、生成時間も生成中のピークも、2つのチェックポイントを並べて比較できない。比べられるのは配布ファイルの大きさと、読み込みにまつわる3つの値にとどまる。読み込みにかかった時間はファイルを読んでGPUへ載せるまでの時間で、生成の速さではない。ロード時間は3回の中央値、読み込み中のピークは3回とも同値だった。
読み込みのところに差が出る理由はファイル形式にある。日本語向けのチェックポイントは学習途中の状態を含む.ptファイルで、最適化器や学習率スケジューラの状態も一緒に入っている。現行の実装は、読み込み先としてGPUを指定してこのファイルを読むため、チェックポイント内のテンソルはいったんGPUへ展開される。そのうえで推論に使う移動平均の重みだけを取り出し、チェックポイント全体を捨てる。読み込みが終わったあとに残るのが取り出した重みだけなので、ピークと残る量がこれだけ離れる。
今回の2つのチェックポイントから見える目安は1つある。読み込み中のピークは、配布ファイルの大きさに読み込み後に残る量を足した値に近かった。ファイルの大きさをMiBに直した値に読み込み後に残る量を足すと、既定・日本語向けのどちらも実測のピークにほぼ一致する。一方で、読み込みが終わったあとに残る量はファイルの大きさに比例しない。約4倍のファイルでも、残る量はほぼ同じだった。ただしこの対応関係は、読み込み先にGPUを指定してファイルを一括で読むF5-TTSの読み込み処理で見たものである。重みを分割して流し込むソフトでは同じようには当てはまらない。
測定条件を1つ添えておく。日本語向けのチェックポイントは、公式の派生モデル一覧（SHARED.md）が推論時のアーキテクチャ設定と専用の語彙ファイルを指定しており、設定は既定のものとは別である。本測定はその指定どおりの設定と語彙ファイルで読み込んでいる。この一覧に載っているのは第三者が作った派生モデルで、配布者自身が予備的な試みだと説明している。この設定や語彙ファイルを取り違えても、モデルの読み込みは成功し、警告もエラーも出ないが、出力は崩れる。
2枚のカードで何倍違うか
同じ4本の文を2枚のカードで生成した時間と、そこから計算したRTFを並べた。RTFは生成時間を生成された音声の長さで割った値で、小さいほど速い。
| 生成テキスト | 音声の長さ | RTX 5080 | RTX 5080のRTF | RTX 5060 Ti | RTX 5060 TiのRTF | 5060 Ti / 5080 |
|---|---|---|---|---|---|---|
| 日本語 30字 | 8.56秒 | 1.08秒 | 0.126 | 1.87秒 | 0.218 | 1.73倍 |
| 英語 162字 | 15.44秒 | 1.51秒 | 0.098 | 2.88秒 | 0.187 | 1.91倍 |
| 日本語 86字 | 23.86秒 | 2.42秒 | 0.102 | 4.73秒 | 0.198 | 1.95倍 |
| 日本語 185字 | 51.69秒 | 5.50秒 | 0.106 | 10.93秒 | 0.211 | 1.99倍 |
「5060 Ti / 5080」の列は、「音声の長さ」の列の順に並べると1.73倍・1.91倍・1.95倍・1.99倍と上がっていく。文字数の順（30字・86字・162字・185字）とは一致しない。英語162字の行は、文字数では日本語86字より多いのに音声は短く、倍率も日本語86字より小さい。
ただしこの4条件は、音声の長さだけが違うのではない。F5-TTSは読ませる文を句読点で区切り、参照音声と参照テキストから計算した上限バイト数に収まるようまとめてから、まとまりごとに生成して0.15秒ずつ重ねてつなぐ。上限は固定値ではなく、本測定の参照音声では156バイトだった。測った4条件のまとまりの数は、日本語30字が1、英語162字が2、日本語86字が3、日本語185字が6で、音声の長さと同じ順に増えている。倍率はどちらの順でも単調に上がるので、この4点では音声の長さとまとまりの数を分けられない。さらに英語の行は言語も同時に変わっている。文字数が倍率を決めているのではない、というところまでは言えるが、何が決めているかはここでは確定していない。
RTFが目立って大きいのは、測った中で音声が最も短い日本語30字の行だけである。RTX 5080では0.126で、残る3行は0.098から0.106に収まる。生成時間に、生成される音声の長さにもカードの速さにも左右されない固定費が含まれていると読めば、音声が短いほど2枚の比が1に寄ることを説明できる。ただし残る3行は音声が長いほうがRTFがわずかに高く、固定費だけではこの並びを説明できない。固定費が何でできているか、短い走行でクロックが上がりきらないといった別の要因が混ざっていないかは切り分けていない。
この表は1台のPC・1本の参照音声での測定である。参照音声、生成ステップ数、読ませる文の内容を変えれば値は動く。まとまり1つぶんの音声の長さは、参照音声の長さと参照テキストのバイト数の比に、そのまとまりのバイト数（UTF-8）を掛けた値で決まる。全体の長さはそれを足し合わせ、重ねたぶんを引いたものになる。したがって文字数だけでは決まらず、参照音声を替えれば同じ文でも長さが変わる。生成した音声の聞こえ方はこの表では扱っていない。
日本語を読ませると、速度ではないところで止まる
既定のモデルに日本語を読ませても、生成時間は英語と同じ水準に収まる。RTX 5080のRTFは日本語30字が0.126、86字が0.102、185字が0.106で、英語162字の0.098と大きな段差はない。問題は速度ではなく、出力そのものが日本語にならなかったことである。
生成した音声をfaster-whisper large-v3（compute_type float16・beam_size 5）へ通した結果と、同じ文をWindows同梱のMicrosoft Haruka Desktopに読ませた対照を並べた。
| 音源 | 言語判定 | 文字誤り率 | 聴いた判定 |
|---|---|---|---|
| F5-TTS 英語162字（対照） | 英語（確率1.00） | 0.000 | （英語のため対象外） |
| Haruka 日本語30字（対照） | 日本語（確率1.00） | 0.000 | 日本語として聞き取れた |
| F5-TTS 日本語30字 | 中国語（確率0.82） | 0.750 | 中国語のように聞こえた |
| F5-TTS 日本語86字 | 中国語（確率0.97） | 0.950 | （聴取は30字のみ） |
| F5-TTS 日本語185字 | 中国語（確率0.95〜0.99） | 0.971 | （聴取は30字のみ） |
この表が示すのは自動の文字起こしがどこまで戻せたかであって、人が聞いたときの品質ではない。聴取で判定したのは日本語として聞き取れるかの1点のみで、音質や自然さは判定していない。言語判定は言語を指定しない実行、文字誤り率は言語を指定した実行の値で、別々の実行から取っている。Harukaは方式の違う音声合成なので、対照に使ったのは言語判定と文字誤り率だけで、速度もVRAMも比べていない。
既定の重みで日本語がこうなる背景には3つの要素がある。前処理では、分かち書きした断片がすべて3バイトの文字で構成される場合、その断片が中国語の読みを返す処理にかけられ、漢字がピンインへ置き換わる（仮名は変換対象にならず、そのまま残る）。学習データは、論文が述べるとおり、転写の失敗と言語の誤判定を除いたEmiliaの英語と中国語の約95K時間である。公式の派生一覧も、既定の重みの学習データを同じEmiliaのEN/ZHと記載している。同梱の語彙ファイルは2,545行で、ひらがな86文字中27文字、カタカナ86文字中19文字が含まれておらず、欠けている文字には「い」「て」「ふ」「ほ」が入る。ただし語彙に無い文字が推論時にどう扱われるかは追っていないので、この欠落が出力へどう表れるかまでは測れていない。
ハードウェアの話としての結論はこうなる。日本語で使うなら日本語向けのチェックポイントに差し替えることになる。今回比較できた範囲では、読み込み後にGPUへ残る量はほぼ変わらず、明確に増えたのは読み込み中のピークで、5,855 MiBまで上がった。生成側は参照音声を揃えられていないので、2つを並べて比べていない。
漢字がピンインへ変換される経路の詳細、ライセンスの条件、日本語向けのチェックポイントを実際に試した結果は、姉妹サイトのAIツール図鑑で扱う。
動かす前に踏む、FFmpegの落とし穴
F5-TTSの公式READMEは、導入手順のコードブロックの中でFFmpegを入れるよう案内しており、その手段としてconda経由の導入（conda install ffmpeg）を示している。ここを飛ばすか、入れ方を取り違えると、推論に入る前に止まる。
torchaudioは2.9以降、音声の読み込みをtorchcodecへ委譲する設計に変わっており、torchcodecはFFmpegの共有ライブラリを要求する。2026年9月22日の環境（torchaudio 2.11.0）では、実行ファイルだけを含むFFmpegの配布では足りず、OSError: Could not load this library の形でF5-TTSの推論に入る前にエラーが出た。共有ライブラリを含む配布（Windowsでは shared 版と呼ばれる）へ差し替え、その共有ライブラリが入ったフォルダを実行時に見つけられる状態にすると、同じ手順が通った。
分かれ目は、conda経由で入れたかどうかではない。入れたFFmpegの配布に共有ライブラリが含まれているかどうかである。実行ファイル1本だけを同梱した配布は、どの入れ方であってもここで条件を満たさない。見分け方は単純だ。展開したフォルダに、実行ファイルのほかに共有ライブラリのファイルが入っているかを確認すればよい。共有ライブラリが要るという要件は、torchcodecの導入手引きに明記がある。
これはたまたまのバージョンの組み合わせで起きるのではなく設計上の変更なので、torchaudio 2.9以降ではこの経路が既定になる。2.8以前の環境ではここに当たらない。
16GBクラスで、上位カードに払う価値があるか
測った2枚では容量が不足しなかったので、どちらを選ぶかは生成時間と、他のものと同居させるかどうかで決まる。ただし確かめたのは16GBのカード2枚だけで、より少ないVRAMのカード、CPUだけでの実行、必要なシステムメモリ、OSごとの動作条件は測っていない。配布元も一律の最低GPU容量を示していない。
生成時間の差は1.73倍から1.99倍で、測った4条件では文字数の順ではなく生成された音声の長さの順に倍率が上がった。ただしこの倍率は、RTX 5060 TiをOCuLinkで外付けした構成で測っている。同じカードをマザーボードのスロットへ直接挿した場合は測っていない。実測では、音声8.56秒の生成がRTX 5060 Tiで1.87秒、音声51.69秒の生成が10.93秒だった。今回の実測では、音声が長い条件ほど、2枚の差は秒数でも倍率でも大きかった。ただし音声が長い条件は文の分割数も多いので、どちらが効いているかはこの4点では分けられない。
公称の総グラフィックス電力はRTX 5080が360W、RTX 5060 Tiが180Wである。これはメーカーが公表しているリファレンスの仕様で、上限の定格である。1回の生成あたりの消費電力量ではないし、カードのメーカーによって変わりうる。本測定ではRTX 5080のほうが1.73倍から1.99倍速く終わっているため、同じ仕事あたりで定格どおりの差がそのまま出るとは限らない。電力も価格も本記事では測っていない。
同居については、nvidia-smiが示すカード全体の値が、読み込み前から載っていた分を含む合計であることに注意が要る。F5-TTS自身が足す分はそれより小さい。ただし読み込みが終わったあとに増えていた786 MiB（RTX 5080）と754 MiB（RTX 5060 Ti）は、同居できるかを決める数字ではない。空きが要るのは読み込みの最中のほうで、torchの割当1,990 MiBのほかに、割当へ入らない分も要る。当環境で見えた差は200 MiB前後だったが、測定時点も対象範囲も違う値なので固定の上乗せ分としては使えず、環境によっても変わる。もっとも、VRAMが足りていてもGPU計算の取り合いで遅くなることはある。その形はローカルLLM常駐中にWhisperで文字起こしを回すと何が詰まるか｜VRAMは足りてもGPU計算の取り合いで遅くなるで扱っている。
ここまでの数字は、実際に測ったRTX 5080（マザーボードのスロット）とRTX 5060 Ti（OCuLink）の2枚についてのものである。別のカードで何倍になるかは、この測定からは出てこない。
