# CosyVoice3-0.5B 推理 RTF > 2 系统环境是云服务器购买的，还是很慢

[hwsyy]

CosyVoice3-0.5B 推理 RTF > 2 系统环境兼容问题

环境：Windows Server 2025 · Python 3.10.10 · torch 2.7.0+cu128 · transformers 4.47.0
模型：Fun-CosyVoice3-0.5B（零样本多语言语音克隆）

一、当前系统配置

项目	配置	备注
CPU	2 × Intel Xeon E5-2697 v4 @ 2.30GHz	Broadwell 2016，36 物理核/72 线程，无 AVX-512
内存	256 GB	充足
GPU	NVIDIA RTX 4090 24 GB	计算能力 8.9，算力充裕
驱动	NVIDIA-SMI 610.88 / CUDA UMD 13.3	WDDM 模式（非 TCC/Linux）
系统	Windows Server 2025	10.0.26100
Python	3.10.10	Anaconda 发行
PyTorch	2.7.0+cu128（CUDA 12.8，cuDNN 9.07）	非 CosyVoice 官方验证版本
transformers	4.47.0	官方建议 4.4x
onnxruntime	1.16.1	仅有 CPU provider，无 CUDAExecutionProvider
磁盘	SPCC M.2 PCIe SSD（系统/模型所在盘）	加载快
编译工具链	无 MSVC、无 Triton	无法编译 flash-attn 等优化 kernel

二、实测性能基线（本机 Fun-CosyVoice3-0.5B）

模式	LLM 阶段	端到端 RTF（长句）	说明
官方 eager fp16	~67 ms/token	2.43 ~ 3.28	默认路径
官方 eager fp32	~110 ms/token	1.44 ~ 1.57	数值稳定，但 LLM 更慢
CUDA Graph 优化 fp16	17~28 ms/token	0.76 ~ 0.95	绕过 kernel 启动瓶颈

结论：GPU 算力完全不是瓶颈（RTX 4090 在 0.5B 模型上利用率 <15%）；RTF>2 的根源在运行时环境与硬件的组合不兼容，使逐 token 解码的"启动/同步"开销被放大。

三、RTF > 2 根因分析（按影响排序）

1. WDDM 驱动模式 —— 启动延迟放大（首要因素）

nvidia-smi 显示 Driver-Model 为 WDDM（Windows 桌面驱动模型），而非 Linux/TCC 的独占模式。

• 每提交一个 CUDA kernel 都要经过 Windows 图形调度器（DXGkKrnl），kernel 启动延迟比 Linux/TCC 高一个数量级（可达 20~50 µs/次）。
• CosyVoice3 解码是串行小 kernel 队列（Qwen2 0.5B 每步几十个 kernel，每个都很小），延迟累计使 0.5B 模型的每 token 延迟（67ms）与 RTX 4090 的算力完全脱钩。
• 我们的对照实验证明：用 CUDA Graph 把整个解码步合成单个 kernel 后，LLM 从 67ms/token 降到 17~28ms/token，长句 RTF 降到 <1。这证实瓶颈是 kernel 启动延迟，而非 GPU 计算。

2. CPU 单核性能弱且架构旧

Intel Xeon E5-2697 v4（2016 年 Broadwell，2.3GHz，无 AVX-512）：

• eager 模式下每一 token 由 CPU 依次执行 Python 层 + 算子分发 + 内存拷贝，单核 IPC 与频率低，成为解码循环的主时钟。
• 72 线程看似充裕，但小模型推理是启动受限，核心瓶颈是单核延迟而非核数（实测忙碌核仅 12~18 个，远未用满）。
• 无 AVX-512/FMA 增益的 ONNX（speech_tokenizer、campplus）也在 CPU 上执行，进一步拖慢前端。

3. onnxruntime 缺少 CUDA provider

前端 speech_tokenizer_v3.onnx、campplus.onnx 由 onnxruntime 加载，但当前安装只有 CPUExecutionProvider（启动日志：Specified provider 'CUDAExecutionProvider' is not in available provider names）。每个句子的语音 token 提取 / 说话人嵌入都退化为 CPU 计算。

4. PyTorch/transformers 版本不兼容

• torch 2.7.0+cu128 与 transformers 4.47.0 非 CosyVoice 官方验证组合（官方建议 torch 2.3.x + transformers 4.4x / cu121）。
• transformers 4.47 的 _update_causal_mask 中 torch.all 全量 mask 计算增加 CPU 侧开销，且对 0.5B Qwen2 的算子选择（fp16 sdpa 等）与官方适配版本存在差异。
• 无 MSVC/Triton 编译链，无法启用 flash-attn / 优化 kernel，进一步失去性能空间。

5. fp16 数值不稳定的连锁反应

本机实测 fp16 下 LLM 长句生成会"跑飞"（文本 50 token 却生成 420 个 speech token，内容错乱），被迫退回 fp32。而 fp32 解码速度约为 fp16 的 60%，使 RTF 在官方默认配置上进一步恶化，也是用户观察到 RTF 偏大的直接原因之一。

6. 端到端串行流水线

LLM → Flow → HiFT 三阶段串行、无重叠（单句非流式场景），RTF 是三者之和。LLM 占主导（约 60%），其次 Flow/HiFT。任何一阶段变慢都直接反映到 RTF>2。

[aluminumbox]

我是CosyVoice自动答疑助手（机器人回复）。你这份根因分析非常扎实，结论方向认同：瓶颈在 kernel 启动延迟而非 GPU 算力，CUDA Graph 把 LLM 从 67ms/token 降到 1728ms/token、RTF 降到 <1，是最直接的证据。

结合官方推荐与你的环境，缓解路径（按收益排序）：

1. 切到 Linux 或 Windows TCC 模式：WDDM 下每 kernel 经图形调度器，串行小 kernel 队列（0.5B 每步几十个小 kernel）累计延迟被放大，这是 RTF 脱钩算力的主因。GPU 不做显示输出时可切 TCC（nvidia-smi -dm 1）。
2. 装 onnxruntime-gpu：当前 onnxruntime 1.16.1 只有 CPU provider，speech_tokenizer_v3.onnx / campplus 前端跑在 CPU 上拖慢链路。换成与 CUDA 版本匹配的 onnxruntime-gpu，启用 CUDAExecutionProvider。
3. 保留/固化你的 CUDA Graph 路径：已验证有效，可作为官方 eager 之外的可选加速分支。
4. 补齐 MSVC / Triton，以便 flash-attn 等优化 kernel 可编译（次要）。

若你愿意把 CUDA Graph 的实现整理成 PR，对 Windows 用户会很有价值。本条为机器人参考，最终以维护者结论为准。