Mobile-VideoGPT: Fast and Accurate Model for Mobile Video Understanding

Paper: arXiv:2503.21782v2 Code: Amshaker/Mobile-VideoGPT Code reference: main @ c82a4cbc (2025-08-07)

版本说明

当前 arXiv v2 标题为 Mobile-VideoGPT: Fast and Accurate Model for Mobile Video Understanding；本笔记文件名保留旧题名中的 “Video Understanding Language Model”，以避免破坏现有 Obsidian 链接与分类路径。

1. Motivation (研究动机)

1.1 核心问题：视频理解模型很强，但太慢、太大、太贵

现有 Video LMM / Video VLM 通常沿用“大视觉编码器 + 大语言模型 + 大量视频帧”的路线。 这条路线在离线评测上有效，但在移动端、Jetson、机器人、可穿戴设备等场景中会暴露三个瓶颈。 第一，参数量大：许多强基线处在 7B 甚至更大规模，显存和加载成本都高。 第二，视觉 token 多：视频输入往往把几十帧拆成成千上万个 patch token，LLM 侧上下文开销急剧上升。 第三，推理吞吐低：模型可能回答准确，但 tokens/sec 或 frames/sec 无法支撑实时交互。 因此论文的目标不是单纯追求最高 benchmark 分数，而是在“小模型、低分辨率、少帧数”的条件下尽量保持视频问答能力。

1.2 为什么单纯缩小 LLM 不够

如果只是把 LLM 从 7B 换成 0.5B / 1.5B，视觉侧的冗余不会自动消失。 视频仍然会包含大量重复帧、静态背景帧、低信息量帧。 视觉编码器产生的 token 仍需要投影到语言空间，投影器若只是普通 MLP，也不会主动压缩空间 token。 小语言模型的容量更有限，输入过多冗余 token 反而会挤占上下文和注意力预算。 所以 Mobile-VideoGPT 的动机是：同时压缩视觉帧、视觉 token 和语言模型规模，而不是只在某一处做轻量化。

1.3 论文想解决的具体 trade-off

论文关心的是 accuracy-efficiency Pareto frontier。 模型需要在 MVBench、EgoSchema、NextQA、PerceptionTest、MLVU、ActivityNet-QA 等常用视频理解 benchmark 上维持竞争力。 同时模型要减少参数量、降低输入分辨率、减少帧数，并提升吞吐。 Table 1 显示 Mobile-VideoGPT-0.5B 使用 0.6B 参数、224×224 输入、16 帧，在 RTX A6000 上达到 45.9 throughput。 对比 LLaVA-OneVision-0.5B：后者约 1.0B 参数、384×384、32 帧、22.7 throughput。 这意味着 Mobile-VideoGPT 的设计重点是“用更少的视觉输入和更小的模型做足够好的视频理解”。

1.4 论文针对的部署场景

移动端视频问答：用户拍摄或上传短视频后需要低延迟回答。 边缘端监控/机器人：设备可能没有服务器级 GPU，但需要理解动作、对象和场景变化。 实时交互系统：模型需要边看边答，吞吐比离线 batch accuracy 更关键。 低成本多路视频分析：当同一硬件要处理多路视频时，模型大小和视觉 token 数直接决定可并发数量。 论文 README 还报告了 Jetson Orin Nano 部署新闻：Mobile-VideoGPT-0.5B 达到 7.3 tokens/sec，相比 LLaVA-OneVision 的 3.4 tokens/sec 超过 2×。

1.5 贡献定位

论文不是提出一个新的大规模通用 Video LMM。 它更像是一个面向移动/边缘视频理解的系统化轻量化方案。 关键贡献包括： 轻量级双视觉编码器架构。 Attention-Based Frame Scoring，用图像特征对视频帧做显著性选择。 Efficient Token Projector (ET-Proj)，把视觉 token 压缩后再送入 SLM。 三阶段训练策略，先对齐图像投影器，再对齐视频投影器，最后做指令微调。 公开代码、模型和训练/评测脚本，便于复现。

1.6 读论文时应抓住的主线

主线不是“0.5B 模型是否能全面超过 7B 模型”。 更合理的问题是：在移动端预算下，哪些视觉信息必须保留，哪些可以删掉。 Mobile-VideoGPT 的回答是： 保留少量代表性关键帧。 同时保留图像级空间上下文和视频级时间动态。 用投影器压缩 token，但不要把位置信息完全抹掉。 让小语言模型只接收更干净、更短的视觉序列。

2. Idea (核心思想)

2.1 一句话核心

Mobile-VideoGPT 的核心思想是：用轻量双视觉编码器先把视频拆成空间上下文与时间动态，再用注意力式关键帧选择和 ET-Proj 压缩视觉 token，使小语言模型在低延迟条件下仍能完成视频问答。 它把“帧选择”和“token 压缩”放在 LLM 之前做，而不是让 LLM 自己在冗长视觉 token 中寻找重点。 这也是它相比普通小型 VLM 更系统的地方。

2.2 设计直觉

视频中的大多数相邻帧高度相似。 如果直接把所有帧都送进视频编码器，会浪费大量计算在重复背景和缓慢变化区域上。 CLIP 类图像编码器对单帧空间语义更敏感，可以先为每帧生成 patch 特征。 通过帧内/帧间 token 的自注意力相关性，可以粗略估计哪些帧被更多 token “关注”。 被更多 token 关注的帧更可能包含全局事件、关键动作或显著对象。 因此只把 top-K 帧送入 VideoMamba，能减少时间编码开销。 但只做帧选择还不够，因为每帧仍有大量空间 token。 ET-Proj 再通过 FFN、AdaptiveAvgPool2d 和位置卷积把 token 数压下去，并保留空间结构。

2.3 架构层面的关键拆分

Image encoder：处理所有或上下文帧，提供空间 patch 表征。 Video encoder：只处理关键帧，捕获时间动态。 Image projector：把图像上下文 token 对齐到 SLM 维度。 Video projector：把 VideoMamba 输出对齐到 SLM 维度。 SLM：使用 Qwen 系列小语言模型作为最终生成器。 输入到 SLM 的视觉 token 是图像上下文 token 与视频动态 token 的组合。 这种拆分让模型不用在一个笨重的视频编码器里同时承担空间和时间建模。

2.4 与常见 Video LMM 的差异

维度	常见 Video LMM	Mobile-VideoGPT
视觉输入	多帧全量输入	16 帧中选择 8 个关键帧用于视频编码
视觉编码器	大图像/视频 backbone	轻量图像编码器 + VideoMamba
投影器	常规 MLP projector	ET-Proj：MLP + token pooling + position encoder
语言模型	多为 7B 以上	0.5B / 1.5B 小语言模型
优化目标	更强 benchmark 结果	accuracy 与吞吐兼顾
部署假设	服务器 GPU 较常见	边缘/移动端友好

2.5 为什么这种组合合理

图像编码器先看所有帧，避免一开始就丢掉潜在关键画面。 Frame Scoring 只在较轻的图像特征上运行，选择成本低于先运行重视频编码器。 VideoMamba 只处理被选出的帧，时间建模成本降低。 ET-Proj 在进入 SLM 前减少视觉 token，总体上下文长度下降。 小语言模型避免被冗余视觉 token 淹没，回答速度更快。 三阶段训练使两个投影器和 SLM 逐步对齐，避免端到端一次性训练不稳定。

2.6 这篇论文最值得复用的点

如果目标是移动端实时视频理解，帧选择比盲目加帧更重要。 如果目标是小模型，视觉 token 数必须被主动控制。 如果视觉 token 被压缩，必须补偿位置信息，否则细粒度空间关系会受损。 如果同时使用图像和视频 encoder，训练时应分阶段对齐不同 projector。 论文的实证表明，0.5B 模型可以在多个 benchmark 上接近或超过更大模型，但细粒度动作/姿态任务仍会受帧数和分辨率限制。

3. Method (方法)

3.1 Overall framework

输入是一段视频和一条文本指令。 系统首先抽取固定数量的视频帧。 在代码中，mobilevideogpt/utils.py::preprocess_input 调用 _get_rawvideo_dec，并使用 NUM_FRAMES 与 NUM_CONTEXT_IMAGES 生成两组张量。 video_frames 用于视频编码器分支。 context_frames 用于图像编码器分支和帧评分。 文本 prompt 被包进 qwen2_instruct conversation template。 视觉占位符通过 tokenizer_image_token 插入到文本 token 中。 推理时调用 model.generate(..., images=..., context_images=...)。 语言模型的 generate 会把 images 和 context_images 继续传给 prepare_inputs_labels_for_multimodal。 该函数负责把视觉特征转换成可拼接到文本 embedding 的视觉 embedding。

3.2 双视觉编码器

论文采用两个视觉分支。 图像分支负责空间上下文。 视频分支负责时间动态。 代码中 MetaModel.initialize_vision_modules 根据 model_args.vision_tower 构建视频编码器。 同一函数根据 model_args.image_vision_tower 构建图像编码器。 如果存在视频 encoder，会创建 mm_projector。 如果存在图像 encoder，会创建 image_mm_projector。 两个 projector 可以有不同输入 hidden size。 VideoMamba 分支的 hidden size 在代码中对应 576。 图像分支则对应图像 encoder 的 hidden size。

3.3 Attention-Based Frame Scoring

论文的 Frame Selection 目标是从 (T) 帧中选出 (K) 帧。实验设置里常用 (T=16)，(K=8)。直觉是：若某一帧的 token 被其他 token 高度关注，它更可能包含全局重要信息。

设图像编码器输出的每帧空间特征为： [ X \in \mathbb{R}^{T \times H_s \times W_s \times D_s} ] 将所有帧展平成： [ Z \in \mathbb{R}^{S \times D_f},\quad S=T H_s W_s ] 计算 token-token 相似度： [ A = \operatorname{softmax}\left(\frac{ZZ^\top}{\sqrt{D_f}}\right) ] 再把每个 token 接收到的注意力按所属帧聚合，得到 frame-wise score： [ s_t = \sum_i A_{i, \text{tokens in frame } t} ] 最后选择： [ \mathcal{K} = \operatorname{TopK}(s, K) ] 代码实现位置：mobilevideogpt/model/arch.py::select_frame_in_chunk。

代码先把 (B,T,L,D) reshape 为 (B,T*L,D)。然后执行 torch.matmul(tokens, tokens.transpose(-1, -2)) / sqrt(D)。再通过 F.softmax 得到 attention weights。之后用 one-hot frame mask 把 token-level attention 聚合到 frame-level score。torch.topk 得到 top-K indices。topk_indices.sort(dim=1) 保持选中帧的时间顺序。

3.4 分 chunk 的关键帧编码

真实代码并不是对整段视频一次性选帧，而是按 chunk 处理。 encode_videos_by_seletive_frames 先把 context_images 经图像编码器变成 patch features。 然后按 CHUNK_SIZE 将帧分成多个 chunk。 每个 chunk 内独立运行 select_frame_in_chunk。 选出的帧再送入 VideoMamba。 VideoMamba 输出去掉 CLS token 后按每帧重新排列。 代码中还使用 apply_adaptive_avg_pooling(..., shape=(7,7)) 将视频特征池化到 49 个空间 token。 这一步对应论文中视频 token 的 8 × 49 = 392。 这种 chunk 内选择方式能避免长视频里早期/后期帧互相稀释评分。

3.5 Efficient Token Projector (ET-Proj)

ET-Proj 的作用是把视觉 encoder 输出压缩并映射到 SLM hidden size。代码实现位置：mobilevideogpt/model/multimodal_projector/builder.py::ETProjector。组件一：DenseMLP。DenseMLP 是 Linear -> GELU -> Linear。它先把视觉 hidden size 对齐到语言模型 hidden size。组件二：VideoTokenReducer。它内部是 nn.AdaptiveAvgPool2d(target_size)。

当输入维度 inc == 576 时，代码认为是 VideoMamba 特征，target size 为 (7,7)。当不是 576 时，代码认为是图像特征，target size 为 (12,12)。组件三：VideoPosEncoder。它是 depthwise-like 3×3 convolution 加 residual shortcut。作用是在 token 压缩后重新注入局部位置偏置。ET-Proj forward 流程是： 先做 MLP。将 (B,N,C) reshape 成 (B,H,W,C)。permute 成卷积友好的 (B,C,H,W)。AdaptiveAvgPool2d 压缩空间尺寸。PEG 卷积补充位置关系。

reshape 回 (B,H*W,C)。

3.6 视觉 token 预算

Supplementary Table 中给出 token efficiency 对比。 LLaVA-OneVision 使用 32 × 196 = 6,272 个 image tokens。 Mobile-VideoGPT 使用 16 × 144 = 2,304 个 image tokens。 Mobile-VideoGPT 额外使用 8 × 49 = 392 个 video tokens。 总视觉 token 数为 2,696。 相比 6,272，约减少 2.3×。 注意这里不是简单删掉视频信息。 Mobile-VideoGPT 用少量 video tokens 承担时间动态，用压缩后的 image tokens 保留空间上下文。 这个设计比“只保留少量帧”更稳，因为上下文帧仍以压缩形式进入 SLM。

3.7 多模态 embedding 拼接

代码核心函数：MobileVideoGPTMetaForCausalLM.prepare_inputs_labels_for_multimodal。 当 images 和 context_images 都存在时，它首先计算 num_frames 和 num_chunks。 然后调用 filter_tensors。 filter_tensors 会根据选中帧数量调整 input_ids、attention_mask 和 labels 中视觉占位符的位置。 接着调用 encode_videos_by_seletive_frames 得到 video_features 和 context_features。 再调用 project(..., input_type="video")。 project 会分别通过 mm_projector 和 image_mm_projector 映射视频与图像上下文。 随后把图像上下文特征和视频特征合并。 合并后的视觉 embedding 会替换文本序列中的 IMAGE_TOKEN_INDEX。 最终交给 Qwen causal LM 执行标准自回归生成。

3.8 推理伪代码

def mobile_videogpt_infer(video_path, prompt):
    # 1. 解码视频，得到两组帧
    video_frames, context_frames = decode_video(
        video_path,
        num_video_frames=NUM_FRAMES,
        num_context_images=NUM_CONTEXT_IMAGES,
        resolution=224,
    )
 
    # 2. 构造 Qwen-style 对话 prompt，并插入视觉占位符
    input_ids = build_qwen2_prompt_with_image_tokens(prompt)
 
    # 3. 图像分支先编码上下文帧
    context_features = image_encoder(context_frames, select_feature="patch")
 
    # 4. 对每个 chunk 运行 attention-based frame scoring
    selected_frames = []
    for chunk in split_into_chunks(context_frames, CHUNK_SIZE):
        score = aggregate_token_attention(chunk)
        selected_frames += topk_frames(score, K_per_chunk)
 
    # 5. 视频分支只编码选中的关键帧
    video_features = video_encoder(selected_frames)
 
    # 6. ET-Proj 分别压缩/投影图像与视频 token
    image_tokens = image_projector(context_features)
    video_tokens = video_projector(video_features)
 
    # 7. 合并视觉 token 与文本 embedding
    inputs_embeds = replace_image_placeholders(input_ids, image_tokens, video_tokens)
 
    # 8. 小语言模型生成答案
    return qwen_slm.generate(inputs_embeds)

3.9 Frame Scoring 伪代码（对应源码）

def select_frame_in_chunk(video_features, num_topk):
    # video_features: (B, T, L, D)
    B, T, L, D = video_features.shape
    tokens = video_features.view(B, T * L, D)
 
    # token-token attention
    logits = tokens @ tokens.transpose(-1, -2) / sqrt(D)
    weights = softmax(logits, dim=-1)
 
    # token -> frame mask
    frame_ids = repeat_interleave(arange(T), L)
    frame_mask = one_hot(frame_ids, num_classes=T)
 
    # frame score = how much attention each frame receives
    token_to_frame = weights @ frame_mask
    frame_score = token_to_frame.sum(dim=1)
 
    # keep temporal order after top-k selection
    indices = topk(frame_score, k=num_topk).indices
    return sort(indices)

3.10 ET-Proj 伪代码（对应源码）

def et_projector_forward(x, is_video):
    # x: (B, N, C_in)
    x = linear_gelu_linear(x)
    B, N, C = x.shape
    H = W = int(sqrt(N))
 
    # recover spatial grid
    x = x.view(B, H, W, C).permute(0, 3, 1, 2)
 
    # adaptive pooling
    if is_video:
        x = adaptive_avg_pool2d(x, output_size=(7, 7))
    else:
        x = adaptive_avg_pool2d(x, output_size=(12, 12))
 
    # positional encoding generator with residual
    x = depthwise_conv_3x3(x) + x
 
    # flatten back to tokens
    return x.permute(0, 2, 3, 1).reshape(B, -1, C)

3.11 三阶段训练

论文和 supplementary 表格给出三阶段训练策略。 Stage 1：Image Projection Pre-training。 图像编码器冻结。 视频编码器冻结。 Small Language Model 冻结。 Projection 可训练。 Batch size 128。 Learning rate 1e-3。 Cosine decay，warmup ratio 0.03。 AdamW。 训练 2 epochs。 Stage 2：Video Projection Pre-training。 图像编码器冻结。 视频编码器冻结。 Small Language Model 冻结。 Projection 继续可训练。 Batch size 128。 Learning rate 1e-3。 Cosine decay，warmup ratio 0.03。 AdamW。 训练 2 epochs。 Stage 3：Instruction Tuning。 图像编码器冻结。 视频编码器冻结。 Small Language Model 可训练。 Projection 可训练。 Batch size 64。 Learning rate 2e-4。 Cosine decay，warmup ratio 0.03。 AdamW。 训练 2 epochs。

3.12 代码映射

Code reference: main @ c82a4cbc (2025-08-07)

Paper Concept	Source File	Key Class/Function
推理入口与视频预处理	mobilevideogpt/utils.py	preprocess_input
视频解码与均匀采样	eval/video_encoding.py	_get_rawvideo_dec, read_frame_mod, uniform_sample
模型加载	mobilevideogpt/model/builder.py	load_pretrained_model
双视觉 encoder 初始化	mobilevideogpt/model/arch.py	MetaModel.initialize_vision_modules
Attention-Based Frame Scoring	mobilevideogpt/model/arch.py	MobileVideoGPTMetaForCausalLM.select_frame_in_chunk
分 chunk 关键帧编码	mobilevideogpt/model/arch.py	encode_videos_by_seletive_frames
图像/视频 projector 合并	mobilevideogpt/model/arch.py	project, prepare_inputs_labels_for_multimodal
ET-Proj	mobilevideogpt/model/multimodal_projector/builder.py	ETProjector, DenseMLP, VideoTokenReducer, VideoPosEncoder
Qwen causal LM 适配	mobilevideogpt/model/language_model/qwen.py	MobileVideoGPTQwenForCausalLM.forward, generate
lmms-eval 适配	eval/mobile_videogpt.py	MobileVideoGPT.generate_until
0.5B 训练脚本	scripts/Mobile-VideoGPT-0.5B_training.sh	pretrain / finetune stages
1.5B 训练脚本	scripts/Mobile-VideoGPT-1.5B_training.sh	pretrain / finetune stages

3.13 实现细节提醒

源码函数名中 encode_videos_by_seletive_frames 拼写为 seletive，笔记保持源码名以便搜索。 filter_tensors 依赖视觉占位 token 数量调整文本序列。 如果修改 NUM_FRAMES、NUM_CONTEXT_IMAGES 或 CHUNK_SIZE，必须同步检查视觉占位符数量。 Frame scoring 中 self.topK == False 时会取 smallest top-k；默认行为需要结合配置确认，不能只看论文描述。 README 的 inference 示例加载 Amshaker/Mobile-VideoGPT-1.5B，并以 images=torch.stack(video_frames)、context_images=torch.stack(context_frames) 传入生成函数。

4. Experimental Setup and Evidence (实验设置与证据)

4.1 Benchmark 范围

论文在六个视频理解 benchmark 上评估。 ActivityNet-QA / ActNet-QA：偏长视频问答和活动理解。 EgoSchema：第一人称长视频理解与推理。 MLVU：多任务长视频理解。 MVBench：20 个子任务，覆盖动作、对象、运动、场景、计数、属性等。 NextQA：视频问答，包含 causal、temporal、descriptive 等推理类型。 PerceptionTest / PercepTest：感知和时空理解。 Table 1 同时报告模型参数量、输入分辨率、帧数和吞吐。 这符合论文主张：不能只看 accuracy，必须同时看效率。

4.2 主实验设置

Model	Params	Res.	Frames	Throughput	ActNet-QA	EgoSchema	MLVU	MVBench	NextQA	PercepTest
LLaVA-OneVision-0.5B	1.0B	384×384	32	22.7	50.5	26.8	50.3	47.2	57.2	49.2
Mobile-VideoGPT-0.5B	0.6B	224×224	16	45.9	51.6	31.4	47.9	53.5	65.4	58.7
Mobile-VideoGPT-1.5B	1.6B	224×224	16	41.0	54.4	36.7	48.1	53.6	73.7	65.3

0.5B 版本参数量比 LLaVA-OneVision-0.5B 更小。 0.5B 版本输入分辨率更低。 0.5B 版本帧数更少。 0.5B 版本吞吐约为 45.9，对比 LLaVA-OneVision 的 22.7，约 2×。 0.5B 版本在 ActNet-QA、EgoSchema、MVBench、NextQA、PercepTest 上高于 LLaVA-OneVision-0.5B。 但在 MLVU 上低于 LLaVA-OneVision-0.5B。 1.5B 版本在 NextQA 和 PercepTest 上进一步提升明显。 1.5B 版本吞吐略低于 0.5B，但仍高于 LLaVA-OneVision-0.5B。

4.3 MVBench 细粒度证据

MVBench overall average： Video-ChatGPT：32.7。 Video-LLaMA：34.1。 Video-LLaVA：43.1。 LLaVA-Mini：44.5。 LLaVA-OneVision：47.2。 Mobile-VideoGPT-0.5B：53.5。 论文强调 0.5B 模型在 MVBench 上取得最高 overall average。 强项包括 object existence、moving direction、moving count、moving attribute、state change 等任务。 例如 object existence 中 Mobile-VideoGPT 得到 82.5。 moving direction 得到 59.0。 moving count 得到 63.5。 moving attribute 得到 81.0。 这些结果支持“关键帧 + 视频动态 token”确实能帮助对象和运动相关问题。 但 fine-grained pose 上 Mobile-VideoGPT 为 28.0，低于部分基线。 这说明低分辨率和少帧数会影响细粒度姿态识别。

4.4 架构消融

Benchmark	Image encoder	Video encoder	Dual w/ FS	w/o FS	Attn-Based FS	MLP_proj	ET_proj
ActNet-QA	51.4	49.3	51.6	51.3	51.6	50.9	51.6
EgoSchema	26.5	27.1	31.4	31.2	31.4	30.5	31.4
MLVU	43.0	48.2	47.9	48.3	47.9	45.0	47.9
MVBench	52.4	49.6	53.5	54.0	53.5	54.9	53.5
NextQA	62.1	62.6	65.4	65.3	65.4	64.9	65.4
PercepTest	58.3	58.0	58.7	58.7	58.7	58.7	58.7

双 encoder 相比单图像/单视频 encoder 在多个任务上更稳。 EgoSchema 从单图像 26.5 / 单视频 27.1 提升到双分支 31.4。 NextQA 从 62.1 / 62.6 提升到 65.4。 ET-Proj 在 EgoSchema、MLVU、ActNet-QA 上优于普通 MLP projector。 MVBench 上 MLP_proj 为 54.9，高于 ET_proj 的 53.5；这说明 ET-Proj 不是所有任务都绝对更高，而是用较低 token 预算换取整体效率。 Frame Selection 在平均效果上接近不使用 FS，但能提高吞吐。 因此消融的正确解读是：Mobile-VideoGPT 的优势主要来自系统级组合，而不是单个模块在所有指标上独胜。

4.5 帧数与效率消融

Setting	Fine-grained Action	Fine-grained Pose	Throughput
16 frames	39.8	32.4	38.5
16 frames + FS	36.5	28.0	45.9
32 frames	43.3	41.6	30.2
32 frames + FS	41.2	37.8	36.7

增加帧数从 16 到 32 会提升细粒度动作和姿态识别。 32 frames 在 fine-grained action 上达到 43.3。 32 frames 在 fine-grained pose 上达到 41.6。 但 32 frames 的 throughput 降到 30.2。 加入 FS 后吞吐提高。 16 frames + FS 从 38.5 提高到 45.9。 32 frames + FS 从 30.2 提高到 36.7。 代价是细粒度 action/pose 准确率下降。 这个表直接揭示了论文方法的边界：效率收益依赖于删帧，而删帧会影响细粒度时空线索。

4.6 Token efficiency 证据

Model	Projection Strategy	Image Tokens	Video Tokens	Total Tokens
LLaVA-OneVision	MLP_proj	32×196=6,272	—	6,272
Mobile-VideoGPT	ET_proj + FS	16×144=2,304	8×49=392	2,696

Mobile-VideoGPT 的总视觉 token 数约为 LLaVA-OneVision 的 43%。 2.3× token reduction 是其吞吐优势的重要来源。 这种 token reduction 来自两个层面。 第一，帧数从 32 降到 16，并且视频分支只用 8 个关键帧。 第二，ET-Proj 把图像和视频的空间 token 从 14×14 等更高网格压到 12×12 或 7×7。 因此吞吐提升不是单靠小语言模型，而是视觉侧 token 管线整体变短。

4.7 训练配置证据

Item	Stage 1 Image Proj. Pre-training	Stage 2 Video Proj. Pre-training	Stage 3 Instruction Tuning
Image Encoder	Frozen	Frozen	Frozen
Video Encoder	Frozen	Frozen	Frozen
Small Language Model	Frozen	Frozen	Trainable
Projection	Trainable	Trainable	Trainable
Batch Size	128	128	64
Learning Rate	1e-3	1e-3	2e-4
Schedule	Cosine decay	Cosine decay	Cosine decay
Warmup Ratio	0.03	0.03	0.03
Optimizer	AdamW	AdamW	AdamW
Epochs	2	2	2

训练策略的重点是先让投影器学会对齐视觉和语言空间。 最后阶段才放开 SLM，降低训练不稳定风险。 视觉 encoder 全程冻结，符合移动端轻量化和训练成本控制的目标。 对复现者来说，不能只看模型结构，还需要按阶段加载不同数据和可训练模块。

5. Experimental Results, Analysis, and Limitations (结果、分析与局限)

5.1 主要结论

Mobile-VideoGPT-0.5B 是一个效率优先但仍具备较强视频理解能力的模型。 它不是所有指标最高。 但它在参数量、输入分辨率、帧数、视觉 token 数和 throughput 之间取得了很好的平衡。 在 Table 1 中，0.5B 版本相对于 LLaVA-OneVision-0.5B 用更少参数、更少帧和更低分辨率，在 5/6 个列出的 benchmark 上更高。 1.5B 版本进一步提升 NextQA 到 73.7，PercepTest 到 65.3。 这说明模型规模增大仍有效，但效率会有所下降。

5.2 结果如何支持方法设计

MVBench 的 object / moving / attribute 相关任务表现强，说明双分支对对象和运动线索都有帮助。 Token efficiency 表说明视觉 token 缩短是吞吐提升的直接机制。 帧数消融说明 FS 能提高吞吐，但会牺牲细粒度线索。 架构消融说明单独 image encoder 或 video encoder 都不够稳。 ET-Proj 与 MLP_proj 的对比说明 token 压缩不一定每项都提升 accuracy，但能支撑整体速度目标。 三阶段训练说明投影器对齐是该架构可训练的关键。

5.3 定性结果

定性示例展示了开放式视频问答、多轮对话和事件描述。 这些例子主要用于说明模型可以输出连贯自然语言，而不是只做多选 benchmark。 对比 LLaVA-OneVision-0.5B 和 LLaVA-Mini-8B 时，论文强调 Mobile-VideoGPT 的 latency / throughput 更低。 定性图中的价值在于展示小模型在真实场景描述中并非只会短答。 但定性结果不能替代系统性评测，仍需结合 Table 1、MVBench 细分表和消融表阅读。

5.4 局限性

第一，细粒度动作和姿态识别受限。 Supplementary 中明确指出，低分辨率和少帧数会丢失细微空间/时间线索。 这在 fine-grained action 和 fine-grained pose 消融中很明显。 第二，Frame Selection 的收益依赖视频内容。 如果关键信息分散在多个短暂瞬间，top-K 可能会漏掉低注意力但关键的帧。 第三，低分辨率 224×224 对文字、细小物体和微表情可能不友好。 第四，小语言模型的复杂推理能力仍有限。 对长链推理、跨镜头因果推理和需要外部知识的问题，0.5B/1.5B SLM 可能不如更大模型。 第五，ET-Proj 的压缩可能损失局部几何关系。 位置卷积能补偿一部分，但不能完全恢复原始 patch 细节。 第六，代码中部分行为需要结合配置确认，例如 self.topK 的取值会影响 torch.topk 选择 largest 还是 smallest。

5.5 与相关方向的关系

相比大规模 Video LMM，Mobile-VideoGPT 更强调边缘部署。 相比纯帧采样方法，它使用 attention-based score 而不是固定均匀采样。 相比只做 projector 压缩的方法，它同时做帧选择和 token 压缩。 相比只用图像 encoder 的模型，它加入 VideoMamba 捕捉时间动态。 相比只用视频 encoder 的模型，它保留图像上下文帧作为空间语义来源。 因此它的贡献是系统整合，而不是单点 trick。

5.6 实践复现建议

如果只想跑推理，优先看 README 的 Running Inference。 模型路径可用 Amshaker/Mobile-VideoGPT-1.5B 或 0.5B checkpoint。 需要安装 VideoMamba 依赖。 训练还需要 FlashAttention。 如果复现实验，优先使用 eval/README.md 和 eval/Mobile-VideoGPT-evaluation.sh。 如果复现训练，优先使用 scripts/Mobile-VideoGPT-0.5B_training.sh 或 scripts/Mobile-VideoGPT-1.5B_training.sh。 修改帧数时，需要同步确认 NUM_FRAMES、NUM_CONTEXT_IMAGES、chunk 逻辑和占位 token 数。 修改 projector 时，需要重新检查 token 数是否与 language model 输入拼接逻辑一致。 修改 frame selection 策略时，应同时报告 throughput 和 fine-grained action/pose。

5.7 适合借鉴的后续方向

自适应 (K)：不同视频按内容复杂度动态选择帧数，而不是固定 (K=T/2)。 任务感知帧选择：对细粒度动作/姿态问题保留更多帧，对粗粒度场景问题保留更少帧。 多尺度 token 压缩：同时保留少量高分辨率局部 token 和大量低分辨率全局 token。 更强的小语言模型：替换为更新的 SLM 可能进一步提高推理能力。 端侧真实延迟评测：除 RTX A6000 / Jetson tokens/sec 外，可补充功耗、内存峰值和冷启动时间。 鲁棒性评测：测试快动作、遮挡、字幕、低光照、长视频和镜头切换密集场景。

5.8 个人总结

这篇论文的价值在于把视频理解中的“看得多”和“答得快”拆开重新平衡。 它承认移动端预算下不可能无限增加帧数和 token。 因此它把模型设计重点放在“哪些帧值得看”和“哪些 token 值得保留”。 从系统角度看，Attention-Based Frame Scoring 负责减少时间冗余。 ET-Proj 负责减少空间 token 冗余。 双视觉 encoder 负责避免过度压缩导致时间或空间信息完全丢失。 三阶段训练负责让这些压缩后的视觉 token 能被 SLM 理解。 如果任务目标是实时、低成本、多路视频理解，Mobile-VideoGPT 是一个值得优先复现的 baseline。 如果任务目标是高精度细粒度动作/姿态识别，则需要增加帧数、分辨率或引入更任务感知的帧选择策略。