2026-06-08 — 회 조회

llama.cpp, 네이티브 동영상 입력 확보: FFmpeg 서브프로세스 디코딩이 mtmd 스택에 안착

2026년 6월 8일, llama.cpp는 PR #24269를 병합하여 멀티모달(mtmd) 하위 시스템에 네이티브 동영상 입력을 추가했다. FFmpeg를 링크하는 대신 FFmpeg 서브프로세스를 호출해 프레임을 디코딩하며, 새로운 지연 비트맵 API가 단일 동영상 마커를 토큰화 시점에 디코딩된 프레임으로 확장한다. 이 설계는 모델 비의존적이어서 Qwen3-VL과 Gemma-4 같은 기존

무엇이 출시되었나

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를 외부 서브프로세스로 호출한다(이슈 스레드는 이를 libavcodec의 dlopen과 견주어 보고 정적 링크를 “실제로는 나쁜 UX로 이어질 것”이라고 지적하며 곧장 기각했다). 여기에는 두 가지 동기가 있다. 독점 포맷에서 비롯되는 코덱 라이선스 복잡성을 피할 수 있고, 빌드를 의존성 없이 유지할 수 있다는 점이다. 절충점은 사용자가 FFmpeg를 별도로 설치해야 한다는 것이며, 그것은 llama.cpp와 함께 배포되지 않는다.

토큰화 쪽에서는, 새로운 지연 비트맵 API(mtmd_bitmap_init_lazy)가 동영상마다 단일 <__media__> 마커를 받아 토큰화 시점에 이를 여러 개의 디코딩된 이미지 프레임으로 확장한다. 프레임 확장이 라이브러리 내부에서 일어나므로 서버와 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로 향하게 하라. 프레임 수에 주의하라. 지연 확장기는 하나의 마커를 다수의 이미지 토큰으로 바꾸므로, 높은 샘플링 레이트의 긴 클립은 컨텍스트 길이와 KV 메모리를 빠르게 폭증시킬 수 있다. --video-fps가 널리 안착하기 전까지는, 실효 프레임 레이트를 어떤 클립이 특정 머신에서 당신의 컨텍스트 예산에 들어맞는지를 결정하는 지렛대로 다루라. 그리고 FFmpeg는 별도의 서브프로세스이므로, 디코딩 동작이 머신 간에 재현 가능하도록 환경에서 그 버전을 고정하라.

충분히 고려되지 않은 각도

조용히 중요한 세부 사항은 그 라이선스 태세다. 코덱을 링크하거나 번들하기를 거부하고 대신 사용자가 설치한 어떤 FFmpeg든 호출함으로써, llama.cpp는 자신의 배포물을 특허에 얽매인 디코더로부터 깨끗하게 유지하면서도, 사람들이 실제로 가진 지저분한 현실 세계의 포맷을 여전히 지원한다. 이는 벤치마크 차트에는 좀처럼 오르지 않지만, 관대한 라이선스로 널리 재배포되는 바이너리에서 어떤 기능이 애초에 출시될 수 있는지를 좌우하는 종류의 결정이다. 그것은 또한 컴플라이언스 부담을 운영자의 환경으로 교묘하게 옮기는데, 로컬 우선 도구에서는 그곳이 그 부담의 올바른 자리다. 그리고 이는 지금까지 동영상을 피해 온 다른 런타임들이 결국 모방하게 될 수도 있는 패턴이다.