发生了什么

Google 的 Gemma 4 模型家族包含两个不寻常的小型模型：gemma-4-E2B 和 gemma-4-E4B。前缀'E'并非代表混合专家（Mixture-of-Experts, MoE）中的“专家”。这些模型采用了一种独特的架构，称为逐层嵌入（per-layer embeddings），它既非传统的稠密模型，也非 MoE。作为对比，gemma-4-26B-A4B 是标准的 MoE 模型，拥有 252 亿总参数，但每次推理步骤仅激活 38 亿参数。E 系列模型则采取了不同的方法来减少推理过程中的活跃计算量。

为何重要

对于运行本地推理的独立开发者和中小企业而言，这一区别具有实际意义。MoE 模型虽然减少了每个 token 的计算量，但仍需将所有专家权重加载到内存中，造成显存压力。逐层嵌入提供了不同的权衡：该架构允许更少的活跃参数数量，同时避免了 MoE 路由基础设施带来的完整内存开销。这意味着：

  • 降低了在消费级 GPU 上部署的显存要求
  • 在预算部署中常见的 CPU 卸载设置下实现更快的推理速度
  • 相比 MoE，路由逻辑更简单，降低了推理引擎的复杂性
  • 与同等规模的稠密模型相比，具有更具竞争力的质量与计算比率

社区对'E'命名的困惑凸显了模型架构术语的快速演变，使得开发者在缺乏深入技术背景的情况下更难评估模型。

亚太视角

构建端侧或边缘 AI 应用的中国及东南亚开发者面临严格的硬件限制，特别是在平均 GPU 规格较低的市场部署时。Gemma 4 E 系列模型针对低活跃参数推理进行了优化，对于使用 llama.cpp 或 Ollama 等工具在中端硬件上部署的团队而言直接相关。该地区已熟悉 Qwen2.5 和 MiniCPM 小型模型架构的开发者，应在其目标硬件上直接对 E2B 和 E4B 进行基准测试。Google 的逐层嵌入方法可能在东南亚移动和边缘部署中常见的基于 ARM 的推理硬件上提供更好的吞吐量。

本周行动项

通过 Ollama 或 Hugging Face 下载 gemma-4-E2B，并在您的实际部署硬件上，将其与可比的 MoE 模型（如 3B 的 Qwen2.5）进行并行的推理速度和质量基准测试。记录每秒 token 数和内存使用情况，以确定哪种架构符合您的生产约束。