vLLM-Omni：调度、KV 与 connector 是三套相连但不同的机制

1. 调度对象是 stage，不是抽象的整条模型

一个 any-to-any 请求可以横跨 Thinker、Talker、Code2Wav 或 AR、DiT、专用模块。vLLM-Omni 的架构将每个 stage 作为独立 engine 的工作单元：它们可拥有不同 batch、GPU 资源和运行参数。端到端请求仍需在这些 stage 间维持关联，因此服务端既需要 stage 内的调度，也需要 stage 间的编排。

这与简单的数据并行不同：把请求随机分给任一设备，不能保证后续阶段仍能找到该请求对应的上游状态。也与单一 pipeline parallel 不同：不同 stage 可以使用不同模型执行器，甚至一个是 vLLM AR engine、另一个是 diffusion engine。本章以下的「调度」均指这些明确可见的运行时职责，不推断未公开的全局最优策略。

2. StagePool 管理副本、负载均衡与亲和性

stage_pool.py 中的 StagePool 维护 stage replica，并提供负载均衡和 request affinity。请求第一次进入一个 stage 时会选择副本；后续与该请求相关的操作应回到同一副本，避免把该 stage 的局部运行状态当作可任意迁移的数据。

亲和性不是端到端性能优化的万能答案。它解决的是「同一 stage 的同一请求去哪一个 replica」；上游到下游仍要通过 pipeline 路由和 connector 交接载荷。若某一 stage 副本已饱和，亲和性也可能让后续 chunk 等待该副本。容量规划应分别看每个 stage 的排队、服务时间和跨 stage 等待，而不是只报一条总 QPS。

3. AR KV 缓存属于具体 AR stage

AR 解码依赖其历史 token 的 KV cache。vLLM-Omni 复用 vLLM 的 AR 能力，但不同 AR stage 具有各自的模型、token 序列和缓存空间。例如 Qwen3-Omni 的 Thinker 与 Talker 都是 LLM_AR，并不是共享同一套可直接互换的 KV。Thinker 输出的 hidden state 或 token 语义也不等于 Talker 的 attention KV。

因此跨 stage 的正确问题是「下游怎样构造自己的输入和 prefill」，不是「能否把上游 KV 原封不动传过去」。对于同一个 stage，前缀缓存、持续请求或 session 状态是否启用，又取决于该 stage 的配置和模型适配。不要把某个 YAML 中的 enable_prefix_caching: false 解读为全项目都不支持前缀缓存，也不要反过来假定所有多阶段路径都有会话 KV 复用。

4. async_chunk 让下游有机会提前准备

在 connector adapter 中，construct_next_stage_streaming_input_prompt 会构造下游的流式输入 prompt，并更新 prompt bookkeeping 与 block hash。它服务于异步 chunk 的预热路径：下游不必等到整段上游结果全部传完，才开始其可执行的准备工作。

这是重叠机制而非通用传输协议。收益受下游 prefill、chunk 间隔、KV 余量、设备竞争和 connector 延迟共同限制；过小 chunk 会增加控制与调度开销，过大 chunk 又降低重叠机会。可比的实验至少要记录：上游首 chunk、下游开始 prefill、首个最终媒体 chunk、最终完成和取消释放的时间，而非只比较一个总耗时。

5. OmniConnector 的契约：数据与通知分开

adapter 的发送路径会尝试通过 connector put() 交付 payload，成功后再向通知队列放入描述信息；connector 不可用或发送失败时，代码可退回队列路径。接收端则根据通知尝试 try_recv_via_connector。这一设计使控制消息不必承载整个 tensor，同时保留在特定失败条件下的回退路径。

不过，回退并不自动等价于任意大小载荷的无损、高吞吐或 exactly-once 传送。发送端、接收端、共享 buffer 生命周期和请求取消必须达成一致；否则可能出现通知已到而载荷未就绪、消费后未释放或取消后残留的数据。官方 connector 文档描述的是接口与后端能力，而不是跨所有故障域的事务协议。

6. 本地共享内存与远端 Mooncake 的区别

官方 stage 配置文档将 SharedMemoryConnector 作为同机默认选择，将 Mooncake Store 用于跨主机的场景。源码 factory 在该 tag 注册了 SharedMemory、Mooncake Store、Mooncake Transfer Engine，以及 Yuanrong、Mori 等实现；「存在于 factory」只说明实现被注册，不能替代每个后端、每个模型配方的兼容性结论。

Mooncake Transfer Engine 文档说明远端数据面由 ZMQ 元数据和 Mooncake Transfer Engine 的直接 P2P 传输组成，可转移 KV、hidden state、chunk 等数据。它还注明一次成功传输为单消费者语义，接收端对 raw tensor 快路径的 buffer 要负责释放。于是跨机设计必须明确消费者拓扑和内存回收，不能把单消费者实例暗中扩展为广播。

7. Qwen3-Omni 配置展示的是拓扑，不是硬件下限

仓库的 qwen3_omni_moe.yaml 有一个注释明确的示例：两张 H100 上，stage 0 使用 cuda:0，stage 1 与 stage 2 使用 cuda:1；配置开启 async_chunk，并让 stage 间使用共享内存。stage 0/1 的批 token 上限均为 32k、最大序列数 64，而 stage 2 的批 token 上限为 65k、最大序列数 64。

文件还显示 stage 0 使用 0.9 的 GPU memory utilization，stage 1 使用 0.6，stage 2 使用 0.1；这些数值是该参考配方的资源划分，不是可迁移的推荐比例。该 YAML 还含 NPU、ROCm 和 XPU 的平台分支，例如 NPU 的 Thinker 使用 TP=2 和 PIECEWISE CUDA graph 设置，ROCm 的 Code2Wav 因 MIOpen 的 conv_transpose 捕获限制而 eager。部署时应从目标模型的官方配方开始，而非抄一个数字。

8. 扩散引擎有 request-batch 与 step-batch 两种执行形态

diffusion_engine.py 定义 REQUEST_BATCH 与 STEP_BATCH。前者由 RequestScheduler 组织请求批次；后者由 StepScheduler 按去噪 step 推进。源码规定，要求流式输出会强制 step execution；若模型不支持 batch 而 max_num_seqs 大于 1，会报错而非悄悄伪造批处理。

这意味着扩散吞吐测试不能只看 batch size。是否要流式中间结果、模型是否可批、每个请求的步数和分辨率，都会改变调度粒度。在该版本的 layerwise distributed offload 路径里，若数据并行度大于 1，代码会把最大运行请求数设为 DP size，并有默认 500 ms 的 admission wait；这是具体实现路径，不能推广为所有扩散部署的公平性或排队策略。

9. 扩散缓存和显存卸载带来的是可量化取舍

官方Diffusion Features把 TeaCache 与 Cache-DiT 标为有损的速度/质量权衡，不能把它们写成等价计算。文档还明确：TeaCache 与 Cache-DiT 互不兼容；模块级 CPU offload 与层级 CPU offload 互不兼容；层级 CPU offload 仅支持单卡；step execution 不能使用 diffusion cache backend。

这些限制足以改变实验结论。例如若一组基线以 step mode 流式输出，另一组使用 request batch 加缓存，二者并非只改变了一个开关。报告应同时给出执行模式、采样参数、缓存策略、是否 offload、图像/视频大小、步骤数和质量评估，避免把一次特定吞吐增益说成所有 diffusion 请求的加速比。

10. 并行策略必须从兼容矩阵出发

官方文档列出 Ulysses、Ring、CFG parallel、TP、PP、HSDP、EP 等 diffusion 并行或资源策略，并在 feature 页说明部分组合有约束：TP 与 HSDP 不兼容。release notes 还把分布式策略描述为叠加 TP、DP、PP、EP 与 stage replica 的 overlay，并注明 phase 1 的端到端验证只覆盖 TP 与 stage replica。

因此不能从「配置里有 DP/PP/EP 字段」推出任意组合已获端到端验证。应区分模型内并行、扩散内并行、stage 副本和 stage 间数据面：它们分别影响算子切分、请求数、模型副本数和中间载荷传输。启用多项策略时，先查版本对应文档和具体模型 recipe，再做小规模正确性与取消测试。

11. 背压、故障与可观测性仍是部署者的责任

某个 connector 快并不说明系统在消费者变慢、缓冲区耗尽、客户端取消或某个 stage 失联时仍可维持目标延迟。安全的运行监控至少应把请求 id 的各 stage 入队、开始、首 chunk、完成、取消与 connector 失败分开记录，并在容量测试中施加下游慢消费和短连接中断。

官方metrics 文档当前只把文本与音频指标列为覆盖范围，扩散/图像/视频指标仍待后续支持；并明确动态增删 replica 的运行时指标问题尚不在范围内，原因涉及上游 Prometheus 指标索引初始化。这里不能据此宣布运行时弹性伸缩已经可观测或可恢复。

12. 一个实际的调优顺序

先固定模型、版本、输入形态和最终输出目标，再为每个 stage 记录 GPU、并行方式、batch 与显存上限；随后选择同机共享内存或经验证的跨机 connector；最后才比较 async_chunk、缓存和卸载。每次只改变一个会影响执行模式或语义质量的变量，并记录失败、取消和内存释放行为。

这个顺序的目的不是追求一个通用最佳配置，而是避免把三个相互作用的层次同时改变：stage 内 scheduler、AR KV/下游预热、跨 stage 数据面。对于任何没有对应官方模型 recipe 的组合，结论应写成待测假设，而不是将 Qwen3 参考配置或一篇论文的单机实验外推成产品承诺。

13. 一手来源