一句话定义：RTF（Real-Time Factor，实时因子）是一个比值——生成一段音频所消耗的计算时间，除以这段音频本身的时长。合成 10 秒语音花了 1 秒算力，RTF = 0.1；花了 20 秒，RTF = 2。
打个比方。把 TTS（Text-to-Speech，语音合成）想成一家餐厅，客人在"听"你上的菜。客人要听 10 分钟的播报，后厨 1 分钟就做完了，RTF = 0.1，那一个厨师同时伺候好几桌都不慌；如果后厨做 10 分钟的内容要 20 分钟，RTF = 2，那播报永远追不上，客人只能听一句等一句，越听越卡。
所以业内那条约定俗成的线是 RTF < 1：只有小于 1，生成速度才快过播放速度，语音才能像水龙头一样连续流出来。等于 1 是刚好跟上，没有任何余量；大于 1 基本只能用于离线批处理，做不了实时对话。
几个容易混的地方。
第一，RTF 只衡量纯计算效率，不包含网络传输、排队、调度。用户觉得"卡"，可能首包就等了很久，也可能服务被挤爆了，这些都不体现在 RTF 里。
第二，RTF 是跟硬件绑死的。同一个模型在带 GPU 的服务器和普通 CPU 上，RTF 可能差一个数量级。所以看到任何 RTF 数字，都要追问：什么硬件、什么精度、多大 batch、跑了几路并发。脱离条件谈 RTF 没有意义。批处理（batch）通常能把吞吐拉上去，但单条请求的等待时间可能反而变长。
第三，它和首包延迟、吞吐量是三件事，各回答一个问题：
| 指标 | 回答的问题 | 用户感受到的 |
|---|---|---|
| RTF | 生成速度跟得上播放速度吗 | 会不会说着说着卡住 |
| 首包延迟 | 多久能听到第一个字 | 点下去要等多久 |
| 吞吐量 | 一台机器能同时服务多少路 | 高峰期要不要排队 |
为什么这条线决定生死。RTF 直接换算成单机并发上限。假设一路语音流是实时的，单核 RTF = 0.1，理想情况下这块算力能同时喂饱大约 10 路；RTF 从 0.5 优化到 0.2，同样的机器能扛的并发就上了一个台阶。对做 TTS 服务的人来说，这不是调优炫技，而是单位成本能不能撑住商业化的分水岭——模型再好听，扛不住并发也只能当 demo。
给非技术同学的建议。挑语音供应商时别只试一句短 demo。demo 是单条、短文本、独占算力；真实业务是长文本、多人同时用、还有网络抖动。值得问清楚的是：长文本的 RTF 大概什么水平、峰值并发是多少、超过多少路会开始排队、是流式返回还是一次性生成。具体数字各家不同，以官方页面为准。
最后一句实用判断：如果是实时语音对话，别忘了预算里还有 ASR（语音识别）和大模型要花时间，RTF 只是整条链路里的一环，得留出余量给所有环节。