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

- 来源：LMSYS：Blog（Chatbot Arena 团队）
- 发布时间：2026-06-17 00:00
- AIHOT 分数：67
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmqj36zhf06vksl5w4wx2c0eo
- 原文链接：https://www.lmsys.org/blog/2026-06-17-moss-tts-local-v15

## 精选理由

SGLang-Omni 把 MOSS-TTS 的端到端服务拆成三阶段并做了大量底层优化，对想落地实时语音合成的团队是现成的技术方案，技术细节扎实，可以直接照着搭。

## AI 摘要

MOSS-TTS-Local-Transformer-v1.5 是一款开源 TTS 模型，支持 48 kHz 立体声、零样本声音克隆、最长 10 分钟长文本合成、时长控制及 31 种语言。其核心采用 Qwen3-4B 骨干与约 2B 参数的 MOSS-Audio-Tokenizer-v2 音频编解码器，通过 12 个 RVQ 码本运行。SGLang-Omni 以三阶段流水线部署该模型。在 Seed-TTS-Eval 上词错误率 5.10%、语音相似度 69.23%，CV3-Eval 上 WER 7.48%、SIM 61.59%，MiniMax Multilingual 上 WER 6.37%、SIM 75.31%，X Voice 上 WER 20.48%、SIM 63.00%。

## 正文

今天，我们宣布在 SGLang-Omni 上实现对 MOSS-TTS-Local-Transformer-v1.5 的端到端服务，该成果由 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 系列中的第二款旗舰模型。它遵循音频分词器加 LLM 自回归的技术路线，采用了更重的音频编解码器，并包含全局 Transformer 加局部 Transformer 的生成路径。

该模型支持直接 TTS、续说、零样本语音克隆、时长控制、显式停顿标记（例如 `[pause 3.2s]`），以及最长 10 分钟的长文本生成。它覆盖 31 种主要语言，并在约 400 万小时的多语言语音数据上进行了训练。

在音频边界上，MOSS 使用了 MOSS-Audio-Tokenizer-v2，这是一种神经音频分词器，其编码器和解码器合计约 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。

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

基准测试词错误率（越低越好）相似度（越高越好）

Seed-TTS-Eval5.10%69.23%

CV3-Eval7.48%61.59%

MiniMax Multilingual6.37%75.31%

X Voice20.48%63.00%

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

MOSS-TTS-Local-Transformer-v1.5 是在阿里云 PPU-ZW810 集群上以千卡规模训练的。本文重点介绍服务端。

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

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

预处理和参考编码。文本被 token 化，参考音频被加载，参考波形被编码为 RVQ 码。

自回归 TTS 引擎。Qwen3 骨干网络和本地 transformer 生成 [1, 13] 的帧行向量。

流式声码器。生成的 RVQ 行向量由有状态的 MOSS 编解码器解码为波形片段。

每个阶段都有不同的瓶颈。参考编码运行一个大型神经编解码器编码器。自回归生成将正常的骨干网络解码与一个微小但严格顺序的本地码本循环混合在一起。声码器是一个有状态的解码器，必须跨片段保持流式状态。系统必须管理所有这三个阶段，而不让一个阶段的批处理或内存行为损害其他阶段。这正是 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 本地模型、流水线和 API 支持建立三阶段服务路径#728

参考编码批量编码、基于内容寻址的 LRU 缓存和单飞重复数据删除避免对重复使用的说话人进行重复的编解码器编码工作#748, #778, #788

AR 引擎解码状态池、帧级 CUDA Graph 支持和 GPU 原生行哈希将解码状态保持在稳定的 GPU 地址上，并消除每帧的主机端哈希操作#745

AR 引擎帧启动状态池化和异步解码管道减少启动准备开销并修复解码步骤的所有权问题#759, #758

AR 引擎编译后的确定性采样器融合热点采样路径，同时保持每请求的确定性采样#773

声码器有状态流式会话、流槽和合并的块调度实现具有请求隔离的帧级音频流式传输#753

声码器有状态声码器 CUDA Graph加速短流式解码步骤#798

跨阶段显式同地内存预算规划防止编解码器和 AR 内存压力相互干扰#810

参考音频编码

语音克隆通常会在多个提示词中重复使用同一声源。在 MOSS 中，这一点很重要，因为在自回归生成开始之前，参考编码需要运行一个大型编解码器编码器。

SGLang-Omni 将批量参考编码与基于内容寻址的 LRU 缓存相结合。重复的参考依据音频内容而非路径进行键值索引，因此复制或重命名的文件仍能复用相同的编码 RVQ 结果。单次飞行路径会合并针对同一声源的并发缓存未命中，防止冷缓存突发引发重复的编解码器编码。

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

自回归引擎

MOSS 自回归引擎包含两个计算层级：Qwen3 主干网络和局部 Transformer 帧解码循环。SGLang-Omni 使用 CUDA Graphs 捕获这两者，但将它们分开处理，因为它们的结构和所有权不同。

主干网络图使用 SGLang 的标准 CUDA Graph 路径进行因果语言模型解码。MOSS 专用的帧图则捕获局部 Transformer 微循环以处理完整的一帧：停止/继续采样、12 个顺序码本投影、码本反馈，以及用于下一帧的反馈嵌入组装。这消除了一个虽小但高度顺序循环的启动开销。

为了实现图回放，MOSS 将每个请求的解码状态保存在持久的 GPU 端池中。反馈嵌入、采样参数、随机种子、计数器和音频历史记录在帧与帧之间保持稳定的地址。SGLang-Omni 还将生成行的基数哈希移至 GPU，避免了每帧的 CPU 哈希计算和 D2H 同步。

每帧 13 次采样操作使用带种子的 GPU 采样器。我们仅编译此采样路径，而不编译主干网络或局部 Transformer。在 SeedTTS 英文评测中，并发数为 16 时，这种窄范围的编译使吞吐量提升了 12.3%，平均延迟降低了 11.1%，平均 RTF 降低了 10.5%，且未改变更大的模型执行路径。

流式声码器

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

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

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

对于短流式块，加速效果最为显著：

每步帧数即时模式CUDA Graph加速比

466.3 毫秒30.1 毫秒2.20 倍

565.8 毫秒30.7 毫秒2.14 倍

865.6 毫秒34.0 毫秒1.93 倍

1365.4 毫秒40.4 毫秒1.62 倍

2574.8 毫秒58.3 毫秒1.28 倍

100222.9 毫秒215.3 毫秒1.04 倍

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

内存预算管理

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

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

性能

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

模式完成 / 失败吞吐量音频吞吐量平均延迟平均 RTF词错误率

非流式1088 / 05.976 req/s26.303 audio s/s2.669 s0.6441.75%

流式1088 / 02.909 req/s12.804 audio s/s5.474 s1.3222.14%

非流式模式达到 5.976 req/s，平均 RTF 为 0.644。流式模式会增量式地发出音频块；在并发数为 16 时，平均块间间隔为 0.109 秒，每个请求平均发出 8.82 个块。流式吞吐量较低是符合预期的：声码器在更小的块上运行更频繁，并与自回归引擎共享 GPU 时间。

两种模式下的质量指标非常接近：在相同的 CI 运行中，非流式模式的 WER 为 1.75%，流式模式为 2.14%。流式/非流式模式的伪影一致性检查也通过了。

各项独立的优化测量结果不应相加成一个总指标，因为它们是在不同的硬件和并发设置下收集的。这些数据更有价值的地方在于，它们是一张 MOSS 时间消耗的地图：参考缓存消除了冗余的编码器工作，帧 CUDA Graphs 消除了本地循环的启动开销，采样器编译优化了热门的采样路径，声码器 CUDA Graphs 加速了短流式块的生成，内存预算则稳定了共置部署。

路线图

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

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

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

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

更广泛的基准测试覆盖。当前测量主要关注 CI 中的 SeedTTS 英文。我们计划将覆盖范围扩展到中文、多语言评估、长文本生成、多说话人池、不同参考长度以及类似生产环境的流量混合。

加入我们

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

致谢

SGLang-Omni — 邓嘉欣、蔡浩广、蔡尚铭、陈宇浩、邵康祥、金浩、高逸飞、顾靖文、郭志浩、洪晨晨、景新力、柯祥瑞、Estella Liu、陆新宇、Ratish Palanisamy、Mick Qian、田一江、夏子杰、叶雪松、殷悦、张高凯、张晓宇、赵晨阳、张一驰。

MOSS-TTS Local Transformer v1.5 — 龚逸天、陈旷伟、张志诚、江博天、张一扬、余康、高阳、杨晓贵、陈钦源、费兆晔、李世敏、邱锡鹏。

了解更多

模型：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：重新设计多阶段生成模型的推理框架