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 秒速览维度TensorRT 路线官方ONNX Runtime 路线vocoder 官方 DiT 社区硬件锁 NVIDIA GPUCPU / CUDA / 多种后端同一 .onnx 通吃上手成本中Docker 一键拉起引擎需分钟级构建低vocoder 一条命令导出DiT 要自己写导出实测 RTFBaseL200.03942 并发服务端官方 benchmark 未覆盖需自测吞吐特性动态批处理 FP16/FP8 引擎图优化 量化CPU 场景可用灵活度引擎绑定 GPU 型号与 TRT 版本跨平台部署、边缘设备分发原理速览两段式管线里两条路线各自提速在哪先记住 F5-TTS 的推理是两段式前端 DiTDiffusion 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 仓库、起服务 MODELF5TTS_v1_Base docker compose up # 2. 容器内一条命令走完全流程 bash run.sh 0 7 F5TTS_v1_Baserun.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 声码器为 ONNXopset 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 L2024GB模型 F5-TTS Base Vocos 声码器测试集 seed_tts 的 wenetspeech4tts split 共 26 条样本NFE 16TensorRT 路线用仓库自带 benchmark.py 与 Triton 客户端PyTorch 基线同脚本换--backend-type pytorch。路线 / 模式并发batch平均延迟RTF相对 PyTorch 基线TensorRTTriton 服务端2253 ms0.03943.72xTensorRT离线 TRT-LLM1-0.04023.65xPyTorch离线基线1-0.14671.0xONNX Runtime-官方未提供官方未提供需自测数据来自 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 float32v0 和 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.04ONNX 路线补上跨平台那半块拼图两条线可以在同一条管线里各管一段。部署文档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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
