Gemma 4 下载：模型来源、断点续传和完整性校验

Gemma 4 下载最重要的不是“能下下来”，而是半年后还能回答：这个文件来自哪里、是什么 revision、什么格式、长度是多少、哈希是什么、下载中断后怎样恢复、镜像是否提供同一份 bytes。缺一项，模型升级和故障复现都会变得困难。

固定 revision，不要永远指向 main

生产下载 URL 应固定到明确版本或提交。若链接永远跟随 main，同一个 App 版本可能在不同日期拿到不同文件，预期大小、哈希和输出都无法复现。

模型配置至少记录：变种、下载 URL、镜像 URL、文件名、revision、预期长度、SHA-256 和运行时格式。

不同格式不能靠改后缀转换

.litertlm、GGUF 等属于不同运行时的部署路径。确认运行时以后再下载对应 artifact。文件名看起来相似，不代表内容或 tokenizer 一致。

Cove 当前 E2B 文件

Cove 当前 Gemma 4 E2B LiteRT-LM 下载 URL 固定到 Hugging Face 的具体提交，代码记录的预期大小为 2,583,085,056 字节。这个数字只适用于当前固定文件。

当前配置里的 SHA-256 仍为空。下载器只有在 digest 非空时才会执行哈希验证，因此官网不能宣称“当前模型已哈希校验”。正确动作是下载固定 artifact、计算 digest、回写配置并跑下载测试。

E4B 配置的大小和 SHA-256 仍是占位，下载 URL 也尚未固定到稳定提交。它不能进入发布清单，更不能拿占位体积做用户存储预检。

断点续传的正确边界

Cove 当前下载器把内容先写入 .tmp 文件，根据已有长度发送 HTTP Range 请求；只有服务器返回部分内容时才追加，否则会重写临时文件。它还会发射字节进度，并在超时或 DNS 失败时尝试已配置镜像。

断点文件必须绑定 artifact 身份。revision 变化后，旧临时文件不能续到新文件里。镜像也必须通过相同哈希证明内容一致，不能只看文件名。

临时文件与最终文件

最终文件名只应在下载和验证完成后出现。应用重启时，看到 .tmp 应进入“可续传或清理”状态，不能把它当成可加载模型。

重命名也要检查结果。达到输入流末尾不等于最终文件已经成功放置。更新时更应保留旧的可用 artifact，直到新版本验证并加载成功。

下载前的空间预检

空间检查不能只算模型文件。还要考虑临时文件、更新时旧文件与新文件并存、数据库与缓存余量。提示应写实际所需空间、当前网络策略和是否支持后台继续。

失败分类

把错误归一成用户可行动的类别：

• 存储不足；
• DNS 或连接失败；
• HTTP 响应异常；
• 读取中断；
• 文件长度不符；
• 哈希不符；
• 最终文件放置失败；
• 模型加载失败。

不要把底层异常堆栈直接展示给用户，也不要在日志里输出带凭据的完整 URL。

发布检查单

• URL 固定到明确 revision。
• 文件格式与运行时匹配。
• 记录真实长度。
• 计算并回写 SHA-256。
• 主站和镜像 hash 一致。
• 临时文件与最终文件分离。
• 服务端不接受 Range 时从头重下。
• revision 变化时清理旧断点。
• 检查最终放置结果。
• 加载失败可进入修复流程。
• 官网体积与发布 manifest 同步。

继续阅读 Gemma 4 E2B 是什么和 Gemma 4 本地部署。Cove 英文交付方法见 On-Device Model Download UX。

---

本文最后核验于 2026-09-16。发布前仍需为 Cove 当前 E2B artifact 补齐真实 SHA-256。