Gemma 4 E2B 是什么：参数名、模型包和端侧部署

Gemma 4 E2B 是 Gemma 4 家族中面向端侧部署的变种。真正接入应用时，不能把“E2B”“参数量”“量化权重大小”“LiteRT-LM 包大小”和“加载峰值内存”混成一个数字。它们回答的是不同问题。

E2B 是模型标识，不是文件大小

模型名称用来区分家族与变种；部署文件还会受到量化、转换工具、运行时包格式和附加元数据影响。即使两个文件都叫 Gemma 4 E2B，也应核对来源、revision、格式、量化和哈希。

官方移动部署路径

Google 官方移动部署文档给出了通过 Google AI Edge 工具在 Android 与 iOS 使用 Gemma 的路径，并提供 AI Edge Gallery 等验证入口。它适合先确认模型能否加载和完成目标任务，再进入完整 App 工程。

Gemma 运行指南将 LiteRT-LM 列为 Android 与 iOS 的端侧 LLM 开源框架，并描述 CPU、GPU、NPU 路径。具体设备是否走到某个后端，仍需在真实 artifact 与设备上验证。

为什么网上会出现不同大小

一个模型可能同时出现：

• 训练或模型卡中的参数口径；
• 原始权重大小；
• 某种量化后的权重大小；
• 运行时专用部署包大小；
• App 实际下载文件大小；
• 加载后的峰值内存。

把其中任意一个数字写成“实际占用”都可能误导。产品页应注明口径和 artifact revision。

Cove 当前使用的口径

Cove 当前固定的 E2B LiteRT-LM artifact 在 Android 配置中记录为 2,583,085,056 字节。这个数字用于该文件的下载和存储预检，不代表全部 E2B 包，也不等于运行时峰值内存。

当前 E2B 配置中的 SHA-256 仍为空，所以不能写成“文件已完成哈希校验”。发布前应对固定 artifact 计算真实 digest，再让下载器强制验证。

Cove 代码还列出 E4B 变种，但其预期大小和 SHA-256 明确标记为占位值。占位值不能进入官网模型表、兼容页或发布说明。

接入前要确认的字段

字段	为什么需要
家族与变种	避免拿错模型
指令版/基础版	输出行为不同
artifact revision	保证可复现
文件格式	与运行时匹配
量化	影响体积与输出
预期长度	下载与存储检查
SHA-256	精确完整性验证
运行时版本	API 与执行路径
后端	CPU/GPU/NPU 实际选择
测试集	判断任务是否可用

先验证任务，再做产品包装

不要先做下载页和设置页。先用最小工程或 AI Edge Gallery 验证：artifact 能加载，代表输入能处理，输出格式可控，失败能捕获。通过后再建设断点续传、状态机、变种切换和 UI。

读模型页时的判断原则

看到任何数字都追问：它来自官方模型卡、文件系统、代码配置，还是真机 profiler？是否标明 revision 和量化？是否能复现？如果答案不完整，这个数字只能做线索，不能做兼容结论。

下一步看 Gemma 4 本地部署和 LiteRT-LM Android 教程。Cove 的三语模型页见 Gemma 4 E2B。

---

本文最后核验于 2026-09-16，未使用占位 E4B 数字或未经真机测量的性能数据。