@PyTorch: 在他的PyTorch Conference Europe 2026主题演讲中,Patrick von Platen (@MistralAI)讨论了为什么现实世界的……

X AI KOLs Following 事件

摘要

在PyTorch Conference Europe 2026上,Mistral AI的Patrick von Platen解释了为什么现实世界的AI交互需要能够处理连续输入并产生连续输出的流式架构,并以Vox Real Time作为实时转录示例。

在他的PyTorch Conference Europe 2026主题演讲中,Patrick von Platen (@MistralAI)讨论了为什么现实世界的机器交互需要能够接收连续输入并产生连续输出的模型。 他以实时转录为例,解释了流式架构与处理更大音频块的传统语音识别方法有何不同。 观看完整主题演讲:https://youtu.be/sn5954LcXq8?si=Hf8ABKIZ4-I0cTA2… #PyTorchCon
查看原文
查看缓存全文

缓存时间: 2026/06/12 21:03

在这个来自 PyTorch Conference Europe 2026 主题演讲的片段中,Patrick von Platen(@MistralAI)讨论了为什么现实世界的机器交互需要能够接收连续输入并产生连续输出的模型。

他以实时转录为例,解释了流式架构与传统语音识别方法(一次处理较大音频块)的不同之处。

观看完整主题演讲:https://youtu.be/sn5954LcXq8?si=Hf8ABKIZ4-I0cTA2…

#PyTorchCon


TL;DR

PyTorch Conference Europe 2026 上,Mistral AI 的 Patrick von Platen 提出了流式处理范式:不是一次性获取全部输入,而是让语言模型在输入源源不断到来的同时自回归生成输出,实现真正实时的语音识别、翻译和多模态交互。

引言:重新思考语言模型的应用方式

大家好,我叫 Patrick,在 Mistral 的研究团队工作,也领导开源项目。我在机器学习开源生态系统中贡献了大约四年(之前在 Hugging Face),这是第一次参加 PyTorch 大会,非常高兴。

今天的演讲聚焦“流式处理”(streaming),不是花哨的智能体或 LLM 相关,而是希望大家退一步,重新思考语言模型的应用。

目前使用 ChatGPT 等模型时,是发出一个聊天补全请求,所有输入都在一个请求中,然后模型以流式方式输出。但反过来,我们也可以流式传输输入,而不是一次性获取所有输入。人类处理世界的方式正是如此:大脑接收流式输入的音频和视觉信息,在每一步采取行动,同时新信息仍在涌入;行动也是自回归的,基于之前行动并不断获得更多输入。关键点:我们在新输入不断涌入的同时产生输出

为什么流式处理对语言模型重要?

要实现完美无瑕的现实世界语言模型或通用机器交互,就需要流式处理——一个能接收连续输入并给出连续输出的应用。经典应用包括自动驾驶、仓库机器人、实时转录等。

今天我会重点用实时转录(自动语音识别) 来讲解流式架构。

Vox Real Time:真正的流式实时模型

我们推出的 Vox Real Time 模型是目前为数不多的真正流式实时模型,其构建深受 Q AI 研究启发(他们在流式处理范式方面领先)。

与 Whisper 等传统语音识别不同,Vox Real Time 不需要处理整个 30 秒音频块,而是处理非常小的音频流输入,并在新输入源源不断到来的同时生成输出——这正是人类处理世界的方式。

在架构图中,绿色部分是音频,语言模型不仅接收音频输入,还接收自回归生成的文本嵌入。每个时间步都接收新音频并生成输出。这对于实现真正流式语音识别至关重要,否则只能把音频切成越来越小的片段,总会遇到极低延迟的瓶颈。

架构详解

架构非常简单:有词嵌入和音频嵌入。Vox Real Time 将这两个向量合并成一个隐藏嵌入,输入给因果语言模型。因果语言模型擅长自回归地生成下一个标记,这里本质上是将已生成的内容与源源不断的输入结合起来。

对齐与延迟

流式处理的一个关键问题:确保生成的输出与传入输入在时间上严格对齐。音频中,说话速度有快有慢,每个音频帧必须与生成的输出对齐才能将嵌入一起输入。

例如句子 “I am wondering”,“wondering” 可能被切成两个标记,前面还有静默。不能简单地为单个音频嵌入预测一个单词嵌入 “wondering”。我们的办法是:教模型也预测静默或填充标记,只在单词被完整说出后才预测它——即等到完整输入被语言模型处理完毕再预测。

另一个难点:模型需要一点“展望未来”的能力。比如转录音频 “San San Francisco”,如果模型先听到 “Francisco”,那么转录 “San” 就容易得多。通过引入延迟实现:幻灯片中显示我们有三个延迟标记(240 毫秒后才预测第一个音频标记的转录),让模型可以展望约 250 毫秒的未来。

这个延迟参数可以根据使用场景调整:设置越低,模型越快、延迟越低;设置越高(如 2 秒),就回到离线转录世界,但性能更高。对 Vox Real Time,约 480 毫秒延迟已可实现最先进的语音识别,非常出色。

扩展至多模态

一旦将音频与文本对齐,在潜在空间相加,就可以再加入另一个嵌入,比如视频。视频有类似的时间频率特性,可以同样分块、同样添加。这是一个非常棒的框架,允许语言模型处理无限数量的模态

文本到文本的流式应用

对于普通应用(比如问答),流式输入行不通:如果请求是 “How many people live in Paris?”,只看 “How” 无法产生输出,必须处理完整请求。所以很难放入流式框架。

但有些文本到文本场景非常适合流式,例如翻译。考虑聊天翻译:没有音频,只是文字,但希望实时——当人们打字时自动翻译。在这里,你可以在处理输入的同时流式输出结果。翻译通常只需要知道句子的上下文,不需要整篇文章。

我们可以教模型逐词处理输入,模型被训练为:一旦句子结束,就可以在没有任何新输入的情况下开始流式输出结果。例如,当你写下 “Dinner?” 时,模型开始翻译前一个句子的单词 “Paris”。这又是一种引入的延迟,但模型可以这样训练。

一旦拥有这种能力,就可以将所有模态组合到流式架构中:流式输入单词、音频、视频,生成输出词嵌入。工业界有很多有趣的应用。

实际考虑

预训练困难

流式处理总是需要某种输入-输出映射,而预训练通常在原始数据上训练,没有可用标签,所以很难。

输入-输出不对齐

很多文本语言模型的应用中,输入和输出在时间上不对齐。比如把冗长的错误日志复制粘贴给 ChatGPT,期望简短回答,输入可能有几千行。这对流式处理极其困难。

组合模态的简单性

流式处理的一大优势:组合模态非常简单。当前范式下,一次性拥有完整请求时,需要纠结图像放在哪里(文本之前、之后、之间?)。而流式处理中,无论什么输入进来,都在相同时间间隔内被组合、处理。

允许提前停止

如果你在做实时翻译,意识到模型一开始就跑偏,可以停止它,不必等待模型处理完整篇长文。

工业实时系统

很多工业任务需要实时系统,比如文本在控制台中流式输入,需要立即输出。

将预训练模型调整为流式

尽管流式预训练困难,但我们可以很好地将预训练的语言模型(从完整请求到输出)微调为流式输入到输出。

流式输入用于加速预填充

即使对于当前模型,流式输入的想法也非常有用。使用视觉语言模型时,如果输入很长,模型会自动分块预填充(因为一次性处理会占用太多激活内存)。输入分成块后一个一个处理。如果允许输入流式传输,你可以更快地运行输入,因为一旦完成第一个输入的处理,就可以开始预填充 KV 缓存。

例如,输入流 “how many…” 时,因果语言模型已经可以处理句子的一部分,KV 缓存随着输入增长而增长。这对于已经拥有部分输入的应用场景很有用,可以尽快使用语言模型,避免浪费时间。

结语

当我们发布 Vox Real Time 时,与视觉语言模型团队合作很多,添加了流式输入 API 和实时 API,大家可以尝试。这对于未来可能具有完全流式处理功能的模型来说也非常有趣。

非常感谢。

来源: PyTorch Conference Europe 2026 主题演讲片段 (https://www.youtube.com/watch?v=sn5954LcXq8)

相似文章

OpenAI 如何实现大规模低延迟语音 AI 部署

OpenAI Blog

OpenAI 详细介绍了其重新架构的 WebRTC 技术栈,旨在为超过 9 亿用户提供大规模低延迟语音 AI 服务。文章阐述了全新的 split-relay 和 transceiver 架构如何优化媒体路由与连接建立,以支持 ChatGPT 语音等实时交互场景。