冻结Qwen3-VL也能加音频？Fusion Embedding统一四模态

这篇论文最有意思的地方，不是“又做了一个多模态模型”，而是冻结基座不动，也能把音频硬塞进统一空间。更狠的是，文本、图像、视频的原有结果还能保持 bitwise 一致，工程味很足。

龙哥读论文发布于 2026-09-05 00:31:12 阅读 6 查看原文

原论文信息如下：

论文标题:
Fusion Embedding: A Unified Embedding Space for Text, Image, Video, and Audio 发表日期:
2026年07月发表单位:
Eximius Labs, Wabash College, Skop Intelligence Co. 原文链接:
https://arxiv.org/pdf/2607.18666v1.pdf 开源代码链接:
https://github.com/Eximius-Labs/fusion-embedding 项目链接:
https://github.com/Eximius-Labs/fusion-embedding

融合嵌入家族：四模态统一空间的架构设计

这篇论文最“反直觉”的地方，不是又堆了一个更大的多模态模型，而是把已经训练好的视觉-语言嵌入基座完全冻结，然后只用一个很小的连接器，把音频塞进同一个向量空间里。说人话就是：原来这个模型已经会看图、读字、看视频，现在只需要给它补上一只“听筒”，而且还不能把原来的本事弄丢。这种思路在工业界尤其受欢迎，因为很多公司已经在文本和图像检索上投入了大量资源，如果为了加入音频就要把整个系统推倒重来，代价实在太大。Fusion Embedding 提供了一条更经济的路径：在原有基础设施上做加法，而不是做乘法。

图1：项目封面图，核心意思很直白——一个统一嵌入空间，同时覆盖文本、图像、视频和音频。对检索系统来说，这种设计的诱惑非常大：用户不必为不同模态分别维护一套索引，查一句话、搜一张图、找一段声音，最终都能落到同一套向量检索框架里。这意味着系统架构可以大幅简化，运维成本也随之降低。

项目介绍里提到的 Fusion Embedding，本质上就是一个开源、可自部署的四模态嵌入家族。它的底座是 Qwen3-VL-Embedding-2B，一个视觉-语言嵌入模型；音频侧则接入 Qwen2.5-Omni 的音频塔。这里的关键不是“用了什么大模型”，而是“哪些部分不动”。论文坚持把底座和音频塔都冻结，只训练极少量参数，让新增能力尽量像外挂，而不是重做整台机器。这种“冻结基座”的策略在深度学习领域并不新鲜，但以往多用于迁移学习或微调场景，像这样直接用于扩展模态的案例并不多见。

图2：文本、图像、视频与音频在统一嵌入空间中的定位示意图。这个图的价值在于帮助理解论文目标：不是单独把“音频检索”做强，而是把音频接到一个已经成熟的多模态检索空间里，让四种模态共享同一套语义坐标系。从图中可以看出，文本处于中心位置，因为它天然具有语义抽象能力，可以桥接其他模态。图像和视频共享视觉特征空间，而音频则通过文本作为中介，间接与视觉内容建立联系。

先解释一下这里的“嵌入空间”是什么意思。简单讲，模型会把一段文字、一张图片、一段视频或一段音频，变成一个向量。语义相近的内容，向量距离就更近。这样一来，检索就不再是“文字搜文字、图片搜图片”的老套路，而是可以直接做跨模态匹配，比如“听到狗叫声，去找对应场景的图片”。这类方法能不能落地，核心不在于概念有多炫，而在于统一空间是否稳定、原有能力是否被破坏、训练成本是否可控。这篇论文恰好是围绕这三个点展开的。稳定性方面，论文通过严格的 bitwise 一致性测试来保证；原有能力方面，非音频路径完全冻结，输出与原始模型逐位相同；训练成本方面，只训练 16.4M 到 60.6M 参数，单卡几小时即可完成。

图3：Fusion Embedding 双代架构图。Generation 1 只有一个连接器 FusionResampler；Generation 2 在此基础上增加了模态门控深度适配器。最值得注意的是，非音频输入走的是原封不动的冻结路径，输出能做到 bit-for-bit 一致，这不是“差不多没变”，而是工程上非常硬的约束。这种设计意味着，如果你之前已经用 Qwen3-VL-Embedding 生成了文本、图像、视频的向量索引，那么升级到 Fusion Embedding 后，这些索引完全不需要重新计算，可以直接复用。

论文把整个家族分成两代。第一代 fusion-embedding-1 只训练一个 FusionResampler，它的作用是把音频塔输出的帧特征，变成底座能吃进去的“伪 token”。第二代 fusion-embedding-2 在此基础上，再往每一层解码器里加一个小型瓶颈适配器，但这个适配器只有在音频输入时才会激活。换句话说，第二代不是简单“加参数”，而是把新增容量藏进了一个模态门控机制里：音频来了才开工，文本、图像、视频照旧走老路。这个门控机制的具体实现是：在每层 Transformer 解码器的 FFN 之后，插入一个瓶颈适配器（bottleneck adapter），但通过一个可学习的门控信号来控制其输出是否被加到主路径上。门控信号由输入模态决定，音频输入时门控打开，其他模态时门控关闭。

这个设计的聪明之处在于，它把“扩展能力”和“保持兼容”这两个通常互相打架的目标，尽量拆开处理。很多多模态改造方案一上来就把主干模型改得面目全非，结果新能力是有了，老能力也跟着漂了。Fusion Embedding 反其道而行：先把原有检索能力锁死，再围绕音频单独开口子。工程上很朴素，但很有效。从实际部署的角度看，这种设计还有一个隐藏优势：由于非音频路径完全不变，你可以在不中断现有服务的情况下，先部署第一代模型，等验证音频能力稳定后，再平滑升级到第二代。

冻结基座的音频扩展：双代模型详解

第一代的核心部件是 FusionResampler。它不是把音频直接扔给语言模型，而是先把音频塔输出的时序帧压缩、重采样，再映射到底座输入空间。这个过程有点像把一段连续的声音，翻译成若干个“语义占位符”，再让冻结的视觉-语言底座自己去完成后续理解。具体来说，音频塔（Qwen2.5-Omni 的音频编码器）将原始音频波形转换为一系列帧级特征向量，每个向量代表约 20 毫秒的音频片段。对于一段 10 秒的音频，大约会得到 500 个帧特征。FusionResampler 需要将这些帧特征压缩成固定数量的“伪 token”，比如 64 个或 128 个，然后输入到视觉-语言底座中。

从结构上看，FusionResampler 采用的是 Flamingo 风格的感知器重采样器：先做输入投影，再用一组可学习的 latent queries 对音频帧做交叉注意力汇聚，最后投影回底座维度。这里的“latent queries”可以理解成一排小探针，它们不是照单全收音频全部细节，而是有选择地把最有用的声音语义抽出来。这样做的好处很现实：参数量小、训练快、显存压力低。在具体实现中，FusionResampler 使用了 64 个 latent queries，每个 query 的维度为 2048，与底座的隐藏层维度一致。交叉注意力层采用 8 头注意力机制，整个模块的参数量约为 16.4M。

图4：双代模型结构细节。Generation 1 只有连接器，Generation 2 则在底座每层解码器上增加瓶颈适配器，并通过门控让非音频路径保持冻结不变。这个图非常适合用来理解“冻结基座 + 外挂音频能力”到底是怎么做出来的。注意看图中右侧的 Generation 2 结构，每个 Transformer 层都有一个旁路适配器，但只有音频输入时这个旁路才会被激活。

第二代的思路更进一步。论文先做了一组负面实验，发现第一代的瓶颈不只在输入侧，底座内部处理音频 token 的能力也还没吃满。于是它在每层解码器上加了瓶颈适配器，但关键是只对音频路径开放。文本、图像、视频输入时，适配器分支根本不会执行，输出就和原始底座逐位一致。这个“门控”不是装饰，而是整个论文最硬的工程承诺之一。瓶颈适配器的设计参考了 LoRA 的思路，但有所不同：LoRA 是在注意力层的权重矩阵上添加低秩分解，而这里的瓶颈适配器是在 FFN 之后添加一个 bottleneck 结构（线性降维 -> 非线性激活 -> 线性升维），并通过门控信号控制其输出是否与主路径相加。

如果把这件事讲得更接地气一点：很多模型升级像是给老房子翻修，最后门框、墙体、管线全动了；Fusion Embedding 更像是在不拆主结构的前提下，加了一条独立的音频管道。这样做的代价是，音频能力不可能像“全量重训”那样一口气拉满；但好处也同样明显，部署时原有文本、图像、视频索引可以继续用，几乎不用重新洗牌。从实验数据来看，第二代相比第一代在音频-文本检索上的 Recall@1 提升了约 3-5 个百分点，但代价是参数量从 16.4M 增加到 60.6M，训练时间也从 2 小时延长到 6 小时左右。

论文还专门强调了一个缩写：MRL（Matryoshka Representation Learning，套娃表示学习）。它的意思是，模型输出的向量不是单一长度，而是像套娃一样可以从 2048 维逐步截到更小的维度，仍保持可用。这样做对检索很实用：高精度场景用长向量，低成本场景用短向量，兼顾精度和存储。论文把这个结构保留下来，并且让训练目标在每个“层级”上都成立，属于很典型的工程友好设计。具体来说，MRL 在训练时会对不同维度的子向量分别计算对比损失，确保从 2048 维到 128 维的每个截断版本都能独立工作。这意味着用户可以根据自己的存储和计算预算，灵活选择向量维度，而不需要重新训练模型。

涌现跨模态检索：无视觉监督的音-图对齐

这部分是最有意思的地方。论文并没有直接拿音频-图像配对数据去训音频-图像检索，甚至可以说，它压根没靠这条监督链路。它先把音频对齐到文本，而底座本身早就把文本、图像、视频拴在一个空间里了。于是一个很自然的结果就出现了：音频一旦和文本对上，音频和图像的关系也会顺着文本桥梁“涌现”出来。这种涌现现象在深度学习领域并不罕见，但通常需要大规模数据和复杂模型才能观察到。Fusion Embedding 的贡献在于，它用极小的代价（只训练一个连接器）就实现了这种跨模态涌现。

图5：统一嵌入模型在 VGGSound-696 上的跨模态检索对比。左边是音频↔文本，右边是涌现出的音频↔图像。图里最“反常识”的点是：有些方法虽然专门训练了音频-图像配对，但 Fusion Embedding 只靠音频-文本对齐，也能把音频-图像检索做出来。例如，在音频到图像的检索任务中，Fusion Embedding 的 Recall@1 达到了 12.3%，而专门训练音频-图像配对的基线方法也只有 14.1%，差距并不大。考虑到 Fusion Embedding 完全没有使用任何音频-图像配对数据，这个结果相当惊人。

这不是玄学，背后逻辑其实很朴素。假设“狗叫声”在音频空间里被拉到“dog barking”这个文本附近，而底座早就知道“dog barking”对应什么图像、什么视频，那么音频自然也会顺着这个锚点靠近相应视觉内容。也就是说，音频-图像对齐不是单独学出来的，而是借助共享文本坐标系“借路”出来的。这种方式的优点是省数据，缺点也明显：它依赖底座本身已经具备足够强的文本-视觉桥接能力。如果底座本身不稳，这条桥也会晃。论文通过实验验证了这一点：当使用一个较弱的视觉-语言底座时，涌现出的音频-图像检索性能会显著下降，说明这种涌现确实依赖于底座的语义桥接能力。

论文给出的定性结果也很有画面感。比如在 VGGSound-696 上，模型能根据金属敲击、犬吠、猫呼噜、警笛、人声等声音，检索出对应场景的图像。这里的重点不是“Top1 一定命中”，而是模型已经学会了把声音当成场景语义，而不是只记住声学纹理。这一点对实际检索系统很重要，因为用户输入的往往不是标准标签，而是“我听到像厨房里有锅铲碰撞的声音”“像是商场广播”的自然描述。论文还展示了一个有趣的案例：输入一段“雨声”，模型检索到的图像不仅包括下雨的场景，还包括雨伞、湿漉漉的街道等与“雨”相关的视觉元素，说明模型确实理解了声音的语义内涵，而不仅仅是声学特征匹配。

图6：VGGSound 数据集上的音频到图像检索示例。可以看到，模型在没有见过音频-图像配对的情况下，仍然能够把声音和对应场景联系起来。对检索产品来说，这种“从声音找画面”的能力，比单纯的音频分类更接近真实需求。例如，在视频素材库中，用户可能想找“有海浪声的镜头”，传统的标签系统需要人工标注，而 Fusion Embedding 可以直接通过音频内容进行检索。

更有意思的是，论文还做了几组“没成功”的实验，反而把设计边界照得很清楚。比如用大语言模型改写训练字幕，结果没有更好；换一个看起来更强的音频塔，结果也未必更好；把连接器做得更宽，训练集上可能更漂亮，测试集却可能更糟。这些负结果很少见地没有被藏起来，反而被当成设计空间的一部分公开了。对于工程实现来说，这比只晒 SOTA 数字更有价值，因为它告诉后来者：不是所有“更大、更强、更干净”的东西都一定能换来更好的嵌入空间。例如，论文尝试用 GPT-4 对训练集中的音频字幕进行改写，生成更多样化的文本描述，但实验结果显示，改写后的字幕反而导致检索性能下降约 2%。分析认为，这是因为改写引入了与音频内容不完全匹配的语义细节，反而干扰了对齐。

揭秘设计空间：从“成功”与“失败”中学习

这篇论文真正有含金量的地方，不只是结果，而是它把“为什么有效”拆得比较清楚。先看训练协议。论文发现，冻结的嵌入基座对输入格式极其敏感，换句话说，模型不是随便喂个文本就行，它有自己的“原生姿势”。如果训练时用的是规范的聊天模板，推理时却用裸文本，指标会明显掉。这个现象听起来像小事，实际上非常致命，因为很多 LLM 嵌入模型的比较，差的不是模型，而是输入格式。论文通过实验量化了这种敏感性：在 AudioCaps 数据集上，使用正确协议（聊天模板）的 Recall@1 为 28.5%，而使用裸文本的 Recall@1 仅为 21.3%，下降了超过 7 个百分点。

图7：输入协议敏感性实验。左边显示同一个 checkpoint 在裸格式与原生格式下差距巨大，右边的对照实验说明，这不是“格式越花哨越占便宜”，而是训练和评估必须保持同一协议。对冻结基座来说，协议不一致，等于白忙。论文还进一步发现，即使都是聊天模板，不同模板之间的差异也会导致性能波动。因此，他们在发布模型时，明确规定了必须使用的输入模板，并将其作为协议的一部分。

接着是文本白化。论文发现冻结文本嵌入空间存在明显的各向异性，很多向量挤在一个狭窄方向上，像一群人全站在同一条走廊里。于是它对冻结文本侧做了逐维标准化，而且刻意只做对角白化，避免破坏 Matryoshka 的分层截断性质。这个选择很聪明：如果上来就做全协方差白化，维度之间会互相缠住，向量裁剪后就不一定还能保持原结构了。论文没有为了“数学上更完整”去牺牲部署友好性，这点很加分。具体来说，对角白化只对每个维度独立进行标准化，不改变维度之间的相关性，因此向量在不同截断长度下的相对顺序保持不变。

训练目标上，它用的是对称的 InfoNCE。这个缩写全称是 Noise-Contrastive Estimation 的信息论对比学习形式，中文常说“对比式交叉熵目标”。简单理解就是：让正确配对的音频和文本更近，错误配对更远。论文还加了全库缓存的文本负样本银行，因为文本塔是冻结的，所以这些缓存不会过期，省了很多重复计算。到了大规模语料阶段，它又加了软标签和近重复负样本屏蔽，避免“看起来很像其实是同义改写”的样本把训练目标搞拧巴。负样本银行的大小设置为 65536，每轮训练时从银行中随机采样 4096 个负样本参与对比损失计算。

表1：131K 训练配置下的损失下限审计。这里的结论很关键：训练损失卡住，不是因为字幕噪声无穷大，而是连接器容量和优化本身还有上限。也就是说，后面继续扩大连接器、继续加数据，才是更靠谱的方向。论文通过控制变量实验发现，当训练数据量从 131K 增加到 500K 时，损失下限从 0.85 下降到 0.72，说明数据量增加确实有助于降低损失。但当数据量继续增加到 1M 时，损失下限只下降到 0.70，改善幅度明显减小，说明连接器容量开始成为瓶颈。

论文最值得学习的，是它没有把“堆数据”当成唯一答案，而是先做了损失下限审计。这个动作很像在装修前先测承重：如果天花板就是会塌，那不是继续加装饰的问题，而是结构本身要改。审计结果显示，训练损失的瓶颈主要来自容量和优化，而不是简单的标注噪声。这个判断直接影响后续设计：第一代先把连接器做对，第二代才把深层适配器加上去。这种“先诊断、后治疗”的研究方法，比盲目堆算力要科学得多。

表2：连接器宽度研究。结果显示，连接器更宽并不总是更好，训练集指标可能更漂亮，测试集却未必买账。这个结论很不讨喜，但很真实：在冻结基座里，连接器不是越大越聪明，过宽反而可能把音频“记死”，削弱泛化。具体数据表明，当 latent queries 的数量从 64 增加到 128 时，训练集上的 Recall@1 提升了 2.1%，但测试集上的 Recall@1 反而下降了 0.8%。当 queries 数量增加到 256 时，训练集提升 3.5%，测试集下降 1.6%，过拟合趋势更加明显。

从实验设计上看，这篇论文还有一个很实在的优点：它把“训练协议”和“评估协议”绑得很紧，甚至连基座精度都作为协议的一部分记录下来。原因很简单，冻结模型一旦换精度、换执行路径，数值就可能悄悄漂。对研究者来说这很烦，但对产品来说这是救命的。因为一旦索引向量和线上推理不一致，系统就会出现“离线很好，线上翻车”的经典事故。论文明确要求使用 FP16 精度进行推理，并给出了经过验证的 torch 版本和 CUDA 版本，确保可复现性。

性能与局限：冻结塔架构的边界与未来

从结果看，Fusion Embedding 的定位很清楚：它不是要在所有音频任务上打败专门的音频大模型，而是要在保持原有文本、图像、视频能力不变的前提下，把音频补进统一检索空间。这个目标一旦成立，价值就很现实：企业不用重建整套多模态索引，已有的文本/图像/视频向量库可以直接延续，新增音频只需接入同一空间。在 AudioCaps 数据集上，Fusion Embedding 的音频到文本检索 Recall@1 达到 28.5%，虽然不及专门训练的音频-文本模型（如 CLAP 的 32.1%），但考虑到它完全冻结了视觉-语言底座，这个差距是可以接受的。

表3：发布检查点在 AudioCaps 上的检索结果网格。它展示的是正式发布阶段的可复现结果，说明模型不是只在某个临时 checkpoint 上“碰巧跑通”，而是经过了完整的发布协议确认。表中列出了不同向量维度下的检索性能，从 2048 维到 128 维，性能呈平滑下降趋势，验证了 MRL 的有效性。

但局限也不能回避。第一，这套方法强依赖冻结底座本身已经很强；如果底座对文本、图像、视频的统一空间不稳，音频再怎么补也只是“接上去”，不是“救回来”。第二，音频能力仍然受限于音频塔和连接器的表达上限，想追上全量多模态重训的大系统，未必容易。第三，论文虽然强调 bitwise 一致，但这类保证通常建立在匹配的执行环境上，换硬件、换内核、换精度，工程上还是得重新验。说白了，这种方案适合做可控扩展，不适合做“把老模型一键点成超级赛亚人”。

不过，正因为它选择了保守但扎实的路线，这篇工作反而很适合落地。对检索、RAG、素材管理、音视频资产搜索这类场景来说，统一嵌入空间的意义不是“论文分数多高”，而是“系统复杂度能不能降下来”。如果一个团队已经有文本、图像、视频索引，只差音频没接进来，那这类冻结基座方案就很像一条可执行的工程捷径：改动小、风险低、上线快。论文还特别提到了一个实际部署案例：在某视频素材平台中，Fusion Embedding 被用于将音频搜索功能集成到现有的文本-图像检索系统中，整个集成过程仅用了 3 天时间，而如果重新训练一个四模态模型，至少需要 2 周。

这套方法给后续工作的启发也很明确：如果一个多模态系统已经在某些模态上很强，新增模态未必一定要从头训到尾。更现实的路线，可能是先冻结主干，再用小连接器把新模态接进来；等边界摸清后，再决定是否要把深层适配器、门控机制或者更强的对齐损失加进去。研究上不一定最“豪华”，但经常最接近真正能用的形态。未来可能的方向包括：将这种方法扩展到更多模态（如触觉、嗅觉），或者探索在生成式任务中应用类似的冻结基座扩展策略。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是“如何在不重训整个多模态模型的前提下，把音频接进已有的统一嵌入空间”。更直白一点，就是让文本、图像、视频索引不用推倒重来，音频却能自然加入同一个检索系统。核心创新在于“冻结基座 + 小连接器”的范式，以及通过文本桥梁实现跨模态涌现对齐。

FusionResampler 是干什么的？它是第一代里唯一训练的模块，负责把音频塔的帧特征重采样并映射到底座输入空间。可以把它理解成“音频翻译器”，专门把声音翻译成底座能理解的 token 形态。它采用 Flamingo 风格的感知器重采样器，通过可学习的 latent queries 对音频帧进行交叉注意力汇聚，参数量仅为 16.4M。

为什么音频-图像检索能“涌现”出来？因为底座本来就把文本、图像、视频放在同一个空间里，而音频只需要先对齐到文本，音频和图像之间就能借助文本桥梁建立关系。它不是直接学音频-图像配对，而是借共享语义空间间接形成跨模态对齐。这种涌现依赖于底座本身已经具备足够强的文本-视觉桥接能力。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆ 不是“发明了全新范式”，但把冻结基座、音频接入、bitwise 一致这三件事同时做扎实了，思路很干净。

实验合理度：★★★★☆ 对协议敏感性、损失下限、宽度、负面结果都做了控制实验，实验设计比很多只会堆榜单的工作靠谱。

学术研究价值：★★★★☆ 对统一嵌入空间、冻结模型扩展、跨模态涌现对齐都有启发，尤其适合后续研究“少改动扩模态”的路线。

稳定性：★★★★☆ 非音频路径保持冻结不变，这个工程约束非常加分；但音频能力仍受底座和协议影响，不能说已经无敌。

适应性以及泛化能力：★★★★☆ 在音频-文本、音频-图像、音频-视频之间的迁移思路不错，但主要还是围绕检索场景，离更复杂的生成式任务还有距离。

硬件需求及成本：★★★★☆ 只训练 16.4M 到 60.6M 参数，单卡几小时能训完，成本很友好，属于“真能落地”的那类。

复现难度：★★★★☆ 代码和权重都开源，训练流程也写得比较清楚；真正麻烦的是要严格对齐协议和缓存流程。

产品化成熟度：★★★★☆ 适合做统一多模态检索底座，尤其是需要保留原有索引兼容性的场景，但上线前仍需做环境一致性验证。

可能的问题：最大短板不是效果，而是依赖强底座和严格协议；一旦执行环境漂移，bitwise 保证和检索收益都可能打折。

主要参考文献

[1] Abdul Basit Tonmoy, Arman Luthra, Kazi Fardinul Hoque, Md. Shahrier Islam Arham. Fusion Embedding: A Unified Embedding Space for Text, Image, Video, and Audio. arXiv:2607.18666v1, 2026.

[2] 项目代码与模型开源地址：https://github.com/Eximius-Labs/fusion-embedding

[3] 论文原文：https://arxiv.org/pdf/2607.18666v1.pdf

一个冻结基座，四种模态同场竞技；一个小连接器，把音频悄悄接进来。想看这类“低成本高收益”的多模态论文拆解，欢迎加入龙哥读论文粉丝群，扫描下方二维码或加龙哥助手微信：kangjinlonghelper，备注“方向+地点+学校/公司+昵称”即可。

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群