COLM'25 | PredGen：你还在说话，LLM 已经想好怎么回了

June 25, 2026

2026   ·   LLM   推理优化   语音交互   投机解码   论文解读  

插播：之前写的《动手学 AutoML》终于出版了，从 NAS 到超参优化都有覆盖，适合想系统入门 AutoML 的同学。好了广告结束，现在进入正题。

动手学AutoML书籍封面

COLM’25 | PredGen：你还在说话，LLM 已经想好怎么回了

原文：PredGen: Accelerated Inference of Large Language Models through Input-Time Speculation for Real-Time Speech Interaction

1. 前言

你有没有想过，和语音助手对话时，那段烦人的”停顿感”是哪来的？

不是网络延迟，不是模型太大——核心症结在于：LLM 必须等你说完，才能开始想怎么回。

这句话看起来是废话，但仔细想想：你说一句话通常要 2-5 秒，这 2-5 秒里 GPU 在干嘛？啥也没干，白白闲着。等你说完，LLM 开始生成，生成完第一句，再喂给 TTS（文字转语音）系统，TTS 再输出声音——用户实际感受到的延迟，是这一串链条的总和。

这篇来自 COLM 2025 的工作 PredGen（Predictive Generation） 提出了一个非常直觉的想法：既然 GPU 在等你说话时是空闲的，不如趁这个窗口先”猜”你想问什么，提前把回答准备好一部分。 实验结果显示，audio latency 能压缩大约 2×，而额外的计算开销极小。

2. 问题背景：语音交互的延迟到底卡在哪

现在的语音对话系统基本是一条流水线：

用户说话（ASR） → 文字 → LLM 生成回复 → TTS 转成语音 → 播放

其中 Audio Latency（音频延迟） 是用户体验的核心指标，也就是”你说完到你听到第一个字”之间的等待时间。

现有优化方向大多集中在：

  • 用更快的解码算法（如 speculative decoding）减少 LLM 生成时间
  • 用流式 TTS，边生成文字边合成语音

这些方案都在”你说完之后”的环节做文章。但 PredGen 换了个角度：在你还没说完时，就偷偷开始干活。

3. PredGen 的核心思路

整体 pipeline 如下图：

PredGen 整体流程

思路可以用一句话概括：边听用户说话，边用当前已知的部分 prompt 预测回复；等用户说完，用 verifier 验证预测结果，接受能用的部分，丢掉不符合的。

这本质上是把 speculative decoding 的思路，从”token 层面的预测”搬到了”输入时间维度”——利用的是同一个洞察：预测比验证便宜，只要命中率够高，整体就是赚的。

3.1 具体怎么运作

详细的算法设计如下图：

PredGen 算法设计：预测更新与 Jacobi 解码

分两个核心子模块：

（a）预测-验证循环（Predictive-Verify Loop）

用户每说完一小段 prompt（记为 $P_{i+1}$），系统：

  1. 用当前已有的 response $R_i$ 作为”猜测”
  2. 用 verifier 检查 $R_i$ 里有多少 token（$k_i$ 个）在新 prompt 下仍然成立
  3. 接受这 $k_i$ 个 token，在此基础上继续生成更新后的 $R_{i+1}$，同时合成第一句话的音频 $A_{i+1}$

这样每轮循环，已经生成并验证通过的部分就会积累，等用户说完的那一刻，很可能第一句回复已经准备好了。

算法伪代码：

PredGen 推理流水线算法

（b）Jacobi 解码（更快的 AR 生成）

在”预测”阶段，为了让每轮的生成速度更快，PredGen 引入了 Jacobi decoding。相比标准的 autoregressive 解码（一个 token 一个 token 串行出），Jacobi decoding 通过多步并行迭代近似来加速生成，特别适合这里”宁快勿慢”的场景——反正结果最后还要过 verifier。

3.2 用户说话有多快？

论文里有一个细节：实验设定的输入速率是 600 字符/分钟，折算下来大概 10 字/秒，接近正常说话速度。这意味着用户说一句完整的问题，系统有好几秒可以提前”猜”，时间窗口其实相当可观。

4. 实验结果

4.1 主结果

核心数据如下：

主实验结果：四个数据集上的延迟对比

所有 PredGen 变体都实现了至少 1.6× 的 audio latency 加速，在部分场景接近 2×。

各变体加速倍数汇总

Latency 和 TTFS（Time-To-First-Sound）的单位是 ms，数字是实打实的工程收益。

4.2 不同 LLM 的泛化性

四款 8B 量级 LLM 的 audio latency 对比

这张图说明 PredGen 在 Llama、Mistral 等四款约 8B 规模的模型上都有效，不依赖某个特定模型架构。对多轮对话（MT-bench）的 NFETFS（Normalized First Echo Time-to-First-Sound）也做了消融，效果持续稳定。

4.3 Top-K 接受策略的影响

Top-K 接受策略消融实验

verifier 的接受策略（Top-K）对速度和质量都有影响，K 太小则接受率低（预测白做），K 太大则质量下滑。论文里给出了最优区间的参数建议。

5. 个人 take

这篇工作的出发点非常接地气——不是在 GPU 更忙的地方榨性能，而是在 GPU 闲着的时候多干活，属于”填谷”而不是”削峰”的思路。

几个觉得有意思的点：

  1. 和传统 speculative decoding 的区别：经典 speculative decoding 是”用小模型猜，大模型验”，在 token 级别并行。PredGen 是”用部分 prompt 猜，完整 prompt 验”，在时间维度并行。两者都是”预测比验证便宜”这个核心假设，但利用的资源完全不同。

  2. 适用场景的边界：这套方案对”用户输入有明确时间窗口”的场景（语音对话、慢速打字）非常有效。但对于 API 调用、批量推理这类场景，用户 prompt 是一次性给完的，就没有可利用的输入时间窗口了。

  3. 实际部署的工程考量：预测阶段的 LLM forward 会抢占推理资源，如果系统同时有其他请求，资源调度会更复杂。论文里的实验是单用户场景，多并发下的 overhead 值得后续研究。

总体来说，思路简洁、切中实际痛点、数据漂亮，是那种”想到之后会拍大腿”的工作。语音交互这个场景下，2× 的延迟降低对用户感知影响是非线性的——从 800ms 降到 400ms，体感差距比数字看起来大得多。

感兴趣的同学可以去看原文，有完整的算法描述和更多消融实验。欢迎评论区交流～

*作者：Shufan Li, Aditya Grover COLM 2025*