Thinking Machines 发了一个新的交互模型，切入了一个更根本的问题：我们与 AI 交互的方式。它能够同时进行聆听、观察、说话、被打断、作出反应、在后台思考，以及调用工具。这一切并非靠语音转文字、轮次检测和各种智能体技巧拼接而成的流水线，而是一种原生的模型能力！如果这套机制能够实现，AI 将从“输入提示词、输出答案”的模式，转变为一种更像真正协同工作的体验。模型会注意到你的迟疑，会在看到情况时主动插话，会在一面听你说话时预判你的下一步行动。它不仅在变得更聪明，也在变得更善于维持与人之间自然流畅的对话。我们离真正的贾维斯更近了一步。Mira Murati的Thinking Machines Lab刚刚发布了新的研究成果：交互模型（interaction models）。核心思路：与其把实时交互功能拼接到原本按轮次工作的模型上，不如从头训练一个天生就能处理实时交互的模型。现在的AI，其实不是真实时用过语音AI的人都有这种感受：你必须说完，它才开始听。它说完，你才能接话。Murati把这个问题描述得很准确：当前的AI体验，往往感觉像是一场对话，只有在我们停止说话之后才真正开始。用户必须把想法攒成一批，不能指着东西说，甚至要把问题写得像发邮件一样。是人在适应模型，而不是模型适应人。问题出在架构层面。今天的模型是单线程感知现实的：用户没说完，模型就什么都感知不到；模型没生成完，感知就冻结，不接收任何新信息。这条人机协作的通道非常窄，人的知识、意图和判断，大量无法传递给模型；模型在做什么，人也很难随时介入理解。现有的解决方案是在模型外面套一个控制框架（harness），用语音活动检测等组件模拟打断、多模态输入、并发处理。但这些组件本身比模型要笨得多，天然限制了交互能力。比如"当我说错的时候打断我"或者"发现我代码里有bug就告诉我"，这类功能靠外挂根本做不到。更根本的矛盾在于：按照机器学习的苦涩教训，这些手工搭建的系统迟早会被通用能力的进步所超越。要让交互能力随着智能一起扩展，交互本身必须成为模型的一部分。从头训练，而不是外挂Thinking Machines的做法是训练一个原生支持实时交互的模型。系统由两部分组成：一个持续与用户保持双向交换的交互模型，加上一个异步运行的后台模型。交互模型负责实时感知和响应；当任务需要更深度的推理时，交互模型把任务委派给后台模型，后台模型在完成后把结果流式传回，交互模型再选择合适的时机把结果融入对话，而不是突兀地切换上下文。交互模型在整个过程中始终保持在线：接收新输入、回答追问、维持对话线索。这样的分工，让用户同时获得两种能力：非思考型模型的响应速度，以及推理模型的规划、工具调用和智能体工作流。交互模型本身也具备独立的智能，在交互基准和智能基准上都有竞争力。架构细节时间对齐的微轮次（Micro-Turns）交互模型以200毫秒为单位连续工作，交替处理200毫秒的输入和生成200毫秒的输出。输入和输出都被当作流来处理，没有人为设定的轮次边界。借助这个设计，模型可以在说话的同时听，比如西班牙语实时翻译成英语；也可以在看视频的同时说话，比如给体育比赛做实时解说。无编码器的早期融合（Encoder-free Early Fusion）大多数全模态模型需要分别训练独立的音频编码器（类似Whisper）和解码器（类似TTS模型）。Thinking Machines的方案是最小化预处理：音频信号以dMel格式输入，经过轻量嵌入层处理；图像切分为40×40的图块，由hMLP编码；音频解码器使用flow head。所有组件从头联合训练，与Transformer一体。这样的好处是，各种交互模式不再需要专门的控制框架，而是成为模型本身能力的自然延伸，并且可以随模型规模提升。推理优化200毫秒的分块意味着需要频繁、小批量的prefill和decode，现有的大语言模型推理库并不为此优化，每轮都有大量额外开销。Thinking Machines实现了流式会话（streaming sessions）：客户端把每个200毫秒的分块作为独立请求发送，推理服务器把这些分块追加到GPU显存中的持久序列里，避免频繁的内存重新分配和元数据计算。这一特性已向上游提交至SGLang。同时针对延迟和双向服务的形状做了内核优化，MoE内核采用gather+gemv策略替代标准的grouped gemm。训练器与采样器对齐Thinking Machines发现，训练器与采样器的逐位对齐（bitwise alignment）对训练稳定性和各组件调试都很有帮助。团队实现了批量无关的内核，端到端性能开销不超过5%。在通信内核方面，使用NVLS实现低延迟的All-Reduce和Reduce-Scatter，在Blackwell上具有确定性，并在序列并行和张量并行等不同并行策略之间实现逐位对齐。注意力机制的主要挑战是Split-KV，通过在decode和prefill之间保持一致的累积顺序来解决。安全性实时交互对安全的压力与按轮次交互不同。Thinking Machines的安全工作聚焦于两个方向：一是适合语音场景的拒绝方式。他们用TTS模型生成自然口语化的拒绝和过度拒绝训练数据，覆盖多种不允许的话题类别，让拒绝听起来自然但毫不妥协。二是长对话中的鲁棒性。使用自动化红队框架生成多轮拒绝数据，并与模型基于文本的拒绝行为保持高度一致。能做什么原生的交互能力，解锁了一系列此前需要外挂才能（或根本无法）实现的功能：无缝对话管理：模型隐式跟踪说话者是在思考、让步、自我修正还是在等待回应，无需独立的对话管理组件。口头和视觉插话：模型在合适的上下文中主动插话，而不是等用户说完。同时发言：用户和模型可以同时说话，比如实时翻译。时间感知：模型对已流逝的时间有直接感知。同步工具调用、搜索和生成式UI：在和用户说话、倾听的同时，模型可以并发地搜索、浏览网页或生成界面，并在需要时把结果融入对话。基准测试Thinking Machines发布了他们的模型TML-Interaction-Small，一个276B参数、12B激活的MoE模型。在交互质量方面，他们使用FD-bench进行评测，该基准针对交互性设计，覆盖用户打断、用户反馈、和他人交谈、背景语音等场景。在智能方面，使用Audio MultiChallenge基准。结果显示，TML-Interaction-Small是第一个在强智能/指令遵循和强交互性上同时表现优秀的模型。现有的交互基准还没能捕捉到这个模型带来的质性跃升。为此，Thinking Machines还构建了几个内部基准：时间感知和同步发言TimeSpeak：测试模型能否在用户指定的时间点开口说话，并输出正确内容。例如：让我练习呼吸，每4秒提醒我呼气吸气，直到我让你停。CueSpeak：测试模型是否在正确时机、以语义正确的回应发言。数据集专门设计为模型需要和用户同时说话才能拿到满分。例如：每当我切换语言，立刻给我纠正原语言中正确的词。视觉主动性现有商用实时API通过纯音频的对话管理框架做轮次检测，只响应语音轮次，无法在视觉世界发生变化时主动开口。比如当用户说请数我做了几个俯卧撑时，这类系统可能回应好的之后就保持沉默，因为没有音频触发信号。Thinking Machines改编了三个基准来评测视觉主动性：• RepCount-A：包含重复动作视频，改编为在线计数任务。模型需要跟踪动作并在正确时机报数。• ProactiveVideoQA：包含在特定时刻才能回答的问题，测试模型能否主动在正确时机给出答案。留空不说可得25分基础分，正确回答才能得高分，错误回答有惩罚。• Charades：标准时序动作定位基准，模型需要说出动作开始和结束的时间点。目前没有任何现有模型能有效完成上述任务，包括GPT Realtime-2和各类思考型高端模型，它们要么保持沉默，要么给出错误答案。局限与未来计划Thinking Machines也坦诚列出了当前的局限：• 长会话方面，音频和视频会快速积累上下文，流式会话设计能较好处理短中期交互，但超长会话仍需仔细管理上下文，这是当前的重点方向。• 计算与部署方面，低延迟的音视频流式传输需要稳定的网络连接，连接质量差会显著降低体验。• 模型规模方面，TML-Interaction-Small是276B参数的MoE，激活参数12B。团队预计交互能力会随模型规模提升，但更大的预训练模型目前速度太慢，无法在这一场景部署。计划今年晚些时候发布更大的模型。• 后台智能体方面，除了实时交互，智能体能力同样是核心。Thinking Machines认为交互模型和后台智能体如何更好地协同，目前才刚刚触及表面。