百万 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）：
- LLM 读问题。
- LLM 向一个检索工具要相关片段（"给我有猫的片段"）。
- 工具返回匹配的片段时间戳。
- LLM 经一个 VLM 读那些片段。
- 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 年生产模式
实践中，生产长视频流水线是混合的：
- 对整段视频跑动态 FPS 采样 + 激进池化（拿到一个 100k token 的全局表示）。
- 传给一个 72B VLM 做全局摘要。
- 若用户问细节问题，用摘要作索引跑 agent 式检索。
这把硬上上下文用于全局理解、检索用于局部细节结合起来。
mm-video-token-budget实际使用
code/main.py：
- 在不同 FPS + 池化下，为 1 分钟到 3 小时的视频算 token 预算。
- 模拟一次大海捞针：在随机时间戳注入一个标记，问一个问题，给召回打分。
- 包含一个 agent 式检索路由器模拟器，挑出特定片段喂给下游 VLM。
跑那张预算表，感受规模差距。
拿去用
本节课产出 outputs/skill-long-video-strategy-planner.md。给定一个视频时长和查询复杂度，它在硬上上下文、压缩、agent 式检索之间挑选，并算出延迟 + 质量预期。
练习
一段 45 分钟讲座 1 FPS、每帧 81 token。总 token？塞得进哪些模型的上下文？
设计一个大海捞针测试：你在第几分钟注入标记，确切的查询格式是什么？
在一段 1 小时视频上，把硬上上下文的 Qwen2.5-VL-72B（80k 上下文）与 VideoAgent（Claude 3.5 + 检索）作比较。谁在召回上赢？谁在延迟上赢？
ring attention 的内存成本随序列长度线性、随设备数线性。解释为什么，以及如果你去掉环形旋转阶段会崩什么。
读 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 式检索设计：问题 -> 工具 -> 片段 -> 答案 |