2026-06-08 — 次浏览
llama.cpp 取得原生视频输入:FFmpeg 子进程解码进驻 mtmd 堆栈
2026 年 6 月 8 日,llama.cpp 合并了 PR #24269,为其多模态(mtmd)子系统加入原生视频输入。它并非链接 FFmpeg,而是调用 FFmpeg 子进程来解码帧,并通过新的惰性位图 API,在 tokenization 阶段将单一视频标记展开为已解码的帧。此设计与模型无关,因此 Qwen3-VL 与 Gemma-4 等既有视觉模型只需极少量的 CLI/服务器变更,即可在本地硬件上取得视频功能。
推出了什么
2026 年 6 月 8 日,llama.cpp 合并了 PR #24269(作者 ngxson,由 ggerganov 审查),为其多模态子系统 mtmd 加入原生视频输入。此变更关闭了早在 2025 年 12 月就勾勒出计划的 issue #18389,并实现了维护者在 FOSDEM 2026 多模态支持演讲中列出的三项路线图项目之一(另外两项为文本转语音与图像生成)。此功能出现在 build b9562 及之后的版本。
在此之前,在 llama.cpp 上对一段视频运行视觉语言模型,意味着你得自行解码该片段,并将帧以一连串静态图像的形式喂入。如今视频对 CLI 与服务器而言都是一等公民的输入类型。
运作方式
有趣的工程抉择关乎避免痛点,而非追求峰值吞吐量。
在解码方面,llama.cpp 不链接 libavcodec,也不内附编解码器。它改为将 FFmpeg 作为外部子进程来调用(该 issue 讨论串将此方案与对 libavcodec 进行 dlopen 相互权衡,并直接否决了静态链接,指出其「在实务上会导致糟糕的用户体验」)。背后有两项动机:它能规避专有格式带来的编解码器授权复杂性,并让构建保持无依赖。代价是用户必须另行安装 FFmpeg;它并未随 llama.cpp 一同发布。
在 tokenization 方面,一个新的惰性位图 API(mtmd_bitmap_init_lazy)为每段视频接受单一 <__media__> 标记,并在 tokenization 阶段将其展开为多个已解码的图像帧。由于帧展开发生于库内部,服务器与 CLI 只需极少量变更即可取得完整的视频支持。对于会融合帧的模型(例如 Qwen 的 3D 卷积路径),内部的 clip_image_f32 结构被赋予了额外一个维度,以便将多个帧批量组合在一起。
结果与模型无关:GGUF 生态系中任何既有的视觉模型都能在不做逐模型修改的情况下接受视频。维护者在 CLI 上测试了 Qwen3-VL-2B,并在 web UI 中测试了 Gemma-4-E4B,使用的是出自 Blender 开源短片 Agent 327 的一段 10 秒片段。讨论串中规划的近期后续工作包括 --video-ffmpeg-path 与 --video-fps 标志,以及作为独立轨道的音频输入。
为何对本地推理至关重要
| 方面 | 之前 | PR #24269 之后 |
|---|---|---|
| 视频处理 | 手动提取帧,以图像序列喂入 | 单一 <__media__> 标记,库解码帧 |
| 编解码器依赖 | 无(你自己的问题) | FFmpeg 子进程,未内附、未链接 |
| 模型变更 | 逐管线黏合 | 与模型无关;可用于既有 GGUF 视觉模型 |
| 接口 | 临时脚本 | CLI 与 llama-server,一等公民 |
最初的功能请求直白地点出了其中的关键:视频理解正在「从专门的专有 API 走向本地推理」,其回报是「在消费级硬件上进行保护隐私的视频分析,而无需沉重的 Python 依赖」。这道出了为何由 C/C++ 运行环境承担视频处理如此重要。人们早已用于本地文本与图像推理的同一批工作站级与统一内存机器,如今能在没有云端 API、也没有 PyTorch 堆栈的情况下,运行时序推理工作负载(事件定位、动作与因果问题、具身代理感知)。
基于子进程的解码器也很契合本地硬件的现实。相对于视觉编码器与 LLM 解码流程,帧解码成本低廉,因此把它交给一个久经实战的外部可执行文件代价甚微,同时又能规避原本会拖累采用的构建系统与授权麻烦。
从业者须知
若你想尝试,请取得 b9562 或更高版本的 build,在 PATH 上安装 FFmpeg,并用如 Qwen3-VL 或 Gemma-4 之类的视觉模型,将一段视频指向 llama-mtmd-cli 或 llama-server。请留意你的帧数量:惰性展开器会把一个标记变成许多图像 token,因此高采样率下的长片段可能很快撑爆上下文长度与 KV 内存。在 --video-fps 广泛落地之前,请把有效帧率视为决定某片段能否在特定机器上塞进你上下文预算的那根杠杆。而由于 FFmpeg 是独立的子进程,请在你的环境中固定其版本,以使解码行为在各机器间维持可复现。
被低估的角度
那个悄然重要的细节是其授权态势。借由拒绝链接或内附编解码器,改为调用用户自行安装的任何 FFmpeg,llama.cpp 让自身的分发保持干净、不含受专利约束的解码器,同时仍支持人们实际拥有的杂乱真实世界格式。这正是那种鲜少登上基准图表、却决定了一项功能能否在以宽松授权、广泛再分发之二进制文件中得以推出的抉择。它也微妙地将合规负担转移到操作者的环境,而对一个本地优先的工具而言,那正是它该在的位置;其他至今回避视频的运行环境,最终或许也会仿效这种模式。
Sources
- llama.cpp Releases (b9562, June 8 2026, video input feature) — ggml-org/llama.cpp ↗
- mtmd: plan to add video input support · Issue #18389 (closed by PR #24269) — ggml-org/llama.cpp ↗
- llama.cpp Adds Video Input via FFmpeg Subprocess — AI Weekly ↗
- Feature Request: Add Video Modality Support (Qwen2.5-VL) via llama-mtmd-cli · Issue #17660 — ggml-org/llama.cpp ↗
- Multimodal support in llama.cpp — Achievements and Future Directions (FOSDEM 2026) ↗