李沐：我带着新模型回来了！

1. 李沐：我带着新模型回来了！

[!abstract] 速览

  • 端到端架构：保留语音和视觉编码器，合并 ASR 解码、TTS 文本处理与大模型主干，实现从声音/画面直接到声音/表情的闭环。
  • 全双工窗口：模型每 160 毫秒处理一个窗口，持续接收新信息并提前生成下一窗口输出，支持静音、附和和即时响应。
  • 复杂任务：引入分段思考、异步工具调用和前端后台协同机制。
  • 训练：Mid-training 加入语音视频数据，后训练结合 GRPO 强化学习和多老师蒸馏。
  • 成本：通过 Token 压缩和 5 分钟上下文窗口控制成本，每小时成本压到人工时薪 1/10 以下。
  • 延迟：传统管线延迟达 1.5-2 秒，端到端设计降至 0.7-0.9 秒。
  • 评测：45B MoE 模型在多模态交互中表现出色，参数规模并非唯一提升因素。

李沐分享了全双工实时多模态交互模型的架构设计，通过端到端消除 ASR/TTS 的文字中转环节、采用 160 毫秒时间窗口实现持续接收与输出，结合分段思考和异步工具调用，显著降低了延迟至 0.7-0.9 秒，同时通过 MoE 模型和蒸馏训练实现成本与性能的平衡。

1.1. 摘要

文章详细阐述了李沐团队开发的全双工实时多模态交互模型（Higgs Realtime Duplex）的核心技术方案。为解决传统语音助手的延迟问题，作者提出端到端架构：保留语音和视觉编码器，合并 ASR 解码、TTS 文本处理与大模型主干，实现从声音/画面直接到声音/表情的闭环。通过 160 毫秒时间窗口设计，模型持续接收新信息并提前生成下一窗口输出，支持静音、附和和即时响应。为处理复杂任务，引入分段思考、异步工具调用和前端后台协同机制。训练方面，采用 Mid-training 加入语音视频数据，后训练结合 GRPO 强化学习和多老师蒸馏，最终通过 Token 压缩和 5 分钟上下文窗口控制成本。评测显示 45B MoE 模型在多模态交互中表现出色，参数规模并非唯一提升因素。

1.2. 主要内容

序号 要点 说明
1 端到端架构消除 ASR/TTS 的文字中转环节，显著降低延迟 传统管线需等待语音完整后转文字、模型生成、再转语音，延迟达 1.5-2 秒。端到端设计保留语音/视觉编码器与音频/视频解码器，模型直接处理声学向量，延迟降至 0.7-0.9 秒。
2 160 毫秒时间窗口实现持续接收与输出的全双工交互 模型每 160 毫秒处理一个窗口，接收新输入并提前生成下一窗口输出。支持静音、附和和即时响应，用户说话时模型可同步思考，突破“一问一答”模式，实现自然的双向实时交流。
3 分段思考与异步工具调用解决复杂任务的时限问题 模型将思考 token 和工具调用拆分到多个窗口内，遇到需要查资料的任务可在当前窗口发起调用，后续窗口逐步返回结果。前端模型主动解决绝大部分任务，仅在必要时调用更大模型，平衡成本与效果。
4 通过 GRPO 强化学习和多老师蒸馏优化训练效果 后训练采用 GRPO 强化学习训练交互行为，模型学会把握回复时机和工具调用时机。同时采用多老师同源蒸馏，将相似环境归类训练专项模型，再让这些专家老师教授同一学生模型，提高学习效率。
5 Token 压缩和 5 分钟上下文窗口控制成本 音频输入仅用 1 个 token/160ms，输出 2 个音频 token；视频每 6 窗口取一帧。系统保留最近 5 分钟完整上下文，更早的内容转为文字记录。这种设计将每小时成本压到人工时薪 1/10 以下。
李沐半身照：戴眼镜、穿深蓝色 POLO 衫，在室内走廊背景前微笑

最新：李沐，BosonAI 联合创始人

1.3. 沐神回归 B 站了！

辣个男人终于又带着新模型回小破站讲技术了！

这次沐神聊的是现在硅谷最火的方向之一：全双工（Full-Duplex）实时多模态交互。

现在的大模型光会「你一句、我一句」地问答已经不够看了，真正的全双工，是要让 AI 像真人一样持续接收声音和画面，自己还带一张实时生成的脸，一边跟你聊天，一边把交代的任务完成了。

线上发布会截图：左侧为 BosonAI「Higgs Realtime Duplex」研究预览幻灯片，含前端模型、后台模型、工具与每 160 毫秒一步进出的时间轴；右侧为 Higgs 数字人及李沐等参会者的视频画面

先看视频里的两段演示。

一段是在车里，用户先让 AI 查股市、看看自己正在跑的训练任务，转头就跟快餐店员点餐。点单的时候 AI 安静听着，绝不插嘴；等点完单，它才接上话汇报股价和 GPU 训练进度。到了取餐口，用户突然问：“我刚才点 animal-style 薯条了吗？” AI 马上回答：没有，它听见了刚才的点单。

车载点单演示截图：男子坐在驾驶位，右侧手机端 Higgs Live 显示正在查询标普 500、纳斯达克指数与训练任务进度

另一段是英语陪练。用户看着照片描述旅行经历，AI 会在计时结束后叫停、指出语法问题；发现用户把“vest”读成了“west”，它还会直接看着用户的嘴型提示，发 v 的时候上牙应该怎么接触下唇。

一个像真人的模型，沐神觉得有三大要求：像人、有用、够便宜

[!note] 三大要求：像人、有用、够便宜

  • 像人：真人聊天通常在对方说完 200 毫秒内就能接上话，甚至边听边附和。
  • 有用：聊天往往是为了办事。
  • 够便宜：如果以后大家每天要跟 AI 聊好几个小时，聊 1 小时的成本，最多不能超过人工时薪的十分之一。

1.4. 沐神教你手搓全双工大模型

传统的语音助手大家都很熟：用户开口后，先由 VAD（语音活动检测）判断有没有人说话、有没有说完，接着 ASR 把语音转成文字，大语言模型生成回复，最后交给 TTS 合成声音。

这套架构的好处是每个模块都能单独升级，但缺点也很明显：模块接得越长，等待就越久。确认说完要等几百毫秒，后面三个环节再串起来跑，延迟很容易落到 1.5 到 2 秒。

幻灯片《经典的分段式架构》：用户→VAD→ASR→LLM→TTS 的串行管线，右侧为李沐讲解画面

而且停顿不一定代表说完。比如「我要订一个……去上海的航班」，用户中间只是在想目的地，普通 VAD 一检测到停顿就会抢话；就算换上能判断句意完整度的语义 VAD，后面的模块还是得排队等着。同时，声音里的很多信息也在这个过程里丢了，比如一个人说话的情绪、周围还有没有别人。一旦被 ASR 转成标准文字就全没了，TTS 拿到回复文字，也不知道该用什么语气和节奏读出来。

所以第一步，就是砍掉中间转文字的环节，做端到端。

把 ASR 和 TTS 各拆开一次就很容易看懂：ASR 先用编码器把连续语音切成向量，再用解码器转成文字；TTS 则是从文字和参考声音出发生成音频表示（比如团队之前讲过的 Higgs Audio 用的音频 token），再交给音频解码器还原成声波。这当中，ASR 的解码部分和 TTS 处理文字的部分，在架构上本来就和语言模型高度相通。

既然如此，沐神团队干脆把 ASR 的解码端、TTS 的文字处理端和中间的大模型主干合二为一：输入端只保留语音和视觉编码器，输出端只保留音频和视频解码器。毕竟文本大模型本来就会把输入 token 转成向量再交给主干处理，语音和画面经过编码器后，同样能以向量的形式直接进主干，算完再直接交给另一头的解码器生成声音和表情画面。

幻灯片《合成一个模型》：音频编码器→多模态 LLM→音频解码器的架构，对比分段式与端到端在文字中转和延迟上的差异

李沐把这个过程比作说外语。当一门外语足够熟练时，听到问题不需要先在脑子里翻译成母语（中间文字），就能直接用外语组织回答。打通文字、声音和画面的语义联系后，模型不仅能直接利用声学信息控制说话语气，加上网络开销后的延迟也降到了 0.7 到 0.9 秒。

幻灯片《视频也是同样的道理》：声音与画面分别经音频、视觉编码器进入多模态 LLM，再由音频、视频解码器输出「它的声音」和「它的脸」

但这就引出了新的问题：端到端虽然快了，可系统里依然有 VAD，还是得按「一问一答」的轮次来工作。

用大模型的 prefill 和 decode 来解释就很清楚：传统设置把处理输入和生成回复分成了两大块，用户说话时模型做 prefill，等用户说完了，模型才进入逐个生成 token 的 decode 阶段。但真实聊天往往是交错的——对方说到一半，人已经开始理解、点头附和，发现需要查东西甚至已经提前动手了。

怎么打破这种一问一答？团队的做法很直接：不按句子切轮次了，直接把时间切成 160 毫秒的窗口！

在 Higgs Realtime Duplex 里，模型每 160 毫秒处理一个窗口，接收这段时间里的新信息（语音、画面或工具返回的结果），同时预测下一个 160 毫秒窗口要输出的内容。这里有个容易忽略的细节：用户当前听到的这一小段声音，其实是模型在上一个窗口提前生成好的。模型一边接收现在的输入，一边准备下一个窗口的输出，必须在当前窗口播完前算好下一段，才能把听和说无缝接起来。

幻灯片《全双工：按时间切片，而不是按轮次》：用户、模型声音、模型思考三行 160 毫秒时间轴，标注静音、附和「嗯嗯」、边听边想、调工具、重新规划与交给大模型

而且，这一小段输出完全可以是静音。用户连续说话时，模型判断暂时不用开口，就连续几个窗口输出静音保持安静（同时画面还在持续输入，模型一直在看）；听了几个窗口觉得该给个反馈，就输出一声「嗯哼」附和；等用户停下来，它已经有了一部分判断，可以马上接话；如果用户中途突然插话，模型在新的窗口收到输入，就立刻调整回答方式，让后面的窗口停下声音。

听和说能同时进行了，但每个窗口只有 160 毫秒，遇到需要多想一会儿的问题，或者要花几秒钟查资料、订票，怎么保证不冷场？

团队的办法是，把思考 token 和工具调用也拆开塞进 160 毫秒的时间窗口里：

机制 做法
分段思考 模型不用在一个窗口里把事情全想完，而是在有限的窗口时间里生成一部分思考 token，没想完的放到下一个窗口继续，让思考随着用户的新输入一步步往前推。
异步调工具与分段回复 听用户说到一半发现需要用工具，不用等他说完，直接在当前窗口发起调用让工具在后台跑；返回的长结果也可以分批放进后面的输入窗口。哪怕工具还没跑完，模型也能先根据已经确认的信息说出前半句，等新结果到了再组织后半段。
前端交互 + 后台大模型协同 遇到更复杂的难题，前端模型还可以选择呼叫后台更大、更强的模型来处理，自己继续留在前台陪用户聊天，等结果返回后再接进对话。
幻灯片：全双工时间轴及其放大图，展示每一步进一个输入块、出一个输出块，思考 token 与 search 工具调用被拆进多个窗口

不过李沐也特别点出了这套设计的边界。他拿 Thinking Machines Lab 的交互模型做了个对比：对方的做法是前端模型只管纯聊天，把所有思考和工具调用全交给后台大模型。那样虽然好训练，但如果每个问题都交出去，后台推理模型动辄算上十来秒，用户每次都得干等，或者只能听前端先说一段没什么信息量的套话，而且每轮都调大模型成本太高。所以 Higgs 的原则很明确：前端主模型自己必须解决绝大部分思考和工具任务，只在真正搞不定时才找后台帮忙。

[!warning] 设计边界：前端主模型必须自己解决绝大部分任务
对方的做法是前端模型只管纯聊天，把所有思考和工具调用全交给后台大模型。那样虽然好训练，但如果每个问题都交出去，后台推理模型动辄算上十来秒，用户每次都得干等，或者只能听前端先说一段没什么信息量的套话，而且每轮都调大模型成本太高。所以 Higgs 的原则很明确：前端主模型自己必须解决绝大部分思考和工具任务，只在真正搞不定时才找后台帮忙。

架构定下来了，接下来怎么训练前端模型，让它同时学会「什么时候开口」和「怎么调工具办任务」？

团队试过更大的模型，评测表现确实更好，但实时推理的成本也更高；权衡能力和成本后，他们选了一个 45B 的 MoE 作为前端主模型，训练分三步走：

首先是 Mid-training。从已经完成文字预训练的模型开始，一边继续喂文字保住原有的理解和推理能力，一边加入大量语音、视频数据（总计约 2 万亿 tokens），把听和看直接练成模型熟悉的「母语」。

接着是后训练，主要用了两种方法。第一种是基于 GRPO 的强化学习。在实时交互里，一句回复不仅内容要对，接话的时机也得对。团队把模型放进不同的交互和工具环境里生成、探索，用户思考时要能等、需要工具时要及时调，通过环境反馈直接把这些交互行为练出来。

第二种是多老师同源蒸馏。团队发现，一个 45B 的模型很难同时在所有环境里都学好。这就好比一个徒弟很难同时练好所有功夫，于是他们把相似的环境归成一类，先用强化学习分别训出擅长不同方向的专项模型（比如一个更会把握对话节奏，另一个更擅长调工具做任务），再让这些专项老师一起教同一个学生模型。

沐神提到，这种方法要求老师和学生有足够的相似性，差别太大反而学不会；而用同一个基底模型分别强化后再做在线蒸馏，就很容易见效。在此之上，团队还加了一轮模拟环境里的自我迭代，在带有真实延迟、抢话重叠和背景噪音的环境里继续打磨。

幻灯片《模型与训练》：模型为 45B 参数混合专家（MoE），Mid-training 使用约 2T token 的文字、语音和视频，后训练包含 GRPO 与多老师在线蒸馏

最后还有一个很现实的问题：全双工模式下，哪怕没人说话，模型也在处理每一个窗口，音视频上下文越积越长，怎么才能让人“聊得起”？

要把每小时的交互成本压到人工时薪的 1/10 以下，就得在 Token 开销上精打细算：

项目 规格 折算
音频输入 每 160 毫秒的窗口只用 1 个 token 每秒 6.25 个 token
音频输出 对应 2 个音频 token 每秒 12.5 个 token
视频输入 视频每一帧占的 token 更多，但聊天时画面通常不会剧烈变化，所以每 6 个窗口才取一帧画面 约每秒看一次，每帧约 12 个 token
数字人输出 每窗口先输出 2 个 latent 向量 再交给解码器还原画面
纯音视频流 — 每分钟约 2.6K tokens

加上渐进式压缩后的思考和工具记录，每分钟总共也就 2.6K 到 5K tokens。

  • 只留 5 分钟完整上下文：面对几个小时的长对话，系统只保留最近 5 分钟的完整多模态上下文（大约 13K 到 25K tokens），5 分钟之前的内容全部转成文字记录，既留住了近期细节，又不用背着越来越长的音视频历史做推理。
  • Zero-shot 零样本换声换脸：换声音或换人脸都不需要重新训练中间的 45B 主模型，推理时直接把参考声音和人脸图片给到两头的解码器就行。音频端用因果流匹配解码器保持参考声音的特点；视频端则用基于扩散模型的因果 DiT，结合参考图和前两个窗口的 latent 向量生成画面，保证人物外观和动作的连续性。
幻灯片《精打细算的 token 预算》：音频输入 6.25 tok/s、音频输出 12.5 tok/s、视频每 6 块看一帧、人脸输出每块 2 个 latent、上下文压缩至 5 分钟，一分钟对话约 2.6K token

1.5. 写在最后

视频最后，李沐放出了团队在交互、理解和工具任务上的评测结果。里面有个很有意思的对比：Higgs 的前端主模型是 45B MoE，而表里的 Thinking Machines Lab Interaction Small 是 276B MoE。

模型 参数规模 Big Bench Audio 关闭后台 Agent 后
Higgs 前端主模型 45B MoE 98.9 —
Thinking Machines Lab Interaction Small 276B MoE 96.5 75.7

参数规模差了大概 6 倍，但各项成绩却有来有回。

[!important] 结论：单纯把模型做大，未必是现阶段最关键的因素
李沐的判断很直接：全双工实时交互这个方向还非常早期，数据、架构设计（比如 160 毫秒切片和前端独立思考）以及训练方法对结果的影响很大，单纯把模型做大，未必是现阶段最关键的因素。

那么，现在可以体验到哪一步？

[!tip] 现在可以体验到哪一步

  • 目前已经开放 API 的是端到端模型 Higgs Realtime，支持数字人输出。
  • 今天拆解的全双工模型 Higgs Realtime Duplex，在 Boson 官方发布文中已开放候补名单，即将上线。

想跟着沐神继续扣细节的同学，建议先看原视频里端到端架构合并和 160 毫秒时间轴这两段，再回到车载点单和英语陪练演示，看看模型是怎么接收新信息、决定开口以及处理后台任务的。原视频和官方文档链接放在下面了，别忘了去给沐神一键三连～

原视频：https://www.bilibili.com/video/BV1LB4a6DEWL/
官方资料：https://docs.boson.ai/models/higgs-realtime/overview