VoxServe：面向语音语言模型的流式中心化推理服务系统

统一框架优化SpeechLM流式推理，吞吐量提升10-20倍

前置知识

SpeechLM（语音语言模型）

Speech Language Model是以大型语言模型（LLM）为骨架，结合神经音频编解码模型构建的语音生成系统。典型架构包含三个核心组件：语音编码器将输入音频转换为特征表示，LLM骨架自回归地生成离散音频token，以及音频反标记器（detokenizer）将这些离散token重构为连续波形。代表模型包括CosyVoice 2.0、Orpheus 3B、Step-Audio 2等，广泛应用于TTS（文本转语音）和STS（语音转语音）场景。

本文的核心研究对象就是SpeechLM的服务系统，理解其架构组成和推理流程是理解全文技术方案的基础。

音频token与多码本（multi-codebook）表示

音频token是通过神经音频编解码模型（如向量量化自编码器）将连续语音信号量化得到的离散表示。现代tokenizer普遍采用多码本设计，即一个音频片段映射到多个token，分别捕获语义信息和声学信息。例如DAC使用9个码本、约86 tokens/s的速率，而CosyVoice 2使用单码本、25 tokens/s。不同模型的码本数量和token速率差异很大，这导致了架构异构性。

多码本的架构多样性是本文要解决的核心挑战之一，直接影响调度策略和系统设计。

流式推理（streaming inference）

在语音生成中，流式指的是增量式地生成音频块，而非等待整个序列生成完毕。系统每隔10-50个token就调用一次反标记器重构音频，从而降低用户感知的响应延迟。流式推理要求系统保证：首次音频块快速交付（低TTFA），以及后续音频块在前一块播放完成前及时到达（流式可行性）。

本文的核心优化目标就是流式场景下的TTFA和流式可行性，这是区别于传统文本LLM服务系统的关键指标。

CUDA Graph与推理优化

CUDA Graph是NVIDIA GPU上的优化技术，通过将一系列GPU操作录制为计算图并重复执行，消除内核启动开销。在LLM推理中，CUDA Graph常用于加速前向传播和注意力计算。配合FlashInfer等高效注意力后端，可以显著降低推理延迟。但CUDA Graph要求固定的执行形状，因此需要标准化张量契约来提高捕获命中率。

VoxServe通过CUDA Graph优化LLM前向和反标记器推理的关键路径，是实现高性能的技术手段之一。

vLLM与LLM服务系统

vLLM是当前最流行的开源LLM服务系统，引入了PagedAttention等技术来优化KV缓存管理和请求批处理。类似的系统还包括SGLang、TensorRT-LLM等。这些系统针对文本生成场景做了深度优化，使用TTFT（首token时间）和TPOT（每token时间）作为核心指标。然而，它们不支持语音模型特有的多阶段推理管道和流式音频指标。

理解现有LLM服务系统的能力边界，才能理解VoxServe为何需要设计全新的统一服务框架。

研究动机

当前部署语音语言模型（SpeechLM）面临严重的系统层面挑战。首先，现有服务系统是碎片化的：每个新模型发布时通常附带定制的推理库，这些推理库很少针对多并发请求的流式场景进行优化，且仅支持特定的模型架构，导致架构变更需要巨大的工程成本。常见的变通方案是将现有LLM服务系统与自定义的音频专用引擎组合，但这种方式忽略了系统级优化机会，例如协调LLM和反标记器的推理调度。其次，当骨干LLM不被现有服务系统原生支持时（例如需要多码本预测），这种组合方案就完全不可行。实验数据显示，CosyVoice的基线系统在约0.4 req/s的请求速率下就达到500ms的p90 TTFA，而Orpheus基线在低请求率下p90 TTFA也很高，Step-Audio由于9B的模型体积导致请求速率最低。这些系统缺乏系统级调度和高效的反标记器批处理，导致排队堆积和高TTFA。

本文的目标是本文的具体目标是设计一个统一的SpeechLM服务系统VoxServe，实现三个核心目标：（1）构建单一推理框架支持多样化的SpeechLM架构，使系统级优化能以模型无关的方式工作；（2）将系统级优化与模型细节解耦，使新SpeechLM架构无需重新发明服务相关优化就能获得高效服务；（3）为流式应用场景优化性能，特别是最小化TTFA（Time-To-First-Audio）并严格满足流式可行性约束。具体而言，系统需要在保持与现有实现相当的延迟的同时，实现10-20倍的请求吞吐量提升。

与已有工作不同的是，本文的独特切入角度在于将模型架构抽象与系统级优化解耦。现有工作的根本问题是将推理引擎与特定架构紧耦合，导致每个新模型都需要重新实现批处理、分块反标记、CUDA图等核心优化。VoxServe设计了一个统一的模型执行接口，将推理流程分解为Preprocess、LLM Forward、Sampling、Postprocess四个标准步骤，每个步骤的输入输出都有标准化的张量契约（token IDs、masks、features）。这种抽象使得调度器可以不感知模型内部细节地进行请求调度和批处理，同时每个模型子类独立实现其特定行为。此外，VoxServe专门针对流式指标设计了调度算法，区别于传统文本LLM的TTFT/TPOT指标，利用流式可行性是二值属性这一洞察来动态调整请求优先级。

核心方法

VoxServe的整体设计思路是：首先通过统一的模型接口抽象掉SpeechLM的架构差异，然后在这个抽象之上实现模型无关的系统级优化。系统由两个高层进程组成：接口进程暴露HTTP端点接收用户请求，执行进程包含三个核心模块——调度器（Scheduler）负责请求生命周期编排，工作器（Worker）管理GPU资源并执行推理操作，模型（Model）提供跨架构的统一抽象。直觉上，这类似于操作系统的设计：将硬件差异抽象为统一接口，在接口之上实现调度和资源管理。技术路线是：通过标准化的张量契约（IDs、masks、features）使得不同SpeechLM可以在同一个框架中运行，同时通过流式感知的调度算法和异步推理管道来优化端到端性能。

VoxServe的核心创新点在于将模型架构细节与系统级优化完全解耦，这与现有方法有本质区别。现有系统要么将推理引擎与特定架构紧耦合（每个模型需要独立实现所有服务优化），要么简单组合LLM服务系统与自定义音频引擎（忽略系统级协调优化）。VoxServe的统一模型接口将每个请求的推理分解为四个标准步骤：Preprocess执行LLM前向所需的所有预处理操作；LLM Forward支持多样化的数据表示（token IDs为2D整数张量、features为可选浮点张量、mask为同形布尔张量）；Sampling实现标准采样算法并准备下一轮输入；Postprocess以分块方式运行音频反标记器。关键区别在于：调度器可以在不感知模型内部细节的情况下调度任意步骤并批处理请求，而每个模型子类独立实现其特定行为，两者正交。这种设计首次将批处理、分块反标记、CUDA图等优化统一到单一抽象下，使新模型无需重新发明这些优化。

方法步骤详情

VoxServe的推理流程包含四个标准步骤，每个步骤都有明确的输入输出和操作。第一步Preprocess：执行LLM前向传播前的所有准备工作，包括提示格式化、文本tokenization、分配请求特定元数据的缓冲区，以及对于接受音频输入的模型运行音频编码器推理。元数据包含LLM的输入数据（token IDs、masks、features）和可选的缓存缓冲区。第二步LLM Forward：运行骨干LLM生成下一个token。该接口接受输入token IDs（2D整数张量，跨越时间和码本维度）、masks（同形布尔张量，用于分支操作如分离文本和音频token的嵌入层）和features（可选浮点张量，存储连续输入）。第三步Sampling：将LLM输出的logits转换为token决策，实现温度、top-k、top-p等标准采样算法和可选的重复惩罚，并准备下一轮LM前向的输入。第四步Postprocess：以分块方式运行音频反标记器，将生成的音频token重构为波形块。系统维护反标记器的缓存状态（如KV缓存或因果卷积的激活值），支持批量推理且不使用动态张量形状以兼容CUDA图优化。流式生成时，反标记器按指定间隔（chunk size）调用。

技术新颖性

VoxServe的技术新颖性体现在三个方面。第一，统一模型执行接口的设计：这是首个将多样SpeechLM架构的推理流程标准化为四个步骤的抽象，每个步骤的输入输出都有标准化的张量契约。这使得系统优化（如批处理、CUDA图、分块反标记）可以模型无关地工作，而新模型只需实现Model子类即可获得所有优化。论文实现了对7种不同架构SpeechLM的支持（Chatterbox TTS、CosyVoice 2.0、CSM 1B、GLM-4-Voice、Orpheus 3B、Step-Audio 2、Zonos-v0.1）。第二，针对流式指标的调度算法：传统LLM调度器优化TTFT/TPOT，而VoxServe的调度器区分启动阶段（TTFA关键）和稳态阶段（流式可行性关键），利用流式可行性是二值属性的洞察——对于某些请求，临时延迟推理不会降低服务质量，这个空闲时间可以分配给更紧急的请求。第三，异步推理管道：将LLM前向和反标记器前向调度为独立的GPU任务，与CPU侧采样和控制流重叠执行，减少流水线气泡。

**Figure 1**: Typical workflow of SpeechLM inference

**Figure 2**: SpeechLMs have diversity in how to represent both text and audio data

**Figure 4**: Overview of VOXSERVE architecture

**Figure 5**: Asynchronous pipeline design

实验结果

VoxServe在三个具有官方基线实现的SpeechLM上进行了全面评估，在单块NVIDIA H100 GPU上测量TTFA和流式可行性。核心发现如下：对于CosyVoice 2.0模型，基线系统在约0.4 req/s的请求速率下达到500ms p90 TTFA，而VoxServe在4.0 req/s的请求速率下仍能维持相同的500ms p90 TTFA，实现了10倍的吞吐量提升，且流式可行性保持100%。对于Orpheus 3B模型，VoxServe的p90 TTFA在高达10 req/s时仍低于500ms，但由于其高token速率（86 tokens/s），流式可行性在8.0 req/s后开始下降；即便如此，VoxServe在给定TTFA下的吞吐量仍比基线高出10倍以上。对于Step-Audio 2（9B参数，最大模型），VoxServe同样显著优于基线。消融实验表明，调度算法对TTFA有实质性影响：在固定TTFA目标下，优化调度使服务吞吐量从1.5 req/s提升到3.5 req/s；在固定请求率2.0 req/s下，TTFA降低约2.5倍。异步管道在高请求率下提供额外改进，在4.0 req/s时进一步降低TTFA约15%。数据并行实验显示近线性扩展：DP=4在500ms TTFA约束下支持约16 req/s，是单GPU配置（4 req/s）的4倍。吞吐量导向场景下，VoxServe实现134倍实时生成（基线仅10倍）。

**Figure 6**: Serving performance of VOXSERVE compared against existing systems

**Figure 7**: TTFA comparison across scheduling strategies

**Figure 8**: Multi-GPU serving performance

**Figure 9**: Performance for throughput-oriented scenario

查看结构化数据

任务	指标	本文	基线	提升
CosyVoice 2.0 流式TTS推理	p90 TTFA @ 500ms	4.0 req/s（100%流式可行性）	0.4 req/s（92%流式可行性）	吞吐量提升10倍
Orpheus 3B 流式TTS推理	p90 TTFA @ 500ms	10 req/s（99%流式可行性）	约1 req/s（99%流式可行性）	吞吐量提升10倍以上
Step-Audio 2 流式STS推理	p90 TTFA	显著优于基线	低请求率下即高TTFA	吞吐量显著提升
CosyVoice 数据并行扩展	p90 TTFA @ 500ms	DP=4: 16 req/s	DP=1: 4 req/s	近线性4倍扩展
CosyVoice 吞吐量导向推理	逆实时因子（生成音频总时长/执行延迟）	134倍实时（优化开启）	10倍实时	13.4倍吞吐量提升

局限与改进

本文存在以下局限性。首先，评估仅在单块NVIDIA H100 GPU上进行（除多GPU扩展实验外），未覆盖其他GPU型号（如A100、L40S）或异构硬件环境，实际部署中的硬件兼容性未知。其次，仅评估了3个具有官方基线的模型（CosyVoice 2.0、Orpheus 3B、Step-Audio 2），虽然论文声称支持7个模型，但其余4个模型缺乏基线对比，性能优势的普适性有待验证。第三，流式可行性的评估指标是音频块是否及时到达，但未考虑网络传输延迟和客户端缓冲策略对实际用户体验的影响。第四，论文未提供与vLLM、SGLang等通用LLM服务系统的直接对比，仅与模型特定的官方实现比较，这可能低估了通用系统的潜力。第五，吞吐量导向实验使用1000个并发请求，这种极端并发场景在实际生产中可能不常见。最后，论文未讨论系统在不同音频长度、不同文本内容复杂度下的鲁棒性，评估的输入数据集（LibriTTS、VoiceBench）可能不能代表真实应用场景的多样性。

独立分析的弱点

VoxServe存在几个值得深入分析的弱点。第一，调度算法的启动阶段优先级策略虽然通过有界并发限制防止了稳态请求的饥饿，但论文未详细说明这个有界并发的具体参数设置和调优策略，在不同工作负载下可能需要不同的配置。改进方向是引入自适应的并发控制机制，根据当前系统负载动态调整启动阶段的资源分配比例。第二，异步管道的设计将LLM前向和反标记器前向调度为独立GPU任务，但这两个任务共享同一块GPU的计算资源，在高并发下可能产生资源竞争。改进方向是考虑将反标记器卸载到单独的计算设备（如CPU或小型GPU），实现真正的流水线并行。第三，模型接口的标准化张量契约（IDs、masks、features）虽然支持了多样性，但这种固定接口可能限制了某些新型SpeechLM架构的表达能力，例如未来可能出现的非自回归语音生成模型。改进方向是设计更灵活的接口扩展机制。第四，论文未讨论系统的容错能力，如GPU故障、请求超时等异常情况的处理策略。

未来方向

基于VoxServe的成果，未来研究方向可以从以下几个方面展开。首先，作者提到的分布式推理场景（数据并行和解聚推理）仅做了初步探索，未来可以深入研究异构设备间的负载均衡策略、跨设备的KV缓存共享、以及针对超大模型（如数十B参数的SpeechLM）的张量并行方案。其次，VoxServe的统一抽象为多模态模型服务提供了平台，未来可以将其扩展到视频生成、音乐生成等需要流式输出的场景。第三，当前的调度算法基于启发式规则，未来可以探索基于强化学习的自适应调度策略，根据实时负载和请求特征动态优化TTFA和流式可行性的权衡。第四，论文展示了吞吐量导向场景的灵活性，但仅修改了调度策略；未来可以进一步研究批处理策略、缓存策略在不同应用场景下的最优配置。最后，VoxServe可以作为研究平台，探索SpeechLM的系统-模型协同设计，例如设计对服务系统更友好的模型架构。

复现评估

VoxServe的复现条件相对友好。代码已开源在GitHub（https://github.com/vox-serve/vox-serve），使用Python和PyTorch实现，约20,000行代码。评估数据集LibriTTS和VoiceBench都是公开可用的。主要的复现门槛在于算力要求：评估使用单块NVIDIA H100 GPU，这是当前的高端硬件，普通研究者可能难以获取。不过，论文展示了系统在不同请求率下的性能曲线，可以使用较小的模型（如CSM 1B）在较低端的GPU上进行功能验证。所有支持的模型（7个）都是开源的，可以直接下载使用。论文提供了详细的系统架构图和算法描述，复现的技术路线清晰。建议复现时首先在CosyVoice 2.0模型上验证流式推理流程，因为该模型有最详细的性能对比数据。需要注意的是，CUDA图优化和FlashInfer依赖特定的CUDA版本和GPU架构，在不同硬件环境下的兼容性需要额外调试。

VoxServe：面向语音语言模型的流式中心化推理服务系统 VoxServe: Streaming-Centric Serving System for Speech Language Models