最近你要是也被 ollama 的下载进度条折磨过，那这篇应该能帮你省下至少半个下午。前几天我在一台新机器上装本地大模型，ollama pull qwen2.5:14b跑了四十分钟，进度条卡在 17% 附近不动，终端里刷的全是read tcp i/o timeout。后来折腾了手动下载 GGUF 再导入、迁移模型存储目录、加 nginx 前置认证，总算把整套流程跑通了。
这篇文章就是这次排障的完整记录，顺手把网上那些“ollama 国内镜像源”的说法也说清楚。适合正在被模型下载慢卡住，或者准备在公司内网、实验室里部署私有大模型，但不想在“拉模型”这一步浪费时间的人。
先说结论：ollama 目前没有一个类似pip换清华源、docker换 registry mirror 那样的“模型仓库镜像开关”。所以如果你搜了一堆“国内镜像源”还是没解决，不是你的姿势不对，是 ollama 压根没给你开这扇门。真正能落地的路径只有两条：换一个国内可达的下载源手动把模型文件拉回来，再离线导入；或者想办法让官方域名在国内能连得通。后者需要基础设施配合，普通人最稳的还是前者。
1. 慢到想骂人不是错觉：ollama 拉模型走的哪条路
1.1 一条 pull 命令背后发生了什么
ollama pull看起来是一句命令，实际过程分两步。
第一步是拉取 manifest。ollama 会先访问registry.ollama.ai，把这个模型对应的配置文件拿下来，里面写清楚了这个模型由哪些层（layer）组成、每个层的 sha256 校验值、文件大小和格式。manifest 本身很小，也就几 KB 到几十 KB，但它决定了后续所有数据块该往哪里存。
第二步才是真正的大头，根据 manifest 里的地址逐块拉取模型文件。这些文件在官方存储里被切成很多个 blob，下载完成后 ollama 会按 sha256 重新组织成可加载的模型。你看到终端里的pulling xxx... 100%，就是这个过程。
问题就出在这里：manifest 和模型大文件都放在官方 registry 的海外存储节点上。国内直连这个节点的路由质量波动很大，TCP 握手超时、TLS 握手中断、传输中断都是家常便饭。加上大模型动辄几个 GB 到十几 GB，稍微丢包重传一下，实际有效速度就被打骨折了。你看到的“慢”，很多时候不是带宽不够，是连接根本不稳定，一直在断线重连。
1.2 先分清卡在 manifest 还是卡在大文件
这是排查时第一个要判断的事，但大部分人都会忽略。
如果你执行ollama pull之后，长时间停在pulling manifest这一行，说明你连 manifest 都没拿到。这个阶段不需要下载任何大文件，纯粹是网络握手和 DNS 的问题。这时候你盯着进度条是没用的，因为 manifest 阶段不显示百分比。
如果你已经看到类似pulling 1234abcd5678... 3%这种内容，说明 manifest 已经拿下来了，卡的是模型数据本体。这种情况下网络链路是通的，只是速度太慢，进度条偶尔还会往回跳，那是 TCP 超时重连后的表现。
两个阶段对应的处理思路不一样：
- 卡 manifest 阶段：先检查 DNS 解析是否正常，
ping registry.ollama.ai、curl -I https://registry.ollama.ai/v2/看看握手能不能通。经常是解析出来的 IP 不稳定，或者连接受阻。 - 卡大文件阶段：这是绝大多数人的情况，解决思路就是后面要说的离线导入。
另外说一句：ollama pull本身支持断点续传。中途断了不要慌，重新跑同一条命令，它会从已下载的 blob 继续，不会真的从头再来。所以不要因为断了一次就删掉~/.ollama/models里的东西，那是自己给自己加戏。
1.3 它为什么没有 pip/npm 那种“官方换源”开关
用过pip的人都知道，pip install -i https://pypi.tuna.tsinghua.edu.cn/simple一行命令就换源了。docker也能在 daemon.json 里配registry-mirrors。
但你翻遍 ollama 官方文档，找不到一个“registry mirror”配置项。这是 ollama 的设计选择，它把模型管理做得更“包管理化”，而不是“源切换化”。ollama pull拿到的模型最终会被打散成 blob，有自己的校验逻辑和 manifest 结构，不是简单地把一个 GGUF 文件挪到固定目录。所以网上那种“给 ollama 配国内镜像”的教程，要么是在教你把域名解析到自建缓存机器（这个后面说），要么干脆是把“模型存储路径”和“模型下载源”两件事搞混了。
搞清楚这个底层逻辑，你就不会再浪费时间到处找不存在的开关了。
2. 先把能落地的方案讲了：手动下载 GGUF 再离线导入
2.1 准备一台国内速度正常的模型文件源
我最终选择的方案，是把模型文件放在国内可达的仓库里下载，然后再导入 ollama。
第一步是拿到 GGUF 格式的模型文件。ollama 底层用的就是 GGUF，你从网上找对应模型的 GGUF 版本，下载回来就能直接用。两个比较靠谱的渠道：
- Hugging Face 的国内镜像站
hf-mirror.com：支持直接复制文件的 resolve 链接，然后用wget断点续传。 - ModelScope 魔搭社区：阿里系平台，国内下载速度通常能跑满带宽，上面有不少模型作者上传的 GGUF 版本。
举个例子，我想用 Qwen2.5 14B，就在 hf-mirror 上找到Qwen/Qwen2.5-14B-Instruct-GGUF这个仓库，选择qwen2.5-14b-instruct-q5_k_m.gguf这个量化文件。q5_k_m 是容量和效果比较平衡的量化档位，14B 模型大概 10GB 出头，显存 16G 的卡能跑。
下载命令类似：
wget -c https://hf-mirror.com/Qwen/Qwen2.5-14B-Instruct-GGUF/resolve/main/qwen2.5-14b-instruct-q5_k_m.gguf-c参数是断点续传，网络断了重跑一遍就能接着下。当时我这里是稳定在 20~50MB/s，不到十分钟就下完了。
这里提醒一句：模型文件不是随便找个仓库下的。尽量去模型官方账号或者大机构镜像仓库下，核对一下文件大小。GGUF 文件如果被人篡改过，导入进去之后模型输出什么你都控制不了，等于往系统里塞了一个不可信的黑盒。有条件的话，看一下仓库里有没有 sha256 校验文件，下载完对比一下再导入。
2.2 用 Modelfile 把 GGUF 注册成 ollama 模型
拿到 GGUF 之后，ollama 并不能直接识别这个裸文件，需要写一个 Modelfile 告诉它“这个文件是模型、叫什么名字、用什么提示词模板”。
过程很简单：
mkdir -p ~/models # 把下载好的 GGUF 放到这个目录 mv ~/Downloads/qwen2.5-14b-instruct-q5_k_m.gguf ~/models/然后新建一个 Modelfile：
FROM /root/models/qwen2.5-14b-instruct-q5_k_m.gguf TEMPLATE """{{- if .System }}<|im_start|>system {{ .System }}<|im_end|> {{- end }} <|im_start|>user {{ .Prompt }}<|im_end|> <|im_start|>assistant """ PARAMETER temperature 0.7这里的 TEMPLATE 要跟模型本身配套。不同模型的提示词模板不一样，Qwen 系列是<|im_start|>这套，Llama 3 系列是<|begin_of_text|>开头那套。搞不清楚的话有个取巧的办法：先拉一个同系列的小模型，比如ollama pull qwen2.5:0.5b，然后用ollama show --modelfile qwen2.5:0.5b把官方模版抄出来，把里面FROM那一行换成你自己的 GGUF 路径就行。
最后执行导入：
ollama create qwen2.5-14b-local -f ./Modelfile这个过程大概几十秒到几分钟，取决于你的磁盘速度。ollama 会把 GGUF 文件重新组织成 blob 存进模型目录。
2.3 导入后的验证与临时文件清理
导入完成不代表一定能跑，先验证。
ollama list你应该能看到qwen2.5-14b-local这一条。然后直接跑：
ollama run qwen2.5-14b-local输入一句话，能正常生成就说明导入成功。
这里有个磁盘空间的坑：导入过程中，ollama 一般会把 GGUF 复制或转换到自己的 blob 目录，所以整个操作前后，你的磁盘可能需要容纳“原始 GGUF + 导入后的模型”两份体积。建议准备两倍模型大小的空闲空间再操作。导入成功并确认没问题之后，~/models/下的原始 GGUF 就可以删掉，或者如果你打算以后再重新导入，搬到冷存储里也行。
3. “国内镜像”的真实身份：哪些能用，哪些是坑
3.1 镜像加速在 ollama 里的边界在哪里
网上搜“ollama 国内镜像源”会出来一堆文章，点进去你会发现，真正能用的其实没有。
有一种说法是“设置OLLAMA_MODELS环境变量指向国内镜像目录”——这是错的。OLLAMA_MODELS定义的是模型存储路径，不是下载源。你改了它，只是让模型换个地方放，下载速度一点都不会变。
还有一种是“用ollama run hf.co/用户名/仓库名直接从 Hugging Face 拉模型”。ollama 确实支持这种写法，但如果你访问 Hugging Face 本身都慢，这个功能也一样慢，解决不了你的问题。
真正让“镜像”这个词生效的场景，是 Hugging Face 的国内镜像。如果你的 ollama 需要从 HF 拉模型，可以把HF_ENDPOINT=https://hf-mirror.com配到 ollama 服务进程的环境变量里，这样hf.co/...前缀的模型请求会走镜像。但注意，这只能影响那部分模型，官方ollama pull的模型仍然走 registry.ollama.ai，两条路互不相干。
3.2 网上流传的 hosts 替换法与一键脚本为什么容易埋雷
还有一种更野的路子：改系统 hosts 文件，把registry.ollama.ai解析到某个“据说很快”的 IP 上。理论上如果那台机器有完整的模型缓存，速度确实能起飞。但这玩意儿本质上是在赌第三方机器的可靠性和安全性：
- 今天能用，明天可能就失效，你得反复改 hosts；
- 对方如果是个人维护的缓存节点，模型文件被替换了你根本察觉不到；
- 有些一键脚本会把你的 hosts 改得乱七八糟，卸载都不好卸载。
我的建议是别碰这条线，尤其是生产环境，一次异常的模型来源就可能让你的整个私有大模型服务变得不可信。
3.3 和 LM Studio、vLLM 的下载机制做个对比
理清楚 ollama 的边界之后，顺便说说它跟其他工具的区别，因为好多人会拿 LM Studio 的经验套用到 ollama 上。
LM Studio 的模型下载走的是 Hugging Face，所以它支持配置 HF 镜像源，改了之后下载确实能提速。但是 LM Studio 对模型的管理不如 ollama 这么“blob 化”，更像“把文件下载到本地模型目录”的朴素逻辑。
vLLM 和 sglang 这类推理框架就更直接了，它们通常不提供“pull 模型”的功能，而是直接用你本地已有的模型文件路径启动服务。比如 vLLM 启动时给个--model /data/models/Qwen2.5-14B-Instruct，模型文件需要你自己准备。
所以这三个东西不能混着用：LM Studio 的换源经验搬到 ollama 上是不成立的；vLLM 那种“自己准备文件”的思路倒是跟 ollama 离线导入很像，这也是为什么你搜 vLLM 部署教程时，几乎不会看到“下载慢”这个话题——因为下载过程被前置到你自己可控的环节了。
4. 提速之后才暴露的问题：模型盘爆了与前置网关
4.1 模型默认存系统盘，你怎么把它迁到数据盘
下载问题解决不代表万事大吉，我这边紧接着就遇到第二个问题：磁盘空间。
ollama pull默认把模型存在~/.ollama/models。如果系统盘本来就不大，一个 14B 模型 10GB+，再拉两个 32B 的模型，系统盘直接红了。很多人装了 ollama 之后发现df -h显示根目录占用突然暴涨，就是这个原因。
迁移有两种做法，任选其一。
第一种，设置OLLAMA_MODELS环境变量，把模型目录指到你想要的大分区：
sudo mkdir -p /data/ollama/models sudo systemctl edit ollama.service在打开的配置里加：
[Service] Environment="OLLAMA_MODELS=/data/ollama/models"保存后：
sudo systemctl daemon-reload sudo systemctl restart ollama注意，只在你自己的 shell 里export OLLAMA_MODELS=/data/ollama/models是没用的。ollama 服务进程根本读不到你 shell 里的变量，必须写到 systemd 服务配置里。
第二种做法是软链接：
systemctl stop ollama mv ~/.ollama/models /data/ollama/models ln -s /data/ollama/models ~/.ollama/models systemctl start ollama两种方法选一个就行，不要同时配，否则会把自己绕晕。
最后跑一下ollama list，确认模型还在，再用ollama run qwen2.5-14b-local简单试一句，确保迁移后能正常加载。
4.2 同时拉多个模型时真正需要监控的指标
我还见过有人为了“赶时间”，一次开四五个终端窗口同时ollama pull不同模型，结果所有进度条全部卡死，一个都下不动。这不是 ollama 不支持并发下载，而是并发一多，本来就一般的网络链路更容易触发超时重连，几路下载互相挤占，最后谁都没跑完。
我的建议是老老实实串行，一个模型下完再下下一个。如果你有多个必须下的模型，可以写个脚本：
#!/bin/bash for model in qwen2.5:7b qwen2.5:14b qwen2.5:32b; do echo "===== pulling $model =====" ollama pull "$model" done这样至少是“排队”，而不是“打架”。
另外一个很容易被忽略的监控点是磁盘 IO。模型文件很大，一边下载一边写入，如果机械盘速度跟不上，下载速度也会显得很慢。可以用iostat或者iotop看一眼磁盘在不在瓶颈，别一股脑全怪到网络头上。ollama ps可以看当前有哪些模型正在被加载，下载阶段它基本是空的，如果你看到某个模型一直挂在里面，说明服务还在跑推理任务，别急着重启服务。
4.3 给 ollama 套一层 nginx：API Key 与局域网访问
模型能正常拉取之后，我做的第三件事是把 ollama 从本地暴露给局域网里其他服务用。
默认情况下 ollama 只监听127.0.0.1:11434，别的机器访问不了。要让它监听局域网地址，还是用环境变量，在 systemd 配置里加：
Environment="OLLAMA_HOST=0.0.0.0:11434"重启之后，局域网里其他机器就能用http://你的IP:11434访问了。
但直接裸奔暴露服务不靠谱。虽然它本身没做什么鉴权，但只要你暴露到局域网，就有被扫描和滥用的风险。我习惯在前面加一层 nginx，把/v1路径转发到 ollama，并且在 nginx 层做简单的 API Key 校验。
一个最小可用的 nginx 配置长这样：
map $http_authorization $auth_result { default 0; "Bearer sk-ollama-local-2024" 1; } server { listen 8080; location /v1/ { if ($auth_result != 1) { return 401; } proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这样所有请求必须带Authorization: Bearer sk-ollama-local-2024，否则直接返回 401。比你直接暴露端口安全一个量级。
如果你是把 ollama 接给 Dify、Cherry Studio 这类平台用，填 API 地址的时候记住是http://你的IP:8080/v1，模型名填qwen2.5-14b-local这种你自己的命名，不要填成了模型文件的名字。Dify 里接入本地 Ollama 模型供应商时，Base URL 就是这样配置，模型列表刷新后能看到你离线导入的模型。
5. 完整踩坑复盘：从进度条卡住到最终跑通
5.1 我踩过的三个“看起来像解决方案”的弯路
第一个弯路是换存储路径。当时我以为是模型目录在系统盘导致写入慢，兴冲冲把OLLAMA_MODELS指到了数据盘，结果发现下载速度没有任何变化。这个坑前面已经说了，存储路径管不了下载源。
第二个弯路是找镜像源。我把网上流传的“ollama 国内镜像”帖子都翻了一遍，试了一个 hosts 替换脚本，也确实在短时间内看到速度上来了，但第二天就失效了，而且那个脚本在我系统里留了一堆自己写的 DNS 解析规则。最后手动清干净，再也不敢用这类东西。
第三个弯路是同时开多个 pull。我以为并行能提高总吞吐，结果四个窗口全部卡死，查看日志全是连接重置。后来改成脚本串行，反而顺利跑完。
这些弯路耗时加起来接近两个小时，比后面真正解决问题的时间都长。
5.2 最终操作序列与耗时记录
真正跑通的步骤整理如下，你可以直接照做：
- 找国内可达的 GGUF 文件源，我用的是 hf-mirror，下载 Qwen2.5-14B 的 q5_k_m 量化文件，速度稳定在 20~50MB/s，10GB 左右的文件不到十分钟下完。
- 新建 Modelfile，用
ollama create qwen2.5-14b-local -f ./Modelfile导入，耗时大约两分钟。 ollama list确认模型已注册，ollama run qwen2.5-14b-local试跑一条提问，验证正常。- 把下载的原始 GGUF 保留在外部存储，删掉工作目录里的临时副本，释放磁盘占用。
- 设置
OLLAMA_MODELS=/data/ollama/models，把模型目录迁移到数据盘。 - 设置
OLLAMA_HOST=0.0.0.0:11434，并配置 nginx 前置校验 API Key。
整个流程从下载到跑通，全算上不到一小时，比之前干等进度条四十分钟高效太多。
5.3 留给你的收尾检查清单
复盘之后我把自己日常部署 ollama 时的检查项整理成了一份清单，每次新装或者排障都按这个走一遍：
- 先判断卡点是 manifest 还是大文件阶段，别一股脑换源。
- 大文件慢，优先用 hf-mirror 或 ModelScope 手动下载 GGUF，再用 Modelfile 导入。
- 确认磁盘空间至少是模型体积的两倍，再进行导入操作。
- 确认
OLLAMA_MODELS指向了大分区，且环境变量真正写进了 ollama 服务进程。 - 如果需要局域网内其他服务访问，确认
OLLAMA_HOST配置正确，并建议在 nginx 层加 API Key 校验。 - 多模型下载时串行执行，不要并开一堆终端窗口。
- 下载完成后做一次模型输出验证，不要导完就放着不管。
我个人现在部署 ollama 私有大模型的习惯是：不管网络状况好不好，一律用“国内源下载 GGUF + 本地导入”这条路。虽然多了一步写 Modelfile，但整个过程完全是可控的、可断点的，也不依赖任何第三方缓存节点的稳定性。
这篇文章里提到的方法我已经在几台不同环境里验证过，包括全新 Linux 服务器和 Docker 部署的 ollama，只要模型文件本身能下载下来，导入流程基本不会出幺蛾子。真遇到导入后模型加载报错的，先查 GGUF 文件是否完整，再查磁盘空间，这两项占了九成的问题。