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和EnvironmentOLLAMA_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 里设了EnvironmentOLLAMA_MODELS/data/ollama/models那解压目标就要改成/data/ollama/models并且确保该路径属主也是 ollama。可以用一个 systemd override 片段固定路径配置如下# /etc/systemd/system/ollama.service.d/override.conf [Service] EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_HOST0.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确认两边架构一致这是最容易被忽略又最致命的一点。