多模态模型架构：媒体编码器、projector、LLM 与生成头

1. 前置：媒体最终也要变成可计算的 token

文本 tokenizer 把字符串变成离散 token id；图像和视频通常先经过 resize、patchify 和 vision encoder，得到连续向量；音频通常先变成波形窗口、mel 特征或 codec token，再由 audio encoder 编码。projector 或 connector 把这些向量映射到语言模型的隐藏维度，最后与文本 embedding 拼接或交错，形成 LLM 可以处理的序列。

这里有三个容易混淆的“token”。媒体 patch 是 encoder 输入单元；encoder 输出经过 projector 后是 LLM 序列中的视觉或音频 token；生成图像时，模型还可能输出 VQ code 或连续 latent token。它们的维度、生命周期和缓存方式并不相同，不能统一叫“多模态 token”后就忽略差异。

2. 模型骨架：媒体编码器、projector、LLM 与生成头

最简单的视觉语言模型把媒体 encoder 的输出经 projector 接入 decoder-only LLM；更复杂的统一模型会保留一个理解/推理主干，并连接语音 codec、vocoder 或图像/视频 diffusion decoder。无论输入模态多少，先要回答的是：表示在哪里产生、被投影到哪个隐藏空间、在主干中怎样与文本交互，以及输出由哪个 head 解码。

以 Qwen2.5-Omni 论文中的抽象为例，请求进入 Thinker 后生成文本与 hidden state；Talker 使用这些 hidden state 和多模态 embedding 生成音频 codec token，DiT vocoder 再把 codec 表示变成波形。一次普通的 model.generate() 无法自然表达这组相互衔接的状态机。

这是一张模型数据流：Thinker 的 hidden state 是 Talker 的条件输入，Talker 的 codec token 是 vocoder 的条件输入。它先定义哪些状态存在、由谁产生和谁消费；不应先把这些边误读为某种固定的服务拓扑。

3. 从模型图到 Runtime：文本服务的四个默认假设被打破

只按“prompt token 数”做 admission control 会失真。两条各 100 字的请求，一条带 224×224 单图，另一条带 60 秒视频，媒体侧计算可能相差几个数量级。若调度器直到 GPU worker 收到请求后才知道真实媒体形状，队列时间、显存峰值和 SLO 都无法提前控制。

vLLM-Omni 在 2026 年把 any-to-any 模型投影为 stage graph：节点是 LLM、DiT、CNN 或其他模型阶段，边是转换和传输中间结果的函数。每个节点可以拥有自己的 batch、GPU 配额和执行引擎，orchestrator 负责请求状态与路由。stage graph 除了拆分代码，还允许各阶段独立扩缩、连续批处理和量化。例如 Thinker 比 Talker 短、Talker token 数远多于文本输出时，三个阶段需要的 GPU 比例会随 workload 改变。

4. 底层算子：瓶颈会在一个请求中连续换三次

媒体预处理主要是 JPEG/PNG/video decode、resize、normalize、切帧和拼 batch，常受 CPU、内存带宽与数据搬运限制。vision/audio encoder 以大矩阵乘、卷积或 attention 为主，通常是一次性且高并行度的 prefill 型计算。LLM prefill 仍是大 GEMM 与 attention；逐 token decode 又转为低 batch、反复读取权重和 KV 的带宽受限计算。

模型若能生成媒体，LLM 后面通常还有 DiT：同一批 latent 要在数个到数十个 timestep 上反复经过 transformer，末端再由 VAE 或 vocoder 上采样。因此吞吐应按媒体 encoder、LLM、生成 decoder 和媒体 decode 分阶段报告，单一 tokens/s 无法描述整条路径。

5. 张量形状：分辨率和帧数怎样变成计算量

不考虑裁剪与 token merge，patch size 为 P 的图像会产生近似 Nv=(H/P)*(W/P) 个 patch。视频再乘帧数 F。例如 2048×2048、P=14 的示意输入约有 21,316 个 patch；若原样取 60 帧就是约 128 万个 patch。真实模型会 resize、tile、时空下采样、merge 或限制 token budget，否则 full attention 无法承受。

这个平方项说明“限制上传文件大小”不等于限制 GPU 工作量。压缩良好的 MP4 文件可能很小，但解码后有大量帧；一张高分辨率 PNG 文件可能不大，却会触发多 tile。admission control 应使用解码后的帧数、像素预算与预计 token 数。

6. 显存：权重之外还有四类容易漏算的对象

第一是 encoder 和 projector 权重；第二是媒体 embedding 与 stage 间中间张量；第三是 LLM KV cache；第四是图像/视频生成阶段的 latent、DiT activation 和 VAE workspace。若各阶段共卡部署，峰值可能叠加；若分卡部署，则增加跨进程或跨节点传输。

KV 公式里的 2 代表 K 与 V。视觉 token 一旦进入 LLM 前缀，也会在每层产生 KV，因此“vision encoder 已经结束”并不代表图像不再占显存。相反，它可能在长对话中一直以前缀 KV 的形式存在。多轮会话若重复携带同一图像，runtime 需要决定复用、重编码还是淘汰。

7. 多模态缓存：命中条件必须包含整个预处理语义

用 URL 或文件名作为 cache key 不可靠：同一 URL 内容会变化，不同 resize、crop、帧采样率、encoder checkpoint、projector、dtype 或 layout 会产生不同 embedding。稳健的 key 至少应包含内容 hash、解码与预处理配置、模型版本、输出 dtype 和张量布局。

可缓存层次也不同：原始媒体下载结果、解码后的帧、encoder embedding、projected token、LLM prefix KV 都能缓存，但越靠后越绑定模型和并行布局。跨请求共享 projected token 比共享原始图片省计算，却更难跨模型版本迁移；共享 KV 还绑定层数、KV head、位置编码和并行分片。

8. 调度：不能把不同分辨率直接塞进同一个 batch

encoder batch 适合按图像分辨率、tile 数、帧数或音频时长 bucket；LLM prefill 适合按总 token work 控制；decode 适合 continuous batching；DiT 则适合按 latent shape、采样步数和 guidance 配置组批。把所有阶段强行共用一个 batch 边界，会造成 padding、空等和 head-of-line blocking。

实用的调度器会为各 stage 分别维护队列和 token/pixel/latent budget。请求完成 encoder 后转入 prefill 队列，不再占着原 worker；文本完成后，无媒体输出的请求即可结束，其余请求进入生成队列。backpressure 还要沿图反向传播，否则下游 DiT 一旦堵塞，中间 hidden state 会不断堆积。

9. 并行与通信：每个阶段可以选择不同的卡数

vision encoder 可能用 data parallel，LLM 用 tensor/expert parallel，DiT 用 tensor、sequence/context parallel，VAE 又可能单卡或按 tile 并行。stage graph 的价值在于不要求这些组件共享同一并行度。代价是 stage 间需要搬运 embedding、hidden state、codec token 或 latent。

vLLM-Omni 报告的 Qwen2.5-Omni connector 微实验中，共享内存的 Thinker→Talker 与 Talker→Vocoder 传输分别为 5.49ms 和 0.53ms；Mooncake 路径为 8.28ms 和 3.34ms。论文把它们与数十秒级总推理比较，认为开销较小。这个结论不能无条件外推到跨区域网络或超大视频 latent，部署仍须实测字节数和拓扑。

10. 具体例子一：一张高分辨率文档图的问答

请求是“阅读这张 3000×2000 的发票并返回 JSON”。第一步不是 LLM：CPU 解码图片，按照模型规则 resize 或切 tile。第二步 vision encoder 对 tile 计算特征，projector 生成 LLM token。第三步 prefill 同时处理系统提示、JSON schema、问题和视觉 token。第四步 decode 逐 token 输出结构化结果。

若 OCR 需要细节，提高视觉 token budget 会增加 encoder、prefill 和 KV；若仅做分类，低预算更划算。DiffusionGemma 官方模型卡就公开了 70、140、280、560、1120 五档视觉 token budget，并建议 OCR/文档解析用较高预算、分类或视频理解用较低预算。这是“质量参数也是资源参数”的具体例子。

缓存时不能只保存最终 JSON，因为用户问题可能变化。可复用的中间层是固定预处理配置下的图像 embedding 或 prefix KV；一旦 encoder 或 projector 升级，必须版本失效。

11. 具体例子二：视频输入、文本思考、语音输出

假设用户上传 30 秒视频并要求语音总结。runtime 先采帧并编码视频，再由 Thinker 生成文本与 hidden state；Talker 根据这些状态生成远多于文本长度的 audio codec token；vocoder 再合成波形。若 Talker 是最长阶段，增加 Thinker GPU 不会提高端到端吞吐，反而会更快地制造待处理 hidden state。

正确做法是分别测量视频预处理时间、encoder time、Thinker TTFT/输出长度、Talker token rate、vocoder real-time factor 和 connector bytes。随后按瓶颈配置 stage 副本，并让 orchestrator 在下游拥塞时降低上游 admission。

12. 2026 已证实模型与系统数字

13. 部署蓝图：把资源池按阶段和瓶颈拆开

生产部署至少需要四类组件：媒体入口负责下载、解码、安全扫描和元数据；encoder pool 按媒体形状 bucket；LLM pool 管理 prefill/decode 与 KV；generation pool 运行 DiT、VAE 或 vocoder。orchestrator 保存 DAG 状态、SLO、重试与中间对象位置，object store 或高速 connector 负责大对象传输。

低并发时，共卡可以少一次传输；并发提高后，分卡更方便各阶段独立扩缩。应根据权重能否同时驻留、显存峰值是否叠加、connector 带宽和 workload 的阶段比例来选择，不能仅凭模型是否冠以“统一”之名。

14. 验证：必须把端到端延迟拆成可归因部分

至少记录媒体下载/解码、encoder queue、encoder compute、transfer、LLM prefill、首 token、decode、下游生成和编码输出时间。吞吐同时记录 images/s、frames/s、audio seconds/s、LLM tok/s 和 completed jobs/s。显存记录各 stage 权重、KV、中间 tensor、workspace 与峰值。

缓存实验要报告命中层级与失效条件；并行实验要报告 GPU 型号、拓扑、batch/shape 和输入分布；模型质量要在相同 token budget、帧采样和输出配置下比较。否则“更快”可能只是少看了帧或降低了分辨率。

15. 局限：统一模型并没有统一成本函数

媒体 token pruning 可能丢失小字、短暂事件或音画对应关系；embedding cache 可能因模型升级产生静默错误；stage disaggregation 会引入序列化、传输和故障恢复；独立 batching 还会改变请求完成顺序。闭源模型通常不公开 encoder tokenization、训练数据和真实 stage 边界，因此只能依据模型卡说明输入输出，不能推断内部部署。

论文中的最大加速多是特定 workload 和 baseline。vLLM-Omni 的 91.4%、SEATS 的 4.8× 都不是任意模型上的普遍常数。系统选型必须回到自己的分辨率、帧数、并发、硬件和 SLO。

16. 最小复现与进一步阅读

第一步先复现媒体 token 与 prefill 成本，而不是直接搭建复杂 any-to-any 集群。SGLang 官方 benchmark 支持按图片数量和分辨率生成请求，可对同一 VLM 扫描 360p、720p、1080p 与多图输入：

python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-VL-3B-Instruct \
  --disable-radix-cache

python -m sglang.bench_serving \
  --backend sglang-oai-chat \
  --dataset-name image \
  --num-prompts 500 \
  --image-count 3 \
  --image-resolution 720p \
  --random-input-len 512 \
  --random-output-len 512

记录每档输入的 encoder time、TTFT、峰值显存和输出质量，再决定是否需要 token pruning、encoder cache 或 stage disaggregation。完整 any-to-any 复现应直接使用 vLLM-Omni 官方仓库当日文档，避免把快速变化的安装参数固化到本文。

本地前置材料：Qwen-VL 多模态输入、多模态 prefill/decode、多模态 KV cache。

17. 一手来源