Gander全双工交互：砍掉三段串行延迟

一个端到端模型把全模态感知（omni）、实时交互与 Agent 能力装进了同一个框架，模型、代码、数据在 GitHub 仓库 Omni-Interaction-Gander/Omni-Interaction-Agent 全部开源，它叫 Gander。我在 4sapi.com 维护大模型 API 中转站，这种"边听边说"的全双工链路正好落在日常工作面的正中央，这一期就把它的原理、接入骨架和延迟账一次拆完。

痛点：说完才想、想完才说的憋屈

轮次式（turn-based）语音助手的每一次应答，背后都是一条串行流水线：ASR 转写 → LLM 生成 → TTS 合成。我管这个叫"三段憋屈"：转写要等尾音落定才敢定稿，生成要等完整转写才肯开笔，合成要等整句攒齐才出声，每一段的下游都在干等上游收尾，任何一处慢半拍，用户就对着空气发呆。三段单看都不慢，串到一起，等待就成了体验的主旋律。

更难受的是打断（barge-in）。播报中途用户插话，传统方案要先跑一遍 VAD 判断这确实是人声，再回滚已经塞进 TTS 的文本、清空播放缓冲，处理不利索就会出现机器自顾自念、人声叠在半截的双讲混乱。轮次式范式的基因就是"说完才想、想完才说"——延迟在这里不是调参问题，而是结构问题，结构不动，所有优化都只是把等待摊薄一点。

Gander 原理速览：两张图看懂范式切换

Gander 是一个端到端模型，在单一框架内统一了全模态感知（omni）、实时交互与 Agent 能力。与传统轮次式范式不同，它持续接收视频、语音、文本的流式多模态输入，支持自然全双工交互：用户可以随时打断，模型也能主动给中间反馈或者追问。第一张图对比延迟结构，图中数值均为演示参数，只用于说明结构性差异：

① 传统三段串行链路 vs Gander 全双工流式（延迟数值均为演示参数）

传统轮次式（turn-based）：

  语音 ─▶ [ASR 转写] ─▶ [LLM 生成] ─▶ [TTS 合成] ─▶ 播报
             │              │              │
             └─ 每段等上一段收尾，串行叠加（演示口径约 0.3s + 0.8s + 0.4s）
             └─ barge-in 需要额外插入 VAD 判定 + 文本回滚

Gander 全双工流式：

  语音/视频/文本 chunk ─┐
                       ├─▶ [单一端到端模型 · chunk 级 token 流] ─▶ 逐 chunk 播报
  打断/附和/追问 ◀─────┘
        输入与输出在同一条有序 token 流上推进：边听边说、随时可打断、可主动插话

第二张图给出"小脑-大脑"的分工结构：

② Gander"小脑-大脑"（Cerebellum-Brain）协作框架

   视频/语音/文本流（持续流入）
        │
        ▼
  ┌──────────────────────────┐       工具调用        ┌─────────────────────┐
  │ 小脑 Cerebellum           │ ───────────────────▶ │ 大脑 Brain           │
  │ · 实时交互与全模态对话     │ ◀─────────────────── │ · 复杂推理           │
  │ · 流式 Thinker-Talker 底座 │    Agent 编排运行时   │ · 高层 Agent 任务    │
  │ · chunk 级输入输出展平     │      持续交互         │                     │
  └──────────────────────────┘                       └─────────────────────┘
        │ 逐 chunk 播报
        ▼
   用户侧（随时可打断，模型可主动给中间反馈或追问）

Cerebellum-Brain 架构展开：实时归小脑，推理归大脑

两大设计里的第一个，是"小脑-大脑"协作框架：小脑负责实时交互与全模态对话，大脑负责复杂推理与高层 Agent 任务，两者通过工具调用与 Agent 编排运行时持续交互。

我的读法是，这套分工解决的是"反应快"和"想得深"互相拖累的问题。全模态对话对时效的要求近乎苛刻，感知刚到就要开始回应；复杂推理和 Agent 任务却要多步规划、调用工具、等待结果，天然是慢活。把两件事塞进同一个实时线程，要么推理拖慢应答，要么应答挤压推理。Gander 的做法是把"当下正在发生"的一切交给小脑——听清正在说的话、看着正在发生的画面、把回应按 chunk 吐出去；把"值得多想一步"的任务交给大脑——需要规划、需要查证、需要编排的活儿移出实时线程。Agent 编排运行时居中传话：小脑遇到复杂问题先给中间反馈稳住场面，大脑把结果算出来再流回小脑播报。用户随时打断时，接住打断的是小脑，被打断的推理在大脑侧另行处置，两边互不卡死。

这套结构对中转层的意义也很直接：实时线程的流量特征是"连接长、单包小、节奏密"，推理任务的流量特征是"请求重、耗时长"，两路流量混在一个池子里互相挤兑是选型大忌，后文路由一节会回到这个点。

Thinker-Talker 底座：chunk 级 token 流怎么跑

第二个设计落在小脑内部：基于流式 Thinker-Talker 架构，用户输入与模型输出在 chunk 级被展平成有序 token 流，实现低延迟连续交互。

我把它理解成"一条流水线上的两道工序"。Thinker 管"想"，负责语义推进；Talker 管"说"，负责把语义变成声音。在轮次式系统里，这两道工序轮流上岗，中间隔着完整的等待；在流式架构里，它们不再切换班次，而是同一条有序 token 流上的两段推进——输入 chunk 进来即入流，输出 chunk 备好即播出。等待之所以被"结构性砍掉"，是因为链路里不再存在"等转写收尾""等整句攒齐"这类同步点：一小段输入就能推进一小步输出，低延迟是架构的直接产物，而不是事后调参挤出来的成果。这也是这一期标题写成"砍掉三段串行延迟"的原因——砍掉的不是毫秒，是同步点。

评测四维度：对话、全模态、交互与 agentic

Gander 的评测覆盖四个维度：对话能力、全模态理解、交互能力、agentic 智能。人评结果里，它保住了 SOTA 开源模型在自然口语对话上的能力，在全模态交互上具备竞争力——前半句意味着切换到它不必牺牲对话质量，后半句才是范式切换带来的增量。

更有参考价值的是鲁棒性考题的三类场景：背景噪声、多人对话、backchannel（附和插话）。这三类恰好是全双工链路在真实环境里最容易翻车的地方：噪声会把"该不该接话"变成玄学，多人同场会让"对谁说话"失去锚点，backchannel 则专门考验模型会不会把"嗯嗯哦哦"的附和误判成真正的打断。模型层面的鲁棒性是一半，另一半要靠接入层的工程处理，避坑清单一节展开。

接入教程：全双工会话骨架（Python 演示）

接入从 OpenAI 兼容入口起步最省事：普通问答直接走 chat 接口，全双工会话走流式通道，中转层把鉴权与路由统一到同一套协议上。密钥一律从环境变量读取，不进代码库。下面是我整理的会话骨架，分块发送、逐 chunk 收流、模拟打断的中断处理都在里面；类名与事件名是示意，实际以所选链路的文档为准：

# Gander 全双工会话骨架（演示用：类名/事件名以所选中转链路文档为准）
import json
import os
import queue
import threading

from openai import OpenAI

# ── 中转站配置：OpenAI 兼容入口，密钥一律从环境变量读取 ──
client = OpenAI(
    base_url="https://4sapi.com/v1",
    api_key=os.environ["RELAY_API_KEY"],
)
MODEL_ID = "gander"  # 以中转站模型列表里的实际名称为准


def text_reply(prompt: str) -> None:
    """半双工兜底：普通问答走标准 chat 接口，同样按流式逐 chunk 返回。"""
    stream = client.chat.completions.create(
        model=MODEL_ID,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for piece in stream:
        print(piece.choices[0].delta.content or "", end="", flush=True)


class DuplexSession:
    """全双工会话骨架：分块发送、逐 chunk 收流、打断即中断。"""

    def __init__(self) -> None:
        self.inbox: "queue.Queue[str]" = queue.Queue()  # 输入 chunk 按序入队
        self.outbox: "queue.Queue[dict]" = queue.Queue()  # 输出 chunk 出队即播
        self.barge_in = threading.Event()  # 打断标志位
        self.closed = False

    # ① 分块发送：语音/视频/文本统一封装成 chunk，到了就推，不等整句
    def send_chunk(self, chunk: str) -> None:
        self.inbox.put(chunk)

    def sender_loop(self) -> None:
        while not self.barge_in.is_set() and not self.closed:
            chunk = self.inbox.get()
            if chunk is None:  # 收到结束信号，发送线程收尾
                return
            self._downstream({"type": "input_chunk", "payload": chunk})

    # ② 逐 chunk 收流：输出 chunk 到达即处理，不攒整段再播
    def receiver_loop(self) -> None:
        while not self.barge_in.is_set() and not self.closed:
            event = self.outbox.get()
            if event is None:
                return
            if event.get("type") == "interrupted":
                return  # 服务端确认中断，本轮回收结束
            self._play(event)

    # ③ 模拟打断（barge-in）：先停本地播放，再向服务端发 interrupt 帧
    def user_interrupt(self) -> None:
        self.barge_in.set()
        self._downstream({"type": "interrupt"})

    def _downstream(self, frame: dict) -> None:
        # 演示占位：真实场景替换为 ws.send(json.dumps(frame))
        print("[ws-send]", json.dumps(frame, ensure_ascii=False))

    def _play(self, event: dict) -> None:
        # 演示占位：真实场景接播放器，边收边播
        print("[play]", event.get("delta", ""), flush=True)


if __name__ == "__main__":
    session = DuplexSession()
    threading.Thread(target=session.sender_loop, daemon=True).start()
    threading.Thread(target=session.receiver_loop, daemon=True).start()
    for i in range(5):  # 模拟麦克风持续送入音频 chunk
        session.send_chunk(f"audio-chunk-{i}")
    # session.user_interrupt()  # 需要演示打断时调用

骨架里三个环节对应三件工程事。分块发送对应输入侧的连续封装，音频、视频、文本都能切成 chunk 进入同一条队列；逐 chunk 收流对应输出侧的即到即播，收流和播放之间不设整段缓冲；打断处理讲究顺序——先把本地播放静音，再发 interrupt 帧，服务端按已生成 chunk 的边界截断在途生成，这个边界同时就是计费边界，成本一节细说。留一条半双工兜底也是必要的：全双工通道抖动时，普通问答还能落到标准 chat 接口上，产品不至于整块失能。

两种交互范式对照表

把轮次式和全双工流式放在一张表里看（表中数值均为演示参数，用于呈现结构差异；实际表现与计费以所选链路和中转站说明为准）：

表格读法：延迟结构与打断体验决定产品形态的上限，计费模型决定运营成本的下限。选型之前先把这两笔账分开算，再看场景匹配度，顺序反了很容易做出"体验好但账算不平"的实时化改造。

中转层选型：延迟优先路由怎么配

全双工链路进了中转层，路由策略要和普通 chat 分开设计。我的做法是分池：实时全双工会话进延迟优先池，普通问答进吞吐优先池，两套健康检查、两套切换逻辑。延迟优先池看三条指标——节点就近程度、长连接稳定性、首响延迟分布；吞吐优先池看并发承载与单位成本。健康检查带 RTT 探测，探测周期与切换阈值都是演示参数，要按真实流量压测之后再定。

两条铁律。一是会话粘性：全双工连接一旦建立就不该中途漂移节点，切换等于把打断体验整个毁掉，重连成本远高于普通请求重试。二是降级路径：延迟优先池整体不可用时回落半双工 chat 接口，宁可损失全双工形态，也不让会话挂死。营销流量来了先排队限流，别把连接池一次打穿——长连接的并发容量和短请求完全不是一个数量级，这一点在容量规划时就要写死。

避坑清单：打断边界、噪声、多人对话

打断边界

• [ ] 打断处理顺序固定：先静音本地播放，再发 interrupt 帧，最后等服务端确认，顺序颠倒会"嘴停了声音还在放"
• [ ] 已生成 chunk 与未生成 chunk 的计费口径提前与中转站对齐，写进接入文档
• [ ] 打断后重置会话状态，别让上一句的残句混进下一句的上下文
• [ ] backchannel（附和插话）要与真正打断区分开，短促附和不应触发中断

噪声场景

• [ ] 背景噪声下按场景调 VAD 灵敏度，宁可让模型多看到"疑似人声"，也不要漏掉真实打断
• [ ] 音乐与电视音是重灾区，接入层保留一个手动静音开关兜底
• [ ] 最小打断时长从演示参数起步，现场实测再调，避免一声咳嗽就掐断播报

多人对话

• [ ] 多人同场先定义"谁说了算"，说话人分离没接稳就别开主动追问
• [ ] 会议室场景收窄拾音范围，降低远场串音误触发打断的概率
• [ ] 把评测里的三类鲁棒性考题（背景噪声、多人对话、backchannel）逐条搬进自己的测试集

成本与风险提示：连接时长与 chunk 边界

全双工的账单结构和轮次式不一样，两处最容易踩。

第一处是连接时长计费。按连接时长计费的部分，页面挂着、后台没关、空闲不摘，表就在走。会话要有空闲检测，超时主动断开；重连要做成幂等，恢复上下文别靠客户端硬存，靠服务端会话快照。上线前先在演示环境跑一遍"挂着不动一小时"的成本测算，很多产品形态的实时化冲动会被这张账单浇醒。

第二处是 chunk 计费边界。用户打断之后，服务端已经生成的 chunk 算不算钱？通行口径是按服务端已产出部分结算，被打断丢弃的部分不计，具体以中转站计费说明为准。接入层要做的配套是：UI 把打断前的播报干净利落地收掉，避免"没听完还照付"的情绪变成客诉。

风险侧三条。音视频采集要有明确授权与告知，实时音流不挪作他用；只做合法接入与合规优化，不碰任何绕过官方限制的手段；长连接对服务端的压力数倍于短请求，限流、排队、熔断三件套一个都不能少。

总结

这一期把 Gander 讲了四件事。一是痛点：轮次式"说完才想、想完才说"的三段串行结构（ASR→LLM→TTS）天生自带同步点，打断还要额外付 VAD 与回滚的工程代价。二是架构：Gander 用"小脑-大脑"协作框架把实时交互与复杂推理分而治之，两者靠工具调用与 Agent 编排运行时持续交互；小脑基于流式 Thinker-Talker，把用户输入与模型输出摊到同一条 chunk 级有序 token 流上，从架构层面砍掉串行等待。三是接入：从 OpenAI 兼容入口起步，全双工会话按"分块发送、逐 chunk 收流、打断即中断"的骨架搭建，普通问答留半双工兜底，中转层按延迟优先路由分池选路。四是账本：盯住连接时长计费与 chunk 计费边界两处陷阱，避坑清单覆盖打断、噪声、多人对话三类场景。评测的四个维度里，交互能力与鲁棒性是我最想持续跟下去的观察点；模型、代码、数据全开源，接入门槛会随生态迅速摊薄，4sapi.com 的中转站也会同步跟进这条链路的选型与上架节奏。Gander 式的全双工能不能让"跟机器说话"终于像"跟人说话"，欢迎在评论区发表想法。