从视频里抽帧经一把 key 发出去：各视觉后端到底收几张图、怎么算 token

为什么视频抽帧任务容易悄悄丢帧

视频摘要、内容审核等场景常需要从视频中抽帧，再作为图片负载发送给视觉模型。许多开发者使用一个聚合 API key 同时调用多个后端（如 Claude、GPT、DeepSeek、Qwen、GLM、Kimi 的视觉版本）。但不同后端对图片数量、单图尺寸和 token 计算方式有不同限制，如果不加注意，请求可能被静默截断——只处理了前几张图片，或者图片被压缩到模型无法识别细节的程度。

抽帧策略：先决定抽多少、抽哪几帧

抽帧不是越多越好。过多的帧会迅速耗尽上下文窗口，增加成本，也可能触发后端的图片数量上限。常见的策略包括：

• 等间隔抽帧：按固定时间间隔抽取，适合内容变化平缓的视频。
• 场景切换抽帧：检测画面显著变化时抽帧，适合剪辑密集的视频。
• 关键帧抽帧：利用视频编码中的 I 帧，但可能遗漏中间变化。

建议先根据视频时长和目标摘要粒度确定总帧数上限，再均匀分布。例如，对于几分钟的短视频，抽取 8-16 帧通常足够；长视频可适当增加，但需检查后端限制。

图片负载上限：各后端差异巨大

不同视觉模型对单次请求的图片数量、单图分辨率、图片格式和总负载大小有不同约束。常见限制维度包括：

• 图片数量：部分后端限制单请求最多 N 张图片，超出可能报错或直接忽略。
• 单图尺寸：过大的图片会被缩放，可能丢失细节；过小的图片可能无法识别文字。
• 总 token 数：图片 token 会计入上下文，与文本 token 共享窗口。

由于聚合站统一转发，你无法直接看到每个后端的原始错误。建议在客户端主动限制图片数量和尺寸，并在响应中检查是否所有图片都被处理（例如通过要求模型引用每张图片的序号）。

图片 token 计法：没有统一标准

图片 token 的计算方式因模型而异，主要分为几类：

1. 按图片数量固定计费：无论图片大小，每张图消耗固定 token 数（如低细节模式）。
2. 按分辨率分块计费：将图片切分为若干块（tile），每块消耗固定 token，总 token 与图片面积相关。
3. 按尺寸缩放后计费：先将图片缩放到固定尺寸，再按缩放后的像素或块数计算。

这意味着同一组图片在不同后端消耗的 token 可能相差数倍。如果使用统一 key 轮询多个后端，成本估算和上下文管理需要以最严格的后端为准，或为每个后端单独配置抽帧参数。

工程实践：避免静默失败

• 显式检查响应：要求模型在输出中列出它看到的图片数量或描述每张图片，与发送数量对比。
• 客户端预压缩：将图片统一缩放到合理尺寸（如长边不超过 1024 像素），减少被后端二次缩放的概率。
• 分批发送：如果帧数较多，分成多个请求，每个请求包含少量图片，避免触及数量上限。
• 记录 token 用量：聚合站通常返回 usage 信息，对比不同后端的图片 token 消耗，调整抽帧策略。
• 降级与重试：当某个后端因图片限制失败时，自动减少图片数量或切换后端。

成本与计费提醒

通过聚合站调用时，用户按官方价 ×1.3 扣费，贡献 key 按官方价 ×1.1（优质 ×1.2）返 USDC。图片 token 会计入总 token，因此抽帧数量直接影响成本。建议在开发阶段用少量帧测试各后端的实际 token 消耗，再确定生产环境的抽帧参数。

小结

视频抽帧加多后端视觉模型是一条实用但容易踩坑的链路。核心是：控制帧数、统一图片尺寸、了解各后端 token 计法差异，并通过响应验证确保没有丢帧。用一把 key 调多个模型时，把这些差异纳入设计，才能让视频摘要任务稳定可靠。