LagoraLagora
Agora
返回 Agora

对话脉络图

豆包实时视频对话技术解析

已导入 · 未验证

@lhzxbsdr · 3月1日 22:00

系统提示词

Gemini

gemini-3.1-pro-previewAI生成的内容可能不准确。请核实重要信息。
博弈策略与技术架构原理视频模型技术原理与架构系统底层与语言抽象语言系统与模型架构

对话

12 条消息
lhzsbsdr2月24日 17:53

豆包为什么能做到和人实时视频对话?Token 数不会爆炸吗?使用了小模型吗?还是抽取关键帧?

gemini-3.1-pro-preview2月24日 17:53

这是一个非常专业且切中要害的问题。豆包(以及类似的像 GPT-4o、Gemini Live)之所以能做到流畅的实时视频对话,且没有因为海量视频数据导致 Token 爆炸或延迟过高,主要依赖于‌“多模态大模型技术栈”的几个关键优化策略‌。

简单来说,它确实不是在处理原始视频流,也不是每一帧都看。

以下是其背后的核心技术原理拆解:


1. 并没有处理“视频”,而是处理“图片流” (关键帧抽取)

你的猜测是对的,‌抽取关键帧(Frame Sampling)‌ 是最基础也是最重要的一步。

  • 机制:‌ 视频本质上是连续的图片(通常是每秒 30 或 60 帧,即 fps)。AI 根本不需要每秒看 60 张图来理解你在做什么。

  • 采样率:‌ 模型通常会以极其稀疏的频率进行采样。例如,‌每秒仅提取 1-2 帧‌,或者基于“动作变化”来提取(画面静止时不提取,画面剧烈变动时提取)。

  • 效果:‌ 这直接将数据处理量降低了 30-60 倍。对于 AI 来说,这就像是在看幻灯片,而不是看电影,但这足以理解场景。

2. 视觉 Token 的极度压缩 (Visual Encoding)

即便每秒只看 1 张图,一张 1080P 的图片如果直接转成 Token 也是巨大的。这里用到了视觉编码器(Visual Encoder,如 ViT 或 VQ-VAE 的变体)‌‌。

  • 切片处理 (Patching):‌ 模型不会逐个像素处理,而是将图片切成小块(比如 16x16 像素的 Patch)。

  • 特征压缩:‌ 这些 Patch 经过编码器后,会被压缩成高维向量。一张几兆的图片,最终可能只会被表示为 256 个或 512 个 Token‌(甚至更少,取决于压缩率)。

  • 结论:‌ 即使你开着摄像头聊了 1 分钟,对于模型来说,可能只是增加了几万个 Token,而不是几亿个数据点。

3. 滑动窗口与上下文管理 (Context Management)

为了防止 Token 随着对话时间无限累积(导致“爆炸”),系统使用了滑动窗口(Sliding Window)‌或动态丢弃机制。

  • 短期记忆:‌ 模型通常只关注“最近”的视觉信息。比如它可能只保留最近 10-20 帧的视觉 Token 在显存中。

  • 旧数据丢弃:‌ 一旦你把摄像头从“水杯”移到“电脑”上,关于“水杯”的视觉 Token 在几轮对话后就不再重要了,会被系统从上下文中丢弃或压缩成一段简短的文本摘要(Summary)。

4. 端到端的多模态原生模型 (Native Multimodal / Omni)

以前的技术是“接力赛”:

语音转文字 -> 截图 -> 视觉模型识别图片 -> 文本模型生成回复 -> 文字转语音。

这种链路太慢了。现在的豆包(尤其是豆包-Vision 模型)和 GPT-4o 倾向于使用 原生多模态(Native Multimodal)‌ 或高度优化的 级联架构‌:

  • 原生理解:‌ 模型是直接在“听”声音和“看”视觉 Token。它不需要中间转成文字这个步骤(或者转换极快)。

  • 流式输出 (Streaming):‌ 就像你说话还没说完,人脑就已经在构思回应一样,模型在接收视频流的同时就在进行预计算(Prefill),从而实现极低的延迟。

5. 关于“小模型”的猜测 (MoE & Quantization)

你问是否使用了小模型,答案很可能是 ‌“混合专家模型 (MoE)”‌ 或者是 特定任务的蒸馏模型‌。

  • MoE (Mixture of Experts):‌ 这是一个巨大的模型,但在处理每一帧时,只激活其中一小部分参数(专家)。比如看到“猫”时,只激活“动物专家”部分的参数。这样既保持了“大模型”的智商,又保持了“小模型”的推理速度和成本。

  • 端侧+云侧协同:‌ 虽然主要计算在云端(字节跳动的火山引擎),但手机端可能也承担了一些预处理工作(如画面裁剪、压缩、人声检测),减轻云端压力。


总结表格:豆包是如何“省”出来的?

挑战 解决方案 效果
视频数据太大****关键帧采样 (每秒仅看 1-2 帧)数据量减少 95% 以上
图片像素太多****视觉编码器 (ViT / Patching)将一张图压缩为几百个 Token
对话太长****滑动窗口 (丢弃旧画面的 Token)显存占用保持稳定,不会爆炸
延迟太高****流式传输 & MoE 架构只有在需要推理时才激活计算

Export to Sheets

结论

豆包之所以流畅,并不是因为它是“神”,而是因为它‌“懂得取舍”‌‌。它并没有时刻盯着你的每一个像素,而是通过高压缩比的视觉编码和稀疏采样‌,在你能感知的“实时”范围内,用最少的算力实现了视频理解。

下一步,我可以为你做些什么?‌

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?

lhzsbsdr2月24日 17:53

也就是说,模型在视频中对图像的理解远弱于在对话中直接发送图时对图像的理解能力?

gemini-3.1-pro-preview2月24日 17:53

你的理解非常敏锐,结论总体上是正确的。

在当前的技术架构下,‌实时视频通话中的图像理解能力,确实在“细节捕捉”和“深度分析”上弱于直接发送静态图片。‌

这主要是一种‌“为了速度和流畅度而牺牲精度”‌的工程权衡(Trade-off)。我们可以从以下几个维度来对比这两者的区别:

1. 分辨率与清晰度(分辨率差异)

  • 发送图片时(高精模式):‌ 当你上传一张照片给豆包或 GPT-4o 时,系统通常会以较高分辨率(例如 1024x1024 或原图压缩版)来处理它。模型可以“凑近了看”,能识别出文档上的小字、复杂的图表细节或物体表面的微小纹理。

  • 实时视频时(低精/速览模式):‌ 为了保证每秒处理多帧且不卡顿,视频流中的单帧画面通常会被大幅压缩和降采样‌(Resizing)。

  • 后果:‌ 模型看到的可能是一张较为模糊的、分辨率较低(比如 336x336 或 512x512)的图。

  • 典型场景:‌ 如果你拿一个药瓶在视频里晃,模型可能只能认出“这是一个白色药瓶”,但看不清上面的成分表小字;但如果你拍一张高清图发过去,它就能把成分表读出来。

2. 算力分配与思考时间(System 1 vs System 2)

借用心理学《思考,快与慢》的概念:

  • 发送图片 = System 2(慢思考):‌ 模型有充裕的时间(几秒钟)来对这张图的每一个 Patch 进行深度推理。它可以调用更多的参数来分析图片中物体之间的逻辑关系。

  • 实时视频 = System 1(快思考):‌ 视频通话要求毫秒级响应。模型必须在极短时间内给出反馈,因此它往往处于一种“直觉反应”模式。它更倾向于识别大轮廓、动作、颜色和场景‌,而没有“脑力”去深究细节。

3. 上下文聚焦(注意力机制)

  • 静态图:‌ 模型的注意力(Attention)全部集中在这一张图上,它是信息的唯一来源。

  • 视频流:‌ 模型的注意力被分散在“时间轴”上。它需要分配算力去记忆“上一秒你在干嘛”和“这一秒你干了嘛”。‌为了记住连贯的动作,它必须牺牲对单帧画面的细节关注。‌

4. 视频模式的独特优势:时序信息

虽然在“静态细节”上变弱了,但视频模式拥有静态图没有的能力:‌理解变化和因果‌。

  • 例子:‌ 如果你发一张你手举在半空的静态图,模型不知道你是要“打人”还是要“击掌”。

  • 视频:‌ 模型能看到你的动作轨迹,从而准确判断意图。


打个形象的比方

  • 直接发送图片:‌ 就像你拿着放大镜,在博物馆里仔细端详一幅画。你能看到画家的笔触、画布的纹理。

  • 实时视频对话:‌ 就像你骑着自行车经过那幅画。你依然能看清那是幅画,知道画的是风景还是人像,颜色是否鲜艳,但你绝对看不清画里的人穿了几颗扣子。

总结与使用建议

所以,如果你在使用豆包或其他类似 AI 时:

  1. 如果要分析细节‌(如:读说明书、看复杂的报错代码、检查皮肤问题、分析复杂的Excel截图):‌请直接拍照或上传图片‌。

  2. 如果要交互或展示环境‌(如:练习英语口语、展示房间布局、让 AI 看看猫咪在玩什么、演示一个操作步骤):‌请使用实时视频通话‌。

lhzsbsdr2月24日 17:53

视频模型和对话模型是完全不一样的模型吗?

gemini-3.1-pro-preview2月24日 17:53

这是一个非常关键的架构问题。答案是:‌在过去是“完全不一样”的模型,但现在的趋势是它们正在变成“同一个大脑”,也就是所谓的“原生多模态模型” (Native Multimodal Models)。‌

为了让你理解这种演变,我们可以把 AI 架构的发展分为三个阶段。豆包、GPT-4o 这种级别的产品,目前正处于第二阶段向第三阶段过渡的状态。


第一阶段:拼凑时代 (Pipeline / Cascade)

‌“三个臭皮匠,顶个诸葛亮”‌

在早期的 AI 系统中,视频模型和对话模型确实是完全独立的,它们甚至互相不认识。

  1. 眼睛(视觉模型):‌ 这是一个专门的 CNN(卷积神经网络)或早期的 ViT。它只负责看图,然后把看到的转化成文字标签‌。比如看到视频,输出:“一只猫,在沙发上,跳跃”。

  2. 大脑(对话模型):‌ 这是一个纯文本的 LLM(如 GPT-3)。它接手上面那段文字,然后生成回复:“哇,它好活泼啊。”

  3. 嘴巴(语音模型):‌ 把文字转成声音。

  • 缺点:‌ 很多非文字信息丢失了。比如猫的眼神很犀利,或者背景里有某种氛围,视觉模型如果没有把这些转成文字,对话模型就永远不知道。‌这就像你蒙着眼睛,全靠别人给你描述画面来聊天。‌

第二阶段:对齐时代 (Alignment / Projection) —— 目前主流

‌“给大脑装上视神经”‌

这是目前大多数多模态模型(包括早期的 LLaVA, MiniGPT-4 等)采用的架构。

  • 核心逻辑:‌ 依然有一个核心的“语言大脑”(LLM),但是工程师训练了一个‌“翻译器”(Projector/Adapter)‌‌。

  • 如何工作:‌

  1. 视频/图像不再转成文字。

  2. 而是通过视觉编码器(Visual Encoder)‌变成一串数字向量(Visual Tokens)。

  3. 关键一步:‌ 这些视觉向量被“翻译”成语言大脑能听懂的“语言向量”。

  4. 大脑处理:‌ 在 LLM 看来,视频画面就像是一段外语文本‌。它把视频 Token 和文字 Token 混合在一起进行推理。

  • 结论:‌ 在这个阶段,视觉部分和对话部分共用同一个“推理大脑”‌‌,但视觉的“眼睛”是外挂的。

第三阶段:原生全模态 (Native Omni) —— 豆包/GPT-4o 的方向

‌“天生的通感者”‌

这就是你提到的“实时视频对话”能做到的终极形态。

  • 核心逻辑:‌ 模型从一开始训练时,就是看着视频、听着音频、看着文字一起长大的。

  • **是不是同一个模型?**是的,是同一个神经网络。‌

  • 原理:‌ 在这个模型里,输入可以是任何东西(音频波形、图像像素、文本字符)。它们进入模型后,都变成了统一的表示。模型不需要先把声音转成字,它能直接“听懂”语气里的愤怒;不需要先把图转成字,它能直接“看懂”画面的压抑感。


总结:它们到底是不是同一个?

回到你的问题,我们可以用‌“人脑”‌来做比喻:

  1. 视觉编码器(Visual Encoder) = 人的视网膜和视神经 这部分是专门处理图像的,跟处理语言的部分不一样。它负责把光信号(像素)变成神经信号(Token)。

  2. 大语言模型基座(LLM Backbone) = 人的大脑皮层 这部分是通用的。‌无论是视神经传来的信号(看视频),还是听觉神经传来的信号(对话),最终都在这同一个区域进行思考、推理和决策。‌

所以答案是:‌ 它们在‌“感知层”(眼睛和耳朵)‌是不一样的模块,但在‌“思考层”(大脑)‌是完全同一个模型在运作。

lhzsbsdr2月24日 17:53

正因为共用了“思考层”,豆包才能在看到你拿出一朵花时(视觉),结合你刚才说“今天是情人节”(文本上下文),推断出“你是要送给女朋友吗?”(逻辑推理)。如果它们是完全割裂的模型,是做不到这种深度融合的。

那对于图片 token 的处理是完全不一样的呀?也能在一次训练中同时获得多种能力吗?

gemini-3.1-pro-preview2月24日 17:53

这是一个非常棒的直觉!你触碰到了多模态大模型最核心的魔法——‌‌“表示对齐”(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 的‌“前端工序”‌‌(切片、编码)和处理文字完全不一样,但它们被映射到了同一个“数学空间”‌‌。

打个比方:‌

  • 文本是美元。

  • 图片是日元。

  • 模型是一个国际银行。 虽然美元和日元长得完全不一样(入口处理不同),但银行把它们都换算成了黄金(向量)‌‌。在银行的金库里(模型内部),只有黄金,没有美元和日元之分。

所以,通过一次大规模的混合训练,模型不仅学会了怎么赚美元(写作),学会了怎么赚日元(识图),更学会了汇率换算(图文理解)。

lhzsbsdr2月24日 17:53

我说的是大模型处理图片的时候和处理视频的时候,对于图像 token 的处理是很不一样的吧?为什么能获得通用能力?

gemini-3.1-pro-preview2月24日 17:53

这是一个非常敏锐且深入的技术视角!你抓住了‌“多模态大模型”‌‌(LMM)中最微妙的一个矛盾点:

既然单张图片处理是“高分辨率、重空间细节”,而视频帧处理是“低分辨率、重时间流动”,这两者的输入数据特征差别这么大,为什么同一个模型能通用?‌

答案在于现代 Vision Transformer (ViT) 架构的一个核心特性:‌分辨率无关性(Resolution Agnostic)‌‌,以及 LLM 对 Token 序列的‌“不敏感性”‌‌。

我们可以把这个原理拆解为三个层面来理解:


1. 视觉层:ViT 的“橡皮筋”特性 (Patching & Interpolation)

这是最关键的技术点。你可能认为模型像传统的全连接网络一样,输入层必须固定大小(比如必须是 224×224)。但现在的 ViT 不是这样的。

  • 切块(Patching)逻辑:‌ ViT 处理图像时,是把图片切成一个个 14×14 或 16×16 的小方块(Patch)。

  • 无论大图还是小图:‌

  • 处理高清单图(1024px):‌ 切出 64×64=4096 个 Patch。

  • 处理视频低清帧(336px):‌ 切出 24×24=576 个 Patch。

  • 位置编码插值(Positional Embedding Interpolation):‌ 模型训练时通常有一个标准分辨率。当输入变大或变小时,模型会自动对“位置编码”进行插值(拉伸或压缩)。

  • 比喻:‌ 这就像人的眼睛。当你凑近看书(高清图)时,你看到的视野范围小但细节多;当你退后看整面墙(视频帧)时,你看到的视野大但细节少。‌你的视网膜并没有换一个新的,只是聚焦方式变了。‌模型用的也是同一套参数(权重),只是处理的 Patch 数量不同。

2. 语言层:总量守恒定律 (Space-Time Trade-off)

对于后面的大语言模型(LLM)来说,它根本不知道前面的视觉编码器是看了一张高清图,还是看了 8 张低清图。它只看到了一堆 Token。

这里有一个巧妙的‌“空间换时间”‌的算力平衡:

  • 场景 A:精读一张图

  • 输入:1 张 1024×1024 的图。

  • Token 组成:全部分配给空间细节‌。

  • LLM 看到的:[细节1] [细节2] ... [细节1000] (共 1000 个 Token)。

  • 能力:‌ 能看清文字、微小物体。

  • 场景 B:看一段视频

  • 输入:8 帧 336×336 的图(每秒 1 帧)。

  • Token 组成:空间细节减少,但增加了时间维度‌。

  • LLM 看到的:[第1秒大概轮廓] ... [第2秒大概轮廓] ... [第8秒大概轮廓] (共 1000 个 Token)。

  • 能力:‌ 看不清文字,但能看清动作连贯性。

结论:‌ 对于 LLM 来说,这两种情况的计算负载(Token 总量)可能是一样的‌。模型并没有针对视频“切换大脑”,只是输入的 Token 序列所携带的信息侧重点不同‌(一个是深度的空间信息,一个是广度的时间信息)。

3. 语义层:特征的鲁棒性 (Feature Invariance)

为什么这样能获得“通用能力”?因为核心语义特征是抗压缩的‌。

  • 猫还是猫:‌ 一只猫,无论是在 4K 照片里,还是在 360P 的视频里,它的核心特征(尖耳朵、胡须、毛茸茸)在经过卷积或 Patch 处理后的高维向量表示是非常相似的。

  • 对齐训练:‌ 模型在预训练阶段(Pre-training),使用了海量的数据:

  1. 高分辨率图文对‌(学习细节)。

  2. 低分辨率视频文本对‌(学习动作)。 这让模型学会了在不同的分辨率下都能把视觉特征映射到同一个概念上。

总结

并不是模型“分裂”成了两个,而是它具有弹性‌:

  1. 硬件上:‌ Vision Encoder 像手风琴一样,根据分辨率高低,吐出不同数量的 Token。

  2. 软件上:‌ LLM 接收的是一个“长序列”,它不在乎这个序列是“一张大图的切片”还是“几张小图的拼接”。

所以,当你视频通话时,豆包并没有“变笨”,它只是把原本用来“看清毛孔”的脑细胞,分配去“看清你的动作”了。‌

lhzsbsdr2月24日 17:53

所以,具体到切分成图片之后的视频,每帧视频是一帧一帧地给出 token,还是多帧合成一个带时间维度的 token?

gemini-3.1-pro-preview2月24日 17:53

这是一个非常硬核的架构细节问题。目前的业界主流做法(包括 GPT-4o、Gemini 1.5 Pro 和豆包等)通常介于你说的两者之间,但更倾向于‌“先一帧一帧提取,再进行时序压缩/融合”‌‌。

很少有模型会把多帧合成仅仅一个 token(信息量太少),也不会傻乎乎地把每一帧的所有 token 全部保留(信息量爆炸)。

目前主流的处理方案通常分为以下两种路径,豆包这类实时模型极有可能采用的是方案二的变种‌:


方案一:糖葫芦模式 (Frame Stacking / Concatenation)

‌“一帧接一帧,靠位置记时间”‌

这是最直观的做法,也是早期多模态模型(如 Video-LLaVA)常用的方式。

  1. 独立编码:‌ 视觉编码器(Visual Encoder)把视频切成 Frame 1, Frame 2, Frame 3... 然后独立把每一帧变成一组 Token(比如每帧 256 个 token)。

  2. 直接拼接:‌ 把这几组 token 像串糖葫芦一样串起来。

  3. 位置编码(Positional Embedding):‌ 给它们打上标记,告诉 LLM:“这是第 1 秒的图,这是第 2 秒的图”。

  • LLM 看到的序列:‌[Frame1_Tokens] + [Frame2_Tokens] + [Frame3_Tokens] ...

  • 弊端:‌ Token 消耗极大。如果每秒采 2 帧,每帧 256 token,一分钟视频就是 2×60×256=30,720 个 token。这对于实时对话来说太贵了,也太慢了。


方案二:时空压缩模式 (Spatiotemporal Pooling / Aggregation)

‌“多帧进,少帧出” —— 实时模型的首选

为了解决 Token 爆炸,现在的先进模型引入了‌“时序聚合器”(Temporal Projector/Adapter)‌‌。这就是你猜的“合成带时间维度的 token”。

  1. 提取特征:‌ 视觉编码器依然先看 Frame 1, Frame 2, Frame 3, Frame 4。

  2. 融合压缩(Pooling):‌ 模型中间有一个层,专门负责‌“去重”‌和‌“提取变化”‌‌。

  • 如果 Frame 1 和 Frame 2 画面几乎一样(比如你坐着没动),模型会把这两帧的 token 进行数学上的平均或加权。

  • 它可能会把 4 帧的原始数据(假设共 1000 个 token),压缩成 一组 代表这段时间的 token(比如压缩到 64 个 token)。

  1. 输入大脑:‌ LLM 接收到的不再是单帧的静态画面,而是一组代表‌“这 2 秒内发生了什么”‌的浓缩信息包。
  • LLM 看到的序列:‌[Time_0-2s_Summary_Tokens] + [Time_2-4s_Summary_Tokens] ...

还有一个更激进的技术:Tubelet Embedding (3D 切片)

在学术界和一些特定模型(如 Sora 类视频生成模型,或某些高效理解模型)中,有一种更彻底的‌“带时间维度的 Token”‌做法,叫做 Tubelet(管道切片)‌‌。

  • 原理:‌

  • 普通图片切片 (Patch):‌ 是切一个 2D 的正方形(x, y)。

  • 视频切片 (Tubelet):‌ 是切一个 3D 的长方体(x, y, t)。

  • 举例:‌ 模型切下来的一个 token,不再是“这一秒左上角的像素”,而是‌“左上角这块区域在未来 3 帧里的变化情况”‌‌。

  • 结果:‌ 这样一个 Token 天生就包含了时间流动的信息。


总结:豆包大概率是怎么做的?

考虑到实时通话的极低延迟要求,豆包极有可能采用了 ‌“关键帧采样 + 局部时序池化 (Local Temporal Pooling)”‌ 的混合策略:

  1. 并没有每一帧都看:‌ 它是跳着看的(比如只看第 1, 5, 10 帧)。

  2. Token 是独立的但有联系:‌ 每一帧生成独立的 Token。

  3. 靠 LLM 脑补时间:‌ 它依赖强大的 LLM(大脑)通过 Token 的前后顺序(Sequence Order)来理解时间,而不是把时间硬塞进一个 Token 里。

通俗理解:‌ 它并不是把“你挥手”这个动作压缩成了一个“挥手Token”; 而是发给大脑一串 Token:[手在下] ->[手在中] ->[手在上]。 大脑读完这个序列,自己得出了结论:“哦,他在挥手。”

评论

0

暂无评论。快来发表第一条评论吧!

登录后即可发表评论。

相关讨论

中剧填补影视屏幕中间态空白 → 电视剧与电视媒介的脱钩

中剧填补影视屏幕中间态空白;电视剧与电视媒介的脱钩

Sdreavmer@Sdreavmer

无向量RAG原理与对比

用户询问PageIndex和无向量RAG的概念及动机,助理详细解释了PageIndex基于倒排索引的原理,并对比了向量RAG与无向量RAG在检索单元、匹配逻辑、上下文完整性等方面的核心差异,指出无向量RAG旨在解决向量RAG的切片破碎、模糊匹配和黑盒问题。

lhzsbsdr@lhzxbsdr

编译与解释的深层区别与JIT

用户进一步追问编译和解释的区别,并引申出现代语言性能是否已无差异的困惑。助理用赛车类比解释了两者在“负重”(运行时环境)和优化时间上的根本差异,并详细介绍了JIT(即时编译)的工作原理、优缺点及其开发难度。

lhzsbsdr@lhzxbsdr

编译器开发的生态与国内现状

用户询问编译器实际由谁开发,并推测中国可能没什么人做。助理描绘了由科技巨头、芯片厂商、学术界和开源社区构成的全球编译器开发生态,并重点介绍了中国在华为、互联网大厂、AI芯片及开源社区等领域的活跃投入和现状。

lhzsbsdr@lhzxbsdr

隐形爆发的硬核AI应用

用户补充提及自动驾驶、工业AI等更多应用,助理分析了这些“非生成式”但正在爆发的领域,阐释了它们与LLM技术或近或远的关系,并类比为一场由通用技术(蒸汽机)驱动各行业(火车、纺织机)的工业革命。

lhzsbsdr@lhzxbsdr

指针本质与C语言抽象

从内存和编译器视角解释了指针的本质是存储地址的变量,并由此引出对C语言低抽象特性的讨论,通过对比汇编代码揭示了C语言作为“可移植汇编语言”的底层特性。

lhzsbsdr@lhzxbsdr