Technical Analysis of Doubao's Real-Time Video Dialogue
Imported@odus · Mar 1, 10:00 PM
Conversation summary
Real-time video models like Doubao adopt the spatiotemporal compression mode of Scheme 2, using temporal aggregators to deduplicate and extract features from multiple video frames, compressing a large number of original tokens into a small amount of condensed information packets, thereby achieving efficient real-time dialogue with low latency.
Conversation
How can Doubao achieve real-time video conversations with people? Won't the token count explode? Does it use a small model? Or does it extract keyframes?
This is a very professional and spot-on question. The reason Doubao (and similar models like GPT-4o, Gemini Live) can achieve smooth real-time video conversations without token explosion or high latency due to massive video data mainly relies on several key optimization strategies within the "multimodal large model technology stack."
In simple terms, it's not processing the raw video stream, nor is it looking at every single frame.
Here is a breakdown of the core technical principles behind it:
- It Doesn't Process "Video," but an "Image Stream" (Key Frame Extraction)
Your guess is correct. Key frame sampling is the most fundamental and important step.
-
Mechanism: Video is essentially a sequence of continuous images (usually 30 or 60 frames per second, i.e., fps). The AI doesn't need to look at 60 images per second to understand what you're doing.
-
Sampling Rate: The model typically samples at an extremely sparse rate. For example, it might extract only 1-2 frames per second, or extract frames based on "motion changes" (no extraction when the scene is static, extraction when the scene changes drastically).
-
Effect: This directly reduces the data processing volume by 30-60 times. For the AI, it's like watching a slideshow rather than a movie, but that's sufficient to understand the scene.
- Extreme Compression of Visual Tokens (Visual Encoding)
Even if only looking at 1 image per second, converting a 1080P image directly into tokens would be enormous. Here, a Visual Encoder (a variant of ViT or VQ-VAE) is used.
-
Patching: The model doesn't process pixels one by one. Instead, it cuts the image into small blocks (e.g., 16x16 pixel patches).
-
Feature Compression: After passing through the encoder, these patches are compressed into high-dimensional vectors. A multi-megabyte image might ultimately be represented by only 256 or 512 tokens (or even fewer, depending on the compression ratio).
-
Conclusion: Even if you've had your camera on for a minute, for the model, it might only add a few tens of thousands of tokens, not hundreds of millions of data points.
- Sliding Window and Context Management
To prevent tokens from accumulating indefinitely over the conversation time (leading to an "explosion"), the system uses a Sliding Window or dynamic discard mechanism.
-
Short-Term Memory: The model usually only focuses on the "most recent" visual information. For example, it might only retain the visual tokens from the latest 10-20 frames in VRAM.
-
Old Data Discard: Once you move the camera from a "water bottle" to a "computer," the visual tokens for the "water bottle" become irrelevant after a few turns and are discarded from the context or compressed into a short text summary.
- End-to-End Native Multimodal Models (Native Multimodal / Omni)
Older technology was a "relay race":
Speech to text -> Screenshot -> Vision model identifies image -> Text model generates reply -> Text to speech.
This pipeline is too slow. Current models like Doubao (especially the Doubao-Vision model) and GPT-4o tend to use Native Multimodal or highly optimized Cascaded Architectures:
-
Native Understanding: The model directly "hears" audio and "sees" visual tokens. It doesn't need the intermediate step of converting to text (or the conversion is extremely fast).
-
Streaming: Just like your brain starts formulating a response before you've finished speaking, the model performs precomputation (Prefill) while receiving the video stream, achieving extremely low latency.
- On the "Small Model" Guess (MoE & Quantization)
You asked if a small model is used; the answer is likely a Mixture of Experts (MoE) or a task-specific distilled model.
-
MoE (Mixture of Experts): This is a huge model, but when processing each frame, it only activates a small fraction of its parameters (experts). For example, when it sees a "cat," it activates only the parameters of the "animal expert." This maintains the intelligence of a "large model" while keeping the inference speed and cost of a "small model."
-
Edge + Cloud Synergy: Although the main computation is in the cloud (ByteDance's Volcano Engine), the phone may also handle some preprocessing tasks (e.g., frame cropping, compression, voice detection), reducing the cloud's workload.
Summary Table: How does Doubao "save" resources?
| Challenge | Solution | Effect |
|---|---|---|
| Video data is too large | Key frame sampling (only 1-2 frames per second) | Data volume reduced by over 95% |
| Image pixels are too many | Visual Encoder (ViT / Patching) | Compresses one image into a few hundred tokens |
| Conversation is too long | Sliding Window (discards tokens of old frames) | VRAM usage remains stable, no explosion |
| Latency is too high | Streaming & MoE Architecture | Computation activated only when needed for inference |
Conclusion
Doubao is smooth not because it's "divine," but because it "knows how to make trade-offs." It doesn't constantly monitor every single pixel of yours; instead, through high-compression visual encoding and sparse sampling, it achieves video understanding with minimal computational power within the range you perceive as "real-time."
What can I do for you next?
Would you like me to explain more about how Visual Encoders (like ViT) work to compress images, or how MoE (Mixture of Experts) allows large models to run fast?
So, does this mean that the model's ability to understand images from video is much weaker than its ability to understand images when you directly send a picture in a chat?
Your understanding is very sharp, and the conclusion is generally correct.
Under the current technical architecture, the image understanding capability in real-time video calls is indeed weaker in "detail capture" and "in-depth analysis" compared to directly sending static images.
This is mainly an engineering trade-off "sacrificing precision for speed and fluidity." We can compare the differences between the two from the following dimensions:
1. Resolution and Clarity (Resolution Differences)
-
When sending an image (high-precision mode): When you upload a photo to Doubao or GPT-4o, the system usually processes it at a higher resolution (e.g., 1024x1024 or a compressed version of the original). The model can "zoom in" and recognize small text on documents, complex chart details, or subtle textures on object surfaces.
-
During real-time video (low-precision/quick-scan mode): To ensure processing multiple frames per second without lag, individual frames in the video stream are usually heavily compressed and downsampled (Resizing).
-
Consequence: The model might see a relatively blurry, low-resolution image (e.g., 336x336 or 512x512).
-
Typical Scenario: If you shake a medicine bottle in the video, the model might only recognize it as "a white bottle" but can't read the small ingredient text on it; however, if you take a high-definition photo and send it, it can read the ingredient list.
2. Computational Allocation and Thinking Time (System 1 vs System 2)
Borrowing the concept from the book "Thinking, Fast and Slow":
-
Sending an image = System 2 (Slow Thinking): The model has ample time (a few seconds) to perform deep reasoning on every patch of the image. It can invoke more parameters to analyze the logical relationships between objects in the image.
-
Real-time video = System 1 (Fast Thinking): Video calls require millisecond-level responses. The model must give feedback in an extremely short time, so it often operates in an "intuitive reaction" mode. It tends to recognize large outlines, actions, colors, and scenes, without the "brainpower" to delve into details.
3. Contextual Focus (Attention Mechanism)
-
Static Image: The model's attention is entirely focused on that single image; it is the sole source of information.
-
Video Stream: The model's attention is distributed across the "timeline." It needs to allocate computational power to remember "what you were doing a second ago" and "what you are doing now." To remember coherent actions, it must sacrifice attention to the details of individual frames.
4. Unique Advantage of Video Mode: Temporal Information
Although it is weaker in "static details," video mode has an ability that static images lack: understanding change and causality.
-
Example: If you send a static image of your hand raised halfway, the model doesn't know if you are about to "hit" or "high-five."
-
Video: The model can see the trajectory of your action, thus accurately judging your intention.
A Vivid Analogy
-
Directly sending an image: It's like holding a magnifying glass and carefully examining a painting in a museum. You can see the artist's brushstrokes and the texture of the canvas.
-
Real-time video conversation: It's like riding a bicycle past that painting. You can still tell it's a painting, know if it's a landscape or a portrait, and see if the colors are vibrant, but you absolutely cannot see how many buttons the person in the painting has on their shirt.
Summary and Usage Suggestions
So, when using Doubao or other similar AIs:
-
If you need to analyze details (e.g., reading a manual, looking at complex error codes, checking a skin issue, analyzing a complex Excel screenshot): Please take a photo or upload an image directly.
-
If you need to interact or show an environment (e.g., practicing spoken English, showing a room layout, letting the AI see what your cat is playing with, demonstrating a procedure): Please use the real-time video call.
Are the video model and the conversation model completely different models?
This is a very critical architectural question. The answer is: In the past, they were "completely different" models, but the current trend is that they are becoming "the same brain," also known as "Native Multimodal Models."
To help you understand this evolution, we can divide the development of AI architecture into three stages. Products like Doubao and GPT-4o are currently in a state of transitioning from the second stage to the third stage.
Stage 1: The Patchwork Era (Pipeline / Cascade)
"Two heads are better than one"
In early AI systems, the video model and the conversation model were indeed completely independent, and they didn't even know each other.
-
Eyes (Vision Model): This was a specialized CNN (Convolutional Neural Network) or early ViT. It was only responsible for looking at images and converting what it saw into text labels. For example, seeing a video, it would output: "A cat, on a sofa, jumping."
-
Brain (Conversation Model): This was a pure text LLM (like GPT-3). It took the text above and generated a reply: "Wow, it's so lively."
-
Mouth (Speech Model): Converted text into sound.
- Disadvantage: A lot of non-textual information was lost. For example, if the cat's expression was very sharp or there was a certain atmosphere in the background, if the vision model didn't convert this into text, the conversation model would never know. It's like you're blindfolded, relying entirely on someone else describing the scene to chat.
Stage 2: The Alignment Era (Alignment / Projection) – Current Mainstream
"Installing an optic nerve for the brain"
This is the architecture used by most current multimodal models (including early LLaVA, MiniGPT-4, etc.).
-
Core Logic: There is still a core "language brain" (LLM), but engineers trained a "translator" (Projector/Adapter).
-
How it works:
-
Video/images are no longer converted to text.
-
Instead, they are turned into a string of numerical vectors (Visual Tokens) via a Visual Encoder.
-
Key Step: These visual vectors are "translated" into "language vectors" that the language brain can understand.
-
Brain Processing: From the LLM's perspective, the video frames are like a piece of foreign language text. It mixes the video tokens and text tokens together for reasoning.
- Conclusion: At this stage, the visual part and the conversational part share the same "reasoning brain," but the visual "eyes" are external.
Stage 3: Native Omni – The Direction of Doubao/GPT-4o
"Born synesthete"
This is the ultimate form that the "real-time video conversation" you mentioned can achieve.
-
Core Logic: From the very beginning of training, the model grew up watching videos, listening to audio, and reading text together.
-
Is it the same model? Yes, it is the same neural network.
-
Principle: In this model, the input can be anything (audio waveforms, image pixels, text characters). They all become a unified representation after entering the model. The model doesn't need to convert sound to text first; it can directly "understand" the anger in the tone; it doesn't need to convert the image to text first; it can directly "understand" the oppressive feeling of the scene.
Summary: Are They the Same or Not?
Back to your question, we can use the "human brain" as an analogy:
-
Visual Encoder = Human retina and optic nerve This part is specialized for processing images and is different from the part that processes language. It converts light signals (pixels) into neural signals (tokens).
-
LLM Backbone = Human cerebral cortex This part is general-purpose. Whether it's signals from the optic nerve (watching video) or signals from the auditory nerve (conversation), they all end up in this same area for thinking, reasoning, and decision-making.
So the answer is: They are different modules at the "perception layer" (eyes and ears), but at the "thinking layer" (brain), it is entirely the same model operating.
Precisely because they share the "thinking layer," Doubao can, upon seeing you take out a flower (visual), combine it with you just saying "Today is Valentine's Day" (text context), and infer "Are you going to give this to your girlfriend?" (logical reasoning). If they were completely separate models, this deep fusion wouldn't be possible.
But the processing of image tokens is completely different, isn't it? Can it also acquire multiple abilities simultaneously in a single training session?
This is a fantastic intuition! You've touched upon the most core magic of multimodal large models——"Representation Alignment".
The answer is: Yes, although the "entry points" for images and text are completely different, once inside the model, their mathematical essence becomes the same thing, so they can "learn from each other" during the same training process.
This is like: Although Chinese and English are written completely differently (one is characters, the other is letters), in your brain, when you see "苹果" and "Apple," the concept that pops into your mind (that red fruit) is the same.
Here is a detailed breakdown of how this process works:
1. Different Entries: A "Translation" Process with the Same Goal
As you said, their initial processing is indeed vastly different:
-
Text: Uses a Tokenizer.
-
Process:
"A cat"-> Look up dictionary ->[ID: 105, ID: 2003]->Vector A. -
Image: Uses a Visual Encoder.
-
Process:
Image Pixels-> Cut into Patches -> Convolution/Transformer operations ->Vector B.
Here's the key point: Although they come from different sources, they both ultimately become "High-dimensional Vectors" (Embedding Vectors) , which are just long strings of numbers (e.g., [0.1, -0.5, 0.9, ...]).
Once they become vectors, for the Transformer brain behind them, it doesn't care at all whether this vector originally came from pixels or text. It just calculates.
2. The Training Process: The Magic of Fill-in-the-Blanks (Unified Training)
How do you gain both abilities in a single training session? The secret is that the training data is "interleaved with text and images," and the training task is a unified "Predict the Next Token."
Imagine the model reading a comic book with illustrations, or browsing a webpage:
-
Input Sequence:
[Image_Token_1] [Image_Token_2] ... [Image_Token_256]+[Text_Token: What]+[Text_Token: is]+[Text_Token: this]+[Text_Token: ?] -
Training Goal: The model needs to predict the next word is
[cat].
To answer this correctly, the model is forced to do one thing:
"I must look for clues in the previous
[Image_Token]! If I understand that those image vectors represent the features of a 'cat,' I can predict the word 'cat'; if I don't understand, I'll guess wrong, and the error (Loss) will be large."
Through trillions of such training steps (gradient descent), the model learns to establish connections:
- Feature vector of "cat" in the image ≈ Semantic vector of "cat" in the text.
3. The Same Space: Breaking the Dimensional Wall (Joint Embedding Space)
After this training, a "Unified Semantic Space" forms inside the model's brain.
-
In this space, the image vector representing a "round object" and the text vector representing the word "Ball" are geometrically very close to each other.
-
This explains how "video conversation" is possible: when you provide a video feed, the model is essentially reading a bunch of vectors, and these vectors automatically activate related textual concepts in its mind.
Summary
Although the "front-end process" (slicing, encoding) for handling image tokens is completely different from that for text, they are mapped into the same "mathematical space."
As an analogy:
-
Text is US Dollars.
-
Image is Japanese Yen.
-
Model is an international bank. Although US Dollars and Japanese Yen look completely different (different entry processing), the bank converts them all into Gold (Vectors) . In the bank's vault (inside the model), there is only gold, no distinction between Dollars and Yen.
So, through a single large-scale mixed training session, the model not only learns how to earn Dollars (writing) and how to earn Yen (image recognition), but also learns the exchange rate (image-text understanding).
I mean, when a large model processes images versus when it processes videos, the handling of image tokens is quite different, right? How can it achieve general-purpose capability?
This is a very sharp and deep technical perspective! You've grasped the most subtle contradiction in "Multimodal Large Language Models" (LMMs):
Since processing a single image is "high-resolution, heavy on spatial details," and processing video frames is "low-resolution, heavy on temporal flow," the input data characteristics are so different—how can the same model be versatile?
The answer lies in a core feature of the modern Vision Transformer (ViT) architecture: Resolution Agnosticism, and the LLM's "insensitivity" to token sequences.
We can break down this principle into three layers for understanding:
1. Visual Layer: The ViT's "Rubber Band" Property (Patching & Interpolation)
This is the most critical technical point. You might think the model, like a traditional fully connected network, requires a fixed input size (e.g., must be 224×224). But modern ViTs are not like that.
-
Patching Logic: When a ViT processes an image, it cuts the image into small squares (Patches) of, say, 14×14 or 16×16 pixels.
-
Whether Large or Small Image:
-
Processing a High-Res Single Image (1024px): Cuts out 64×64 = 4096 Patches.
-
Processing a Low-Res Video Frame (336px): Cuts out 24×24 = 576 Patches.
-
Positional Embedding Interpolation: The model is usually trained at a standard resolution. When the input becomes larger or smaller, the model automatically interpolates (stretches or compresses) the "positional encodings."
-
Analogy: This is like the human eye. When you lean in to read a book (high-res image), your field of view is small but detailed; when you step back to look at an entire wall (video frame), your field of view is large but less detailed. Your retina doesn't get replaced; just the way you focus changes. The model uses the same set of parameters (weights), just processing a different number of Patches.
2. Language Layer: The Law of Conservation of Total Tokens (Space-Time Trade-off)
For the Large Language Model (LLM) downstream, it has no idea whether the visual encoder upstream looked at one high-res image or eight low-res images. It only sees a bunch of tokens.
There is an elegant "space-for-time" computational balance here:
-
Scenario A: Close Reading of One Image
-
Input: 1 image at 1024×1024.
-
Token Composition: All allocated to spatial details.
-
What the LLM sees:
[Detail_1] [Detail_2] ... [Detail_1000](1000 tokens total). -
Capability: Can read text, see tiny objects.
-
Scenario B: Watching a Video Clip
-
Input: 8 frames at 336×336 (1 frame per second).
-
Token Composition: Spatial details are reduced, but a temporal dimension is added.
-
What the LLM sees:
[Rough outline of 1st second] ... [Rough outline of 2nd second] ... [Rough outline of 8th second](1000 tokens total). -
Capability: Cannot read text, but can see the continuity of motion.
Conclusion: For the LLM, the computational load (total token count) for these two scenarios might be the same. The model doesn't "switch brains" for video; it's just that the information focus carried by the input token sequence is different (one is deep spatial information, the other is broad temporal information).
3. Semantic Layer: Feature Invariance
Why does this yield "general capability"? Because core semantic features are resistant to compression.
-
A cat is still a cat: Whether a cat is in a 4K photo or a 360P video, its core features (pointy ears, whiskers, furriness) after convolution or patch processing are represented by very similar high-dimensional vectors.
-
Alignment Training: During the pre-training phase, the model uses massive amounts of data:
-
High-resolution image-text pairs (learning details).
-
Low-resolution video-text pairs (learning actions). This teaches the model to map visual features to the same concept across different resolutions.
Summary
The model hasn't "split" into two; rather, it has elasticity:
-
Hardware-wise: The Vision Encoder acts like an accordion, outputting a different number of tokens depending on the resolution.
-
Software-wise: The LLM receives a "long sequence" and doesn't care whether this sequence is "slices of one large image" or "concatenations of several small images."
So, when you're on a video call, Doubao hasn't "gotten dumber"; it has simply allocated the brain cells it would have used to "see your pores" to instead "see your movements."
So, specifically for video that has been split into images, does each video frame give tokens frame by frame, or are multiple frames combined into a single token with a temporal dimension?
This is a very hardcore architectural detail question. The current mainstream industry practice (including GPT-4o, Gemini 1.5 Pro, and Doubao) usually falls somewhere between the two options you mentioned, but leans more towards "extracting frame by frame first, then performing temporal compression/fusion."
Few models would merge multiple frames into just one token (too little information), nor would they foolishly keep all tokens from every frame (information explosion).
The current mainstream processing solutions generally fall into the following two paths. Real-time models like Doubao most likely use a variant of Plan 2:
Plan 1: The Tanghulu (Candied Hawthorn) Mode (Frame Stacking / Concatenation)
"Frame after frame, using position to remember time"
This is the most intuitive approach, commonly used by early multimodal models (like Video-LLaVA).
-
Independent Encoding: The Visual Encoder cuts the video into Frame 1, Frame 2, Frame 3... and then independently turns each frame into a set of tokens (e.g., 256 tokens per frame).
-
Direct Concatenation: String these sets of tokens together like candied hawthorns on a stick.
-
Positional Embedding: Mark them to tell the LLM: "This is the image from the 1st second, this is from the 2nd second."
-
Sequence the LLM sees:
[Frame1_Tokens] + [Frame2_Tokens] + [Frame3_Tokens] ... -
Drawback: Extremely high token consumption. If sampling 2 frames per second, with 256 tokens per frame, a one-minute video would be 2×60×256 = 30,720 tokens. This is too expensive and too slow for real-time conversation.
Plan 2: Spatiotemporal Compression Mode (Spatiotemporal Pooling / Aggregation)
"Multiple frames in, fewer frames out" — The preferred choice for real-time models
To solve the token explosion, advanced models now introduce a "Temporal Projector/Adapter." This is what you guessed as "synthesizing a token with a temporal dimension."
-
Extract Features: The Visual Encoder still first looks at Frame 1, Frame 2, Frame 3, Frame 4.
-
Fusion Compression (Pooling): There is a layer inside the model specifically responsible for "deduplication" and "extracting changes."
-
If Frame 1 and Frame 2 are almost identical (e.g., you're sitting still), the model will mathematically average or weight the tokens of these two frames.
-
It might take the raw data from 4 frames (say, 1000 tokens total) and compress it into one set of tokens representing that period of time (e.g., compressed down to 64 tokens).
- Input to the Brain: The LLM no longer receives static images of individual frames, but a set of condensed information packets representing "what happened during these 2 seconds."
- Sequence the LLM sees:
[Time_0-2s_Summary_Tokens] + [Time_2-4s_Summary_Tokens] ...
Another, more radical technique: Tubelet Embedding (3D Slicing)
In academia and some specific models (like Sora-class video generation models, or certain efficient understanding models), there is a more thorough approach to creating "tokens with a temporal dimension," called Tubelets.
-
Principle:
-
Regular Image Patch: Cuts a 2D square (x, y).
-
Video Tubelet: Cuts a 3D rectangular prism (x, y, t).
-
Example: One token cut by the model is no longer "the pixel in the top-left corner at this second," but rather "the change in this top-left area over the next 3 frames."
-
Result: Such a token inherently contains information about the flow of time.
Summary: How is Doubao most likely doing it?
Considering the extremely low latency requirements of real-time conversation, Doubao most likely uses a hybrid strategy of "keyframe sampling + local temporal pooling":
-
It doesn't look at every frame: It samples sparsely (e.g., only looking at frames 1, 5, 10).
-
Tokens are independent but related: Each frame generates its own set of independent tokens.
-
Relies on the LLM to infer time: It relies on the powerful LLM (the brain) to understand time through the sequential order of tokens, rather than forcing time into a single token.
In simple terms: It doesn't compress the action of "you waving" into a single "WavingToken"; instead, it sends the brain a sequence of tokens: [Hand down] -> [Hand mid] -> [Hand up]. After reading this sequence, the brain concludes: "Oh, he's waving."