边听边译，究竟是怎么算出来的
一次 1.6 秒音频的完整推理旅程

00先给结论

这套推理的本质不是"流式 ASR + 流式 MT"的级联，而是把同声传译当成一场多轮对话： 每 1.6 秒音频就是用户发来的一条新消息，模型回答"这一块我现在能确定的那部分译文"，说完就停。

1. 切块。音频按 1.6 s 一段滑进缓冲，首块严格 1.6 s；VAD 判定为静音的块直接跳过，根本不发请求。
2. 长上下文。每一轮请求都把之前所有音频块 + 之前所有译文重新发一遍，新的一块音频追加在最后。
3. 模型续写。模板让模型永远停在"接着我上一句话往下说"的位置，于是术语、语气、句法自然连贯。
4. 自己决定说不说。有把握就吐字（EMIT），没把握就输出空串（WAIT）——"什么时候开口"由模型判断，不是外部 wait-k 策略。
5. 兜底追平。连续 4 块都没出字、或 2.4 s 静音、或音频结束，就把积压音频整段重译一次，一口气补上。
6. 防爆。上下文随对话线性增长，所以有三条切断线：输出被截断、token 预算逼近、定时切窗。

01整体路径：从麦克风到耳朵

一次请求要穿过五个阶段。左侧三段的职责是把连续音频整理成模型能吃的离散输入， 右侧两段负责把模型的稀疏输出还原成连续的说话节奏。

为什么第 1 段必须固定 1600 ms

首块长度在代码里被硬校验：first_chunk_ms 必须等于 1600，后续块只能是 800 或 1600 （config.py __post_init__）。这不是随意取的数——1.6 秒大约是一个短句的最小完整单元， 首块太短模型无从下手，太长则开场就要等两秒。

# simulinfer/translation.py:376  —— 按首块/后续块不同长度切流
size = (self.settings.first_chunk_ms if self.index == 0 else self.settings.chunk_ms) * 16
if len(self.buffer) < size: break
chunk, self.buffer = self.buffer[:size], self.buffer[size:]
yield await self.step(chunk, size)

02切块与静音：什么时候根本不叫模型

切块之后并非每块都会触发推理。VAD 会给每一块打上"是否静音"的标签， 静音块直接被丢弃而不产生任何模型调用（skip_initial_silence 默认开启）。 这次省下的不只是一次前向，而是一整个往返。

VAD 只做三件事，但每件都影响正确性

两个细节值得注意。第一，VAD 的状态不随对话窗口重置而重置—— 代码注释写得很直白："only real source samples advance VAD and the progress cursor"， 源时间轴与模型对话轮次是两套独立的时钟。第二，人声区间裁剪只影响送给模型的音频， 不影响源时间轴上的记账，所以被裁掉的静音不会被误算成"漏译"。

到这里，输入已经变成"每 1.6 秒一个、带静音标记的音频块"。接下来的问题是： 这些块怎么变成模型能读的上下文？

03请求是怎么"长"出来的

这是整套机制最反直觉的地方：没有增量状态，每一轮都把全部历史重发一次。 会话里维护一个 messages 列表，每处理一块音频就往后追加两条——一条 user（音频块）、 一条 assistant（这一块的译文）。下一轮把这个列表原样再发一遍，末尾再加上新的一块音频。

模板把"对话"翻译成"续写"

光有 messages 还不够，关键在 chat 模板怎么渲染。模板给每个音频 part 展开成三个特殊标记， 给每条 assistant 历史补上角色头与结束符，最后让模型停在"接着说"的位置：

<｜hy_begin▁of▁sentence｜><｜reasoning_mode｜>reasoning_effort:no_think
<｜hy_User｜>请完成下面的同声传译任务……不必等待整句结束。
   <｜hy_place▁holder▁no▁6｜><｜hy_place▁holder▁no▁5｜><｜hy_place▁holder▁no▁8｜>   ← 音频占位，中间那个会展开成 11 个语音词元
<｜hy_Assistant｜><think></think>所以关键的想法是<｜hy_EOT｜>
<｜hy_User｜>   <｜hy_place▁holder▁no▁6｜><｜hy_place▁holder▁no▁5｜><｜hy_place▁holder▁no▁8｜>
<｜hy_Assistant｜><think></think>  ← 模型从这里继续往下写

请求侧怎么把它接上？分两种情形。只出译文的模式走标准生成提示——模板在末尾补一个空的 assistant 角色头， 模型从空白处开始写。需要续写已有内容时（Interleave 模式要先写源文、ST 补偿时要接上旧译文）， 改用 continue_final_message：把一段 assistant 前缀塞进 messages，让模板不补生成提示， 模型从这段前缀的末尾继续往下写。

# simulinfer/translation.py:61-83  —— 极简版
continuation = prefix if prefix is not None else (SRC if mode == 'source_target' else None)
fields = {'messages': wire,
          'add_generation_prompt': continuation is None,
          'continue_final_message': continuation is not None,
          'add_special_tokens': False}
if continuation is not None:
    wire.append({'role': 'assistant', 'content': [{'type': 'text', 'text': continuation}]})

两种输出模式

04模型内部：1600 ms 如何变成 11 个词元

音频不是以"文本转写"的形式进入 LLM 的。它先被压成一条很短的离散序列， 再从词嵌入表旁边"借道"插进语言模型里。整条链上有两次压缩，合起来把 160 个 mel 帧压成 11 个词元， 时间轴上每个词元代表约 145 ms。

把数字验一遍

这几个数字不是估的，是 budget.py 里三行算术算出来的，可以直接复跑：

# simulinfer/budget.py:27-34
def speech_tokens(num_samples):
    frames = (num_samples + 159) // 160          # 16 kHz / hop 160 → mel 帧
    tail   = (frames % 100 + 7) // 8             # 尾块每 8 帧出 1 帧
    return (frames // 100 * 13 + tail + 1) // 2  # 每满百帧出 13 帧，再按 FSK k=2 折半

占位符是怎么被"撑开"的

请求里音频只体现为一个占位符，但服务端算出的 prompt token 数必须把 11 个位置算进去。 render() 在渲染模板之后做了一个偏移修正：每出现一个音频 part，就加上 speech_tokens(n) − 1，因为占位符本身已经被计过一次。 这个数在生成后还会被核对一遍——如果 usage.prompt_tokens 不等于预算值， 说明模型侧的音频模板与推理层不匹配，直接抛错而不是"带病继续译"。

# 真实响应里的计数校验（translation.py:263）
if budget is not None and actual != budget.prompt_tokens:
    raise RuntimeError('模型音频token计数与SimulInfer模板不一致')

05说不说：一步决策的全部逻辑

模型返回之后，会话层只做一件事——看这段文本是不是空的。这个判断看着太简单， 但它是整条链路里唯一决定"用户什么时候听到声音"的地方。

用一段话跟到底

下面用一句 8 秒的英文口语走一遍，假设方向是英译中。每条译文都是示意， 用来展示节奏，不是模型实测输出。

四道输出约束

"让模型自己决定"不等于放任。采样端挂了四个约束，防止它在长上下文里跑偏：

06说漏了怎么办：ST 整段重译

模型"忍一下"是有代价的。如果演讲者进入一个很长的从句、或者环境噪声让模型持续不敢下判断， 就会连续多块空输出。这时听众已经七八秒没听到任何东西，必须有人介入——这套机制叫 ST 补偿。

三个触发口

这三个口子最终都进同一个函数 flush()。它内部还有几道防重复的闸： 同一段音频不重复尝试（用起止采样点做 key）、超过 st_fallback_max_seconds 就裁掉头部并记一笔"漏译"、 结果为空则丢弃并可选重置。这些细节不影响理解主链路，但决定了长时间运行的稳定性。

07上下文什么时候撑爆

第 3 节说过每轮重发全部历史。这个设计的成本是线性的：说得越久，每次请求越长。 按默认参数估算，音频本身每分钟贡献约 412 个 token，译文再贡献约 190 个。

三条切断线

上下文逼近上限时的处理不是"报错"，而是主动断开对话、从零开始。 切断点有三处，都汇总到 cut()：

1. 输出被截断（finish_reason == 'length'）。这一轮已经写满 64 个 token 还没说完，说明模型在"补一大段"， 而 prompt 也快满了。默认先抛错（reset_on_max_tokens = false），可配置成保留部分输出后重置。
2. token 预算逼近。prompt + completion + 256 ≥ max_model_len 时切断。256 是留给下一轮的余量。
3. 定时切窗。window_seconds 默认 0（关闭），开启后按固定时长重置，用于超长会议。

切断前一定先 flush()：把未成句的音频译完再清空，避免"切断瞬间丢掉半句话"。 清空只清对话（messages、等待计数），不清 VAD 状态，也不回退源时间轴—— 这两套时钟是分开的，第 2 节提过。

# simulinfer/translation.py:549-566  —— 切断的顺序很重要
async def cut(self, event, reason):
    if any(not b[3] for b in self.pending):
        await self.flush(event, force=True, trigger=reason)   # 先译完
    ...
    if self.run == run:
        self.reset(event, reason)                                    # 再清空

08把节奏摊平：一段 8 秒的完整时序

前面几节拆的是零件。这里把第 5 节的例子摊到时间轴上，特别注意第三行的积压—— 它解释了为什么"块 3 没说出话，块 4 却能把它一起译出来"。

延迟到底由什么决定

从这张图能直接读出这条关系：

用户听到第一个字的时间 ≈ 首块长度 + 一次推理往返
                       ≈ 1.6 s + (prefill + decode)

句子被完整译出的时间 ≈ 句子结束时刻 + 一次推理往返 + 可能的补偿
                       （如果模型中途 WAIT 过，就要等见证后续音频的那一轮）

第一行是硬下限，1.6 秒无法绕过——要译一句话，至少得先听完这么大一块。 第二行才是质量与延迟的真实权衡点：模型越敢"提前说"，第二行越短、但改口概率越高； 越保守，质量越稳、但听众等得越久。README 里 StreamLAAL ≈ 3 秒，本质上就是这个权衡的产物。

09代码地图

想把某个环节落到具体文件时查这张表。行号对应当前仓库版本。

10自己验证这些数字

三个不需要 GPU 的复算，直接对着仓库跑就能对上：

# 1. 语音词元数（纯算术，不依赖 torch）
python3 -c "from simulinfer.budget import speech_tokens; \
print([speech_tokens(n) for n in (25600, 12800, 480000)])"
# → [11, 5, 195]

# 2. 模板渲染后长什么样（看占位符与角色头的位置）
python3 -c "from simulinfer.budget import render; \
print(render([{'role':'user','content':[{'type':'text','text':'probe'}]}], 'target_only')[0])"

# 3. 真实跑一遍，观察每个 chunk 的事件字段
curl -N http://127.0.0.1:8080/translate/stream -F direction=en-zh -F file=@audio.wav

第 3 条会流式吐出 JSON 事件，每块一个，看 action（WAIT/EMIT）、 prompt_tokens（是否随轮次线性增长）、stop_reason（是否正常收尾）、 st_attempted（有没有触发补偿）。这四个字段基本能还原每一次决策的来龙去脉。