Skip to main content

SGLang-Omni 多阶段运行时

上一章 多模态推理 的结论是：听、想、说这三段计算，各自要的调度规矩是打架的。塞进一个进程，只能取三边都不违反的那套 —— 也就是最保守的。

出路是把它们拆开，各配各的调度。这一章讲拆开之后会遇到什么，以及一个真实的开源实现是怎么解的。

先说清楚拆开的代价。一个请求原本待在一个进程里，拆完之后它的碎片同时散在好几个进程中 —— 下面这张图里每个问号，都是拆开之前根本不存在的问题：

同一个请求，拆开前后拆开前 · 一个进程听 → 想 → 说 全在这里状态就在内存里，出错就抛异常拆开后 · 三个进程，碎片散开进程 A · 听第 17 号在这进程 B · 想第 17 号也在这进程 C · 说刚吐完半句谁都只知道自己这一段于是凭空长出五个问题① 请求跑到哪了没人知道全局② 几 MB 张量怎么跨进程搬③ 还没算完就得往下游送④ 用户打断了谁通知这三个⑤ 中途 OOM算成功还是失败五个问题没有一个跟模型有关，全是拆开之后凭空长出来的。它们分别由本章的 02、04、04、06、06 篇回答。⑤ 尤其麻烦：用户已经听到半句话了，HTTP 响应头早就发出去，这时候没法再改状态码说「失败」。
拆分不是免费的。上面这五项加起来，就是一个多阶段运行时相对单进程服务多出来的全部复杂度 —— 也是这一章八篇的全部内容。

这五个问题没有一个跟模型有关，全是拆开之后凭空长出来的。

SGLang-Omni 是把它们解得最完整的开源实现。它不是「又一个推理引擎」。显存怎么分、批里挑谁、装不下踢谁，这些它直接用 SGLang 现成的。

它管的是编排 —— 流水线长什么样、数据怎么在几个进程之间搬、新模型怎么接进来。

一、五个问题对应哪几篇​

左边是拆开后长出来的问题，右边是本章对应的篇目没人知道请求跑到哪一步了02 流水线与阶段协调器持有全局状态，阶段只收发几 MB 的张量怎么跨进程跨卡搬04 控制面与数据面五种传输，框架按拓扑替你选还没算完就要开始往下游送02 · 04 篇流式边与普通路由并行存在用户打断时谁去通知四个进程06 接一个新模型中止清理的三条竞态路径中途 OOM 了怎么让客户端知道06 接一个新模型错误处理的四条硬规定剩下三篇是横向的：03 讲每一段各配什么调度器，05 讲阶段怎么落到进程和 GPU 上，07 与 08 讲性能怎么调、怎么查。
建议按顺序读 01 到 06，它们是一条递进链；07 和 08 是相对独立的性能工程，随时可以单独看。

二、八篇正文​

#标题讲什么
01SGLang-Omni 总览它做什么、不做什么，五层结构与「认不认识模型」这条判据，一个请求从 HTTP 到波形的完整旅程，四个模型流水线形状的横向对照
02流水线与阶段谁记着请求的全局状态、阶段为什么必须什么都不知道、拓扑怎么用配置声明出来、动态路由为什么被刻意收窄
03三种调度器与模型运行器三种调度器分别接哪一类计算、怎么复用上游调度器而不变成分叉、模型特有代码最后收在哪一层
04控制面与数据面几 MB 的隐状态每秒传几十次，五种传输各自的代价、一次传输的六步、为什么控制消息必须先于传输完成发出
05进程放置与并行第二张卡只用 2% 怎么办、显存预算为什么会算错、阶段融合、同卡数据并行加 MPS 到 1.4～2.1 倍
06接一个新模型要写哪些文件、哪两处必须手工连线、请求边界与张量设备的坑、中止清理的三条竞态、错误处理四条硬规定
07性能瓶颈与优化案例五个真实案例：并发拐点、有状态 CUDA Graph、一步前瞻、把缓存键搬上 GPU、声码器长度分桶，含一组「我们比对照组慢三倍」的诚实数字
08运行时性能排查方法论接手一个「好像不够快」的任务时按什么顺序查、四种测法的两个反向偏差、py-spy 的四个陷阱、哪些数据不可信

三、什么时候不该用它​

这一条放在前面比放在后面有用：

你的场景建议
只服务一个纯文本大模型用 SGLang 或 vLLM 主线，多阶段带来的全是成本
只服务一个「编码器 + 大模型」结构的 VLM 或 ASR同上，单进程装得下
TTS、音乐生成值得用。AR 段和声码器的调度需求根本冲突
Omni 语音对话值得用。多终点、跨阶段流式、分布式中止，单进程接不住
图像视频生成走 SGLang diffusion 那一侧，批处理语义完全不同

判据只有一条：看这个请求里有几种「一步」的定义。只有一种，用主线；有两种以上且调度需求冲突，才需要多阶段。

四、数据出处​

来源用在哪
sglang-omni 的 docs/design/ 与 docs/developer_reference/01 到 06 篇的架构与传输、07 篇的优化案例
sglang-omni 的 docs/_static/image/ 与 docs/design/diagram/全章引用的官方架构图
sglang-omni 的 docs/basic_usage/05 篇的部署实测
sglang-omni issue #179808 篇的排查方法论框架

五、缩写速查​

缩写全称中文一句话
TPTensor Parallelism张量并行一个模型切到多张卡上，每层之后要 all-reduce
DPData Parallelism数据并行跑多个完整副本，各处理各的请求
EPExpert Parallelism专家并行MoE 模型把不同专家分到不同卡
NCCLNVIDIA Collective Communications Library英伟达集合通信库多卡之间做 all-reduce 这类集合操作
ZMQZeroMQ——一个轻量消息库，这里用来走控制面
IPCInter-Process Communication进程间通信CUDA IPC 指跨进程直接共享显存
SHMShared Memory共享内存同机进程之间搬数据的一种方式
RDMARemote Direct Memory Access远程直接内存访问跨机搬数据不经过 CPU
MPSMulti-Process Service多进程服务让多个进程的 kernel 真并发，而不是轮流用卡
LRULeast Recently Used最近最少使用一种缓存淘汰策略
SSEServer-Sent Events服务端推送事件HTTP 上做单向流式下发
ARAutoregressive自回归一步一个，拿自己的输出当下一步输入
CUPTICUDA Profiling Tools InterfaceCUDA 性能采集接口profiler 底层靠它拿 GPU 活动
OOMOut Of Memory显存不足装不下了