企业官网建设流程全解析

F5-TTS 推理加速：TensorRT 与 ONNX Runtime 两条部署路线的实测对比

【免费下载链接】F5-TTSOfficial code for "F5-TTS: A Fairytaler that Fakes Fluent and Faithful Speech with Flow Matching"项目地址: https://gitcode.com/gh_mirrors/f5/F5-TTS

给单卡上的 F5-TTS 挂服务，最直观的体感是请求排队：PyTorch 基线下，一条十几秒音频的合成往往要等 2 秒以上，并发一上来 GPU 却还没吃满。官方仓库在 src/f5_tts/runtime/triton_trtllm/ 给出的 TensorRT 加速路线，把 L20 单卡上的 RTF（实时率 = 推理耗时 / 音频时长）从 0.1467 压到 0.0394，约 3.7 倍提速，2 并发下单请求平均延迟 253ms；另一条更轻量的路线是 ONNX Runtime 推理，vocoder 部分的导出脚本仓库直接给了，DiT 主干则要靠社区实现补全。

30 秒速览

原理速览：两段式管线里，两条路线各自提速在哪

先记住 F5-TTS 的推理是两段式：前端 DiT（Diffusion Transformer）负责流匹配采样，把参考音频 + 目标文本变成 mel 频谱；后端 Vocos 声码器把 mel 还原成波形。两条加速路线作用的位置不同。

TensorRT 路线：引擎编译 + 动态批处理

输入是 PyTorch 权重，处理分两步：trtllm-build把 DiT 编译成 TRT-LLM 引擎（FP16，可选--fp8_linear进一步压线性层精度），trtexec把 vocoder 的 ONNX 编成 TensorRT 引擎；输出是两份硬件绑定的 .engine/.plan 文件。快在三处：算子融合减少 kernel 启动开销、低精度权重省显存带宽、Triton 的动态批处理把并发请求拼成一个 batch 一次前向。

ONNX Runtime 路线：计算图优化 + 后端可换

输入同样是 PyTorch 模型，处理是把计算图固化成 .onnx（官方 vocoder 导出用 opset 17），再用 ONNX Runtime 做常量折叠、图改写和融合优化；输出是同一份 .onnx 可以跑 CPU、CUDA 等后端。vocoder 计算量小，图优化收益有限，这条路真正的卖点是跨平台：一份模型文件在开发机、服务器、边缘设备间直接搬。

动手实操：把两条路线各自跑通

TensorRT 路线：run.sh 一条命令从权重到服务

在 src/f5_tts/runtime/triton_trtllm/ 下：

# 1. 拉起官方镜像（阶段 0-4：拉权重、转引擎、建 Triton 仓库、起服务） MODEL=F5TTS_v1_Base docker compose up # 2. 容器内一条命令走完全流程 bash run.sh 0 7 F5TTS_v1_Base

run.sh 按 0-8 共 9 个阶段执行：阶段 1 用 scripts/convert_checkpoint.py 把 DiT 权重转成 TRT-LLM 格式并trtllm-build出引擎（--max_batch_size 8）；阶段 2 导出声码器 ONNX 并编译 TRT 引擎；阶段 4 启动 Triton；阶段 7 跑离线 benchmark。

• 只要引擎不要服务：bash run.sh 1 4跑到阶段 4 即停
• 自训 fp32 权重：阶段 1 加--dtype float32，否则引擎出来音频会发糊

验证：起服务后用python3 client_http.py发一条 HTTP 请求，或直接bash run.sh 5 5走 gRPC 压测，客户端都在同目录。

ONNX Runtime 路线：vocoder 一条命令，DiT 需要自己搭

vocoder 部分仓库直接支持：

# 导出 Vocos 声码器为 ONNX（opset 17，内含 STFT 自定义算子） python3 scripts/export_vocoder_to_onnx.py --vocoder vocos --output-path vocos_vocoder.onnx

加载侧pip install onnxruntime-gpu后，ort.InferenceSession读入 .onnx，喂 mel 频谱出波形，同一个文件换 CPU 后端只需改 provider 参数。

DiT 主干官方没有导出脚本（README 的 Community 一节列了社区的 F5-TTS-ONNX 实现）。自建的难点在于流匹配采样是 16 步迭代循环，torch.onnx.export时要把循环展开成固定步数，输入按最长参考音频对齐；导出后先用 onnxruntime 加载，把 mel 输出和 PyTorch 逐帧比对一致，再接进推理链路。

实测数据：L20 单卡上的延迟与吞吐

测试环境：单张 NVIDIA L20（24GB），模型 F5-TTS Base + Vocos 声码器，测试集 seed_tts 的 wenetspeech4tts split 共 26 条样本，NFE 16；TensorRT 路线用仓库自带 benchmark.py 与 Triton 客户端，PyTorch 基线同脚本换--backend-type pytorch。

数据来自 src/f5_tts/runtime/triton_trtllm/README.md 的 Benchmark Results 一节。两个值得注意的点：服务端 2 并发的 RTF 比离线单条还低 2%，动态批处理把两条请求拼成一次前向，排队时间被算力复用抵消了；ONNX Runtime 路线官方 benchmark 不覆盖，vocoder 单点加速可参考 scripts/export_vocos_trt.sh 里的 trtexec 参数做同形状对照自测。

选型决策：按你的硬件和场景对号入座

• 如果你是 NVIDIA GPU、要扛并发服务：选 TensorRT 路线，动态批处理 + 引擎编译的组合拳只有它有，2 并发 253ms 延迟是这条线的价值所在
• 如果你同一份模型还要跑在 CPU 或边缘设备：vocoder 走 ONNX Runtime，.onnx 直接搬；DiT 部分在 CPU 上无论哪条路线都不经济，建议边缘端只放声码器或换小模型
• 如果你只做离线批量转音频：TensorRT 离线模式（bash run.sh 7 7）就够，不用起 Triton，省一套服务端运维
• 如果你要压单卡显存：TensorRT 路线加--fp8_linear走 FP8 线性层，代价是音质保真度需要重新听一遍

混合折中：DiT 主力留在 GPU 用 TRT-LLM 引擎，vocoder 单独导出 ONNX 分发给多端，仓库工具链天然支持这种拼接——两条路线在管线里各管一段，不互斥。

避坑清单与收尾

• fp32 训练的权重直接转 fp16 引擎：阶段 1 加--dtype float32
• v0 和 v1 模型结构有差异，F5TTS_Base与F5TTS_v1_Base的 config 参数不同（如text_mask_padding、pe_attn_head），传错会构建失败或输出异常
• TensorRT 引擎和 GPU 型号、TRT 版本强绑定，换卡或升级环境必须重新run.sh 1 2
• 参考音频超过 12 秒会被自动裁剪，建议先截断并在结尾留约 1 秒静音，避免截在词中间
• benchmark.py不传--enable-warmup时首条样本会显著拉高均值，对比数据时两边都开 warmup

一句话收束：TensorRT 路线把 RTF 从 0.147 压到 0.04，ONNX 路线补上跨平台那半块拼图，两条线可以在同一条管线里各管一段。

• 部署文档：src/f5_tts/runtime/triton_trtllm/README.md
• 全流程脚本：src/f5_tts/runtime/triton_trtllm/run.sh
• 压测工具：src/f5_tts/runtime/triton_trtllm/benchmark.py

【免费下载链接】F5-TTSOfficial code for "F5-TTS: A Fairytaler that Fakes Fluent and Faithful Speech with Flow Matching"项目地址: https://gitcode.com/gh_mirrors/f5/F5-TTS