变的是「谁来决定看什么」
旧做法是静态的：按固定帧率把整段视频采样进来，默认 1 FPS，开发者可以通过 API 调。问题在长视频上很直接——一段 90 分钟的讲座按 1 FPS 就是 5400 帧，要么付高昂的 token 费用，要么用各种降采样技巧，而后者经常把关键细节丢掉。 新做法把决定权交给模型：它把自身推理和原生视频工具配合起来，动态地搜索、扫描、检视目标片段，并在视觉帧、音频和字幕之间选用合适的模态。也就是说，模型会先判断"这个问题该看哪儿"，再去看那一段——而不是先把整段看完再回答。 这个改动的性质更接近检索而非压缩：省下来的不是画质，是根本没被载入的那部分内容。
数字和它的适用条件
官方给的是：在标准视频分析基准上，分析成本最多降 66%、token 消耗最多降 88%，同时准确率最多提升 7%。收益在长视频上最明显——从 10 分钟的教程到 90 分钟的讲座再到数小时的录像。 计费文档里写得更实在：token 用量按模型载入的内容变化，而不是按视频总长，长视频通常能少用最多 88% 的输入 token；但具体数量取决于查询复杂度和动态采样深度，遇到需要细看的视觉片段时采样率可能超过 1 FPS。换句话说，88% 是上限不是均值，账单会随问题的难度浮动——问「这段视频讲了什么」和问「第 47 分钟那个人手里拿的是什么牌子」，成本不会一样。
怎么开，以及需要注意的
在 Google AI Studio 或 Gemini Enterprise Agent Platform 里把 API 配置设成 agentic 即可启用，标注为生成式 AI 预览，不收额外功能费。Gemini 应用端标注为「即将」，YouTube 观看页的 Ask YouTube 标注为未来几个月。 社区反应是分化的：一部分人认为 88% 的 token 削减让长视频分析第一次变得实际可行、成本可接受；另一部分则质疑这些模型本身的可靠性，认为谷歌应该先解决基础质量问题。这个分歧点其实指向同一个测试重点——动态采样意味着模型可能"没看到"某个关键帧，而静态采样至少是可预测的。要评估的话，值得专门构造一批"答案只出现在某一两帧里"的用例，看它跳不跳得准。 对做视频类应用的团队，这条的实际含义是成本结构变了：以前预算按视频时长估，现在得按查询类型估。上线前把典型查询跑一遍拿到实际 token 分布，比套用 88% 这个数字靠谱。