> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Gemma 4：云端垄断的终结？
- URL: https://www.hubwiz.com/blog/gemma-4-the-end-of-cloud-monopoly/
- Published: 2026-04-07T00:38:36.000Z
- Updated: 2026-04-07T00:38:36.000Z
- Description: 为什么还要付钱调用 API？一款 31B 的模型就能在你的本地机器上超越 20 倍体量的模型。
- Author: admin
- Tags: MODEL-ZOO, GEMMA4, #Import 2026-10-14 14:41

每一个曾盯着 API 账单看过的工程师心中都有一个问题：**在什么时候，在本地运行 AI 变得不只是可能，而是显然正确的选择？**

多年来，诚实的答案是“还不到时候”。开源模型足以做实验，但不足以投入生产。上下文窗口太小，无法处理真实文档。许可证条款上的星号让法务团队望而却步。而开放权重模型与专有前沿模型之间的推理能力差距大到让人感觉使用云端 API 就像是在交一种“必然的税”。

谷歌于 2026 年 4 月 2 日发布的 Gemma 4，是改变这个答案的发布。

不是因为它神奇地解决了所有问题。而是因为它同时推动了三个不同的杠杆：能力、许可证和硬件覆盖范围。31B Dense 模型目前在全球 Arena AI 排行榜上位列第三，以参数量计击败了体量是其 20 倍的竞争对手。26B Mixture of Experts 变体在推理时仅激活 38 亿参数，就能提供几乎相同的质量。边缘模型可以在 Android 手机和树莓派开发板上原生运行。而有史以来第一次，Gemma 家族的所有模型都基于 Apache 2.0 许可证发布。

最后一点不是脚注。对许多工程团队和企业来说，这才是标题。

## 1、改变一切的许可证

让我们从大多数报道在第八段才提及的内容开始，因为它值得放在第一段。

过去两年，谷歌的 Gemma 系列一直表现强劲。模型确实很好。但它们基于谷歌自定义许可证发布，该许可证包含公司可以单方面更新的条款，要求开发者将谷歌的规则传递给所有下游用户，包含需要法务解读才能在企业采用的“有害使用”例外条款，以及让法务团队对微调感到紧张的关于合成数据的条款。

带星号的“开放权重”不等于真正的开放。对于那些一直在等待谷歌采用与领域其他公司相同许可证条款的团队来说，等待结束了。

Gemma 4 基于 Apache 2.0 发布。与覆盖 Qwen、Mistral 以及大多数严肃开源生态系统的许可证相同。要理解这为什么重要，有助于将其与当前的其他选择进行比较。

> ***许可证对比：你能实际做什么***

![无](https://www.hubwiz.com/blog/content/images/2026/04/1-MMnksDfBTte6pUGzbQIBRg-1.png)

没有自定义条款，没有需要法务解读的“有害使用”例外，没有再分发或商业部署的限制。你下载权重。你构建东西。你发布它。需要署名。这就是全部的法律义务。

之前的 Gemma 服务条款包含了公司可以单方面更新的严格禁止使用政策，要求开发者在所有基于 Gemma 的项目中执行谷歌的规则，并且包含可能将许可证扩展到使用 Gemma 生成的合成数据训练的模型的条款。所有这些都没了。

对独立开发者来说，这只是更干净了。对构建产品的企业来说，这是一场需要三天的法务对话和一场根本不需要发生的区别。

## 2、Gemma 4 家族，逐一解析

Gemma 4 有四种规格：E2B 和 E4B 用于边缘设备，一个 26B Mixture of Experts 模型，以及一个用于工作站的 31B Dense 模型。但这些规格名称正在做特定的技术工作，值得在选择之前理解。

> ***一览全系列***

![无](https://www.hubwiz.com/blog/content/images/2026/04/1-SeI0doWHwmsnXzasHmISag-1.png)

### 2.1 边缘模型：E2B 和 E4B

E2B 和 E4B 中的"E"代表“有效参数”，这个命名方式做了一件容易被误读的微妙工作。

E2B 有 23 亿有效参数，但总计 51 亿。E4B 类似，在磁盘上的权重比推理时激活的更多。这个差距不是营销花招。这是一种叫做 **逐层嵌入（Per-Layer Embeddings，PLE）**技术的结果。

这是直觉。在标准 transformer 模型中，每个 token 恰好有一个嵌入：一个固定向量，在网络开始处理之前表示它的身份。单词"bank"无论出现在关于金融的句子还是关于河流的句子中都有相同的嵌入。然后模型的各层通过注意力来消歧义。

PLE 通过为每个解码层为每个 token 提供自己的小嵌入表来改变这一点。可以把它想象成模型根据它从哪个层思考这个词而有不同的“第一印象”。这些逐层表在磁盘上很大，但在推理时仅用于快速查找操作，而不是重计算。结果：模型以 2B 模型的速度和内存占用运行，同时在整个处理过程中携带更丰富的、层特定的上下文信号。

> ***可视化逐层嵌入（PLE）***

> *标准模型：每个 token 获取* **一个** \*\* *嵌入 → 所有层相同的起点*

> *`Token "bank" → [embedding vector] → Layer 1 → Layer 2 → Layer 3 → Output ↑ 所有层相同`*

> *PLE 模型：每个 token 在每个层获得* ***不同的残差信号***

> *`Token "bank" → [base embedding] + [layer-1 residual] → Layer 1 + [layer-2 residual] → Layer 2 + [layer-3 residual] → Layer 3 → Output ↑ 小查找表，廉价计算`*

> *表在磁盘上很大，但在运行时基本免费。你获得更丰富的表示，而无需在计算或内存上付出代价。*

实际结果是 E2B 和 E4B 边缘模型可以在智能手机和树莓派开发板上完全离线运行，运行速度比之前的 Gemma 版本快高达 4 倍。E4B 可以在 8GB 笔记本电脑上运行。E2B 可以在树莓派 5 上以每秒 7.6 个 token 的速度进行解码，在预填充（初始提示处理）阶段达到每秒 133 个 token。

两个边缘模型还携带大型模型没有的东西：**原生音频输入**。这在多模态部分有更多介绍。

### 2.2 效率之王：26B A4B（混合专家）

这是任何构建生产推理系统的人都值得关注最多的模型。

名称中的“A4B”代表“活跃 40 亿参数”。模型有 252 亿总参数，组织成 128 个小的专家子网络。在推理时，一个学习到的路由机制为每个 token 选择 8 个专家加上 1 个共享的常驻专家。这意味着每个前向传递实际只有 38 亿参数被激活。

让这个概念理解的类比：想象一家医院有 128 名专科医生。当病人到达时，分诊系统将他们路由到恰好 8 名适合他们病情的专科医生。其他 120 名随时待命，但不为这个病人做任何工作。医院携带所有 128 名专科医生的知识，但治疗任何个别病人的成本与 8 名专科医生的工作成正比。

> ***26B A4B 中的混合专家如何工作***

![无](https://www.hubwiz.com/blog/content/images/2026/04/1-Hsa8zuxEo7TDjlGgPcJqRw-1.png)

```
存储的总参数：252 亿（完整模型知识）
每个 token 活跃的参数：38 亿（实际计算成本）
相比 31B dense 的效率提升：每次推理步骤便宜约 8 倍
质量 vs 31B dense：约 97% 基准持平

```

MoE 变体以一小部分推理成本提供几乎相同质量。而 E2B 模型为内存低于 2GB 的设备带来了真正的多模态智能。

这里值得注意谷歌的具体架构选择。不同于近期使用少数大型专家的大型 MoE 模型，谷歌选择了 128 个小型专家，每个 token 激活 8 个加上 1 个共享的常驻专家。相比之下，Llama 4 Scout 使用 16 个大型专家。128 个小型专家的方法似乎有效：26B A4B 在 Arena AI ELO 上达到 1441，与活跃参数数量多许多倍的 dense 模型具有竞争力。

推理经济学很简单。一个以 4B 类吞吐量提供 27-31B 类推理的模型意味着更少的 GPU、更低的延迟，以及生产中更便宜的每 token 成本。对于运行编码助手、文档管道或多轮代理工作流的大规模组织，这可能是该系列中最理性的选择。

### 2.4 重量级：31B Dense

31B Dense 是简单的那一个。没有奇特的路由，没有查找表技巧。只是一个大型的、capable 的 dense transformer。当你在专有数据上进行微调时，当你想要推理质量的绝对天花板时，或者当你需要一个最稳定的专业适配基础时，你会选择它。

未量化的情况下，它适合单张 80GB H100。以 4 位量化（Q4\_K\_M），它可以在 20-24 GB 范围内的消费级 GPU 上运行。31B 模型将在 Arena 顶级开放 AI 模型排行榜上首次亮相第三名，击败体量是其 20 倍的模型。

## 3、技术突破

### 3.1 整个家族的原生多模态

每个 Gemma 4 模型都能原生处理文本和图像输入，重新设计的视觉编码器支持可变的纵横比和可配置的 token 预算，从每张图像 70 到 1120 个 token。这个范围在实践中很重要：更低的预算快速处理分类和标题；更高的预算解锁 OCR、文档解析和密集的图表理解。

26B 和 31B 模型支持最长 60 秒、每秒 1 帧的视频理解。E2B 和 E4B 支持语音识别和翻译的音频输入，全部在设备上运行。

边缘模型上的音频能力特别值得注意。音频编码器已压缩到 3.05 亿参数，从上一代的 6.81 亿，而帧持续时间从 160ms 降至 40ms，以获得更灵敏的转录。一个 4B 类模型在手机上完全离线进行实时语音识别和多模态理解，不是一个演示。它是设备端 AI 的一个新能力层。

> ***多模态能力地图***

![无](https://www.hubwiz.com/blog/content/images/2026/04/1-lThMdYmI7tkl25Xf8pPxxQ.png)

### 3.2 256K 上下文窗口：p-RoPE 如何解决内存问题

256K token 上下文窗口听起来很棒，直到你了解到为什么大多数声称大上下文的模型在实际达到广告限制之前质量就已经下降。

核心问题是位置编码。标准 transformer 使用旋转位置嵌入（RoPE）来告诉模型每个 token 在序列中的位置。但 RoPE 是用针对特定序列长度校准的特定频率模式训练的。超出该长度扩展，位置信号就会变得不连贯，就像试图用为厘米设计的尺子来测量公里。模型失去了对事物位置的跟踪，检索质量崩溃。

Gemma 4 的大型模型通过两个协同工作的架构选择来解决这个问题。

**混合注意力**在局部滑动窗口注意力（每个 token 关注其 512-1024 个最近邻，非常快）和完整全局注意力（整个序列，昂贵但精确）之间交替。最后一层始终是全局的。大多数计算使用廉价的局部路径；稀疏的全局层保持长程理解。

**比例 RoPE（p-RoPE）**应用于全局注意力层。p-RoPE 不用固定的 RoPE 频率，而是根据实际序列长度按比例缩放位置编码。模型的 positional “词汇”扩展到覆盖你给它的任何输入，而不会因打破标准长上下文模型的不连贯问题而崩溃。

> ***混合注意力如何实现 256K 上下文***

![无](https://www.hubwiz.com/blog/content/images/2026/04/1-AvD1asG4QM8_Z4p6JlkUZA.png)

结果不仅仅是规格表上的更大的数字。Gemma 4 在 256K 上下文下实际可以检索和推理长文档。31B 模型在多针检索测试中从 13.5% 提升到 66.4%。你可以传入整个代码库、一个长法律文档或几小时的会议记录，模型会真正利用这些信息。

### 3.3 思考模式：教模型在回答前推理

所有四个 Gemma 4 模型都包含一个可配置的推理追踪模式。在系统提示开头添加 `<|think|>`，模型会在给出最终答案之前输出内部思维链。

机制类似于你可能知道的思维链提示，但有一个关键区别：它被训练进模型的行为中，而不是通过提示工程诱导出来。模型在训练中学会了逐步推理作为一等能力，而不是当你说服它时才试图模仿的模式。

这正是让 AIME 2026 分数成为可能的原因。数学竞赛问题需要多步推导，第 3 步的错误会级联到之后的所有步骤。能够在输出答案前内部验证推理的模型，在结构上更适合这类任务。

```
# 在 Gemma 4 中启用思考模式
messages = [
    {
        "role": "system",
        "content": "<|think|> You are a precise reasoning assistant. Think through problems step by step before answering."
    },
    {
        "role": "user",
        "content": "What is the time complexity of Dijkstra's algorithm with a Fibonacci heap?"
    }
]
# 模型输出：
# <think>
# Dijkstra's algorithm processes each vertex once and each edge once.
# With a Fibonacci heap: decrease-key is O(1) amortized...
# 
# 
# Dijkstra's algorithm with a Fibonacci heap runs in O((V + E) log V) time...

```

一个重要的实现说明：在构建多轮对话时，只在后续轮次中包含最终可见的答案。不要将之前的 `<think>` 块反馈回上下文。模型可能会被自己的先前推理追踪分散注意力。

## 4、基准测试实际上告诉你什么

没有上下文的数字会误导。以下是 Gemma 4 的基准分数在实践中的含义。

> ***Gemma 4 基准分数（指令微调变体）***

![无](https://www.hubwiz.com/blog/content/images/2026/04/1-TBT56IsRwS7pwz0mur8wtQ.png)

> ***代际飞跃：Gemma 3 vs Gemma 4***

![无](https://www.hubwiz.com/blog/content/images/2026/04/1-OruGBCaU9_ceZELWfk0paA.png)

代理 tau2-bench 的提升值得特别关注。从 6.6% 到 86.4% 在多步工具使用任务上的 13 倍跳跃意味着 Gemma 4 不仅仅是更好地回答问题。它在作为自主代理行动方面 qualitativ 更好：规划工具调用序列、从中间失败中恢复、完成 Gemma 3 无法以生产质量处理的多步复杂任务。

对于在本地硬件而非云端 API 上构建 AI 代理的开发者，这些结果缩小了一个能力差距，该差距以前使云端托管模型成为代理工作流的唯一实际选择。

### 4.1 每瓦性能论点

这个框架比看起来更重要。在云端基础设施上运行的 AI 代理为它生成的每个 token、占用的每个 GPU 秒数计费。在本地运行的代理有一次性的硬件成本，然后以边际电力成本运行。

对于始终在线的应用——监视你的编辑器的编码助手、在后台运行的文档处理器、保留隐私的分析管道——本地推理的经济效益随着时间推移会显著复合。26B A4B 模型每个 token 只激活 3.8B 参数不只是更便宜。它也更快，为交互式应用产生更低的延迟，并且每单位有用输出实际消耗更少的电力。

当你每天运行数百个代理任务时，为云端推理付费与在你已经拥有的硬件上运行本地模型之间的差异不是四舍五入的误差。它是你应用的全部成本结构。

## 5、使用 Gemma 4 构建

### 5.1 原生函数调用：不是提示技巧

函数调用在所有四个模型上都是原生的，借鉴了谷歌 FunctionGemma 发布的研究。与之前依赖指令遵循来诱导模型进行结构化工具使用的方法不同，Gemma 4 的函数调用是从根本上训练进模型的，为多工具多轮代理流优化。

这个区别在生产中很重要。当函数调用是训练出的行为而不是提示的行为时，你获得更高的模式合规性（模型第一次就返回有效 JSON，而不是两次重试后）、更好的多工具排序（模型正确决定以什么顺序调用什么工具），以及更低的提示工程开销（你描述工具，而不是如何使用工具）。

模型还原生支持结构化 JSON 输出，用于 UI 元素检测和浏览器自动化的边界框输出，以及在工具调用前可配置思考追踪的多步规划。

### 5.2 三命令入门（Ollama）

```
# Pull the model
ollama pull gemma4:26b-a4b
# Start the server
ollama serve
# Run inference
curl http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:26b-a4b",
    "messages": [
      {
        "role": "user",
        "content": "Explain the tradeoffs between B-trees and LSM-trees for write-heavy workloads."
      }
    ]
  }'

```

使用 Ollama 的硬件要求（Q4\_K\_M 量化）：

![无](https://www.hubwiz.com/blog/content/images/2026/04/1-wcDgXO_6gXrgxt2_5l61uw.png)

### 5.3 场景：离线私有文档分析器

这是一个从不发送你的数据的文档分析系统的完整 Python 设置：

```
from transformers import AutoProcessor, AutoModelForCausalLM
import torch
model_id = "google/gemma-4-26B-A4B-it"
processor = AutoProcessor.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map="auto",
    torch_dtype=torch.bfloat16,
)
def analyze_document(document_text: str, question: str) -> str:
    messages = [
        {
            "role": "system",
            "content": "<|think|> You are a precise document analyst. Reason carefully before responding."
        },
        {
            "role": "user",
            "content": f"""Document:\n{document_text}\n\nQuestion: {question}"""
        }
    ]
    inputs = processor.apply_chat_template(
        messages,
        return_tensors="pt",
        return_dict=True,
    ).to(model.device)
    outputs = model.generate(
        **inputs,
        max_new_tokens=1024,
        do_sample=True,
        temperature=0.7,
    )
    response = processor.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True)
    return response
# Example: analyze a contract entirely on your own hardware
with open("contract.txt") as f:
    contract = f.read()
analysis = analyze_document(
    contract,
    "What are the key liability clauses and their limits?"
)
print(analysis)

```

模型完全在你的机器上运行。没有任何文档离开你的基础设施。没有 API 密钥。没有按 token 计费。对于法律文档、医疗记录、财务数据或任何其他敏感材料，这不只是更经济。从数据治理的角度来看，这是质的不同。

### 5.4 首日生态系统支持

Gemma 4 在每个主要推理框架上都有即时集成：Hugging Face Transformers、vLLM、llama.cpp、MLX for Apple Silicon、LM Studio、Unsloth、SGLang、NVIDIA NIM 和 NeMo，以及用于浏览器内推理的 WebGPU。权重在 Hugging Face、Kaggle 和 Ollama 上可用。谷歌云运行支持两种工作站模型，采用零扩展计费。

## 6、主权 AI 时代

开发者和 AI 基础设施之间的关系正在发生结构性转变。

自第一代 Gemma 发布以来，开发者已下载 Gemma 超过 4 亿次，构建了一个拥有超过 100,000 个变体的充满活力的生态系统。社区已经展示了当 capable 的开放权重遇到积极的建设者会发生什么：保加利亚语主权基础设施、耶鲁大学的癌症通路研究、乌克兰的政府服务、跨越印度 22 种官方语言的多语言应用。

Gemma 4 给这个社区提供了以前没有的东西：前沿级能力，且条款不产生任何法律摩擦。

云端推理模式不会消失。对于某些用例，特别是在原型开发期间，或对于真正受益于最新前沿模型在能力绝对天花板处的应用，云端 API 仍然是正确的选择。没有人假装不是这样。

但问题变了。过去几年的问题是“开放权重模型能足够好吗？”对于越来越多的用例，答案现在显然是肯定的。这意味着真正的问题是：“既然开放权重模型对我的用例已经足够好，有什么令人信服的理由要为云端推理付费？”

数据主权。规模化成本。离线运行。基础设施控制。延迟。能够在专有数据上进行微调并保留结果。这些不是边缘案例。它们是团队实际关心的生产 AI 部署的大多数。

对于基于开放模型构建产品的组织，许可证的清晰性与基准数字同样重要。Gemma 4 两者兼得。

权重已经就绪。唯一的问题是：你将构建什么？

---

原文链接: [Gemma 4: The End of the Cloud Monopoly?](https://pub.towardsai.net/gemma-4-the-end-of-the-cloud-monopoly-a7e728d1b2ea?ref=hubwiz.com)

汇智网翻译整理，版权归作者所有，转载需标明出处