一张标题卡写着“Gemma 4 12B”,副标题为“无编码器的 12B,详解”,上方有三个圆角胶囊标签,分别写着“11.95B 稠密”“256K 上下文”和“文本 + 图像 + 音频”。干净的白色背景,带有柔和的蓝色和青色渐变点缀以及极简的扁平线条图标。OrcaRouter 标志合成在右下角。
Guides & Insights

Gemma 4 12B:深入解析谷歌的无编码器 12B 模型

作者

Gideon Frost

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

Gemma 4 12B是 DeepMind 的 Gemma 4 家族中的中等规模成员:一个稠密的、119.5 亿参数的开放权重模型,可读取文本、图像、音频和视频帧并输出文本,其决定性的工程决策是完全不搭载任何多模态编码器。它介于面向边缘的Gemma 4 E4B与更大、更稀疏的Gemma 4 26B A4B之间。发布说明将其任务定位为把智能体式多模态工作带到笔记本电脑上——推理、工具使用、编码以及文档或屏幕理解,这些都运行在你面前的机器上,而不是通过按流量计费的连接。它也是在我们自己的网站上承载该家族全部在线足迹的规模:有三篇对比页面是围绕它撰写的,而在这篇之前,还没有关于该模型本身的页面。

这种倒置值得先说清楚,Gemma 4正是他们走近一款模型的方式。他们往往是绕道而来,通常是因为真正的问题在于该选 Gemma 4 的哪个规模——而且他们想在花一次下载之前就弄清楚这场对比的左边到底指什么。围绕这个名字,我们测到的搜索绝大多数都是比较型的;单独搜这个光秃秃的词,量很单薄。所以这是一张参考页:12B 是什么,它的模型卡怎么讲,跑起来需要什么条件,许可证允许什么,以及现有三组对比中哪一组已经能回答你带来的那个问题。

这不是一篇发布报道,也不应被当作发布报道来读。Gemma 4 12B于 2026 年 6 月 3 日发布——距本页面发布已有 132 天——而在本文发表前的七天里,该模型没有任何变化。这个日期来自厂商自己的发布说明,此处引用它只是为了将模型置于时间线上,而非为了宣布其发布。

12B 是什么,以及它与 26B A4B 有何不同

Gemma 4 系列有五种尺寸,而且它们并不是同一条直线上的五个点。模型卡将它们列为 E2B、E4B、12B Unified、26B A4B和31B,并且它们分属两种架构:三个稠密模型和一个混合专家模型,其中 E 尺寸使用逐层嵌入,以缩小实际在设备上运行的内容。

Gemma 4 12B是一个稠密模型。模型卡显示,它共有 119.5 亿参数,分布在 48 层中,滑动窗口为 1,024 个 token,上下文长度为 256K 个 token。而Gemma 4 26B A4B则恰恰相反,是该系列中的混合专家模型:总参数量为 252 亿,但每个 token 仅激活 38 亿参数,分布在 30 层中,128 个专家中激活 8 个,外加 1 个共享专家。名称中的“A”正是关键所在——该模型承载 260 亿权重,但在每次前向传播中只为其中约 40 亿的权重付出计算成本,因此模型卡将其描述为运行速度几乎与 4B 模型一样快,同时却拥有多得多的知识。

坦率的一句话区分是这样的。26B A4B 是当你想要单位延迟下最强能力,并且有工作站或服务器可以部署它时选择的规模。12B 是当机器是笔记本电脑、内存预算为 16GB 时选择的规模。发布说明将 12B 描述为 E4B 与 26B A4B 之间的桥梁,规格表也证实了这一点。

A two-column scoreboard titled 'Gemma 4 12B — the scoreboard'. The left column, 'Gemma 4 12B', lists: total parameters 11.95B dense; active per token 11.95B (no experts); context 256K tokens; input text, image, audio; multimodal encoders none; 4-bit download about 7 GB. The right column, 'Gemma 4 26B A4B', lists: total parameters 25.2B MoE; active per token 3.8B; context 256K tokens; input text, image; multimodal encoders about 550M vision; 4-bit download larger than 12B. A footer reads 'Figures per the Gemma 4 model card, Google DeepMind; 4-bit sizes are community GGUF file sizes, not requirements.' The OrcaRouter logo is composited in the bottom-right corner.

更有趣的差异在于架构,这也是 12B 被标记为“Unified”而非仅仅是“Dense”的原因。该系列中其他所有多模态模型都会先通过专用编码器处理图像和音频,再将结果交给语言模型——模型卡在 E-sizes 上列出了约 150M 的视觉编码器和约 300M 的音频编码器,并在 31B 和 26B A4B 上都列出了约 550M 的视觉编码器。12B 两者都没有;在 12B 上,视觉和音频编码器参数那一列在两处都显示为破折号。

取代它们的东西很小。发布文章将视觉描述为一个轻量级嵌入模块——一次矩阵乘法加上位置嵌入和归一化——并将音频描述为完全移除编码器,把原始信号投影到与文本 token 相同的维度空间中。原始图像块和音频波形直接进入单个仅解码器 Transformer。其所宣称的收益是更低的多模态延迟,以及能够跨模态一次性微调整个模型,并且只需一个适配器,而不是每个编码器各一个。

这也是 12B 成为首个具备原生音频输入的中型 Gemma 的原因。在卡片上,"文本、图像、音频"是 E2B、E4B 和 12B 的模态行;而 31B 和 26B A4B 仅标注为"文本、图像"。

该规范,正如模型卡所述

本节中的所有内容均来自 ai.google.dev 上的 Gemma 4 模型卡,该模型卡涵盖整个系列,而非仅 12B。模型卡未提及之处,会予以注明,而不是填补。

A screenshot of the specification table on Google's Gemma 4 model card at ai.google.dev, showing the family's published rows — context length, modality, total parameters, sliding window and vocabulary — broken out by size, with the 12B Unified column sitting between the E4B and the 26B A4B.

• 上下文长度 —— 12B 上为 256K 个 token。模型卡明确说明了这一划分:小型模型(E2B、E4B)为 128K,中型模型(12B、26B A4B、31B)为 256K。

• 模态——文本、图像和音频输入;文本输出。该卡片将视频列为以帧序列方式处理的一项系列能力,并说明图像输入可在所有尺寸下支持可变的宽高比与分辨率。

• 总参数量 — 11.95B,稠密,48 层。该卡片未给出激活参数量,因为没有可激活的专家。

• 滑动窗口——1,024 个 token,是 E 型号所用 512 的两倍。

• 词汇表 — 26.2万,五种规模共享。

• 注意力——一种混合机制,将局部滑动窗口注意力与完整的全局注意力交错结合,且最后一层始终为全局注意力。全局层使用统一的键和值,并配合比例 RoPE,以在长上下文下控制内存占用。

• 语言——在 140 多种语言上预训练,模型卡声称开箱即支持 35 种以上语言。

有两个数字值得核对一下,因为它们看上去像是有出入,其实并非如此。模型卡上写的是 256K token;Artificial Analysis 上Gemma 4 12B的模型页面写的是 262k。这其实是同一个数字的两种写法——262,144 个 token 就是 256K——而模型卡上就在旁边的那个 262K 词表数字,才是让这对数字乍看之下显得自相矛盾的原因。

在基准测试中,该模型卡为指令微调检查点发布了一张系列表格,而这些是厂商报告的数值,并非独立数据。对于Gemma 4 12B,模型卡列出 MMLU Pro 77.2%、GPQA Diamond 78.8%、AIME 2026 无工具 77.5%、LiveCodeBench v6 72.0%、Codeforces ELO 1659、MMMU Pro 69.1%,以及 MRCR v2 在 128K、八针条件下 43.4%。同一张表还将Gemma 4 26B A4B列为 MMLU Pro 82.6%、AIME 88.3%、LiveCodeBench 77.1% 和 MRCR 44.1%——在大多数行上领先,这正是你对更大模型的预期,而在少数几项上足够接近,说明规模差距并非全部原因。

来自 Artificial Analysis 的独立解读只有一条核心结论:智能指数得分为 14,在其对比类别的 141 个模型中位列第 20,实测输出速度为每秒 110.9 个 token,混合成本为每百万输入 token 0.10 美元、每百万输出 token 0.30 美元。这些成本数字是提供开放权重的第三方平台的中位数,而非厂商标价——这一点值得精确说明,因为厂商在模型卡上根本没有为 12B 公布任何按 token 计费的价格。

运行它:它实际需要什么

发布帖直接给出了核心要求:12B 模型“小到只需 16GB 的显存或统一内存就能在本地运行”。随之公布的各项量化规格让这一点变得具体可见。

An infographic titled 'Gemma 4 12B — what fits where' showing four cards in a row: 23.9 GB for BF16 full precision, needing a 24GB card or more; 7.0 GB for Google's QAT GGUF weights plus a 0.18 GB projector; 7.1 GB for a community GGUF Q4_K_M build, described as the 16GB laptop version; and 12.7 GB for a community GGUF Q8_0 or MLX 8-bit build. A centered line below reads 'Google: small enough to run locally with just 16GB of VRAM or unified memory.' A footer reads 'Sizes are published file sizes, not memory requirements; the local-run line is Google's own claim.' The OrcaRouter logo is composited in the bottom-right corner.

• 全精度——Hugging Face 上经过指令微调的检查点是一个单个 23.92 GB 的 safetensors 文件。在 bfloat16 下,这只是原始权重占用,还未计入任何 KV 缓存,因此 16GB 的机器无法容纳它,而 24GB 的显卡也很吃紧。

• 厂商自己的量化构建——因为 12B 出厂时采用的是量化感知训练,而不只是事后量化器。厂商发布了一个 QAT GGUF,权重约 6.98 GB,外加一个 0.18 GB 的多模态投影文件,以及一个 10.26 GB 的 QAT compressed-tensors 构建(w4a16)。此外还发布了一个未量化的 QAT 检查点,专门作为重新量化前进行微调的基座。

• 社区 GGUF —— 被广泛镜像的 Unsloth 构建版本,从最激进的 2-bit 约 4.2 GB 起步,到 IQ4_XS 的 6.38 GB、Q4_K_M 的 7.12 GB、Q5_K_M 的 8.41 GB,以及 Q8_0 的 12.67 GB。LM Studio 镜像发布的 Q4_K_M 为 7.38 GB,Q6_K 为 9.79 GB,Q8_0 为 12.67 GB,每个都附带相同的 0.18 GB 投影文件。

• MLX — 面向 Apple 芯片的 8 比特量化版本由三个文件组成,总大小约为 12.7 GB;而某个代码微调模型的 4 比特社区版则约为 6.7 GB。

综合起来看,这就是"能否装得下"这个问题的实际答案。Gemma 4 12B的 4 位量化版本约为 7 GB,正是能让 16GB 笔记本跑起来的那一版,与厂商的说法完全一致。如果你想让模型以未量化形式运行,目标就是一块 24GB 或更大的显卡;而如果你想要完整的 256K 上下文,除了权重占用之外,还需要为缓存留出额外余量。

有两个信息,来源并未提供,本页也不会凭空编造。厂商没有发布本地推理的吞吐量数据——Artificial Analysis 给出的 110.9 个 token/秒是在第三方基础设施上托管测量的结果,并非笔记本电脑上的数值,两者不能混为一谈。而且,也没有按量化级别发布的最低内存表;上面列出的大小是文件大小,那是下限,而非要求。

模型卡真正记录的是周边工具链,而非某个被钦定的运行时:用于推理和微调的 Hugging Face Transformers、llama.cpp、MLX、SGLang、vLLM 和 Unsloth,以 LM Studio、Ollama 和 LiteRT-LM 作为打包好的本地部署路径,权重则托管在 Hugging Face 和 Kaggle 上。12B 还附带多 token 预测草稿模型,以独立的 assistant 检查点形式发布——这是一次小规模的额外下载,以额外内存换取更低延迟。

有一个路由事实需要直白说明,因为这类信息在对比页面上往往含糊不清:Gemma 4 12B并不是 OrcaRouter 所提供的模型,无论以何种写法均不提供——无论是直接使用该名称、带日期的变体,还是量化版本。我们实际路由的 Gemma 4 规模是 26B A4B 和 31B。因此,如果你想调用这一模型,自行托管权重或使用提供这些权重的第三方托管服务才是可行之道;如果你不想自己运行,诚实的下一步是检查该系列中不同的规模是否能满足你的需求。

许可证,专门针对这个尺寸的

Gemma 4 模型卡将许可证标注为 Apache 2.0,并链接到 Gemma 4 许可证页面,该页面提供的是 Apache 2.0 文本——即标准的 Apache 许可证,没有使用上限,没有月活跃用户数门槛,也没有单独的商用层级。用于 12B 指令微调检查点的 Hugging Face 仓库在其元数据中带有相同的声明,并指向同一个许可证 URL。因此,对于这一规模,许可证问题的答案很短:在 Apache 2.0 条款下,无论是商业用途还是其他用途,都可以使用、修改和再分发它。

与它并存的还有两份配套文档,值得了解,但不要与许可证混淆。厂商发布了 Gemma 使用条款页面和 Gemma 禁止使用政策。禁止使用政策是一份行为性文件,列出了不得使用这些模型生成哪些类别的输出。它是一项政策,而不是对权重施加的许可限制——权重本身采用 Apache 2.0,这正是该模型能够出现社区衍生版本的根本原因。如果你正在再分发Gemma 4 12B或其微调版本,那么许可证管辖你的再分发行为;政策则管辖可接受的使用方式。

这一区分回答了社区衍生生态所提出的问题,而无需刻画任何人的行为。由于权重是在宽松许可下开放的,第三方可以并且确实会发布 12B 的微调版和量化版——去拒答(abliterated)变体、领域微调、替代量化方案。该许可所允许的是这些衍生品的再分发;该许可也是它们存在的原因。

本页面背后的三项对比

这个路径主干下的三个线上页面都是对阵页,而每一个都已经回答了不同的问题。本页并不对其中任何一个作出裁断——它就是它们所描述的那个东西。

• Gemma 4 12B vs Gemini 3.5 Flash-Lite——当两个选项都来自同一家厂商、而比较的维度变为付费方式时,它给出了答案:一个是可依据 Apache 2.0 许可下载的模型,另一个是托管 API 中按量计费的最低档。

• Gemma 4 12B 对比 GLM 5.2——厘清这对悬殊至极的组合:一边是可直接在笔记本电脑上运行、无需编码器的 12B 模型,另一边是拥有 7440 亿参数、专为长周期智能体编程打造的开源权重混合专家模型,而价格要高出许多倍。

• Gemma 4 12B 对比 Qwen3.8 Max——直接了结“端侧还是租用”之争:一台摆在你桌上的机器,对阵同一实验室以按 token 计费方式提供的旗舰模型。

如果你真正想要的其实是 Gemma 4 的其他某个尺寸,而不是再来一次 12B 对比,那么能一次性覆盖全部五款的页面就是该系列中心页,E2B、E4B、26B A4B 和 31B 都在这里一并介绍。如果你已经确定 12B 不是合适的尺寸,那么最常与它相比较的模型——GLM 5.2、Qwen3.8 Max 和 Gemini 3.5 Flash-Lite——都可以通过 OrcaRouter 用一个密钥访问,在提供商自身标价基础上加价 0%,因此厂商降价一经宣布,这里当天就会同步生效。

什么尚未确定

有两处缺口值得直说,而不是粉饰过去。上方的基准测试表是厂商报告的——来自厂商自己的资料卡和评估设置——尽管 Artificial Analysis 后来独立给该模型打出了 Intelligence Index 14 分,但针对各项基准测试的独立复现并不广泛,所以请把这些行级数字当作厂商说法。而且 12B 没有公开的按量化划分的内存表,这意味着“16GB 就够了”是一句有文件大小作为支撑的厂商说法,而不是你可以照搬的实测配置。

这款模型本身很容易定位:一个采用 Apache 2.0 许可、无编码器、120 亿参数的多模态模型,日期为 2026 年 6 月 3 日,可在笔记本电脑上以 4 位精度运行,并且是 Gemma 4 中最小、原生支持音频的规格。它并不是一款有第一方托管费率的模型,因此围绕它的实际决策首先是硬件决策,其次才是价格决策。

如果你是从某个对比页面来到这里的,而那个对比并不是你所需要的,那么下一页就是与你的问题相匹配的对比;如果那也不行,还有范围更广的 Gemma 4 系列——12B 只是五个尺寸中的一个,而你真正想要的尺寸,可能是你今天就能调用的 26B A4B,也可能是处于该系列规格顶端的、你可以运行的 31B。