ollama离线迁移模型

内网机器装好了 Ollama，却拉不动模型，只能从已经下好的机器上把模型搬过去。这事听起来简单，卡点通常在三个地方：模型到底存在哪个目录、哪些文件必须一起带走、导过去之后为什么跑不起来。这篇按顺序把每一步和对应检查项列出来，照着做就行。

内网机器装好了 Ollama，却发现拉不动模型，只能从已经下好的机器上把模型搬过去。这事听起来简单，卡点通常集中在三处：模型到底存在哪个目录、哪些文件必须一起带走、导过去之后为什么跑不起来。这篇按顺序把每一步和对应检查项列出来，照着做就行。

先说一个前提：本文只讲同一台机器上已经跑通的模型怎么搬到另一台机器，不涉及自己转换模型格式或从别处下载权重。如果你的源机器上模型本来就没跑通，先别打包，先回去把源机器的问题解决掉，否则搬过去只会把同一个问题复制一遍。

先搞清楚模型到底存在哪儿

第一步永远是上源机器确认模型实际存放路径，别凭印象猜。默认存储位置随系统不同而不同：Linux 和 macOS 通常在用户目录下的隐藏目录里，Windows 在用户目录下的同名目录。先在源机器上把真实路径敲出来看一眼，再决定后面怎么打包。

如果之前改过模型存储位置的环境变量，模型就在新位置。两台机器路径不一致是后面跑不起来的头号原因，源机器改了、目标机器没改，或者反过来，都会出现「文件明明在、服务就是找不到」的情况。路径怎么确认、环境变量有哪几个，可以对着站内关于环境变量与路径的文章核对。

最省事的做法是整体复制模型目录，而不是逐个模型挑文件。多个模型可能共用同一个权重分片，只挑单个模型的文件很容易漏掉共享部分，结果就是这个小模型在目标机器上加载失败，而你根本想不到问题出在它跟另一个模型共享了文件。

搬运介质这件事容易被忽略。如果介质不是自己独占、经过多人手，注意模型文件本身可能带来源信息，敏感环境建议走内网通道而不是公共存储。这不是技术问题，是流程问题，但出问题往往比技术问题更麻烦。

启动服务后先列一遍模型清单，确认名字和标签都在。清单能列出来但加载失败，多半是文件损坏或路径权限问题；清单里压根没有这个模型，先回去看目录是不是放错位置了。这两类现象指向的排查方向完全不同，先分清再动手。

接下来直接跑一次最小推理，看能不能正常出字。能出字说明权重完整，迁移这件事就算成了。出字慢或者直接 OOM，那是显存和量化档位的问题，跟迁移本身无关，别在这个环节怀疑文件完整性。

常见报错按下面这个顺序排查，从最常见、最容易验证的开始，别一上来就重装环境。

需要看具体环境变量细节、目录结构说明或者服务配置项，去站内对应的文档页核对当时的说明；这些内容会随版本更新，别拿旧笔记当准。真遇到加载失败又排不出来，把报错原文和目录清单一起带上，去站内工具页做一轮环境自检再回来判断。

能不能只复制单个模型，不搬整个目录？

可以，但前提是你会看哪个 blob 被这个模型引用。多个模型共用同一个基础权重分片是常事，只挑单个模型的 manifest 加上它引用的分片，漏掉共享分片就会加载失败。图省事就整体复制，图省空间再按引用关系挑，两种做法都要在目标机器上跑一次验证。

迁移过去的模型，标签名和原来不一样怎么办？

标签名来自 manifest 里的记录，正常复制过去应该一致。名字对不上通常是复制过程中只拿到了部分文件，或者中间做过改名。先在目标机器上列一遍清单，比一眼源机器的清单，缺哪个补哪个；确实想改名，用本地导入的方式重新生成标签，别直接改目录里的文件名。

迁移完成后需要联网吗？

不需要。模型文件已经在本地，推理过程完全离线。要注意的是某些客户端界面第一次连接时会去查模型列表或版本信息，这类请求失败可能导致界面显示异常，但模型本身能跑。纯内网环境建议把客户端的自动更新和在线检查关掉，减少无谓报错。