多模态模型为什么更容易遇到上下文预算问题？
简化版
图像、视频和音频经编码后会展开成大量视觉/声学 Token，再与文本历史共享同一个上下文窗口。高分辨率图像按 Patch 数增长，视频还要乘帧数；因此一段媒体可能占掉数千到数万 Token，挤压问题、检索证据和输出预算。
解决要做任务感知预算：先给系统指令、用户问题和输出留硬预算，再按重要性选择分辨率、Tile、帧、音频片段和 OCR；使用视觉 Token 压缩、分层摘要、检索式选择或 Cross-Attention。不能简单均匀降采样，否则小字、短时事件和关键页面会先丢失。
详细版
total = system + conversation + retrieved_text
+ image_tokens + video_frames × tokens_per_frame
+ audio_tokens + output_reserve| 模态 | Token 增长因素 | 易丢信息 |
|---|---|---|
| 图像 | 分辨率/Patch/Tile | 小字、小对象 |
| 视频 | 帧数×单帧 Token | 短动作、状态变化 |
| 音频 | 时长/帧率 | 短事件、说话人切换 |
| 文档 | 页数+布局+OCR | 表格关系、页眉上下文 |
预算策略必须用真实任务评测：比较质量、视觉/音频覆盖、TTFT、显存和成本，并记录实际各模态 Token，避免只按原始字节估算。
完整版教学
1. 多模态 Token 从哪里来
图像被切 Patch 或 Tile，视频先采样帧再切 Patch，音频变成声学帧/压缩 Token，文档还可能加入 OCR 与布局。
这些表示最终要被 LLM 自注意力处理或被 Cross-Attention 读取，都会消耗计算与缓存。
2. 图像分辨率如何影响 Token
若图像高 H、宽 W，Patch 边长 P，基础 Token 数近似：
N_image ≈ ceil(H/P) × ceil(W/P) + special_tokens长宽各翻倍时 Patch 数约变四倍；动态 Tile 还会增加全局缩略图和重叠块。
3. 视频为何增长更快
视频 Token 约为帧数乘每帧 Token。10 分钟视频即使每秒只取 1 帧，也有 600 帧。
均匀抽帧会漏短时事件，全部高分辨率帧又不可承受，需要时间选择与空间压缩同时做。
4. 音频预算有什么特点
音频 Token 随时长增长，语音停顿和背景静音也可能被编码。VAD 可删除无声区，但不能误删轻声或环境事件。
长会议还要保留说话人与时间信息，单纯文本转录可能丢语气和非语音声音。
5. 预算应先保留什么
System/安全规则、用户当前问题和必要输出空间设硬保留；历史、检索和媒体使用剩余预算竞争。
| 优先级 | 内容 |
|---|---|
| 必保 | 系统边界、权限、当前问题 |
| 高 | 直接证据、关键媒体区域 |
| 中 | 相关历史、辅助帧 |
| 低 | 重复页面、静音、相似帧 |
不能让媒体 Token 截掉系统规则。
6. 为什么均匀压缩不够
重要信息分布不均：合同关键条款可能只在一页，视频事故只出现半秒，图片答案可能是角落小字。
任务无关降采样在平均场景看似有效，却会系统性伤害稀有证据。
7. 任务感知选择如何做
先用低成本全局编码/缩略图理解问题，再选择相关区域、页面、帧或音频段做高分辨率处理。
query -> coarse scan -> relevance scoring -> high-res evidence
-> answer with source coordinates/timestamps这类似多模态 RAG，需要验证召回而非只验证最终答案。
8. 视觉 Token 压缩方法
可用 Pooling、Token Merging、Perceiver Resampler、Q-Former 或学习式 Pruning，把大量局部 Token 压成固定数量。
固定瓶颈便于控制成本，但对复杂页面可能容量不足。可按图片复杂度动态分配 Token。
9. 分层表示有什么价值
保留低分辨率全局 Token用于场景与布局，再为候选区域加入高分辨率局部 Token，兼顾全局和细节。
文档可先做页级检索，再对命中页执行 OCR/布局；视频可先镜头切分，再选择关键帧。
全局 Token 不能被局部块完全替代，否则模型可能看清文字却失去页面/场景位置关系；两级表示需要共同携带坐标或时间编码。
10. 文本历史如何参与竞争
多轮对话引用前面的图片时，不能只删除媒体而保留“如上图”文本。历史摘要需保留媒体 ID、关键事实和来源区域。
缓存可复用未变化媒体编码，但上下文长度本身仍受模型架构限制。
11. Cross-Attention 能否解决
将媒体特征放在独立记忆中，由文本 Token Cross-Attend，可减少它们占用语言自注意力序列的方式，但媒体记忆仍有计算与显存成本。
架构是否支持由模型决定，不能在现有 Prefix VLM 上仅靠 Prompt 切换。
Cross-Attention 的复杂度仍随文本查询数与媒体记忆长度增长，KV/特征缓存也占显存；它改变预算形态，但没有消除预算问题。
12. 如何做预算算法
为每个候选片段估计 relevance、information_gain、token_cost 和 risk，做受约束选择：
maximize Σ value_i × select_i
subject to Σ tokens_i × select_i <= media_budget安全/权限项用硬约束，不参与普通价值竞价。
13. 如何评估与上线
按媒体数量、分辨率、时长和证据位置分桶，测答案、Grounding、召回、小字 OCR 和短事件检测。
性能记录各模态 Token、TTFT、峰值显存和成本；灰度监控截断率与“证据未进入上下文”失败。
多模态上下文管理不是平均压缩所有输入，而是把有限 Token 留给最可能决定答案的跨模态证据。
14. 常见误区与追问
- 误区：图片只算一个输入。 编码后可能是成百上千 Token。
- 误区：降低分辨率总能无损省 Token。 小字和小对象先丢失。
- 误区：视频均匀抽帧就足够。 短时关键事件可能落在采样点之间。
- 误区：只按原始文件大小预算。 关键是编码后的 Token 与架构。
- 误区：媒体太长就先截掉 System Prompt。 安全和权限规则必须硬保留。
- 追问：如何动态分配？ 粗粒度检索后对相关片段高分辨率编码。
- 追问：怎样验证预算策略？ 同时看证据召回、任务质量与真实 Token/性能。
15. 加强记忆
- 先算来源：文本、图像 Patch、视频帧、音频帧。
- 再记增长：图像随面积，视频再乘帧数。
- 再留硬预算：系统、问题、输出。
- 再做粗到细：全局扫描、相关区域高精度。
- 再做压缩：Merge、Resampler、Q-Former、Pruning。
- 再保关联：历史媒体 ID、坐标与时间戳。
- 最后评测：证据召回、长尾质量、Token 和 SLO。