ollama模型迁移内网

内网机器装好了 Ollama，却卡在拉不动模型：外网那台能跑，内网这台 ollama pull 一直转圈。这篇按「先看清本地模型是怎么存的——再搬运——再验证——最后处理路径与权限」的顺序走，给一份可照着执行的清单。适合要在隔离网段搭本地推理、又不想重下模型的同学。

内网机器装好了 Ollama，却卡在拉不动模型：外网那台能跑，内网这台 ollama pull 一直转圈。这篇按「先看清本地模型是怎么存的——再搬运——再验证——最后处理路径与权限」的顺序走，给一份可照着执行的清单。适合要在隔离网段搭本地推理、又不想重下模型的同学。

先说清楚适用范围：这套办法解决的是「文件已经从外网机器上拿到了，怎么安全搬到内网并让它跑起来」。如果你的模型根本还没在外网下载过，或者目标机硬件带不动这个档位，迁移这一步做了也白做，后文会单独讲这类情况。

先搞清 Ollama 的模型到底存在哪、由什么组成

动手拷之前，先在源机器上把现状摸清。很多人迁移失败不是因为拷得不对，而是压根不知道自己要拷什么，只把 ollama list 里显示的名字当成路径去拼，结果拷过去的目录结构是错的。

manifest 层

记录这个模型由哪些分片组成的清单文件，相当于目录，体积小但缺了就没法索引

blobs 层

真正的权重分片，单个文件可能很大，是迁移时最占时间也最容易拷漏的部分

tag 名

ollama list 显示的名字里冒号后面那段，跟磁盘上的目录名不是一一对应，别拿它拼路径

models 目录

由安装方式和系统决定，也可能被某个环境变量改过，必须先查真实位置

1. 列出现有模型在源机器执行 ollama list，确认哪些已经在本地；再用 ollama show 逐个看详情，记下哪些是你要搬的，别整台机器无脑全拷
2. 定位真实存储目录查清 models 目录的绝对路径；如果之前用环境变量改过存放位置，把这个设置一起记下来，迁移时要同步带过去
3. 确认两层结构到该目录下看 manifest 和 blobs 两层是否都在。只拷其中一层，迁到目标机后必然加载失败，这是最常见的坑
4. 决定整拷还是挑拷整目录拷最稳、最省心；只挑个别模型时，要保证被挑模型的 manifest 和它引用的 blobs 都带上，不能只拎一个目录出来

搬运这一步：怎么拷、拷完怎么确认没坏

搬运本身没什么玄机，怕的是通道不可靠导致文件截断。跨网段迁移时，优先选能校验完整性的方式，拷完一定要在目标机上做两层验证，而不是看到命令不报错就当成功。

• 拷完先比目录结构：manifest 与 blobs 的层级要和源机器一致，缺一层都别急着启动
• 在目标机执行 ollama list，能列出目标模型才算导入成功，这一步失败先回查目录路径
• 列表出来不等于能推理：实际发一次对话或补全请求，确认权重完整、没有半截文件
• 内网机不要设置成自己去补拉缺失层，缺哪层就回源机器补哪层，反复报错十有八九是漏拷 blobs

服务侧收尾：目录、环境变量与运行权限

文件到位只完成一半，剩下的是让服务正确读到它。目标机建议把模型统一放在一个固定目录，并通过环境变量指向它，以后增删模型不用动服务配置。改完环境变量要重启服务才生效，重启之前先确认服务进程是以哪个用户身份跑的。

校验顺序建议固定成一条线：目录对不对→环境变量生效没→服务重启没→实际推理通不通。跳步排查容易在中间某个环节绕圈，先把这条链走完再谈其他优化。

什么情况下这套办法不适用

这套办法不是万能的，遇到下面几类情况，硬拷过去只会浪费一轮时间，不如换个思路。判断标准很简单：文件能不能直接复用、目标机扛不扛得住、是否需要多台共享。

• 硬件差异太大不适用：源机器跑得动的档位，目标机显存或内存更小就起不来，得先按目标机资源重新选档位再迁移
• 跨大版本或跨推理框架不适用：模型目录格式可能不兼容，硬拷不如按目标框架重新准备权重
• 多机共享同一份模型不适用单机拷贝思路：更适合做只读共享目录或统一镜像，避免每台各存一份、版本漂移
• 要对外提供服务还要单独核显存、并发与许可证，迁移只解决文件搬运，不解决能不能稳定对外服务

想少走弯路，可以先把这套清单在你自己的源机器上跑一遍，记录下模型目录的真实路径和两层结构，再去处理内网那一侧。实际推理表现、可选的推理框架和不同机器的承载能力，可以到站内的资料库和工具页比对当时的数据，再决定搬哪些、搬到什么程度。