MOSS-TTS-Local-Transformer-v1.5 在 SGLang-Omni 上：原生流式 48 kHz 语音服务

今天，我们宣布端到端服务MOSS-TTS-Local-Transformer-v1.5在SGLang-Omni上，连同MOSI以及OpenMOSS 团队.

MOSS-TTS-Local-Transformer-v1.5 是一个开源 TTS 模型，支持 48 kHz 立体声语音、零样本声音克隆、长文本合成、多语言生成、时长控制以及原生流式输出。从演示脚本中调用这个模型并不难。难的是把它服务好：一次请求要经过参考音频编码、Qwen3-4B 自回归主干、帧级 12 码本采样循环，以及一个有状态的编解码器解码器。

SGLang-Omni 将 MOSS-TTS-Local-Transformer-v1.5 作为三阶段流水线来提供服务，而不是把它硬塞进单个 LLM 解码循环中。本文的工作主要围绕这一映射展开：各阶段位于何处、哪些部分需要模型特定的钩子，以及模型在负载下运行后暴露出了哪些瓶颈。

MOSS-TTS-Local-Transformer-v1.5 模型

MOSS-TTS-Local-Transformer-v1.5 是 MOSS-TTS v1.5 系列中的第二款旗舰模型。它采用 Audio Tokenizer + LLM 自回归路线，配备更重的音频编解码器，以及 Global Transformer + Local Transformer 的生成路径。

它支持直接 TTS、续写、零样本声音克隆、时长控制、诸如 [pause 3.2s] 这样的显式停顿标记，以及最长 10 分钟的长篇生成。它覆盖 31 种主要语言，并在约 400 万小时的多语言语音数据上训练。

在音频边界上，MOSS 使用 MOSS-Audio-Tokenizer-v2，这是一个神经音频 tokenizer，其编码器与解码器合计约 2B 参数。它以 12.5 Hz 运行，支持 0.125 kbps 至 4 kbps 的可变比特率压缩，可重建 48 kHz 立体声音频，并通过残差向量量化（RVQ）来表示语音。

生成核心使用 Qwen3-4B 主干。全局 Transformer 逐帧推进序列。对于每一帧，一个单层局部 Transformer 先输出停止/继续的决策，然后按顺序采样 12 个 RVQ 码本，并在采样下一个之前将每个已采样的码反馈回去。

服务侧可见的 token 布局是 [T, 13]：一个文本/控制通道和 12 个音频码本通道。文本位置在通道 0 中携带一个文本 token，其余通道中携带音频填充。音频位置在通道 0 中携带一个槽位/控制 token，并从每个音频码本中携带一个 RVQ 码。这是 MOSS 第一次不再像一个普通的下一 token 预测模型：每个生成的帧是一行，而不是一个标量 token。

在公开的模型级评测集上：

这些是离线模型指标。后续的服务基准测试使用了不同的评估流程，应将其理解为端到端系统测量结果。

MOSS-TTS-Local-Transformer-v1.5 在阿里云 PPU-ZW810 集群上以千卡规模完成训练。本文聚焦于服务侧。

为什么 MOSS 需要多阶段服务运行时

标准的 LLM 服务引擎围绕一个重复的模型循环构建。而 MOSS 在一个请求中包含三种不同类型的工作：

• 预处理与参考编码。文本被 tokenize，参考音频被加载，参考波形被编码为 RVQ codes。
• 自回归 TTS 引擎。Qwen3 主干网络与局部 transformer 生成 [1, 13] 帧行。
• 流式声码器。生成的 RVQ 行由有状态的 MOSS codec 解码器解码为波形块。

每个阶段有不同的瓶颈。参考编码运行一个大型神经 codec 编码器。AR 生成将普通的主干网络解码与一个微小但严格串行的局部 codebook 循环混合在一起。声码器是一个有状态的解码器，必须在各个块之间保持流式状态。系统必须管理这三者，同时不让某一阶段的批处理或内存行为损害其他阶段。这正是 SGLang-Omni 所针对的工作负载类型：一个多阶段生成流水线，其中每个阶段根据自身的计算模式进行调度，各阶段通过低开销通道通信，GPU 分配与内存预算由框架管理。

使用 SGLang-Omni 服务 MOSS

详细说明请参见 SGLang-Omni MOSS-TTS-Local cookbook。

安装与服务

docker pull lmsysorg/sglang-omni:dev
docker run -it --gpus all --shm-size 32g --ipc host --network host --privileged \
  lmsysorg/sglang-omni:dev /bin/zsh

git clone git@github.com:sgl-project/sglang-omni.git
cd sglang-omni
uv venv .venv -p 3.12
source .venv/bin/activate
uv pip install -v -e .

hf download OpenMOSS-Team/MOSS-TTS-Local-Transformer-v1.5

sgl-omni serve \
  --model-path OpenMOSS-Team/MOSS-TTS-Local-Transformer-v1.5 \
  --port 8000

SGLang-Omni 将 MOSS-TTS Local Transformer v1.5 作为三阶段流水线提供服务：

preprocessing -> tts_engine -> vocoder

预处理阶段解析 OpenAI 兼容请求，准备多通道提示词，并为声音克隆编码参考音频。tts_engine阶段运行在OmniScheduler上，因此 MOSS 可以复用 SGLang 的请求批处理和 KV-cache 机制，同时携带模型特有的[T, 13]行。声码器阶段以流式方式消费生成的行，并从持久的编解码器流式会话中返回音频块。

被复用的部分是运行时形态：阶段生命周期、调度器接口、阶段间路由、流式输出、进程放置以及阶段级资源核算。MOSS 特有的部分更小也更明确：如何构建多通道提示词、如何运行帧局部码本循环，以及如何将 MOSS 编解码器连接为流式解码器。下一节只聚焦于这些 MOSS 特有的瓶颈与优化。

优化 MOSS 端到端性能

当流水线在功能上完整之后，我们针对性能分析显示存在重复工作或启动开销的阶段进行了优化。

参考音频编码

语音克隆往往会在许多提示词中重复使用相同的说话人。在 MOSS 中，这一点很重要，因为参考编码会在 AR 生成开始之前先运行一个大型编解码器编码器。

SGLang-Omni 将批量参考编码与内容寻址的 LRU 缓存相结合。重复的参考音频以音频内容而非路径作为键，因此即使文件被复制或重命名，仍会复用相同的编码 RVQ 结果。单飞（single-flight）路径会合并针对同一说话人的并发未命中，防止冷缓存突发导致重复启动编解码器编码。

在 2x H100、并发数为 16 的 SeedTTS 英语评测中，将参考缓存容量从 256 条增加到 1024 条，使吞吐量提升了 32.0%，平均延迟降低了 24.3%。内存开销很小，因为编码后的 code 张量很紧凑；更大的缓存主要是防止活跃说话人工作集被驱逐。

AR 引擎

MOSS 的 AR 引擎有两级计算：Qwen3 主干网络和局部 transformer 帧解码循环。SGLang-Omni 用 CUDA Graphs 同时捕获两者，但将它们分开，因为二者的结构和归属不同。

骨干图使用 SGLang 标准的 CUDA Graph 路径进行因果 LM 解码。MOSS 专用的帧图则捕获完整一帧的局部 transformer 微循环：停止/继续采样、12 次顺序 codebook 投影、codebook 反馈，以及为下一帧组装反馈嵌入向量。这消除了一个虽小但高度串行的循环所带来的启动开销。

为使图重放成为可能，MOSS 将每个请求的解码状态保存在一个持久的 GPU 侧池中。反馈嵌入向量、采样参数、随机种子、计数器以及音频历史在各帧之间都位于稳定的地址上。SGLang-Omni 还将生成行的基数哈希移至 GPU，从而避免了每帧的 CPU 哈希计算和 D2H 同步。

每帧的 13 次采样操作使用带种子的 GPU 采样器。我们只编译这条采样路径，而不编译骨干或局部 transformer。这一狭窄的范围在并发数为 16 的 SeedTTS 英文测试上，将吞吐量提升了 12.3%，将平均延迟降低了 11.1%，并将平均 RTF 降低了 10.5%，且未改变更大模型的执行路径。

流式声码器

声码器阶段将生成的 RVQ 帧转换为音频块。由于 MOSS-Audio-Tokenizer-v2 支持有状态流式解码，SGLang-Omni 在声码器执行器内部保持一个持久的编解码器流式会话。

调度器管理流式槽位、一个离线回退槽位、分块阈值以及合并的解码步骤。第一个分块可以使用较小的阈值来缩短首段音频的延迟，而后续分块则使用更大的窗口来提升吞吐量。当多个请求积累了足够多的待处理帧时，调度器会在一次编解码器调用中将它们一起解码。

短流式分块的启动开销较大，因此 SGLang-Omni 通过 CUDA Graphs 捕获常见的声码器帧数。该实现将编解码器状态缓冲区保持在稳定的地址上，并就地更新它们，从而允许在流式步骤之间进行图重放。

短流式分块的加速幅度最大：

当帧数未被捕获或内存紧张时，图路径会回退到 eager decode。该路径覆盖了流式/非流式一致性检查。

内存预算

在默认的 MOSS Local 配置中，预处理、AR 生成和声码器执行可以共置在同一块 GPU 上。这种紧凑布局很方便，但 AR 引擎和编解码器运行时的内存分配模式并不相同。因此，SGLang-Omni 为 AR 引擎提供了显式的共置内存契约，并为编解码器运行时的内存分配和流式状态预留了余量。

在并发数为 8 的单卡共置配置中，显式的编解码器内存预算将吞吐量提升了 8.9%，并将平均 RTF 降低了 8.4%。更重要的是，它让部署行为在内存压力下变得可预测。

性能

我们在包含 1088 个样本的 SeedTTS 英文集上评估了优化后的服务路径。以下结果来自启用声码器 CUDA Graph 后的完整 CI 评估，使用 2x GPU 和客户端并发数 16。ASR 评分使用 Qwen3-ASR-1.7B，说话人相似度使用 WavLM-Large 微调模型。

非流式达到 5.976 req/s，平均 RTF 为 0.644。流式会逐块输出增量音频；在并发数为 16 时，平均块间间隔为 0.109 s，每个请求平均输出 8.82 个音频块。流式吞吐量较低是意料之中的：声码器会更频繁地处理更小的音频块，并与 AR 引擎共享 GPU 时间。

质量指标在各模式间保持接近：在同一次 CI 运行中，非流式为 1.75% WER，流式为 2.14%。流式/非流式产物一致性检查也通过。

各项优化测量结果不应相加成一个总体数字，因为它们是在不同的硬件和并发设置下收集的。它们更有用的地方在于勾勒出 MOSS 的时间花在哪里：引用缓存消除了冗余的编码器工作，帧 CUDA Graph 消除了本地循环的启动开销，采样器编译改善了热点采样路径，声码器 CUDA Graph 加速了短流式块，内存预算则稳定了同机部署。

路线图

当前路径已能端到端运行，但仍有几个部分值得改进：

池原生帧 CUDA Graph。当前的帧解码图使用了持久状态池，但采样参数和生成行周围仍有一些暂存。更原生的池到池图路径可以简化启动/解析边界。

自适应流式调度。流式 TTS 存在真实的延迟与吞吐量权衡。我们正在探索负载感知的块大小、优先级感知的槽位调度，以及更好的合并策略，使低负载请求能快速获得首批音频，而高负载部署能恢复更多吞吐量。

更广泛的编译覆盖范围。 编解码器编码器和 Qwen3 主干网络仍有针对性的编译实验空间。我们会将编译范围保持得足够窄，以避免冷启动回退和输出变化。

更广泛的基准覆盖范围。 目前的测量在 CI 中聚焦于 SeedTTS 英语。我们计划将覆盖范围扩展到中文、多语言评估、长文本生成、多说话人池、不同参考长度以及类生产流量组合。

加入我们

如果你对 TTS、全模态模型、流式推理、CUDA Graphs、调度、通信、模型接入、基准测试或生产服务感兴趣，欢迎贡献和讨论。

致谢

SGLang-Omni - Jiaxin Deng、Haoguang Cai、Shangming Cai、Yuhao Chen、Kangxiang Shao、Hao Jin、Yifei Gao、Jingwen Gu、Zhihao Guo、Chenchen Hong、Xinli Jing、Xiangrui Ke、Estella Liu、Xinyu Lu、Ratish Palanisamy、Mick Qian、Yijiang Tian、Zijie Xia、Xuesong Ye、Yue Yin、Gaokai Zhang、Xiaoyu Zhang、Chenyang Zhao、Yichi Zhang。

MOSS-TTS Local Transformer v1.5 - Yitian Gong、Kuangwei Chen、Zhicheng Zhang、Botian Jiang、Yiyang Zhang、Kang Yu、Yang Gao、Xiaogui Yang、Qinyuan Chen、Zhaoye Fei、Shimin Li、Xipeng Qiu。

了解更多

• 模型： OpenMOSS-Team/MOSS-TTS-Local-Transformer-v1.5
• 服务框架： GitHub 上的 SGLang-Omni
• 文档： SGLang-Omni 文档
• MOSS-TTS-Local 指南： SGLang-Omni 中的 MOSS-TTS-Local
• MOSS 优化路线图： #637
• 设计背景： SGLang-Omni：为多阶段生成模型重新设计推理框架