windows ollama pull 加速

在 Windows 上敲 ollama pull，进度条卡住不动、或者几十 KB 每秒磨半天，多半不是模型太大，而是连接 registry 那一段不稳。这篇不聊模型选型，只解决「怎么把权重顺利落到本地」这一件事：先分清楚卡在哪一步，再按换源、走代理、离线搬运三条路依次试，最后给一套下次换模型的排查顺序。

在 Windows 上敲 ollama pull，进度条卡住不动、或者几十 KB 每秒磨半天，多半不是模型太大，而是连接 registry 那一段不稳。这篇不聊模型选型，只解决「怎么把权重顺利落到本地」这一件事。

思路很简单：先分清楚卡在哪一步，再按换源、走代理、离线搬运三条路依次试，最后给一套下次换模型的排查顺序。三条路不是随便挑，而是有先后——上一条走不通再走下一条，能省掉大量瞎折腾。

先判断卡在哪一步，别上来就换源

同样是「慢」，成因差别很大。先看现象，再决定要不要动环境变量，否则容易改成另一个更糟的状态。

看 ollama 服务端日志和命令行输出，确认是 DNS/连接阶段慢还是传输阶段慢。用站内的接口测速先量一条本机到外网的延迟与带宽基线，避免把本机网络问题误判成源的问题，到 /tools/speed-test 跑一次就有底了。

换源：把默认 registry 指到国内可达的镜像

Ollama 走的是 OLLAMA_HOST 之外的另一套地址，换源要改的是 registry 相关环境变量，不是 host 变量，两者别混。改错了会表现为服务起不来或者命令连不上本地服务。

1. 确认改哪个变量认准 registry / mirror 相关的那一个，不要顺手把 OLLAMA_HOST 一起改了
2. 写入系统环境变量用系统环境变量面板或 setx 写入，改完必须重启 Ollama 服务或托盘程序才生效，只重开终端没用
3. 小模型验证连通先用一个小体积模型验证连通性，再拉你要的大模型，避免大文件下到一半才发现源不对
4. 记录改了什么把变量名和值记一条备忘，出问题时能快速回退

走代理与断点续传：拉大模型时的稳定性

代理要同时覆盖命令行和服务进程。只给终端设代理而 Ollama 后台服务没走代理，是很常见的白忙一场——命令行走通了，实际下载的那个进程还在裸连。

• 给终端设代理后，确认服务进程也继承了同样的变量，或者干脆在系统级设置
• 下载中断后重新 pull 通常会复用已下载的分层，不必删目录重来；反复失败再考虑清掉对应模型的半成品目录
• 一次只拉一个模型，多个 pull 并发会互相抢带宽，表现就是每个都很慢
• 拉之前先看一眼磁盘剩余空间，别等下到一半才发现盘不够，到 /models 核对模型体积和占用

离线搬运：网络实在不行时的兜底方案

前面两条都走不通，就用最笨但最稳的办法：在能正常拉取的机器上把模型拉全，再整目录拷到目标 Windows 机器的模型目录下。路径规则到站内模型路径相关页面核对，别凭记忆猜。

搬运前

源机器上先 ollama list 确认模型完整可用，别拷一个半成品

拷贝时

整目录拷，保持目录结构不变；Windows 上用资源管理器直接拷大目录容易中断，能压缩就先打包

拷贝后

目标机器先 ollama list 看能不能识别，再跑一次最小推理确认权重完整

判断标准

能 list 出来不代表能用，必须真跑一次推理再用于生产

下次换模型时的排查顺序清单

把下面这个顺序固定下来，每次只改一个变量，改完重启服务并记录。这样出问题能立刻定位是哪一步引入的，而不是全盘推倒重来。

1. 确认服务在跑托盘图标或服务状态正常，命令行能列出已有模型
2. 测本机带宽基线到 /tools/speed-test 量一次，排除本机网络问题
3. 验证源可达确认 registry 地址能连通，必要时换源后重启服务
4. 拉小模型试通用一个小体积模型跑通全流程，确认下载和加载都正常
5. 拉目标模型最后再拉真正要用的那个，期间不要再并发别的 pull

拿不准当前模型体积和磁盘占用时，到 /models 和部署测算页面核对，别等下到一半才发现盘不够。常用模型的拉取方式记成一条本地备忘，下次直接照做，省掉重新试错的时间。

慢不一定是源的问题，先量基线、再改一个变量，比一次改五个环境变量管用得多。