Windows 10 / RTX 3070 benchmark report - 2026-08-04
Purpose
This report documents local Windows benchmark runs performed against tts-bench,
including completed result sets and reproducible timeout/performance anomalies.
It is intended as the body of a GitHub issue for the repository maintainer.
Test environment
- OS: Microsoft Windows 10 Home, 10.0.19045 (build 19045)
- CPU: AMD Ryzen 9 3900XT, 12 physical cores / 24 logical processors
- RAM: 31.92 GB
- GPU: NVIDIA GeForce RTX 3070, 8 GB VRAM
- NVIDIA driver: 610.74
- Python: 3.11.9
- Repository revision: cf50de2 (2026-08-03, "Add interactive charts to scores page")
- Results rig label: windows-3070
- Date: 2026-08-04
All model caches, temporary files, generated WAV files, and benchmark result
directories were configured under D:. The repository and results were run from:
D:\prueba\tts-bench
The latest repaired default-voice batch metadata is available locally at:
results\2026-08-04_0808\meta.json
Completed local result collections
These collections completed without failed rows and remain preserved locally.
windows-default
- 189 / 189 successful rows
- 11 models: chatterbox, chatterbox_turbo, inflect_micro, inflect_nano,
kittentts, kokoro, lfm2_audio, piper, scyllasband, soprano, supertonic
- Local artifact: results\windows-default\results.csv
windows-cloning
- 117 / 117 successful rows
- 9 models: dia, echo, longcat_1b, miratts, openvoice, qwentts_fast,
styletts2, wavtts, zonos
- Local artifact: results\windows-cloning\results.csv
Repaired remaining Windows default-voice batch
Command configuration:
- Models: pocket, neutts_air, neutts_nano, f5tts, coqui, qwentts, indextts,
qwentts_06b_custom, vibevoice_15b, outetts
- Devices requested: CPU and CUDA
- Runs per prompt: 3 (cold run plus two warm runs)
- Harness per-cell subprocess timeout: 600 seconds
- Output directory: results\2026-08-04_0808
Overall: 231 successful rows out of 241 rows. The 10 non-success rows are all
caused by a 600-second timeout or a subsequent prompt skipped after a timeout;
there was no model-reported inference exception in these cells.
| Model |
Device |
Successful / rows |
Result |
| coqui |
CPU |
15 / 15 |
Complete |
| coqui |
CUDA |
15 / 15 |
Complete |
| f5tts |
CPU |
6 / 8 |
Prompt 3 timeout; prompt 4 skipped |
| f5tts |
CUDA |
12 / 12 |
Complete (English-only prompts) |
| indextts |
CPU |
6 / 8 |
Prompt 3 timeout; prompt 4 skipped |
| indextts |
CUDA |
6 / 8 |
Prompt 3 timeout; prompt 4 skipped |
| neutts_air |
CPU |
12 / 12 |
Complete (English-only prompts) |
| neutts_air |
CUDA |
12 / 12 |
Complete (English-only prompts) |
| neutts_nano |
CPU |
15 / 15 |
Complete |
| neutts_nano |
CUDA |
15 / 15 |
Complete |
| outetts |
CPU |
3 / 7 |
Prompt 2 timeout; prompts 3-5 skipped |
| outetts |
CUDA |
15 / 15 |
Complete |
| pocket |
CPU |
15 / 15 |
Complete |
| qwentts |
CPU |
15 / 15 |
Complete |
| qwentts |
CUDA |
15 / 15 |
Complete |
| qwentts_06b_custom |
CPU |
15 / 15 |
Complete |
| qwentts_06b_custom |
CUDA |
15 / 15 |
Complete |
| vibevoice_15b |
CPU |
12 / 12 |
Complete (English-only prompts) |
| vibevoice_15b |
CUDA |
12 / 12 |
Complete (English-only prompts) |
Artifacts for this batch:
- results\2026-08-04_0808\results.csv
- results\2026-08-04_0808\meta.json
- results\2026-08-04_0808\report.html
- results\2026-08-04_0808\index.html
Timeout and performance anomalies
The harness timeout applies to the entire model/device/prompt subprocess. With
--runs 3, it covers all three generations together, not each generation
individually. Direct single-run reproductions were performed outside that
600-second outer timeout.
F5-TTS CPU: completes, but exceeds the aggregate timeout
The local benchmark completed prompts 1 and 2 on CPU:
- Prompt 1: 108.49-109.28 s per generation, about 2.5 GB peak RAM
- Prompt 2: 125.35-126.03 s per generation, about 2.5 GB peak RAM
Prompt 3 timed out at the harness limit of 600 s before returning its three
JSON rows. A direct single-run reproduction of the same prompt completed
successfully:
- Generation time: 429.60 s
- Generated audio: 10.25 s
- Peak RAM: 2.70 GB
- Diagnostic WAV: results\f5tts_cpu_p3_diagnostic.wav
Therefore, three prompt-3 generations would require about 1,288.8 s (21.5
minutes), so the timeout is expected. This was not an OOM or paging event:
there was more than 17 GB free RAM after the run and no remaining F5-TTS
processes.
For comparison, the published origin/gh-pages windows-default results identify
a Windows 11 / Ryzen 9 9950X3D / RTX 5090 / 126 GB RAM rig. Its F5-TTS CPU
prompt-3 rows are 77.62-77.99 s per generation for 10.17 s of audio. The local
single-run result is about 5.5x slower for a very similar output duration.
IndexTTS CPU: unusually slow but completes
The local benchmark completed IndexTTS CPU prompts 1 and 2, then timed out on
prompt 3 under the aggregate 600-second limit. A direct single-run reproduction
of prompt 3 completed correctly:
- Total generation time: 346.38 s
- Generated audio: 13.33 s
- Peak RAM: 8.96 GB
- Diagnostic WAV: results\indextts_cpu_p3_diagnostic.wav
IndexTTS's own timing output was:
- GPT generation: 95.78 s
- s2mel diffusion: 191.56 s
- BigVGAN vocoder: 46.32 s
The process was not stuck and did not OOM. During the long run it reached about
8.7 GB resident RAM / 18.6 GB private memory, while pagefile use remained about
0.34 GB. Three generations would require about 1,039.1 s (17.3 minutes).
This is a large discrepancy from the published windows-default CPU rows. The
published prompt 3 completed in 11.07-12.39 s for roughly 14.95 s of audio.
The local direct run is approximately 28-31x slower, despite being a successful
inference. The host hardware differs substantially, but this gap appears too
large to attribute confidently to CPU generation alone and may merit checking
IndexTTS package/runtime versions, CPU backend settings, and model code paths.
IndexTTS CUDA: VRAM-constrained and much slower than published Windows data
The RTX 3070 did complete prompts 1 and 2 on CUDA, but used most of its 8 GB
VRAM:
- Prompt 1: 21.45-24.05 s per generation, 7.35-7.44 GB peak VRAM
- Prompt 2: 44.17-50.17 s per generation, 7.35-7.46 GB peak VRAM
Prompt 3 timed out under the 600-second aggregate limit. The published Windows
rig has an RTX 5090 with 32 GB VRAM and completed its prompt-3 CUDA rows in
12.06-13.74 s. The 3070 result is likely affected by both a much older/slower
GPU and very limited VRAM headroom. This report does not establish whether a
software/runtime difference also contributes.
OuteTTS CPU: expected aggregate timeout on a slow CPU path
The published Windows result collection contains OuteTTS CUDA rows only, so
there is no owner CPU baseline to compare. Locally, OuteTTS CPU prompt 1
completed three times in 146.47-165.14 s per generation. Prompt 2 then exceeded
the 600-second aggregate cell timeout; prompts 3-5 were skipped as designed.
This looks like a timeout-policy limitation for CPU benchmarking, not a model
exception or memory exhaustion. OuteTTS CUDA completed all 15 / 15 local rows.
Environment differences from the published Windows collection
Published origin/gh-pages Windows metadata reports:
- Windows 11 (10.0.26200)
- AMD Ryzen 9 9950X3D, 16 physical / 32 logical cores
- 126 GB RAM
- NVIDIA RTX 5090, 32 GB VRAM
- Python 3.14.4
The local system is considerably smaller and older (3900XT / 32 GB / RTX 3070
8 GB / Python 3.11.9). This clearly explains some performance difference,
especially CUDA performance and VRAM headroom. It does not by itself explain
the unusually large IndexTTS CPU gap, which is why that case is being reported
as an anomaly rather than a conclusion.
Request for maintainer guidance
- Is the IndexTTS CPU path expected to run at roughly 26 RTF on a Ryzen 9
3900XT, or is there a known runtime/version/configuration requirement that
avoids this slow path?
- Were specific IndexTTS versions, CPU thread settings, optional kernels, or
acceleration settings used for the published Windows CPU measurements?
- Would you accept a model/device-specific timeout override for very slow CPU
paths, so successful long prompts are recorded instead of becoming partial
results after a fixed 600-second aggregate timeout?
- For 8 GB GPUs, should IndexTTS CUDA be marked as constrained/unsupported, or
is there a recommended lower-VRAM configuration that preserves comparable
results?
No benchmark results have been published or merged upstream from this machine.
The raw result directories and diagnostic WAVs are retained locally and can be
provided if useful.
Windows 10 / RTX 3070 benchmark report - 2026-08-04
Purpose
This report documents local Windows benchmark runs performed against tts-bench,
including completed result sets and reproducible timeout/performance anomalies.
It is intended as the body of a GitHub issue for the repository maintainer.
Test environment
All model caches, temporary files, generated WAV files, and benchmark result
directories were configured under D:. The repository and results were run from:
D:\prueba\tts-bench
The latest repaired default-voice batch metadata is available locally at:
results\2026-08-04_0808\meta.json
Completed local result collections
These collections completed without failed rows and remain preserved locally.
windows-default
kittentts, kokoro, lfm2_audio, piper, scyllasband, soprano, supertonic
windows-cloning
styletts2, wavtts, zonos
Repaired remaining Windows default-voice batch
Command configuration:
qwentts_06b_custom, vibevoice_15b, outetts
Overall: 231 successful rows out of 241 rows. The 10 non-success rows are all
caused by a 600-second timeout or a subsequent prompt skipped after a timeout;
there was no model-reported inference exception in these cells.
Artifacts for this batch:
Timeout and performance anomalies
The harness timeout applies to the entire model/device/prompt subprocess. With
--runs 3, it covers all three generations together, not each generation
individually. Direct single-run reproductions were performed outside that
600-second outer timeout.
F5-TTS CPU: completes, but exceeds the aggregate timeout
The local benchmark completed prompts 1 and 2 on CPU:
Prompt 3 timed out at the harness limit of 600 s before returning its three
JSON rows. A direct single-run reproduction of the same prompt completed
successfully:
Therefore, three prompt-3 generations would require about 1,288.8 s (21.5
minutes), so the timeout is expected. This was not an OOM or paging event:
there was more than 17 GB free RAM after the run and no remaining F5-TTS
processes.
For comparison, the published origin/gh-pages windows-default results identify
a Windows 11 / Ryzen 9 9950X3D / RTX 5090 / 126 GB RAM rig. Its F5-TTS CPU
prompt-3 rows are 77.62-77.99 s per generation for 10.17 s of audio. The local
single-run result is about 5.5x slower for a very similar output duration.
IndexTTS CPU: unusually slow but completes
The local benchmark completed IndexTTS CPU prompts 1 and 2, then timed out on
prompt 3 under the aggregate 600-second limit. A direct single-run reproduction
of prompt 3 completed correctly:
IndexTTS's own timing output was:
The process was not stuck and did not OOM. During the long run it reached about
8.7 GB resident RAM / 18.6 GB private memory, while pagefile use remained about
0.34 GB. Three generations would require about 1,039.1 s (17.3 minutes).
This is a large discrepancy from the published windows-default CPU rows. The
published prompt 3 completed in 11.07-12.39 s for roughly 14.95 s of audio.
The local direct run is approximately 28-31x slower, despite being a successful
inference. The host hardware differs substantially, but this gap appears too
large to attribute confidently to CPU generation alone and may merit checking
IndexTTS package/runtime versions, CPU backend settings, and model code paths.
IndexTTS CUDA: VRAM-constrained and much slower than published Windows data
The RTX 3070 did complete prompts 1 and 2 on CUDA, but used most of its 8 GB
VRAM:
Prompt 3 timed out under the 600-second aggregate limit. The published Windows
rig has an RTX 5090 with 32 GB VRAM and completed its prompt-3 CUDA rows in
12.06-13.74 s. The 3070 result is likely affected by both a much older/slower
GPU and very limited VRAM headroom. This report does not establish whether a
software/runtime difference also contributes.
OuteTTS CPU: expected aggregate timeout on a slow CPU path
The published Windows result collection contains OuteTTS CUDA rows only, so
there is no owner CPU baseline to compare. Locally, OuteTTS CPU prompt 1
completed three times in 146.47-165.14 s per generation. Prompt 2 then exceeded
the 600-second aggregate cell timeout; prompts 3-5 were skipped as designed.
This looks like a timeout-policy limitation for CPU benchmarking, not a model
exception or memory exhaustion. OuteTTS CUDA completed all 15 / 15 local rows.
Environment differences from the published Windows collection
Published origin/gh-pages Windows metadata reports:
The local system is considerably smaller and older (3900XT / 32 GB / RTX 3070
8 GB / Python 3.11.9). This clearly explains some performance difference,
especially CUDA performance and VRAM headroom. It does not by itself explain
the unusually large IndexTTS CPU gap, which is why that case is being reported
as an anomaly rather than a conclusion.
Request for maintainer guidance
3900XT, or is there a known runtime/version/configuration requirement that
avoids this slow path?
acceleration settings used for the published Windows CPU measurements?
paths, so successful long prompts are recorded instead of becoming partial
results after a fixed 600-second aggregate timeout?
is there a recommended lower-VRAM configuration that preserves comparable
results?
No benchmark results have been published or merged upstream from this machine.
The raw result directories and diagnostic WAVs are retained locally and can be
provided if useful.