最近几个月，各路视频理解模型（VLM）的评测榜单刷得飞起，动辄“刷新SOTA”“超越人类基线”，看着确实唬人。但真把模型拉出来，丢一段几十秒的短视频进去，问它“这个人在干什么”“刚才那个物体是什么颜色”，翻车的情况一点不少。

我不是说榜单没用，而是想聊一个更扎心的问题： 高分的视频理解模型，真的“看懂”视频了吗？

先说结论：很多模型在评测集上的高分，靠的是“捡漏”和“记忆”，而不是真正的时序推理。你把视频拆成帧、把问题改成更刁钻的变体、或者把画面里的物体遮挡一下，分数立马掉一个档次。这篇文章我就拿我自己实测过的方案、跑过的模型、踩过的坑，把这件事拆开讲清楚——既讲评测里那些看不见的“水分”，也讲怎么在部署VLM时避开这些坑，让它真正干点实事。

无论你是刚入门想做视频问答，还是已经在用AutoGLM、Ollama这类工具折腾多尺寸VLM部署，这篇文章都值得你花几分钟看完。尤其是最后一部分的实测记录和问题排查，都是常规文档里不会写的东西。

1. 内容整体设计与思路拆解

1.1 视频理解到底难在哪

视频理解和单张图片理解，表面上只差了一个“时序”，实际上复杂度完全不是一个量级。一张图，模型只需要做空间推理：物体在哪、颜色是什么、人和人的关系怎样。但视频是连续帧的集合，模型必须同时处理三件事：

• 空间感知 ：每一帧里有什么物体、什么状态。
• 时序感知 ：物体在帧与帧之间怎么移动、状态怎么变化。
• 因果推理 ：前一步的动作导致了什么结果，事件发生的顺序是什么。

举个最简单的例子：一段视频里，一个人先拿起杯子喝水，然后把杯子放回桌上。单帧上看，第一帧有“人拿着杯子”，第三帧有“杯子在桌上”，但如果你只看这两帧，根本不知道中间发生了什么。模型必须学会把“拿起—喝水—放下”这个动作序列串起来，才算真正理解。

目前主流方案是直接把视频抽帧，然后丢给大语言模型（LLM）做图文问答。这种方法的好处是工程实现简单，坏处是模型本身并不具备真正的“时序建模”能力，它只是把几帧图片当成多图输入来处理。于是问题就来了： 如果模型本身不理解时序，它凭什么在高分？

1.2 高分背后的“水分”从哪来

我扒过不少公开榜单的测试集，也自己做过交叉验证，发现高分主要来自三个地方：

• 静态帧就能答对 ：很多视频问答的题目，答案就藏在某一帧的画面里。比如问“画面里有什么颜色”，你抽第10帧看到的和抽第50帧看到的一模一样，模型根本不需要看完整视频，瞥一眼就能答对。
• 问题文本里有提示词 ：不少测试集的问题写得太“友好”，答案关键词直接出现在问题里。比如问“这个人是不是在跑步”，画面里人明明只是走路，但问题里带了“跑步”两个字，模型容易顺着文本误导，反而答错，但数据统计上这类题目偏容易。
• 训练数据泄露 ：一些榜单用的公开视频，模型在预训练阶段就已经见过。你说它是在“理解”，不如说它是在“回忆”。

我在实测时就遇到过这种情况：同一个视频，我把画面裁剪掉一半、去掉颜色信息，模型从“满分”直接掉到“不及格”。这说明它依赖的不是对视频的语义理解，而是对画面纹理和文本关联的浅层匹配。

1.3 什么样的VLM才算“真看懂”了视频

结合我自己的判断标准，一个真正具备视频理解能力的VLM，至少要满足三点：

• 换场景不失准 ：训练集里的场景和测试集里的场景差异很大，模型依然能保持稳定表现，而不是换个背景就崩。
• 对时序敏感 ：把视频倒放、插帧、去掉中间过程，模型的回答应该明显变差——如果它不变差，说明它在“偷懒”，根本没用到时序信息。
• 能拒绝回答 ：遇到画面模糊、信息不足、问题歧义的情况，模型应该主动说“不确定”，而不是强行编一个答案。这一点很多模型都做不到。

记住这三个标准，后面我们讲评测策略和部署优化时都会用到。

2. 核心细节解析与实操要点

2.1 评测VLM视频理解能力的正确姿势

想判断一个模型是不是真的“看懂”了视频，不能只看它给的分数，要用对抗性评测方法去“拆穿”它。我整理了一套自己常用的评测流程，分四步走：

第一步：构建分类评测集

不要只用一个通用测试集，把测试集按难度分层：

• 静态题 ：答案直接从单帧画面可得，用来测试基础视觉感知。
• 动态推理题 ：必须结合多帧时序才能回答，比如“球是从左滚到右还是从右滚到左”。
• 因果推理题 ：需要判断事件先后顺序，比如“他是先开门还是先开灯”。
• 反事实题 ：问“如果某人没做某个动作，结果会怎样”，这类题对模型难度极大，能有效过滤“伪理解”。

分层之后，你得到的不是一个总分，而是模型在每种能力维度上的表现。如果某个模型静态题接近满分、动态题却不及格，那你基本可以断定：它没有真正理解视频。

第二步：做“换皮”测试

把同一个问题，用十几种不同的措辞来问：

• 原文：“视频里的人在做什么？”
• 换皮：“这个人的动作是什么？”
• 换皮：“描述一下画面中人物的行为。”
• 换皮：“你觉得这个小哥在干嘛？”

如果模型只在一种问法上答对，换成其他问法就错，说明它对语义的理解很脆弱，更多是在“背答案”。

第三步：对视频做扰动

这是我最喜欢的一步，因为操作简单、效果立竿见影。

• 把视频抽帧间隔拉大（比如原来每秒抽8帧，改成每秒抽1帧）。
• 把视频黑白化、加噪点、轻度模糊。
• 把关键物体用色块遮挡。
• 把视频倒放（注意：倒放后问题需要同步调整，否则问题不成立）。

你会发现，真正理解视频的模型受扰动影响较小，而“伪理解”模型在扰动后表现直线下降。

第四步：看失败案例，不要只看平均分

平均分是最骗人的指标。一个模型可能90%的题都答对，但剩下10%是“低级错误”——比如把狗认成猫、把红色说成蓝色。这类错误恰恰说明模型的视觉基础不扎实。我建议每个评测集至少人工翻50个失败案例，分类记录错误类型，这样才能定位模型的真实短板。

2.2 多尺寸VLM部署时，哪些参数最影响理解能力

很多人拿到AutoGLM、Ollama这类工具，第一件事就是“把模型跑起来”，但参数往往都是默认值，根本不知道自己吃没吃满模型的能力。这里我讲几个实测中影响最大的点。

分辨率设置

VLM的视觉编码器对输入分辨率非常敏感。有些模型你用默认分辨率跑，它连画面里的文字都看不清；你把分辨率提到模型支持的上限，准确率能涨不少。实测里，大部分模型在224×224分辨率下只能做粗粒度识别，至少要到448×448才能较好地读取画面中的文字、细节小物体。在Ollama部署时，记得查模型的 vision 配置项，不要被默认低分辨率坑了。

帧采样策略

视频理解中，抽帧策略直接影响时序推理能力。我自己实测过三档：

• 每秒1帧 ：适合场景变化极慢的视频（监控、会议），能省大量token，但动作细节全丢。
• 每秒4帧 ：适合大部分日常视频，能覆盖大多数动作，也是我推荐的默认值。
• 每秒8帧或更多 ：适合运动场景（球赛、舞蹈），但token成本几乎翻倍。

不要试图“一劳永逸”用最高帧率。你要做的是先看视频类型，再决定帧率。另外还有两个细节很多人会忽略： 抽帧要均匀 ，不要因为开头有精彩画面就密集取帧； 要去掉重复帧 ，视频里常见的静态长镜头会白白消耗token。

上下文窗口与token预算

视频理解最头痛的就是上下文爆掉。一段10分钟的视频，即使每秒只抽1帧，也有600帧，绝大多数模型根本装不下。我的建议是分段处理：把视频切成若干片段，每段单独喂给模型，再把各段的输出汇总给一次LLM做综合。这个做法在工程上叫“分层摘要”（hierarchical summarization），能有效突破上下文窗口限制。

2.3 模型切换时需要注意的坑

AutoGLM这类工具支持在多个VLM之间切换，看起来很方便，但你想真正用起来，有三个坑必须先填平。

视觉编码器不兼容

不同VLM用的视觉骨干网络不同，对输入图像的预处理方式也不同。有的模型需要把图像resize到固定尺寸，有的模型支持动态分辨率；有的模型用RGB顺序，有的用BGR。你用A模型的预处理流程去喂B模型，轻则效果打折，重则直接报错。

Prompt模板不一致

每家的Prompt模板都有自己的习惯，AutoGLM这类工具虽然帮你做了封装，但切换模型后你不检查模板，很容易出现“回答格式乱七八糟”的情况。比如有些模型要求 <image>\nQuestion: 这种格式，有些模型要求 Human: <image> Question: Assistant: ，搞混了模型也能出结果，但效果肯定不对。

tokenizer和生成参数

VLM切换后， max_tokens 、 temperature 这些参数最好也重新调。视频问答场景我建议初始设为 max_tokens=512 、 temperature=0.2 ，然后再根据模型微调。很多人在这一步偷懒，不管什么模型都用同一套解码参数，结果生成质量忽高忽低。

3. 实操过程与核心环节实现

3.1 本地搭一套视频VLM评测环境

为了让大家能跟着做，我把自己的评测环境搭建过程完整还原出来。我用的是Ollama部署VLM模型，再写一个Python脚本控制评测流程。整个过程不需要GPU集群，一张消费级显卡（8GB以上显存）就够用。

第一步：安装Ollama并拉取模型

# 安装Ollama（Linux/macOS）
curl -fsSL https://ollama.com/install.sh | sh

# 拉取一个支持视频帧输入的VLM模型
# 这里用 llava 作为示例，实际根据你的需求选
ollama pull llava

第二步：用Python把视频转成帧序列

import cv2
import os

video_path = "test_video.mp4"
frame_dir = "frames"

os.makedirs(frame_dir, exist_ok=True)

cap = cv2.VideoCapture(video_path)
fps = cap.get(cv2.CAP_PROP_FPS)
interval = max(1, int(fps / 4))  # 目标帧率：4fps，动态计算抽帧间隔

frame_count = 0
saved_count = 0

while True:
    ret, frame = cap.read()
    if not ret:
        break

    if frame_count % interval == 0:
        frame_path = os.path.join(frame_dir, f"frame_{saved_count:04d}.jpg")
        cv2.imwrite(frame_path, frame, [cv2.IMWRITE_JPEG_QUALITY, 90])
        saved_count += 1

    frame_count += 1

cap.release()
print(f"抽取完成，共 {saved_count} 帧")

这段代码做了两件事：一是根据视频实际fps动态计算抽帧间隔，保证输出约4fps；二是把每帧存成JPEG。注意JPEG质量设为90就好，没必要设100，否则文件体积膨胀，推理速度也会变慢。

第三步：调用Ollama逐帧/多帧推理

import ollama

# Ollama Python客户端支持图片输入
response = ollama.chat(
    model="llava",
    messages=[
        {
            "role": "user",
            "content": "仔细看这几张连续画面，回答：这个人正在做什么动作？",
            "images": ["frames/frame_0000.jpg", "frames/frame_0001.jpg", "frames/frame_0002.jpg"],
        }
    ],
    options={"temperature": 0.2, "max_tokens": 512},
)

print(response["message"]["content"])

这里有个关键点： 不要把所有帧一次性全塞进去 。我实测过，大多数VLM对图片数量的容忍上限在4～8张之间，超过之后模型会“失忆”，只记得最后几张。更好的做法是每次喂4帧，用滑动窗口方式逐段推理，最后汇总所有推理结果。

第四步：做“倒放测试”验证时序理解

这个测试很简单：把帧序列的顺序反转，再问同样的问题。如果模型对倒放视频和正放视频给出相同的答案，说明它并没有使用时序信息。操作上只需把 images 里的文件名顺序反过来即可。实测中，不少模型在倒放后依然给出同样答案，这就是“时序失明”的铁证。

3.2 用Ollama部署支持多尺寸输入的VLM

如果你用的是Ollama这类推理工具，可能会遇到一个问题：模型默认只支持固定尺寸输入，换一个尺寸就报错。解决方法有两个。

方法一：在模型文件中自定义尺寸

Ollama的Modelfile允许你自定义参数。先导出模型配置：

ollama show llava --modelfile > Modelfile

然后编辑 Modelfile ，修改 TEMPLATE 或视觉相关的配置项。不同模型对尺寸的定义位置不同，常见的是在 TEMPLATE 里加 resize 指令，或者通过环境变量指定。修改后保存，重新构建模型：

ollama create my-llava -f Modelfile

方法二：在代码层做预处理

如果你不想折腾模型文件，可以在喂图之前先用OpenCV把图片缩放到模型支持的尺寸。我甚至封装了一个函数：

def preprocess_image(image_path, target_size=(448, 448)):
    img = cv2.imread(image_path)
    img = cv2.resize(img, target_size, interpolation=cv2.INTER_LINEAR)
    return img

这个方案最稳，因为它不依赖具体模型实现，所有VLM都适用。唯一的代价是：缩放过狠会丢失细节，所以尽量选模型支持的最大尺寸。

3.3 AutoGLM-Phone场景下的模型切换实录

AutoGLM-Phone这类工具主打“手机端多模型切换”，我在测试环境里做了几组VLM切换实验，记录如下：

场景	模型A（偏视觉）	模型B（偏语言）	切换后表现
识别人脸表情	准确率高，能区分细微表情	准确率尚可，但会漏掉微表情	掉点约15%
理解视频中人物对话	能读懂口型变化	对话内容理解更强	视觉细节丢失
长视频摘要	需要分段	单段即可	B更省token

从实践看，切换模型不能只看“哪个分高”，还要看任务类型。如果你的场景更依赖视觉细节（表情、物体纹理），选视觉强模型；如果更依赖语言推理（对话、逻辑），选语言强模型。AutoGLM-Phone里切换模型很快，但你要有意识地针对任务选模型，而不是无脑追高分。

4. 常见问题与排查技巧实录

4.1 为什么模型输出质量时好时坏

这是最频繁被问到的问题。视频理解模型输出不稳定，通常不是模型本身的问题，而是你的预处理链路不一致。

常见原因一：帧分辨率不一致

视频源是1080p，你直接抽帧喂给模型，模型内部会缩放到固定尺寸。但如果你的抽帧时用了不同压缩质量，或者中间有一步缩放过，最后喂进去的实际分辨率就飘忽不定。解决方法是：在代码里显式统一输入尺寸，不要依赖模型内部缩放。

常见原因二：上下文长度溢出

视频帧多的时候，很容易超出模型的上下文窗口。超出后不同模型表现不一样，有的直接报错，有的静默截断（只保留前N帧或后N帧）。静默截断最坑，因为它不报错，但输出结果已经“漏看”了大量画面。排查方法是打印实际输入给模型的token数量，或者观察API返回的 prompt_eval_count 。

4.2 帧率到底应该怎么选

这个没有标准答案，但可以给你一个实用的决策公式。先判断你的视频场景变化速度：

• 画面90%时间静止，只有说话人偶尔动一下： 1fps足够 ，再多纯属浪费。
• 画面中等运动，比如人在走路、做手势： 4fps是甜点值 。
• 画面高速运动，比如球赛、舞蹈、物体快速移动： 8fps起步 ，如果token预算足够就上16fps。

我自己的做法是：先以4fps跑一版，查看关键片段——如果模型在某个时间点的回答明显错误，再单独把那段视频用8fps重跑。这种“先粗后细”的策略，能在token成本和准确率之间取得平衡。

4.3 模型对中文视频理解差，怎么办

很多VLM的中文视频理解效果不如英文，这不是模型“笨”，而是训练数据的锅。中文视频里的台词、字幕、背景文字，视觉编码器未必能有效识别。我的补救措施有三个：

• 先提取字幕 ：用语音识别工具把视频里的中文语音转成文本，再喂给模型做辅助信息。
• 把问题写成英文再翻译回中文 ：有些模型的中文指令跟随能力弱，但英文能力强，用英文提问效果反而更好。实测后如果英文回答质量高，再用翻译工具转回中文就行，虽然多一步但结果更稳。
• 调整提示词 ：在提示词里加入“请用中文回答，但思考过程可以用英文”之类的引导，部分模型会因此提升中文表现。

4.4 部署多尺寸模型时显存不够怎么办

这是本地部署最容易卡住的一关。一张8GB显卡，跑7B模型勉强，跑13B模型就爆显存。我的建议按优先级排列：

1. 降低帧率 ：从4fps降到2fps，显存占用直接减半。
2. 减小图像尺寸 ：从448×448降到336×336，视觉编码器的显存占用能降25%左右。
3. 用量化版模型 ：Ollama里的模型默认可能是 Q4_K_M 等量化版本，如果觉得精度不够，换更大的量化档位前先确认你的显存放不放得下。
4. 分块推理 ：不要一次性把12帧全喂进去，改成一次4帧，推理三次再汇总。

注意：分块推理会损失一定的跨片段时序理解，所以视频摘要类任务优先选这个方法，而单点动作判断任务建议用足帧率，不要分块。

4.5 一个容易忽略的坑：视频方向

很多手机拍的视频是竖屏的，但有些模型在预处理时默认按横屏缩放，导致画面被压缩变形。人脸识别、物体识别这类任务受影响尤其严重。解决办法很简单：抽帧后先检查画面宽高比，如果 height > width ，在喂给模型前先做旋转或填充处理，不要直接塞进去。

这个坑我踩过不止一次，后来统一在抽帧脚本里加了方向检测，才彻底解决。

5. 写在最后：VLM视频理解的下一步

说实话，目前的VLM视频理解能力还处在“看得见，但没完全看懂”的阶段。那些榜单上的高分，更像是模型在特定数据集上的“应试技巧”，距离真正的视频理解还有距离。

我在实际部署和测试中最深的体会是： 别迷信一个模型的平均分数，要看它在扰动、换场景、换问题下的稳定性 。一个稳定在70分水平的模型，远比一个“满分有时、零分有时”的模型靠谱。

如果你也在折腾VLM部署，我的建议是从小处着手：先搭一套评测脚本，跑一批对抗性测试，弄清楚你手上的模型到底强在哪、弱在哪，再针对性地优化输入策略和部署参数。这个过程比盲目追新模型、堆参数有意义得多。

最后再分享一个小技巧： 评测视频理解模型时，永远保留一个“倒放版”测试集 。它不花你一分钱，也不需要额外标注，却能一眼看穿模型是不是真的在理解时序。能抗住倒放测试的模型，不敢说完全看懂了视频，但至少没有在“装懂”。