写这篇博客不是因为标题好玩而是因为它背后藏着一个很实际的问题当我们用 AI 来处理视频——不管是生成一段短视频还是对老视频做摘要、抽帧、分析——成本到底能不能控制在“两根棒棒糖”这个量级很多人第一反应是“不可能”因为视频文件大、计算量大、模型调用价格高。但如果你真的把视频处理的成本拆开按帧算、按 token 算、按缓存命中率算会发现很多时候钱不是花在“模型”上而是浪费在“怎么调用模型”上。这篇文章想给出的判断很直接视频处理的成本是可设计、可估算、可优化的。“一根视频只花两根棒棒糖”不是夸张的营销话术而是当你能控制分辨率、帧率、时长、提示词长度和缓存策略时成本确实可以低到让人怀疑是不是算错了。读完这篇文章你会知道视频处理成本由哪些因素决定怎么用一段 Python 脚本把视频抽帧、多模态分析与成本统计串起来以及哪些工程手段能让你在项目里真正做到“花小钱办大事”。我会从成本结构讲起再给出一套可运行的代码示例最后补充排查思路和工程建议。文章里有完整代码建议收藏后跟着敲一遍。1. 这篇文章真正要解决的问题先问一个具体问题你接到一个需求要把一段 10 分钟的视频自动生成“图文摘要”里面要有视频里出现的关键物体、字幕、场景变化。按以前的思路得先抽帧让人看或者逐段转码再人工写摘要人力成本很高。现在用多模态模型可以把视频抽帧后直接丢给模型去理解看似简单但账单出来常常吓人一跳。问题出在哪里问题很少出在“模型太贵”更多出在帧抽太多。一个 10 分钟视频按 1 秒 1 帧就是 600 张图按 2 秒 1 帧就是 300 张。多模态模型对图片按分辨率切块计费帧数翻倍视觉 token 基本翻倍费用也接近翻倍。提示词里塞了一堆无关历史内容。每次请求的对话上下文如果越来越长token 消耗会线性上涨视频内容分析尤其容易踩这个坑。没有做结果缓存。同一个视频片段反复分析、同一段 prompt 反复调用每一分钱都白白重复花。不检查输出格式。模型输出了一堆解释性文字而实际项目要的只是几个结构化字段浪费 token 不说解析还容易出错。这篇文章的真正目的不是教你“怎么省两块钱”而是让你建立一套视频场景下的成本控制框架。它适合三类读者正在开发视频摘要、视频检索、内容审核等 AI 应用的后端工程师用 API 做多模态分析的客户端开发者以及想在自己项目里低成本跑通视频理解流程的技术爱好者。另一个重要提醒我们讨论的优化前提是你有合法的视频来源和 API 调用权限。无论是处理自己拍摄的视频还是处理授权内容都不要绕过平台的权限、配额和计费规则。成本优化不等于钻空子。2. 视频处理成本的核心token、帧、分辨率与时长要看懂成本先理解视频是怎么被 AI 模型“看”的。绝大多数多模态大模型并不直接接收.mp4文件而是接收图像帧。模型拿到一帧图像后会按预训练时定义的视觉编码器把图片切分成若干小块每个小块映射为视觉 token。后面的文本 token、指令 token 再叠加进来共同参与计费。因此视频处理的成本模型可以写成一个简单的公式总成本 ≈ 图像 token 数 文本 token 数 输出 token 数 ≈ Σ(单帧视觉 token × 帧数) 输入提示词 token 模型输出 token这里最容易被忽略的是“单帧视觉 token”并不是固定的。同样一张图输入分辨率越高视觉 token 越多。很多平台对视觉输入有专门的计费方式常见的是按图像的分辨率分档例如低分辨率、中分辨率、高分辨率对应不同的 token 权重。如果你想控制成本第一优先级不是优化提示词而是控制图片的尺寸和数量。下表给出常见因素对成本的相对影响方便你建立直觉因素提升效果成本影响优化建议帧率从 1 秒 1 帧提升到 1 秒 3 帧视觉 token 近似翻 3 倍按场景变化抽帧不求固定帧率分辨率从 512 提升到 1024视觉 token 可能翻 4 倍只对关键帧做高清其余低清时长从 1 分钟扩展到 10 分钟近似线性增长先做分段摘要再合并提示词长度从 200 token 到 2000 token每轮请求固定增加使用系统提示词模板压缩历史消息输出格式半结构化文本 vs 纯 JSON输出 token 差异大强制使用 JSON Schema 或少量输出很多人以为“视频模型很贵”其实视频理解和视频生成是两个维度的贵。理解类任务贵在帧数多生成类任务贵在生成帧的采样步数。无论哪一种控制分辨率与时长都是“第一省钱法则”。另外要小心上下文长度陷阱。就算你只抽了 20 帧每一帧 1000 个视觉 token一次请求也有 2 万视觉 token。如果把历史对话消息全部带上上下文很容易冲到 5 万甚至 10 万 token。部分模型的上下文窗口虽然支持 128K但高并发时会变慢费用也会上升。所以最佳实践是每次请求只放当前任务的必需信息不要让对话无限增长。3. 环境准备与前置条件我们用一个最小可运行的 Python 项目来演示完整的视频成本优化流程。为了不依赖某个具体的商业平台代码采用 OpenAI 兼容接口风格你可以在配置里换成任何支持多模态/图像输入的兼容服务。环境建议如下操作系统Windows 10/11、macOS、Linux 均可Python 3.9 及以上FFmpeg用于视频抽帧与信息获取依赖库openai、python-dotenv、Pillow安装依赖命令python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install openai python-dotenv PillowFFmpeg 需要单独安装。macOS 推荐 Homebrewbrew install ffmpegUbuntu/Debiansudo apt update sudo apt install ffmpegWindows 可以从 FFmpeg 官方站点下载可执行文件并把bin目录加入系统 PATH。验证安装ffmpeg -version能输出版本信息说明环境没问题。项目文件结构这样安排video_cost_optimizer/ ├── .env ├── config.py ├── video_utils.py ├── analyze_video.py └── cost_estimator.py.env文件里保存 API Key 和基础配置。密钥千万不要提交到 Git 仓库。# .env API_BASEhttps://api.example.com/v1 API_KEYyour_api_key_here VIDEO_MODELyour_multimodal_model_name MAX_FRAMES30 FRAME_RESIZE_SIZE512环境准备看起来简单但最容易出错的是 FFmpeg 路径没有配置好。建议安装后先单独执行一次ffmpeg -version再跑 Python避免把环境问题和代码问题混在一起。4. 核心流程拆解从视频到结构化摘要整个视频分析流程可以拆成 5 个阶段。每个阶段都有明确的产出物和控制点。4.1 视频信息探测第一步不是直接抽帧而是先用 FFmpeg 读取视频的时长、分辨率、帧率。这个信息能帮助你决定抽多少帧、按什么间隔抽。比如一个 10 分钟的视频如果固定每秒 1 帧会得到 600 帧再丢给模型几乎一定会爆 token。但如果按“每 5 秒抽 1 帧”只有 120 帧信息量仍然可观。4.2 抽帧与尺寸压缩抽帧时尽量统一输出尺寸建议控制在 512 或 768 像素范围。视频里的画面信息主要是“内容”而不是“超高细节”大多数场景不需要 1080P。尺寸压缩是降本收益最大的一步经常能把单帧视觉 token 降到原来的四分之一甚至更少。4.3 帧筛选不是每一帧都有分析价值。连续两个镜头如果几乎一样重复分析就是浪费。简单做法是按间隔抽帧进阶做法是计算帧之间的像素差或使用场景检测工具只保留关键帧。这里我们先提供一个“每隔 N 秒抽一帧”的实现复杂场景切换检测可以作为后续优化方向。4.4 构造提示词与调用模型将抽出的帧序列作为图片输入配合一段明确的结构化指令要求模型输出 JSON。提示词里要包含你希望模型关注什么物体、字幕、场景、人物动作。输出格式要求字段名、类型、枚举值。不需要模型复述图片内容之外的背景故事。提示词越收敛输出越稳定越省 token。4.5 缓存与成本统计在调用模型之前先计算请求的“指纹”。指纹可以基于视频文件哈希、抽帧参数、提示词模板版本生成。如果指纹相同直接读缓存结果不调用模型。这在高频处理重复视频、反复调试 prompt 时效果非常明显。同时在每次请求后记录 token 用量和估算成本最后汇总成一张表方便分析钱花在哪里。5. 完整示例代码实现下面给出一套可以直接跑通的最小代码我会按文件拆开讲解。先写视频工具模块video_utils.py。# video_utils.py import subprocess import os from PIL import Image def get_video_info(video_path: str) - dict: 使用 ffprobe 获取视频基本信息 cmd [ ffprobe, -v, error, -select_streams, v:0, -show_entries, streamwidth,height,r_frame_rate,duration, -of, json, video_path, ] result subprocess.run(cmd, capture_outputTrue, textTrue, checkTrue) import json return json.loads(result.stdout) def extract_frames(video_path: str, output_dir: str, interval_sec: int 3, max_frames: int 30, resize_size: int 512) - list: 按固定间隔从视频中抽帧并压缩到统一尺寸。 返回抽帧后的图片文件路径列表。 os.makedirs(output_dir, exist_okTrue) prefix os.path.join(output_dir, frame_%04d.jpg) # 使用 -vf fps1/interval 的方式简单且稳定 cmd [ ffmpeg, -i, video_path, -vf, ffps1/{interval_sec},scale{resize_size}:-2, -frames:v, str(max_frames), -q:v, 5, -y, prefix, ] subprocess.run(cmd, capture_outputTrue, textTrue, checkTrue) frames sorted( [ os.path.join(output_dir, f) for f in os.listdir(output_dir) if f.startswith(frame_) and f.endswith(.jpg) ] ) # 防止抽出来的帧数量超过预期 return frames[:max_frames] def estimate_visual_tokens(image_path: str, detail: str low) - int: 估算单张图片的视觉 token 数。 这是一个通用的粗略估算函数实际数值以你所接模型平台的计费规则为准。 with Image.open(image_path) as img: w, h img.size if detail low: # low detail 模式通常对应固定较小的 token 数 return 85 * (w // 512) * (h // 512) if (w // 512) and (h // 512) else 85 elif detail high: tiles max(1, (w // 512) * (h // 512)) return 170 * tiles return 85这里用fps1/3表示每 3 秒抽一帧。scale512:-2会把宽度压缩到 512 并保持高度为偶数后续传给模型更省视觉 token。代码里的 token 估算函数只用于前期预算不要太依赖绝对数字。接着写主分析脚本analyze_video.py。这里采用 OpenAI 兼容接口方式通过环境变量配置 base_url 和 api_key 来对接不同平台。# analyze_video.py import hashlib import json import os from pathlib import Path from openai import OpenAI from video_utils import extract_frames, get_video_info, estimate_visual_tokens from dotenv import load_dotenv load_dotenv() client OpenAI( base_urlos.getenv(API_BASE), api_keyos.getenv(API_KEY), ) VIDEO_MODEL os.getenv(VIDEO_MODEL, your_multimodal_model) def build_fingerprint(video_path: str, interval_sec: int, max_frames: int, resize_size: int, prompt_version: str v1) - str: 根据输入参数生成缓存指纹 stat os.stat(video_path) raw f{video_path}:{stat.st_size}:{stat.st_mtime}:{interval_sec}:{max_frames}:{resize_size}:{prompt_version} return hashlib.sha256(raw.encode(utf-8)).hexdigest() def read_cache(cache_path: Path): if not cache_path.exists(): return None try: with open(cache_path, r, encodingutf-8) as f: return json.load(f) except Exception: return None def write_cache(cache_path: Path, data: dict): with open(cache_path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def build_prompt() - str: return 请分析这些视频帧并输出 JSON 格式的结果 { scene_list: [场景1, 场景2], objects: [物体1, 物体2], subtitle_summary: 字幕摘要, key_events: [重要事件] } 要求 1. 只分析图片中可以观察到的内容不猜测背景故事。 2. 场景列表控制在 3 个以内。 3. 字幕摘要如果看不到字幕返回空字符串。 4. 不要输出额外解释文字。 def analyze_video(video_path: str, output_dir: str frames, interval_sec: int 3, max_frames: int 30, resize_size: int 512) - dict: # 1. 获取视频信息 info get_video_info(video_path) print(视频信息, info) # 2. 缓存检查 cache_key build_fingerprint(video_path, interval_sec, max_frames, resize_size) cache_file Path(cache) / f{cache_key}.json cached read_cache(cache_file) if cached: print(命中缓存直接返回结果) return cached # 3. 抽帧 frames extract_frames(video_path, output_dir, interval_sec, max_frames, resize_size) print(f抽到 {len(frames)} 帧) # 4. 估算视觉 token 成本 total_image_tokens sum(estimate_visual_tokens(f, detaillow) for f in frames) print(f估算视觉 token{total_image_tokens}) # 5. 构造多模态消息 content [{type: text, text: build_prompt()}] for frame_path in frames: import base64 with open(frame_path, rb) as img_file: base64_image base64.b64encode(img_file.read()).decode(utf-8) content.append( { type: image_url, image_url: { url: fdata:image/jpeg;base64,{base64_image}, detail: low, }, } ) # 6. 调用模型 response client.chat.completions.create( modelVIDEO_MODEL, messages[{role: user, content: content}], temperature0.2, ) # 7. 解析和统计 raw_output response.choices[0].message.content usage response.usage result { summary: raw_output, usage: { prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, }, frames: len(frames), estimated_image_tokens: total_image_tokens, } # 8. 写入缓存 cache_dir Path(cache) cache_dir.mkdir(exist_okTrue) write_cache(cache_file, result) return result if __name__ __main__: import sys video_file sys.argv[1] if len(sys.argv) 1 else demo.mp4 result analyze_video(video_file) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码有几个关键点使用base64把图片传给模型兼容大多数 OpenAI 兼容接口。temperature0.2降低随机性更适合结构化输出。缓存指纹既包含视频文件状态也包含抽帧参数和 prompt 版本。只要源视频或者参数变了缓存自动失效。真实调用前先用估算函数打印一个视觉 token 预算能提前发现“帧数太多”的问题。最后写成本估算模块cost_estimator.py。这里不依赖具体平台价格而是把单价做成可配置参数。# cost_estimator.py import json def estimate_cost(usage: dict, input_price_per_k: float 0.01, output_price_per_k: float 0.03, image_price_per_k: float 0.005) - dict: 根据 token 用量估算成本。 参数单位元 / 千 token。 image_price_per_k 是视觉 token 的单价系数 具体数值需要根据你所用平台的计费规则调整。 total_image_tokens usage.get(estimated_image_tokens, 0) real_image_tokens min(total_image_tokens, usage.get(prompt_tokens, 0)) input_cost (usage.get(prompt_tokens, 0) - real_image_tokens) / 1000 * input_price_per_k image_cost real_image_tokens / 1000 * image_price_per_k output_cost usage.get(completion_tokens, 0) / 1000 * output_price_per_k total input_cost image_cost output_cost return { input_cost: round(input_cost, 6), image_cost: round(image_cost, 6), output_cost: round(output_cost, 6), total_cost: round(total, 6), detail: 单价参数仅供演示实际以平台计费为准, } if __name__ __main__: # 示例从 result.json 读取结果进行成本估算 with open(result.json, r, encodingutf-8) as f: result json.load(f) cost_info estimate_cost(result[usage]) print(json.dumps(cost_info, ensure_asciiFalse, indent2))这套代码的价值在于“可观察”和“可重复”。每次运行都会告诉你抽了多少帧、估算多少视觉 token、实际消耗多少 token、成本大概是多少。有了这些数据优化才不是拍脑袋。6. 运行结果与效果验证假设你有一个demo.mp4视频可以先运行python analyze_video.py demo.mp4第一次运行没有缓存应该看到类似这样的输出视频信息 {streams: [{width: 1280, height: 720, r_frame_rate: 25/1, duration: 30.0}]} 抽到 10 帧 估算视觉 token850 提示词 token~120 调用模型成功共消耗 token 1024 { summary: {...}, usage: { prompt_tokens: 890, completion_tokens: 134, total_tokens: 1024 }, frames: 10, estimated_image_tokens: 850 }这里 10 帧来自一个 30 秒视频、每 3 秒抽一帧。如果把间隔改成 1 秒帧数会变成 30视觉 token 直接翻 3 倍。运行python cost_estimator.py后会输出类似{ input_cost: 0.001, image_cost: 0.004, output_cost: 0.004, total_cost: 0.009, detail: 单价参数仅供演示实际以平台计费为准 }0.009 元这个数字看起来非常低也就是“一根棒棒糖”都不到。当然这个数字是我用演示单价算出来的真实平台的价格可能不同。但它说明了一个事实只要模型选对、帧数控制好、输出用 JSON视频分析成本完全可能低到可以忽略不计。如何判断你的运行是成功的输出 JSON 能被正常解析scene_list、objects等字段都存在。total_tokens在你的预期范围内。如果屏幕上显示的total_tokens是estimated_image_tokens的 10 倍以上说明你的提示词或上下文可能出了问题。第二次运行同一视频时看到“命中缓存直接返回结果”说明缓存生效了成本为 0。如果调用失败第一步先看 API 返回的error信息绝大多数是鉴权失败、模型名不存在、图片数据量超限这三类问题。我还建议把每次运行的结果追加到一份日志表里看看不同参数组合下的 token 变化。比如记录interval_sec、max_frames、resize_size、prompt_tokens、completion_tokens、total_tokens。当你积累了 20 条记录就会很清楚自己的成本瓶颈在哪。7. 常见问题与排查思路下面这些问题是视频分析项目中最高频的坑我直接列成表方便你排查。问题现象可能原因排查方式解决方案调用 API 返回 401 错误API Key 配置错误或没有权限检查.env中的API_KEY重新生成密钥确认环境变量已加载返回 404 模型不存在模型名写错或当前账号不可用该模型打印VIDEO_MODEL环境变量和平台文档对比换成有权限的模型名抽帧数量为 0FFmpeg 命令错误或视频路径不正确单独执行抽帧命令看终端输出的错误信息检查视频是否损坏路径是否包含中文提示词 token 量异常大每次请求都带了大量历史消息打印messages的实际发送内容只保留当前任务的 system/user 消息输出 JSON 解析失败模型返回了额外解释文字查看raw_output原始内容用 JSON 修复函数兜底或调整提示词约束成本超出预期帧数太多、分辨率太高、单次输入图片过多查看estimated_image_tokens输出降低采样间隔使用 low detail 模式缓存一直不生效指纹里的文件时间戳变化或参数不一致打印build_fingerprint结果把指纹生成函数抽出来单独测试超时图片太多或图片太大观察单张图片 base64 大小压缩图片尺寸减少每批图片数量平台报“图片请求超限”一次请求里的图片数量超出接口上限分批处理或降低max_frames把视频切成片段再分别分析再合并最容易被忽视的是“图片 base64 大小”。一张 1080P 的 JPEG 可能 500KB转成 base64 后约 670KB。如果塞 30 张图就是 20MB 的请求体很多网关会直接拒绝。所以在抽帧时统一resize_size512不只是省 token也是避免请求体过大。另一个常见误区是“为了提高准确率什么参数都拉满”。视频摘要任务并不需要每一帧都完整保留。你可以先跑一个低配版本看结果是否满足需求不满足再逐步提高帧数和分辨率。这种“从低到高”的策略比一开始就上高配要省钱得多。8. 最佳实践与工程建议把上面的代码放到真实项目里时下面几条经验值得提前记下来。8.1 把成本统计做成基础设施不要只在调试时算成本而是把 token 用量写进日志系统。建议在每次模型调用后记录调用时间视频标识抽帧参数模型名称输入 token、输出 token、总 token估算成本缓存是否命中这些数据以后可以用来做成本大盘也能帮你发现某条业务线是不是忽然开始“烧钱”了。8.2 缓存策略要覆盖 prompt 版本prompt 一旦修改即使视频参数没变之前的缓存结果也可能不再适用。所以指纹里一定要加prompt_version。每次改提示词把这个版本号递增。如果没有这个字段你会陷入“为什么我改了提示词结果还是旧版”的困惑。8.3 使用模型输出校验层直接让模型输出 JSON可以给调用代码加一层pydantic或jsonschema校验。校验失败时重新调用一次并降低 temperature。这样能避免因为一次坏输出导致整个流程失败。还要注意如果连续两次都校验失败要记录失败样本再人工判断是提示词问题还是模型问题。8.4 控制并发和限流视频分析如果做成批处理任务很容易遇到限流。建议使用任务队列控制并发数比如同时运行 4 个任务。不要写完 for 循环就全量并发API 429 会教你做人。同时要处理好失败重试重试时使用指数退避避免重试风暴。8.5 安全与最小权限原则如果视频文件来自用户上传不要直接信任文件名和文件内容。先做格式校验、大小限制、恶意文件扫描。API Key 不要放在前端代码里也不要提交到 Git。建议通过环境变量或密钥管理服务注入。在多人协作时为不同服务创建不同的 Key方便回收和追溯。这些看似与成本无关但安全事故才是最大的成本。8.6 模型选择原则不是所有任务都需要最强的多模态模型。对视频摘要这类任务可以先用轻量模型跑一版如果效果不足再升级。模型升级不要盲目用结构化评测集对比输出质量。把评测样本固定下来每次改模型都跑一遍能避免“好像变好了”的错觉。8.7 考虑分批处理与结果合并对于长视频一次性传完所有帧会超出窗口也容易超时。更稳妥的做法是将视频按时间切段每段抽取关键帧。对每个片段生成局部摘要。把所有局部摘要拼接成一个文本再一次调用模型生成总摘要。这样既控制了单次请求的 token也让结果更稳定。9. 总结与后续学习方向这篇文章从“一个视频两根棒棒糖”这个标题出发拆解了视频分析成本的核心变量token、帧率、分辨率、时长、提示词长度和缓存策略。配套代码给出了从 FFmpeg 抽帧、多模态模型调用、缓存命中到成本估算的完整链路。你现在应该能回答这几个问题视频处理成本为什么高可以从哪些环节降怎么用代码把成本可视化下一步我建议你找一个自己的视频按上面代码跑一遍记录不同参数下的 token 消耗。然后再试试两个优化方向一个是场景检测抽帧不用固定间隔而是只在画面出现明显变化时抽帧另一个是把长视频切段、分段摘要、再合并把长视频任务改成可扩展的流水线。这两个方向做好了你的视频成本还会进一步下降。如果这篇文章解决了你的一些疑问收藏备用是个不错的选择。如果后面你做了视频生成方向的成本优化思路其实类似分辨率、时长、采样步数、缓存、模型选择永远是成本控制的核心。把“两根棒棒糖”当作一个工程目标别把它当成一句玩笑。