# 百万 token 上下文下的长视频理解

> 一段 1 小时、24 FPS 的 4K 视频，切 patch 并嵌入后，产出量级在 6000 万 token。一集 2 小时播客转录是 3 万 token。一部完整的蓝光电影，即便用激进池化压过，也是数十万 token。Google 的 Gemini 1.5（2024 年 3 月）以 1000 万 token 上下文开启了这个时代，能对一小时长的视频做可靠的大海捞针式召回。LWM（Liu 等人，2024 年 2 月）展示了 ring attention 的缩放路径。LongVILA 和 Video-XL 进一步放大了摄入。VideoAgent 用 agent 式检索换掉了原始上下文。每种路线在算力、召回和工程复杂度上都是不同的取舍。本节课把它们并排来读。

**类型：** Build
**语言：** Python（标准库，大海捞针模拟器 + agent 式检索路由器）
**前置要求：** Phase 12 · 17（视频时间 token）
**预计时间：** ~180 分钟

## 学习目标

- 在不同 FPS 和池化下计算长视频的总视觉 token 数。
- 解释三条缩放路径：硬上上下文（Gemini 1.5）、ring attention（LWM）、token 压缩（LongVILA / Video-XL）。
- 在准确率和延迟上把原始上下文视频 VLM 与 agent 式检索视频 VLM（VideoAgent）作比较。
- 为一段 30 分钟视频设计一个大海捞针测试，并测在某个具体分钟的召回。

## 问题背景

Qwen2.5-VL 大小的 patch 在 384 原生分辨率下单帧约 729 token。3x3 池化下每帧 81 token。一段 30 分钟片段 1 FPS = 1800 帧 = 145,800 token。2025 年的开放 VLM 能做，但紧。2 FPS 时 291,600 token——只有最大的上下文塞得下。

一部 2 小时电影 1 FPS 是 583k token。超出大多数 2026 年开放模型；需要 Gemini 2.5 Pro 或更激进地池化。

出现了三条缩放路径。

## 核心概念

### 路径 1：硬上上下文（Gemini 1.5、Claude Opus）

往问题上砸硬件。把上下文缩放到数百万 token，一次前向处理一切。

Gemini 1.5 Pro 以 1M token 发布；Gemini 1.5 Ultra 到 10M；2026 年的 Gemini 2.5 Pro 能可靠处理数小时视频。论文（arXiv:2403.05530）记录了在约 950 万 token 范围内 99.7% 的大海捞针召回。

工程：一个带内存层级（局部 + 全局 + 稀疏）的定制注意力实现，加上面向长上下文效率的 MoE 专家路由。未完整公开。不开源。

### 路径 2：ring attention（LWM、LongVILA）

ring attention 把长序列分布到设备的一个"环"上，每台设备持有一块。跨整条序列的注意力，靠每台设备按环形模式把自己那块发给下一台、算部分注意力、再聚合来完成。

LWM（Liu 等人，2024）就这么训了一个 1M token 上下文模型。训练算力随上下文线性增长，而非平方增长——注意力的平方代价被环上的设备摊销了。

LongVILA（arXiv:2408.10188）把这个模式适配到 VLM。1400 帧视频每帧 192 token = 268k 上下文，用 8 路并行的 ring attention 训练。

### 路径 3：token 压缩（Video-XL、LongVA）

比硬上上下文便宜：在 LLM 看到序列之前激进压缩。

Video-XL（arXiv:2409.14485）用一个视觉摘要 token：每段 N 帧的片段产出单个"摘要"token，它关注这 N 帧。推理时，LLM 每片段只看一个摘要 token，剧烈缩小上下文。

LongVA 用一个"长上下文迁移"技术把 LLM 上下文从 200k 扩到 2M。在长上下文文本上训练，经共享表示迁移到长上下文视频。

token 压缩用具体时间戳处的召回换可扩展性。模型大体知道发生了什么，但有时会错过确切帧。

### 路径 4：agent 式检索（VideoAgent）

不把整段视频喂给 LLM。而是把视频当成一个数据库，用 LLM 去查询它。

VideoAgent（arXiv:2403.10517）：

1. LLM 读问题。
2. LLM 向一个检索工具要相关片段（"给我有猫的片段"）。
3. 工具返回匹配的片段时间戳。
4. LLM 经一个 VLM 读那些片段。
5. LLM 组织答案，或提追问查询。

这是把 LLM-as-agent 模式应用到长视频。推理更便宜（只编码相关片段），工程更难（检索质量成了瓶颈）。

### 大海捞针基准

标准的长上下文测试：在视频的随机点插入一个独特的视觉或文本标记，然后问一个需要回忆它的查询。

指标：跨视频长度和标记位置的 Recall@k。

Gemini 2.5 Pro 在最长 90 分钟视频上拿到 >99% 召回。开放 72B 模型（Qwen2.5-VL-72B、InternVL3-78B）在 30 分钟时拿到约 85-90%，过 60 分钟后退化。

VideoAgent 在 2 小时以上能追平或胜过原始上下文模型，因为只要工具够好，检索就能命中那根针。

### 该挑哪条路径

15 分钟片段、前沿准确率：开放 72B + 原生上下文通常能行。挑 Qwen2.5-VL-72B。

30 分钟到 1 小时内容：开放选 LongVILA 或 Video-XL；闭源选 Gemini 2.5 Pro。质量门槛要紧——前沿走闭源。

2 小时以上内容：VideoAgent 或类似检索模式。或者摘要成更小的块，喂层级化摘要。

### 2026 年生产模式

实践中，生产长视频流水线是混合的：

1. 对整段视频跑动态 FPS 采样 + 激进池化（拿到一个 100k token 的全局表示）。
2. 传给一个 72B VLM 做全局摘要。
3. 若用户问细节问题，用摘要作索引跑 agent 式检索。

这把硬上上下文用于全局理解、检索用于局部细节结合起来。

## 实际使用

`code/main.py`：

- 在不同 FPS + 池化下，为 1 分钟到 3 小时的视频算 token 预算。
- 模拟一次大海捞针：在随机时间戳注入一个标记，问一个问题，给召回打分。
- 包含一个 agent 式检索路由器模拟器，挑出特定片段喂给下游 VLM。

跑那张预算表，感受规模差距。

## 拿去用

本节课产出 `outputs/skill-long-video-strategy-planner.md`。给定一个视频时长和查询复杂度，它在硬上上下文、压缩、agent 式检索之间挑选，并算出延迟 + 质量预期。

## 练习

1. 一段 45 分钟讲座 1 FPS、每帧 81 token。总 token？塞得进哪些模型的上下文？

2. 设计一个大海捞针测试：你在第几分钟注入标记，确切的查询格式是什么？

3. 在一段 1 小时视频上，把硬上上下文的 Qwen2.5-VL-72B（80k 上下文）与 VideoAgent（Claude 3.5 + 检索）作比较。谁在召回上赢？谁在延迟上赢？

4. ring attention 的内存成本随序列长度线性、随设备数线性。解释为什么，以及如果你去掉环形旋转阶段会崩什么。

5. 读 Gemini 1.5 第 5 节关于大海捞针的内容。论文在 1M vs 10M token 边界处关于召回有什么发现？

## 关键术语

| 术语 | 大家怎么说 | 它实际指什么 |
|------|-----------------|------------------------|
| 硬上上下文 | "就是更多 token" | 把 LLM 上下文缩放到数百万 token；一次前向处理一切 |
| ring attention | "LWM 式并行" | 每台设备持有一块并轮转的分布式注意力模式 |
| token 压缩 | "摘要 token" | 在进 LLM 前用一个学出的压缩器减少每片段 token |
| 大海捞针 | "NIH 测试" | 在随机点插入一个独特标记，测试时让模型回忆它 |
| agent 式检索 | "LLM 作查询规划器" | LLM 向检索工具要相关片段，经 VLM 读取，组织答案 |
| VideoAgent | "视频的检索模式" | 典范的 agent 式检索设计：问题 -> 工具 -> 片段 -> 答案 |

## 延伸阅读

- [Gemini Team — Gemini 1.5 (arXiv:2403.05530)](https://arxiv.org/abs/2403.05530)
- [Liu et al. — LWM / RingAttention (arXiv:2402.08268)](https://arxiv.org/abs/2402.08268)
- [Xue et al. — LongVILA (arXiv:2408.10188)](https://arxiv.org/abs/2408.10188)
- [Shu et al. — Video-XL (arXiv:2409.14485)](https://arxiv.org/abs/2409.14485)
- [Wang et al. — VideoAgent (arXiv:2403.10517)](https://arxiv.org/abs/2403.10517)
