Ollama 没有像 pip、npm 那样一个环境变量就能切过去的公共镜像源，`ollama pull` 默认是从模型仓库按 blob 下载权重。所以「拉取太慢」通常落在三件事上：到模型仓库的网络路径不稳定、同一条大模型在多台机器或多次重建容器时被反复下载、磁盘写入或空间不足把下载拖住。可行的做法不是找一条「万能加速配置」，而是先把慢的原因分开，再用固定模型目录、本地 GGUF 导入、内网分发这几条路径减少重复传输。
Ollama 没有内置的镜像源开关，「镜像加速」实际指换一条可达的模型下载路径，或在本地复用已经拿到的权重。先判断慢在域名连通、带宽还是重复下载，再选固定 OLLAMA_MODELS、GGUF 本地导入或内网拷模型目录；改完用 ollama list、ollama show 和重新 pull 一次来验证；跨版本复制、属主不对、磁盘不足都会让操作失败，需要保留回退到默认模型目录的办法。
先确认当前场景和目标
先判断这个问题在你环境里是否真有优化空间。如果只是几十 GB 的大模型第一次下载慢，那属于带宽和下载量的物理限制，配置层面能做的就是别重复下第二遍；如果是小模型也慢、进度条长时间不动，那更可能是到模型仓库的连接问题；如果是每次重建容器、换一台机器就要重新拉一次，那问题在模型目录没被复用，而不是速度本身。
动手前建议先确认这几项，避免改了半天改错方向：
- 看 `ollama pull` 的进度是否是匀速推进，卡在同一百分比长时间不动和缓慢推进是两类问题。
- 确认模型目录位置：默认在 `~/.ollama/models`，以 systemd 服务运行时通常在 `/usr/share/ollama/.ollama/models`，是否设置了 `OLLAMA_MODELS`。
- 确认部署方式：裸机、systemd 还是容器；容器是否用了 `--rm` 或每次新建匿名卷。
- 确认磁盘剩余空间和目标盘的文件系统，模型动辄十几 GB，空间不足会在中途停住。
- 确认机器上是否已有可用的模型文件（GGUF 或其他来源），有的话直接导入比重新下载快得多。
目标也要定清楚：是「让这一次下载能完成」，还是「让后续每台机器都不再重复下载」。前者关注连通性和空间，后者才需要做模型目录复用和内网分发。
按这个顺序处理
建议按下面的顺序走，先做判断再做改造，不要一上来就改环境变量。
第一步：确认瓶颈在下载还是在本地
先看拉取过程和本机状态，确认到底是网络不通、速度受限还是写入受阻。
# 打开调试日志观察拉取细节
OLLAMA_DEBUG=1 ollama serve
# 另开一个终端执行拉取，同时观察进度是否推进
ollama pull qwen2.5:7b
# 看模型仓库域名是否能正常建立连接
curl -I https://registry.ollama.ai
# 看磁盘余量是否够放下这个模型
df -h ~/.ollama如果 `curl` 这一步长时间无响应或直接失败，说明问题在出口连通性，靠改 Ollama 参数解决不了，需要换一条能访问模型仓库的网络路径，或者改用手工导入权重。如果连接正常、进度也在走，只是慢，那基本是带宽和文件体积的问题，接下来要解决的是「不要重复下」。
第二步：把模型目录固定下来，避免重复下载
这一步对多机部署和容器部署收益最直接。裸机或 systemd 部署建议把模型目录指到一个空间充足、便于备份的路径，并让后续所有部署都指向同一个目录。
# systemd 环境下用 override 注入，不要直接改服务原文件
systemctl edit ollama
# 写入以下内容
[Service]
Environment="OLLAMA_MODELS=/data/ollama/models"
systemctl daemon-reload
systemctl restart ollama容器部署则要用命名卷，不要用 `--rm`，也不要每次换匿名卷：
docker run -d --name ollama -p 11434:11434 \
-v ollama:/root/.ollama \
ollama/ollama容器重建时复用同一个命名卷 `ollama`，已下载的模型就不会丢；这里要注意别把卷挂到宿主机的空目录上，否则等于把已有模型覆盖掉。
第三步：有可用的权重文件时，走本地导入
如果你已经从其他渠道拿到了 GGUF 权重，或者本机另一套环境里已有模型，就不必再走一次完整下载。用 Modelfile 导入是 Ollama 支持的常规做法：
# Modelfile 放在权重文件同目录
FROM ./qwen2.5-7b-instruct-q4_k_m.gguf
PARAMETER num_ctx 8192
# 在 Modelfile 所在目录执行
ollama create qwen-local -f Modelfile`FROM` 后面写相对路径或绝对路径都可以，`ollama create` 会把它注册成本地模型名。模型名、量化格式和模板要对应，否则模型能建出来但对话格式会乱，这一点在第三步就要留意，不要等验证阶段才发现。
第四步：内网多台机器时，直接分发模型目录
一台机器拉好之后，把模型目录整体复制到其他机器，比每台各自下载要省事。模型目录由 `blobs` 和 `manifests` 两部分组成，整体拷贝才完整：
# 从已下载完成的机器推到目标机
rsync -av --progress /data/ollama/models/ user@目标主机:/data/ollama/models/
# 目标机上把属主改成 ollama 服务运行用户
sudo chown -R ollama:ollama /data/ollama/models复制完成后，目标机需要重启服务，让 Ollama 重新扫描目录。这一步的前提是两边 Ollama 版本接近，跨大版本时 manifest 结构可能不一致，建议同版本之间操作。
改完后怎么验证
改完不要只看命令是否报错，要看模型是否真的可用。建议按下面的顺序检查，任意一步不符合预期就回退排查：
- `ollama list` 能看到目标模型名和体积，体积与预期量级相符，不是几百 MB 的残缺条目。
- `ollama show <模型名>` 能看到参数、模板等信息，说明 manifest 被正确识别，不只是 blob 躺在目录里。
- `ollama run <模型名> "用一句话说明你的名字"` 能正常返回内容，且中文不乱码、不重复输出，说明模板和量化格式匹配。
- 再执行一次 `ollama pull`，如果本地已有完整模型，通常不会再重新下载大文件，这是判断目录复用是否生效的最直接信号。
- 分发场景下对比源机和目标机的 `blobs` 目录文件数量与总体积（`du -sh` 和文件计数），差异过大说明拷贝中断；条件允许时对关键 blob 做一次哈希比对。
如果 `ollama list` 里出现了模型但 `run` 报错，优先怀疑权重不完整或模板不匹配，而不是网络问题。
容易忽略的边界
这些限制在配置阶段容易被跳过，但出问题时往往就卡在这几处：
- 版本兼容：Ollama 不同版本之间模型目录的 manifest 结构可能变化，跨大版本复制或导入旧模型目录不一定能被识别，建议源机和目标机用同一版本，或先在测试机验证。
- 文件属主和权限：以 systemd 服务运行时，Ollama 是以 `ollama` 用户身份读目录的，复制或改路径后属主仍是 root 时，常见表现是服务重新下载或直接报错。
- 本地导入的适用范围：GGUF 导入需要模型架构被支持、模板写得对，不是所有量化方式和模型结构都适配；导入后对话异常要先检查模板，不要先怀疑速度配置。
- 非官方分发渠道的完整性：手工拿到的权重文件来源不受控，建议核对文件大小，必要时比对哈希，不要把不完整的文件当模型用。
- 磁盘空间：模型下载中途失败通常会在 `blobs` 里留下部分文件，下次拉取可能报错或重复占用空间，清理时注意只删明确对应的残留文件。
- 不要把 swap、调大页缓存、临时复制到 `/tmp` 这类止血手段当成加速方案，它们改变不了下载量，反而容易在重启后丢失模型目录。
- 回退办法：如果改了 `OLLAMA_MODELS` 后服务异常，删掉 `systemctl edit` 生成的 override 片段并重启服务，即可回到默认的 `~/.ollama/models`，原有模型目录不要急着删，先确认新路径是否可用。
真正决定这块体验的，通常是模型目录有没有被稳定复用、有没有可用的本地权重来源；把这两点固定下来，比反复调整下载参数更实际。