DL0116 Video VLM Temporal Sampling

How do video VLMs balance temporal sampling resolution against KV cache memory limits when processing multi-hour video streams, as in Google’s Gemini video understanding?

Answer

A video VLM has no separate temporal-resolution dial: it flattens the stream into one token sequence, so frame rate, tokens per frame, and clip length all collapse into a single token count N = f \cdot T \cdot t_f, and that count fixes both the KV cache size (linear in N) and the prefill cost (quadratic in N). Two hours sampled at 1 fps with 64 tokens per frame is 460,800 tokens; on a Llama-3-8B-class decoder with 32 layers, 8 KV heads of head dimension 128, and a bf16 cache, each token costs 128 KB of KV, so the cache alone is roughly 60 GB, against the roughly 62 GB an 80 GB H100 has free after weights and activations. Multiply the frame rate by four or keep the encoder’s full 256 tokens per frame and you are at 240 GB, which no single device holds. Production systems therefore invert the question: fix a token budget from the memory and latency SLO first, then decide how to spend it across time and space. The three levers are temporal subsampling (fewer frames), token compression (pooling, merging, or resampling each frame), and bounded state (a sliding window plus a compressed memory bank or an offline retrieve-then-read pass), and only the third one makes memory independent of stream length.

(1) Tokens Are The Currency: memory scales as O(N) and prefill attention as O(N^2), so a 4x frame-rate increase is a 4x memory bill and a 16x prefill bill.
(2) Per-Token KV Cost Is Architectural: m = 2 L n_{kv} d_h b bytes, so GQA with 8 KV heads instead of 32 already cuts it 4x, and INT4 KV quantization cuts it another 4x before any sampling change.
(3) Equal Memory, Different Failures: halving f and quartering t_f can cost the same tokens, but the first causes temporal aliasing of short events while the second destroys small text and fine spatial detail.
(4) Slow-Fast Splitting: strong systems decouple the two axes, keeping many frames at very few tokens for motion and a handful of keyframes at full spatial resolution for detail.
(5) Adaptive Beats Uniform At Fixed Budget: dropping near-duplicate frames by feature similarity and selecting query-relevant segments spends the same tokens on the informative part of the timeline.
(6) Time Grounding Must Survive Downsampling: position encodings need absolute timestamps, not token indices, or a variable frame rate makes the model’s answers about “when” drift.

Log-scale bar chart of KV cache size for a two-hour video under six configurations: 242 GB at 1 fps with 256 tokens per frame, 60 GB at 1 fps with 64 tokens, 30 GB at 0.5 fps, 15 GB at 16 tokens per frame, 15 GB with INT4 cache, and under 1 GB for a streaming window plus memory bank, against a 62 GB device budget line

Figure 1: KV cache for the same two-hour video under six budgets. Memory depends only on the product f \cdot T \cdot t_f and the per-token cost, so sampling changes and cache quantization are interchangeable for memory, but only a bounded streaming state stops growth with stream length.

The reason the two sampling axes are not interchangeable for accuracy is that they alias different things. Uniform sampling at 1 fps is enough for plot-level questions over an hour of footage but silently deletes any event shorter than a second, which is why counting, ordering, and “who handed what to whom” questions collapse at low frame rates. Cutting tokens per frame is safe for gist and scene recognition and catastrophic for anything requiring OCR of on-screen text or small-object detail. Public systems make these trade-offs explicit: Gemini samples video at 1 fps with about 258 tokens per frame by default, which is roughly 0.93M tokens per hour and effectively consumes a 1M-token context, and offers a low-resolution mode at about 66 tokens per frame that stretches the same window to several hours. For genuinely unbounded streams the only stable design is bounded state: keep the last few tens of seconds as an exact KV window with attention sinks so the distribution stays in-domain, merge evicted frames into a fixed-size memory bank, and for offline archives replace dense prefill with a two-pass pipeline that indexes cheap summaries and then re-decodes only candidate segments at high frame rate.

Mathematical Formulation:
N = f \cdot T \cdot t_f
m = 2 L n_{kv} d_h b
M_{kv} = m \cdot N
C_{prefill} = O(N^2 d)
f_{max} = \frac{M_{budget}}{m \cdot T \cdot t_f}
m = 2 \cdot 32 \cdot 1024 \cdot 2 = 131072
N = 1 \cdot 7200 \cdot 64 = 460800

Where:

  • N is the total visual token count fed to the decoder, f the sampling rate in frames per second, T the stream duration in seconds, and t_f the tokens retained per frame after pooling or resampling.
  • m is the KV bytes per token, with L layers, n_{kv} key-value heads, head dimension d_h, and b bytes per stored element; the factor 2 counts keys and values.
  • M_{kv} is cache size and M_{budget} the free HBM after weights, activations, and the text prompt; f_{max} is the highest frame rate a dense prefill can afford at a given t_f.
  • C_{prefill} is prefill attention cost with model width d; it usually binds before memory does, since doubling N quadruples time to first token.
  • The numeric example uses L = 32, n_{kv} d_h = 1024, and b = 2 bytes, giving 128 KB per token, and T = 7200 s at f = 1, t_f = 64, so M_{kv} \approx 60 GB.
  • A streaming design replaces N with N_w + N_{mem}, the exact window plus a fixed memory bank, which is O(1) in T.
Pipeline diagram: a two-hour 30 fps stream is decoded at 1 fps, encoded per frame into 256 patch tokens, reduced to 64 tokens per frame, then fed into a sliding-window KV cache whose evicted frames are merged into a fixed-size compressed memory bank, with both feeding an LLM decoder that answers a timestamped user query

Figure 2: A streaming video VLM: decode rate and per-frame token count shrink the sequence by two orders of magnitude, then eviction into a fixed memory bank makes resident state constant in stream length while the exact sliding window preserves fine detail for recent seconds.

PropertyUniform dense samplingQuery-adaptive keyframe retrievalStreaming window plus memory bank
Token growth with durationLinear and unboundedBounded at read time, but the index still scales with durationConstant resident state
KV cache for 2 h60 GB at 1 fps and 64 tokens per frame; 240 GB at full 256 tokensA few GB, set by the number of retrieved segmentsUnder 1 GB for roughly 5,900 live tokens
Where information is lostBetween sampled frames, uniformly across the timelineIn segments the retriever scored as irrelevantIn merged history: detail decays with age
Best fitClips of a few minutes and dense temporal groundingOffline archives with a known question per requestLive monitoring, assistants, always-on capture
Typical failureOut-of-memory, or time to first token in the tens of secondsRetriever misses the one relevant second, so the answer is confidently wrongQuestions about hour-old fine detail that the merge already discarded
Latency profileOne huge quadratic prefill per requestCheap index build offline, small prefill per queryAmortized per frame, answers available at any instant

Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *