Gemma 4 12B：Google 把多模态编码器拿掉了

Google DeepMind 这次押的不是「再堆一个更大的开源模型」，而是把多模态模型里最常见的前置编码器拿掉。6 月 3 日发布的 Gemma 4 12B，被定位为一款能在笔记本上跑的 12B 级多模态模型：支持视觉和原生音频输入，目标硬件是 16GB 显存或统一内存的消费级设备，许可证是 Apache 2.0。1

这件事值得看，不是因为 12B 这个参数规模本身稀奇，而是因为 Google 在 Gemma 4 系列里补上了一个位置：比面向边缘设备的 E4B 更强，又比 26B MoE 更容易塞进本地机器。官方说它的标准 benchmark 表现接近 26B 模型，同时把总内存占用压到后者一半以下。1 如果这个取舍在真实任务里站得住，很多本来需要云端模型的「看图、听音频、写代码、调工具」流程，就能搬回开发者自己的电脑。

传统多模态模型通常先让图像编码器、音频编码器把原始信号变成向量，再交给语言模型理解。这个做法稳定，但代价也明显：每一种模态都有一套前处理网络，推理时多一段延迟，部署时多一块显存或内存。Gemma 4 12B 的发布博客把问题说得很直接：分离式编码器会增加延迟，也会拉高内存占用。1

Gemma 4 12B 的答案是「统一」。视觉和音频不再先交给重型编码器，而是尽量投到和文本 token 相同的空间里，让同一个 LLM 主干继续处理。Google Developers Blog 的开发者指南把它描述为一个 dense multimodal model，并说明它使用了和 Gemma 4 31B Dense 相同的高级 decoder 结构。2

这里的「encoder-free」不能理解成完全没有预处理。它更准确的含义是：不再保留一套独立的大型视觉或音频编码器。信号仍然要被切块、投影、加上位置信息，只是这一步变得很薄，后面的理解任务交给同一个 Transformer 主干。

视觉路径的变化最容易看出来。开发者指南称，Gemma 4 12B 用一个 3500 万参数的 vision embedder 替换了其他中型 Gemma 4 模型里的 27 层视觉 Transformer；原始 48×48 像素 patch 通过一次矩阵乘法投到 LLM 隐藏维度，再用按 X/Y 拆分的坐标查表补上空间位置信息。2

这意味着图像理解的重活不再主要由一个外置视觉塔完成。模型主干要直接学习「这些视觉 token 和文本 token 如何一起组成上下文」。好处是结构更短，调优链路也更直接；风险是多模态能力更依赖主干训练本身，不能简单假设换掉编码器后所有视觉任务都自动更强。

音频路径更激进。Gemma 4 E2B 和 E4B 原本使用 12 层 conformer 音频编码器；Gemma 4 12B 则把 16 kHz 原始音频切成 40 毫秒一帧，每帧 640 个浮点数，再线性投影到 LLM 输入空间。2 这让它成为 Gemma 家族第一款能原生接收音频输入的中等规模模型。1

对开发者来说，音频不只是「语音转文字」。如果模型能把声音、图像和文本放在同一个上下文里处理，本地应用就可以直接做会议片段理解、视频问答、语音编辑、离线助理等任务。Google 在开发者指南里展示了一个 5 分钟视频片段的例子：取 00:15:32 到 00:20:45 之间的内容，以 1 FPS 抽取 313 帧，再把视频音频和问题一起交给模型分析。2 这不是完整评测，但能说明 Google 希望它进入的使用场景：不是单轮聊天，而是带多模态上下文的本地 Agent。

统一架构的一个隐含收益在训练和微调阶段。开发者指南明确提到，因为视觉、音频和文本共享同一组权重，做 LoRA 或全量微调时，不需要再分别协同调整冻结的外部编码器。2 这对小团队很实际：调一个模型已经够麻烦，如果还要处理视觉塔、音频塔、投影层和 LLM 主干之间的接口，工程复杂度会很快上去。

Gemma 4 12B 还配了 Multi-Token Prediction drafters，用来降低生成延迟。1 MTP 的直觉是先草拟多个后续 token，再由主模型确认或修正。对本地 Agent 来说，这类延迟优化比跑分更贴近体验：工具调用前后都要生成文本，慢半秒、慢两秒，用户感受完全不同。

生态支持也来得很快。官方列出的入口包括 LM Studio、Ollama、Google AI Edge Gallery、Google AI Edge Eloquent、LiteRT-LM CLI，权重可从 Hugging Face 和 Kaggle 下载；推理和部署侧则支持 Hugging Face Transformers、llama.cpp、MLX、SGLang、vLLM、Unsloth，以及 Google Cloud、Cloud Run 和 GKE 等路径。1 这说明 Google 没把它只当研究展示，而是在往本地开发工作流里塞。

第一，官方博客说它的 benchmark 表现接近 26B MoE，但这篇发布文没有给出完整表格和逐项任务明细。1 如果你关心的是 OCR、图表理解、长视频问答、ASR、代码修改或工具调用成功率，仍然要用自己的任务集测。单看「接近更大模型」这句话，不足以判断它能不能替掉现有方案。

第二，16GB 显存或统一内存是一个部署门槛，不等于所有多模态任务都能流畅运行。视频会把帧数、分辨率、音频长度一起带进上下文，token 预算很快被吃掉。Gemma 4 12B 的结构减少了编码器开销，但没有取消多模态输入本身的计算成本。

第三，统一主干让微调更简单，也会让不同模态的能力更绑在一起。对一些垂直任务来说，独立编码器并不一定是坏事：成熟的视觉或语音前端可能在特定场景更稳。Gemma 4 12B 的路线更适合想要一个统一本地 Agent 底座的团队，而不是所有单点任务的默认最优解。

如果你正在做三类产品，Gemma 4 12B 值得尽快拉下来测试。

如果你的目标是最高质量的云端推理，或需要稳定处理长视频、大规模批量音频，Gemma 4 12B 可能只是候选项之一。它的看点在「能否把足够好的多模态 Agent 放进本地电脑」，不是替代所有大模型。

最务实的评估方式也很简单：拿 20 到 50 个真实任务测一遍，包含图片、音频、视频片段、代码和工具调用。记录四件事：能不能跑在目标机器上、首 token 和总耗时、失败样式、微调后是否真的改善。如果这四项过关，Gemma 4 12B 的统一架构才从漂亮设计变成可用工具。