拆解 BosonAI Higgs Realtime Duplex：级联 vs 端到端 vs 全双工三代架构、160ms 窗口调度、45B MoE 三步训练、每分钟 2.6K--5K token 的成本账，附 token 预算计算。
车里，你让 AI 查一下股价和训练任务跑到哪了。转头你开始点餐，它一句话都不说。等你点完，它才接上：股价多少，GPU 跑到第几步。到了取餐口你随口问一句「我刚才点 animal-style 薯条了吗」。它说：没有。它听见了。
这是李沐在 B 站演示里的一个片段。第一次看会觉得平常，因为真人就是这么对话的。但今天几乎所有语音助手都做不到------它们只会「你一句、我一句」，而且每次接话前，都要在后台把你说的话先转成文字。
李沐这次讲的模型叫 Higgs Realtime Duplex，BosonAI 做的全双工实时多模态。它把上面那套流程拆了两次：一次砍掉中间的文字层，一次砍掉「按句子切轮次」的假设。
下面把架构、训练和成本账拆开讲，最后说说我认为这套设计真正的门槛在哪。
一、先把「像人」变成可测量的三条
李沐给了三个要求，我认为这是全文最有价值的部分：他把一个感觉很虚的目标，压成了三个能对着评测的指标。
| 要求 | 具体标准 | 为什么是这个数 |
|---|---|---|
| 像人 | 对方说完 200 毫秒内接上话 | 真人的应答延迟就在这个量级，慢一点就「像机器」 |
| 有用 | 聊天是为了办事 | 光会聊的助手没有使用场景，得能调工具、查数据、下订单 |
| 够便宜 | 聊 1 小时成本 ≤ 人工时薪的 1/10 | 每天聊几个小时的场景下，成本决定它能不能普及 |
第三条最容易被忽略。实时交互意味着没人说话的时候，模型也在算------这是一个持续烧钱的状态。所以后面那套 token 精算不是优化，是生死线。
二、第一刀：砍掉中间那层文字
先看大家熟悉的级联架构，也就是 Siri 那一代的做法：
VAD 判断有没有人在说话、说完了没有 → ASR 把语音转成文字 → 大语言模型生成回复 → TTS 把文字合成为声音。
这套结构的好处很实在：每个模块都能独立升级，ASR 换个更好的、TTS 换个更像人的，互不影响。工程上极其省心。
缺点是三个，而且都是结构性的：
第一，延迟是串联出来的。确认「说完了」要等几百毫秒，后面三个环节再排队跑一遍，延迟很容易落在 1.5 到 2 秒。你每说一句都要等两秒，这个体验没法谈「像人」。
第二，停顿不等于说完。「我要订一个......去上海的航班」------中间那个停顿只是你在想目的地。普通 VAD 一检测到静音就抢话，抢完发现你还没说完。就算换成能判断句意完整度的语义 VAD，后面的模块还是得排着队等。
第三，声音里的信息被抹平了。你的情绪、语速、周围还有没有别人、说话时是不是在笑------这些在 ASR 转成标准文字的那一刻全部消失。TTS 拿到回复文字，也不知道该用什么语气和节奏读出来。
所以第一步是端到端：把 ASR 的解码端、TTS 的文字处理端和中间的大模型主干合并成一个。
拆开看很自然。ASR 是「编码器把连续语音切成向量 → 解码器转成文字」，TTS 是「从文字和参考音色出发生成音频表示 → 音频解码器还原声波」。其中 ASR 的解码部分和 TTS 处理文字的部分，在架构上本来就和语言模型高度相通------既然都是「向量进、向量出」，中间那层文字就是多余的。
合并之后，输入端只留语音和视觉编码器，输出端只留音频和视频解码器。语音和画面经过编码器后直接以向量进主干，算完直接交给解码器生成声音和表情。
李沐用了一个很好的比喻：说外语 。一门外语足够熟练时，你听到问题不需要先在脑子里翻译成母语再回答，直接用外语组织回答。打通文字、声音、画面的语义联系之后，模型能直接利用声学信息控制语气，加上网络开销后的延迟也降到了 0.7 到 0.9 秒。
快了差不多一倍，但还是「一问一答」。因为系统里还留着 VAD，还是得先判断你说完没有。
三、第二刀：不按句子切，按 160 毫秒切
用大模型的 prefill 和 decode 来看就清楚了。传统设置把「处理输入」和「生成回复」分成两大块：你说话时模型做 prefill，你说完了它才进入逐个生成 token 的 decode。
但真实对话是交错的。对方说到一半，人已经开始理解、点头、附和，发现要查东西甚至已经动手了。
团队的做法很直接：不按句子切轮次了，直接把时间切成 160 毫秒的窗口。
规则只有一条：模型每 160 毫秒处理一个窗口------接收这段时间里的新信息（语音、画面、工具返回的结果），同时预测下一个 160 毫秒窗口要输出的内容。
这里有个容易漏掉的细节：你此刻听到的这一小段声音，是模型在上一窗口提前生成好的。它一边收现在的输入，一边准备下一窗口的输出，必须在当前窗口播完之前算好下一段，听和说才能无缝接上。这是一个硬实时的约束，不是「尽力而为」。
更有意思的是，这 160 毫秒的输出完全可以是静音：
- 你连续说话时，它判断暂时不用开口，就连续几个窗口输出静音（画面照收，一直在看）
- 听了几个窗口觉得该给反馈，就输出一声「嗯哼」
- 等你停下来，它已经有了一部分判断，可以马上接话
- 你中途插话，它在新窗口收到输入，立刻调整，让后面的窗口停声
所以「不说话」在这套架构里不是缺席，而是一个被显式训练出来的动作。这一点很关键------它把「什么时候开口」从工程判断变成了模型能力。
四、不冷场的三个办法
每个窗口只有 160 毫秒。遇到要查资料、订票、算一会儿的问题怎么办？
团队把思考 token 和工具调用也塞进了时间窗口：
分段思考。模型不用在一个窗口里把事情想完，而是在有限窗口时间里生成一部分思考 token，没想完的留到下一窗口继续。思考随着你的新输入一步步往前推，而不是攒成一个大的。
异步调工具，分段回复。听你说到一半发现要用工具，不用等你说完，当前窗口直接发起调用，让工具在后台跑；返回的长结果也可以分批塞进后面的输入窗口。哪怕工具还没跑完，模型也能先根据已经确认的信息说出前半句，等结果到了再组织后半段。
前端交互 + 后台大模型协同。遇到真正复杂的难题，前端模型可以呼叫后台更大更强的模型，自己继续留在前台陪你聊，等结果返回再接进对话。
这里李沐特别点了设计的边界，我认为是全文最有判断力的一段。他拿 Thinking Machines Lab 的交互模型做对比：对方是前端只管纯聊天，所有思考和工具调用全交给后台大模型。
那条路好训练，但代价是：如果每个问题都交出去，后台推理模型动辄算十来秒，用户每次都得干等，或者只能听前端先说一段没信息量的套话；而且每轮都调大模型，成本太高。
所以 Higgs 的原则很明确：前端主模型自己解决绝大部分思考和工具任务，只在真正搞不定时才找后台。这等于把「省成本」和「低延迟」两个目标绑定在了同一个设计决策上。
五、怎么把它训出来
架构定了，接下来是训练。团队试过更大的模型，评测确实更好，但实时推理成本跟着涨。权衡之后选了一个 45B 的 MoE 做前端主模型，分三步训练：
第一步，mid-training 。从完成文字预训练的模型出发，一边继续喂文字保住原有的理解和推理能力，一边加入大量语音、视频数据，总共约 2 万亿 tokens，把听和看练成模型熟悉的「母语」。这一步决定了它能不能「不翻译直接答」。
第二步，后训练。两种方法：
- 基于 GRPO 的强化学习 。实时交互里，一句回复不仅内容要对------接话的时机也得对。团队把模型放进不同的交互和工具环境里生成、探索------用户思考时要能等，需要工具时要及时调------通过环境反馈把这些行为直接练出来。
- 多老师同源蒸馏。一个 45B 的模型很难同时在所有环境里都学好，这就像一个徒弟很难同时练成所有功夫。于是他们把相似环境归成一类，先用强化学习分别训出专项老师（一个更会把握对话节奏，一个更擅长调工具做任务），再让这些老师一起教同一个学生。前提是老师和学生要足够相似，差别太大反而学不会------所以用同一个基底模型分别强化再做在线蒸馏，效果才出得来。
第三步，自迭代。在带真实延迟、抢话重叠和背景噪音的模拟环境里继续打磨。
六、成本账：一分钟到底烧多少 token
这是我最想抄下来的一节，因为很少有人把实时多模态的钱算到这么细。
要让人「聊得起」，每小时的交互成本必须压到人工时薪的 1/10 以下。做法是在 token 上精打细算：
| 项目 | 开销 |
|---|---|
| 音频输入 | 每 160 毫秒 1 个 token（每秒 6.25 个） |
| 音频输出 | 每 160 毫秒 2 个 token（每秒 12.5 个） |
| 视频输入 | 聊天时画面变化不大，每 6 个窗口取 1 帧，约每秒 1 次，每帧约 12 个 token |
| 数字人输出 | 每窗口 2 个 latent 向量，再交解码器还原画面 |
| 纯音视频合计 | 每分钟约 2.6K tokens |
| 含渐进式压缩的思考与工具记录 | 每分钟 2.6K 到 5K tokens |
再看长对话。连续聊几个小时，音视频上下文会越积越长，所以系统只保留最近 5 分钟的完整多模态上下文（约 13K 到 25K tokens），5 分钟之前的内容全部转成文字记录。近期细节留住，推理时不背着越来越长的音视频历史。
最后是换声音、换人脸。这块不需要重训那个 45B 主模型，零样本就行：推理时把参考声音和人脸图直接给到两头的解码器。音频端用因果流匹配解码器保持参考声音的特点；视频端用基于扩散模型的因果 DiT，结合参考图和前两个窗口的 latent 生成画面，保证人物外观和动作的连续性。
七、45B 对 276B
视频最后放了评测。里面有个对比值得单独拎出来：
Higgs 的前端主模型是 45B MoE ，对比表里的 Thinking Machines Lab Interaction Small 是 276B MoE------参数差了约 6 倍。
但成绩有来有回。在 Big Bench Audio 上，Higgs 45B 拿到 98.9 分；而那个 276B 的模型一旦关掉后台 Agent，分数就从 96.5 掉到 75.7。
这个跌幅说明的事很清楚：那套设计的能力有相当一部分挂在外部的后台模型上，前端自己并不扛事。关掉后台，真实水平就露出来了。
李沐的判断很直接：全双工实时交互这个方向还非常早期，数据、架构设计（160 毫秒切片、前端独立思考）和训练方法对结果影响很大，单纯把模型做大，未必是现阶段最关键的因素。
八、我的看法
这篇演示最容易被误读成「语音助手变快了」。我认为真正的变化在别的地方。
第一，粒度变了。交互的基本单位从「一句话」变成了「160 毫秒」。这个变化带来的不是 10% 的延迟优化，而是一整套新问题：模型必须在硬实时约束下输出、必须学会「不说话」这个动作、必须能在信息不全时先答一半。这套东西以前不属于语音工程的范畴。
第二，成本和质量被绑在一起了。「前端自己扛绝大部分思考」这个原则，同时决定了延迟和账单。反过来说，如果哪天客户愿意付更多钱换更好的回答，架构里也留了往后台升级的口子------这是一个有弹性的设计，不是二选一。
第三，有两处我认为还没被真正证明。一是 5 分钟滑窗之外全靠文字摘要，长对话里「记得住」这件事其实被悄悄降级了，体验上会不会露馅要看真实使用；二是前端自我承担绝大部分任务，失败模式会从「慢」变成「答得快但答错」，这比慢更难被用户察觉，也更难评测。
现在能用到什么程度？端到端模型 Higgs Realtime 已经开放 API，支持数字人输出；今天拆的这套全双工 Higgs Realtime Duplex 已开放候补名单，即将上线。
想自己扣细节的，建议按这个顺序看原视频：先看端到端架构合并那一段，再看 160 毫秒时间轴，最后回头看车载点单和英语陪练两个演示------你会突然明白它在每个窗口里到底在干什么。
参考资料：