Gemma 4 12B：扔掉编码器，用 16GB 显存跑多模态

Google 在 6 月 3 日放出了 Gemma 4 12B——一个把视觉和音频直接塞进语言模型本体、不再依赖外部编码器的统一多模态模型。更关键的是：16GB 显存或统一内存就能本地跑，高端笔记本直接部署，不需要云端算力兜底。

这件事值得认真看，不只是因为"又出了一个新模型"，而是因为它代表了一条正在成型的架构路线：把多模态能力内化到语言模型本身，而不是外挂一个视觉编码器再做对齐。

编码器去哪了？

传统多模态模型的套路是"双塔+桥"：一个视觉编码器（比如 ViT）提取图像特征，一个语言模型处理文本，中间用投影层或交叉注意力把两边对齐。这套做法有效，但代价不小——编码器本身就要吃掉几 GB 显存，对齐训练也需要大量数据和时间。

Gemma 4 12B 走了另一条路：直接把图像和音频的原始信号（或轻量预处理后的表示）喂进语言模型的 token 流，让 Transformer 自己学会"看"和"听"。换句话说，模型内部不再有"视觉专家"和"语言专家"的分界，所有模态共享同一套注意力权重和参数空间。

这带来的直接好处：

• 参数更集中——没有编码器占位，12B 参数全部服务于统一推理，同等参数下能力密度更高。
• 推理路径更短——图像信号不需要先过编码器再过投影层再进 LLM，减少了一次信息压缩和转换。
• 部署更简单——一个模型文件搞定多模态，不用分别加载编码器和语言模型。

当然，代价也很明显：统一架构的训练难度更高，早期阶段模态间可能互相干扰，需要更精细的训练策略来平衡。源材料没有披露具体训练细节，但可以合理推测 Google 在数据配比和训练节奏上做了相当多的工程调优。

16GB 显存意味着什么

"仅需 16GB 显存"这个数字，把 Gemma 4 12B 推到了一个很实际的落地点。来看一下当前消费级硬件的分布：

注意"刚好"和"舒适"的区别——16GB 是最低门槛，实际运行时操作系统和其他进程也要占内存，建议留出 2-3GB 余量。如果用 Mac 的统一内存架构，情况稍好，因为 CPU 和 GPU 共享同一块内存池，不存在"VRAM 独占"的问题。

本地跑起来：三种路径

下面给出三个可以直接复制运行的部署方案，从最简单到最灵活。

方案一：Ollama 一键拉起（最省事）

Ollama 对 Gemma 系列的支持一直很及时，Gemma 4 发布后大概率已入库。运行方式：

# 拉取模型（首次会下载，约 8-10GB）
ollama pull gemma4:12b

# 直接对话测试
ollama run gemma4:12b

# 多模态推理：传入图片
ollama run gemma4:12b --image ./test_photo.jpg "描述这张图片中的主要物体和场景"

注意：截至本文写作时，Ollama 对 Gemma 4 的多模态支持可能仍在更新中。如果 --image 参数暂不可用，可关注 Ollama GitHub 的 release 日志，通常一周内会跟进。

Ollama 的优势是零配置，劣势是推理参数调优空间小。如果你只需要快速验证模型能力，这够了。

方案二：Hugging Face Transformers + quantization（灵活可控）

用 4-bit 量化把模型塞进 16GB 显存，同时保留大部分精度：

import torch
from transformers import AutoModelForCausalLM, AutoProcessor, BitsAndBytesConfig

# 4-bit 量化配置——这是 16GB 显存能跑的关键
quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,  # 二次量化再省一点显存
)

model_id = "google/gemma-4-12b"  # 实际 repo 名以 HuggingFace 发布为准

processor = AutoProcessor.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    quantization_config=quant_config,
    device_map="auto",  # 自动分配 GPU/CPU
    torch_dtype=torch.bfloat16,
)

# 多模态推理示例
from PIL import Image

image = Image.open("./test_photo.jpg")
inputs = processor(
    text="这张图片里有什么？请详细描述。",
    images=image,
    return_tensors="pt",
).to(model.device)

output = model.generate(
    **inputs,
    max_new_tokens=512,
    temperature=0.7,
    do_sample=True,
)
print(processor.decode(output[0], skip_special_tokens=True))

运行前需要修改：model_id 请替换为 Hugging Face 上实际的仓库路径。Gemma 模型通常需要先在 Google's model consent page 同意使用条款才能下载。安装依赖：pip install transformers accelerate bitsandbytes pillow.

4-bit 量化后模型占用约 4-5GB 显存，加上 KV cache 和中间激活，16GB 卡可以跑 2048-4096 token 的上下文。如果需要更长上下文，考虑用 flash_attention_2 进一步压缩：

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    quantization_config=quant_config,
    device_map="auto",
    attn_implementation="flash_attention_2",  # 需要 flash-attn 包
)

方案三：vLLM 高吞吐服务（生产部署）

如果要把 Gemma 4 12B 作为 API 服务跑在本地服务器上，vLLM 是更合适的选择——它支持 continuous batching 和 PagedAttention，吞吐量远高于原生 Transformers：

# 安装 vLLM（需要 CUDA 12.1+）
pip install vllm

# 启动 OpenAI 兼容的 API 服务
# --quantization awq 或 gptq 可选，看 HuggingFace 上是否有对应量化版
vllm serve google/gemma-4-12b \
  --tensor-parallel-size 1 \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.90 \
  --quantization awq \
  --port 8000

启动后用任何 OpenAI SDK 调用：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="empty")

response = client.chat.completions.create(
    model="google/gemma-4-12b",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "描述这张图片"},
                {"type": "image_url", "image_url": {"url": "file:///./test_photo.jpg"}},
            ],
        }
    ],
    max_tokens=512,
)
print(response.choices[0].message.content)

注意：vLLM 对 Gemma 4 多模态的支持进度请查看 vLLM 官方文档 的 supported models 列表。新模型通常在发布后 1-2 周内被纳入。

统一架构的取舍

Gemma 4 12B 的"无编码器"设计不是银弹，它是一条有明确代价的路线：

优势面： - 部署复杂度大幅降低——一个权重文件，一套推理代码，不需要处理编码器-LLM 的版本匹配和接口对齐。 - 模态融合更自然——图像和文本在同一个注意力空间里交互，理论上更容易捕捉跨模态的细微关联（比如图文幽默、视觉隐喻）。 - 扩展新模态的架构成本更低——加音频不需要再训练一个音频编码器然后做三方对齐，只需要在训练数据里加入音频信号。

风险面： - 训练难度陡增——没有编码器做特征预提取，模型要从更原始的信号中学习，对数据量和训练稳定性要求更高。 - 模态干扰——语言能力和视觉能力共享参数，极端情况下可能出现"看图能力提升但文本推理下降"的跷跷板效应。 - 生态兼容性——大量现有工具链（CLIP 检索、视觉特征提取管线）是基于编码器架构设计的，统一模型需要新的适配方案。

落地检查清单

如果你在考虑把 Gemma 4 12B 用到实际项目中，跑一遍这个清单：

1. 显存审计——目标机器的 GPU/Mac 实际可用内存是多少？扣掉系统占用后是否 ≥14GB（留 2GB 余量）？
2. 延迟预期——12B 模型在消费级 GPU 上单次推理约 2-5 秒（视量化程度和硬件而定），能否接受？
3. 模态需求——你只需要视觉，还是视觉+音频都要？如果只用视觉，更小的纯视觉模型可能更高效。
4. 精度容忍度——4-bit 量化在大多数场景下够用，但医学影像、精密 OCR 等场景建议至少 8-bit。
5. 工具链适配——现有项目是否依赖 CLIP/SigLIP 等编码器做特征检索？切换到统一模型后这部分需要重写。
6. 合规检查——Gemma 系列有使用条款限制（特别是商业用途），部署前确认你的场景在许可范围内。

Gemma 4 12B 的意义不在于"12B 参数又破了个纪录"，而在于它把统一多模态架构从实验室概念推到了"16GB 显存就能跑"的工程现实。这条路线是否会在更大参数量上持续有效，还需要后续 27B 等版本验证。但就当前而言，它给了开发者一个低门槛的入口去亲手实验：当一个模型不再区分"看"和"说"，推理会变成什么样。