Ollama模型分片下载中断后如何断点续传并校验文件完整性 [复制链接]

52JinY 一级用户组 3小时前

金小颖论坛 AI 摘要

AI 正在阅读全文并生成摘要，请稍等……

下载几十 GB 的 Ollama 模型时，网络波动、代理超时、磁盘写入阻塞都可能导致分片传输中断。遇到这种情况，通常不必立即删除模型目录重新下载；正确做法是先保留已有分片，再重新执行拉取，并利用 Manifest 中记录的大小与 SHA-256 摘要检查文件完整性。🔧

一、先理解 Ollama 的模型存储方式

Ollama 并不是简单地把一个模型保存为“模型名.gguf”。它采用内容寻址方式组织文件：manifests 目录保存模型清单，blobs 目录保存权重、配置、模板等实际数据。每个 Blob 都以 SHA-256 摘要标识，Manifest 则记录各层的 digest、大小和媒体类型。具体实现可参考来源链接源代码仓库。

常见的模型根目录由环境变量 OLLAMA_MODELS 决定。若没有自定义，Linux 普通用户通常可先检查 ~/.ollama/models；如果 Ollama 作为系统服务运行，还应检查服务账户的主目录或环境变量。Windows 和 macOS 的实际位置会受到安装方式、运行账户及版本影响，因此不要盲目照搬路径。

关键原则：中断后先不要删除 blobs、临时分片或整个 models 目录。删除这些内容可能使原本可复用的下载进度彻底丢失。

二、首选方法：直接重新执行 pull

多数情况下，最稳妥的续传方式就是再次运行相同的模型拉取命令。模型名称和标签必须与上次完全一致，例如：

ollama pull qwen2.5:7b

Ollama 会重新获取 Manifest，检查本地已经存在的 Blob，并处理缺失或未完成的层。历史版本中曾有“停止后再次 pull 可继续”的维护者说明，也有部分版本或异常场景出现重新下载的问题，因此实际行为应以当前安装版本为准，可参阅相关断点续传讨论。⚠️

如果进度看似短暂回退，不一定代表整个文件从零开始。分片并行下载时，某个分片重试、总量重新计算或摘要校验失败，都可能改变进度显示。建议观察磁盘占用和下载日志，而不是只根据百分比判断。

三、如何找到 Manifest 和 Blob

在 Linux 或 macOS 中，可以先查看模型目录：

echo "${OLLAMA_MODELS:-$HOME/.ollama/models}"
find "${OLLAMA_MODELS:-$HOME/.ollama/models}" -maxdepth 3 -type d

Manifest 是 JSON 数据，其中的 layers 和 config 通常包含 digest 与 size。假设摘要为 sha256:abcdef...，对应的本地 Blob 文件名一般表现为 sha256-abcdef...。不要只校验最大的权重层，因为配置、模板或适配器层损坏，同样可能造成模型加载失败。

如果系统安装了 jq，可用下面的方式查看某个 Manifest 引用的层：

jq -r '.config, .layers[] | [.digest, .size, .mediaType] | @tsv' /实际路径/manifest

操作前最好复制 Manifest 留作备份。不要手工修改其中的 digest 或 size 来“绕过校验”，因为这会破坏模型清单与 Blob 之间的对应关系。

四、使用 SHA-256 校验文件完整性

在 Linux 中，可对 Blob 执行：

sha256sum /模型目录/blobs/sha256-完整摘要

macOS 可使用：

shasum -a 256 /模型目录/blobs/sha256-完整摘要

Windows PowerShell 可使用：

Get-FileHash "D:\Ollama\models\blobs\sha256-完整摘要" -Algorithm SHA256

计算结果应与 Manifest 中 digest 的十六进制部分完全一致，包括每一个字符。GNU Coreutils 对 sha256sum 的计算与检查方式有明确说明，可参考 sha256sum 文档。✅

还应比较实际文件大小与 Manifest 中的 size。Linux 可执行：

stat -c '%s' /模型目录/blobs/sha256-完整摘要

macOS 可执行：

stat -f '%z' /模型目录/blobs/sha256-完整摘要

大小一致但摘要不同，说明内容已损坏；大小小于 Manifest 记录，通常表示下载不完整。只有大小和 SHA-256 都一致，才能较可靠地确认该 Blob 完整。

五、校验失败后的正确处理

若只有一个 Blob 校验失败，优先停止 Ollama 服务，把该异常 Blob 和同摘要的临时分片移动到备份目录，而不是清空整个 models 目录。随后启动服务并再次执行 ollama pull，让 Ollama只重新获取缺失层。

不要在 Ollama 正在下载或运行模型时移动文件，也不要随意删除 manifests。Manifest 丢失后，即使权重 Blob 仍在磁盘中，Ollama 也可能无法把它识别为对应模型。

反复 unexpected EOF：检查 DNS、代理、网关和链路稳定性，相关案例可参考 Ollama 问题记录。
反复 digest mismatch：排查透明代理、防病毒网关或缓存设备是否修改、截断响应，参考摘要不匹配案例。
磁盘空间不足：同时检查模型目录所在分区和临时目录所在分区。
权限错误：确认下载命令与 Ollama 服务使用的是同一账户或同一模型路径。
不同标签混淆：始终保留完整的“模型名:标签”，不要把不同量化版本当成同一份文件。

六、关于 curl 或 aria2 手工续传

只有在能够合法、稳定地获得 Blob 下载地址，并确认服务器支持 HTTP Range 时，才适合使用 curl 的续传功能，例如 curl -C - -o 目标文件下载地址。不过 Ollama Registry 返回的实际下载地址可能经过重定向或带有时效参数，直接保存旧地址往往会失效。

手工下载后仍必须核对 Manifest 中的 size 和 SHA-256，并按 Ollama 的文件命名规则放入 blobs 目录。对于普通用户，重新执行 ollama pull 通常比手动拼接分片更安全，也更不容易造成 Manifest 与本地文件不一致。

总结

Ollama 模型分片下载中断后，应遵循“保留现场、重复 pull、定位 Blob、核对大小、验证 SHA-256、只替换损坏层”的流程。不要一遇到失败就删除整个模型仓库，也不要通过修改 Manifest 跳过校验。最终以摘要一致、模型能被 ollama list 识别并可以实际加载运行作为完整性判断依据。🚀