在单流服务引擎里塞进多码本与双路引导：延迟交织与配对调度的吞吐保卫战

英文题目：An Efficient vLLM-Based Inference Pipeline for Unified Audio Understanding and Generation

会议身份：conference:interspeech:2026:conference-paper-id:wang26w_interspeech

来源为官方会议 PDF；图片依据原页像素，表格数字依据原文引用。PDF 文字层不视为原始 TeX，未可靠恢复的结构不作推断。

会议来源：官方记录 · 官方 PDF

标签：#开源工具 #自回归模型 #统一音频模型 #高效推理 #音频生成

评分：8.5/10 | 创新 1.5/2 | 技术严谨 1.2/1.5 | 实验充分 1.0/1.5 | 清晰度 0.8/1 | 影响力 1.2/1.5 | 开源 1.2/1.5 | 可复现 0.3/0.5 | 工程/实践 1.3/1.5

排名：前25% | 文档类型：系统技术报告

👥 作者与机构

• Haoran Wang：机构信息未能从会议 PDF 纯文本可靠映射
• Jinchuan Tian：机构信息未能从会议 PDF 纯文本可靠映射
• Siddhant Arora：机构信息未能从会议 PDF 纯文本可靠映射
• Shinji Watanabe：机构信息未能从会议 PDF 纯文本可靠映射

📌 核心摘要

统一语音理解与生成要求同一自回归模型输入文本与编码语音并输出文本与多码本音频，而现有高吞吐引擎仅支持单流文本自回归，难以原生处理延迟交织多流采样与条件无条件双路引导。先将每步多码本隐状态与流嵌入输入主辅分解，由一路主码本交由调度器管理并在对数计算内采样缓冲其余辅流，输出单流主词元序列并使其进入下一步模态控制。再将主词元序列输入模态状态机与动态词表掩码，依据输出分布推断模态并注入桥接词元与刷尾补齐，输出完整S×T码本矩阵并送入片上合成。最后将完整矩阵与条件无条件配对请求输入同批前向与片上声学解码器，共享主干前向合并引导对数同步采样并直接合成波形，与朴素双请求独立调度相比以共享前向与前缀缓存复用吸收双路开销而非重复分配显存。在单卡H100评测设置下，Bagpiper（vLLM）的解码吞吐指标为5694.5 tok/s，高于Bagpiper（PyTorch）的解码吞吐指标52.7 tok/s。该结论仅适用于延迟模式残差向量量化架构与单卡大并发压测，尚未验证流式低延迟对话与多卡分布情形。推理部署成本为单张H100显卡持续高并发serving，原文未披露训练成本。

🔗 开源与复现资源

• 代码相关资源：https://github.com/whr-a/vllm/tree/opuslm — 链接可访问（HTTP 200） 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

输入是什么，目标是什么，先保留哪些信息？

这篇解读的输入是论文正文与两张官方原图像素，目标是让刚进入语音与音频方向的研究生能复述出一套可运行的高吞吐推理管线。必须保留的信息包括任务边界、延迟交织的输入输出形态、主辅分解如何欺骗单流调度器、配对协同如何处理无分类器引导、实验用的 3 个模型与硬件并发条件，以及数值正确性与质量指标的对照口径。输出是 1 篇按学习依赖展开的中文技术解读，不做营销式判断，所有数字只讲原文实际报告的值。

语音语言模型要同时做理解与生成。理解侧输入是原始音频或文本加音频，输出是文本，例如音频问答与语音识别；生成侧输入是文本提示，输出是离散声学记号再经声码器变成波形，例如文本转语音与直接语音对话。论文研究的不是训练新模型，而是把已有的延迟交织类语音语言模型装进以文本为中心的高吞吐服务引擎，并在保持输出正确的前提下提升吞吐。

举例来说，一个样本可以是朗读提示加一段待合成文本，模型先输出文本推理，再切换到音频相输出多层码本，最后解码为波形，这个例子只是帮助理解流程，不代表论文报告了该样本的效果。

残差向量量化 × 延迟交织： 残差向量量化负责把每 1 帧连续语音压缩成 S 层离散码本记号，保证高保真重建；延迟交织负责把这 S 层按流错开 i 步排成可自回归训练的扁平序列，二者搭配的原因是前者给出 2 维码本网格，后者给出在 1 维时间步上可 teacher forcing 的顺序，组合意义是训练时可统一建模，推理时却留下多流采样与解交织负担。

连续语音先被神经音频编解码器压缩。白话说，残差向量量化就是把 1 帧声音用多层码本逐层逼近，第一层记大体轮廓，后面层补残差；英文是 Residual Vector Quantization，缩写 RVQ。延迟交织就是把不同层的记号在时间上错开，训练时排成 1 维序列，英文是 delay-pattern interleaving。论文面向的 Bagpiper、OpusLM 与对话版都共享这种结构，只是层数与编解码器不同，后文固定用 S 表示流数，用 T 表示声学帧数。

与文本推理引擎和级联语音管线的关系是什么？

传统做法是级联管线，语音识别加语言模型加语音合成各做一段，优点是每段可独立优化，缺点是延迟累积与韵律信息在文本瓶颈处丢失。端到端语音语言模型把音频也变成离散记号，与文本共用一个自回归主干，从而能直接做语音到语音对话。论文不训练这类模型，而是解决部署侧的结构性缺口。 文本服务引擎的代表是 vLLM 与 SGLang，它们靠连续批处理与自动前缀缓存提升吞吐。白话说，连续批处理就是每个解码步都可进可出，不等整批结束。

分页注意力就是把键值缓存分块管理，英文是 PagedAttention。它们把模型看作对所有活跃请求执行均匀前向的黑盒，天然假设每个请求每步只产生一个记号。

连续批处理 × 分页注意力： 连续批处理负责在单步粒度上动态插入新请求与回收已完成请求，避免静态批的空转；分页注意力负责把键值缓存切成按需分配的非连续块以消除碎片，二者搭配的原因是动态调度需要能随时分配释放显存的底层，组合意义是文本大模型服务能以均匀单记号前向维持高吞吐，但也把模型当成单流黑盒。

已有音频生成框架广泛使用无分类器引导提升保真，但朴素实现把条件与无条件当作两个独立请求，会复制键值缓存并需要跨请求同步对数。已有同步多记号预测与延迟交织训练虽然优雅，但推理需要多流采样与复杂解交织，再加上外部声码器服务，与单步单记号的服务循环直接冲突。论文的定位就是在不重写调度器与显存管理的前提下，把这两处冲突收敛到模型层与对数处理层。

为什么单流循环装不下多层音频生成？

第一个卡点是多层记号的生成与解码。文本每步采样一个词表记号即可，音频每步要在同一隐状态下同时产生 S 个码本记号，且第 i 路在逻辑时间上偏移 i 步。训练时把错位序列展平很方便，推理时却要在每步做多流采样，回填时还要把不同时间位置的嵌入聚合起来，最后把 S 乘 T 矩阵解交织再送声码器。标准引擎只管理单条轨迹，装不下这种内部并行的缓冲与排空。 第二个卡点是无分类器引导的双路开销。

直觉上每步要做 2 次前向，吞吐减半。更麻烦的是调度器假设请求独立，无法原生协调配对的 2 次通过，独立发两个请求会导致调度碎片、双份键值缓存与跨上下文的对数合并同步。若只在外部包一层同步循环，每步都要停下来等两路对齐，连续批处理的优势就被抵消。 第 3 个卡点是混合模态的相位管理。同一回答可能从文本无缝切到音频，结束时还要把延迟缓冲排空。

由于连续批处理把多请求的记号展平成一个序列，不能靠输入位置判断当前模态，必须从模型未掩码输出分布的词表分区归属动态推断，否则文本与音频的词表会互相污染。

整体管线如何把三件事装进同一服务进程？

论文的全景分 3 步。第一步是统一多记号预测服务管线，用主辅分解让引擎以为仍在做单流文本生成，内部却并行采样 S 路并缓存辅路。第二步是端到端融合声学管线，把轻量声学解码器放在同一进程的输出路径，请求完成后直接在卡上解交织并合成波形，不再调用外部声码器服务。第 3 步是配对请求协同调度处理无分类器引导，把条件主请求与空提示伴随请求绑成原子调度单元，同批共享主干前向，仅在音频相合并对数并同步采样结果。 下面先看模型侧的生成形态，再看服务侧如何承接，这是理解后文所有改动的基础。

看图路径： 1. 先从左下音频输入经音频编码器进入蓝色大模型主干，再看文本输入汇入同一主干；2. 再看主干上方黄色 ht 如何加流嵌入后经共享头产生多路对数与记号；3. 最后看右侧延迟模板经解交织进入绿色声学解码器生成音频波形

论文图 1。原论文 Figure 1：“Speech language model architecture.”。

上图展示了统一自回归主干的工作方式。左下音频波形经红色音频编码器与文本输入一起进入蓝色大模型主干，主干既可直接产生文本输出，也可在音频生成时输出隐状态 ht。上方白色大框是码本预测头，每个流把 ht 加上各自可学习流嵌入再经共享矩阵得到对数并采样出记号。右侧小框给出延迟模板的错位示意，经解交织后进入绿色声学解码器得到音频输出。关键是同一词表被划分为文本与 S 个音频子词表，因此混合回答可以在解码中自然切换，这也解释了为什么后文需要相位状态机与词表掩码。

主辅分解与相位状态机如何骗过调度器？

主辅分解的操作是指定一路码本为主记号，完全由引擎的标准管线管理，剩下 S 减 1 路在模型对数计算阶段内部采样并按请求缓存。对引擎可见的仍是每步一个记号，对模型实际是每步 S 个并行头。为避免重复计算，辅路的投影被批量放在一起执行。请求结束时，缓存的矩阵被延迟解交织并送入同卡声学解码器，完成单进程波形合成。 相位管理用每请求的相位状态机加动态词表掩码实现。

系统在文本相只允许文本记号，过渡相注入确定性桥接记号以 conditioning 音频生成，音频相激活全部 S 流，终止音频相后进入排空子相，补发 S 减 1 个填充记号以冲刷延迟缓冲，保证得到完整的 S 乘 T 矩阵。由于不能依赖输入位置，系统用未掩码输出分布的最大值落在哪个词表分区来推断当前模态，这种做法与引擎无关，因此不需要改迭代级调度器。

主辅分解 × 相位状态机： 主辅分解负责把 S 个码本流中的一路当作引擎可见的主记号，其余 S 减 1 路在对数计算内部采样并缓存，使引擎仍以为是单流生成；相位状态机负责用动态词表掩码在文本相、过渡相、音频相与排空子相之间切换，二者搭配的原因是前者骗过调度器，后者保证混合模态输出的起止与补齐正确，组合意义是不改调度器与分页注意力即可支持多记号预测。

下图把服务侧的左右两半放在一起，左半是总体管线，右半是引导的配对调度，需要对照着看数据流与控制流。

看图路径： 1. 先看左侧虚框内调度器到模型再按文本直出或音频经解码器汇合的分支；2. 再看右侧条件主请求与无条件伴随请求如何汇入同一共享前向；3. 最后看合并采样后主记号外露而伴随同步记号回填下一轮的虚线回路

论文图 2。原论文 Figure 2：“Unified serving framework for SpeechLMs.”。

上图左侧从上到下是文本或原始音频进入灰色服务虚框，经调度器到模型后按文本直出或音频经红色解码器再汇合为助手消息，说明连续批处理、主辅生成与在片解码在同一进程内闭环。右侧从上到下是带引导的请求被自动拆分为有条件主路与无条件伴随路，进入同一批的共享前向，再经合并采样得到主记号，虚线把同一记号同步给伴随路以保证下一轮自回归历史完全一致。注意合并只在音频相执行，会绕过模态切换记号，伴随路的外部输出对客户端不可见，下一轮两者仍被强制同批调度。

配对协同如何吸收双路引导的开销？

无分类器引导在每层码本独立做插值，权重 w 大于 1，条件对数与无条件对数按线性组合得到合并对数。论文把公式中符号交代清楚，输入是同一隐状态下两路的前向对数，计算目标是更高保真的音频分布，实现上只在音频相执行，文本推理段不启用，从而把双路成本摊薄到整个端到端序列。原文未给出该公式的梯度路径，因为本研究不训练，只做推理时对数合并。

无分类器引导 × 配对请求协同调度： 无分类器引导负责在每层码本上对条件对数与无条件对数按权重插值以提升音频保真；配对请求协同调度负责把主条件请求与空提示的伴随请求当作原子单元放进同一连续批共享 1 次主干前向再合并对数，二者搭配的原因是朴素双请求会复制键值缓存并需要跨请求同步，组合意义是把双倍计算吸收为批尺寸的边际增量，只在音频相启用合并以免污染模态切换。

具体执行分 4 步。服务端收到引导系数大于 1 的请求时透明生成伴随请求，主路带原始提示，伴随路用空提示。两者作为原子单元被调度，引擎把每步记号预算均分给这 1 对，保证同批。共享前向后得到两组原始对数，按权重合并并采样出唯一主记号。最后把该记号同步追加到伴随请求的历史，使两路下一轮输入完全对齐，伴随输出仍对外隐藏。

论文报告这种设计使系统维持约 80% 非引导吞吐，直接回应了减半直觉。 需要强调的是伴随请求严格复制主序列，因此前缀缓存命中率接近完美，键值缓存增量很小。又因为自回归解码本身受显存带宽限制，伴随路只是让活跃批稍变大，用空闲算力换利用率，延迟与同步惩罚很小。像 Bagpiper 这种先长文本推理后短音频输出的模型，选择性只在短音频相开引导，进一步摊薄了成本。

本研究训练了什么，没有训练什么？

本研究没有训练任何语音语言模型，也没有微调声学解码器。3 个评估模型是直接调用的已有全开源架构，Bagpiper 用 Qwen3-8B 主干加 8 路并行码本，OpusLM 用 OLMo-2-7B 主干加 9 路设置，OpusLM 对话版用 SmolLM2-1.7B 主干并保留同样的 9 路编解码配置。论文未报告参数冻结与否、梯度路径、监督来源与重置时机，因为不存在训练阶段，这些缺项不是遗漏，而是研究类型决定的，读者不应从模型名称推定其训练实现。 真实的计算过程是推理侧的工程构造。

研究者改了 vLLM 的模型层与对数处理层，加入多码本头、流嵌入、相位状态机、主辅缓冲、解交织与在片解码，以及配对请求的自动分配、共享前向、对数合并与记号同步。验证侧用相同输入与随机种子对比连续批处理管线与原始 PyTorch 逐请求管线的记号序列与对数分布，区分单精度与半精度加高效注意力的硬件效应。代码层面声明已公开，但本解读只依据正文证据，不对仓库可运行性做额外断言，资源状态以文末复现节的可用性记录为准。

在什么硬件与并发下测，与谁比？

硬件统一为单张 80 GB 显存的 H100，开启高效注意力，最大序列长度设为 16384。基线是原始 PyTorch 推理管线，逐请求顺序处理，不带连续批处理。对方法是本文的连续批处理管线，支持多流生成与在片解码。标准评估保持 512 并发以打满显卡，引导配置把并发调为 256 以计入内部伴随请求，使活跃工作负载等价，并维持适度队列以保持峰值吞吐。 模型覆盖 3 种设计点，都支持音频理解与生成。

Bagpiper 侧重开放式音频任务并原生支持引导，OpusLM 侧重识别与合成，对话版侧重口语对话质量。理解用 MMAU-mini 准确率与 LibriSpeech 干净测试集词错率，生成用 LibriSpeech 词错率与 Eval2000 上的 UTMOS，方向是准确率与 UTMOS 越高越好，词错率越低越好。数值正确性用 Bagpiper 在 MMAU-mini 上对比记号序列与对数分布，均方根误差越小越好。 并发与序列长度的选择理由是原文明确要饱和显卡并维持稳定队列。512 与 256 的对应关系不是随意减半，而是为了让含伴随请求的引导负载与非引导负载在活跃请求数上可比。

所有吞吐还附带模型浮点利用率，以剔除模型大小不同带来的绝对速度差异。

吞吐与硬件利用率提升了多少，代价是什么？

要回答的核心比较问题是，在同一单卡与同一最大长度下，连续批处理管线相对顺序 PyTorch 基线能否把多流生成批量化，以及硬件利用率是否同步提升。公平条件是同卡同注意力同长度，指标方向是解码记号率与利用率越高越好。论文报告连续批处理把记号处理速度提升约两个数量级，硬件利用率从远低于 0.1 个百分点提升到 Bagpiper 与 OpusLM 接近 10%，而 1.7B 对话模型记号最高但利用率只有 3% 量级。

下表把原文 prose 中实际出现的利用率与加速数字整理在一起，主要收益是批量化多流生成把显卡从严重空闲推到接近 10% 利用并带来上 100 倍加速，具体代价是小模型因算术强度低先触及显存带宽墙，绝对速度最高但利用率反而更低，未胜出项是紧凑模型的利用率明显落后于两个 7B 到 8B 模型，这说明总体趋势不等于每种规模都同等受益，实际延迟还需结合输出帧率另行测量。

模型浮点利用率 × 解码吞吐： 模型浮点利用率负责度量实际浮点运算占峰值的比例以标准化硬件利用；解码吞吐负责度量每秒生成的记号数以反映服务能力，二者搭配的原因是只看记号数会被模型大小与算术强度迷惑，组合意义是能区分计算受限与显存带宽受限，例如 1.7B 对话模型记号最高但利用率反而更低。

复述时要注意百分点与相对百分比不同，9.95% 与 0.1% 以下的差是百分点差，108×是相对倍数，不能混算。数值相同也不是同一指标的证据，解码记号率与利用率必须分开讨论，总体加速不代表每一步都加速。

数值漂移从哪一步开始，质量是否还保得住？

要回答的第二个问题是服务优化是否引入数值错误，以及半精度高效注意力的漂移是否传导到端到端质量。与谁比是同一输入同一种子下的参考 PyTorch 实现，条件是否一致是单精度与半精度两档分别对比，指标是记号序列是否一致与对数均方根误差。

上表整理自原文连续句中的误差数字，主要结论是单精度下两实现记号严格一致且平均误差仅 0.008，证明多流采样与相位控制没有引入逻辑错误；切到半精度高效注意力后约 34 步出现失配且平均误差升至 0.163，原文明确归因为精度损失与浮点非结合律，属于预期的硬件级分歧。

未胜出项是高效配置在实例级必然存在漂移，不能宣称逐记号完全一致。 质量侧用理解与生成指标验证漂移没有破坏聚合性能。Bagpiper 在理解上有轻微波动，生成词错率略有起伏，对话模型的 UTMOS 从 2.85 降到 2.51，原文解释为合成语音的实例级方差与硬件精度偏移所致，强调整体仍维持底层模型的预期表现。限制是论文只报告聚合指标，未测量误判率分布与每步延迟，读者不应把聚合保真等同于每个样本都更好。

引导开销为何没有减半，哪些条件在起作用？

第 3 个问题是双路引导的真实成本。测的是 Bagpiper 在 LibriSpeech 合成任务上的预填充与解码吞吐及利用率，对比不带引导与带引导两档，并发分别为 512 与 256 以对齐活跃负载。论文报告协同调度维持超过 80% 基线吞吐，机制有 3 条，伴随请求复制主序列带来近乎完美的前缀缓存命中，自回归解码受带宽限制使伴随路只是边际增大批尺寸，以及只在短音频相启用引导把成本摊薄到长文本推理上。

支持该判断的细节是引导后利用率反而更高，因为空闲算力被有效利用，而延迟与同步惩罚很小。适用条件很关键，文本推理越长而音频越短，摊薄效果越明显；若全程都是音频且引导权重很大，80% 的数字可能不再成立，原文未评测这种边界。另一个未评测边界是跨请求干扰，当队列中混入大量文本与引导音频请求时，原子配对是否会阻塞普通请求，论文只说支持并发预填充与解码，未给出细粒度排队延迟。

复述时不要把 80% 记成精确值，摘要与正文分别表述为维持 80% 与超过 80%，应保留原文的约数语气。百分点与相对保留的换算也不能自创，原文没有给出引导前后的绝对记号率差值，只给出去向性结论与 3 条机制解释。

还有哪些没测到与不能承诺的事？

论文直接报告的是吞吐、利用率、数值误差与聚合质量，有限解释是小模型利用率低源于算术强度不足与带宽墙，以及半精度漂移源于非结合浮点运算。未验证的推测不应写成结论，例如不能承诺输出帧率与端到端对话延迟同比例改善，因为训练资源、推理开销、输出帧率与实际延迟是四件不同的事，原文只测了前两者。 缺失证据不是技术错误，但必须点名。

原文未报告不同引导权重下的质量与速度曲线，未报告长音频与多轮对话下的尾延迟，未报告多卡与更大并发下的扩展性，也未报告自动指标之外的人评。相关性不等于因果，前缀缓存命中高与吞吐保持相关，但不能单独证明就是 80% 的原因，3 条机制是联合起作用。 另一个特有误解是把无训练等同于确定性求解。即使参数冻结，半精度与高效注意力的非确定性仍会带来实例级差异，单精度一致不代表线上半精度一致。

同样，不能从冻结参数推定系统输出确定，采样、同步时机与队列交织都会引入变化，复现时应固定种子、精度与注意力实现再对比。

要复现应先做什么，需要补哪项验证？

何时值得尝试是当你已有延迟交织类语音语言模型，且瓶颈在多流采样、外部声码器往返与引导双路开销，而不是模型本身质量不足时。若只是单请求离线合成，顺序 PyTorch 已够用，不必引入连续批处理。 复现先做三件事。第一，按原文条件准备单卡 H100 环境，固定最大长度 16384，标准 512 并发与引导 256 并发分别压测，记录解码记号率与利用率。

第二，用 Bagpiper 在 MMAU-mini 上以相同输入与种子对比单精度下的记号序列与对数分布，先拿到 0.008 量级的平均误差与严格一致，再切半精度高效注意力观察约 34 步附近的漂移。第三，打开引导只在音频相的开关，对比文本相误触引导时的相位错误，以验证绕过模态切换记号的必要性。

代码方面，资源状态是正文开源声明的唯一依据，本次收到的资源记录显示类型为代码且当前可用，状态码为 200，地址指向分支路径，复现时应以该地址的实际可达版本为准，不把代码可用等同于权重可下载或系统开箱可运行。还需补的验证是长音频尾延迟、不同引导权重的质量曲线，以及混合文本与引导音频并发时的排队公平性，这些在原文中未充分展开。

一句话收束：拿走了什么，留下了什么？

拿走的是文本单流引擎装不下语音生成的 3 个障碍，主辅分解让调度器无感，片上解码省掉外部服务，配对协同把双路引导吸收为批增量。留下的是可核对的数字锚点，约两个数量级加速、接近 10% 的利用率、单精度严格一致、半精度约 34 步后漂移但聚合质量维持，以及引导下约 80% 吞吐。 对初学者而言，复述顺序应是样本先行，先沿一个文本加音频样本走完输入到表示到组件到目标再到输出，再展开插值与调度的细节，指代保持唯一，前置概念先于依赖它的结论。

比喻只在有帮助时使用，例如把主辅分解说成台前 1 人报幕而幕后多声部齐唱，随后必须对应到主记号可见而辅路缓存的真实机制，不把比喻当证明。 最终判断是工程型贡献，改动 confined 在模型与对数处理层，可移植到同类延迟交织架构。是否采用取决于你的负载形态，长文本短音频加引导的场景最受益，全程高权重引导或极小模型的场景需另测延迟与利用率后再定。

⚖️ 评分明细

评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。

• 评分规则：type-aware-v1
• 评分模型：muse-spark-1.3-contributor
• 评分请求协议：openai_responses

← 返回 interspeech-2026 论文汇总