RTF 实时率怎么读：多快才算够快

2026-08-24

RTF（实时率）等于处理耗时除以音频时长。RTF 小于 1 表示比实时快——处理 10 秒音频用了不到 10 秒；等于 1 是刚好打平；大于 1 就是跟不上。

定义简单到几乎不需要解释，但它在选型里被误读的频率非常高。原因也很直白：RTF 是个单一数字，好比较、好写进材料，于是人们习惯把它当成”这个系统快不快”的总答案。

它不是。它只回答一个很窄的问题。

RTF 真正回答的那个问题

RTF 回答的是：在这台机器上、用这套配置、跑这批音频，处理完需要多长时间。

这个问题在离线转写里是核心问题。你手上有一万小时的历史录音要转写，RTF 直接决定它是跑一周还是跑一天，也直接决定你要租几台机器。这时候 RTF 是最该盯的指标，没有之一。

但它有个天然边界：RTF 描述的是”处理完”的速度，不是”开始出结果”的速度。这两件事在离线场景里没差别，在实时场景里差得很远。后面会专门讲。

从 RTF 推并发，为什么理论值几乎从不成立

最常见的推演是这样的：RTF 是 0.1，说明处理一路音频只占用十分之一的算力，那么一台机器理论上能同时扛约 10 路。

这个算法本身没错，但它是理论上限，实际能跑到的数字通常明显更低。至少三件事会把它拉下来。

第一，显存。 每一路请求都要占一份中间状态。算力还有富余，显存先满了，机器就只能停在那个并发数上——这时候瓶颈根本不是 RTF 描述的那个东西。

第二，批处理策略。 那个 0.1 通常是攒批测出来的：一次送进去很多段音频，一起算完，摊到每段头上就很快。但实时场景没法攒——要攒批就得等，等就是延迟。不攒批的单路 RTF 往往比宣传值差一截。攒批与延迟的取舍见 ASR 并发怎么算：按路数还是按 QPS。

第三，请求到达的分布。 理论值默认负载是均匀的，现实里请求扎堆。峰值时段所有人一起说话，谷时机器空转。按平均负载算出来的容量，到了尖峰就排队。

所以更稳妥的用法是：把 RTF 推出的并发当成上限参考，实际容量必须压测，而且要在真实的到达节奏下压。

流式场景该看的不是 RTF，是首字延迟

这是本文最想说清的一点。

设想一个识别服务，RTF 好看，处理速度绰绰有余。但它的实现是攒够一个较长的窗口才解码一次，于是用户说完一句话，要等这个窗口攒满、算完，字才成片地蹦出来。

RTF 漂亮，体验依然差。 因为用户感知的不是”这段音频总共算了多久”，而是”我开口之后多久看到第一个字”，以及”我说完之后多久拿到最终结果”。前者是首字延迟，后者是尾包延迟，两个都不在 RTF 的定义里。

这个结构和语音合成那边是同构的：流式 TTS 的首包延迟一文里讲过，一个总耗时更长但很快吐出第一块音频的系统，体验反而更好。识别和合成在这一点上遵循同一条规律——流式管道里，总耗时是成本指标，不是体验指标。

所以流式场景的健康标准是两条：RTF 必须小于 1（这是必要条件，否则积压会滚雪球），但真正要优化和监控的是首字与尾包延迟。识别里流式和整段的差别，见流式识别和整段识别有什么不同。

RTF 是平均值，平均值会藏东西

第二个陷阱：一个 RTF 数字通常是一批音频跑下来的整体平均。

平均值的问题在于它会稀释掉长尾。一批音频里绝大多数是几十秒的短句，跑得飞快；少数几条是超长录音，因为切分不当、静音过多或者解码退化跑崩了，耗时高出一个量级。这几条被大量短音频摊薄之后，整体平均 RTF 仍然好看。

而线上出事的恰恰是那几条。用户不会因为”别人的音频都很快”就原谅自己那条卡了十分钟。

正确做法是看分布，尤其看高分位数，并且按音频时长分桶单独看 RTF。同一个系统在 10 秒音频和 2 小时音频上的表现可能完全不同——这跟长音频怎么切分强相关，属于管道第一环的事。

这种”只报平均不报分布”的毛病不只出现在速度上，准确率指标同样中招，可以对照看准确率被高估的几种常见情况。

脱离硬件谈 RTF，等于没说

同一个模型，换一块卡、换一种精度、换一个推理运行时，RTF 就能差出很远。CPU 和 GPU 之间的差距更大，而且方向未必是你想的那样——低并发、请求稀疏的场景下 GPU 大量空转，账不一定划算，这部分见 ASR 该用 GPU 还是 CPU。

因此一个不带上下文的 RTF 数字，信息量接近于零。看到它时至少要追问四件事：

什么硬件：具体型号、几张卡、什么精度、什么推理运行时。
批大小是多少：是单路测的，还是攒了大批摊出来的。
并发数是多少：单路空跑，还是打满并发下的实测。
音频时长分布：测试集里的音频多长，有没有覆盖你线上的长音频。

这四个问题里有任何一个答不上来，这个 RTF 就不能拿来做容量规划。

离线转写 vs 实时对话：各该看什么

对比项	离线转写（会议纪要、字幕、质检）	实时对话（客服、助手、同传）
首要指标	RTF、单位时长成本	首字延迟、尾包延迟
RTF 的地位	核心指标，直接决定跑多久、要几台机器	只是必要条件（须小于 1），远不是充分条件
容量怎么算	按吞吐算，可以排队	按并发路数算，长连接全程占资源
批处理	尽量攒大批换吞吐	不能攒久，攒批直接伤延迟
该看的分布	RTF 的高分位数，看长音频有没有跑崩	首字延迟的高分位数
失败长什么样	一批音频跑了一夜没跑完	用户说完了，屏幕半天不出字
优化方向	更大的批、更合适的硬件、更小的模型	缩短解码窗口、减少回溯改写、砍掉不必要的后处理等待
排队策略	可以被抢占，让位给实时流	优先级最高，不能被批量任务堵死

这张表的用法是：先确定你在哪一列，再决定要不要关心 RTF。混着看是大部分选型失误的起点。

常见问题

问：RTF 到多少才算够用？

离线转写没有统一答案，取决于你的音频总量和交付期限——用总时长除以可接受的完成时间，倒推出需要的 RTF 和机器数，比对着一个通用标准更实际。实时场景则是另一套逻辑：RTF 小于 1 只是及格线，真正的门槛在首字延迟上，而那个门槛由你的产品形态决定，得自己量。

问：RTF 小于 1，是不是就一定不会积压？

不一定。RTF 小于 1 只保证单路处理跟得上，不保证并发打满时跟得上。多路请求共享同一份算力，实际每路拿到的资源被摊薄，有效 RTF 会上升。另外突发流量会让队列先涨起来，即便平均处理能力够，尖峰期的排队延迟一样难受。

问：厂商给的 RTF 能直接拿来用吗？

只能当参考起点。厂商的数字通常在最有利的条件下测出来：理想硬件、大批处理、干净的短音频。你自己的音频时长分布、噪声情况、并发形态都不一样。可行的做法是拿自己的真实音频，在自己的目标硬件上，按线上并发压一遍，测出的分布才是能拿来做容量规划的。