Commercial Reality — Gemini, Twelve Labs, OpenAI/Anthropic, Open-source

Chapter 3~7에서 우리는 AKS, BOLT, Frame-Voyager, Q-Frame, AdaRD-Key, FOCUS, VideoChat-Flash 등 sampling 연구의 frontier를 훑었다. 모두 uniform baseline 대비 명확한 정확도 우위를 보였고, 일부는 ~93% frame 감축에서도 등가의 성능을 보였다. 그런데도 2026년 6월 현재 상용 video-LLM API를 열어보면 — Gemini 2.5 Pro는 1 fps, Qwen2.5-VL은 2 fps, InternVL은 uniform 16-32 frame, LLaVA-Video는 uniform 64 frame — 누구도 그 연구 SOTA를 default로 채택하지 않았다. 이 갭은 우연이 아니다. 이 chapter는 (a) 각 상용 player가 어떤 구체적 선택을 했는지, (b) 왜 그것이 economically rational인지, (c) 어디서만 예외가 생기는지(retrieval indexing)를 정직하게 살펴본다. 결론은 disappointing하지만 중요하다 — 당신이 production system을 만든다면, 첫 버전은 uniform/fps-based로 시작해야 한다. SOTA sampler는 measured pain point가 생긴 후 swap-in할 plugin으로 설계되어야지, day-one default가 아니다.

1. Gemini 2.5 Pro — 1 fps라는 솔직한 default

Google의 Gemini 2.5 Pro는 2026년 현재 가장 널리 쓰이는 production video understanding API이다. Document 어디를 봐도 fancy keyframe selection은 없다. Default sampling rate는 1 fps, configurable range는 0.1 fps ~ 24 fps (videoMetadata.fps parameter). Visual은 frame당 258 tokens, audio는 parallel하게 1 Kbps로 처리된다.

수치를 정리하면: - 1 fps × 258 tokens/frame ≈ 15,480 tokens/min (audio 제외) - 1M context window 기준 ≈ 1시간 video (default fps) - 2M context + low-resolution mode ≈ 6시간 video - 가격은 분당 약 $0.015 수준 (입력 video token 기준 환산)

왜 1 fps인가? Google이 공개한 official rationale은 'human-speech granularity' — 사람의 발화 음절·단어 단위와 비슷한 sampling rate이고, 대부분의 narration/dialogue 기반 video QA에는 충분하다는 것. 더 본질적으로는 1 fps가 (a) cost를 predictable하게 만들고 (분당 정확히 N tokens), (b) benchmark를 reproducible하게 만들고 (uniform이라 randomness 없음), (c) latency variance를 0으로 만든다 (query-conditioning이 없으므로 prefill이 결정적).

사용자에게 주는 knob은 videoMetadata.fps 단 하나. fps=0.5로 낮추면 영상 길이를 2배로 늘릴 수 있고 (느린 영상, 강의), fps=2~5로 올리면 빠른 motion (sports, gaming)을 잡을 수 있다. 그러나 query-aware 동적 조절은 없다. AKS/BOLT를 쓰고 싶다면 client side에서 직접 frame을 select해서 image batch로 보내야 한다 — Gemini 자체는 video를 알아서 sample한다.

2. Twelve Labs — Multi-vector dense indexing이라는 다른 길

Twelve Labs (Marengo 3.0 임베딩 모델 + Pegasus 1.2 생성 모델, 2026 라인업)는 sampling 문제에 전혀 다른 답을 낸다. 그들은 video를 약 6초 chunk로 자르고, 각 chunk에서 visual + audio + ASR + motion을 합친 multi-vector dense embedding을 추출한다. 즉, '몇 frame을 고를까?'를 묻지 않고 '모든 segment에 high-dimensional embedding을 미리 입혀두자'를 선택했다.

Key design decisions: - Chunk size ≈ 6s — shot 길이의 통계적 중간값에 맞춤 - Joint modality embedding — visual / audio / ASR transcript / motion이 한 vector에 entangled - Built for retrieval, not inference QA — query는 vector similarity search로 relevant chunk를 찾고, 그 chunk만 Pegasus generative model에 넘긴다 - Pricing: Bedrock 기준 input 1M tokens당 ~$0.07. 분당 indexed cost는 별도 (per-minute indexed)

이것이 작동하는 이유는 cost amortization이다. Index time에는 fancy multi-modal encoding을 써도 괜찮다 — 한번만 한다. 그 후 천 번의 query가 들어와도 retrieval은 vector 비교 한 번에 끝난다. 반대로 Gemini는 매 query마다 video를 처음부터 decode + sample + encode + LLM forward해야 하므로, 처음부터 cheap한 uniform이 합리적이다.

Twelve Labs도 사실은 'sampling'을 하긴 한다 — 6초 chunk라는 fixed-duration uniform이다. Adaptive는 아니다. 단지 sampling output을 frame이 아니라 embedding으로 저장한다는 점이 다르다.

3. OpenAI와 Anthropic의 의도된 부재

가장 솔직해야 할 부분이다. OpenAI는 native video understanding API가 없다. GPT-4o, GPT-4.1 모두 video 입력을 받지 않는다. Official cookbook의 가이드는 '~1 fps로 client-side에서 frame을 뽑아서 image batch로 보내라'다. Sora 2는 generation 전용 (10-25초 clip 생성)이지 understanding이 아니다.

Anthropic의 Claude는 한 발 더 나간다. Video를 아예 입력으로 받지 않는다. Image만, 그리고 PDF의 frame을 image로 변환해야 한다.

왜 두 frontier lab이 video를 deprioritize했을까?

1. TCO가 안 맞는다. Video 1분 = image 60~1800개. Frontier model의 per-token cost 구조에서 video는 image 대비 60~1800배 비싸지만, 사용자가 분당 그만큼의 가치를 지불할 use case는 좁다 (compliance 검토, 의료 영상, 강의 요약 등 vertical 시장). General-purpose chatbot에서는 ROI가 안 나온다.

2. Encoder/decoder pipeline이 무겁다. Video는 decode (codec 의존), sample (정책 의존), encode (visual encoder GPU 비용)의 3단 pipeline이 들어가는데, 이는 OpenAI/Anthropic의 LLM-centric serving 아키텍처에 어울리지 않는다. Gemini는 Google의 YouTube infra 위에 얹은 advantage가 있어서 가능했다.

3. Evaluation이 어렵다. Text/image와 달리 video QA는 benchmark variance가 크고 (sampling 선택만 바꿔도 점수가 크게 흔들린다), customer-facing quality가 측정하기 어렵다.

결과적으로 OpenAI/Anthropic은 video를 '나중에', '필요해지면 partner를 통해' 정도로 미뤘다. 이는 frame sampling 연구가 production에 흡수되지 않은 또 하나의 이유다 — 가장 큰 두 LLM lab의 default가 video를 다루지 않는다.

4. Open-source defaults — 일관된 uniform 패턴

오픈소스 video-LLM의 default 표를 모아보면 패턴은 더 분명하다.

공통 패턴이 명확하다: - 누구도 query-aware adaptive sampling을 default로 두지 않는다. AKS, BOLT, Q-Frame이 plug-in으로 쓸 수 있게 만들어졌음에도 불구하고. - fps-based이든 uniform-N이든 결정적이다. 같은 input에 대해 같은 frame이 뽑힌다. - Frame cap이 있다. 64~768. Cap을 넘으면 uniform downsample. - Sampling 정책은 model card / config의 한 줄. Algorithm이 아니라 number.

이는 우연이 아니다. 이 model들의 training data 자체가 uniform sampling으로 만들어진 frame sequence를 input으로 받은 supervision으로 학습되었다. Inference time에 갑자기 AKS로 sampling 분포를 바꾸면 train-test distribution mismatch가 발생하고, 일부 benchmark에서는 오히려 성능이 떨어진다. 즉, uniform은 단순한 default가 아니라 model의 trained behavior와 결합된 default다.

5. Retrieval exception — Mixpeek과 index-time amortization

위 패턴에서 명시적으로 벗어나는 곳이 있다. Mixpeek은 PySceneDetect 기반 shot detection으로 chunk를 만들고, 각 chunk에 vuse-generic-v1 embedding + transcript + face recognition + OCR을 entity-level로 입힌다. 이건 uniform이 아니다 — content-aware adaptive segmentation이다.

Twelve Labs도 같은 결을 따른다. 6초 chunk가 uniform처럼 보이지만 그들의 indexing pipeline은 multi-modal joint encoding을 매 chunk에 수행한다 — Gemini의 single visual encoder pass보다 훨씬 무겁다.

왜 retrieval 시스템만 이게 가능한가? Cost amortization 때문이다.

• Inference-time (Gemini, Qwen, LLaVA): 사용자 query 1회 = sampling 1회 + LLM forward 1회. 매 query마다 sampling cost를 지불한다. Cheap한 uniform이 이긴다.
• Index-time (Twelve Labs, Mixpeek): video 등록 1회 = sampling/encoding 1회 + query는 vector search로 cheap. 한번 비싸게 sampling을 해두면 1,000번의 query가 그것을 공유한다.

수치적으로, video 1시간에 AKS-style query-aware sampling을 적용하는 데 5초가 더 걸린다 치자. Inference 시스템에서는 사용자 latency에 5초가 더해진다 (각 query마다). Index 시스템에서는 등록 1회에 5초가 더해지고 query latency는 그대로 (~100ms vector search)다. 1,000개 query면 inference는 5,000초 누적, index는 5초 누적.

이것이 commercial reality의 핵심 분기점이다. Adaptive/fancy sampling을 쓰고 싶다면 시스템을 retrieval로 설계해야 한다. Inference-time generative QA를 한다면 uniform이 거의 항상 이긴다 — 적어도 default로는.

6. 갭이 영구히 존재하는 이유

이 chapter의 thesis는 단순하다 — 연구 SOTA와 production의 갭은 일시적 lag이 아니라 구조적이다. Production engineer가 uniform을 고르는 이유는 게으르거나 무지해서가 아니라, 다음 6가지 properties가 어떤 정확도 향상보다 비싸기 때문이다.

1. Predictable cost — 1분 video = 정확히 N tokens. Finance/quoting/SLA가 가능하다. Adaptive sampler는 video 내용에 따라 cost가 흔들린다.

2. Easy benchmarking — 같은 input에 같은 output. Regression test가 가능하다. Stochastic/query-conditioned sampler는 매번 다른 결과.

3. No query-conditioning latency — Prefill을 model warmup 전에 시작할 수 있다. Adaptive sampler는 query를 봐야 sampling이 시작된다 — 사용자 latency가 늘어난다.

4. No additional training/finetuning — 모델 변경 시 sampler도 재훈련하지 않는다. AKS/BOLT가 'training-free'를 강조해도, 실제로는 base model의 train distribution과의 mismatch가 있어 fine-tuning이 도움이 되는 경우가 많다.

5. Debuggable — '왜 이 frame을 골랐나?'에 'frame 1, 31, 61, ...'이 답이 된다. Adaptive sampler는 'CLIP score 0.73, top-K cutoff'를 설명해야 한다.

6. Failure mode가 알려져 있다 — Uniform이 실패하는 곳 (긴 video, sparse event)을 정확히 알고 있다. Adaptive sampler의 failure mode는 새 vid가 들어올 때마다 발견된다.

이는 데이터베이스가 B-tree를 default로 쓰는 이유와 같다. LSM tree, fractal tree, hash index 등이 특정 workload에서 더 빠르지만, B-tree의 known properties (logarithmic, ordered, range scan, lock 동작 등)이 production engineer에게 더 값지다. Known beats optimal, 늘 그렇다.