单卡GPU上的全精度TTS为何吐字慢：FP16 vs GGUF的RTF实测与显存权衡

“吐字速度慢得离谱，分析一下原因。”

这是我在语音助手的项目里收到的一句话。彼时语音回复的体验是：一句 5 秒的话，要干等 7 到 10 秒才能听到。生成比播放还慢，意味着用户永远在等机器说完。这篇文章记录一次完整的慢因排查，以及最后那个可能出乎你意料的决定——算清楚账之后，我不修了。

先量化”慢”：RTF 才是唯一诚实的指标

TTS 性能不能看绝对耗时，要看 RTF（Real-Time Factor）：合成耗时除以音频时长。RTF < 1 表示生成比播放快，可以边生成边播；RTF > 1 则用户必然等待。

从服务日志里抓出两个响应头字段：X-Synthesis-Time-S（合成耗时）和 X-Audio-Duration-S（音频时长），一除，稳定在 1.5 到 2.0 之间。也就是说，每说一句话，机器要花接近两倍的时间先把它”想”出来。5 秒的语音等 10 秒，不是玄学，是 RTF 1.8 的必然结果。

排查三步：进程、GPU、模型文件

第一步看进程参数。 ps 抓出服务的启动命令，两个关键信息：--device cuda:1 和端口 8701。这台双卡 2080Ti 改装 22G 的服务器上，主卡 GPU0 被 llama-server 长期占着跑对话模型，TTS 被挤到了副卡 GPU1。

第二步看 GPU 实时状态。 nvidia-smi 显示：GPU0 显存 75%、利用率 90%；GPU1 显存 83%、利用率 63%。注意 GPU1 的利用率并没有打满——如果是算力瓶颈，利用率应该常年 95% 以上。63% 的利用率配上慢吞吞的响应，指向一个经典嫌疑：内存带宽瓶颈，GPU 大量时间在等数据搬运。

第三步看模型文件。 这是最关键的一步。磁盘上有两个模型目录，服务实际加载的是 Qwen3-TTS-Base——Safetensors 格式，FP16 全精度，1.7B 参数，未做任何量化。GGUF 量化版本根本不存在，find 全盘搜索确认无一结果。

根因：一笔带宽账

把数字摆出来算：

• FP16 每个参数 2 字节，1.7B 参数 ≈ 3.4GB 权重，加上 embedding 和开销，每个自回归步要完整读一遍约 6GB 权重；
• 2080Ti 的显存带宽约 696 GB/s；
• 仅主干权重读取的理论下限就是 6GB ÷ 696GB/s ≈ 8.6ms/token。

要把这个理论值和实测 RTF 对上账，得先看清 8.6ms 只覆盖了 talker 主干这一环。文本到语音是一条多级流水线：主干逐 token 输出语义 token，code predictor 要在每个音频帧上跨多码本（codebook）自回归预测 codec token，最后还有 codec 解码成波形。语义 token 12Hz 意味着 1 秒音频至少 12 步主干推理，每步又触发一整串 predictor 与解码计算；再加上 transformers 非融合推理路径的 Python 侧调度开销，单步实际耗时从理论下限的 8.6ms 膨胀一个数量级是常态。旁证就在 nvidia-smi 里：GPU1 利用率 63%，远没吃满算力——卡住的不是计算，是逐级搬运与调度。所以诚实的结论是：权重读取是开销的大头之一，但完整解释 RTF 1.5-2.0 需要”带宽 + 多级流水线 + 框架开销”三项叠加。而这三项里，量化对前两项都有直接缓解——这正是下一节预期 GGUF 能提速的原因，注意那是预期，不是本机实测：我们最终没有做这次切换。

FP16 vs GGUF：dense 模型的反直觉

理论对比很清晰：

对比项	Safetensors FP16	GGUF Q4_K_M
每参数字节	2.0	~0.6
显存占用	~6GB	~1.8GB
每步权重读取	~6GB	~1.8GB
反量化开销	无	有（实时反量化）
RTF（本机实测/预期）	1.5-2.0	0.5-0.8

反直觉的地方在于：反量化要额外消耗算力，按理说量化应该更慢才对。但这条经验有一条清晰的分界线——密集访问权重的 dense 模型，压缩收益远大于反量化开销。TTS 恰好是最典型的场景：模型小、每步都要扫全部权重、串行自回归步数多，权重读取占了绝对大头，把权重压到三分之一，带宽压力直接降 3 倍，速度立竿见影。

而 llama.cpp 的转换代码里确实已经有 Qwen3-TTS 的支持（把 talker 主干映射到文本推理路径、说话人编码器映射到音频编码路径），技术上这条路是通的。

算清了账，然后我决定不修

修复方案有三个：转 GGUF 量化（预期 RTF 1.8 → 0.6）、挤回 GPU0（但主卡只剩 5GB 空闲，有 OOM 风险）、双卡重新分工（要动主力 LLM 服务的部署）。听起来方案 A 稳赢，但把使用数据摆进来算总账：

• 使用频率：语音合成是低频功能，每天调用次数两只手数得过来，等待者是我自己，不是付费用户；
• 优化成本：模型转换、服务改造、音质回归验证，一次完整的折腾加回归测试；
• 稳定性代价：当前部署是”开机自启 + 副卡固定 + 10 分钟闲置自动卸载”的稳定态，量化引入的是新的变量。音质劣化这种事，等用户听出来了再回头排查，成本更高。

于是最终决定：保持 FP16，不动。RTF 1.8 在”低频 + 自用 + 已稳定”的约束下，是一个可接受的数字。性能优化文章的默认叙事是”快就是好”，但真实的工程决策里，慢本身不是问题，慢造成的代价才是。没有代价的慢，修它是纯支出。

留下决策清单

这次排查沉淀下来的判断流程，比结论本身更值钱：

1. 先量化：任何”感觉慢”先算 RTF / P99 / 吞吐，拒绝凭印象优化；
2. 看利用率辨瓶颈：GPU 利用率不满 + 响应慢 ≈ 带宽瓶颈；利用率打满才是算力瓶颈；
3. 查模型格式：Safetensors 全精度 + dense 小模型 + 长自回归 = 量化的教科书场景；
4. 优化前先算使用账：频率 × 等待人数 × 单次代价，三个因子有一个趋近于零，优化收益就趋近于零；
5. 把”暂不修”也写成决策：记录前提条件（当前低频、无外部用户），条件变了——比如语音功能要对外——这个决定自动失效，届时再启动方案 A。

工程上最贵的不是慢，而是不知道为什么慢、以及不知道自己为什么决定不修。