模型图、模态状态与输出 codec

1. 模型图是 runtime 的输入，不是宣传图

任何模型都能被画成“输入 -> neural network -> 输出”，但这张图对部署没有帮助。runtime 需要的是能回答四个问题的图：哪个节点可独立组批；哪条边跨越设备或进程；边上传的是可复用状态还是一次性结果；以及输出何时达到可交付状态。只有这些问题有答案，调度器才知道什么时候分配 KV 页、什么时候等待 codec、什么时候释放 latent。

在文本 decoder-only 模型中，常把 token 与 KV cache 当成足够的描述。any-to-any 模型破坏了这个简化：图像 encoder 的连续 feature 既不是词表 token 也不是历史 KV；diffusion 的噪声 latent 需要跨 denoising step 保留；语音 codec 的多 codebook 索引不是文本 token；实时会话还要保存未消费输入、播放进度和打断水位。

因此，本文将“模型图”限定为从公开材料可观测到的功能节点和有类型的边。它允许 runtime 设计者做资源分析，同时不把教学抽象冒充成某个研究团队的逐层实现。

2. 六类状态：名字相近，生命周期完全不同

状态	典型生产者	典型消费者	可否跨请求复用	主要风险
文本或离散模态 token	tokenizer、AR decoder、离散 tokenizer	embedding、AR decoder、detokenizer	原始内容可去重；生成历史通常只限本请求	顺序、词表/码本版本和位置编码不匹配
KV cache	Transformer 各层 prefill/decode	同一模型、同一层的后续 attention	仅在严格 prefix、模型和位置语义一致时	HBM 常驻、页表、跨租户或跨版本误命中
媒体 feature	图像、音频、视频 encoder	projector、fusion 或 LLM backbone	内容、预处理和 encoder 版本一致时可能	分辨率、帧率、时序位置和大 tensor 传输
连续 latent	VAE、随机初始化、上游生成器	DiT/UNet、VAE decoder	通常不应跨随机请求复用	每步读写、噪声日程、显存与中断恢复
音频 codec code	audio tokenizer、talker 或 codec predictor	codec decoder、vocoder、文本/语音联合模型	取决于 codec、采样率和声学上下文	码本顺序、帧率、jitter 与可播放边界
session state	会话控制面、流处理器、应用	下一轮输入、取消/续传、双工控制	仅同一受控会话；须有明确保留策略	泄漏、错误恢复后孤儿状态、时间轴漂移

这六类可同时存在于一次请求中。例如音频输入先成为连续 feature，随后在 thinker 内部影响 KV；输出端先出现文本 token，又由 talker 产生 codec code，最终才有 waveform。把它们全归为“token cache”会让缓存键、容量估算和故障清理都失去语义。

3. token、feature、latent、code 与 KV 的精确区别

token是有离散 ID 或可被统一序列模型按位置消费的符号；文本 BPE ID 和 AnyGPT 的离散模态表示属于这一类。媒体 feature是 encoder 输出的连续向量序列，通常还需 projector 对齐到语言 backbone 的 hidden dimension。latent是生成模型工作空间中的连续变量，例如 VAE latent 在 diffusion 的多个时间步反复被更新。codec code是量化后的声学/语义码本索引，能作为序列建模目标，但只有配套 decoder 才能变回声音。KV则是 Transformer 每层针对已有序列位置的 attention 中间状态，不是输入内容的通用 embedding。

令 batch 为 \(B\)，某媒体有 \(L_m\) 个时间或空间位置，encoder 维度为 \(d_m\)，语言模型 hidden dimension 为 \(d\)。典型的 feature 对齐可写为 \[ X^{(m)}\in\mathbb{R}^{B\times L_m\times d_m},\qquad H^{(m)}=X^{(m)}W_m\in\mathbb{R}^{B\times L_m\times d}. \] 这里 \(W_m\) 是 projector 或更复杂 adapter 的抽象。它说明 feature 已是连续张量，不意味着它有文本词表 ID。若将 \(H^{(m)}\) 拼入 sequence，后续各 Transformer 层才为这些位置建立相应的 KV。

系统设计中最危险的混淆是把“可序列化”为“可安全复用”。所有状态都能写入字节流，但只有内容、版本、位置、随机性和权限域都匹配时，复用才保持模型语义。反过来，某个状态很大也不代表必须跨网络传输，合适的 device placement 可能让下游在同一 GPU 上直接消费它。

4. 真实模型谱系：同为 any-to-any，不是同一种图

模型	公开的核心图式	runtime 首要状态	不能由名称推出的事情
NExT-GPT	多模态 adapter 将 LLM 与输入 encoder、输出 diffusion decoder 相连	媒体 feature、LLM KV、输出控制与生成 latent	每个 decoder 的实时性、并行方式和部署支持
AnyGPT	多模态内容先变为统一离散序列，再做 next-token prediction	离散 code、LLM KV、detokenizer 上下文	离散化不会消除音频/图像重建成本
Transfusion	单 Transformer 同时处理离散文本与连续图像，并结合 AR 与 diffusion	文本 KV、连续图像 latent、denoising step	“单模型”不等于单一 decode loop
BAGEL	统一的交错多模态理解与视觉生成/编辑能力	backbone 状态和视觉生成支路状态	shape 只采用论文和仓库明确给出的值
Qwen3-Omni	MoE Thinker–Talker 与多 codebook 实时语音方向	媒体 feature、thinker/talker 状态、codec code	不同 checkpoint 是否都带 talker/流式输出
Ming	专用 encoder -> Ling MoE 与模态 router -> 感知/生成	媒体 token/feature、MoE 路由与图像/声学生成状态	原始 Ming-Omni 与后续 Flash 版本的组件不能混用
MiniCPM-o / Moshi	面向在线输入输出、隐藏状态或 codec 多流交错的实时对话	时间对齐的流、KV、codec code、会话水位	“streaming”自动等于任意时刻无损打断

表中的图式来自各自论文与官方仓库，不是性能排名。它说明调度器应从状态类型开始分类，而非先按“视觉模型”“语音模型”选一个固定 backend。

5. NExT-GPT：LLM 作为枢纽，外接理解与生成分支

NExT-GPT 的论文与官方仓库明确把多模态 LLM 放在中间：输入侧通过多模态 encoder 和 adapter 把图像、视频、音频等信号接入；输出侧通过 adapter 与不同的 diffusion decoder 生成相应模态。它是理解“any-to-any 不必是一个统一原生 token space”的好起点：语言模型可以是决策枢纽，感知和生成则保留为模型专用分支。

image / video / audio
        | encoder + input adapter
        v
interleaved representations -> LLM (text + control) -> output adapter -> modality-specific diffusion decoder
                                  |                                      |                         |
                                  +-> text tokens / KV                    +-> condition             +-> latent -> media

对应的 runtime 合同至少有四种边：输入 media feature、LLM 的 token/KV、输出 adapter 的条件表示、diffusion 的连续 latent。后两者不能用普通文本 prefix cache 代替。若需要同时生成文字和图像，文字可在 AR 分支早到，而图像要等去噪与 decoder；API 应暴露两个不同 output stream，而不是人为等待慢分支后再返回一个“回答”。

6. AnyGPT：统一离散序列不等于统一的物理输出

AnyGPT 的官方定义是将语音、文本、图像和音乐转换为统一离散表示，用 next-token prediction 做统一训练，并支持模态间转换。这条路线将更多边变成离散 sequence：模型主体可使用统一的自回归、KV 和采样抽象，跨模态 interleaving 也更自然。

audio / image / music -> modality tokenizer -> discrete code sequence --+
text ---------------------------> text tokens ----------------------------+-> unified AR LLM -> code/text sequence
                                                                              |                         |
                                                                              +-------------------------+-> modality detokenizer / decoder

然而离散 code 仍需要明确的 codec 身份。不同 codebook 数、码率、采样率或 tokenizer 版本会使相同整数序列失去意义；输出端 detokenizer 也有自己的 GPU、CPU 或实时预算。因而可以为离散序列做 KV 和 batch 调度，但不能把“整数 ID”误当成“已经可以播放或显示的媒体”。

7. Transfusion：离散文本和连续图像在同一 Transformer 中共存

Transfusion 提出在一个多模态 Transformer 中结合 next-token prediction 与 diffusion：文本按离散 token 的自回归目标处理，图像保留连续表示并按 diffusion 目标处理。论文还讨论在混合模态序列上训练与用模态专用编码/解码层改善表现。这一图式比“把图像量化成词表 ID”更直接地保留了连续 latent 的多步演化。

text tokens -----------------------------> mixed Transformer -> next text token
image encoder -> continuous image patches -> mixed Transformer -> denoising update at step s
                                                               -> ... repeat s = S ... 1 -> image decoder

部署上，文本 AR 分支的核心长期状态是 KV；图像分支的核心长期状态则是当前连续表示、noise schedule、step index 和可能的 conditioning。即使两者复用一个 Transformer 权重，batch 的适合 shape、迭代次数和完成条件依然不同。把它建模成两个相关 stage 或一个具有两种 workload class 的 stage，取决于公开实现是否允许独立排队和设备放置；不能仅由“single model”字样决定。

8. BAGEL：统一理解和视觉生成，参数按一手来源登记

BAGEL 官方仓库和报告将其描述为在大规模交错多模态数据上训练的开源基础模型，公开的 BAGEL-7B-MoT checkpoint 具有 14B 总参数、7B active 参数，并覆盖多模态理解、文本到图像、编辑和其他视觉生成任务。对 serving 来说，重要结论是同一请求可沿着理解文本支路或视觉生成/编辑支路走向不同终端，而非它是否拥有一个营销意义上的“统一”标签。

interleaved text + image representations
                |
                v
          BAGEL backbone / MoT
             |              |
             v              v
   understanding text    visual generation or editing branch
             |              |
       text output      image-generation state -> decoded image

上图有意把未在当前公开材料中固定的 latent shape、VAE 版本、scheduler 和具体层间 payload 标作“visual generation state”。这些信息若要进入 connector、缓存页或 CUDA graph 配置，必须从目标 checkpoint 的官方配置和代码读取。推断“BAGEL 必然使用某个常见 VAE 或某种 diffusion step 数”会把别的模型的实现细节写进错误合同。

9. Qwen3-Omni：Thinker–Talker 把推理和语音输出拆开

Qwen3-Omni 技术报告描述了 MoE Thinker–Talker 架构：模型接收文本、图像、音频和视频，面向文字与自然语音输出；报告还说明多 codebook 表示可使语音路径从第一 codec frame 开始流式，替代更重的 block-wise diffusion。官方仓库则明确区分了带 thinker 和 talker 的 Instruct、只含 thinker 的 Thinking 等变体。因此，模型名称本身不构成“任何 checkpoint 都有语音 output”的证据。

text / image / audio / video -> modality preprocessing + encoders -> Thinker MoE
                                                               |              |
                                                               |              +-> text stream
                                                               v
                                                        Talker MoE
                                                               |
                                                        multi-codebook sequence
                                                               |
                                                    streaming codec decoder -> audio stream

此图提示至少有三种不能混用的缓存：Thinker 的长上下文 KV，Talker 的生成历史或 KV，以及 codec decoder 的帧边界状态。若 thinker/talker 被放在不同 GPU 或进程，连接器也要知道传的是隐藏条件、离散 code 还是最终 PCM；这三种 payload 的字节数与重试语义完全不同。

10. Ming：专用感知入口、MoE 路由与版本化的生成支路

Ming-Omni 论文说明它用专用 encoder 从图像、文本、音频和视频提取 token，再交给带模态特定 router 的 Ling MoE 处理，并支持语音与图像生成。这个图有两个系统含义：输入阶段不能假设所有模态已经是语言 token；MoE 的 token dispatch 也不是普通单卡 decoder 的局部实现细节，可能影响专家放置和通信。

image / text / audio / video -> dedicated encoders -> modality tokens/features
                                                       |
                                                       v
                                            Ling MoE + modality-specific routers
                                                 |                       |
                                                 v                       v
                                           perception/text       speech and image generation paths

官方 Ming 仓库还描述了后续 Ming-flash-omni 2.0 的版本性设计：用于统一声学生成的连续自回归加 DiT head，并提供图像、文本、音频输出。这里必须保留版本界线：2025 的 Ming-Omni 论文与 2026 的 Flash 2.0 不是可随意互换的配置。runtime 的模型适配器应把 checkpoint、编码器、router 和输出 head 绑定为一个不可拆散的 capability descriptor。

11. MiniCPM-o 与 Moshi：在线时间轴是模型状态的一部分

MiniCPM-o 4.5 官方说明将模态 encoder/decoder 与 LLM 通过 hidden states 做端到端连接，并把离线 encoder/decoder 改造成在线、全双工形式。其语音 token decoder 交错地建模文本和语音 token；TDM 机制按毫秒时间线把并行输入/输出流划成小的顺序信息组。换言之，运行时除了保存模型状态，还必须保存每路输入已到哪里、每路输出已生成和已播放到哪里。

Moshi 是更聚焦语音的对照：论文和官方仓库说明它是使用流式 Mimi neural audio codec 的全双工 speech-text foundation model。Moshi 的多流语音与并行文本表示说明“语音 token”可以有不同的流和码本职责；会话系统必须保留对齐关系，不应只把音频当一段上传文件。

live video/audio chunks -> online encoders --+
                                             time-aligned hidden state / codec streams -> dialogue backbone
text and speech output <--------------------+                                      |
                                                                                     v
                                                    interleaved text + speech codes -> streaming decoder -> playable chunks

全双工的最小状态除了 KV 和 codec history，还包括输入 watermark、输出 sequence number、播放水位、turn-taking 或 interruption 决策，以及当前 session 的 ownership。它们通常不能进入全局 prefix cache，更不应在连接断开后无期限保留。

12. 从模型图推导 stage shape

shape 不是“张量有几维”的小问题，而是 batch 能否合并、通信是否昂贵和 CUDA graph 是否稳定的前提。设 \(B\) 是 batch，\(T\) 是文本位置数，\(F\) 是音频帧数，\(N\) 是视频帧数，\(P\) 是每帧视觉 patch 数，\(d\) 是投影后的 hidden dimension，\(Q\) 是一个音频帧的 codebook 数。常见的抽象形状如下：

\[ \begin{aligned} H_{\mathrm{image}} &\in \mathbb{R}^{B\times P\times d}, \\ H_{\mathrm{video}} &\in \mathbb{R}^{B\times N\times P\times d}\ \text{或}\ \mathbb{R}^{B\times (NP)\times d}, \\ H_{\mathrm{audio}} &\in \mathbb{R}^{B\times F\times d}, \\ C_{\mathrm{audio}} &\in \{0,\ldots,K-1\}^{B\times F\times Q}, \\ Z_{\mathrm{image}} &\in \mathbb{R}^{B\times C\times H\times W}. \end{aligned} \] 前三行是投影后的媒体 feature，第四行是码本大小为 \(K\) 的离散 codec code，第五行是常见图像 latent 的抽象形状。具体模型可能采取其他排列、动态分辨率或压缩策略；公式用于命名维度，不能替代其配置文件。

同一逻辑请求还会产生按层分块的 KV。例如层数为 \(n_\ell\)、KV head 数为 \(n_h\)、head dimension 为 \(d_h\) 时，KV 的长轴首先随有效 sequence length \(L\) 增长，而不是随音频原始字节数直接增长。视频和音频在送入 backbone 前究竟压成多少位置，常常比原始文件大小更能决定 KV 容量。

13. 从 shape 推导速率：帧、token 与 step 不能直接相除

每类 state 有自己的时钟。若音频采样率是 \(f_s\)，codec hop 是 \(h\) 个采样点，则 codec 的理论帧率为 \(f_s/h\)；每帧有 \(Q\) 个 codebook 时，离散 code 的符号产生率与 \(Qf_s/h\) 成正比。文本 token/s 不可直接和它比较，除非知道 talker 需要多少计算才能生成一帧和 decoder 需要多少帧才能产生可播放 chunk。

\[ r_{\mathrm{frame}}=\frac{f_s}{h},\qquad r_{\mathrm{code}}=Q\,r_{\mathrm{frame}},\qquad r_{\mathrm{media\ positions}}=\frac{L_m}{\Delta t}. \] 这里 \(r_{\mathrm{frame}}\) 是 codec frame/s，\(r_{\mathrm{code}}\) 是 code symbol/s，\(L_m\) 是在时长 \(\Delta t\) 内送入 backbone 的媒体位置数。它们是容量建模的单位换算，不是任何特定模型公开的码率。

diffusion 还增加 step 时钟：一张图的完成时间取决于每步计算、所需步数、latent shape、条件编码和 decoder，而不是 AR token rate。可以在同一个请求中同时报告 text TTFT、first-audio-frame time 与 image completion time，但不应该选其中最快的一个冒充端到端延迟。

14. 驻留：哪些状态应留在 HBM，哪些可作为边上传输

每条边都要做一个 placement 决策。后续 attention 会在每个 decode iteration 重复读取的 KV 通常应留在执行该 decoder 的 HBM；只被下游消费一次的 encoder feature 可以在同机直接引用、在节点间 zero-copy/高速传输，或重算，取决于尺寸、复用次数和网络。diffusion latent 通常在连续 step 中原地更新，跨节点迁移会破坏 pipeline overlap；codec code 较小但对顺序和实时性敏感，常适合按小 chunk 流动。

若某 payload 有 \(n\) 个元素、每元素 \(b\) bytes，则其裸数据量为 \(M=nb\)。跨一条可用带宽为 \(W\) 的边传输时，忽略排队后的下界为 \[ T_{\mathrm{transfer}}\ge \frac{M}{W}. \] 对 KV 的粗略容量写作 \[ M_{\mathrm{KV}}\approx B\,L\,n_\ell\,2\,n_h\,d_h\,b, \] 其中系数 \(2\) 对应 key 与 value。真实容量还受 GQA/MQA、量化、分页、对齐、压缩和工作区影响，因此不能把这个教学式当作某模型的显存测量。

状态驻留也决定故障成本。若唯一副本只在某张 GPU 的临时 buffer，stage 重启就要从上游重算；若把每个中间量都持久化，存储和隐私成本又会压垮系统。正确的策略应由 payload 可重算性、生成随机性、客户端已收到多少结果和恢复 SLO 决定。

15. 传输合同：tensor 内容之外，还必须传元数据

将 GPU tensor 从 stage A 交给 stage B，至少要携带 request_id、payload type、shape、dtype、layout、设备/内存所有权、模型和 tokenizer/codec 版本、位置或时间范围、sequence number 与终止标志。对远程传输还需要校验、超时、是否允许重试和已消费确认。只传一个 torch.Tensor 句柄时，这些语义常被隐含在进程假设里，一旦扩展到多机或恢复就会出错。

对于 session state，合同还应包含 tenant、session epoch、turn ID、保留期限和取消代数。session state 不是模型 KV 的同义词：它可能指向 KV、媒体缓存和输出历史，但应该有控制面拥有者，且在用户结束会话或 policy 要求删除时可枚举地释放。

传输优化的前提：零拷贝、shared memory、CUDA IPC、NCCL 或远程对象存储只优化“怎样搬”。它们不解决“能否搬、搬的是否是正确版本、下游是否仍需要它、失败后谁释放它”这些合同问题。

16. 从状态图到 scheduler 的直接约束

模型图一旦写清，就能得到可实施的 scheduler 约束：AR stage 按活跃 sequence、KV 页和 token budget 准入；encoder stage 按媒体长度、分辨率或帧窗口组 batch；diffusion stage 按 latent shape、step 和条件组 batch；codec/vocoder stage 按 chunk 时长与播放 deadline 组 batch。所有阶段共享的是 request deadline、取消和资源配额，不是一个虚假的统一 token budget。

同一个输入可复用的 feature cache、可复用的文本 prefix cache 和不可跨请求复用的 live-session buffer 应分开度量与淘汰。跨阶段边也应计入端到端 tracing：若 TTFAS 变差，需要能区分是 audio encoder 堵塞、thinker 未给出条件、talker 速率不够、codec decoder chunk 太大，还是客户端网络抖动。

后续的 vLLM-Omni 与 SGLang-Omni 页面将把这些抽象映射到各自的配置、stage、scheduler 和 relay 代码。这里不先判定谁“更快”；没有固定模型、版本、硬件、输入分布和 SLO 的比较不具备解释力。

17. 一手来源与版本边界

以下链接是本页模型图的主要证据。来源页面描述的是各自论文或当前官方仓库的公开版本；没有找到明确说明的 tensor shape、输出格式或部署拓扑，本页均保留为未确定，而不以常见实现补全。