ollama pull 卡住/超时（官方 registry 国内直连不稳定）

Q: 会遇到什么问题？

装好 ollama 后跑 ollama pull qwen2.5 ，转圈几十分钟没动静，或直接报连接超时；模型一个都拉不下来。你以为是命令写错或模型不存在——其实是 官方模型 registry 国内直连不稳定 ，不是命令问题。 本文路径： 快速修复 （30 秒一段命令）→ 一步步排查 （可跳读）→ 原理与变体 （症状/原因/证据）。赶时间直接跳到「快速修复」。

Q: 怎么快速修复？

一键：ModelScope 下载 GGUF → ollama create 导入（模型名示例 qwen2.5:0.5b） curl sL o /tmp/qwen2.5 0.5b instruct q4 k m.gguf https://modelscope.cn/models/Qwen/Qwen2.5 0.5B Instruct GGUF/resolve/master/qwen2.5 0.5b instruct q4 k m.gguf && ollama create qwen2.5:0.5b f <<EOF FROM /tmp/qwen2.5 0.5b instruct q4 k m.gguf EOF

Q: 怎么确认修好了？

ollama list 列表出现导入的模型即成功。实测输出形态：ModelScope 下载 491MB/58.5s → ollama create success → 模型出现在列表。

快速修复

# 一键：ModelScope 下载 GGUF → ollama create 导入（模型名示例 qwen2.5:0.5b）
curl -sL -o /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf https://modelscope.cn/models/Qwen/Qwen2.5-0.5B-Instruct-GGUF/resolve/master/qwen2.5-0.5b-instruct-q4_k_m.gguf && ollama create qwen2.5:0.5b -f - <<EOF
FROM /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf
EOF

你会遇到什么

装好 ollama 后跑 ollama pull qwen2.5，转圈几十分钟没动静，或直接报连接超时；模型一个都拉不下来。你以为是命令写错或模型不存在——其实是官方模型 registry 国内直连不稳定，不是命令问题。

本文路径：快速修复（30 秒一段命令）→ 一步步排查（可跳读）→ 原理与变体（症状/原因/证据）。赶时间直接跳到「快速修复」。

为什么会这样

ollama 默认从官方 registry（ollama.com / registry.ollama.ai）拉模型，国内网络直连该域名不稳定（实测：官方 registry 直连超时）。模型文件单个 4~70GB，传输中途断掉重来更难受。

正确路径（本市场实测）：从 ModelScope（国内可达）下载 GGUF 文件，再用 ollama create 导入——绕开官方 registry。

2026-08-29 实测：qwen2.5-0.5b-instruct-q4_k_m GGUF 491MB 下载 58.5s + create 导入成功 + CPU 冒烟通过（证据：实测复现日志（2026-08-29））。

ollama pull 的链路是「CLI → registry 寻址（ollama.com/registry.ollama.ai）→ 按 digest 拉取各层 blob → 写入 blobs/ 并生成 manifests/ 索引」——registry 域名直连不稳时，连接在传输层就失败；模型单文件 4~70GB，中途断掉要从头重来。

GGUF 导入路径绕开的正是「registry 寻址」这一环：ollama create 直接消费本地 GGUF 文件，计算 digest、写入 blobs/、生成 manifest——下载环节换成国内可达的 ModelScope，导入环节不碰网络。

确定性推论：ollama pull 卡住先确认是 registry 域名问题（curl -I https://registry.ollama.ai）而不是命令问题；GGUF 导入后 ollama list 出现即成功，模型与 pull 来的在运行层面等价（都是 manifest+blob）；

后续 ollama run 不再需要网络，离线可用。

一步步来

1. 确认是网络不是命令 — 必做（先排除服务/命令问题）

ollama list

服务正常但 pull 卡住/超时 → 网络问题；换 ModelScope 路径。

2. 从 ModelScope 下载 GGUF — 必做（下载前先 `df -h /` 确认磁盘）

curl -sL -o /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf https://modelscope.cn/models/Qwen/Qwen2.5-0.5B-Instruct-GGUF/resolve/master/qwen2.5-0.5b-instruct-q4_k_m.gguf

实测：491MB / 58.5s（2026-08-29，校园网可达）。下载前先确认磁盘够：df -h /。

3. 用 ollama create 导入 — 必做

ollama create qwen2.5:0.5b -f - <<EOF
FROM /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf
EOF

（Modelfile 也可写成文件再 -f ./Modelfile。）

4. 验证并运行 — 必做（验收）

ollama list && ollama run qwen2.5:0.5b "你好"

能列出模型、能出回答即成功（实测：create success + CPU 冒烟通过）。

怎么确认修好了

ollama list

列表出现导入的模型即成功。实测输出形态：ModelScope 下载 491MB/58.5s → ollama create success → 模型出现在列表。

什么时候不需要这个解法

这个解法解决的是「官方 registry 国内直连不稳」；如果你的网络能直连，直接用 ollama pull 更省事，不用绕 GGUF 导入。

能直连官方 registry 时：curl -I https://registry.ollama.ai 通（返回 200/301）——直接 ollama pull，GGUF 导入是绕路。
要精确版本组合时：GGUF 导入需要自己找对应文件，官方 pull 的 digest 映射更可靠；没有镜像源问题就别换路径。
已在容器里跑 ollama 时：容器镜像通常内置 registry 配置，先试镜像内 pull，比在宿主机 GGUF 导入快。

不确定？先跑 curl -I https://registry.ollama.ai——通就走官方，不通再走本文路径。

其它环境的表现

环境	说明
官方 registry 直连	实测超时，别硬等
ModelScope GGUF	实测 491MB/58.5s 可用（qwen2.5-0.5b-instruct-q4_k_m）
HF 镜像	hf-mirror.com 等可达时同样可下 GGUF 再导入（未实测）
磁盘	模型 4~70GB，先 `df -h /` 确认
LLaMA-Factory 微调	模型获取可走同路径（ModelScope GGUF），微调组合见 combo-local-llm-finetune
代理设置	用户环境变量 http_proxy 对 ollama 下载可能不生效（ollama#15358 外部报告 ignores http_proxy，未本地复现）；代理需注入 ollama serve 进程（systemd `Environment="HTTPS_PROXY=..."`）
网络抖动中途断掉	传输中断后直接重跑 `ollama pull`：已下载的分片写入 blobs/ 会复用、从断点继续（机制核对，未实测）；多次重试仍断再换 ModelScope GGUF 路径
模型名不存在	报 `pull model manifest: ... not found`——是模型名/标签拼写或不存在，不是网络问题；先到 ModelScope / HuggingFace 核对准确模型名
LLaMA-Factory 微调	模型获取可走同路径（ModelScope GGUF），微调组合见 combo-local-llm-finetune

症状

ollama pull 失败的常见形态：

# 形态 1：卡住无进度 / 连接超时（registry 直连不稳）
ollama pull qwen2.5
# 转圈几十分钟没动静，或 Error: ... dial tcp ... i/o timeout

# 形态 2：大文件传输中途断掉
# 下载到一半报 unexpected EOF / connection reset

# 形态 3：模型名不存在（不是网络问题）
Error: pull model manifest: ... not found

同族但根因不同（别在本页死磕网络）：

pull model manifest: ... not found → 模型名/标签拼写错或不存在，先到 ModelScope / HuggingFace 核对名称；
no space left on device（下载/导入阶段）→ 模型 4~70GB，先 df -h / 确认磁盘；WSL 下 df 有空间但写不进是宿主盘满，见 wsl-no-space-left。

原因

官方模型 registry（ollama.com / registry.ollama.ai）国内直连不稳定，大模型文件传输中途失败。

解法

从 ModelScope 下载 GGUF：curl -sL -o /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf https://modelscope.cn/models/Qwen/Qwen2.5-0.5B-Instruct-GGUF/resolve/master/qwen2.5-0.5b-instruct-q4_k_m.gguf。
`ollama create qwen2.5:0.5b -f - <<EOF

FROM /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf EOF` 导入。

ollama list 确认，ollama run 验证。

验证证据

实测（2026-08-29，WSL Ubuntu，ollama 0.33.2 隔离环境）：ModelScope 下载 qwen2.5-0.5b-instruct-q4_k_m GGUF（491MB，58.5s）→ ollama create success → CPU 冒烟通过（实测复现日志（2026-08-29））。

适用工具（1）

本问题方案已挂到下列工具的方案页——从工具页也能回到这里，双向可达。

ollama

成套方案（组合包）

这个问题包含在下列成套安装方案中。

来源与证据

收录 2026-08-30验证 ✓ 实测验证适用 1 工具

方案含本地实测或来源可复核的解法；未实测项已在文中如实标注。

这条方案对你有用吗？

反馈由维护 Agent 汇总，用于重测排期与方案改进；匿名，不收集任何个人信息。

← 大模型本地部署问题域｜问题货架｜遇到其它问题？去问题空间提交求助卡