上周DeepSeek V4刚让我体验了一把本地推理的甜头，这周Google又放出来一个让我眼前一亮的模型。Gemma 4 12B，120亿参数，无编码器架构，原生支持音频输入，官方说16GB显存就能跑。
说实话我对"本地跑大模型"这件事已经没那么激动了，毕竟Llama 3.1 8B在笔记本上跑了好几个月，Qwen2.5 7B也早就用上了。但Gemma 4 12B有个点让我真的想试试——它是这个尺寸里第一个原生支持音频输入的模型。
什么叫原生支持？之前像Whisper那种方案，是音频先经过一个独立编码器转成文字，再喂给语言模型。Gemma 4 12B不一样，它直接把16kHz的原始音频信号切成40毫秒的片段，线性投影到和文本token相同的向量空间里，然后一起送进Transformer。没有中间商赚差价，延迟低，微调也方便——视觉、音频、文本共享同一套权重，一次前向传递全更新。
这篇文章不是一篇部署教程，市面上那种"一行命令跑起来"的教程已经够多了。我想重点聊聊它的音频输入能力到底怎么样，踩了哪些坑，以及它和同级别模型相比值不值得你折腾。
部署过程：Ollama拉取与三个让我卡壳的问题
我的测试机器是一台ThinkPad P16v， RTX 2000 Ada（8GB显存）+ 32GB内存。Ollama是首选，毕竟日常开发都在用这条命令搞定：
ollama pull gemma4:12b
ollama run gemma4:12b
pull了大概十分钟，模型文件8GB左右，Q4_K_M量化版。然后一跑就遇到了第一个问题。
问题一：Ollama 0.30.2加载视觉模块直接崩掉
第一次跑，返回结果是空的。看日志：
error: Failed to load CLIP model from .../blobs/sha256-7d10888...
llama-server process has terminated: exit status 1
Gemma 4 12B-it自带了一个vision projector，Ollama 0.30.2处理不了，连带着整个服务挂掉。解决方案是剥离视觉模块，只保留文本推理能力：
ollama show --modelfile hf.co/unsloth/gemma-4-12b-it-GGUF:Q4_K_M > Gemma4.Modelfile
# 删除第二个 FROM ... 行（mmproj/CLIP blob），只保留文本GGUF
ollama create gemma4-12b-text -f Gemma4.Modelfile
ollama run gemma4-12b-text
这样文本对话就正常了。
问题二：thinking模式把答案藏起来了
文本能跑了，但API返回的content字段是空的，eval_count显示生成了200多个token。翻了半天发现，Gemma 4 12B是个推理模型，默认开启thinking模式，答案全在think channel里。关掉它：
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "gemma4-12b-text",
"think": false,
"messages": [{"role": "user", "content": "用一句话解释什么是Transformer"}]
}'
加了"think": false之后，清清爽爽的答案就回来了。
问题三：Q4量化有token glitch
在Q4_K_M量化下，跑了几段中文文本，发现偶尔会出现乱码——比如"self-さattention"、代码里莫名混进日文片假名。英文prose也有类似问题。看了社区反馈，有个哥们跑生物信息学问题，Q4版把一个统计方法的含义说反了，还说得特别自信。这种"流畅的错误"其实比直接胡编更危险。
解决方案是升到Q8_0量化，或者等后续修复。Q8占用12.7GB显存，我这张8GB卡跑不了，只能切到CPU模式，大概19 tok/s，勉强能用。
音频输入：这是我真正想测的部分
前面那些都是开胃菜，Gemma 4 12B的核心卖点是音频理解能力。用vLLM起服务后，音频输入走的是OpenAI兼容的multimodal格式：
import requests
url = "http://localhost:8000/v1/chat/completions"
payload = {
"model": "gemma-4-12b-it",
"messages": [{
"role": "user",
"content": [
{"type": "text", "text": "请转录这段音频，只输出文字内容"},
{"type": "audio_url", "audio_url": {"url": "test.wav"}}
]
}],
"max_tokens": 512
}
resp = requests.post(url, json=payload)
print(resp.json()["choices"][0]["message"]["content"])
官方文档说音频最大支持30秒。我录了几段测试：
测试一：英文播客片段
一段5分钟的英文技术播客切片，模型能正确转录，语气停顿也捕捉到了，但有个问题——人名和专有名词偶尔会拼错，比如"Transformer"听成了"Trans former"。这不算严重问题，Whisper也有类似的毛病。
测试二：中文会议录音
这个才是我真正关心的场景。我的测试录音是一段15分钟的内部会议，有两个人交替发言。转录结果出来后，基础内容是对的，但有个明显的短板——中文理解的准确率明显低于英文。具体表现是：常用词没问题，但成语和网络用语识别率低，比如"YYDS"直接音译成了一串不知所云的拼音缩写。还有一个小问题是对说话人区分不太准，两个人的发言被混到了一起，没有明确标注谁说了什么。
测试三：带口音的英语
我又找了一段印度小哥的英语 interview，口音比较重。转录效果比预期好，大部分内容能听懂并正确转写，一些连读和吞音处理得也不错。这点让我挺意外。
测试四：音频+文本的多模态理解
这是真正有意思的地方。不只是转录，而是让模型同时理解音频内容和我的文字指令。比如：
用户：[一段录音] + "这段录音里提到的三个技术点，分别用一句话总结"
模型能结合音频内容和文本指令进行推理，不只是机械转录。这个能力是Gemma 4 12B真正区别于Whisper的地方——Whisper只能转文字，Gemma能做理解。
但代价也很明显。我8GB的显存跑音频任务，CPU模式要40秒，差点以为电脑死机了。官方说16GB显存能流畅运行，我是信的，但8GB确实有点勉强。
和同级别模型横向对比
光看官方宣传不够，我找了几个同级别的模型做主观对比。测试问题包括：编程题、逻辑推理、中文理解和音频转录。
Qwen2.5 7B是我日常用的，代码生成能力确实强，中文理解也挺好。缺点是没有音频能力，多模态要靠额外接Whisper。Llama 3.1 8B生态最大，但中文能力更弱一些，代码质量也一般般。
Gemma 4 12B的强项是推理能力和指令遵循。官方说它在GPQA Diamond基准上能达到78.8%，接近26B MoE的82.3%。我实际体验下来，它的思维链连贯性确实不错，对于复杂问题的拆解很有条理。音频理解是独一份的能力，虽然中文还有短板，但这个尺寸的模型能做到这个程度已经很离谱了。
我在Reddit和GitHub Issues翻了翻大家的反馈，发现遇到的情况跟我也差不多。有个哥们在4090上跑代码，模型会突然冒出一些奇怪的语法错误——多一个括号、少一个逗号这类，让人摸不着头脑。中文能力确实是弱项，小语种翻译更是灾难级别，有个哥们测了拉脱维亚语翻译，评价是"大概相当于20年前的Google Translate"。
适合什么人用，不适合什么场景
适合用Gemma 4 12B的人：
做本地AI应用开发的工程师，需要在笔记本上跑多模态任务。Gemma 4 12B的Apache 2.0许可很友好，Ollama/vLLM生态成熟，集成成本低。
对音频理解有需求但不想接Whisper+GPT这套组合的人。原生音频+文本联合推理，省一个API调用，也不用担心录音上传云端。
隐私敏感的场景，会议录音、客户电话这类内容不想上传到第三方服务器。本地跑，数据不离开设备。
不适合的场景：
中文内容生产是主力。Gemma 4 12B的中文理解有明显短板，做内容创作、写作助手这类任务，Qwen系列是更稳妥的选择。
硬件在8GB显存以下的老显卡。老老实实用4B/7B的模型，别为难自己。跑起来也是龟速，没意义。
需要高可靠性代码生成的场景。同参数规模下，Qwen2.5-Coder在HumanEval上领先太多，代码任务交给它更放心。
我的结论
折腾完Gemma 4 12B，我最大的感受是：本地多模态的门槛，真的被拉下来了。
无编码器架构把音频理解塞进了12B这个尺寸，16GB显存就能跑，Apache 2.0随便商用——这几个条件凑在一起，竞争力确实强。虽然中文不行，虽然Q4有bug，但原生音频+文本的架构让我看到了未来AI应用的一个新方向。
一句话总结：如果你需要本地音频理解，Gemma 4 12B是目前这个尺寸里唯一的选择。中文不好？那正好，我打算用它来练练我的英语听力。代码生成？那是Qwen的事，各司其职嘛。
下一步我打算用它做一个本地会议纪要小工具，期待它后续的优化。
