1. 先问：究竟在比较哪个系统问题

一条 any-to-any 请求不一定走完整模型。图文问答可能只需要媒体 encoder 和 Thinker；文本到语音还要经过 Talker、codec 与 vocoder；图像编辑又可能进入 VAE、DiT 和 classifier-free guidance 分支。若一个系统只执行其中一条路径，而另一系统把整张图固定在同一进程，二者的资源占用和排队对象已经不同。

因此本文用同一层次的问题来读各项目：谁声明逻辑图，谁决定一项工作何时进入局部 batch，谁持有 KV、feature 或 codec 状态，谁把大对象交给下游，以及谁能够改变 GPU 放置。接口名称相同，例如 /v1/chat/completions，只说明入口相似，不能说明内部路径、流式语义和可靠性相同。

2. 证据锚点与版本，不把移动主线混在一起

路线本页使用的公开锚点可证明的范围
vLLM-Omniv0.26.0，commit a4ea67a21b20054dacc6e83952f9bd407e8ee4e7，2026-08-03。固定代码、配置与文档；另有 2026-02 的独立系统论文。
SGLang-Omnimain 7daa5be3aa0e2c3787eb1bc371594ea277191b61，2026-08-07；release 0.1.0 为 8e272bcb...。官方仓库、文档、cookbook、release 和明确的 issue；截至核验日没有独立 SGLang-Omni 论文。
CornservearXiv:2603.12118v2，2026-04-28；CAIS 2026 论文。论文描述的 task abstraction、model fission、Kubernetes runtime 与论文评测，不能替代任意部署的资格报告。
M*arXiv:2606.12688 与 公开代码 commit 82ea8212，2026-08-05。Walk Graph、Conductor/Worker、论文列出的模型与实验；研究结果不是所有组件组合的生产 SLO。
FlashRT公开代码 commit 7fd75d20，2026-08-06。小 batch、延迟敏感的模型前端、CUDA Graph 和内核路径；它不是通用分布式 Omni 编排器。

上表也解释了不对 SGLang-Omni 伪造论文引用的原因。它可以有清楚的源码与 cookbook 证据，但这些证据的推断范围仍不同于有固定实验表、基线和系统设计章节的论文。

3. 执行图：相同模型，系统切分可不同

下列图是比较用的概念图，不是对每个 checkpoint 的精确拓扑。它展示的是系统把哪一种关系升为一等对象：stage、task、component walk，或单个低延迟 forward。模型作者仍必须声明哪些边在特定请求中会被跳过、复制或流式化。

any-to-any 的一条语音输出路径

media -> encoder -> Thinker -> Talker -> codec tokens -> vocoder -> audio chunks

vLLM-Omni:   PipelineConfig 的 stage graph，Orchestrator 连接独立 stage engine
SGLang-Omni: StageConfig 的平面 DAG，Coordinator + stage-local scheduler + relay
Cornserve:    Python task / composite task，record 后 replay 请求实际调用的子图
M*:          component graph + request Walk，Seq / Parallel / Loop / Stream 都可成为边
FlashRT:     模型专用小 batch forward / captured CUDA Graph；无通用跨 worker 图语义

平面 DAG 很适合已知的 Thinker-Talker-vocoder 管线；record-and-replay 适合请求内容决定分支的应用；Walk Graph 进一步把并行、循环和流视为图原语。FlashRT 的目标则不同：它尽可能缩短一个已知模型路径的运行时间，通常不替用户做跨节点任务拆分。

4. Scheduler ownership：谁有权把工作放进 GPU

路线全局/图级 owner局部 owner 与调度单位
vLLM-OmniAsyncOmniEngine 与 Orchestrator 跟踪请求在配置 stage 间的依赖与路由。每个 stage engine 的 scheduler 管理自己的 AR 或 generation 工作、队列和 batch；论文明确描述 per-stage request batching。
SGLang-OmniCoordinator 维护请求生命周期、terminal 聚合与 abort 广播，Stage runtime 处理 fan-in/out。OmniScheduler bridge 负责 AR stage；SimpleScheduler 与 streaming scheduler 服务轻量/codec/vocoder stage。它们不是一个全局 token loop。
CornserveGateway、Task Dispatcher 与 Task Manager 把 record 的任务调用转为 executor 调度。Task Manager 负责某 unit task 的 executor 副本与路由；论文的重点是组件粒度 fission 和独立扩缩，不是一个统一 AR scheduler。
M*Conductor 跟踪 request Walk 并向 GPU Worker 派发 component work。Worker 内有 AR KV engine 与 stateless engine；论文/项目页把 loop 上的 continuous batching 描述为通用机制。
FlashRT没有面向任意分布式图的 Conductor 或 task control plane。应用调用模型前端；关注固定形状、少量并发的内核、量化和 CUDA Graph replay，而非多 stage 的 admission 与负载均衡。

“每 stage 一个 scheduler”不等于“已经全局最优”。局部 scheduler 需要从下游得到容量、deadline 或 credit，才不会让快速 Thinker 无限制造 Talker 等待的状态。下一页把这个问题写成可验证的 backpressure 合同。

5. Batching：batch 边界跟着计算形状，而不是跟着 HTTP 请求

vLLM-Omni 的论文与架构文档以独立 stage engine 和 per-stage batching 为核心；其部署配置还允许分别设定 max_num_seqs、token budget、GPU memory 与 async scheduling。SGLang-Omni 也让 AR、普通函数与流式 vocoder 使用不同 scheduler，因而把 KV、chunk window 与媒体 batch 的约束留在各自 stage。

Cornserve 允许 task executor 在独立组件边界扩缩，batch 政策取决于所选 executor。M* 则宣称其 AR KV engine 和 stateless engine 都支持 continuous batching，且把 loop 纳入同一执行抽象。FlashRT 明确瞄准小 batch、延迟敏感工作负载，其静态 CUDA Graph 需要稳定的 shape、buffer 与运行路径；它的优势前提不能拿来推导高并发混合队列下的 goodput。

比较要点：报告每个 stage 的 batch size、fill ratio、排队时间、活跃 sequence、chunk size 和形状分布。只给端到端 QPS 会把“减小输入、关闭流式、固定 batch=1”误写成 scheduler 优势。

6. Cache 与中间状态：名字相同，身份和寿命不同

路线公开的状态着眼点不可从中推出什么
vLLM-OmniAR 路径继承 vLLM 的 KV 管理；配置/connector 可在 stage 间搬运 KV、hidden state 和 chunk payload；Diffusion 另有自己的 cache 路径。一个 stage 的 prefix cache 开启，不保证另一个 stage、不同模型 revision 或不同媒体 processor 也可复用。
SGLang-OmniAR stage 复用 SGLang tree/Radix KV 机制；Qwen 路径还明确有媒体 encoder output cache，Talker 的 cache policy 可不同。core SGLang 的全部缓存或 scheduling feature 自动适用于 Omni pipeline。
Cornserve论文强调 data dependency、direct tensor forwarding 和可共享的等价 task executor。论文没有把任意 KV cache coherence 或跨租户复用写成通用保证。
M*AR engine 使用 FlashInfer paged-attention KV cache；无状态 engine 运行 encoder、decoder 与 codec，rollout 的 KV 可跨 loop 保留。所有模型 component 都可按同一 key 安全共享，或跨网络有持久缓存语义。
FlashRT仓库记录 checkpoint/sequence-length 维度的量化 calibration cache 和预分配 buffer。它有一个通用、多租户、跨节点的 KV/媒体 feature cache。

安全的复用 identity 至少要包含模型/processor revision、输入媒体派生规则、position/precision/layout、adapter 和租户访问策略。将“同一文本 prompt”当作完整 key，会让媒体 resize、抽帧或音频采样率变化被静默忽略。

7. Connector 与数据面：控制消息和 tensor 不应混为一条线

vLLM-Omni 的 OmniConnector 是可配置的 stage-edge 合同。固定版本文档列出同机 SharedMemoryConnector，以及 Mooncake store/transfer-engine 等远端后端；后者的性能、RDMA 与清理语义都依赖实际 connector、NIC、内存池和拓扑。SGLang-Omni 则把控制消息与 payload reference 分开，当前文档按同进程、CUDA IPC、SHM、NCCL/NIXL 与 Mooncake 等条件选择 relay 路径。

Cornserve 的论文让 per-GPU Sidecar 直接在 producer 与 consumer executor 间转发 tensor，避开中心控制面；M* 公开 shared memory、RDMA 或经 Mooncake 的 TCP 数据面。FlashRT 没有等价的通用 remote tensor connector，因此不宜因它的低延迟单机结果而比较它的跨节点 data-plane 能力。

连接器选型应报告 payload 类型与字节数，而不是只写“zero-copy”：一条边可能传 KV block、hidden state、latent、codec code、CPU bytes 或仅 metadata。每一种对象的序列化、所有权、ACK、cancel 和回收成本不同。

8. Placement 与独立扩缩：声明、计划与实际容量是三件事

vLLM-Omni 的 PipelineConfig 固定逻辑 topology，deploy YAML 决定 stage 的 GPU、TP、每 stage capacity 和 connector edge。SGLang-Omni 的 StageConfig 也可声明 process、GPU、TP、后继和 fan-in；Router 在更外层选完整 worker，不应被误读成把一个请求的 Thinker 与 Talker 随意拆到不同 worker。

Cornserve 论文的 Cornfigurator 根据模型和 workload 搜索 fission、共置与副本计划，并通过 Task Manager 实现；M* 的 placement YAML 映射 component 到 GPU rank，允许 component disaggregation、TP 与 path-aware placement。FlashRT 是模型/硬件前端的显式选择，目标通常是把既定路径压进受控的实时 cell，而非运行在线集群 placement search。

无论哪种系统，资源决定至少包含权重常驻、KV/feature/latent 峰值、workspace、connector pool、网络路径和故障冗余。只把一个组件“放到另一张卡”没有回答它是否能在下游速度、显存和网络预算下持续运行。

9. 支持工作负载：用“已展示的路径”而不是项目名做矩阵

路线公开代表路径正确的支持结论
vLLM-Omni官方矩阵列出 Qwen2.5/3-Omni、Ming Flash Omni、BAGEL、TTS、图像/视频/音频 diffusion 与部分 action policy。以固定版本的“模型 × backend”表和对应 recipe 为准；表中的 model class 不自动证明所有输出组合、流式或多节点已验收。
SGLang-Omni固定提交的文档覆盖 Qwen3-Omni、Ming-Omni、多种 TTS、ASR 与 Router capability routing。区分 text-only、speech、streaming 和实验 cookbook；接口或模型目录存在不等于生产成熟。
Cornserve论文评测涉及 Qwen2.5-VL、InternVL 3、Qwen Image、Qwen2.5/3-Omni 等异构组件图。它证明论文实现的代表模型/工作负载，不声明每个开源 checkpoint 都有现成 executor。
M*论文实例化 BAGEL、Qwen3-Omni TTS、Orpheus、V-JEPA 2 等图。这是多类 composite model 的研究证据；新增模型仍需 component adapter、placement 和正确性验证。
FlashRTREADME 的旗舰路径是 Pi0、Pi0.5、GROOT N1.6/N1.7、Pi0-FAST 等 VLA，另含若干 TTS、world-model、视觉/视频和单流 LLM 路径。按模型、GPU 架构和固定实时 profile 读；它不承诺 general any-to-any serving matrix。

10. API、代码、论文与生产资格不能互相替代

可运行 demo、OpenAI-compatible API、单元测试、论文 prototype、正式 release、持续集成、硬件矩阵和长期故障 SLO 分别回答不同问题。一个项目可能在模型接入与单机 demo 上很强，却没有公开跨节点恢复证据；另一个项目有论文实验，却没有面向任意用户的安装/升级承诺。

故此页不制造“成熟度分”。部署判断应逐路径记录：目标模型 revision、端点、输入输出模态、是否流式、GPU/NIC、并发范围、质量回归、cancel/timeout 结果和可复现环境。特别是 SGLang-Omni 的接口与 stage 架构已经是可验证的公开事实，但没有独立论文不能被补写成论文成熟度；反过来，M* 或 Cornserve 的论文也不能被误当作全量生产支持清单。

11. Benchmark 数字的边界：不能把不同论文的最大值横着相除

来源中的数字原始口径不可外推的结论
vLLM-Omni：JCT 最多降低 91.4%其论文选定的模型、硬件、baseline 与 workload。任何模型、任何拓扑都可降低 91.4%，或高于另一篇论文的吞吐数。
Cornserve：最多 3.81× throughput、5.79× tail-latency reduction论文的 monolith 比较、组件 fission 和部署计划。任意 vLLM-Omni/SGLang-Omni 版本在相同 GPU 数上必然被超过。
M*：BAGEL 文生图平均更低端到端延迟；Qwen3-Omni TTS 的 RTF/throughput 结果论文/项目页给出的模型、placement、batch、H100/H200 等明确设置。一条 Walk Graph 必然优于所有平面 stage graph，或数值可换到另一模型。
FlashRT 的 repo benchmark多为特定模型、量化、GPU、热态与小 batch 的实时 profile。可与集群 goodput、长队列 p99 或多租户性能直接比较。
SGLang-Omni cookbook/benchmark模型路径和文档中列出的有限硬件、并发与音频合同。没有论文就没有性能，或某个 cookbook 数字代表所有模型/connector。

正确做法是选择一个模型路径，例如 Qwen3-Omni 文本到语音，固定 checkpoint、音色、输入长度、输出时长、采样、TP、GPU、connector、到达过程和质量门，在相同 harness 中交替运行。没有等价模型适配时，应报告“不可直接比较”，而不是拿各项目最漂亮的一行数字排名。

12. 一套可执行的公平比较协议

  1. 将请求写成冻结 trace：输入媒体 hash、prompt、输出合同、开始时间、deadline 和取消时间都固定。
  2. 锁定模型/processor revision、runtime commit、镜像 digest、驱动、CUDA、GPU/NIC 拓扑与全部 stage placement。
  3. 先通过输出质量门：文本语义、音频样本数/采样率、图像或视频质量、stream 拼接与终态一致性。
  4. 分别报告 TTFT、TTFA、完整 JCT、RTF、阶段 queue、batch、cache hit、连接器字节、GPU memory 与失败原因。
  5. 在冷启动、热态、开放环饱和、慢消费者、client cancel、worker restart 与 connector 延迟下重复。
  6. 保留全量请求分母和失败 attempt；只统计成功样本会人为抬高吞吐、压低 tail latency。

对同一请求 \(r\)，比较单位不是一个裸延迟，而是配置元组 \(C_r=(m,p,h,a,s,q)\)：模型/processor \(m,p\)，硬件与拓扑 \(h\)，到达过程 \(a\)，stream 与采样合同 \(s\)，以及质量门 \(q\)。只有 \(C_r\) 等价时，端到端时间差才主要可归因于 runtime；这是本站的分析约定，不是任一论文的原始公式。

13. 选型时先匹配问题形状

已有 vLLM-Omni 路径

目标是使用其固定版本已经列出的模型、stage deploy YAML、connector 与硬件后端。优先从模型 recipe、feature matrix 和目标 workload 的本地回归出发。

需要 SGLang AR bridge 与语音 pipeline

目标是 Qwen/Ming/TTS/ASR 等明确 cookbook 路径，并愿意按 stage scheduler、relay 与模型特有流式合同做验证。不要把 core SGLang feature 表当作 Omni feature 表。

研究通用 any-to-any 集群编排

Cornserve 的 task fission/record-and-replay，或 M* 的 Walk Graph/placement，提供了更通用的研究坐标。它们的论文数字应当成为复现实验的假设，而不是采购结论。

单机/边缘小 batch 实时控制

FlashRT 的 CUDA-first、固定路径策略更接近问题本身。若需求转为高并发、多租户、多 stage 集群，还需要额外的 admission、状态与恢复层。

14. 这张比较表刻意不作的推断

第一，connector 的模块或 README 名称不证明每个模型和跨节点组合都经过端到端资格化。第二，GitHub issue 只表明某个版本、配置或调查方向值得复现；它不是所有版本都失败的证据。第三，某系统支持多种模型不表示每个模型都支持相同 API、流式形式、缓存策略或硬件。第四，静态 CUDA Graph 的单机低延迟和 stage-disaggregated 集群吞吐是不同目标函数。

真正值得横比的是能够保留同一输出语义、相同资源和相同负载的可复现实验。其余差异应被保留为架构选择、待验证假设或证据缺口，而不是变成宣传语。

15. 一手来源与本页使用范围