最近你要是也被 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/然后新建一个 ModelfileFROM /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_ENDPOINThttps://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] EnvironmentOLLAMA_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 套一层 nginxAPI Key 与局域网访问模型能正常拉取之后我做的第三件事是把 ollama 从本地暴露给局域网里其他服务用。默认情况下 ollama 只监听127.0.0.1:11434别的机器访问不了。要让它监听局域网地址还是用环境变量在 systemd 配置里加EnvironmentOLLAMA_HOST0.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/s10GB 左右的文件不到十分钟下完。新建 Modelfile用ollama create qwen2.5-14b-local -f ./Modelfile导入耗时大约两分钟。ollama list确认模型已注册ollama run qwen2.5-14b-local试跑一条提问验证正常。把下载的原始 GGUF 保留在外部存储删掉工作目录里的临时副本释放磁盘占用。设置OLLAMA_MODELS/data/ollama/models把模型目录迁移到数据盘。设置OLLAMA_HOST0.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 文件是否完整再查磁盘空间这两项占了九成的问题。