📄 不等目标前缀也能写候选：As2d 把音频本身当作起草依据
英文题目：AS²D: Accelerating On-Demand Audio Understanding on Mobile Devices
标签：#语音识别 | #模型融合 | #高效推理 | #端侧运行 | #语音
评分：7.4/10 | 创新 1.6/2 | 技术严谨 1.2/1.5 | 实验充分 1.3/1.5 | 清晰度 0.8/1 | 影响力 1/1.5 | 开源 0/1.5 | 可复现 0.3/0.5 | 工程/实践 1.2/1.5
👥 作者与机构
- Yunzhe Li：The University of Texas at Austin
- Kyoungjun Park：The University of Texas at Austin
- Hongzi Zhu：Shanghai Jiao Tong University
- Lili Qiu：The University of Texas at Austin
📌 核心摘要
面向音频已缓存的按需理解需要在请求到达后自回归生成完整回复，手机端串行起草常抵消批量验证收益。所提音频推测解码 Audio Speculative Decoding，简称 AS2D，让音频条件起草器只依据固定音频视图、文本指令与自身历史发布候选块，目标模型沿权威提交前缀独立验证或单独解码，对齐模块仅移动缓冲游标并回收可用后缀，设备画像离线选定固定起草器与预算。相对沿目标已验证前缀同步起草的常规推测解码，该机制不再为候选准备多分支延续，也不再等待目标反馈即可推进，从而把起草与验证映射到异构处理器上并发执行。在4款手机688个语音识别窗口的手机代价重放中，合并吞吐相对仅目标解码提升42%至76%，慢于仅目标的电话/窗口对仅占5.7%，而标准推测解码与SpecASR分别为58.1%与63.0%。该增益依赖候选及时到达并覆盖足够目标输出，开放式推理与长时预填充主导场景尚未验证，达到所评估起草器/预算目录下事后逐窗口预言机合并吞吐的97.33%至98.20%。原文未披露训练成本，推理与部署成本仅以校准代价与能耗个例给出。
🔗 开源与复现资源
本次未形成可展示的已核验资源记录，开放状态尚未核实。
可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
输入已经在手机里，为什么回答还是慢？
这篇论文研究的不是如何听懂声音，而是声音已经到手机之后如何更快给出完整文字回答。输入是此前收到的音频流与用户到达时给出的指令，目标是在保持目标模型贪心输出不变的前提下缩短请求到完整回答的时间。必须保留的信息包括固定音频视图、指令组装方式、初始解码状态与终止规则，输出是与纯目标逐词解码一致的词序列。
按需场景把音频预填放在请求之前，可复用的目标语言模型键值在请求到达前准备好，请求时只需处理指令后缀并进入解码。于是瓶颈从音频编码转移到自回归解码：回复越长，需要的顺序目标步骤越多。手机内存要同时容纳权重、保留的音频状态与运行时缓冲，计算也有限，批量验证省下的目标工作很容易被串行起草吃掉。
初学者容易把加速理解为换一个更小的模型直接回答，论文的约束恰好相反：回答必须与大目标模型的贪心结果一致，小模型只提供候选，提交权仍在目标。另一个常见误解是接受率越高一定越快，论文后文用问答任务反驳了这一点：接受率高但覆盖目标输出的比例低、到达不及时，仍然省不下多少顺序步骤。
同输入同目标的已有路线差在哪里？
在同为按需音频理解的路线上，已有系统把连续音频与查询解耦并保留模型上下文，但完整回复的顺序解码仍留在响应路径上，本文方法是补上解码这一段的加速。在同为语音候选加目标验证的路线上，适应性草稿长度、草稿回收与稀疏树等做法仍然在验证后让起草者从已验证文本重新生成，本文不同在于生产者不再同步到目标前缀更新。
在异步投机路线上，已有方法通过并行目标实例或为预测的验证结果准备延续来重叠起草与验证，但它们仍依赖已验证或假设的目标文本前缀。本文的音频生产者直接从请求音频与指令出发，不为各种假设的纠正结果准备分支。在移动执行路线上，已有工作处理模型加载流水、树生成与验证、频率控制或定制架构回滚，本文则把验证放在最适合它的处理器上，让音频生产者在可用处理器上并发推进，并用实测并发代价来约束预算选择。
请求、音频视图与计时边界如何固定？
论文把 1 次请求写成固定输入与固定协议。请求在到达时刻带来指令，协议从已到达音频中选出该请求可见的音频视图，参考输入在整个生成过程中不再随后续到达的音频扩展。生产者与目标都不能用请求之后的新音频，比较不同解码方案时也不改变参考上下文去迁就更快实现。初始状态来自兼容的音频键值与指令处理，每个回答都从该状态开始，而不是悄悄复用上一个回答的生成文本。
计时起点决定结论含义。请求延迟从规定请求时刻算起，包括请求处理、残余预填、生产者启动、排队、验证纠正与对齐。语料评测常用的提交词数除以后预填时间只隔离解码代价，不复现请求时钟，也不证明增长的音频键值缓存一定能在手机上保持就绪。内存记账包括常驻模型、保留音频键值与位置状态、来源与候选缓冲及临时分配，有限容量限制了无需驱逐即可服务的音频历史。
按需音频理解 × 后台音频预填： 后台音频预填负责在请求到达前把音频编码为可复用的目标语言模型键值，按需音频理解负责在请求到达后根据固定音频视图与指令生成完整转写翻译或问答，二者搭配的原因是预填把音频处理移出请求关键路径但自回归解码仍留在路径上，组合意义是评测必须区分预填已完成后的解码吞吐与包含残余预填的请求延迟。
下面示意图把上述时间关系画成四块：请求前的后台预填、请求后的指令预填与完整回答、回复越长步骤越多的直观含义、串行投机为何省不下时间，以及本文让目标不等起草的改法。解码时间线都是示意，从请求之后开始。
看图路径： 1. 先看左下面板的时间轴，确认请求前后分别是后台预填与解码；2. 再看右上与右中面板，对比逐词等待与串行起草加验证的顺序；3. 最后看右下面板，确认目标单步与验证块如何与起草块重叠
论文图 1。原论文 Figure 1:：“As2d overlaps drafting and verification for on-demand audio understanding.”。
这张图的关键不是具体毫秒数，而是依赖关系的变化。右中面板的起草块挡在验证块前面，右下面板的起草块与目标块并排推进，虚线只在目标边界处提供已就绪候选。目标在无可用候选时走目标单步，有候选时做批量验证，提交的词始终由目标决定。理解这一点后，才能进入方法全景而不把并发误读为放松正确性。
As2d 的全景：谁生产、谁决定、谁只调预算？
As2d 的全景分成三部分。左边是目标解耦起草，把固定音频与指令映射为候选词并按序发布到缓冲；中间是验证与对齐，用保留的目标键值与指令处理请求，在已提交前缀下检查已就绪块并推进或修复缓冲游标；右边是设备画像配置，用手机实测代价与开发集轨迹在部署前选定固定预算。请求时没有按请求的配置推理，预算在整个部署中保持固定。本文方法是音频推测解码 Audio Speculative Decoding，名称中只有一个推测含义，生产者独立推进而目标保留验证纠正。
执行时目标始终沿权威轨迹前进：有可用候选就验证，无可用候选就自己单步解码，不等待生产者。生产者沿自己的生成历史前进，不读目标文本更新与目标键值。目标反馈只决定哪些候选被提交，不决定生产者何时能推进。这就是论文反复强调的解除验证器到起草者同步依赖。
目标解耦起草 × 验证与对齐： 目标解耦起草负责只读固定音频与指令以及自身已生成文本来持续产生候选，不读取目标最新已提交文本与目标键值，验证与对齐负责在目标已提交前缀下检查已发布候选并提交匹配前缀或纠正分歧，二者搭配的理由是音频本身已携带未来输出信息因而起草不必等待验证，组合意义是起草与验证可以并发推进而提交权仍保留在目标一侧。
系统框图把数据、缓冲更新与已提交词的流向分开画，预算选择只通过虚线影响验证边界。阅读时不要把右侧预算当成在线控制器，它是离线选好的上限，真正进入验证的宽度还受就绪度、置信停止与剩余输出预算约束。
看图路径： 1. 从左框请求输入出发，跟踪候选如何进入中间框的验证；2. 确认右框设备画像与预算选择只在部署前作用于配置
论文图 2。原论文 Figure 2:：“As2d decouples candidate generation from target verification.”。
从输入到输出走一遍：请求给出固定音频视图与指令，生产者开始生成并陆续发布 8 个词元一批的候选，目标处理指令后缀得到初始解码状态，然后在每个边界取已发布快照做验证，提交连续匹配前缀并在分歧处给出目标自己的纠正，随后对齐步骤决定下一块可用候选，生产者全程不重启。没有可用延续时目标独自推进，之后仍可通过重新对齐复用后来到达的候选。
生产者如何不等目标也能往前写？
动机来自两个实测。一是在同一段音频窗口上，原生串行投机解码的起草占解码时间的 49.4% 到 75.1%，说明串行起草是主要可隐藏代价。二是在受控语音识别探针中，去掉前文参考转写上下文后，480 个配对块中有 72.3% 的块接受率不变，中位变化为零，说明音频本身已携带足够信息让起草者往前走。教学例子：这好比听写员听到完整录音后可以先自己往下写，不必每写一句都等主审改完上一句，但最终交卷以主审确认为准，此处例子不涉及具体数值。
实现上，固定起草者在指令已知后被调度，读取同一可用波形并按自身前缀自回归生成，经目标词表转换后发布。已发布批次不可更改，新批次只追加，验证读取不可变快照，消费游标独立于来源生成推进。目标纠正不会改写生产者文本，也不会重置其模型状态。
串行投机解码 × 目标解耦重叠： 串行投机解码负责每轮先让起草者追赶目标最新前缀再做批量验证，目标解耦重叠负责让起草者在目标验证已发布候选的同时继续向前生成，二者搭配的比较意义在于手机上串行起草可占解码时间近一半以上，组合后新增作用是把起草工作隐藏在验证背后而不是消除验证本身。
候选发布、验证纠正与复用的最小过程如下图所示，图中词与批量长度仅为示意。先只有已发布部分可被检查，目标接受其中匹配前缀并纠正分歧词，然后下一个目标词若在缓冲中找到匹配，就作为根去验证后续已就绪延续，每个复用词都要在当前目标前缀下重新验证。
看图路径： 1. 在左面板确认只有已发布快照进入验证，生成中部分不进入；2. 在中面板跟踪接受与纠正后提交序列的变化；3. 在右面板观察游标如何移到匹配处并复用后续候选
论文图 4。原论文 Figure 4:：“As2d publishes, verifies, and reuses partial drafts.”。
这张图要对照文字理解三件事：验证看到的是快照而不是未来生成，纠正后生产者序列保持原样，对齐只移动读取位置。重复词锚点可能选到不合适的后缀从而增加验证工作，这是论文明确保留的代价，不是实现失误。
验证、纠正与对齐如何保证输出不变？
目标验证在已提交前缀下检查至多预算个已就绪候选，采用标准贪心投机验证。只提交连续匹配目标贪心词的候选，在分歧处给出目标自己的纠正，移除被拒绝缓存条目并按与参考执行相同的状态约定处理纠正。若无兼容候选就绪，目标做单步推进。已知目标根可以带入下 1 次验证，完全接受不需要无条件多做 1 次单步前向。
对齐采用局部延续匹配。若纠正后下一个目标词等于失配位置候选，则该位置仍可用，相当于允许目标插入而不丢弃有用后缀；否则在有界范围内依次寻找下一个目标词、纠正词及其后续延续。找不到匹配就让目标独自继续，已耗尽记录被丢弃，来源顺序与出处保留。所有复用词都要在实际当前前缀下重新验证，旧目标键值不会贴到回收后缀上。
有序发布与缓冲 × 候选对齐： 有序发布与缓冲负责把生产者按 8 个词元一批追加的不可变候选按请求与来源顺序暴露给目标，候选对齐负责在拒绝后移动读取游标去寻找下一个可用延续而不改写生产者文本与模型状态，二者搭配的原因是目标纠正不能打断正在进行的生成，组合意义是部分草稿可以在纠正后被复用并再次接受目标验证。
正确性条件要求三点同时成立：批量目标执行在候选链每个位置上与顺序执行产生相同贪心决策与可保留状态；提交与修复只保留已提交前缀状态并移除拒绝条目；回收只改变候选游标而不改变已发布词、已提交词与目标状态。在这些后端与协议条件下，任意来源提议、预算与回收都不改变每个已提交前缀处的目标词与状态。
上式是按需执行的输出等价要求：固定请求与协议下，本文方法的完整输出等于贪心目标参考。论文强调这是 1 个条件命题，需要路径等价与已接受前缀状态恢复都经过验证，原生跨后端的有限精度差异仍可能改变近似并列词的排序。
\[Y_{\textsc{As}\textsuperscript{2}\textsc{d}}(z_{u};\mathcal{S})=Y_{T}(z_{u};\mathcal{S})\]上式是执行时间分解：总时间等于生产者服务时间加验证服务时间减去重叠再加残余。由此可得严格加速恰好发生在重叠大于各项增量之和时，增量可能为负，例如更便宜的解耦生产者本身就减少生产者时间。
\[T_{r}=D_{r}+V_{r}-O_{r}+H_{r}.\]上式把加速条件写成不等式。重叠上界不超过两者最小值，请求时来源准备、启动、排空与候选就绪都会减少可实现重叠。当验证已持续被供给时，更快的起草 alone 不降低验证服务需求，进一步增益必须减少验证工作、暴露的启动排空或残余时间。
\[T_{a}<T_{s}\quad\Longleftrightarrow\quad O_{a}>\Delta D+\Delta V+\Delta H.\]预算为什么按手机固定而不按请求调整？
批量验证的每词代价不是光滑下降的。论文在两台手机上对同一语音识别目标做宽度扫描，发现从某个宽度到下一个宽度时每位置节省可能明显回落，且回落幅度在不同手机上不同。这说明不能把一台手机的结论搬到另一台，也不能只看验证器节省就推断整请求增益，因为起草、排队与并发减速都在总时间内。
设备画像配置 × 提议预算： 设备画像配置负责在每台手机与后端上实测不同验证宽度的每位置代价与并发减速，提议预算负责在部署前用开发集音频选定固定上限并在运行时只取已就绪候选，二者搭配的原因是批量并非越宽越省且不同手机惩罚不同，组合意义是用固定预算避免请求时推理配置，同时保留就绪度对实际宽度的约束。
做法是先做设备代价画像，再结合开发集音频离线选预算。部署比较中三台手机固定使用同一语音起草者与预算 7，低端机使用预算 3，物理验证宽度为预算加一。选择过程不使用测试结果，运行时也不做特征提取或推理来换配置。候选就绪仍可减小实际验证宽度，置信停止、配置上限与剩余输出预算共同决定每边界的实际链长。论文明确指出，较大宽度的并发代价部分来自拟合比例而非对每个来源宽度组合的直接测量，相关灵敏度范围只是代价模型敏感性，不是统计置信区间。
没有训练阶段时，实际计算是什么？
本研究没有训练新的语音或语言模型，也没有为基线做特定训练，所有起草者与目标都是调用已有预训练模型。真实计算发生在三处：手机端常驻推理，包括音频前端、来源生成与发布、目标验证纠正与对齐；服务器端为回放准备操作轨迹，包括前缀条件起草轨迹与目标路径排序；离线预算选择中的宽度扫描与开发集筛选。论文未报告梯度路径、参数更新与重置时机，解读时应明确记为缺项而不从模型名称推定实现。
无训练不等于确定性求解。冻结参数只说明部署配置固定，不保证跨后端输出按位一致，论文附录保留了原生校验中出现的逗号增减与少量不匹配回合。同样，固定预算只说明不做请求时学习，不说明该预算在所有负载与温度下最优，变化的工作分布与竞争应用可能改变适用配置，重新画像与重选配置是明确留给未来的工作。
在什么手机、数据与计时下比较？
实现基于安卓端推理框架，语音识别比较常驻中央处理器上的 0.6B 音频起草者与图形处理器上的 1.7B 目标，翻译与问答比较共用词表的 7B 目标与 3B 起草者。评测覆盖四台手机、7 个数据集与 3 种任务，语料评测共 928 个请求，去重后 913 段音频，总计约 12.2 小时与 97953 个目标输出词。语音识别用 688 个完整音频测试窗口与每机 94511 个目标词，所有方法用相同窗口与目标参考，包括达到生成上限的输出。
基线包括纯目标逐词解码、标准投机解码与自适应单序列加回收的移植版本。标准投机解码在主表中对固定物理宽度 5 到 8 取吞吐平均，分布曲线在每窗口内平均，表格则是先按宽度合并词与时间再平均，两者聚合顺序不同，不必强求一致。指标是提交词数除以耗时，语音识别主比较用手机代价回放，原生按需请求用设备时钟。回放与原生在匹配定时检查中平均接近，但回放用服务器生成轨迹，定时验证才用手机生成轨迹并固定相同词序列以隔离计时误差。
资源状态是正文开源声明的唯一依据，本次未发现来源绑定且完成超文本传输安全协议状态验证的资源，因此不得声称代码模型或数据已公开。复现应以论文附录的模型与设备配置、数据集选择、开发划分与校准流程为准，而不是假设存在可下载运行包。
四台手机上的吞吐分布支持什么判断？
研究问题是解码吞吐是否在不同手机、模型与音频任务上一致提升。比较条件是相同 688 窗口、相同目标参考与各自手机的单独校准代价，指标方向是每秒提交词数越高越好，分布曲线越靠右越好。论文报告合并语音识别吞吐相对纯目标提高 42% 到 76%，同时给出回放与原生匹配检查的平均绝对误差约 5% 到 8%，说明回放是代价替代估计而不是原生墙钟的逐窗复刻。
逐个手机面板比较 4 条曲线左右位置，右为更高吞吐，注意横轴在不同手机上刻度不同，不跨面板直接比绝对值。纯目标曲线近乎垂直是因为校准模型对每次目标前向收取同一均值代价，而不是原生逐窗墙钟的实测分布。
看图路径： 1. 逐个手机面板比较四条曲线左右位置，右为更高吞吐；2. 注意横轴在不同手机上刻度不同，不跨面板直接比绝对值
论文图 5。原论文 Figure 5:：“As2d improves decoding throughput across four phones.”。
从像素可见四块面板都包含相同窗口集合但横轴刻度不同，解读时只能在同一手机内比较左右位置，不能跨手机比较绝对吞吐。曲线未做平滑，标准投机解码在每窗口内平均 4 个固定宽度，自适应基线用串行移植版本。
代表性 workload 的切面进一步给出可复述的对照。在小米 14 手机代价回放下，5 个选中窗口覆盖朗读、多语、方言、歌唱与会议，论文按每数据集增益中位数附近选窗，而不是按最大增益选窗。下表比较问题是同一音频与同一目标词数下，本文方法相对更快串行基线的提升是多少，公平条件是同一手机画像与同一目标参考，指标方向仍是吞吐越高越好。
| Case | Target | SD | ASP | As2d | Gain |
|---|---|---|---|---|---|
| Read | 19.26 | 16.65 | 16.88 | 32.24 | +91.0% |
| Multi. | 19.24 | 15.58 | 16.02 | 32.48 | +102.7% |
| Dialect | 19.37 | 14.19 | 14.61 | 31.34 | +114.6% |
| Singing | 19.31 | 13.13 | 14.44 | 28.94 | +100.4% |
| Meeting | 19.25 | 11.36 | 8.93 | 22.86 | +101.3% |
表后解释需要同时看到收益与代价。5 个切面的增益约为 91.0% 到 114.6%，会议语音相对纯目标的增益较小，文中举例仅 56 个提议被接受而验证轮数仍多，说明候选覆盖不足时验证与纠正仍决定有用进展。同一朗读输入在不同手机上表现不同，串行投机在一台上有帮助而在另一台上变慢，这支持按设备画像配置而不支持把单机结论推广到所有手机。所有总体统计保留全部窗口，包括短输出与截断输出，没有为分布尾部做删除。
更快是否以更多退化窗口为代价？
合并吞吐提高可能掩盖频繁退化，因此论文另设窗口频率检查。比较问题是每窗口吞吐相对同手机同音频的纯目标是更快还是更慢，公平条件是每窗口等权且截断输出仍计入分母，指标方向是更慢窗口比例越低越好。下表是原表全部行列的直接呈现，Phone 列在原矩阵中对同一手机的多行采用合并显示，其中 As2d 所在行的 Phone 单元格在矩阵中为空并归属于同组首行的手机型号，4 组依次为 Redmi K70 Pro、Xiaomi 11 Pro、Xiaomi 14、Redmi Note 9 Pro，完整计数同时保留串行基线以避免只看单方法。
| Phone | Method | Faster | Slower | Median loss | Max. loss |
|---|---|---|---|---|---|
| Redmi K70 Pro | Standard SD | 541 | 147 | 9.8% | 62.1% |
| SpecASR | 375 | 313 | 19.2% | 74.3% | |
| As2d | 641 | 47 | 14.2% | 21.9% | |
| Xiaomi 11 Pro | Standard SD | 611 | 77 | 8.3% | 58.5% |
| SpecASR | 553 | 135 | 10.7% | 67.8% | |
| As2d | 657 | 31 | 7.4% | 20.3% | |
| Xiaomi 14 | Standard SD | 0 | 688 | 24.6% | 74.7% |
| SpecASR | 0 | 688 | 26.4% | 79.6% | |
| As2d | 647 | 41 | 6.3% | 10.1% | |
| Redmi Note 9 Pro | Standard SD | 2 | 686 | 16.6% | 73.0% |
| SpecASR | 90 | 598 | 20.7% | 79.3% | |
| As2d | 651 | 37 | 7.2% | 11.3% |
表后判断是本文方法同时改善合并吞吐与获益频率。四机更慢比例分别为 6.8%、4.5%、6.0% 与 5.4%，跨机窗对合并为 5.7%，而标准投机解码与自适应基线分别为 58.1% 与 63.0%。这不是保证每窗必快，原表显示本文方法仍有数十个更慢窗口，但中位损失与最大损失小于串行基线。教学上要区分两种聚合：合并吞吐按词与时间合并，窗口频率按窗口计数，长短窗口在此处权重不同。
固定宽度的对照说明验证器吞吐 alone 不能决定最佳串行宽度。在同一 688 窗口上，更大宽度减少目标调用次数但增加起草前向次数与每轮验证代价，回放的验证总时间几乎不变而起草时间上升，因而更大宽度反而吞吐更低。下表比较问题是在相同手机代价下固定宽度 8 与 12 谁的合并吞吐更高，条件是同一窗口集合与同一目标参考。
| Fixed SD | LibriSpeech | AMI | FLEURS | KeSpeech | M4Singer | All five |
|---|---|---|---|---|---|---|
| Standard SD (K8) | 22.93 | 15.19 | 20.90 | 17.81 | 18.62 | 19.55 |
| Standard SD (K12) | 22.79 | 12.45 | 19.53 | 15.55 | 16.52 | 17.76 |
表后限制是该对照只比较两个固定宽度，不声称其中之一是验证选择的最优。主表的标准投机解码取 4 个宽度的吞吐均值，这是一种配置汇总，不是随机切换策略的吞吐，也不代表验证选出的最佳固定设置。预算选择仍需看净解码收益，而不是来源大小、接受率或调用次数 alone。
与事后每窗最优的距离用缺口衡量，部署配置在四机上达到事后预言合并吞吐的 97.33% 到 98.20%，会议数据留出的空间最大。下表按数据集报告相对事后预言的吞吐缺口百分比，缺口越小越接近在已评测目录内的每窗最优。
| Dataset | K70 | 11 Pro | Mi 14 | Note 9 |
|---|---|---|---|---|
| LibriSpeech | 2.48 | 2.09 | 2.46 | 2.67 |
| AMI | 3.56 | 5.83 | 5.93 | 2.94 |
| FLEURS | 1.33 | 1.46 | 0.65 | 1.31 |
| KeSpeech | 1.56 | 1.81 | 0.93 | 0.71 |
| M4Singer | 2.03 | 2.76 | 1.76 | 1.25 |
表后需要明确预言的含义：它在同一窗口内从已评测起草者与固定上限目录中选一个最优并支付零选择代价，不做窗内动态切换，也不代表全局最优树或调度。小缺口不意味着多数窗口动作相同，多个相近代价的选择可以有相似吞吐。较大宽度的并发代价在部分区间是模型外推，论文用比例极值做了灵敏度重复搜索，缺口范围变化很小，但这仍是代价模型敏感性而不是原生语料最优的证明。
去掉解耦与去掉预算配置各损失多少？
消融按累加方式组织：从自适应基线出发，先加预算配置，再加目标解耦重叠起草，另设保留解耦但恢复原始预算规则的对照。比较条件是同一 688 窗口、同一目标参考与同一后预填时钟，指标仍是合并吞吐。论文报告在保持预算 7 不变时加入解耦，四机分别提高约 41.2%、33.4%、95.2% 与 52.5%，跨机从 8.49 提高到 12.90。加入预算配置的增益较小，在已含解耦时提高约 2.0% 到 15.4%，在串行臂上提高约 17.6%。上述消融数字来自全文连续原句的逐字证据，原宽表以选择模式呈现，此处不再重复制表以避免证据重复计数。
解读必须注意该消融同时改变提议接口与调度，不是接受率不变下的纯重叠效应。两臂都用完整音频并完成初始预填后才计时，生产者条件于音频与自身前缀，不读目标文本与目标键值。较大物理宽度的并发减速在部分手机上用中位比外推，论文对最小与最大比做了预先声明的灵敏度检查，结论方向不变。
翻译与问答的跨任务结果构成反证。有条件接受率在问答上最高而覆盖率最低，多词验证轮比例也最低，相对最快基线的提升仅 8.0%，而两个翻译方向分别提升 17.4% 与 31.2%。这支持论文的条件判断：高接受 alone 不转化为高加速，有效加速需要独立候选及时到达并覆盖足够比例的目标输出，从而用多词验证替代顺序目标步骤。问答子群是按有用目标词数的事后长度筛选，不代表未筛选问答整体增益。
哪些边界没有被证明？
第一是评测边界。语料大范围比较用手机画像回放，翻译与问答回放未单独校准置信度与分支切换代价，问答用了事后长度筛选。原生按需扫描覆盖两台手机各一条 10 分钟音频，每检查点每方法 1 次正式请求，不估计跨轮不确定性。持续流式用带 12 秒上下文重置的 paced 录音，加散热与不加散热还在来源期限与起始温度上不同，不能单独归因于散热。
第二是数值边界。有限精度下改变后端与验证形状可能改变近似并列词排序，论文保留了校准多出的逗号、部分不匹配回合与扫描中的词编辑差异，操作计时仍可用于代价校准，但受影响回合不能声称精确输出保持。回放不能验证部分键值修复，状态等价需要对每个容许配置验证路径等价与已接受前缀状态恢复。
第三是任务边界。开放式推理或对话可能更依赖目标中间决策，独立音频候选的可用覆盖可能下降，并发生产者仍消耗资源。目标在无可用候选时可独自继续，但这不消除资源消耗。前缀条件投机是互补候选来源，是否值得混合需要评估额外覆盖能否抵消前缀同步、投机状态与处理器争用。
复现先固定什么，再测什么？
先固定协议与计时。选定音频视图、提示组装、初始状态、上下文保留与终止规则，明确生产者在请求时刻之后调度且请求作用域候选缓冲从空开始。区分两种时钟：请求延迟从请求时刻算起并包含残余预填，解码吞吐从初始音频与提示预填之后算起并包含暴露的来源工作、验证纠正对齐、排队与生产者收尾。两种时钟的分子分母不同，不能把回放吞吐直接改称为请求延迟。
再固定设备与配置。每台手机单独做宽度扫描与共存校准，只纳入实测可执行宽度，缺失形状不赋零代价。部署前在独立开发集上选定固定起草者与预算，测试结果不进入选择，运行时不做配置推理。核对数据集、模型与基线、实验阶段、指标单位与聚合对象，百分点与相对百分比不能混用，不同指标差值不能放入模型列下。
何时值得尝试是当音频与指令能提供与目标回答保持对齐的候选，且起草代价大到值得隐藏、候选能及时到达并覆盖可观比例输出时。还需补的验证包括目标任务上的候选供给与覆盖测量、所用手机后端的并发代价重测、原生输出一致性检查，以及长时间与多应用竞争下的稳定性。鉴于本次未确认可用资源，不得把代码权重或数据当作已公开去写复现前提。
一句话收束：依赖被移到哪里？
这项工作的技术判断是源条件音频生成可以放松对目标演进文本前缀的依赖，把验证器到起草者的同步依赖移除，但把决定提交的责任完整留给目标。生产者用音频与指令独立推进，目标用已就绪候选做批量验证或独自单步，对齐只移动缓冲游标而不改写生产者。设备画像把预算固定在部署前，避免在线选择。
证据强度分 3 层。直接报告是四机合并吞吐提升、更慢窗口比例下降、原生按需最高约 78% 提升与事后预言缺口很小。有限解释是消融指向解耦是主要增益来源，预算配置是较小增益，以及高接受不高覆盖的问答反例。待验证是跨任务推广、长期流式稳定性与总能耗，单窗能量测量显示 1 次请求能量下降约 30%，但不包括早期音频准备与外部散热，也不代表多请求电池续航。初学者复述时应保留这些条件，而不是只记住吞吐数字。
📎 论文与评分元数据
排名：前50% | 文档类型：方法研究 | arXiv 原文
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
评分规则：type-aware-v1
评分模型：muse-spark-1.3-contributor
评分请求协议：openai_responses