Gemini 音视频 token 怎么控
Gemini 的视频按帧计 token：low 与 medium 同为每帧 70，high 为每帧 280；音频在各档位都是固定速率，不随 media_resolution 变化。（核验 2026-11-05，F51、F52、F105）
一、Gemini 音视频 token 怎么控：问题在帧，档位只管每帧预算
处理视频时最直觉的省钱办法是「把分辨率调低」。这个动作对静态图有效，对视频只对一半——因为视频不是按「一张图」算，而是按帧：档位决定的是每帧多少钱，不是总共多少帧。
官方的口径是这样：视频在 low 与 medium 两档都是每帧 70 tokens，只有 high 升到每帧 280（F51），而且 low 与 medium 在处理上是等价的（F52）。也就是说，从 low 调到 medium，一帧都不会省；从 medium 调到 high，成本立刻变成四倍。
音频是另一套逻辑：所有档位都是固定速率，media_resolution 对音频不产生作用（F105）。这一点经常被误解成「调到 high 音频识别更准」，实际调了没用，只是白写了配置。
二、Gemini 音视频档位成本：最小可运行示例
把「档位 → 每帧 token」写成表，倍数关系就能一眼看出。
## EXPECT: 同 1 帧：low=70 | medium=70 | high=280 | high/low 倍数=4 | 混用 high+low=各段相加 | 音频不随档位变
PER_FRAME = {"low": 70, "medium": 70, "high": 280}
FRAMES = 1
def frames_cost(level):
return FRAMES * PER_FRAME[level]
def mixed_cost(items):
return sum(frames * PER_FRAME[level] for level, frames in items)
assert frames_cost("low") == frames_cost("medium")
assert frames_cost("high") == PER_FRAME["high"] * FRAMES
assert mixed_cost([("high", FRAMES), ("low", FRAMES)]) == PER_FRAME["high"] + PER_FRAME["low"]
print(f"同 {FRAMES} 帧：low={frames_cost('low')} | medium={frames_cost('medium')} | "
f"high={frames_cost('high')} | high/low 倍数={PER_FRAME['high'] // PER_FRAME['low']} | "
f"混用 high+low=各段相加 | 音频不随档位变")
注意 low 与 medium 那一行断言：它不是笔误，是官方把两档做成等价的直接后果（F52）。如果你的代码里写了「默认用 medium，比 low 好一点」，那多出来的只是心理安慰，账单一分不省、效果一分不涨。
三、解释与边界：三条能算的，一条不能算的
能算的第一条：档位倍数。 视频从 low／medium 切到 high，每帧预算乘四（F51）。这里的计算只涉及帧，不涉及秒——因为把秒换算成帧需要 FPS，而官方没有给出通用的换算口径。
能算的第二条：帧数。 决定总成本的另一半是「进来了多少帧」。同一段视频，抽帧策略不同，成本差几倍。所以真正有效的降本手段往往不是调档位，而是减少送进去的帧：只喂关键片段、只取首尾、或用摘要代替全片。
能算的第三条：混用档位。 Gemini 4 与 Gemini 3 支持按单个媒体对象设分辨率（F106）。一个请求里可以给复杂图表 high、给背景图 low，没必要整段统一。这比全局调档位精细得多。
不能算的那条：音频的每秒 token 数。 官方两页给了不同的数——一页写 32 tokens/s，另一页写 25 tokens/s（F50，待核）。两处都是官方原文，数值互相矛盾，官方也没有说明适用范围；在官方澄清前，这两个数都不能用于预算。所以本教程的处理是：只写「音频固定速率、不随档位变」，不给每秒换算公式。看到别处给出「一分钟音频等于多少 token」的精确算法，先弄清它引的是哪一页。
还有一个容易混淆的概念：media_resolution 管「每帧预算」，processing 管「加载什么内容」，两者独立起作用（F53）。调前者不等于改了后者，反之亦然。默认值是 unspecified（F52），不显式设置就按模型默认走。
帧数从哪来，决定了成本的大头。 帧数由你的抽帧策略决定，不由模型决定。同一段十分钟的视频，逐秒抽帧和只取关键片段，进来的帧数可能差两个数量级。所以优化顺序应该是：先减帧，再调档位——前者是数量级，后者最多四倍。
音频不能靠降档位省钱。 固定速率意味着这条路上没有旋钮。能做的只有两件：减少送进去的时长（切出真正需要的那一段），或者先用语音转写把音频变成文本再送。后者会损失语气与停顿信息，所以要看任务是否依赖这些——客服质检依赖，纯摘要不依赖。
混用档位之后要能记账。 按媒体对象设分辨率很方便，但事后核算要说得清「哪个对象用了哪档」。最简单的做法是在构造请求时就把档位和 uri 一起写进日志。否则你只能看到一个总数，说不清是哪一段贵。
落到选择上，其实只有三句话。 看得清画面与文字就够用的场景，用 low 或 medium（视频这两档同价，随便挑一个）；要读密集表格、小字标注，才升到 high；音频不用挑档位，挑了也不生效。把这三句写进团队规范，比让人每次现场判断更可靠。规范的价值在于：下次有人问「这条视频该用哪档」，答案不依赖谁在场。
档位可配，抽帧常常写死。 前者在请求参数里，随时能调；后者的逻辑往往埋在处理管线里，没人记得当初为什么这么抽。真要做成本治理，先去看那段抽帧代码——它比任何参数都更能决定账单。
边界。 本节只谈视频与音频的 token 口径。PDF 与图片按页与块计，见 8.2；文件走内联还是上传，见 8.1。本节也不评价哪一档「效果更好」——那依赖你的任务类型，没有通用答案。
四、预期输出与异常分支
真跑输出：
同 1 帧：low=70 | medium=70 | high=280 | high/low 倍数=4 | 混用 high+low=各段相加 | 音频不随档位变
六类分支。以为 medium 比 low 省：两档等价（F52），改配置不改账单。以为调高音频档位更准：音频是固定速率（F105），这条配置对音频无效。用 FPS 公式硬算总 token：官方没给通用换算，且音频速率本身两页冲突（F50），算出来的数不可信。全片统一 high：成本是 low 的四倍（F51），而多数帧并不需要这个精度。混用档位后忘了记录：排查成本时说不清哪一段用了哪档，日志里要记下每个媒体对象的档位。把 processing 当分辨率用：两者独立生效（F53），改错了不报错，只是效果与预期不符。
五、判据卡：什么时候该升到 high
| 该这么做 | 不该这么做 |
|---|---|
| 只给需要看清细节的片段用 high | 全片统一 high |
| 按媒体对象分别设档位 | 一个请求只能一个全局档位 |
| 降本优先减帧数 | 只在档位之间来回调 |
| 音频只算固定速率，不给每秒公式 | 用 32 或 25 套算总账 |
六、来源与核验
https://aistudio.google.com/docs/media-resolution.md（核验 2026-11-05，F51、F52、F53、F105、F106）https://aistudio.google.com/docs/tokens.md（核验 2026-11-05，F49、F50）
档位与每帧 tokens 属于「价格」档事实，复核周期一个月，见 1.3。音频速率冲突（F50）在官方澄清前保持待核状态，正文不写绝对换算——这是本教程对矛盾事实的统一处理方式。
七、动手试
- 把
FRAMES改成2，重跑。预期三档数值都翻倍，倍数关系不变；验收标准是你能说清「为什么倍数不受帧数影响」。 - 给
frames_cost加一个按媒体对象指定档位的版本：输入[(level, frames), ...]，返回总 token。验收标准：一段 high 片段加一段 low 片段的结果，等于两段分别算完再相加。 - 打开你项目里的视频处理代码，找一下有没有抽帧策略。验收标准：能给出「一段典型视频送进去多少帧」；给不出来，说明成本是被默认行为决定的，不是被设计决定的。