1. 内网机器上 Ollama 拉不动 deepseek 模型，离线迁移到底怎么落地
很多做私有化部署的朋友都遇到过这个场景：生产环境是一台完全断网的 Linux 服务器，或者公司内网只放行了极少数白名单域名，ollama pull deepseek-r1:7b这条命令敲下去，进度条卡在 0% 一动不动，最后抛出一句Error: pull model manifest: Get "https://registry.ollama.ai/...": dial tcp: i/o timeout。这时候你手里唯一能用的，就是一台能联网的开发机，以及一个 U 盘或者内网跳板机。
所谓 deepseek 离线迁移，本质就是把 Ollama 在联网机器上已经下载好的模型文件，原封不动搬到目标机器上，让目标机器的 Ollama 认为这个模型本来就在本地。Ollama 的模型存储结构其实很朴素，核心就是两个目录：blobs存的是真正的权重分片和配置，manifests存的是模型的索引清单，告诉 Ollama 这个模型由哪些 blob 组成、用什么模板、参数是什么。只要这两个目录对得上，模型就能被识别。
这套方法适合谁？适合做内网 AI 平台运维的工程师、需要在隔离环境跑 deepseek 做推理服务的后端同学，以及手头只有一台能联网笔记本、却要给机房服务器装模型的倒霉蛋。我试过在 Ubuntu 22.04 和 CentOS 7 之间搬 deepseek-r1 的 1.5b 和 7b 两个版本，只要 CPU 架构一致（都是 x86_64），模型文件是可以通用的，跟发行版关系不大。
迁移的核心动作可以拆成四步：联网机打包模型目录、目标机恢复目录并修权限、Ollama 重新加载、用ollama list和一次真实推理请求验证。下面我会把每一步的命令、路径、容易踩的坑都写清楚，你照着敲就行。需要说明的是，本文聚焦的是模型文件本身的搬运，不涉及任何网络穿透手段，全程离线操作。
2. 迁移前先搞懂 Ollama 的模型目录结构和 deepseek 文件命名规则
动手之前必须先把 Ollama 的家目录摸清楚，否则你打包出来的东西可能是残缺的。Ollama 默认以ollama用户运行，它的家目录在大多数 Linux 发行版上是/usr/share/ollama，模型实际存放在/usr/share/ollama/.ollama/models/。注意这里有个隐藏目录.ollama，很多人第一次找的时候会漏掉。
进去之后你会看到两个关键文件夹。blobs目录里是一堆以sha256-开头的文件，这些就是模型的权重分片、tokenizer 配置、模板文件等，文件名就是内容的 SHA256 摘要。manifests目录则是多层结构，典型路径是manifests/registry.ollama.ai/library/deepseek-r1/7b，这个文件是一个 JSON，里面记录了该模型引用了哪些 blob 的摘要。
deepseek 模型在 Ollama 里的命名规则是deepseek-r1:1.5b、deepseek-r1:7b这种格式，冒号后面是 tag。对应到 manifests 目录，就是library/deepseek-r1/下面有1.5b、7b这些文件。而 blobs 里的文件是多个模型共享的，比如不同量化版本可能共用同一个模板 blob，所以你不能简单地按时间戳去挑文件，最稳妥的方式是直接整目录打包。
这里有个关键点：容器化部署的 Ollama 和单机部署的 Ollama，模型目录结构虽然一样，但挂载路径不同，不能直接把容器里的目录拷到单机环境用，反之亦然。如果你是从 Docker 里往外搬，要先docker cp把/root/.ollama/models弄出来，再按单机的路径放。
另外要确认目标机的 Ollama 版本和源机不要差太多。Ollama 在 0.1.x 到 0.3.x 之间 manifest 格式有过调整，跨大版本迁移偶尔会出现Error: model requires a newer version of Ollama。实测同为主流 0.3.x 或 0.4.x 版本之间迁移最顺。查看版本用ollama --version。
在源机上先执行这几条命令确认现状：
# 确认 ollama 服务运行用户和家目录 ps aux | grep ollama # 典型输出：ollama 1234 ... /usr/bin/ollama serve # 家目录一般是 /usr/share/ollama # 查看模型目录 ls -la /usr/share/ollama/.ollama/models/ # 应该看到 blobs 和 manifests 两个目录 # 查看当前已下载的模型 ollama list # NAME ID SIZE MODIFIED # deepseek-r1:1.5b e0979632db5a 1.1 GB 2 days ago # deepseek-r1:7b 28f8fd6cdc67 4.7 GB 2 days ago把ollama list的输出记下来，迁移到目标机后要对比这个列表是否一致。如果源机上模型是用 root 用户跑的 Ollama 下载的，那目录可能在/root/.ollama/models，用systemctl cat ollama看服务文件里的User=和Environment=OLLAMA_MODELS最准。
3. 源机打包与目标机恢复：可复制的 tar 命令和权限修复配置
搞清楚目录之后就可以打包了。我推荐直接打包整个.ollama目录，而不是只挑 deepseek 相关的文件，因为 blobs 存在共享，手动挑容易漏。打包前先停掉 Ollama 服务，避免文件正在写入导致 tar 报file changed as we read it。
# 源机操作，先停服务 sudo systemctl stop ollama # 进入 ollama 家目录 cd /usr/share/ollama # 打包整个 .ollama 目录，保留权限 sudo tar -zcf /tmp/ollama_deepseek_offline.tar.gz .ollama # 查看包大小，deepseek-r1:7b 大约 5GB 左右 ls -lh /tmp/ollama_deepseek_offline.tar.gz如果你只想迁移 7b 不想要 1.5b，可以打包后到目标机再删，或者用--exclude排除特定 manifest。但 blobs 不好按模型排除，所以整包最省心。打包完成后把 tar 包通过 U 盘或内网 scp 传到目标机。
目标机上的恢复动作要小心，因为目标机可能已经有一个 Ollama 在跑，直接覆盖会丢掉原有模型。建议先备份目标机现有目录：
# 目标机操作，停服务 sudo systemctl stop ollama # 备份原有模型目录（如果存在） sudo mv /usr/share/ollama/.ollama /usr/share/ollama/.ollama.bak # 解压迁移包到家目录 cd /usr/share/ollama sudo tar -zxf /tmp/ollama_deepseek_offline.tar.gz # 关键一步：修复属主，否则 ollama 用户读不了 sudo chown -R ollama:ollama /usr/share/ollama/.ollama # 确认目录结构 ls -la /usr/share/ollama/.ollama/models/权限这一步是最高频的翻车点。如果忘了chown，启动后ollama list会返回空列表，日志里报permission denied。另外 SELinux 开启的 CentOS 系还要处理安全上下文：
# 仅 SELinux enforcing 模式下需要 sudo semanage fcontext -a -t httpd_sys_content_t "/usr/share/ollama/.ollama(/.*)?" sudo restorecon -Rv /usr/share/ollama/.ollama如果你用的是自定义模型路径，比如在 systemd 里设了Environment="OLLAMA_MODELS=/data/ollama/models"，那解压目标就要改成/data/ollama/models，并且确保该路径属主也是 ollama。可以用一个 systemd override 片段固定路径，配置如下：
# /etc/systemd/system/ollama.service.d/override.conf [Service] Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_HOST=0.0.0.0:11434"改完执行sudo systemctl daemon-reload再启动。启动命令：
sudo systemctl start ollama sudo systemctl status ollama状态里看到Active: active (running)就说明服务起来了。如果起不来，用journalctl -u ollama -n 50看日志，常见的是路径不存在或权限不对。
4. 验证迁移结果：ollama list 与真实推理请求的成功返回
服务起来后第一件事就是ollama list，这是判断迁移是否成功的最快方式。如果列表里能看到deepseek-r1:1.5b和deepseek-r1:7b，说明 manifests 被正确识别了。
ollama list # NAME ID SIZE MODIFIED # deepseek-r1:1.5b e0979632db5a 1.1 GB 2 days ago # deepseek-r1:7b 28f8fd6cdc67 4.7 GB 2 days ago注意 MODIFIED 时间会保留源机的时间戳，这是正常的。如果列表为空，八成是 manifests 没放对位置或者权限问题，回到上一节检查。
接下来做一次真实推理，确认 blobs 完整。用ollama run交互式跑一条：
ollama run deepseek-r1:7b "用一句话解释什么是递归"如果模型文件完整，你会看到它正常输出。如果 blobs 缺失，会报Error: failed to load model: ... no such file or directory，这时候要回去核对 blobs 目录里对应的 sha256 文件是否都在。
更工程化的验证方式是直接打 API，这样能确认服务端口和推理链路都通：
curl http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "写一个 bash 函数判断文件是否存在", "stream": false }'返回的 JSON 里response字段有内容就说明成功。如果返回{"error":"model 'deepseek-r1:7b' not found"}，说明 manifest 没被加载；如果返回{"error":"... connection refused"}，说明服务没起来或者端口不对。
对于需要长期在编码场景里调用 deepseek 的团队，本地 Ollama 适合做隔离验证，但如果要接更稳定的云端推理和统一密钥管理，可以了解下 TaoToken 的 Coding Plan，它把模型调用和密钥管理做在了一起，适合把本地验证过的 prompt 直接搬到生产。本地验证通过后，你也可以用 TaoToken 的模型对话页面快速对比同一 prompt 在不同模型上的表现，地址是 https://taotoken.net/api ，接入文档在 https://taotoken.net/api-keys 可以查到密钥配置方式。
5. 迁移后常见报错排查：401、local proxy failed、reading choices 与 OAuth
离线迁移本身不涉及鉴权，但很多人在迁移完成后会顺手把本地 Ollama 接到某个云端网关做对比测试，这时候就会撞上一堆报错。我把几类高频错误和对应原因列一下。
第一类是401 Unauthorized。这个通常出现在你用 curl 或 SDK 去请求某个需要 Key 的端点时，Key 没带、带错、或者带了多余空格。检查请求头里的Authorization: Bearer <key>，确认 Key 是从控制台复制的完整字符串。如果你在 Cline 或 Claude Code 这类工具里配置，Base URL、API Key、Model ID 三件套必须同时正确，缺一个都会 401。
第二类是local proxy failed。这个报错一般出现在你本地开了某个转发工具，但目标端口没监听。比如你把 Base URL 写成http://127.0.0.1:8080，但 8080 上根本没有服务。排查方法很简单：curl -v http://127.0.0.1:8080看是否 connection refused。如果是 Ollama 本身，确认OLLAMA_HOST绑定的是0.0.0.0:11434而不是127.0.0.1，否则外部访问不到。
第三类是error reading choices或reading choices: unexpected end of JSON input。这类错误多见于 OpenAI 兼容接口的响应解析失败，原因通常是返回的不是标准 JSON，比如网关返回了 HTML 错误页，或者流式响应被中途截断。用curl直接打一次非流式请求，看原始返回体是什么。如果返回的是{"error":...}，那就是上游模型侧的问题，不是迁移的问题。
第四类是OAuth相关报错，比如OAuth token expired或invalid_grant。这类一般出现在用 OAuth 方式接入某些云服务的场景，token 过期需要重新授权。离线环境里如果用了带 OAuth 的客户端，建议改成 API Key 方式，避免 token 刷新依赖网络。
排查时有个通用套路：先确认本地 Ollama 自身能跑通（ollama run成功），再确认 API 端口能通（curl /api/tags返回模型列表），最后才去查上层工具的配置。这样能把问题范围一层层缩小。如果你在配置 Codex 的auth.json或 Cline 的 MCP 时遇到问题，重点核对 Base URL 是否带了多余的/v1后缀，不同工具对这个后缀的处理不一致。
6. 迁移完成后的接入与长期使用建议
模型搬过去、ollama list能看到、推理请求能返回，这三步做完，离线迁移就算闭环了。但实际生产里还有几件事值得做。第一是把迁移脚本固化下来，写成一个migrate_ollama.sh，包含停服务、打包、传输、解压、chown、启动、验证七个步骤，下次换机器直接跑。第二是在目标机上留一份ollama list的快照，方便后续对比模型是否被误删。
如果你后续要把本地验证好的 deepseek 能力接到团队协作或自动化流程里，可以考虑用 TaoToken 的 Coding Plan 做统一入口，它适合长期编码和 Agent 场景，密钥和模型管理比本地散落配置更清晰。接入时记得 Base URL 用 https://taotoken.net/api ，Key 在 https://taotoken.net/api-keys 生成，模型 ID 按文档填。需要快速试模型效果的话，模型对话页面 https://taotoken.net/api 可以直接用。
最后提醒一句，离线迁移的模型文件不要跨 CPU 架构混用，x86_64 的包搬到 ARM 机器上，ollama run会直接报exec format error或者加载失败。迁移前用uname -m确认两边架构一致，这是最容易被忽略又最致命的一点。
