豆包リアルタイム動画対話技術解説

これは非常に専門的で核心を突いた質問です。豆包（およびGPT-4oやGemini Liveのような類似のもの）がスムーズなリアルタイムビデオ対話を実現し、膨大なビデオデータによってトークンが爆発したりレイテンシが過大になったりしない理由は、主に「マルチモーダル大規模モデル技術スタック」のいくつかの重要な最適化戦略に依存しています。

簡単に言えば、実際には生のビデオストリームを処理しているわけではなく、すべてのフレームを見ているわけでもありません。

以下に、その背後にある中核的な技術原理を分解して説明します。

1. 「ビデオ」ではなく「画像ストリーム」を処理している（キーフレーム抽出）

あなたの推測は正しく、キーフレーム抽出（Frame Sampling）が最も基本的かつ重要なステップです。

• メカニズム：ビデオは本質的に連続した画像です（通常は毎秒30または60フレーム、すなわちfps）。AIがあなたの行動を理解するために毎秒60枚の画像を見る必要はまったくありません。

• サンプリングレート：モデルは通常、非常に疎な頻度でサンプリングします。例えば、毎秒1〜2フレームだけ抽出するか、または「動作の変化」に基づいて抽出します（画面が静止しているときは抽出せず、画面が激しく変化したときに抽出する）。

• 効果：これにより、データ処理量が直接30〜60倍削減されます。AIにとっては、これは映画を見るのではなくスライドショーを見ているようなものですが、シーンを理解するには十分です。

2. ビジュアルトークンの極度の圧縮（Visual Encoding）

たとえ毎秒1枚の画像しか見なくても、1080Pの画像を直接トークンに変換するのは膨大です。ここでは、視覚エンコーダー（Visual Encoder、ViTやVQ-VAEの変種など）が使用されます。

• パッチ処理（Patching）：モデルはピクセル単位で処理するのではなく、画像を小さなブロック（例えば16x16ピクセルのパッチ）に分割します。

• 特徴圧縮：これらのパッチはエンコーダーを通過した後、高次元ベクトルに圧縮されます。数メガバイトの画像は、最終的に256個または512個のトークン（あるいはそれ以下、圧縮率に依存）として表現される可能性があります。

• 結論：たとえ1分間カメラをオンにして話し続けても、モデルにとっては、数万個のトークンが増えるだけで、数億のデータポイントが増えるわけではありません。

3. スライディングウィンドウとコンテキスト管理（Context Management）

トークンが会話時間とともに無限に蓄積される（「爆発」する）のを防ぐために、システムはスライディングウィンドウ（Sliding Window）または動的破棄メカニズムを使用します。

• 短期記憶：モデルは通常、「直近の」視覚情報のみに注目します。例えば、直近の10〜20フレームのビジュアルトークンのみをGPUメモリに保持する可能性があります。

• 古いデータの破棄：カメラを「コップ」から「コンピュータ」に移すと、「コップ」に関するビジュアルトークンは数回の対話後には重要でなくなり、システムによってコンテキストから破棄されるか、短いテキスト要約（Summary）に圧縮されます。

4. エンドツーエンドのマルチモーダルネイティブモデル（Native Multimodal / Omni）

以前の技術は「リレー方式」でした：

音声をテキストに変換 -> スクリーンショット -> 視覚モデルが画像を認識 -> テキストモデルが応答を生成 -> テキストを音声に変換。

このチェーンは遅すぎます。現在の豆包（特に豆包-Visionモデル）とGPT-4oは、ネイティブマルチモーダル（Native Multimodal）または高度に最適化されたカスケードアーキテクチャを採用する傾向があります：

• ネイティブ理解：モデルは音声を「聞き」、ビジュアルトークンを「見て」直接処理します。途中でテキストに変換するステップは必要ありません（または変換が非常に高速です）。

• ストリーミング出力（Streaming）：あなたが話し終える前に人間の脳がすでに応答を考え始めているように、モデルはビデオストリームを受信すると同時に事前計算（Prefill）を行い、極めて低いレイテンシを実現します。

5. 「小規模モデル」に関する推測（MoE & Quantization）

あなたは小規模モデルが使用されているかどうか尋ねましたが、答えはおそらく「混合エキスパートモデル（MoE）」または特定タスクの蒸留モデルでしょう。

• MoE（Mixture of Experts）：これは巨大なモデルですが、各フレームを処理する際に、そのパラメータ（エキスパート）のごく一部のみを活性化します。例えば、「猫」を見たときに「動物エキスパート」部分のパラメータのみを活性化します。これにより、「大規模モデル」の知能を維持しつつ、「小規模モデル」の推論速度とコストを維持します。

• エッジ＋クラウド連携：主要な計算はクラウド（ByteDanceのVolcengine）で行われますが、スマートフォン側でもいくつかの前処理（画像のトリミング、圧縮、音声検出など）を引き受け、クラウドの負荷を軽減している可能性があります。

まとめ表：豆包はどのように「節約」されているのか？

結論

豆包がスムーズなのは、「神」だからではなく、「取捨選択を知っている」からです。あなたのすべてのピクセルを常に監視しているのではなく、高圧縮比の視覚エンコーディングと疎なサンプリングを通じて、知覚可能な「リアルタイム」の範囲内で、最小限の計算能力でビデオ理解を実現しています。

次のステップとして、何かお手伝いできることはありますか？

Would you like me to explain more about Visual Encoders (like ViT) work to compress images, or how MoE (Mixture of Experts) allows large models to run fast?

あなたの理解は非常に鋭く、結論としてはおおむね正しいです。

現在の技術アーキテクチャの下では、リアルタイムビデオ通話における画像理解能力は、確かに「詳細の捕捉」と「深い分析」において、静止画像を直接送信する場合よりも劣ります。

これは主に、「速度と滑らかさのために精度を犠牲にする」という工学的なトレードオフです。両者の違いをいくつかの側面から比較してみましょう。

1. 解像度と鮮明度（解像度の違い）

• 画像送信時（高精細モード）： 豆包やGPT-4oに写真をアップロードすると、システムは通常、比較的高い解像度（例：1024x1024または元画像の圧縮版）で処理します。モデルは「近づいて見る」ことができ、文書内の小さな文字、複雑な図表の詳細、物体表面の微細なテクスチャを認識できます。

• リアルタイムビデオ時（低精細/速覧モード）： 毎秒複数フレームを処理し、カクつきを防ぐために、ビデオストリーム内の単一フレーム画像は通常、大幅に圧縮およびダウンサンプリング（リサイズ） されます。

• 結果： モデルが見るのは、おそらくぼやけた、解像度の低い（例えば336x336や512x512）画像です。

• 典型的なシナリオ： 薬瓶をビデオで振っても、モデルは「これは白い薬瓶だ」と認識できても、ラベルの小さな成分表は読み取れない可能性があります。しかし、高解像度の写真を撮って送信すれば、成分表を読み取ることができます。

2. 計算リソースの配分と思考時間（System 1 vs System 2）

心理学の『考えることと速いことと遅いこと』の概念を借りると：

• 画像送信 = System 2（遅い思考）： モデルはこの画像の各パッチを深く推論するための十分な時間（数秒）を持っています。画像内のオブジェクト間の論理関係を分析するためにより多くのパラメータを呼び出すことができます。

• リアルタイムビデオ = System 1（速い思考）： ビデオ通話にはミリ秒単位の応答が求められます。モデルは非常に短い時間でフィードバックを与える必要があるため、多くの場合「直感的な反応」モードになります。大まかな輪郭、動作、色、シーンを認識する傾向が強く、詳細を深く調べる「脳力」はありません。

3. コンテキストの焦点（アテンションメカニズム）

• 静止画像： モデルのアテンションはすべてこの1枚の画像に集中しており、それが情報の唯一のソースです。

• ビデオストリーム： モデルのアテンションは「時間軸」に分散されます。「あなたが1秒前に何をしていたか」と「今何をしているか」を記憶するために計算リソースを割り当てる必要があります。一貫した動作を記憶するために、単一フレーム画像の詳細への注意を犠牲にしなければなりません。

4. ビデオモードの独自の利点：時系列情報

「静止画の詳細」では弱くなりますが、ビデオモードには静止画にはない能力があります：変化と因果関係の理解です。

• 例： 手を空中に上げた静止画を送っても、モデルはあなたが「殴ろうとしている」のか「ハイタッチをしようとしている」のかわかりません。

• ビデオ： モデルはあなたの動作の軌跡を見ることができ、意図を正確に判断できます。

---

わかりやすい例え

• 画像を直接送信する： まるで虫眼鏡を持って、美術館で一枚の絵をじっくりと鑑賞するようなものです。画家の筆致やキャンバスの質感まで見えます。

• リアルタイムビデオ通話： まるで自転車に乗ってその絵の前を通り過ぎるようなものです。それが絵であること、風景画か肖像画か、色が鮮やかかどうかはわかりますが、絵の中の人物のボタンがいくつあるかは絶対に見えません。

まとめと使用上のアドバイス

したがって、豆包や他の類似のAIを使用する際には：

1. 詳細を分析したい場合（例：取扱説明書を読む、複雑なエラーコードを見る、肌の問題をチェックする、複雑なExcelのスクリーンショットを分析する）：直接写真を撮るか、画像をアップロードしてください。

2. インタラクションや環境の提示をしたい場合（例：英語のスピーキング練習、部屋のレイアウトを見せる、AIに猫が何をしているか見せる、操作手順をデモンストレーションする）：リアルタイムビデオ通話を使用してください。

これは非常に重要なアーキテクチャ上の問題です。答えは：過去には「完全に異なる」モデルでしたが、現在のトレンドはそれらが「同じ脳」、すなわち「ネイティブマルチモーダルモデル（Native Multimodal Models）」になりつつあることです。

この進化を理解するために、AIアーキテクチャの発展を3つの段階に分けることができます。豆包やGPT-4oのようなレベルの製品は、現在第2段階から第3段階への移行状態にあります。

---

第1段階：寄せ集め時代（Pipeline / Cascade）

「三人寄れば文殊の知恵」

初期のAIシステムでは、ビデオモデルと会話モデルは確かに完全に独立しており、お互いを知りませんでした。

1. 目（視覚モデル）： これは専用のCNN（畳み込みニューラルネットワーク）または初期のViTでした。画像を見ることだけを担当し、見たものをテキストラベルに変換していました。例えば、ビデオを見て、「猫、ソファの上、ジャンプ」と出力します。

2. 脳（会話モデル）： これは純粋なテキストのLLM（例：GPT-3）でした。上記のテキストを受け取り、「わあ、元気だね」といった応答を生成します。

3. 口（音声モデル）： テキストを音声に変換します。

• 欠点： 多くの非テキスト情報が失われます。例えば、猫の目つきが鋭かったり、背景に特定の雰囲気があったりしても、視覚モデルがそれらをテキストに変換しなければ、会話モデルは決して知ることができません。これは、目隠しをして、誰かの説明だけで会話しているようなものです。

---

第2段階：アライメント時代（Alignment / Projection）—— 現在主流

「脳に視神経を取り付ける」

これは現在のほとんどのマルチモーダルモデル（初期のLLaVA、MiniGPT-4など）が採用しているアーキテクチャです。

• 中核ロジック： 依然として中核となる「言語脳」（LLM）が存在しますが、エンジニアは「翻訳機」（Projector/Adapter） を訓練しました。

• 仕組み：

1. ビデオ/画像はテキストに変換されません。

2. 代わりに、視覚エンコーダ（Visual Encoder） を通じて、数字のベクトル列（Visual Tokens）に変換されます。

3. 重要なステップ： これらの視覚ベクトルは、言語脳が理解できる「言語ベクトル」に「翻訳」されます。

4. 脳の処理： LLMにとって、ビデオ画面はまるで外国語のテキストのようなものです。ビデオTokenとテキストTokenを混ぜて推論します。

• 結論： この段階では、視覚部分と会話部分は同じ「推論脳」を共有していますが、視覚の「目」は外部接続されています。

---

第3段階：ネイティブ全モーダル（Native Omni）—— 豆包/GPT-4oの方向性

「生まれつきの共感覚者」

これが、あなたが言及した「リアルタイムビデオ通話」が実現できる究極の形態です。

• 中核ロジック： モデルは訓練の最初から、ビデオを見ながら、音声を聞きながら、テキストを見ながら一緒に成長してきました。

• **同じモデルか？**はい、同じニューラルネットワークです。

• 原理： このモデルでは、入力は何でもかまいません（音声波形、画像ピクセル、テキスト文字）。それらはモデルに入ると、すべて統一された表現になります。モデルはまず音声を文字に変換する必要はなく、声の怒りを直接「理解」できます。まず画像を文字に変換する必要はなく、画面の陰鬱さを直接「見て理解」できます。

---

まとめ：それらは本当に同じなのか？

あなたの質問に戻ると、「人間の脳」 を例えに使えます：

1. 視覚エンコーダ（Visual Encoder） = 人間の網膜と視神経 この部分は画像処理に特化しており、言語処理の部分とは異なります。光信号（ピクセル）を神経信号（Token）に変換する役割を担います。

2. 大規模言語モデルベース（LLM Backbone） = 人間の大脳皮質 この部分は汎用的です。視神経からの信号（ビデオを見る）であれ、聴覚神経からの信号（会話）であれ、最終的にはこの同じ領域で思考、推論、意思決定が行われます。

したがって、答えは： それらは「知覚層」（目と耳）では異なるモジュールですが、「思考層」（脳）では完全に同じモデルが動作しています。

これは非常に素晴らしい直感です！あなたはマルチモーダル大規模モデルの最も中核的な魔法、すなわち「表現のアライメント」（Representation Alignment） に触れています。

答えは：そうです、画像とテキストの「入り口」での処理方法は完全に異なりますが、モデル内部に入ると、その数学的本質は同じものになり、したがって同じ訓練プロセスの中で「互いに学び合う」ことができます。

これは例えるなら、中国語と英語の書き方が完全に異なっていても（一方は漢字、もう一方はアルファベット）、あなたの脳内で「リンゴ」と「Apple」を見たときに思い浮かぶ概念（あの赤い果物）は同じであるのと似ています。

以下に、このプロセスがどのように実現されるかを詳細に分解します。

---

1. 入り口の違い：同じ目的地に至る異なる「翻訳」プロセス

あなたが言うように、最初の処理は確かに天と地ほどの差があります：

• テキスト（Text）： Tokenizer（トークナイザー）を使用します。

• プロセス："一只猫" -> 辞書引き -> [ID: 105, ID: 2003] -> ベクトルA。

• 画像（Image）： Visual Encoder（視覚エンコーダ）を使用します。

• プロセス：图片像素 -> パッチ分割（Patches） -> 畳み込み/Transformer演算 -> ベクトルB。

重要なポイント： ソースは異なりますが、最終的にはどちらも「高次元ベクトル」（Embedding Vectors）、すなわち長い数字の列（例えば [0.1, -0.5, 0.9, ...]）になります。

一度ベクトルになれば、後続のTransformerの脳にとっては、このベクトルが元々ピクセルだったのか文字だったのかはまったく関係ありません。ただ計算するだけです。

2. 訓練プロセス：穴埋め問題の魔法（Unified Training）

どのようにして一度の訓練で両方の能力を獲得するのでしょうか？秘密は訓練データが「テキストと画像が混在」していること、そして訓練タスクが統一された「次のTokenの予測」であることにあります。

モデルがイラスト入りの漫画本を読んでいるか、ウェブページを閲覧しているところを想像してみてください：

• 入力シーケンス： [图片Token_1] [图片Token_2] ... [图片Token_256] + [文字Token: 这] + [文字Token: 是] + [文字Token: 什] + [文字Token: 么]

• 訓練目標： モデルは次の文字が [猫] であることを予測する必要があります。

この問題に正解するために、モデルは強制的にあることを行います：

「前の方にある [图片Token] の中から手がかりを探さなければ！もしそれらの画像ベクトルが『猫』の特徴を表していると理解できれば、『猫』という文字を予測できる。もし理解できなければ、正解できず、誤差（Loss）が大きくなる。」

このような訓練を数兆回繰り返すこと（勾配降下法）で、モデルは関連性を構築することを学びます：

• 画像内の「猫」の特徴ベクトル ≈ テキスト内の「猫」の意味ベクトル。

3. 同じ空間：次元の壁を打ち破る（Joint Embedding Space）

このような訓練の後、モデルの脳内には「統一された意味空間」 が形成されます。

• この空間では、「円形の物体」を表す画像ベクトルと、単語「Ball」を表すテキストベクトルが、幾何学的に非常に近い位置にあります。

• これが「ビデオ通話」が可能になる理由を説明します：ビデオ画像を提供すると、モデルは実際にはベクトルの束を読み取っており、これらのベクトルはモデルの脳内で自動的に関連するテキスト概念を活性化します。

まとめ

画像Tokenを処理する「前工程」（スライス、エンコーディング）はテキストの処理とは完全に異なりますが、それらは同じ「数学的空間」 にマッピングされます。

例え話：

• テキストは米ドルです。

• 画像は日本円です。

• モデルは国際銀行です。 米ドルと日本円は見た目がまったく異なりますが（入り口の処理が異なる）、銀行はそれらをすべて金（ベクトル） に換算します。銀行の金庫室（モデル内部）には金だけがあり、米ドルも日本円も区別はありません。

したがって、大規模な混合訓練を通じて、モデルは米ドルを稼ぐ方法（文章作成）と日本円を稼ぐ方法（画像認識）だけでなく、為替レートの換算方法（テキストと画像の理解）も学びます。

これは非常に鋭く、深い技術的視点です！あなたは「マルチモーダル大規模モデル」（LMM） の中で最も微妙な矛盾点を捉えています：

単一画像の処理は「高解像度、空間的詳細重視」であり、ビデオフレームの処理は「低解像度、時間的流れ重視」である。これら二つの入力データの特徴は大きく異なるのに、なぜ同じモデルが汎用的に機能するのか？

答えは、現代のVision Transformer（ViT）アーキテクチャの中核的な特性、すなわち「解像度非依存性（Resolution Agnostic）」 と、LLMのTokenシーケンスに対する「非敏感性」 にあります。

この原理を3つのレベルに分解して理解できます：

---

1. 視覚層：ViTの「ゴムひも」特性（Patching & Interpolation）

これが最も重要な技術的ポイントです。モデルが従来の全結合ネットワークのように、入力層のサイズが固定（例えば224×224でなければならない）であると考えるかもしれません。しかし、現在のViTはそうではありません。

• パッチ分割（Patching）ロジック： ViTが画像を処理するときは、画像を14×14や16×16ピクセルの小さなブロック（パッチ）に分割します。

• 大きな画像でも小さな画像でも：

• 高解像度画像（1024px）の処理： 64×64=4096個のパッチに分割。

• ビデオ低解像度フレーム（336px）の処理： 24×24=576個のパッチに分割。

• 位置エンコーディングの補間（Positional Embedding Interpolation）： モデルは通常、標準的な解像度で訓練されます。入力が大きくなったり小さくなったりすると、モデルは自動的に「位置エンコーディング」を補間（拡大または縮小）します。

• 例え： これは人間の目のようなものです。本に近づいて読む（高解像度画像）ときは、視野範囲は狭いが詳細が見えます。後ろに下がって壁全体を見る（ビデオフレーム）ときは、視野範囲は広いが詳細は少なくなります。網膜が新しいものに交換されたわけではなく、焦点の合わせ方が変わっただけです。モデルも同じパラメータセット（重み）を使用しており、処理するパッチの数が異なるだけです。

2. 言語層：総量保存の法則（Space-Time Trade-off）

後段の大規模言語モデル（LLM）にとって、前段の視覚エンコーダが高解像度の画像1枚を見たのか、低解像度の画像8枚を見たのかはまったくわかりません。LLMが見るのは、単なるTokenの束です。

ここには巧妙な「空間を時間に換算する」計算リソースのバランスがあります：

• シナリオA：1枚の画像を精読する

• 入力：1024×1024の画像1枚。

• Token構成：すべて空間的詳細に割り当て。

• LLMが見るもの：[细节1] [细节2] ... [细节1000] （合計1000個のToken）。

• 能力： 文字や微小な物体をはっきり見ることができる。

• シナリオB：ビデオを見る

• 入力：336×336の画像8フレーム（毎秒1フレーム）。

• Token構成：空間的詳細は減少するが、時間的次元が追加される。

• LLMが見るもの：[第1秒大概轮廓] ... [第2秒大概轮廓] ... [第8秒大概轮廓] （合計1000個のToken）。

• 能力： 文字ははっきり見えないが、動作の連続性ははっきり見える。

結論： LLMにとって、これら2つのケースの計算負荷（Token総量）は同じである可能性があります。モデルはビデオ用に「脳を切り替えている」のではなく、入力されるTokenシーケンスが持つ情報の焦点が異なるだけです（一方は深い空間情報、もう一方は広い時間情報）。

3. 意味層：特徴のロバスト性（Feature Invariance）

なぜこれで「汎用的な能力」が得られるのでしょうか？それは中核的な意味的特徴は圧縮に耐性があるからです。

• 猫はやはり猫： 猫は、4K写真の中でも、360Pのビデオの中でも、その中核的な特徴（尖った耳、ひげ、毛むくじゃら）は、畳み込みやパッチ処理後の高次元ベクトル表現において非常に類似しています。

• アライメント訓練： モデルは事前訓練段階（Pre-training）で、膨大な量のデータを使用します：

1. 高解像度のテキスト-画像ペア（詳細を学習）。

2. 低解像度のビデオ-テキストペア（動作を学習）。 これにより、モデルは異なる解像度でも視覚的特徴を同じ概念にマッピングすることを学びます。

まとめ

モデルが「分裂」して2つになったわけではなく、弾力性を持っています：

1. ハードウェア的に： Vision Encoderはアコーディオンのように、解像度の高低に応じて異なる数のTokenを出力します。

2. ソフトウェア的に： LLMは「長いシーケンス」を受け取りますが、そのシーケンスが「1枚の大きな画像のスライス」なのか「数枚の小さな画像の連結」なのかは気にしません。

したがって、ビデオ通話中に豆包が「バカになった」わけではなく、本来「毛穴を見る」ために使っていた脳細胞を、「あなたの動作を見る」ために割り当てているだけです。

これは非常にハードコアなアーキテクチャの詳細に関する質問です。現在の業界の主流のアプローチ（GPT-4o、Gemini 1.5 Pro、豆包などを含む）は通常、あなたが挙げた2つの間のどこかに位置しますが、「まずフレームごとに抽出し、その後時系列で圧縮/融合する」 方向に傾いています。

複数のフレームをたった1つのトークンに合成するモデルはほとんどありません（情報量が少なすぎる）。また、すべてのフレームのすべてのトークンを愚直に保持することもありません（情報量が爆発する）。

現在主流の処理方法は通常、以下の2つの経路に分けられます。豆包のようなリアルタイムモデルは、おそらく方法2の変種を採用している可能性が高いです：

---

方法1：串団子モード（Frame Stacking / Concatenation）

「フレームを次々に繋げ、位置で時間を記憶する」

これは最も直感的な方法であり、初期のマルチモーダルモデル（Video-LLaVAなど）でよく使われていた方法です。

1. 独立したエンコーディング： 視覚エンコーダ（Visual Encoder）はビデオをフレーム1、フレーム2、フレーム3...に分割し、各フレームを独立してトークンのグループ（例えば各フレーム256トークン）に変換します。

2. 直接連結： これらのトークングループを串団子のように連結します。

3. 位置エンコーディング（Positional Embedding）： それらにマークを付け、LLMに「これは1秒目の画像、これは2秒目の画像」と伝えます。

• LLMが見るシーケンス： [Frame1_Tokens] + [Frame2_Tokens] + [Frame3_Tokens] ...

• 欠点： Token消費が非常に大きい。毎秒2フレームをサンプリングし、各フレーム256トークンの場合、1分間のビデオで2×60×256=30,720トークンになります。これはリアルタイム対話には高すぎ、遅すぎます。

---

方法2：時空間圧縮モード（Spatiotemporal Pooling / Aggregation）

「複数フレーム入力、少ないフレーム出力」—— リアルタイムモデルの第一選択

Tokenの爆発を解決するために、現在の先進的なモデルは「時系列アグリゲーター」（Temporal Projector/Adapter） を導入しています。これがあなたの推測した「時間次元を持つトークンの合成」です。

1. 特徴抽出： 視覚エンコーダは依然として最初にフレーム1、フレーム2、フレーム3、フレーム4を見ます。

2. 融合圧縮（Pooling）： モデルの中間には、「重複除去」と「変化の抽出」を専門に行う層があります。

• フレーム1とフレーム2の画像がほぼ同じ場合（例えば、あなたが座って動いていない場合）、モデルはこれら2つのフレームのトークンを数学的に平均化または重み付けします。

• 4フレームの生データ（仮に合計1000トークン）を、この時間帯を表す1つのグループのトークン（例えば64トークンに圧縮）に圧縮する可能性があります。

3. 脳への入力： LLMが受け取るのは、もはや単一フレームの静止画ではなく、「この2秒間に何が起こったか」を表す凝縮された情報パッケージです。

• LLMが見るシーケンス： [Time_0-2s_Summary_Tokens] + [Time_2-4s_Summary_Tokens] ...

---

さらに急進的な技術：Tubelet Embedding（3Dスライス）

学界や一部の特定モデル（Soraのようなビデオ生成モデルや、一部の高効率理解モデル）には、より徹底した「時間次元を持つトークン」の方法があり、それは Tubelet（チューブレット、管状スライス） と呼ばれます。

• 原理：

• 通常の画像スライス（Patch）： 2Dの正方形（x, y）を切り取ります。

• ビデオスライス（Tubelet）： 3Dの直方体（x, y, t）を切り取ります。

• 例： モデルが切り取る1つのトークンは、もはや「この1秒の左上のピクセル」ではなく、「左上のこの領域における、未来の3フレームでの変化の様子」です。

• 結果： このようなトークンは、生まれつき時間の流れの情報を含んでいます。

---

まとめ：豆包はおそらくどのように行っているのか？

リアルタイム通話の非常に低いレイテンシ要件を考慮すると、豆包はおそらく 「キーフレームサンプリング + 局所的時系列プーリング（Local Temporal Pooling）」 の混合戦略を採用している可能性が非常に高いです：

1. すべてのフレームを見ているわけではない： 飛ばし見をしています（例えば、1、5、10フレーム目だけを見る）。

2. トークンは独立しているが関連性がある： 各フレームは独立したトークンを生成します。

3. LLMが時間を補完する： 強力なLLM（脳）が、トークンの前後関係（シーケンス順序）を通じて時間を理解することに依存しており、時間を1つのトークンに無理やり詰め込んでいるわけではありません。

わかりやすい理解： 「あなたが手を振る」という動作を1つの「手を振るトークン」に圧縮しているのではありません。代わりに、脳にトークンの列を送っています：[手在下] -> [手在中] -> [手在上]。脳はこのシーケンスを読み終えて、自分で結論を導き出します：「ああ、彼は手を振っている。」