砍掉编码器，AI 反而更强了？Gemma 4 12B 的 Encoder-Free 架构深度拆解

> Google DeepMind 在 Gemma 4 12B 上做了一件反直觉的事：把视觉编码器和音频编码器全砍了，用 3500 万参数的 Embedder 替代了 5.5 亿的 ViT，用一层线性投影替代了 3 亿的 Conformer。结果？模型在 16GB 内存的笔记本上跑多模态任务，延迟更低、微调更容易——而且能力没丢。这不是压缩，是范式转移。

---

一、多模态模型的"标准答案"出了什么问题？

过去三年，多模态大模型的架构几乎是一个模子刻出来的：

图像 → ViT/SigLIP/CLIP 编码器 (150M-550M 参数)
                              ↓
音频 → Conformer/Whisper 编码器 (150M-300M 参数) 
                              ↓
文本 → Token Embedding
                              ↓
                        LLM 解码器

这个"标准答案"有三个结构性缺陷：

1. 延迟叠加

编码器必须先跑完前向传播，LLM 才能开始处理。对于实时交互场景（语音助手、视频理解），这意味着用户已经说完话了，模型还在等编码器。图像编码器的 27 层 Transformer + LLM 的几十层，两阶段串行执行，延迟直接相加。

2. 内存碎片

编码器和 LLM 是两套参数。5.5 亿视觉编码器 + 3 亿音频编码器 + 120 亿 LLM = 接近 130 亿参数。而且这些内存不是连续的——编码器跑完才能释放，LLM 才能加载。在 16GB 内存的设备上，光是编码器就占掉了近 1GB，留给推理的 KV Cache 空间被挤压。

3. 微调死锁

实践中，微调多模态模型时大家只调 LLM，编码器是冻结的。为什么？因为编码器的训练数据和 LLM 不对齐，联合训练容易发散。结果就是：你可以让模型学会用新语言回答问题，但它"看世界"和"听声音"的方式永远是出厂设置，改不了。

---

二、Gemma 4 12B 的解法：直接砍了编码器

Gemma 4 12B 的架构图异常简洁：

图像 → 48×48 Patch → 单层 MatMul (35M) → LLM
音频 → 40ms 帧 → 线性投影 → LLM
文本 → Token Embedding → LLM
                        ↓
                   统一解码器

没有编码器。所有模态直接投影到 LLM 的嵌入空间，然后交给同一个解码器处理。

2.1 视觉处理：550M → 35M

维度	传统 Gemma 4 (E4B)	Gemma 4 12B
编码器	27 层 ViT (550M 参数)	单层 MatMul (35M 参数)
Patch 尺寸	16×16 → 池化到 48×48	直接 48×48
位置编码	ViT 内部学习	因式分解 X/Y 坐标查找
注意力	27 层自注意力	无独立注意力层

处理流程： 1. 图像切成 48×48 像素的 patch 2. 每个 patch 用一个矩阵乘法投影到 LLM 隐藏维度 3. 位置编码：查两个学到的矩阵——X 矩阵给横坐标 embedding，Y 矩阵给纵坐标 embedding，相加得到位置向量 4. 位置向量加到 patch embedding 上，归一化 5. 完成。进入 LLM 解码器。

整个过程没有注意力计算。每个 patch 独立处理，不与其他 patch 交互——这个"交互"被推迟到 LLM 的注意力层里做。

2.2 音频处理：300M → 0

维度	传统 Gemma 4 (E2B/E4B)	Gemma 4 12B
编码器	12 层 Conformer (305M 参数)	无
处理方式	特征提取 + 注意力	原始波形直接投影
帧长	复杂分帧 + 特征工程	40ms (640 采样点 @ 16kHz)
位置编码	Conformer 内部	复用 LLM 的 RoPE

处理流程： 1. 16kHz 原始音频切成 40ms 帧（每帧 640 个值） 2. 线性投影到和文本 token 相同的嵌入维度 3. 时间序列的位置信息由 LLM 自带的 RoPE（旋转位置编码）处理 4. 完成。进入 LLM 解码器。

没有任何特征提取。没有梅尔频谱图。没有 Conformer 层。原始波形直接变成 token，丢给 LLM 自己去"听"。

---

三、为什么这能工作？一个反直觉的假设

Encoder-Free 不是 Google 首创。Fuyu-8B（Adept, 2023）、EVE（Salesforce, 2024）、Chameleon（Meta, 2024）都走过这条路。但 Gemma 4 12B 是第一个主流生产级模型采用这个架构。

核心假设是：LLM 的解码器层足够强大，可以自己完成编码器的工作。

在传统架构中，编码器的职责是： 1. 从原始输入中提取高级特征（图像：边缘→纹理→对象；音频：时域→频域→音素） 2. 将这些特征压缩到低维嵌入空间 3. 添加位置/时间信息

Gemma 4 12B 的做法是把这些职责重新分配：

• 特征提取 → 交给 LLM 的前几层 Transformer 去做
• 压缩 → 投影层（单层 MatMul）做初步压缩，LLM 注意力做语义压缩
• 位置编码 → 轻量 X/Y 查找表 + RoPE

这个假设成立的前提是 LLM 有足够容量（12B 参数）和足够深度（能学到从原始像素/波形到语义的多层抽象）。如果 LLM 太浅或太小，前几层可能还没学会视觉/音频特征提取就耗尽了容量。

Gemma 4 12B 敢这么做，可能是因为： 1. 12B 参数量对端侧设备来说已经是"大模型"了，深度足够 2. Google 有充足的训练资源让模型自己"学会"如何处理原始输入 3. 统一的端到端训练信号比冻结编码器的两阶段训练更强

---

四、工程优势：不只是参数少

4.1 延迟：LLM 不用等编码器

传统流程：

用户上传图片 → 编码器处理 (延迟 T1) → LLM 开始生成 (延迟 T2)
总延迟 = T1 + T2

Encoder-Free 流程：

用户上传图片 → Patch 投影 (几乎零延迟) → LLM 开始生成
总延迟 ≈ T2

对于语音交互，这意味着模型可以在用户说话的同时就开始"预加载"音频 token，实现真正的流式处理。

4.2 内存：连续统一

组件	传统架构内存	Encoder-Free 内存
视觉编码器	~550M 参数 + KV Cache	35M 参数
音频编码器	~305M 参数 + KV Cache	0
LLM	12B 参数 + KV Cache	12B 参数 + KV Cache
总计	~13B+ 参数	~12B 参数

省下来的内存可以分配给：

• 更大的 batch size
• 更长的上下文窗口
• 更低的量化精度损失

4.3 微调：一个循环，一套权重

这是开发者最实际的收益：

维度	传统架构	Encoder-Free
微调范围	通常只调 LLM，编码器冻结	全部权重统一更新
LoRA 适配	只影响文本理解	同时影响视觉+音频+文本
训练管道	多阶段（先调编码器，再调 LLM，或冻结编码器只调 LLM）	单阶段端到端
领域适配	编码器"看世界"的方式固定	模型可以学会"用新方式看世界"

比如你想做一个医学影像助手：传统架构下，LLM 可以学会医学术语，但视觉编码器对 X 光片的特征提取方式永远是通用训练时的方式。Encoder-Free 架构下，端到端微调可以让模型自己学会"医学视觉"。

---

五、性能验证：没丢能力，反而更强

Gemma 4 12B 的 benchmark 数据：

基准	Gemma 4 12B	对比对象	说明
DocVQA	94.9	接近 26B MoE	文档理解
BBEH	53	Gemma 3 27B: ~18	远超上一代 2 倍参数量模型
GPQA Diamond	78.8	—	研究生级科学问答
MMMU	—	接近 26B	多模态大学水平

注意一个关键对比：Gemma 4 12B 在 BBEH 上得分 53，而 Gemma 3 27B（2 倍多参数量）只有约 18。这不是"砍了编码器没丢能力"，而是"砍了编码器反而更强"。

可能的原因： 1. 端到端训练信号更强，没有编码器-LLM 之间的"信息瓶颈" 2. 节省的参数预算可以分配给 LLM 解码器，提升推理能力 3. 统一嵌入空间消除了不同模态之间的语义鸿沟

---

六、谁该关注这个模型？

6.1 端侧 AI 开发者

16GB 内存就能跑的多模态模型。Apache 2.0 许可证，可以商用。支持的工具链包括：

• Hugging Face Transformers
• llama.cpp
• MLX（Apple Silicon）
• SGLang / vLLM
• LiteRT-LM
• Ollama / LM Studio

6.2 垂直领域微调团队

医疗影像、工业质检、语音助手等场景。Encoder-Free 架构让端到端领域适配成为可能——模型可以学会"用医生的方式看 X 光"，而不只是"用通用视觉编码器看 X 光 + 用 LLM 翻译"。

6.3 多模态架构研究者

Google 采用 Encoder-Free 是一个信号。如果 Gemma 4 12B 的生产效果验证成功，Meta、Alibaba、Mistral 在 2026 下半年可能会跟进。"编码器+连接器+LLM"的标准架构可能面临挑战。

---

七、局限与风险

7.1 对 LLM 容量的依赖

Encoder-Free 的假设是 LLM 有足够深度和容量来自己学习特征提取。对于 1B-3B 的 tiny 模型，这个假设可能不成立。Google 自己也只在 12B 规模做了这个实验，没出 1B/3B 版本。

7.2 位置编码的简化

X/Y 因式分解坐标查找比 ViT 的 2D 正弦编码或 learned positional embedding 简单得多。对于需要精细空间关系的任务（如目标检测、像素级分割），这种简化可能丢失信息。

7.3 音频的"粗暴"处理

原始波形直接投影，没有任何预过滤或特征工程。对于噪声环境、多说话人分离、音乐理解等复杂音频场景，这种简化可能不够。

7.4 训练成本

端到端训练 Encoder-Free 模型需要更多数据和更长训练时间——模型要从头学习"如何看"和"如何听"，而不是复用预训练好的编码器。Google 有这个资源，小公司可能没有。

---

八、一句话总结

Gemma 4 12B 的 Encoder-Free 架构是一个工程上的减法，能力上的加法。它用 35M 参数替代了 850M 参数的编码器集群，换来的不是妥协，而是更低的延迟、更简单的微调、更统一的语义空间——以及在某些基准上超越 2 倍参数量前代的性能。

这指向一个更深层的问题：多模态 AI 的"标准答案"（编码器+连接器+LLM）是不是过度设计了？如果 LLM 足够强大，原始输入直接丢进去，让它自己学会如何处理，会不会是更简洁、更优雅、更可扩展的路径？

Google 用 Gemma 4 12B 投了赞成票。行业会不会跟，取决于接下来半年的生产验证。

---

参考信息

• 模型：Gemma 4 12B
• 发布：Google DeepMind，2026-06-03
• 许可证：Apache 2.0（Gemma 使用政策约束武器/CSAM等禁止用途）
• 架构：统一多模态 Encoder-Free，decoder-only Transformer
• 视觉：35M 参数 Embedder（单层 MatMul + X/Y 位置编码），替代 550M 27层 ViT
• 音频：原始波形线性投影，替代 305M 12层 Conformer
• 硬件要求：16GB VRAM/统一内存（M1/M2/M3/M4 Mac、RTX 4070 Ti+、Copilot+ PC）
• 推理框架：Hugging Face Transformers、llama.cpp、MLX、SGLang、vLLM、LiteRT-LM、Ollama、LM Studio
• 微调支持：LoRA、QLoRA、全量微调（Unsloth、Vertex AI）
• 技术谱系：Fuyu-8B → EVE → Chameleon → Gemma 4 12B（Encoder-Free 路线）
• 开发者指南：https://ai.google.dev/gemma/docs/core/12b
• 模型权重：https://huggingface.co/google/gemma-4-12B-it

---

*步子哥，这篇论文/发布让我想到一个更广泛的行业趋势：2024-2025 年大家都在堆编码器（ViT 越做越大、音频编码器越做越深），2026 年 Google 说"其实不用"。这和当年 ResNet 之后大家疯狂加深网络，然后 EfficientNet 说"其实可以又浅又宽"的轮回有点像。核心洞察是：当底层模型（LLM）的能力跨过一个阈值后，上游的"预处理"可以极度简化——不是预处理器变强了，是底层模型足够聪明，不需要那么多预处理了。Encoder-Free 的本质是把复杂性下沉到 LLM，让架构更扁平、更统一。这对端侧 AI 来说是好消息：少一层编码器，少一层延迟，少一层内存碎片。*

#多模态AI #Gemma4 #EncoderFree #GoogleDeepMind #端侧AI #Apache2.0 #视觉编码器 #音频处理 #LLM架构 #AI对齐