03. 核心技术架构与关键论文 (Architecture)
本章我们拆解"如何让模型听懂键盘指令"以及"如何跑得比显卡还快"。我们将深入探讨 Tokenizer、Streaming Inference 和 Action Injection 的底层机制。
3.1 架构对比：视频模型 vs 游戏模型
从技术角度看，Sora 这类 Video Gen 和 Genie 3 这类“可交互 world model”存在本质差异。[来源]
| 组件 | 传统视频模型 (Video DiT) | 交互世界模型 (Game DiT) |
|---|---|---|
| 输入 Condition | Text Prompt, First Image | Control / Action signals（具体形式因系统而异）+ Past Latent |
| Tokenizer | 2D VAE (SDXL Style) | 3D 视频 Tokenizer（如 MAGVIT 系列等） |
| Attention | Spatial-Temporal (Full) | Causal Attention (Masked Future) |
| 推理模式 | Parallel Decoding (一次出全片) | Autoregressive Streaming (逐帧出片) |
3.2 深度解剖 1：视频 Tokenizer（以 MAGVIT 为例）
Genie 3 官方博客给出了 24 FPS / 720p / 分钟级一致性的体验级口径，但并未公开完整 tokenizer 细节。[来源]
不过从系统角度，要把“交互世界生成”推到实时，几乎绕不开一个工程前提：把连续视频压缩成更短的离散/低维表示（tokens/latents），否则序列长度和解码开销会直接把延迟打爆。这里用 MAGVIT (arXiv:2212.05199) 作为可追溯的代表性 tokenizer 路线做拆解。[来源]
flowchart LR
subgraph Input
Video[Raw 16 Frames]
end
subgraph Encoder [3D Causal CNN]
C3D1[Conv3D + Time Padding]
C3D2[ResBlock 3D]
end
subgraph Quantizer [VQ / Discrete Tokens]
Vector[Latent] -->|Nearest Neighbor| Codebook[(Codebook)]
Codebook --> Index[Token ID]
end
Input --> Encoder --> Quantizer
对交互世界模型来说，tokenizer 的价值不在“压缩比”本身，而在于把“像素级推理”变成“token 级推理”，把最重的计算从每一步都做的视觉生成里剥离出去。即使 Genie 3 的 tokenizer 细节未公开，24 FPS / 720p / 分钟级一致性这个公开口径也足以说明：它一定依赖了非常强的表示压缩与高效的流式推理工程。[来源]
3.3 深度解剖 2：实时流式推理工程 (Real-time Streaming)
光有模型不够，怎么让 Web 端的玩家感觉不到延迟？
1. KV Cache 极致优化
在 DiT 中，每一帧生成都依赖历史帧。如果你每次都重算历史帧的 Attention，延迟是 $O(N^2)$。必须引入 KV Cache (Key-Value Cache)，把过去几秒的显存特征存下来。
- Paged KV Cache: 像操作系统管理内存一样管理显存，防止碎片化。
- Window Attention: 只看最近 5秒（Sliding Window），丢弃太久远的记忆，换取 $O(1)$ 的推理复杂度。
2. 网络传输协议选择
| 协议 | 适用场景 | 延迟 | 评价 |
|---|---|---|---|
| HLS/DASH | 视频网站 | 5-30s | 不可用。等你看到画面，角色已经死了一万次了。 |
| WebSocket | 聊天室 | 100-500ms | 勉强可用。传输 Base64 图片可以，但带宽爆炸。 |
| WebRTC | 云游戏/Zoom | < 50ms | 唯一解。UDP 协议，允许丢包（画面花屏总比卡死强）。 |
sequenceDiagram
participant Player
participant Edge_Server
participant GPU_Cluster
Player->>Edge_Server: Action 'W' (UDP)
Edge_Server->>GPU_Cluster: Action Embedding
par Parallel Processing
GPU_Cluster->>GPU_Cluster: DiT Inference (Next Latent)
GPU_Cluster->>GPU_Cluster: VAE Decode (Next Frame)
end
GPU_Cluster->>Edge_Server: Raw RGB Frame
Edge_Server->>Player: H.264 Stream (WebRTC)
不要尝试自己用 Python Flask 写视频流。工程落地的关键是 WebRTC + GPU Encode。推理出来的 Frame 不要拷回 CPU，直接在显卡里用 NVENC 编码成 H.264，然后直接发包。做到 Zero-Copy，否则 PCIe 带宽会成为瓶颈。
3.4 深度解剖 3：动作注入机制 (Action Injection)
Matrix-Game 2.0 是如何让 DiT 理解 "W 键" 的？
- 分桶 (Binning): 把鼠标的
Delta X=120变成Mouse_Right_Fast这样一个离散 Token。 - Cross-Attention: 把动作 Token 当作 Prompt，注入到每一个像素的生成过程中。
目前的 Action Injection 还是"硬注入"。未来的方向是 Latent Action Learning (如 Genie 1)，让模型自己从视频里学会什么是"跳"，而不是人工标注 "Spacebar"。这样才能利用 YouTube 上无限的无标注视频数据。
3.5 关键论文详情 (Paper Deep Dive)
详见附录 参考文献页，那里有我对每一篇论文的"通俗翻译"和"毒舌点评"。
3.6 最新增量：超长流式生成的崩溃模式（sink-collapse）
当你把视频生成推到“分钟 → 小时”时，失败往往不再是画质问题，而是系统性崩溃：画面会在某些时刻突然回到“锚点帧”并开始循环。LoL (arXiv:2601.16914) 将这种现象命名为 sink-collapse，并给出一个训练无关的修复手段。
flowchart LR
A[超长流式生成: KV cache + 窗口注意力] --> B[引入 attention sink 帧稳定长程]
B --> C[失败模式: sink-collapse
画面回归 sink, 场景重置/循环]
C --> D[根因: RoPE 周期结构 × 多头注意力同质化]
D --> E[解法: multi-head RoPE jitter
不同 head 轻微偏移 base frequency]
E --> F[效果: 抑制 collapse, 支持更长 rollouts]
这条工作提醒我们：长时稳定性不只是“更大窗口/更多数据”，位置编码与注意力头的几何结构本身就会制造系统性崩溃。产品化上更关键的是把这些 failure mode 做成可监控指标：什么时候开始向 sink 回归？回归前有什么信号？这决定了你能不能做“提前纠错/重锚定”。
3.7 最新增量：从“生成视频”到“可执行系统”的统一序列建模
两个方向在迅速靠近“世界模型可执行化”的核心：
- 多轮编辑一致性：Memory‑V2V 把“上一轮编辑结果”作为显式外部记忆，通过检索与动态 tokenization 注入到扩散去噪，使视频编辑更像“多轮对话系统”。
- 视频模型变策略：Cosmos Policy 把 action / future state / value 统一编码成 latent frames，用视频扩散目标单阶段微调，测试时用 best-of-N + value 规划。
我把它们看成同一件事的两面：“把系统状态显式化”。Memory‑V2V 显式化的是“历史编辑状态”，Cosmos Policy 显式化的是“动作-未来-价值”。一旦状态能被读写，后续才有机会谈回滚、重锚定、规划与评测回归。
很多人以为把 Sora 的推理做快点就能变成游戏引擎，这是根本性的误判。Video Gen 的本质是 "In-painting"（填补像素），它默认可以看到未来的帧来推现在的帧。而 Game Gen 的本质是 "State Transition"（状态转移），你永远不知道玩家下一秒会按什么键。架构上必须强制 Causal Masking，否则模型会"偷看"未来，导致无法响应玩家当前的突发操作。