2023–2026 Omni serving 论文谱系

1. 先看清谱系：七条支流为什么会在 Omni runtime 汇合

2023 年以后，推理系统的主问题先是如何让同一台 GPU 上的 LLM 请求高效共享 KV cache；随后变成如何把 prefill 与 decode 放到不同资源池。多模态输入又在前面增加昂贵的视觉、音频 encoder，生成式 Omni 模型则在后面增加 Talker、codec、vocoder、DiT、VAE。至此，请求不再是单一 transformer 上的两阶段过程，而是带数据依赖、不同批处理轴和不同状态生命周期的执行图。

这条谱系可以读成连续的系统压力传导：

1. LLM serving解决显存碎片、prefix 复用和 token 级组批，是 AR stage 的地基。
2. PD/EPD 解耦把不同计算形态分到独立资源池，建立 stage placement 与跨阶段传输问题。
3. 多模态 cache处理媒体 token、位置变化和长视频历史，扩展了 KV 之外的状态管理。
4. Diffusion serving引入去噪 step、空间 patch、VAE 与多种并行维度，不能套用纯 AR scheduler。
5. streaming video把一次性 prompt 变成持续到达的帧与 iterative prefill。
6. duplex speech把“完成一个请求”改成播放不中断、能插话、能取消的实时会话。
7. graph runtime 与编译器最终尝试用统一执行图描述上述阶段，再自动做放置、通信、组批和优化。

因此，vLLM-Omni 与 SGLang-Omni 的价值不只在“支持更多模型”，而在于把原本分散在 LLM、Diffusion、视频与语音系统中的专用技术装进一个可组合的多阶段 runtime。

2. 论文在优化什么：从 token 吞吐转向 SLO goodput 与播放连续性

普通离线吞吐把所有完成请求视为同质样本；在线服务更关心请求是否在时限内完成。对到达率为 \(\lambda\)、在给定 SLO 内完成的请求数为 \(N_{\mathrm{SLO}}\)、观测窗口为 \(T\) 的实验，可把 SLO goodput 写为：

其中 \(L_i\) 是请求 \(i\) 的实测延迟，\(S_i\) 是该类请求的时限，\(p\) 是论文要求的达标比例。PD/EPD 论文通常分别约束 TTFT 与 TPOT；Diffusion 论文还会约束整图或整段视频的 deadline；语音论文则需要首音频包、real-time factor、buffer underrun 和 barge-in 响应。只比较 requests/s 会遗漏这些交互语义。

多阶段图的端到端延迟也不能简单理解为各阶段孤立均值相加。若关键路径为 \(\mathcal P\)，阶段计算、排队与传输分别是 \(C_s,Q_s,X_{s\rightarrow t}\)，则一个教学性的下界是：

实际系统还会通过流水重叠降低部分可隐藏开销，也会因下游背压、batch 等待和重试高于这个下界。后续论文的差异，正体现在它们优化了公式中的哪一项，以及是否把收益转化为端到端 SLO。

3. LLM serving 地基：PagedAttention 与 RadixAttention

vLLM / PagedAttention（SOSP 2023）把 KV cache 切成固定大小 block，再用类似虚拟内存页表的映射把逻辑序列与物理显存解耦。问题不是 attention 算子本身，而是请求长度未知时连续预留显存会产生内部、外部碎片，并限制可并发序列数。论文在其模型、GPU 和请求分布下，相对 FasterTransformer、Orca 报告 2–4 倍吞吐；这不是所有模型上的普遍倍数。

SGLang / RadixAttention（NeurIPS 2024）进一步把可复用前缀组织为 radix tree，使多轮对话、few-shot 示例和程序化 prompt 可以共享 KV。论文同时评估结构化输出和多模态程序工作负载，在其设置下报告最高 6.4 倍提升。PagedAttention 解决“页如何放”，RadixAttention 解决“哪些前缀值得复用”，两者共同形成 Omni runtime 中 AR Thinker、Talker 或语言 decoder 的基础能力。

但这两项工作都默认主要计算循环仍是 transformer token generation。视觉 encoder 按图片或 patch 组批，DiT 按去噪 step 和空间 token 运行，codec 按音频 chunk 运行；它们的队列、batch key 与状态都不同。因此 Omni runtime 可以复用 vLLM/SGLang 的 AR engine，却不能把整张模型图压成一个 token scheduler。

4. 从 PD 解耦开始：计算形态不同，就不该强迫它们共享一个资源池

DistServe（OSDI 2024）把 compute-bound 的 prefill 与 memory-bandwidth-bound 的 decode 放到不同 GPU 池，联合选择并行方式、replica 数与放置。它以同时满足 TTFT、TPOT 的请求容量为目标，在论文工作负载中报告最多承载 7.4 倍请求，或在超过 90% 达标条件下支持最多 12.6 倍更紧 SLO。关键贡献不是“多开两个进程”，而是让每个阶段按自己的瓶颈独立扩缩，并显式支付 KV 跨池传输。

Splitwise（ISCA 2024）从异构硬件角度做同一拆分：prompt 与 token generation 可以放到不同 GPU 类型，状态通过高速互连传递。论文比较同成本、同功耗等部署方案，在其集群与模型上报告约 1.4 倍吞吐或 20% 成本下降，也给出同成本功耗下 2.35 倍吞吐的配置。它提醒 Omni 系统：stage disaggregation 的收益取决于硬件匹配、传输拓扑和利用率，不是阶段越碎越好。

PD 留给 Omni 的三个核心问题是：谁拥有跨阶段状态，什么时候传，如何避免上游产生速度长期超过下游消费速度。视觉 feature、Talker hidden state、codec token 和 diffusion latent 的体积与生命周期差异很大，KV transfer 只能作为其中一种特例。

5. EPD 与多模态阶段化：encoder 从前处理变成一等公民

EPD / EPDServe（ICML 2025）把 Encode-Prefill-Decode 明确拆成三类服务。它增加多模态 token cache 与传输、单请求内 encoder parallelism、离线资源优化和运行时角色切换。论文在其模型与硬件上报告最高 15 倍 encoder 内存容量、22 倍 batch、10 倍单请求图片数、2.2 倍 KV 容量，并给出 TTFT 最多降低 71%、吞吐提高 57% 的实验结果。这里不同倍率对应不同实验，不能拼成一条通用收益。

ModServe（SoCC 2025）使用六个开放 LMM 与 Azure 生产 trace，比较 decoder-only 和 cross-attention 模型，再通过模态感知调度、autoscaling 与 colocation 组织模块。其 128 GPU 实验在论文设定下报告 3.3–5.5 倍吞吐与 25–41.3% 成本节省。它比 EPD 更强调真实请求中图片数、分辨率和模态混合造成的负载不均。

HydraInfer把 EPD 扩展到异构实例与动态资源重分配；论文以 8 张 H800 和真实负载评估，在 P90 SLO 约束下报告相对 vLLM 最高 4 倍吞吐。ElasticMM则引入 modality group、弹性分区、统一 prefix cache 和非阻塞 encode，在论文多数据集实验中报告 TTFT 最多下降 4.2 倍、SLO 吞吐提高 3.2–4.5 倍。

EPD-Serve把同一抽象落到 Ascend 集群：Encode、Prefill、Decode 独立编排，配合异步 feature prefetch、分层分组 KV 传输和多路由调度。论文在其硬件、模型和并发负载下，以 TTFT 低于 2000 ms、TPOT 低于 50 ms 为约束，相对 PD 解耦基线报告 57.37–69.48% 的吞吐提升。它补上了一个重要系统变量：stage graph 不只要适配模型结构，还要适配芯片互连拓扑与通信原语。

这些工作是 vLLM-Omni stage graph 的直接前史：资源单位从“一个 LLM replica”变成“一个可独立并行、组批和扩缩的 stage”。SGLang-Omni 也采用 per-stage scheduler，但截至核验日应引用其官方代码和文档，不能把 EPD、ModServe 或 SGLang core 的论文写成“SGLang-Omni 论文”。

6. 解耦不等于远程部署：SpaceServe 与 UnifiedServe 的反向证据

物理解耦可以减少阶段干扰，却会增加空闲碎片与跨卡传输。SpaceServe（NeurIPS 2025）选择“逻辑解耦、同卡共置”：用细粒度 SM partition 隔离 encoder 与 decoder，并以成本模型和 encoder 调度控制干扰。论文在 A100 实验中报告平均 4.81 倍、最高 28.9 倍的 TPOT 改善；这个数字针对论文的基线与负载，不能解读为同卡总优于分离部署。

UnifiedServe同样强调 GPU 内调度与资源共享，并用 FlashCodec 并行化多 GPU 视频解码。它在论文视频 MLLM 工作负载中报告最多服务 3 倍请求、支持 1.5 倍更紧 SLO，以及 4.4 倍吞吐。其重要发现是：视频 decode 本身可能主导 TTFT；如果 benchmark 只从已经解码的 tensor 开始计时，就会系统性高估端到端服务能力。

对 Omni runtime，更准确的设计空间是把逻辑 stage、进程边界、GPU 边界和节点边界分开。两个 stage 可以拥有独立 scheduler 但共享一张 GPU，也可以在不同节点通过 connector 传 tensor。部署规划需要比较节省的排队时间与新增的通信、复制和显存驻留，而不是固定采用全共置或全解耦。

7. 多模态 cache：位置、媒体内容与持续历史共同决定复用

LLM prefix cache 假设复用内容出现在同一前缀位置；多模态对话中，相同图片可能被不同文本包围，绝对 token 位置随轮次变化。MPIC通过位置无关的多模态 KV 表示、磁盘存储、加载与计算重叠，以及按准确率选择复用或重算来解除这一限制。论文在其模型与负载下报告响应时间最多降低 54%、吞吐提高 2 倍。

Inf-MLLM关注持续视频：如果每轮都保留全部历史帧，KV 随时间线性增长；如果只保留最近帧，又会丢失早期关键事件。它观察到 streaming MLLM 的 attention saddle，组合 recent/relevant 有界 cache 与 bias，在论文设置中实现单 GPU 最长 4M token、约一小时视频，并相对 H2O 报告约 2 倍提升。

2026 年的 HybridKV按 attention head 的静态/动态行为分配分层预算，并用文本优先 pruning 与 chunk retrieval；在 Qwen2.5-VL-7B、11 项 benchmark 上报告最高 7.9 倍 KV 压缩与 1.52 倍 decode 加速。Kamera则增加低秩跨 chunk 条件补丁和精确 RoPE rerotation，并报告生产 SGLang kernel 实现。两者说明 cache identity 不能只由字节 hash 决定，还要包含位置变换、模型版本、视觉 tokenizer 和近似误差政策。

Omni runtime 因而至少要区分媒体 decode cache、encoder feature cache、AR KV cache、diffusion latent/condition cache 和 session state。它们有不同的命中键、精度风险和驱逐成本；“统一缓存”更应理解为统一元数据与生命周期协议，而不是把所有对象塞进同一种页。

8. Diffusion serving：调度轴从 token 变成 step、patch 与 trajectory

DistriFusion（CVPR 2024）以 displaced patch parallelism 把图像 patch 分散到多 GPU，并复用前一步 feature 隐藏通信；其 SDXL 实验在 8 张 A100 上报告最高 6.1 倍。PipeFusion用前一步 stale feature 构造 patch pipeline，随后 xDiT把 sequence、patch、CFG 与 data parallel 组合成可选并行空间。它们解决的是单个 Diffusion 请求如何跨 GPU，而非多租户在线排队。

在线 serving 随后把请求异质性纳入 scheduler。PATCHEDSERVE对不同分辨率请求做 patch-level batching/cache 和 SLO 预测，在论文负载中把 SLO attainment 提高 30.1%。DDiT拆分 text encoder、DiT、VAE，根据分辨率选择并行度，并在 denoising step 粒度调整资源；论文在 T5、OpenSora、DiT/VAE 实验中报告 p99 和平均延迟分别最多改善约 1.44、1.43 倍。

DiT-Serve（ICLR 2026）用 step-level continuous batching 让不同到达时间的请求共享执行，以 Brick Attention 打包不同长度/环结构，并用 \(\mathrm{steps}\times\mathrm{patches}\) 近似剩余工作量做 shortest-job-first。其 Open-Sora、Mochi、CogVideoX 实验报告 2–3 倍吞吐与 3–4 倍延迟下降。

进一步地，DisagFusion把 encoder、DiT、decoder 变成独立服务并异步流水，使用预测器与反馈调整 stage ratio；论文在现代 Diffusion 模型和异构 GPU 上报告 3.4–20.5 倍吞吐、最高 18.5 倍延迟下降。GF-DiT把并行策略本身变成可调度对象，用异步 trajectory task 与动态 collective group，在 vLLM-Omni 中实现，并在其图像/视频实验中报告最高 6.01 倍吞吐、平均延迟最多降低 95%。

这条支流解释了 Omni runtime 为何需要专用 DiT engine：AR batch 的进度单位是 token，Diffusion batch 的进度单位是去噪 step，空间大小还随分辨率变化。统一 runtime 可以共享 admission、路由和 connector，但不能假定两类 stage 有同一调度器。

9. Streaming video：一次性视觉 prompt 演化成永不结束的 iterative prefill

VideoLLM-online（CVPR 2024）的 LIVE 框架把视频帧持续送入模型，在事件发生时在线回答，而不是先看完整段视频再生成。这改变了服务状态机：会话没有明确的 prefill 终点，新帧到达、文本生成和历史压缩可能同时发生。

模型侧工作开始主动减少系统负担。LiveCC（CVPR 2025）用与视频对齐的流式 ASR 监督训练实时评论；TimeChat-Online（ACM MM 2025）用 Differential Token Drop 去除静态重复视觉 token，论文报告总体移除超过 80%，长视频子集最高 97.5%。这些百分比描述论文数据上的 token 删除率，不是直接的端到端吞吐倍数。

ViCoStream把优化推进到执行层：协调视频 decode、vision encoder 与 LLM iterative prefill，用 CUDA overlap 和 chunk-wise execution 隐藏阶段空隙。论文在 Qwen2.5-VL 3B/7B 上评估，报告单张 A100 达 134 FPS、TTFT 低于 50 ms，同时接近 full-history 精度。

对 Omni runtime，流式视频需要 session-scoped 队列、帧时间戳、bounded history、增量 encoder、取消与过载降级。若输入帧速率超过可持续消费速率，系统必须明确丢帧、降采样、压缩历史或拒绝会话；把帧无限排队只会把“无错误”变成不可用的陈旧回答。

10. Duplex speech：用户、模型与播放器同时推进

Moshi（2024）用 Mimi codec 表示音频，以并行的用户/助手音频流和 inner-monologue 文本前缀支持全双工对话；论文给出约 160 ms 理论、200 ms 实际延迟。Freeze-Omni在冻结文本 LLM 前后接 streaming speech encoder/decoder，并通过三阶段训练保留文本能力；GLM-4-Voice则组合 12.5 Hz tokenizer、GLM-4-9B 与 streaming CosyVoice decoder。

Qwen2.5-Omni把 Thinker、双轨 AR Talker 和 DiT vocoder 组成流式 text/speech 输出图。Qwen3-Omni进一步采用 Thinker-Talker MoE、多 codebook audio 与 causal ConvNet，并报告 234 ms 理论首包。这里的理论首包由模型因果结构决定，实际服务仍包含排队、跨 stage 传输、组批与音频设备 buffer。

DuplexSLA把持续用户音频、助手音频和结构化 action stream 对齐到共享的 160 ms 时钟，工具规划与语音输出可以并行推进；BayLing-Duplex则用单个自回归 LLM 和少量控制 token 实现原生全双工，不依赖外置 VAD。这两项工作定义了两种不同的 runtime 合同：前者要求 action、音频与工具执行共同调度，后者更接近可直接复用现有 AR serving stack 的持续双向流。

VoxServe为 SpeechLM 建立执行抽象、streaming-aware scheduling 和异步 pipeline；论文在多种现代 SpeechLM 上报告相近延迟下 10–20 倍吞吐。LiveServe则直接面向交互：优先首音频与即将 underrun 的会话，限制生成进度不要过度领先播放器，并在用户讲话时 preload 下一次可能使用的 KV。它实现于 vLLM-Omni，在两种 Omni LM 的混合负载上报告 P90 首音频包平均改善 1.55 倍、最高 2.21 倍，完成吞吐平均提高 1.15 倍、最高 1.56 倍。

这条支流把 scheduler 的单位从 request 变成带播放前沿的 session。生成太慢会 underrun，生成太快会占用 KV、浪费已被 barge-in 取消的音频。正确目标是让计算进度贴近消费进度，并让 cancel 从前端传播到 Talker、codec、vocoder 和下游 buffer。

11. 模型论文为什么属于系统谱系：它们定义了待执行的异构图

NExT-GPT（ICML 2024）用 LLM、模态 adapter 与外部图像/视频/音频 Diffusion decoder 构成 any-to-any pipeline，是异构 stage graph 的早期范型。AnyGPT把 speech、text、image、music 全部离散化后交给单一 AR LLM，代表另一极端：模态统一在 token 空间，runtime 更接近传统 LLM serving，但序列长度和多 codebook 输出更复杂。

Transfusion（ICLR 2025）在同一 transformer 中对文本使用 next-token loss、对连续图像 patch 使用 diffusion loss；BAGEL把 AR text path 与 flow/DiT visual path 放进统一 decoder-only 模型。两者都证明“一个模型”不等于“一个同质 kernel loop”：训练权重可以统一，推理阶段仍需区分 AR、flow、VAE 和媒体后处理。

因此系统评测必须选择能覆盖不同图形态的模型，而不能只跑一个 VLM。Qwen3-Omni 检查 Thinker/Talker/codec，BAGEL 检查 AR+DiT，流式 VideoLLM 检查持续输入，Moshi 类模型检查双工播放。Omni runtime 的通用性应由这些执行契约验证，而不是支持列表长度。

12. Omni graph runtime：vLLM-Omni、Cornserve 与 M*

vLLM-Omni把模型表示为由 AR、DiT、CNN 等节点组成的 stage graph，用 transfer function 描述阶段间数据，允许每个 stage 独立选择 engine、batching 与资源，并由统一 connector 搬运中间状态。论文覆盖多种 Omni、图像与视频生成模型，在其硬件、模型和基线下报告 job completion time 最高降低 91.4%。它是本资料线后续源码页的中心论文。

Cornserve: A Distributed Serving System for Any-to-Any Multimodal Models使用 task/dataflow graph、组件独立扩缩、record-and-replay 执行和 producer 到 consumer 的 tensor 直传。论文实现基于 Kubernetes、约 23K 行 Python，在多种 any-to-any 模型实验中报告 3.81 倍吞吐和 5.79 倍 tail latency 改善。它与 vLLM-Omni 的共同点是把 stage graph 变成服务单位；差异在于 Cornserve 更强调分布式 dataflow 和执行复现。

M*以 Walk Graph 抽象任意组件组合和放置，并承载模型无关优化。项目在 BAGEL text-to-image、Qwen3-Omni TTS、V-JEPA2-AC rollout 上评估；论文分别报告相对指定基线约 20% 端到端延迟下降、Qwen TTS 最高 2.9 倍 RTF/2.7 倍吞吐，以及 rollout 最高 12.5 倍提升。这些数字来自不同模型和协议，不能合并为“M* 普遍快若干倍”。

SGLang-Omni 的证据等级不同。当前官方仓库与架构文档描述 per-stage scheduler、共享 inbox/outbox，以及 SHM、NCCL、NIXL、Mooncake 等 transport；但截至核验日没有一篇独立的 SGLang-Omni 论文。因此本页只把它作为 runtime 实现路线与 vLLM-Omni 对照，不给它虚构标题、作者、venue 或论文实验数字。

13. 从手工部署到 planner 与编译器：Cornfigurator、GF-DiT、FlashRT

Cornfigurator: Automated Planning for Any-to-Any Multimodal Model Serving用粗到细的统计规划搜索共置、解耦与混合部署，以 SLO goodput 为目标。当前 arXiv v3 在论文实验中相对既有系统或专家计划报告 1.12–6.32 倍 goodput。一个容易造成引用错误的版本事实是：该 arXiv 条目的 v1 曾使用 Cornserve 名称，但当前论文是部署规划器 Cornfigurator；分布式 runtime Cornserve 是另一篇 2603.12118，二者不可合并。

GF-DiT 展示了另一种自动化层级：不只选择 stage 放在哪，还在请求运行时选择并行 group。FlashRT则把参考模型 pipeline 转换为 IR，由 agent harness 和 chain-of-program 执行静态分析，再用测量门控的 transformation 跨 GPU 优化。论文在 B200、MI355X 上评估视频世界模型与 MLLM，并报告 Qwen3-Omni text-to-audio 在 MI355X 上相对专家调优 vLLM-Omni 延迟低 65%；这只属于该模型、平台和实现版本。

这三项工作指向下一代 Omni runtime 的分层控制面：模型编译器识别 stage 与数据依赖，planner 决定 replica、并行和 placement，在线 scheduler 根据到达率、batch 与播放状态微调。若三层都独立修改拓扑而没有共同 contract，就会产生重复搬运、错误 cache identity，性能回归也会失去统一的归因依据。

14. 怎样读这些实验：先固定工作负载，再判断机制是否成立

论文间最常见的误读是把不同任务的最大倍率排成排行榜。一个可信的复现实验至少固定以下字段：

尤其要区分三个实验层级：单 stage microbenchmark 证明 kernel 或 batching 机制；固定 pipeline benchmark 证明跨阶段通信与 overlap；开放到达的 trace replay 才能证明 SLO goodput、背压和多租户行为。只有第三层才能回答“这个 Omni runtime 在真实并发下是否稳定”，但前两层仍用于定位收益来源。

15. 2026 年的收束点与仍未解决的问题

到 2026 年，论文已经形成较稳定的共同抽象：模型是一张异构 stage graph；每个 stage 有自己的执行粒度、batch key、并行方式和状态；边通过显式 connector 搬运 tensor 或 token；部署器独立决定逻辑解耦与物理放置。vLLM-Omni、Cornserve、M* 与 SGLang-Omni 的实现方向都可放进这个框架。

尚未收束的是端到端控制。现有论文通常分别优化 KV、Diffusion、视频或音频，跨模态会话的统一 backpressure、公平性、故障恢复和 cache 一致性仍缺乏共同 benchmark。实时会话还引入“已生成但尚未播放”的可撤销工作；多租户系统必须同时约束 GPU 时间、显存驻留、媒体带宽与会话连续性。

因此后续阅读不应只问哪个 runtime 更快，而应问：它如何表示 graph；谁拥有状态；队列在哪里；connector 是否有流量控制；取消能否传播；stage 故障后从哪里恢复；planner 的预测误差由谁修正。第 04–09 页将据此分别追踪 vLLM-Omni 与 SGLang-Omni 的代码路径，再做同层比较。

16. 一手来源与版本边界

来源最后核验于 2026-08-08。arXiv 论文按当前版本题名记录；论文后续若改题、改实验或正式发表，应同时更新题名、版本日期与本站结论边界。