英文题目：Decoding the Trade-off: A Large-Scale Analysis of Latency and Stability in LLM-based Speech Translation Cascades
会议身份：
conference:interspeech:2026:conference-paper-id:sun26f_interspeech
来源为官方会议 PDF；图片依据原页像素，表格数字依据原文引用。PDF 文字层不视为原始 TeX，未可靠恢复的结构不作推断。
标签：#评测协议 #高效推理 #流式处理 #语音翻译
评分：6.4/10 | 创新 1.2/2 | 技术严谨 1.0/1.5 | 实验充分 1.2/1.5 | 清晰度 0.8/1 | 影响力 0.9/1.5 | 开源 0.0/1.5 | 可复现 0.3/0.5 | 工程/实践 1.0/1.5
排名：前50% | 文档类型：系统技术报告
👥 作者与机构
- Shinyoung Sun：机构信息未能从会议 PDF 纯文本可靠映射
- Taehoon Kim：机构信息未能从会议 PDF 纯文本可靠映射
📌 核心摘要
韩语到英语实时字幕需将连续语音转为可读译文，难点在于分段过细会推高云端请求到达率并引发排队累积，同时韩语主宾谓结构又要求足够上下文才能保证英译质量。本文构建可复现字幕管线先由语音活动检测端点切分音频并控制到达率，其输出波形依次进入云端语音识别得到首现文本，再经机器翻译得到稳定译文并区分首现延迟与稳定延迟。该工作以吞吐稳定性为选择准则，提出保留中位实时因子不超过1的最激进可操作阈值，以区别于只评估单次请求延迟的已有方法。在FLEURS韩英全量语料约9.6小时回放评测设置下，stable预设下gpt-4o-transcribe加gpt-4.1-mini级联的BLEU为11.5，高于fast预设下同一级联的BLEU1.9。与单端到端延迟评估不同，该机制差异揭示了激进分段因利用率超限进入积压区而使稳定延迟随时间累积的实际意义。韩英翻译还存在约2至3秒的上下文门限，低于该窗口质量即饱和受损。结论仅适用于非词流式单假设云级联与该语料分布，换语言对、换本地流式模型或高并发生产负载均未验证。其适用边界受限于上述级联与韩英回放语料，原文未披露训练、推理或部署成本。
🔗 开源与复现资源
本次未形成可展示的已核验资源记录，开放状态尚未核实。 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
输入是什么，要输出什么，为什么快不等于稳？
这篇论文研究的输入是连续的韩语会议或讲座语音，目标是实时输出可读的英语字幕。系统不是 1 次翻译整场录音，而是一边听一边切段，一边识别一边翻译，一边把字幕顶上屏幕。研究生刚进语音或翻译领域时容易把注意力放在单个模型准不准、多快返回，但这篇工作的起点是系统视角：切分决定了多久更新 1 次字幕，也决定了每秒要向云端发多少次请求。
用户实际会看到两个时刻。第一个时刻是屏幕上冒出点什么，哪怕是韩语识别的初步结果，这决定了感觉快不快。第二个时刻是英语译文最终定稿不再跳变，这决定了能不能读、能不能用。论文把前者叫做首次文本延迟，后者叫做稳定文本延迟。如果只报一个端到端延迟，就会把提前露头和最终稳定混在一起，看不出 1 次改动到底是真快了，还是把等待从识别挪到了翻译。
更关键的是吞吐。每个切出来的小段都会触发 1 次识别请求加 1 次翻译请求。切得越碎，请求到达率越高。只要到达率接近或超过云服务的有效服务能力，排队就会越积越长。此时每个请求单独看都很快，但字幕整体越来越慢，而且运行越久越慢。
论文把这种状态叫做积压区，用中位实时率大于 1 来标记。理解这个背景后，后面的切分预设、模型矩阵和回放实验才有学习依赖：先有两类延迟的定义，再有实时率的判据，再谈哪种配置可持续。
同输入同目标的三条路线有何不同？
第一条路线是同时语音翻译与评测真实性。已有工作讨论延迟质量权衡在不同评测指标下结论会变，也有批评指出不能假设预切分好、忽略各组件运行时间，而要在流式约束下做端到端评测。这篇论文与它的区别是研究对象是分段式云级联，不做词级流式，并且明确把感知延迟和定稿延迟拆开。
第二条路线是切分与端点检测。早期级联流式翻译把切分当作延迟质量旋钮，切得短延迟低但质量可能掉。这篇论文不否认这个视角，但把重点移到系统级吞吐：更短的段意味着更高的云端请求率，即使单次推理很快，也可能诱发积压。这是从模型权衡到系统容量的视角转移。
第三条路线是端到端音频大模型。近年多模态大模型可以直接转写加翻译，但生产系统仍常用级联，因为模块可替换、可控、易排障。本文的定位就是为这类级联提供可复现的协议和以稳定性为中心的分析。
级联流水线 × 端到端音频大模型： 级联流水线分工是把采集切分识别翻译解耦为可替换模块，端到端音频大模型分工是 1 次完成转写翻译，搭配比较的理由是二者输入目标相似但运行阶段与可控性不同，组合意义是说明生产仍用级联时必须单独研究切分对云端吞吐的系统级影响。
对初学者而言，对照的公平性在于输入都是连续语音、目标都是低延迟可读译文、运行阶段都是在线 serving，而不是拿预切分数据集上的离线分数直接比流式延迟。本文的增量不是提出新翻译模型，而是把切分、吞吐、上下文完整性三者的三角关系量化出来。
要回答的具体问题是什么？
论文要回答 3 个可操作的问题。第一，切分变激进时，用户看到的首次延迟和最终稳定延迟分别怎么变，翻译质量怎么变。第二，在什么边界上系统从吞吐稳定掉进积压，边界能否用一条简单规则选出来。第三，短块下给识别器加提示到底是帮忙还是添乱。
形式化上，每个 utterance 有一个封口时刻，也就是端点检测器决定这段到此为止的时间。对该段定义首次延迟为识别完成时间减去封口时间，稳定延迟为翻译完成时间减去封口时间，实时率为稳定延迟除以该段语音时长。当中位实时率大于 1，系统在稳态下跟不上实时，排队延迟会累积。
举例只是帮助理解，不是论文数据：比如一段 3 秒的语音，如果从封口到译文定稿花了 6 秒，实时率就是 2，意味着处理速度只有说话速度一半，越跑欠账越多。论文的全部实验就是围绕这个判据，在受控回放下比较不同切分和不同识别加翻译组合。
可复现流水线是如何走完一个样本的？
论文搭建的系统叫做可复现字幕流水线，处理韩译英。走完一个样本的路径是：麦克风或回放送来音频，先进基于语音活动检测的端点检测器，按积极度、最小时长、最大时长和挂起时间切出一个 utterance，接着调 1 次语音转文本引擎得到韩语假设，再调 1 次机器翻译引擎得到英语字幕，最后渲染上屏。当前实现每个阶段对每个 utterance 只给一个最终假设，不做词级流式增量输出，所以切分直接控制请求到达率。
实时率 × 积压区： 实时率分工是用稳定延迟除以语音段时长来判断处理能否跟上实时，积压区分工是描述到达超过服务能力后排队延迟主导的状态，二者搭配的理由是单看每次请求都很快会误判，组合意义是以中位实时率是否大于 1 作为是否进入随时间越拖越慢的边界判据。
为保证可分析，作者在应用外包了一层日志。后端本来就会发出切分边界、识别输出和翻译输出的事件，日志包装器不改业务逻辑，只把这些事件收成每 utterance 一条的 JSON 行记录，里面有原始时间戳、推导出的首次延迟、稳定延迟、实时率、引擎标识和切分元数据，离线质量指标也挂到同一条记录上做联合分析。这种设计让延迟分布和翻译质量可以在同一口径下对照。
全量评测用受控回放协议，去掉麦克风和声卡差异：每个片段解码成单声道脉冲编码音频，直接喂进与线上相同的端点检测路径，保证所有配置听到完全相同的波形。回放按实时进行，片段之间留静音间隔以减少边界粘连。教学上可以这样记：先固定输入波形，再换切分和模型，最后看同一批记录里的延迟与质量。
切分、识别、翻译各自管什么？
切分组件用 WebRTC 语音活动检测，只用 4 个参数：积极度、最小块时长、最大块时长、挂起时间。论文对比两个预设。快速预设更激进，最小块更短、挂起更短，用作压力测试。稳定预设把最小块和挂起拉长，降低请求压力。切分不做翻译，它只决定 utterance 边界和请求节奏。
识别组件在 2 乘 2 矩阵里有两个选项：传统声学基线和基于大模型的转写服务。翻译组件也有两个选项，两个轻量或快速大模型。识别管韩语字错率，翻译管英语 BLEU 与字符级分数，但识别错会传给翻译，所以转写质量是下游质量的关键驱动。
端点检测 × 请求到达率： 端点检测负责把连续音频切成 utterances 并决定何时封口发射，请求到达率是单位时间产生的识别加翻译请求数，二者搭配的理由是每切一段就触发 1 次云端调用，切得越碎到达率越高，组合意义是把切分从字幕更新频率问题转化为吞吐与排队问题。
首次文本延迟 × 稳定文本延迟： 首次文本延迟分工是度量封口时刻到识别结果可见的时间，代表感知响应，稳定文本延迟分工是度量封口时刻到最终译文完成的时间，代表字幕定稿，二者搭配的理由是只报端到端会混淆变快与挪延迟，组合意义是可以判断 1 次改动是真提速还是把等待从识别挪到翻译。
沿一个样本走一遍：假设一段韩语发言被切成 3 秒多的 utterance，封口后先等识别返回算出首次延迟，再等翻译返回算出稳定延迟，稳定延迟除以 3 秒多得到该段实时率。所有段的中位实时率决定这次运行是否可持续。如果为了更快更新而把 3 秒切成 1 秒，更新次数变多，但请求数也翻几倍，云端队列可能反而让稳定延迟从几秒涨到几十秒。
本研究训练了什么，没有训练什么？
本研究没有训练任何声学模型或翻译模型，也没有微调提示或端点检测器。论文明确的动作是调用既有云服务、做切分搜索、做日志仿真与计算。缺项也要说清：原文没有报告任何梯度路径、参数冻结或更新、优化器、学习率、训练轮数，因为不存在训练阶段，不能从模型名字推定其内部实现，也不能把调用云端等同于确定性求解。
真实计算过程是系统与评测侧的。系统侧是 VAD 切分、1 次识别调用、1 次翻译调用、渲染。评测侧是回放、打日志、算延迟分布与离线质量。离线质量的算分方式是把每 utterance 输出按片段拼回整段，再与行对齐参考对比，报韩语字错率、英语 BLEU 与字符级分数。延迟侧报首次与稳定延迟的中位与四分位距，实时率按稳定延迟除以段时长计算。
提示消融同样没有训练，只是切换解码条件：关闭提示、上文滚动提示、静态指令提示，且在片段边界重置提示，并关闭翻译以孤立识别影响。这意味着所有质量差异都来自相同输入下的解码与切分条件变化，而不是模型权重变化。复现时应把重点放在固定波形、固定切分参数、记录完整时间戳，而不是找训练脚本。
数据、协议、指标与对比条件是什么？
数据用 FLEURS 的完整韩译英子集，规模是两千多个片段、总计约 9.6 小时音频。回放时每个片段解码成单声道后走同一 VAD 路径，按实时播放，片段间留 2 秒静音减少边界合并。这样的好处是所有切分预设和所有识别加翻译组合都听到相同波形，比较不受录音设备方差污染。
对比条件有两个维度。切分维度是快速与稳定两个预设，再加一个只变最小段时长和挂起时间的激进程度扫描，用于画出稳定与积压的边界。模型维度是两种识别乘两种翻译的级联。指标方向要记牢：首次延迟与稳定延迟越小越好，实时率越小越好且以 1 为界，韩语字错率越小越好，英语 BLEU 与字符级分数越大越好。延迟看分布，不只看均值，论文用中位与四分位距概括。
操作阈值的定义是满足中位实时率小于等于 1 的最激进切分设置。也就是说，在不掉进积压的前提下尽量切得碎。这个定义把吞吐稳定性变成选参规则，后文所有推荐运行点都按这条规则挑。
快速预设为何在稳态下更慢？
要比较的问题是：在相同波形与相同模型下，只把切分从稳定换成快速，延迟与质量谁赢，条件是否公平。公平性来自受控回放保证输入相同，指标方向是延迟与实时率越小越好、翻译分数越大越好。论文报告显示，快速预设切出更短的段，但把级联推进积压区，请求率上升、吞吐失稳、中位实时率大于 1，排队延迟主导稳定延迟。稳定预设降低请求压力，保持可持续吞吐，稳定延迟更低且翻译质量更高。
下图把这种背离可视化，左图是稳定延迟随实时率的变化，右图是稳定延迟随运行时间的变化。读图前先确认左图横轴是实时率对数刻度、纵轴是中位稳定延迟秒数，图例区分稳定与快速，右图横轴是运行分钟数、纵轴是稳定延迟秒数，蓝线是每 30 秒中位。
看图路径： 1. 先看左图横轴实时率对数刻度与纵轴中位稳定延迟，确认蓝色稳定点与红色快速点的位置分离；2. 再看左图在实时率等于 1 处的虚线，比较线左侧与右侧延迟量级差异；3. 然后看右图横轴运行分钟数与纵轴稳定延迟，观察 4 分钟后阶梯中位线是否持续抬升；4. 最后对比右图散点与阶梯线的包络，判断延迟是偶发抖动还是随时间累积
论文图 1。原论文 Figure 1：“Backlog diagnostics from schema logs.”。
从像素可见，左图蓝色稳定点聚在实时率 1 附近、纵轴只有几秒，红色快速点跳到横轴二十多到六十多、纵轴几十秒，中间被虚线隔开，说明过界后延迟不是线性变差而是量级跳变。右图蓝线在前 4 分钟贴着 2 秒左右走，4 分钟后阶梯抬升到 10 秒再到 20 秒左右，散点也同步上移，说明延迟随任务时间累积，符合到达超过服务能力的排队解释。这支持论文的判断：名义上更快的切分在稳态下更慢。
下表整理提示消融的定量结果，用于说明识别侧的另一类不稳定，表前问题是加提示能否改善短块识别，公平条件是同一切分、同语料、关闭翻译，指标方向是字错率越小越好、泄漏率越小越好。
| 条件 | 指标 | 无提示 | 滚动上文提示 | 静态指令提示 |
|---|---|---|---|---|
| 稳定切分短块 | 韩语字错率 | 26.5% | 43.7% | 40.8% |
| 稳定切分短块 | 相对无提示变化 | 0.0 | +17.1 | +14.3 |
| 稳定切分短块 | 指令泄漏率 | – | – | 7.9% |
表后解释是：两种加提示都比不加提示差很多，滚动上文增加约 17 个百分点，静态指令增加约 14 个百分点且有约 7.9% 的假设泄漏提示文本。代价不只是分数，还有可靠性。未胜出项就是加提示的两组，它们本应提供上下文却全部落败。边界是该消融只在稳定切分、关闭翻译下测识别，没有覆盖快速切分下的提示行为，也没有测不同字符预算的影响。
服务时间与上下文窗口如何塑造边界？
除主预设对比，论文还用两组机制实验解释边界从哪来。第一组是服务时间压力测试，用模拟识别加翻译服务固定每段耗时，看不同最大块长下中位稳定延迟怎么变。第二组是韩译英上下文底线，看不同最大块长下 BLEU 怎么变。问题分别是：单段变慢会不会把拐点推向更大块，以及韩语主宾谓结构是否要求最小上下文。
下图左面板横轴是最大块长毫秒数、纵轴是中位稳定延迟毫秒数，蓝线是每段 200 毫秒服务，红线是每段 500 毫秒服务。右面板横轴同样是最大块长、纵轴是 BLEU 分数，灰带标出韩语谓语带来的拐点区。
看图路径： 1. 先看左图横轴最大块长与纵轴中位稳定延迟，对比 200 毫秒与 500 毫秒两条模拟服务时间曲线；2. 再看左图小块长一侧红色虚线是否陡升，确认服务时间变长如何把拐点推向更大块；3. 然后看右图横轴块长与纵轴英译得分，观察 2000 到 3000 毫秒附近灰色带的斜率变化；4. 最后判断右图超过该带后得分是继续陡升还是趋于饱和
论文图 2。原论文 Figure 2：“Two mechanisms shaping the latency–stability frontier.”。
从像素可见，左图蓝色 200 毫秒线几乎贴着底部横走，红色 500 毫秒线在小块一侧高达 2500 毫秒左右随后陡降到 1000 毫秒平台，说明服务时间越长，小块的排队惩罚越陡，拐点向右移。右图绿线从几百毫秒的不足 1 分爬到 1000 毫秒约 3 分、2000 毫秒约 6 分、2500 毫秒约 8 分，之后到 5000 毫秒缓慢爬到约 10 到 11 分，灰带正在 2000 毫秒附近，说明 2 到 3 秒前加上下文收益大，之后饱和。这支持两个判断：吞吐边界取决于到达与服务之比，翻译质量还受语言结构决定的上下文底线约束。
提示条件 × 短块流式： 提示条件分工是给识别器注入上文或指令以补上下文，短块流式分工是在端点频繁截断下每次只解码很短语音，二者搭配出问题的原因是为长语音设计的上下文机制在频繁重置时不可靠，组合意义是解释为何加提示反而显著推高字错率并出现指令泄漏。
下表整理语料与运行规则的规模信息，表前问题是结论的外推需要多大 workload 支撑，公平条件是全文统一回放协议，指标方向是规模越大、间隔控制越严越可信。
| 数据集 | 语向 | 片段数 | 总时长 | 片段间隔 |
|---|---|---|---|---|
| FLEURS | KO→EN | 2,851 clips | ∼9.6 h | 2 s |
| FLEURS | KO→EN | 2,851 clips | ∼9.6 h | 2 s |
| 阈值规则 | 稳定条件 | 中位实时率 | 边界值 | 选择 |
| 阈值规则 | 稳定条件 | median RTF | ≤1 | 最激进满足项 |
表后解释是：全量两千多片段、约 9.6 小时的体量让积压有时间累积出来，2 秒间隔减少边界合并但仍保留连续运行压力。操作阈值选最激进且中位实时率不超过 1 的设置，低于该界延迟有界且随评估时长可扩展，高于该界延迟随时间累积。未评测边界是更长的连续会议、网络抖动、并发用户，这些都可能移动有效服务能力，论文的阈值应理解为代表性负载下的调参起点。
哪些结论有界，哪些不能外推？
直接报告的是：在该韩译英回放语料、该 VAD 参数、该云服务时间段内，快速切分进入中位实时率大于 1 的积压区，稳定延迟随时间增长，翻译分数更低，加提示推高字错率并泄漏指令。这是数据显示的。
有限解释的是用到达率与服务率、利特尔定律解释排队累积，以及韩语主宾谓要求 2 到 3 秒上下文。这能解释趋势方向，但论文没有公开每段服务时间的完整分布与云端并发配额，所以不能算出精确排队公式，只能说机制上支持。
待验证的是：换语向、换供应商、换网络、换长会议是否同一阈值；更激进但带退避重试的切分能否绕开积压；不同提示预算与重置策略能否救回短块识别。原文未测量误判率、端到端人工可读性、成本与能耗，不能承诺这些量同步改善。总体趋势不等于每段都成立，个别长段在稳定预设下仍可能延迟偏高。读数时还要区分百分点与相对百分比：提示带来的是字错率百分点上升，不是相对 10% 几。
要复现应先固定什么，再扫什么？
复现先做输入固定。把 FLEURS 韩译英全集解码成单声道脉冲编码音频，走同一 VAD 路径回放，按实时播放并保留片段间静音。不要用麦克风重录，否则波形差异会污染切分对比。日志必须按每 utterance 记录切分边界、识别与翻译的原始时间戳，再推导首次延迟、稳定延迟与实时率，离线分数按拼回片段后与行对齐参考对比。
再扫切分。先跑论文的快速与稳定两档，确认中位实时率是否分居 1 的两侧、稳定延迟是否一侧有界一侧随时间爬升。然后只动最小段时长和挂起时间做激进程度扫描，保持最大时长封顶，找出满足中位实时率小于等于 1 的最激进点。模型矩阵可用同类识别与翻译服务替代，但要记录引擎标识与测试时段，因为云端服务时间会漂。
资源状态是正文开源声明的唯一依据，本次没有发现来源绑定且完成超文本传输安全协议状态验证的资源，不得声称代码模型或数据已公开。论文致谢与参考文献给出的数据集与模型线索只用于理解条件，不等于可下载可运行。复现报告应写清本次未能确认可达的链接、实际调用的服务版本、失败重试策略与并发数，否则排队行为无法对比。
何时值得用这套思路，何时不值得？
当你的系统是分段式云级联、每段触发 1 次识别加 1 次翻译、且用户同时在乎冒头快与定稿稳时，这套思路值得直接拿去用。先把两类延迟拆开埋点，再用中位实时率是否小于等于 1 选切分，最后在 2 到 3 秒上下文底线之上尽量切碎。这样选出的稳定加高质识别加轻量翻译的组合，在论文的韩译英基准上给出稳健的延迟稳定运行点。
当你的系统是词级流式、本地推理、或语向不需要长上下文时，不要照搬 2 到 3 秒与具体预设数值，只借方法：固定波形回放、扫切分 aggressiveness、看延迟是否随时间累积。短块下不要默认加提示有帮助，论文的反例是加提示反而更差且可能泄漏指令，无提示解码是更稳的基线。
给研究生的行动清单是：第一，为自己的语向重测上下文饱和曲线，找到 BLEU 不再陡升的块长。第二，为自己的服务商重测服务时间压力曲线，找到拐点。第三，把操作阈值写进上线配置，而不是只记单次延迟均值。缺的验证是人工可读性、长会漂移与成本，下一步应补这些，而不是继续调提示措辞。
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
- 评分规则：type-aware-v1
- 评分模型：muse-spark-1.3-contributor
- 评分请求协议：openai_responses