使用ollama导出模型&导入模型

本地跑了一段时间 Ollama，攒了几个自己拉过、甚至微调过的模型，现在要换机器、搬到内网、或者给同事一份离线包——结果发现模型库目录长得跟认不出来一样，直接拷过去又怕跑不起来。这篇不讲概念，按「先定位、再导出、再导入、最后验收」的顺序把动作列清楚，顺带说明哪些情况下这套做法不适用。

本地用 Ollama 跑了一段时间，总会遇到要搬家的时刻：换新机器、把模型挪进内网、给同事一份能离线还原的包，或者把自己微调出来的产物固定下来。真动手时会发现，模型目录里不是一个大文件，直接拷某个 bin 过去，另一端往往列表里根本不出现。

这篇按「先定位、再导出、再导入、最后验收」的顺序，把每一步做什么、怎么验证、什么情况下别这么做讲清楚。整体思路是把迁移当成一次有交接文档的搬运，而不是随手复制一个文件夹。

先判断这次迁移值不值得做

迁移本身有成本，最大的成本不是时间而是排查。动手前先问一句：这件事有没有更省事的路？如果是同一个模型换个地方跑，直接在新机器上重新拉取，往往比打包搬运更快也更不容易踩坑。迁移真正的价值在于「离线」和「固定」这两个诉求。

• 适合迁移：目标机器不能联网、要把微调产物长期固定、要给团队做一份可复现的离线包、内网机器之间同步同一套模型
• 不值得迁移：只是想试试另一个模型、目标机器网络正常、或者只是同一台机器上换目录
• 同一台机器换目录，改环境变量指向新路径通常比导出再导入简单，先试这条路
• 先确认目标机器的架构和显存装得下同一个模型与量化档位，装不下的话导入成功也跑不动；量化档位与显存的对应关系到 /models/deploy 按自己的卡算一遍

找准模型存在哪、由哪些文件组成

Ollama 的模型不是单个大文件，而是一个 manifest 加若干 blob。manifest 记录这个模型由哪些层组成，blob 才是权重和配置的实际内容。只拷某个 bin 文件是无效动作，导入端找不到清单，列表里就不会出现这个模型。

默认存储位置随系统和安装方式变化，Linux、macOS、Windows 各不相同，同一个系统用不同方式装也可能落在不同目录。动手第一步是确认当前生效的路径，而不是凭印象去找。相关的目录与存储术语可以对照 /ai-dict/category/infra 里的解释。

1. 查出当前存储目录用 Ollama 的环境配置或帮助命令确认模型目录实际指向哪里，同时记录服务是哪个用户启动的
2. 区分 manifest 与 blob进目录看结构，manifest 目录下按模型名和标签分层，blob 目录里是哈希命名的大文件
3. 核算体积与空间把要迁移的模型占用加总，和目标磁盘可用空间对比，导出的包通常与本地占用相当甚至略大
4. 写成清单记录主存储目录、manifest 位置、当前环境变量值三项，后面导入时要一一对上

导出：把模型打包成可搬运的产物

导出的核心原则是「先确定范围，再保留结构」。范围没定好，很容易漏掉依赖的基础层，导入端会缺件；结构没保留，导入端还原不出 manifest，模型等于没搬。

• 先把要迁的模型清单列出来，一次导出成一组，别一个一个搬，容易漏掉共享的基础层
• 导出前确认环境变量指向的就是要导的那份存储目录，否则可能导出空目录或旧版本
• 打包时保留完整目录层级，不要只压一层 blob 文件夹，manifest 结构丢了就还原不出来
• 导出完成后换一个目录做一次解包自检，确认文件数量和总大小对得上再发走
• 自检时顺便看一眼 manifest 里引用的层是否都在包里，缺层的话目标端会报错

tar -czf ollama-models-backup.tar.gz -C <模型主目录的上一级> <模型主目录名>

命令里的路径要换成你实际查到的那一份，别直接抄示例。打包完成后建议把包放在另一块盘上再解一次，确认目录结构和文件数量一致，这一步花几分钟，能省掉后面一整轮返工。

导入：在目标机器上还原并注册

导入翻车最多的地方不是文件本身，而是顺序。正确顺序是先在目标机器上把存储目录定好、环境变量设好，再把文件放进去。如果先把文件丢进去再改配置，很容易出现「文件明明在，列表里却没有」的情况。

1. 定目录确认目标机器的模型存储目录，必要时新建并确认服务账号有读写权限
2. 设变量把环境变量指向这个目录，保存配置后重启服务，只改不重启等于没改
3. 放文件把导出的包解到目标目录，保持源端的目录层级不变
4. 注册确认用列表命令查看模型是否出现，名字与标签要和源端一致
5. 离线验证断网状态下再跑一次列表和一次加载，确认不依赖网络也能用

如果目标机器上已经有同名模型，先决定是覆盖还是并存。并存需要改名字，否则会撞车；覆盖则要确认旧的那份不再被别的工作流引用，避免换掉之后有人找不到模型。

路径与环境变量：迁移翻车最多的环节

很多人把「模型存储目录」「服务监听地址」「并发与显存相关变量」混成一类，实际上只有第一类和迁移直接相关。监听地址和显存变量影响的是服务怎么跑，不决定模型能不能被找到，排查时别把它们搅在一起。

• 改完环境变量必须重启服务，这一步没有例外
• 多用户机器上要确认服务是哪个用户跑的，跑在不同用户下会读不同目录
• 目录权限要给到服务账号，只给到自己账户往往不够
• 把最终生效的路径写进交接文档，比口头说一句「按默认来的」靠谱得多
• 两台机器上的路径可以不一致，但环境变量必须各自指对，别指望路径自动对齐

验收：怎么确认导入的模型真的能用

导入完不等于能用，要过三步验收：列表能看到、能加载进显存、能正常出一段完整回答。前两步都过、第三步出问题，通常指向量化档位或显存，而不是文件搬错了。

1. 列表验收确认模型出现在列表里，名字与标签和源端一致
2. 加载验收发起一次推理，观察是否能正常加载进显存，中途不报错
3. 输出验收用一个固定的小提示词在源端和目标端各跑一次，比较输出长度与耗时
4. 接口验收确认本地服务地址可访问、返回格式正常，延迟基线可以到 /tools/speed-test 量一遍

验收不通过时按固定顺序排查：路径 → 权限 → 变量 → 显存 → 量化档位。不要一上来就重装，重装会把已经排掉的变量重置，反而更难定位问题出在哪一层。

这些情况这套做法不适用

导出导入不是万能钥匙，有几类场景按上面流程走反而会出问题。判断标准很简单：只要目标端能联网、或者格式兼容性不确定、或者模型本身带着授权限制，就要换思路。

• 模型本身有许可证或授权限制时，导出给别人用可能越界，先看清授权再分发，别把内部测试包外发
• 跨大版本迁移，格式可能不兼容，建议以目标端重新拉取为准，导入只当兜底
• 涉及自定义模板、系统提示词、参数默认值时，光搬模型文件不够，这些配置在另一端不会自动跟过去
• 生产环境迁移要留回滚路径，先在一台非关键机器上跑通全流程再动主节点
• 团队分发时最好附一份交接说明，写清环境变量值和目录结构，减少对方自己猜的时间

迁移搬的是文件，验收验的是环境；文件对了环境没对齐，模型一样跑不起来。