ollama pull 卡住不是「网络不好」四个字能概括的装完 Ollama，第一件事都是拉一个模型下来试试。然后你大概率会看到这行东西停在那里不动：
pulling manifest
或者进度条走到 30% 就再也没动过，一停二十分钟。这时候网上一搜，答案高度统一：「挂代理」「换镜像」「用国内加速」。这些答案不算错，但它们默认了一个前提——你卡住的原因和你看到的那篇帖子一样。实际上 ollama pull 慢或卡，至少有四个完全不同的成因，位置不同，解法互相不通用：
一是元数据请求出不去，卡在 pulling manifest 这一步，连要下多少东西都还没算出来；二是能下但单连接速度起不来，进度条在动，只是慢；三是下到一半断了要重来，看起来像「越下越慢」；四是下完了却起不来，报显存或格式错误，跟下载已经没关系了。
这篇不给你一堆镜像地址（那东西几个月就失效一批，给了等于没给），给的是：怎么用一分钟判断自己卡在哪一层，每一层的可验证做法是什么，以及哪些「加速方案」是不该碰的。
先说一个机制上的好消息：Ollama 的模型是按内容寻址存的。同一份权重不管你从哪个模型标签拉，磁盘上只存一份；也正因为如此，把整个模型目录拷到另一台机器，比重新下载快得多，而且不需要联网。这一点是后面「离线导入」那条路的基础，理解了它，你就不用再求人了。
ollama pull 到底在干什么一次 ollama pull 分两步：先取 manifest（清单），再按清单取 blobs（实际数据块）。
manifest 是一个几百字节到几 KB 的 JSON，放在 manifests/registry.ollama.ai/library/<模型名>/<标签> 这个路径下；它里面记着这个模型由哪几个层组成、每层的 sha256 digest 和大小。blobs 存在同级的 blobs/ 目录里，文件名就是 sha256-<digest>。默认根目录是：
Windows: %USERPROFILE%\.ollama\models
Linux: ~/.ollama/models
macOS: ~/.ollama/models
想看自己的到底存在哪、存了多少，直接问它：
ollama list # 本地已有模型与体积
ollama show <模型名> # 单模型的结构、参数量、量化方式
ollama show --modelfile <模型名> # 它的 Modelfile，能看到 FROM 指向哪一层
为什么这个结构重要？因为它解释了两件常被误解的事。
第一，pulling manifest 卡住跟「模型多大」无关。 这一步只是一个 HTTPS 请求，几 KB 的响应。它会卡，只有一种原因：到 registry 的请求没通。所以看到它停住时，别去算「7B 模型多少 GB 要下多久」——你连一个字节的权重都还没开始下。
第二，进度条上的百分比是按层算的，不是按整个模型算的。 一个模型通常由若干层组成，有的层几百 MB，有的只有几 KB。所以你看到 87% 停很久，很可能是在下最后一个大层，不是卡死。
Ollama 默认的终端输出信息很省。要看它到底在干什么，把 debug 打开。Windows 上日志文件在 %LOCALAPPDATA%\Ollama\server.log，Linux/macOS 在 ~/.ollama/logs/server.log。
# Windows PowerShell：看最近 40 行日志，找 pull 相关记录
Get-Content "$env:LOCALAPPDATA\Ollama\server.log" -Tail 40
# Linux / macOS
tail -n 40 ~/.ollama/logs/server.log
日志里能直接看出来的东西，比进度条多得多：请求打到哪个域名、有没有超时、第几层开始重试、有没有 digest 校验失败。这一步是分层的唯一依据——没有日志，你只能靠现象猜；有了日志，成因是写在里面的。
pulling manifest——请求根本没出去这是最常见的一种，也最容易被误判成「模型太大」。判别方法很简单：如果超过一两分钟连清单都没取到，那就跟带宽无关。
按成本从低到高排：
先测 registry 通不通。 别用浏览器打开首页来判断，要测的是 API 端点能不能返回：
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://registry.ollama.ai/v2/
返回 200 或 401 都算「通」（401 是没带凭据，正常）；超时或连不上，就是链路问题。这一步能立刻把「网络问题」和「Ollama 自身问题」分开。
再确认代理变量进的是「哪个进程」。 这是 Windows 上最容易踩的坑：Ollama 在 Windows 上通常是托盘程序常驻，它继承的是启动它那一刻的环境变量。你在 PowerShell 里 set HTTPS_PROXY=... 然后重开一个终端跑 ollama pull，那个变量对已经跑着的后台服务没有任何影响。
正确做法是：把 HTTPS_PROXY（必要时加 HTTP_PROXY 和 NO_PROXY=localhost,127.0.0.1）设成用户级环境变量，然后从托盘完全退出 Ollama 再重新启动。判断有没有生效，看新日志里请求的时间戳变化，而不是看设置界面。（来源：Ollama 官方文档与 GitHub 仓库中关于代理环境变量的说明，docs.ollama.com；同类「Windows 托盘程序不继承新环境变量」的问题在 github.com/ollama/ollama 的 issues 里反复出现。）
最后才考虑换 registry。 社区里流传把 registry 指到某个镜像的做法，可行，但我明确不建议把它当第一选择：镜像的可用性、完整性和来源都无法验证，而模型权重是要在你机器上执行的代码资产。（传闻：部分第三方镜像存在层被替换或标签错配的情况，下载后 digest 对不上导致反复重试。）真要换，至少保证换完 ollama show 出来的结构和官方一致，并且记住改了什么，出问题时能改回去。
如果日志显示层在稳定下载，只是速度低，先做一道算术题，别凭感觉：
用模型体积除以你实测的速度，得到预期耗时。比如一个 4~5 GB 的量化模型，在 2 MB/s 的链路上就是 35~40 分钟——这个时间是「正常」，不是「卡住」。很多人在这四十分钟里反复 Ctrl+C 重来，结果是每次都从头开始，永远下不完。
真正该怀疑「有问题」的是这两种表现：
第二种尤其说明问题——速度对链路不敏感，通常意味着瓶颈不在你的出口带宽，而在到 registry 的那一段路由，或者中间有设备在做限速/干扰。这种情况下继续等意义不大，直接跳到下一段的第三条路。
顺便说一个反直觉的点：并行下载并不总是更快。Ollama 对层是逐个取的，单层是单连接。指望「多开几个 pull 同时下」来提高总速度，在不同模型之间反而会互相抢带宽，而且层是共享的——两个模型共用同一层时，先下完的那个会把这个层落到磁盘上，后一个瞬间跳过，这算是个意外收益，但不该被当成加速手段。
断点续传这件事要看断在哪。 正常的下载中断（关终端、休眠）之后重新 ollama pull，它会校验已落盘的部分并接着来，不会白下。但有两种情况会让它重来：一是 blobs/ 里留下了不完整的临时文件而校验一直不过，二是你手动清理了 .ollama 目录里的东西「想清点空间」。
所以清理前先看清楚：blobs/ 下的文件就是模型本体，删了等于删模型。要腾空间，正确做法是把整个 models 目录迁走，而不是删里面几个大文件。迁移用环境变量指路：
# 把模型目录迁到 D 盘（Windows，用户级环境变量）
setx OLLAMA_MODELS "D:\ollama-models"
# 迁完必须完全退出托盘程序再启动，否则它还按旧路径找
ollama list
（实测：改完 OLLAMA_MODELS 但不重启托盘程序，ollama list 仍然是空的——因为后台服务还在用启动时读到的旧路径。这一步不重启，等于没改。）
下完了却报错，通常已经不是下载问题。 典型两类：一类是内存/显存不够，日志里会明确说加载失败或需要更多内存；另一类是格式或量化不匹配。前者要在模型规格和量化等级上做取舍，怎么算自己机器能吃多大，站内有一篇把显存和量化档位对起来的，比这里展开更细：开源 OpenCode 模型微调需要多少显存？最低配置推荐 + 四套预算方案。
排完上面三种情况，解决方案其实只有三条。我把它们按确定性排序，而不是按流行度：
第一条，把请求弄通（改代理/网络）。 确定性最高，因为问题定位清楚——日志里有超时、curl 测不通。代价是你要处理「环境变量进的是哪个进程」这件事。做完用 curl 复测同一个端点，通了就是通了。
第二条，离线导入，完全不依赖网络。 确定性第二高，适合两种情况：一是链路怎么调都慢，二是你有多台机器要装同一个模型。
如果手上是 GGUF 文件，写一个 Modelfile 再 create 就行：
# Modelfile
FROM ./Qwen2.5-7B-Instruct-Q4_K_M.gguf
PARAMETER temperature 0.7
PARAMETER num_ctx 8192
# 然后
ollama create qwen25-7b-local -f Modelfile
ollama run qwen25-7b-local
如果另一台机器上已经有这个模型，更省事的路是直接拷目录：把 models/ 下的 blobs 和 manifests 一起复制过去（保持相对结构），目标机器设好 OLLAMA_MODELS 指向它，重启后就 ollama list 能看见。这就是前面说的内容寻址带来的好处——不需要「导出」「导入」这种仪式，文件到位就等于装好了。
第三条，换更小的模型或更低的量化。 这不是「降级妥协」，很多时候是更正确的选择。在只有 CPU 或小显存的机器上跑一个 7B 的 Q4 量化，体验通常好过一个 14B 的 Q2——后者不仅慢，质量还经常更差。选模型这件事，参数量的边际收益远没有想象中大，先跑通再谈上限。
写这段是因为这些做法在中文教程里流传很广，而它们的共同点是「看起来有效，实际在拿别的东西换」：
别装所谓「Ollama 加速器」。 这类工具的做法多半是改 hosts、塞一个来路不明的 registry，或者常驻代理进程。前两种会让 digest 校验失败变成常态，第三种则把你所有请求交给一个不透明的中间人。你的模型权重是被执行的，不是被浏览的。
别用 --insecure 之类跳过校验的选项。 如果校验过不去，说明数据确实不对，跳过校验只是把问题推迟到运行时。
别在下载途中反复 Ctrl+C。 每次中断都要重新校验已有分片，频繁打断的净效果是更慢。要么让它跑完，要么彻底停掉换个方案。
别把 OLLAMA_HOST 设成 0.0.0.0 就以为「方便局域网用」。 这等于把一个无鉴权的推理接口暴露到网络里。要共享，至少限定在可信网段，并想清楚谁能访问。
给个明确态度，省掉一些人的时间。
适合：有独立显卡（哪怕是入门级）、主要用途是隐私敏感文本、或者需要离线可用；愿意为「可控」付出配置成本。
不适合：只想试试大模型效果、机器是轻薄本、网络本身就不稳定。这三类人去用在线 API，成本低得多——你为了省几十块 API 费用，花三个晚上调一个下载问题，账是亏的。
顺带说一句：本地跑通之后，最常见的下一个问题是「服务在但连不上」。那是端口和监听地址层面的排查，跟下载无关，站内这篇讲得很清楚，别混着查：Ollama 连不上 11434 端口，connection refused 怎么排查？2026 分层排查顺序。如果你是从零开始搭，先按完整部署流程走一遍再来调下载，顺序反了会多出很多假问题：本地部署大模型实战：Ollama + Open WebUI 完整教程。
pulling manifest 卡 >2 分钟 → 请求没出去 → curl 测 /v2/ → 查代理是否进了服务进程
进度在动但 <100KB/s → 链路问题 → 换网络复测，仍不变则走离线导入
同层反复归零 → 分片校验失败 → 清掉该层的临时 blob 重下，别清整个目录
下完报内存/加载失败 → 规格不匹配 → 降参数量或降量化，参考显存对照
多台机器要装同一模型 → 不必重复下载 → 拷 blobs + manifests，设 OLLAMA_MODELS
这张表的价值在于：每一行的动作都是可验证的。curl 有没有返回、日志里有没有变化、ollama list 有没有出现——你看得见结果，就不用靠「好像快了一点」来判断有没有修好。
最后提醒一句：如果日志里显示请求全都正常、层也在稳定落盘，只是总时间比预期长，那它不是故障。大模型就是几个 GB 的东西，在普通家宽上花半小时到一小时是常态。真正的问题不是慢，是不知道自己在等什么——知道在等哪一层、等多久算正常，这件事本身就把焦虑解决掉了。