在 Ollama 0.4 环境下执行 ollama pull llama3:70b 时，进度条爬到 47% 后彻底静止，终端没有任何输出。Ctrl+C 再重试，有时从断点续传，有时又从头开始；偶尔会看到 unexpected EOF 或 connection reset by peer。这类问题几乎不是模型本身的问题，而是下载链路、磁盘预分配或本地注册表文件损坏导致的。
常见原因
1. 下行带宽波动导致 TCP 流超时
Ollama 默认对每个 blob 分片使用单一 HTTP/2 连接，带宽抖动超过 30 秒后服务端会主动断开，客户端表现为进度条停止但没有错误信息。
怎么判断：在另一个终端运行 watch -n2 'ss -s' 观察 established 数量是否在下载期间突然归零。
2. 磁盘空间不足或 inode 耗尽
Ollama 会在下载开始前预分配完整文件大小。如果下载到一半时 / 或 ~/.ollama 所在分区剩余空间不足，写入会静默卡住而非报错。
怎么判断：df -h ~/.ollama 检查可用空间，df -i ~/.ollama 检查 inode 是否为 0。llama3:70b Q4_K_M 大约需要 40 GB 可用空间。
3. 部分 blob 文件损坏无法校验
Ollama 在 ~/.ollama/models/blobs/ 下缓存每个 layer。若之前下载中途断电，blob 文件大小和 manifest 预期不符，再次 pull 时进度条会卡在校验步骤。
怎么判断：ls -lh ~/.ollama/models/blobs/ 找到大小为 0 或远小于预期的文件；ollama show llama3:70b 会列出 blob digest，对比本地文件大小。
4. 防火墙或代理对大文件连接做了截断
企业网络或家用路由器有时对超过一定时长的单 TCP 连接做强制重置，模型 blob 动辄 10-20 GB，下载时间超过代理超时阈值。
怎么判断：curl -v --max-time 600 -o /dev/null https://registry.ollama.ai/ 观察是否在特定时长后被重置；或临时切换到手机热点测试。
5. DNS 解析问题导致 CDN 节点切换
Ollama 注册表使用多 CDN。若本地 DNS 缓存陈旧，一次下载可能切换到不同的 CDN 节点，导致 HTTP range 请求失败并卡住。
怎么判断：dig registry.ollama.ai 连续跑两次，检查返回 IP 是否一致；不一致说明 DNS 存在轮询或缓存问题。
6. Ollama 服务进程僵尸占用写锁
极少数情况下，前一个 pull 进程虽然被 Ctrl+C 终止，但子进程依然持有 blob 写文件锁，导致新 pull 在写入时永久阻塞。
怎么判断：lsof +D ~/.ollama/models/blobs/ | grep -v ollama 检查是否有非 ollama 进程持有锁；或 ps aux | grep ollama 查看是否有僵尸进程。
最短修复路径
Step 1：清理损坏的 blob
# 找出大小异常的 blob（小于 1MB 的一般是损坏文件）
find ~/.ollama/models/blobs/ -size -1M -type f
# 删除整个模型的 blob（只删该模型，不影响其他已下载模型）
ollama rm llama3:70b 2>/dev/null || true
find ~/.ollama/models/blobs/ -name "sha256-*" -size -1M -deleteStep 2：确认磁盘空间充足
df -h ~/.ollama
# llama3:70b Q4_K_M 需要约 40 GB，Q8_0 需要约 70 GB
# 确保可用空间超过目标模型大小的 1.2 倍Step 3：设置环境变量后重新 pull
# 增加 HTTP 超时并指定更大 buffer
OLLAMA_KEEP_ALIVE=60m OLLAMA_MAX_LOADED_MODELS=1 ollama pull llama3:70b
# 如果在代理后面，确保代理支持长连接
export HTTPS_PROXY=http://your-proxy:port
ollama pull llama3:70bStep 4：使用 HuggingFace 镜像源作为备选
# 改用 HuggingFace 上的 GGUF 直接导入（适用于 llama.cpp 格式）
# 先从 HF 下载 Q4_K_M 文件
wget https://huggingface.co/bartowski/Meta-Llama-3-70B-Instruct-GGUF/resolve/main/Meta-Llama-3-70B-Instruct-Q4_K_M.gguf
# 创建 Modelfile 并导入
cat > Modelfile << 'MODELEOF'
FROM ./Meta-Llama-3-70B-Instruct-Q4_K_M.gguf
MODELEOF
ollama create llama3-70b-local -f ModelfileStep 5：分段验证下载完整性
# pull 完成后验证模型可以正常加载
ollama run llama3:70b "hello" --verbose 2>&1 | head -20
# 正常应该看到 model loaded 和 token 输出预防建议
- 在稳定的有线网络环境下执行大模型下载，避免 WiFi 断连。
- 提前用
df -h确认目标分区有足够空间，70B 模型的 Q4 量化版本至少需要 40 GB 余量。 - 企业网络中设置
no_proxy=registry.ollama.ai绕过代理直连。 - 下载后立即执行
ollama run <model> "test"做冒烟验证，而不是等到实际使用时才发现损坏。 - 定期用
ollama list结合ls -lh ~/.ollama/models/核对文件大小与模型列表是否一致。 - 下载超大模型时设置
OLLAMA_DEBUG=1环境变量，可以看到实际的分片下载进度，便于快速定位卡在哪个 blob。 - 如果网络不稳定，优先选 Q4_K_M 而非 Q8_0，文件体积减半可显著降低下载失败概率。
常见问答 (FAQ)
Q: pull 显示 100% 了但 ollama list 里没有这个模型，是怎么回事？
A: 这是 manifest 写入失败的典型表现。blob 全部下载完毕，但最后一步写 manifest 时空间不足或权限不够。检查 ~/.ollama/models/manifests/ 下是否有对应文件；若没有，删掉 blob 重新 pull。
Q: 重试 pull 时是从断点续传还是重头下载？ A: Ollama 使用 content-addressable 存储，每个 blob 独立校验。已经校验通过的 blob 不会重下，只会续传或重下失败的分片。但如果 blob 文件被部分写入且大小不对，Ollama 会删掉重下。
Q: 可以同时 pull 多个模型吗？ A: 可以，但不推荐。多个 pull 会争夺带宽和磁盘 IO，更容易触发超时。建议串行下载，或者在 pull 完成并验证后再开始下一个。
Q: 公司代理只允许 80/443 端口，但 pull 总是失败，有什么办法？
A: Ollama 的注册表走标准 HTTPS（443 端口），理论上应该可以通过代理。问题通常是代理对长时间连接做了强制断开。可以联系网络管理员将 registry.ollama.ai 加入直连白名单，或者在家庭网络下载后通过 ollama create 本地导入。
相关阅读
- Ollama 探测不到 GPU，全跑在 CPU
- Ollama pull 成功但 list 看不到
- Ollama 启动报 port already in use
- 本地模型冷启动后首 token 极慢
- LM Studio 加载模型时显存 OOM
标签: #local-llm #ollama #排查