Gemma 是 Google DeepMind 发布的开放模型家族。在官方产品页上，这条产品线的标题是「Gemma / 我们能力最强的开放模型」，并被放在名为 Open models（开放模型）的导航栏目下，与 Gemini、Veo、Imagen 这些只能通过 API 调用的闭源产品线刻意分开。这个位置本身就是关于这个条目最重要的事实：你拿到的不是一个账号和用量计费表，而是可以自己下载、自己托管、自己运行的模型权重。
有必要把名字说清楚，因为绝大多数混淆都从这里开始。Google DeepMind 是一个研究机构；Gemini 是它的旗舰闭源模型家族，通过 Google 自家产品和 API 提供服务；而 Gemma 是那个开放的兄弟产品——按官网 Gemma 4 页面的说法，它是「源自 Gemini 3 研究与技术、以最大化每单位参数智能水平为目标的最智能开放模型」。这三个名字经常被导航站和新闻聚合器混为一谈，但它们指的是完全不同的东西：一个组织、一个托管模型、一个可下载模型。本页说的是第三种。
Gemma 的设计意图直接来自这种开放性。Google 明确的目标是可移植性而非跑分榜第一：「我们最先进的开放模型帮助开发者创建可以在用户需要的任何地方运行的 AI 应用——从云服务器到笔记本电脑，甚至手机。」这个家族的其他一切特征——异常宽的参数档位跨度、混合专家变体、小模型里的逐层嵌入技巧——都是这句话的下游产物。Gemma 被设计成同一个模型家族既能部署在 Jetson Nano 上，也能部署在一整机架的加速卡上，中间不需要更换供应商或重写应用。
开放性还有第二个实际后果。因为权重是分发的而不是托管服务的，这里没有注册流程、没有席位数、也没有 Google 按 token 开给你的账单。取而代之的是一份许可证、一张硬件账单，以及一份完全由你承担的运维负担。评估 Gemma 的工作，大半就是搞清楚这三样各自落在哪里。
Google 同时把 Gemma 定位为负责任部署的工具，而不只是一个原始研究产物。Open models 栏目下的一句话定位是「负责任地大规模构建 AI 应用」，家族中也确实附带了专门的安全分类器变体。但这个定位能否成立，很大程度取决于你在模型外围搭建了什么——官方文档对这一点说得非常直白，本文的「限制」一节会再回到这里。
采用 Gemma 最难的部分不是安装，而是在阶梯上挑对那一级。各档位之间并不可互换，而决定性因素通常是你手上已有的硬件，而不是某张跑分表。
边缘档（E2B、E4B）。 Google 明确把这一档定位给受限设备：「支持实时边缘处理的音频与视觉能力。它们可以在手机、Raspberry Pi 和 Jetson Nano 这类边缘设备上完全离线运行，延迟接近于零。」离线运行是其核心属性。如果你的硬性要求是推理必须在无网络环境下工作——车内、诊所、车间、乡村教室——这一档就是你需要考虑 Gemma 的根本原因。代价是更短的上下文窗口，以及在困难推理与长文档检索上明显更弱的表现。
工作站档（12B、26B A4B、31B）。 这一档瞄准的是消费级显卡而非数据中心加速卡。Google 的定位是它们提供「面向 IDE、编码助手与智能体工作流的进阶推理能力。这些模型针对消费级 GPU 优化——让学生、研究者和开发者能把工作站变成本地优先的 AI 服务器。」26B A4B 是其中值得注意的中间选项：总参数 25.2B，但推理时激活约 3.8B，因此速度上更接近小模型，同时保留更多容量。31B 稠密模型以 30.7B 参数配 256K 窗口，是这个家族的上限。
上一代仍然重要。 Gemma 3 并没有消失。它仍以 270M、1B、4B、12B 与 27B 五个档位提供，具备 128K token 窗口，而 Google 自己的描述——「Gemma 3 的 128K token 上下文窗口让你的应用能够处理和理解海量信息，实现更复杂的 AI 功能」——描述的依然是一个可用的模型。尤其是 270M 这一档，Gemma 4 中并没有对应型号，因此在极度受限的部署场景下，上一代有时是唯一选项。关键在于两代之间的许可证并不相同，这是下一节的内容。
一条实用的选型经验法则：从你的部署目标出发，而不是从跑分榜出发。如果必须在手持设备上离线运行，你就在边缘档，并且应该尽早用你真实的任务验证质量。如果你有一张现代消费级 GPU，想要本地的编码或智能体助手，从 12B 起步，只有当质量确实不够时再往上走。如果需要语音输入，就把范围限制在 E2B、E4B 或 12B。如果你追求最高质量且硬件足够，31B 稠密模型是这个家族的天花板。
这一节值得读两遍，因为关于 Gemma 流传最广的那句话——「Gemma 是 Apache 2.0 许可的」——只对当前这一代成立。
Gemma 4 确实转向了真正标准的开源许可证。Google 开源官方博客说得很直白：「Gemma 4 模型是 Gemmaverse 中首批以 OSI 认证的 Apache 2.0 许可证发布的模型。」官方模型卡以机器可读的形式确认了这一点，front matter 字段直接写着 license: apache-2.0。因此对 Gemma 4 而言，你面对的是一份 OSI 认证的宽松许可证，具备开发者所预期的再分发与商用属性。
早期版本则是另一回事。Hugging Face 上 Google 官方组织的仓库元数据清楚地显示了这一分界：Gemma 4 系列仓库带 apache-2.0 标签，而 gemma-2、gemma-3n、gemma-7b 等仓库仍然标注 Google 自定义的 gemma 许可证。第三方的版本谱系梳理记录了同一次转变，指出 Google 是在发布 Gemma 4 时采用「自由开源的 Apache 2.0 许可证」，而更早的几代是以 source-available 的 Gemma 使用条款分发的。
实际后果非常具体。如果你的合规流程把「Gemma」作为一个 Apache 2.0 依赖批准通过，而你的工程师随后拉取了 Gemma 3 或 Gemma 2 的检查点——这完全合理，因为那些型号仍在维护、有时甚至更合适——那么真正约束你部署的许可证，并不是你流程批准的那一份。每一次都去查你实际下载的那个具体仓库的许可证字段，不要依赖家族层面的笼统说法，包括本文这一句。
在采用规模方面，Google 报告称「自首次发布以来，社区已下载 Gemma 模型超过 4 亿次，并构建了超过 10 万个衍生模型，社区称之为 Gemmaverse」。这些是厂商自报数字，未经独立审计；它们可以作为「生态没有荒废」的信号，但不应被解读为质量指标。
分发渠道是刻意铺开在开发者已经在用的工具链上的，而不是收拢到某个 Google 自有平台。官方页面列出的平台与集成覆盖 Kaggle、Hugging Face、Keras、Ollama、PyTorch、Gemma.cpp、JAX、Google AI Edge、Google Cloud、Android、LM Studio 与 Unsloth。
具体到权重，Gemma 4 页面把下载渠道与训练部署渠道分开列出，权重下载指向 Hugging Face、Ollama、Kaggle、LM Studio 与 Docker。实际上这意味着最快的路径完全取决于你已有的技术栈，而不取决于任何 Gemma 专有工具：
支持体系是社区与文档形态的，而不是合同形态的。官方页面指向「用于构建 Gemma 应用的官方文档、快速上手与指南」，并把提问引导至开发者论坛。下载一个开放模型不会附带 SLA、工单队列或客户经理——这个取舍在原理上显而易见，但在生产环境中偶尔仍会让人意外。
Google 公布了 Gemma 4 与上一代的对照基准表，在重推理任务上的代际跃升幅度很大。在不使用工具的 AIME 2026 数学测试上，31B 模型报告为 89.2%，而 Gemma 3 27B 为 20.8%。Gemma 4 页面公布的其他数字还覆盖竞技场评分、竞赛编程与研究生水平问答。
对该表中的每一个数字都适用两条警告。第一，这些是厂商自报结果，由对结果有利益关系的一方产出；它们是合理的初始假设，而不是独立结论。第二，总览均值会掩盖在部署中最要命的、随型号变化的性能悬崖。长上下文检索是最清楚的例子：在 MRCR v2 八针 128K 检索指标上，模型卡给出最大型号 66.4%，而每个更小的档位都依次显著下滑。一个宣称支持长窗口的模型，未必能可靠地使用那个窗口，而这个指标上从阶梯顶端到底端的差距，远大于通用知识基准上的差距。
独立分析提出了一个相关的结构性质疑：对 Gemma 4 技术报告的分析指出，它「把性能提升归功于数据构成，然后用两句话描述了自己的训练数据」。由于语料构成没有详细披露，外部方无法独立评估基准污染或核实领域覆盖。这并不让已公布的数字失效，但它意味着唯一能为你的用例完全定论的基准，是你自己在自有留出数据上跑出来的那一个。
Gemma 适合那些看重部署控制权胜过看重便利性的开发者、研究者与技术团队。如果你能自如地准备硬件、选定服务栈并承担运维面，这个家族给了你来自同一家供应商、工具链一致、档位跨度异常宽的一条模型阶梯。
它适合那些有托管 API 无法满足的硬性约束的组织——离线运行、数据驻留、代码保密，或者在规模化后使按 token 计价难以为继的单位经济性。在这些情况下，运维负担不是缺点，而是你为一个别无他法的需求所付的代价。
它适合打算改造模型的人。微调、量化、蒸馏，或者把模型嵌入设备镜像，都需要权重。如果你的计划涉及上述任何一个动词，开放模型就不是若干选项之一，而是唯一符合条件的类别。
它不适合只想打开浏览器标签页就拿到结果的非技术用户。这里没有面向消费者的产品。除了 AI Studio 试用之外，使用 Gemma 意味着工程工作。任何需求是「和 AI 助手聊天」的人，都更适合托管产品，很可能就是 Gemini，而本条目对他们只是一次不必要的绕路。
它同样不太适合需要合同级支持保障的团队。文档和开发者论坛就是全部支持模式。如果你的采购流程要求供应商提供 SLA 和升级路径，下载一个开放模型并不提供这些，无论其背后的厂商有多大。
Google 自己的文档对模型边界说得异常直接，而这些自述限制比大多数第三方批评更有用，因为它们是可归属的。
它不是知识库。 模型卡声明模型「基于从训练数据集中学到的信息生成回答，但它们不是知识库。它们可能生成不正确或过时的事实性陈述。」把事实性输出当作需要核实的对象，而不是检索结果。
训练数据有截止日期。 记录在案的预训练截止日期是 2025 年 1 月，覆盖网页文档、代码、数学、图像与音频。该日期之后的一切都在模型知识之外，因此时效敏感的应用无论选哪个档位都需要外接检索。
开放式任务比明确定义的任务更难。 按模型卡的说法，模型「在能够用清晰提示与指令框定的任务上表现良好。开放式或高度复杂的任务可能构成挑战。」提示词结构在这里确实起作用。
能力在阶梯上并不均匀。 这一点值得强调，因为它是实践中最常见的失望来源。音频输入只存在于 E2B、E4B 与 12B。长上下文检索在较小模型上急剧衰减。在 31B 上验证过的能力，绝不应假定能迁移到 E2B。
专业建议不在适用范围内。 Google 自己的页脚提示很明确：「不要依赖大语言模型获取医疗、法律、财务或其他专业建议。任何涉及这些主题的内容仅供参考，不能替代合格专业人士的建议。」MedGemma 的存在并不改变这一点；一个领域微调模型仍然不是临床医生。
训练数据透明度有限。 如上所述，独立分析批评训练数据描述过于简略。你无法完整审计进入模型的是什么。
你继承了运维负担。 没有托管端点意味着可用性、扩缩容、安全补丁、GPU 容量规划与成本都归你。对小团队而言，这一点在做决定的当下经常被低估。
开放模型的隐私格局与托管服务在结构上不同，而这种不同是双向的。
好的一面是，自托管意味着推理数据完全不必离开你的基础设施。不需要就厂商侧的提示词日志留存去谈判，因为根本不存在厂商侧的推理。对于保密工作负载，这是整个类别最有力的论据。
在训练侧，Google 报告了对预训练语料的过滤工作：「为使 Gemma 预训练模型安全可靠，我们使用自动化技术从训练集中过滤掉特定个人信息和其他敏感数据」，并在多个阶段实施了 CSAM 过滤。这是厂商关于流程的陈述，不是独立审计，应当据此解读。
对任何部署 Gemma 的人来说，最关键的一点是 Google 明确把下游安全责任分配给了你。模型卡把隐私侵犯列为已识别风险，并声明「鼓励开发者采用隐私保护技术遵守隐私法规」。在内容安全上同样直接：「鼓励开发者保持谨慎，并根据其特定产品政策与应用用例实施适当的内容安全防护措施。」
这种责任分配不是形式主义。在托管 API 中，无论你想不想要，供应商的审核层都横在你的用户和原始模型之间。当你下载权重时，那一层不会跟着一起下载。护栏、滥用监控、日志策略、年龄限制与合规都变成了你要自己搭建的东西。ShieldGemma 2 的存在能帮上其中一部分，但把它接进去是你的工作。
在基础设施层面，Google 声明「Gemma 4 模型与我们的闭源模型经过同样严格的基础设施安全流程」，把这个家族定位为面向企业与主权机构的可信基座。该声明涉及的是模型如何被生产与发布，而不是你随后如何运营它们。
Gemma 诚实的对比集合是其他开放权重家族，而不是托管助手，因为「是否自托管」这个决定在前，「托管哪个模型」在后。
与 Gemini 对比，这其实是一个关于部署模式而非质量的问题。Gemini 由 Google 托管、管理并持续更新；Gemma 由你下载、自行运营并锁定版本。如果没有强制自托管的约束，托管路径省事得多。如果确实存在这样的约束，那么 Gemini 无论出多少钱都无法满足它。
与其他开放权重家族对比——通常拿来比较的是 Llama、Qwen 与 Mistral 系列——Gemma 的差异化在于其档位跨度异常宽（尤其在小尺寸一端）、当前代采用 Apache 2.0 许可证，以及官方领域变体的丰富程度。不过竞争者迭代很快，任何关于「谁在质量上领先」的断言保质期都很短。在做决定的那一刻用你自己的任务做评测，而不要相信笼统排名，包括本段的描述。
与完全不在本地跑任何东西对比，账很好算：托管 API 在首个结果的获取速度上胜出，在数据控制、离线能力与规模化后的边际成本上落败。当这三个因素中至少有一个是硬性要求而非偏好时，Gemma 的运维成本才是值得付的。
在家族内部，最被低估的替代方案是上一代。Gemma 3 提供了 Gemma 4 所没有的 270M 档位，在极度受限的部署场景下这可能是决定性的——前提是你把上文讨论过的许可证差异也一并算进去。
权重可以免费下载，运行时 Google 也不按 token 收费，因为算力由你提供。Gemma 4 以 OSI 认证的 Apache 2.0 许可证发布。真正的成本是硬件、电费或云实例时长，以及自己运营模型的工程投入。这里的「免费」指的是「没有许可费」，而不是「没有成本」。
对 Gemma 4 而言，Apache 2.0 许可证在其标准条款下允许商业使用、修改与再分发。对更早的版本则需要单独核实：Gemma 2、Gemma 3n 及其他旧仓库仍标注 Google 自定义的 gemma 许可证而非 Apache 2.0，那些自定义条款包含 Apache 2.0 所没有的使用限制。请务必查看你实际下载的那个仓库的许可证字段。
Gemini 是 Google 的闭源模型家族，以托管服务的形式访问。Gemma 是开放家族，权重由你下载并自行运行，构建自相关研究——Gemma 4 页面称其源自 Gemini 3 的研究与技术。同源，但分发模式相反。而 Google DeepMind 是发布两者的那个研究机构。
完全取决于你选择的档位。E2B 与 E4B 是为手机和小型开发板设计的，包括 Raspberry Pi 与 Jetson Nano，并且可以完全离线运行。12B、26B A4B 与 31B 面向消费级 GPU。26B A4B 是混合专家设计，推理时在 25.2B 总参数中激活约 3.8B，因此运行速度快于其总规模所暗示的水平——通常是这个家族中每单位显存容量性价比最好的选择。
工作站档最高 256K token，边缘档配备更小的 128K 窗口。需要注意的是，支持一个窗口和可靠地使用它是两回事：在模型卡的长上下文检索指标上，最大型号达到 66.4%，而较小档位急剧下滑。在围绕长上下文做设计之前，先在你实际的上下文长度上测试检索表现。
图像与视频理解在整条 Gemma 4 产品线上都可用，也支持交错多模态输入。音频是例外：官方模型卡把自动语音识别与语音转翻译文本限定在 E2B、E4B 与 12B。如果语音输入是硬性需求，两个最大的型号就不在选项之内。
Google 声明支持 140 种语言，并把目标框定为理解文化语境而非执行字面翻译。与任何宽泛的多语声明一样，质量在这个范围内差异相当大，因此请在你具体的目标语言上验证表现，而不要假定各语种表现一致。
如果你自托管，推理数据完全不必离开你的基础设施，这是开放权重方案最强的隐私属性。但 Google 明确把下游责任分配给你，鼓励开发者采用隐私保护技术遵守隐私法规。数据保护合规、日志策略与内容防护措施，都需要由你自己设计并实施。
可以——微调是 Google 为该家族列出的五项能力之一，官方分发页面也给出了包括 Unsloth、Keras、JAX 与 GKE 在内的训练工具链入口。微调得到的模型仍在你的控制之下，这正是团队选择开放权重而非托管 API 的主要理由之一。
Gemma 4 在推理类基准上更强，且采用更宽松的 Apache 2.0 许可证，因此是默认选择。Gemma 3 在两种情况下仍然相关：当你需要 270M 这个 Gemma 4 没有对应型号的档位时，以及当现有工具链已经锁定在它上面时。如果你确实选择 Gemma 3，请记住它的许可条款与 Gemma 4 不同，必须单独审阅。
