为什么实时 AI 助手难以构建
构建实时 AI 非常困难。大多数系统使用一系列独立的组件：一个组件负责语音检测；另一个将语音转换为文本；第三个生成响应；第四个将文本转换为语音；第五个渲染虚拟化身（Avatar）。
这些组件之间的每一次交接都会增加延迟。每一个边界都会产生时序错误。这使得交互感觉非常机械化。
Wan-Streamer v0.1 改变了这种方法。它不再使用独立的各种服务，而是使用一个流式 Transformer。它将音频、视频和文本视为一个单一的循环。
标准助手的运行方式如下： • 用户说话。 • 系统将语音转换为文本。 • 模型创建文本响应。 • 系统将文本转换为语音。 • 虚拟化身尝试让口型与音频同步。
这种方法非常脆弱。如果其中一个步骤变慢，整个系统都会停下来等待。如果用户中途打断，系统往往无法察觉。
Wan-Streamer 通过对语言、音频和视频进行统一建模来解决这个问题。它使用块因果注意力机制（block-causal attention）。这使得模型能够持续更新其状态。它不会等到一轮对话完全结束才采取行动。
该系统采用了“思考者-执行者”（thinker-performer）分离架构： • “思考者”负责感知和状态更新。 • “执行者”负责处理下一个生成单元。
这种重叠防止了循环中的各个部分互相阻塞。模型实现了约 200 毫秒的模型端延迟。总交互延迟保持在 550 毫秒左右。
当响应时间保持在一秒以内时，对话感觉就像是实时的。这对于以下场景至关重要： • 客服虚拟化身。 • 辅导代理。 • 远程呈现工具。 • 交互式演示。
Wan-Streamer 目前仍处于 0.1 版本。视频质量较低。单一模型并不能解决安全性或可靠性问题。然而，它证明了交互循环的形式至关重要。
如果你正在构建实时 AI，请思考以下问题： • 你能否将独立的模块融合进一个主干网络（backbone）中？ • 你的流水线（pipeline）中哪些环节存在等待？ • 哪些部分可以重叠以减少延迟？
在实时 AI 中，信息流动的方式本身就是产品。
Optional learning community: https://t.me/GyaanSetuAi