统一音视频理解与生成：JavisGPT 架构与技术细节解析

第一次看到 JavisGPT 这个名字，我愣了一下——谐音 Jarvis，摆明了是要做全能管家式的 AI 助手。再往下看副标题，Unified Multi-modal LLM for Sounding-Video Comprehension and Generation，翻译成人话就是：一个模型，既能读懂带声音的视频，也能生成带声音的视频。跟我一样常年做多模态的人应该秒懂，这件事听起来简单，但想做到“读”和“写”都强，其实是块硬骨头。这篇论文放在 2025 年的机器学习顶会上，核心思路是把音频和视频当成平等的多模态信号，塞进一个大语言模型里统一理解和生成。这篇文章我会把它的技术思路、核心模块、训练流程、实操体验和踩坑点一起拆开聊，给做视频理解、视频生成、多模态 Agent 的同学做一个参考。

1. 先聊聊背景：为什么音视频理解与生成这么难统一

1.1 现在的视频模型普遍“近视+失聪”

前两年视频理解模型大多在干一件事：把视频抽帧，按图像序列处理。视觉上做得越来越细，但音频往往只是顺带接一个特征提取器，甚至直接忽略。问题在于，视频信息从来不只是画面。一个人说话的内容、语气、背景里的环境音、物体碰撞的声音，这些信息在纯帧序列里是不完整的。比如判断“这个人是不是在敲键盘”，单看画面可能分辨不出机械键盘和薄膜键盘的区别，但一听声音就清楚了。

生成侧更分裂。视频生成模型基本不听声音，输入一段文本，输出一段画面；音频生成模型基本不看画面，输入文本或参考音色，输出一段波形。表现在产品里就是：你想给一段无声视频配一段符合画面节奏的背景音，流程要串好几个模型，还得手动对齐关键帧和音效，非常痛苦。

JavisGPT 想干的事，就是把这套割裂的流程统一起来：一个模型、一套参数、一个 token 空间，既做视频理解，又做视频生成，中间还带音频。

1.2 统一模型要解决的四个核心问题

拆开看，Sounding-Video 这个方向其实覆盖了四类典型任务：

• 理解类：音视频问答（“视频里的人说了什么”）、音视频字幕生成（把语音和画面内容转成文本）、音视频事件定位（“第几秒开始下雨”）。
• 生成类：无声视频配音（给视频补上环境音、对白、音乐）、文本驱动视频生成（根据一段描述生成音视频片段）、音视频联合编辑（把视频里的说话人换成另一个人，同时保留语气和口型）。
• 跨模态关联类：声源定位（根据声音找出画面里发声的物体）、声音事件检测与画面验证（听到爆炸声，确认画面里确实有爆炸）。
• 统一控制类：用户用一段自然语言指令，让模型同时操作画面和声音，比如“把这段采访的背景音乐换成爵士，同时把说话人的语速调慢一点”。

这四类任务里，前两类是显性的应用价值，后两类是支撑性的能力。你会发现它们有一个共同底层需求：时间对齐。声音和画面必须在时间轴上严格同步，否则理解会错乱，生成会“声画不同步”——这也是整个论文里我认为最难啃的部分。

1.3 为什么非要用“大语言模型”做统一底座

有人会问，理解任务用传统编码器+分类头，生成任务用扩散模型或 GAN，这套老组合不也能做吗？为什么要硬塞给大语言模型？

核心原因是语言是最好的“对齐介质”。文本天然能把视觉和音频拉到一个语义空间里——听到“猫叫”和看到“猫张嘴”可以被同一句文本描述。大语言模型擅长的是长序列建模和指令跟随，音视频本质上是高维长序列，只要把它们表示成 token，Transformer 的自回归机制就可以同时处理“看图说话”和“按文生成画面+声音”两类任务。

更实际的好处是，指令微调、RLHF、工具调用这些在大语言模型上被验证成熟的技术，可以整套迁移到音视频大模型上。多模态模型最缺的不是架构能力，而是对齐能力和指令跟随能力，LLM 底座正好补上这一块。

2. 架构设计：这个“统一”到底是怎么统一的

2.1 总体框架：编码器 + 大模型 + 解码器

JavisGPT 的整体框架在我看来是典型的“输入端 token 化、中间统一理解、输出端多模态解码”三段式。输入端分为视觉编码器和音频编码器，分别把视频帧和音频波形映射成 token；中间是一个大语言模型，负责融合这些 token 并进行推理；输出端有两套解码器，一套把文本 token 解码成文字，一套把音视频 token 解码回画面和声音。

这里要注意一个细节：理解任务里大模型输出的还是文本 token，而生成任务里大模型输出的是离散的音视频 token。也就是说，语言模型本身不直接生成像素和波形，它生成的是压缩后的“音视频词汇表”索引，再把索引交给解码器还原。这样设计的最大好处是，生成任务和文本任务共用同一套自回归框架，不用为视觉生成单独设计一套复杂的采样结构。

2.2 理解任务怎么走通

输入一段视频，预处理阶段先把视频切成均匀的帧序列，音频波形经过重采样和分帧变成声谱图序列。视觉编码器和音频编码器各自产生一组 token，再加上时间位置编码，拼成一个长序列送进大语言模型。大模型通过自注意力机制，让画面里的某个物体和对应时间点的声音建立关联。

比如提问“视频里这个人说的是什么语言”，模型会先在序列里定位“人”对应的视觉 token，再定位“说话声”对应的音频 token，两个模态的信息同时被注意力层交叉引用，最后在输出端生成一句文本回答。整个过程跟我们用 ChatGPT 差不多，只是上下文从纯文本变成了多模态 token 混合序列。

2.3 生成任务怎么走通

生成任务稍微绕一些。以“给无声视频配音”为例：画面 token 输入大模型，模型理解画面里有哪些物体、发生了哪些事件、节奏快慢，然后生成一段音频 token 序列。这段音频 token 再经过音频解码器还原成波形。

关键点在于，生成音频 token 时必须同时参考画面 token，还要参考前一段已经生成的音频 token。本质上这还是一个 next-token prediction 问题，只不过每个预测出来的 token 对应的是声音片段而不是文字。联合生成画面+声音的任务会更复杂一点，因为要同时输出两组 token，论文里通常的做法是设计一种交替式解码策略：先生成视觉 token，再根据视觉 token 生成对应的音频 token，循环往复。这样能保证声画在时间轴上基本对齐。

2.4 为什么不用“理解模块+生成模块”双系统拼装

工程上最容易想到的替代方案是：一个视频理解模型 + 一个视频生成模型，中间用文本或隐藏向量连接。比如先让理解模型把视频写成一段详细描述，再让生成模型根据描述重建画面和声音。听起来也能跑，但实际问题和麻烦非常多。

第一个问题是信息损耗。理解模型输出的文本描述再详细，也丢掉了大量低频细节：人物的微表情、环境的复杂纹理、声音的空间位置。这些信息一旦变成文本就不可逆了，生成模型只能“脑补”，结果就是画面不稳定、声音对不上。

第二个问题是训练代价翻倍。两个模型各需要一套数据集、一套训练配置、一套推理服务，体积和算力开销都很大，而且两个模型单独优化时并不知道对方需要什么信息，协同效果很差。

第三个问题是任务割裂。像“根据这段视频的声音判断画面里的动作”这种任务，既不是纯理解也不是纯生成，需要在一个共享表征空间里来回切换。双系统架构很难处理这种跨界需求，统一模型天然就有优势。

3. 核心细节：Sounding-Video Tokenization

3.1 视频和音频怎么变成 token

要说清楚 JavisGPT 的技术细节，绕不开 tokenization。图像 token 化大家很熟：一张图切成 patch，每个 patch 映射成一个编码向量，再用量化器量化成离散 token。音频 token 化相对陌生一点，本质是把波形切成小片段，按时间顺序生成一组离散 token，类似把声音“写”成一段序列。

视觉 token 和音频 token 各自独立生成后，还要合并成“联合音视频 token”。合并不是简单地拼接，而是要在时间戳上做对齐。视觉 token 每秒钟有比如 8 个，音频 token 每秒钟可能也是 8 个或 16 个，它们必须一一对应到同一个时间轴上。这样大模型在注意力计算时，才能知道画面里第 3 秒出现的动作，对应的是音频序列里第 3 秒的声音。

3.2 时间对齐：联合 tokenizer 的真正难点

常规视频理解模型不用太关心音画同步，因为大多是抽帧训练，音频只是辅助信号。但 Sounding-Video 模型必须把时间对齐做进 token 的基因里，不然生成出来的视频就会——画面已经关门了，关门声还没出来。

论文里我能推测到的做法是：联合 tokenizer 在训练时同时优化三个目标。第一个是视觉重建损失，保证视觉 token 能还原画面；第二个是音频重建损失，保证音频 token 能还原声音；第三个是对齐损失，惩罚“视觉 token 和音频 token 在时间上错位”的情况。具体实现可能是让同一时间点的视觉 token 和音频 token 拥有接近的表示，或者用一个对比损失拉近它们。

这类训练最容易出现的问题我在别的项目里也遇到过：两个重建损失收敛速度不一样，视频重建 loss 降得快，音频重建 loss 掉得慢，模型容易“偏科”——画面很清晰但声音很糊。常规解法是给音频重建损失加一个更大的权重，或者在两阶段的训练中先固定视觉编码器，单独训练音频分支一小段时间。

3.3 长视频上下文怎么压缩

视频最大的麻烦是 token 太长。一秒钟视频如果抽 8 帧，每帧 256 个 token，一秒钟就有 2048 个 token，一分钟的视频就是 12 万 token。大模型的上下文窗口再长，也扛不住这种量级，所以必须做压缩。

常见的做法有几种：均匀采样、关键事件采样、多尺度时间池化。均匀采样最简单，但会丢掉关键瞬间；关键事件采样依赖一个事件检测模块，先找出画面动作剧烈或声音突变的时刻，再优先保留这些时刻的 token；多尺度时间池化是把相邻几个时间点的 token 合并成一个，比如每 4 个相邻 token 合并成一个高层 token，这样模型既能看细节，又能看宏观变化。

我怀疑 JavisGPT 采用了一种混合方案：低层 token 保留细粒度信息，高层 token 做时间池化，大模型读的是经过压缩后的高层 token，生成时再通过解码器逐级恢复细节。这个思路跟图像生成里的多尺度 VQGAN 很像，属于行业里比较成熟的路线。

3.4 tokenizer 训练时的翻车点

说几个我在实际做音视频 tokenizer 时踩过的坑，给想复现的同学提个醒。

第一个坑是音频采样率不一致。视频里的音频轨道采样率可能是 44.1kHz、48kHz，也可能是语音电话的 16kHz。如果 tokenizer 在不同采样率上表现差异巨大，下游大模型很容易学到“采样率偏差”这种无关特征。建议训练时把音频统一重采样到一个固定频率，同时做一点随机抖动增广，增强鲁棒性。

第二个坑是量化码本崩溃。离散 token 化常用向量量化，如果码本大小设置不当，训练后期会发现大量 token 都映射到同一个码字上，模型退化成一个“复读机”。解决思路是增加码本数量或采用残差量化，让不同层负责不同精度的信息。

第三个坑是视觉和音频的 token 数不匹配。如果每秒视频抽了 8 个视觉 token，音频却有 16 个 token，后续对齐就非常麻烦。最好在 tokenizer 设计阶段就统一设定两者的时间分辨率，比如都对齐到每秒 8 或 16 个 token，宁可损失一点细节，也要保证时间轴对齐是干净的。

4. 训练流程：四阶段课程学习

4.1 阶段一：音视频模态对齐

大模型训练不像普通分类任务，不能一上来就丢给它一堆任务混合数据。JavisGPT 这类统一模型，我自己推测采用的是一种课程学习路线，从简单的模态对齐开始。

第一阶段的目标是让视觉 token 和音频 token 在语义空间里“对上话”。具体任务可以是音视频匹配：给模型一段画面和一个声音，判断声音是否来自该画面；也可以是无监督重构：遮住视频某一段的音频，让模型根据画面预测音频 token。这一步不要求模型理解复杂语义，只要求它建立起跨模态的对应关系。数据量不需要标注，随便找自然视频就能训练，效果却非常关键。如果这个阶段模型没学好，后面所有任务都会带上“声画错位”的老毛病。

4.2 阶段二：理解能力激活

模态对齐之后，模型已经具备了音视频联合感知能力，下一步就是把它“教成人话”。这个阶段用大量音视频问答数据做指令微调，任务包括：

• 根据视频内容回答事实性问题（“视频里出现了几只猫？”）
• 生成带时间戳的字幕（“第 12 秒，角色 A 走进房间”）
• 声音事件检测（“视频第 8 秒有敲门声”）
• 跨模态推理（“为什么第 15 秒主角突然回头？”）

理解指令微调一个值得注意的点是：数据里必须混入“需要同时看画面和听声音才能回答”的问题，否则模型会退化成一个普通视频问答模型，只依赖视觉模态。我见过不少团队在这步偷懒，用纯视觉问答数据硬凑，最后模型对音频相关问题的答对率惨不忍睹。建议训练集里至少保证 30% 以上的样本，答案必须由音频信息才能推导出来。

4.3 阶段三：生成能力解锁

理解能力激活后，模型已经是半个“视频理解专家”了，但它还不会生成。阶段三要做的是“教它写作文”——让大模型学会输出离散的音视频 token 序列。

这个阶段的典型任务是条件视频补全：给定前几帧的视觉 token 和对应音频 token，让模型预测后面的 token 序列。还有一个任务是音频生成：给定视觉 token 序列，让模型生成对应的音频 token。训练目标就是纯 next-token prediction，跟训练语言模型没有任何区别，只是预测的对象从文本换成了音视频 token。

这里有个经验坑：生成预训练的数据量需求非常大。语言模型预训练用的是互联网文本，音视频数据的规模天然小一个量级，而且质量参差不齐。建议先在大规模“无声视频 + 外部音频库”拼出来的弱相关数据上做一轮预训练，再回到高质量音视频对上微调，能明显减少训练崩掉的风险。

4.4 阶段四：联合指令微调

最后一个阶段是把理解和生成统一起来。模型不仅要能回答问题和生成视频，还要能理解“看一下这段视频，然后给这段视频配一段声音”这种复合指令。训练数据要把问答、字幕、配音、编辑、续写全部混合，让模型学会在不同模式之间切换。

这个阶段我最想强调的一点是任务配比。理解任务和生成任务在优化目标上存在天然冲突：理解任务希望模型“少生成、多判断”，生成任务希望模型“多生成、少分析”。如果配比失控，模型会偏向某一边。我见过比较稳的做法是理解类任务和生成类任务保持在 3:7 到 4:6 之间的比例，同时把生成类任务的学习率调低一点，防止生成损失把理解能力冲掉。

4.5 训练阶段速查表

5. 实操体验：跑一次完整流程

5.1 数据格式：一条训练样本长什么样

如果你是第一次接触这种统一多模态模型，最直接的问题可能是：训练数据到底长什么样？我按目前主流的 scoped JSONL 格式给你看一条示例，假设我们要训练“音视频问答 + 配音”两个任务。

{ "video": "path/to/clip.mp4", "audio": "path/to/clip.wav", "instruction": "请描述这段视频里发生的事件，并指出说话人说的第一句话。", "ground_truth_text": "视频开头一个人走进办公室，说了一句“今天会议取消”。", "ground_truth_audio": "path/to/synthesized_speech.wav", "timestamps": [[0.0, 2.5], [2.5, 4.0]], "task_type": "qa_and_audiogen" }

注意这里的ground_truth_audio是可选的，只有生成类任务才有。理解类任务只需要ground_truth_text。timestamps字段很重要，它记录事件发生起止时间，用来训练模型对时间轴的感知能力。在我自己的实验里，如果 timestamps 标得不准，模型生成的视频音频会严重漂移，这个字段值得花大力气清洗。

5.2 推理流程：无声视频配乐/配音

假设你训练好或者拿到一个推理权重，想给一段无声视频配音，完整流程大概是这样：

1. 用解码器把视频抽成帧序列，同时把无声视频的音频轨（如果有的话）去掉，替换成静音波形。
2. 视觉编码器处理帧序列，得到视觉 token；静音波形也走一遍音频编码器，得到静音 token（或直接省略音频 token）。
3. 视觉 token + 用户文本指令（“给这个场景配一段紧张的音乐”）拼成提示序列，送进大模型。
4. 大模型自回归生成音频 token 序列。采样参数我一般设置 temperature 0.8、top_p 0.9，这个组合在我的经验里音质比较稳定，太低容易呆板，太高容易出爆音。
5. 音频解码器把 token 序列还原成波形，做一次后处理降噪和响度均衡，再封装回视频文件。

整条流程最耗时的是第 4 步的生成阶段。如果模型上下文是 10 秒视频，生成对应的音频 token 可能要跑几百步自回归，GPU 上跑起来体感比较明显。想加速的话，可以考虑分组缓存 KV 状态、并行解码相邻 token、或者用蒸馏后的轻量解码器做一次性预测。

5.3 推理性能与部署注意

这类模型的显存占用，说实话不小。视觉编码器、音频编码器、大模型主干、解码器四件套加起来，在 7B 主干的规模下，FP16 推理一个 16 秒视频的 batch，大概要吃掉 25-35GB 显存。如果加上长上下文 KV cache，可能还要再加 8-10GB。做线上服务的话，建议至少上单卡 80GB 的配置，或者用模型并行把视觉编码器和解码器拆到单独卡上。

部署时还有几个容易踩的坑：一是输入视频分辨率不一致会让视觉 token 数量波动剧烈，影响 batch 效率，最好在预处理阶段统一缩放或做动态 padding；二是音频解码端对采样率敏感，建议统一输出 48kHz 或 44.1kHz，不要跟着视频源采样率走；三是长视频生成时解码器可能累计误差，每生成 5-10 秒最好用轻量质量检测模块人工卡一下，避免声画不同步越积越严重。

5.4 从论文到落地容易踩的坑

我自己在复现类似模型时，踩过最深的坑是 tokenizer 不匹配。训练和推理时如果用了不同版本的视觉 tokenizer，画面输入还好，音频 tokenizer 一旦更新，模型生成的音频质量会急剧下降。原因是音频 token 的码本几乎不可跨版本复用，画面 token 语义兼容性稍好，但也会出问题。所以如果你要基于 JavisGPT 做二次开发，第一件事就是把 tokenizer 权重冻结，任何微调都不要再动它。

第二个坑是指令格式不一致。训练时用了某种 prompt 模板（比如“System: 你是音视频助手。User: ... Assistant: ...”），推理时必须用完全一样的模板。很多项目效果不知道为什么变差，十有八九是 prompt 里加了一句训练时没见过的话，导致模型对指令理解偏移。我建议把模板代码单独抽出来做成一个公共函数，训练和推理共用，不要手写两套。

第三个坑是评测不全面。只看视频生成指标（如 FVD、CLIP Similarity）容易忽略音频质量，只看音频指标又感受不到声画同步问题。建议在每个测试集上都同时算三组指标：视频质量、音频质量、音画同步时间差，缺一不可。

6. 应用场景：哪些地方会先跑起来

6.1 短视频与影视后期

短视频是音视频统一模型最直接的落地场景。现在大量创作者在处理视频时，最花时间的就是配乐、配音、音效对齐。原本要手动拖时间轴、对齐关键帧，用 JavisGPT 这类模型可以直接说“在画面切换处加一个鼓点”，模型会在对应位置生成音效。影视后期方面，更实用的能力是“声音修复”：一段旧视频只有模糊的背景音，模型可以根据画面推断出应有的对话信息或环境音，生成更干净的声音轨道。自动音效生成也能大幅缩短剪辑师的工作时间——不用再满世界找音效库了。

6.2 视频搜索与内容管理

另一个我看到刚需的是视频语义索引。目前视频搜索主要靠标题、标签，或者 OCR 识别字幕，很难做到“听懂画面里发生了什么”。统一模型可以把视频内容自动转成带时间戳的结构化文本——什么人在什么时候做了什么事、说了什么话、周围有什么声音——然后交给传统搜索引擎做索引。对做知识库、档案馆、在线教育平台的同学来说，这是实打实的效率提升。

6.3 无障碍工具

无障碍领域是我个人觉得最有温度的场景。听障用户看视频需要高质量字幕，但纯字幕丢了大量声音信息：敲门声、脚步声、警报声、笑声的语调视频里是不会显示的。JavisGPT 这类模型可以根据声轨自动生成“声音描述文字”，比如“听到急促敲门声”“背景里有人低声交谈”，让听障用户也能感知完整的氛围。反过来，视障用户需要把画面转成语音描述，统一模型生成的画面描述可以更自然，因为它同时参考了画面和声音两路信号。

6.4 具身智能与监控场景

从长期看，具身智能机器人需要同时理解视觉和听觉。机器人在厨房帮忙，听到“水开了”的嘶嘶声，同时看到锅盖在震动，需要快速判断去关火。场景里的声画联合推理，统一模型天生适合。监控场景也有类似需求：突发情况往往伴随异常声音，模型不仅要知道有声音，还要定位声音来源、判断是否需要告警。这些任务以前要让视觉系统和音频系统各跑一套再融合，现在一个模型全干了。

7. 冷静聊聊：惊喜、短板与建议

7.1 值得点赞的设计

JavisGPT 最有价值的，我认为是真正把“音频”从辅助地位提升到了跟视频平等的地位。之前的视频大模型多数只把音频当作附带信号，而它把音频和视频联合 token 化，在架构层面让声音参与理解和生成的所有环节。这个设计彻底解决了“音频管音频、画面管画面”的割裂问题。

另外，统一理解和生成到同一个 LLM 里，从工程角度是划算的。模型参数可以共享，训练流程可以复用，部署底座统一，对做产品的人来说维护成本低很多。理解任务学到的时间对齐能力，可以直接迁移到生成任务上，这种跨任务的正向迁移是双系统方案给不了的。

7.2 明显短板与我的担心

说不担心是假的。第一个担心是离散 token 化的信息瓶颈。音频 token 化到每秒 16 个 token 左右时，高频细节已经损失不少；视频 token 化在高分辨率、高帧率场景下信息压缩更严重。统一模型生成的音视频，质量上限被 tokenizer 锁死了。短期看它适合做“轻量级生成”，真要达到电影级后期标准，难度不小。

第二个担心的点是长视频的上下文限制。自回归模型生成音视频 token 是一步一步来的，长视频意味着生成步数爆炸。16 秒视频可能就要近千步解码，分钟级视频的实时性目前不现实。现实落地大概率要先把视频切成小段，分段生成再接起来，但分段之间的音频节奏和画面光影一致性又很难保证。

第三个担心是数据与评测。音视频联合数据集的标注成本比纯视觉数据高得多，别说音画同步标注，连“这段音频是否来自这段视频”这种监督信号都很难大规模采集。评测方面，目前视频生成指标、音频生成指标、音画同步指标分散在不同论文里，没有一套公认的联合评测体系。这会让研究者很难客观比较不同模型的实际水平。

7.3 想跟进的人三条建议

如果你打算顺着 JavisGPT 的思路做研究或产品，我三条建议供参考：

第一，先玩透 tokenizer。别一上来就调大模型，先把视觉和音频的联合 tokenizer 训练到能稳定重建、稳定对齐。这一步决定了你整个系统的上限。第二，从小场景切入。别想一口吃个“全功能音视频助手”，先聚焦一个具体任务，比如“给录屏视频生成讲解配音”，把数据、模型、评测闭环跑通，再扩展能力和任务面。第三，重视时间对齐评测。不管用什么数据、什么架构，最终产品要过的一关永远是“声画同不同步”。早早在评测集里加入时间偏移检测，能帮你避免很多后期返工。

我个人在实际操作中的体会是，这类统一音视频模型最难的不是某一模态的单独能力，而是如何在同一个模型里消化和理解“时间”这个维度。画面会流动，声音会流动，两者一旦错位，所有高级能力都会变成空中楼阁。JavisGPT 的贡献在于，它第一次让我看到音视频理解和生成可以共用一套架构、一套 token、一条训练管道，从工程角度这是非常高效的方向。如果你最近也在做多模态相关项目，建议先盯着它的 tokenizer 和训练阶段细节看，大概率比直接看整体效果图更有收获。