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) ↗