如何使用 SGLang-Omni 为语音和多模态模型设置快速推理
任何尝试在生产环境中部署现代语音或多模态模型的人都深知其中的痛点。服务文本 LLM 已有成熟的解决方案：使用 vLLM 或 SGLang，配置好批处理，就能正常运行。但一旦音频进入流水线，一切都乱了套。
语音模型不仅仅是单个 transformer。首先是音频编码器，然后是自回归块（"思考者"），接着是语音生成模块（"说话者"），最后还有一个声码器，将原始音频 token 组装成干净的 48 kHz 音频。每个阶段都有各自的工作负载特征、内存需求和延迟要求。试图将这些塞进标准的文本推理引擎中，必然会导致可怕的延迟和不稳定的音频生成 FPS。
SGLang 团队为这一任务发布了一个专门的解决方案——SGLang-Omni。
什么是 SGLang-Omni
这是一个用于 omni 模型、语音模型和 TTS 模型多阶段推理的运行时。该项目处理最棘手的部分：管理复杂的计算流水线、在各阶段之间传输数据，并提供符合 OpenAI 规范的即用型 API。
主要特点在于多阶段运行时概念。SGLang-Omni 没有试图将整个流水线打包到一个单体进程中，而是将生成过程分离为独立的阶段：
- 输入流的预处理；
- 编码器处理；
- 基于 SGLang 内核的自回归引擎；
- 将最终音频组装在一起的解码器和声码器；
- 结果聚合器。
每个步骤都由各自的调度器提供服务。例如，文本生成或控制 token 生成在 SGLang 的优化调度器上运行，支持 KV-cache，而声码器则在轻量级流式循环中运行，立即将音频块传递给客户端。
无冗余开销的数据传输
当模型被拆分到多个组件时，张量在 GPU 或进程之间的传输往往成为瓶颈。如果通过常规 CPU RAM 路由中间数据，实时对话的延迟将变得无法接受。
在 SGLang-Omni 中，传输层是独立分离的。控制平面同步请求，而数据平面通过优化的后端进行传输：本地进程使用共享内存，分布式操作使用 NCCL、NIXL 和 Mooncake。这将阶段间开销保持在最低水平。
开箱即用支持哪些模型
可用模型的集合令人印象深刻，尤其是考虑到该仓库还在积极开发中。它已经包含了针对流行架构的现成配方（cookbooks）：
- Omni-chat：Qwen3-Omni 和 Ming-Omni。接受多模态输入（文本、音频），输出文本或流式语音。
- 语音合成（TTS）：Higgs Audio v3、MOSS-TT（包括本地 Transformer v1.5 版本，支持原生 48 kHz 音频）、Fish Speech S2-Pro、Qwen3-TTS、Voxtral TTS、dots.tts 和 ZONOS2。
- 音乐生成：MiniMax Music 3，能够根据文本和风格描述组装 32 kHz 立体声音轨。
- 语音识别和说话人分离（ASR）：Qwen3-ASR、Fun-ASR、ARK-ASR 和 MOSS-Transcribe-Diarize，后者可以以
verbose_json格式放置时间戳和说话人标签。
所有这些都通过熟悉的 /v1/audio/speech、/v1/audio/transcriptions 和 /v1/chat/completions 端点进行部署。如果你已经为 OpenAI API 编写了客户端，切换到自己的后端将非常简单。
快速入门和启动
该包可通过 PyPI 获取，最简单的安装方式是使用 uv 或常规 pip：
对于生产环境，该项目有自己的路由器（SGLang-Omni Router）。它处理工作节点健康/就绪检查、多个 GPU 节点之间的负载均衡，以及根据特定实例能力进行请求路由。
至于硬件，NVIDIA CUDA 仍然是主要后端。但开发者已经添加了实验性的 Intel GPU（XPU）支持，通过 PyTorch XPU 实现。Qwen3-ASR、Qwen3-TTS 和 Qwen3-Omni（推理块使用张量并行）已经在 Intel Arc 显卡上运行。
谁现在会发现这个项目有用
如果你正在构建语音助手、实时翻译器、带说话人分离的电话转录服务或内容配音平台，你不再需要用 FastAPI 和原始脚本重复造轮子。
该项目还很年轻，仓库中有数百个 open issues，文档有时会引用源代码。但它有强大的 LMSYS 团队和 SGLang 生态系统作为后盾，因此架构是扎实的。它绝对值得一试，特别是如果你需要在流式对话中获得最小的首音频 token 时间。
相关项目