简介：面向需要在本地离线部署大模型的技术人员，这份PDF以ollama+deepseek+open-webui为主线，系统梳理了从环境准备到服务上线的完整流程，重点解决内网隔离环境中的安装、配置、硬件适配与排错难题。文档覆盖Windows、macOS、Linux及Docker四种安装方式，不仅给出不同DeepSeek参数版本对应的CPU、内存、显存配置建议，如1.5B轻量级到671B超大规模模型如何选型，还详细演示了Linux下离线安装包的制作与安装步骤、模型离线导入方法，以及常用环境变量的设置要点。资源为单个PDF文件，约915KB，内容紧凑、目录清晰，适合随时查阅。目前已吸引855人学习，适合需要搭建私有大模型服务、兼顾数据隐私与推理性能的开发者、运维人员。文中还专门总结了模型启动失败、服务响应慢等常见问题的日志定位思路，并提醒数据处理与合规使用注意事项，能帮助读者减少踩坑，快速完成可用部署。 接到一个需求：单位内网有台服务器，完全不连外网，却想跑一个本地问答大模型，还要让小组几个人同时用。我给出的方案就是 ollama + deepseek + open-webui 这套组合。折腾完以后把过程整理成了一份PDF，今天把其中的关键思路、操作步骤和踩过的坑铺开写一写，给准备做离线大模型部署的同学做个参考。
先说结论：这套方案对离线环境非常友好，核心就是“在有网机器上准备物料，再搬到内网机器上导入运行”。如果你是第一次接触本地大模型部署，或者正在被“离线环境装不上模型”折磨，这篇文章应该能帮你少走不少弯路。
1. 离线部署为什么选这三个组件
1.1 三个组件各管一摊
很多人一上来就问“部署大模型用什么”，但实际上大模型不是一个软件，而是一套组合。我选 ollama + deepseek + open-webui，是因为它们分工特别清晰：ollama 是模型运行环境，负责把 GGUF 格式的模型文件加载起来，对外暴露一个类似 OpenAI 的本地 API；deepseek 是模型本体，也就是真正干活的“大脑”，负责理解你的问题并生成回答；open-webui 则是网页界面，把命令行下的操作变成像 ChatGPT 一样的浏览器聊天窗口，还自带多用户、历史记录、文档上传这些功能。
打个比方，ollama 是发动机，deepseek 是燃油，open-webui 是仪表盘。发动机负责把能量转成动力，燃油决定能跑多远，仪表盘让你直观地看到转速和油耗。对应到技术栈上就是：ollama 负责推理计算，模型决定回答质量，界面决定使用体验。这三者各自独立又能无缝衔接，恰好满足离线部署“组件尽量少、依赖尽量简单”的诉求。
1.2 为什么不是 vLLM 或 LM Studio
群里经常有人问要不要换 vLLM。我的态度很明确：vLLM 适合高并发生产环境，吞吐量确实猛，但对离线部署来说太重了。它需要干净的 Python 环境、一整套 pip 依赖，还要严格匹配 CUDA 版本，任何一环对不上就是一场灾难。在没有公网的内网机器上，光是补 pip 依赖就能让人崩溃。
LM Studio 则是另一个极端，它很适合个人在笔记本上玩模型，双击打开就能用，但它本质是桌面软件，没有多人同时访问的权限体系，作为一个内网共享服务不合适。相比之下，ollama 的安装包就是一个二进制或安装程序，模型走 GGUF 文件导入，不依赖 Python 环境，open-webui 再用 Docker 镜像打包，把几乎所有运行依赖都封在了容器里。这套方案的离线友好度是最高的。
| 方案 | 离线友好度 | 部署复杂度 | 多用户支持 | 适合场景 |
|---|---|---|---|---|
| ollama + open-webui | 高 | 低 | 支持，有管理员体系 | 内网小团队、个人服务 |
| vLLM | 中 | 高 | 需要自己写API层 | 高并发API服务 |
| LM Studio | 中 | 低 | 无 | 单机桌面体验 |
1.3 离线部署的整体链路
离线环境的核心假设是：目标机器无法访问任何公网资源。所以所有安装包、模型文件、镜像都必须在联网机器上提前准备，然后通过移动硬盘、U盘或内网传输通道搬到目标机器上。
整个链路可以概括成四步：准备物料、离线安装、导入模型、启动服务。每一步之间有依赖关系，物料没准备好，后面就全卡住。我见过太多人卡在“模型文件没提前下载”这一步，到了内网才发现 ollama pull 根本拉不动，然后现场干瞪眼。所以第二章节我会重点讲物料准备，这是整个离线部署最容易出错的地方。
2. 离线安装包准备：一台有网机器搞定所有物料
2.1 ollama 安装包下载提速
ollama 的官方安装包托管在 GitHub Releases 上，很多内网机器的下载通道对这种国外站点不稳定，经常是下了半天进度条不动。遇到这种情况，我建议直接改用国内软件镜像站下载安装包，很多云厂商的镜像仓库同步了 ollama 的 Windows、Linux 和 macOS 安装包，下载速度能快出几个数量级。
下载完以后一定要核对安装包的校验值，官方页面会提供 SHA256 摘要。这一步不是为了走形式，而是为了避免传输过程中文件损坏，损坏的安装包在离线机器上安装会出现各种诡异报错。拿到校验值以后，在有网机器上用系统自带的校验工具比对一次，确认没问题再拷贝。
Linux 服务器一般下载 .tar.gz 或 RPM/DEB 包，Windows 机器直接下载 .exe 安装程序。内网里如果同时有 Windows 和 Linux 机器，建议两种安装包都准备好，以免临时换机器。
2.2 deepseek 模型文件离线获取
模型文件是离线部署里体积最大的物料，提前下载是必须的。deepseek 在 ollama 官方模型库里有多种尺寸的版本，比如 deepseek-r1 系列从 1.5B 到 70B 都有。不同尺寸对应不同的显存和内存需求，可以看表格参考：
| 模型 | 参数量 | 量化格式 | 文件大小（约） | 推荐硬件 |
|---|---|---|---|---|
| deepseek-r1:1.5b | 1.5B | Q4_K_M | 1.1GB | 无独显也能跑 |
| deepseek-r1:7b | 7B | Q4_K_M | 4.7GB | 8GB 显存 |
| deepseek-r1:8b | 8B | Q4_K_M | 4.9GB | 8GB 显存 |
| deepseek-r1:14b | 14B | Q4_K_M | 9GB | 16GB 显存 |
| deepseek-r1:32b | 32B | Q4_K_M | 20GB | 24GB 显存 |
| deepseek-r1:70b | 70B | Q4_K_M | 43GB | 48GB 显存 |
这里说的量化格式 Q4_K_M 是一种在效果和体积之间比较平衡的选择。如果是第一次在内网部署，或者机器配置一般，建议先拿 1.5B 或 7B 把流程跑通，再考虑换大模型。我甚至见过有人在只有 CPU 的机器上硬扛 32B 模型，结果每条回复要等十几分钟，基本不可用。
模型文件的来源有两种。第一种：在有网机器上安装 ollama，用ollama pull deepseek-r1:7b拉取，然后去模型目录下把文件捞出来。第二种：直接从 Hugging Face 等模型仓库下载 GGUF 格式文件，再通过 Modelfile 手动导入。我推荐第二种，因为它不要求有网机器上先装好 ollama，而且下载过程可以用专门的下载工具断点续传，大文件传输更稳定。
2.3 open-webui 镜像与 docker 依赖打包
open-webui 官方推荐用 Docker 部署，所以在有网机器上要把镜像提前拉取并导出。命令很简单：
docker pull ghcr.io/open-webui/open-webui:main docker save -o open-webui.tar ghcr.io/open-webui/open-webui:main导出的 tar 包通常有好几 GB，因为镜像内部打包了完整的 Python 环境、前端资源和各类依赖。这里提醒一句：open-webui 镜像托管在 GitHub Container Registry，国内拉取有时比较慢，有网机器上可以先配置 Docker 镜像加速器再拉取，效率会高很多。
除了 open-webui 镜像，还要确认内网机器上的 Docker 环境可用。如果是离线机器，docker 本身的安装包也得提前准备好。另外，如果内网机器没有公网拉取镜像的条件，那docker load就是唯一的镜像导入渠道，整个镜像文件需要跟随你的移动硬盘一起“配送”。
这一步很多人会忽略一个细节：open-webui 容器运行后，可能需要下载额外的 Python 依赖或前端资源，如果镜像版本太旧，内置资源不全，离线环境很可能启动失败。所以建议直接拉取最新的main标签镜像，而不是贪图体积选了旧版本。
3. 离线机器上的实践：安装、导入、验证
3.1 操作系统与驱动准备
物料到了离线机器以后，先不要急着安装组件，应该检查系统环境。Linux 服务器建议提前确认 NVIDIA 显卡驱动和 CUDA 是否可用，直接执行nvidia-smi，如果能看到显卡信息，说明驱动正常。很多离线服务器出厂时没有装好 NVIDIA 驱动，而离线环境下装驱动又是另一个大坑，所以一定要提前把对应系统版本的驱动安装包也放进物料清单。
如果是纯 CPU 机器，就要更注意模型尺寸选择，避免选超出内存容量的模型。我在一台只有 16GB 内存的机器上跑过 7B 量化模型，勉强能用，但如果开多个对话窗口，内存很快就被占满。
Windows 内网机器相对简单，确认显卡驱动正常、磁盘空间足够就行。要注意的是模型目录默认在 C 盘用户目录下，建议提前改到 D 盘或其他数据盘，避免 C 盘被几个模型文件塞满。
3.2 离线安装 ollama
Linux 环境下，把 ollama 的 tar 包解压到指定目录，再将可执行文件路径加入 PATH。启动服务用ollama serve，或者写成 systemd 服务让它开机自启。Windows 环境下直接双击安装程序，按向导下一步即可，安装路径可以自定义到 D 盘。
模型目录和环境变量这一步很关键。Windows 下设置系统环境变量OLLAMA_MODELS=D:\ollama_models，Linux 下可以写入~/.bashrc，如果使用 systemd 服务则要在 service 文件里增加Environment配置。设置完以后，模型文件就都会放到指定目录，方便统一管理，也避免系统盘被占满后引发一系列问题。
我遇到过一种情况：明明设置了OLLAMA_MODELS，重新打开终端后ollama list还是空。这是因为环境变量没有生效，或者 ollama 服务是旧环境变量启动的。改完环境变量必须重启 ollama 服务，这个坑频率非常高。
3.3 从 GGUF 文件导入 deepseek 模型
把下载好的 GGUF 文件放到离线机器某个目录下，然后在同目录建一个文本文件，命名为Modelfile，内容就一行：
FROM ./deepseek-r1-7b.Q4_K_M.gguf接着执行：
ollama create deepseek-r1 -f Modelfile等待提示成功即可。这条命令的作用是让 ollama 读取 GGUF 文件，并在它的模型仓库里登记一个名叫deepseek-r1的模型。之后就可以用ollama run deepseek-r1直接对话。
Modelfile 里还可以配置更多参数，比如上下文长度、温度等。例如希望降低显存占用，可以加上：
FROM ./deepseek-r1-7b.Q4_K_M.gguf PARAMETER num_ctx 2048 PARAMETER temperature 0.7参数的含义我会在后面章节展开，这里先记住：Modelfile 就是给模型写“启动配置”，离线导入的核心就靠它。
3.4 一条命令验证模型服务
模型导入以后，先在命令行里试跑一次：
ollama run deepseek-r1 "你好"能得到正常回答，说明ollama本身没问题。接着验证 API 接口是否正常，因为 open-webui 是通过 API 来通信的，如果 API 不通，界面也会连不上：
curl http://127.0.0.1:11434/api/generate -d '{"model":"deepseek-r1","prompt":"你好"}'如果返回一段带有response字段的 JSON，说明服务已经完全可用。这一步验证特别重要，很多人在图形界面里排查半天连接问题，最后才发现是 API 层压根没起来。
4. open-webui 图形化界面的离线部署
4.1 Docker 离线导入与启动
到了这一步，前面准备的 open-webui.tar 终于派上用场。在离线机器上执行：
docker load -i open-webui.tar docker images | grep open-webui看到镜像加载成功以后，写一个 docker-compose.yml。这是我最常用的配置：
services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - "3000:8080" environment: - OLLAMA_BASE_URL=http://192.168.1.100:11434 volumes: - ./data:/app/backend/data restart: unless-stopped启动命令是docker compose up -d。这里有个非常容易踩的坑：OLLAMA_BASE_URL不能写http://127.0.0.1:11434，因为在容器内部，127.0.0.1 指向的是容器自己，而不是宿主机。必须写宿主机的局域网 IP，这样才能让 open-webui 找到 ollama 服务。
如果局域网 IP 会变，可以使用 Docker 的extra_hosts机制，把host.docker.internal映射到宿主机地址，然后再把OLLAMA_BASE_URL写成http://host.docker.internal:11434，但 Linux 下需要额外配置，不如直接写静态 IP 省事。
4.2 首次登录与模型管理
启动完成后，浏览器访问http://内网机器IP:3000，第一次打开会要求注册一个管理员账号。这是 open-webui 的默认行为，注册第一个账号就是超级管理员。
登录后进入聊天页面，左侧模型列表里应该能看到刚才导入的deepseek-r1。如果列表是空的，先别急着怀疑模型导入失败，去管理后台的设置里确认OLLAMA_BASE_URL是否配置正确，并查看容器日志：
docker logs open-webui日志里如果出现Ollama连接失败，大概率还是地址或端口问题，按照 4.1 的路径再检查一遍。
4.3 局域网访问与实际使用
open-webui 启动后，默认绑定容器内的 8080 端口，通过宿主机端口映射对外提供服务。要让局域网同事访问，除了端口映射正确之外，还要确保宿主机防火墙放行了对应端口，否则同事在浏览器里看到的只能是连接超时。
ollama 那边也要做同样的事。默认情况下 ollama 只监听 127.0.0.1，局域网内其他机器访问不到，这时需要设置环境变量OLLAMA_HOST=0.0.0.0:11434并重启服务。
如果你希望同事免登录直接使用，可以在环境变量里加一项：
- WEBUI_AUTH=false但我不太建议在内网多人环境关掉登录，因为没有权限控制，任何一个人误删对话或改配置都会影响所有人。保持默认的注册登录机制，在后台开启注册审核，才是最稳妥的做法。
5. 高频问题与排查链路
5.1 下载慢或者完全拉不动模型
离线机器上执行ollama pull超时，这几乎是必然的。正确做法就是前面说的，在有网机器上下载 GGUF 文件，再通过 Modelfile 导入。
安装包下不动的话，除了换国内镜像站，还可以检查是不是下载工具限制并发。一个几十 MB 的安装包不用太纠结，但模型文件通常好几个 GB，强烈建议使用支持断点续传的下载工具，避免中途失败后从头再下。我之前用浏览器直接下 7B 模型，下到 80% 断掉，白白浪费了一个多小时。
5.2 模型加载速度慢、频繁内存溢出
模型加载慢，第一要检查是不是 GPU 没生效。在ollama run的过程中另开一个终端执行：
ollama ps如果输出里 GPU 那列显示的是 100%，说明模型已经加载到显存；如果都是 CPU，说明驱动或版本有问题。纯 CPU 机器上跑大模型本来就慢，不要有太高预期。
内存溢出这个问题，可以通过控制上下文长度来缓解。上下文越长，占用的显存或内存越多。在 Modelfile 里调整num_ctx，比如从默认的 4096 改到 2048，推理时的资源占用会明显下降。另外还可以设置：
OLLAMA_MAX_LOADED_MODELS=1 OLLAMA_KEEP_ALIVE=5m第一个环境变量限制同时驻留的模型数量，第二个让模型空闲 5 分钟后释放显存。这在多人共用一台服务器的时候特别有用，不然每个人开一次对话就把模型驻留显存里，资源很快就满了。
5.3 open-webui 连不上 ollama
我把完整的排查链路写在这里，按顺序执行，基本能定位 90% 的问题：
- 在宿主机上执行
curl http://127.0.0.1:11434/api/tags，确认 ollama 本身正常。 - 确认 ollama 监听地址是
0.0.0.0，不是127.0.0.1。 - 进入 open-webui 容器内部，执行
docker exec open-webui curl http://宿主机IP:11434/api/tags，确认容器能访问到宿主机。 - 检查宿主机防火墙是否放行 11434 和 3000 端口。
- 查看 open-webui 日志，看是否有具体的报错信息。
这几个步骤里，第 3 步最容易被忽略。很多人的 open-webui 和 ollama 明明装在同一台机器上，却因为容器网络隔离导致访问不了。写配置的时候多确认一下该用宿主机 IP 还是容器别名。
5.4 显卡驱动与 CUDA 版本不匹配
NVIDIA 驱动太老或 CUDA 版本低于 ollama 要求时，模型虽然能跑，但只会调用 CPU。最直接的确认方法还是ollama ps。如果确认驱动有问题，就必须手动安装匹配的驱动包，离线环境下的驱动安装包一定要提前准备，而且要和操作系统版本、显卡型号严格对应。
这个坑我踩过一次之后学聪明了：物料清单里永远多备一份驱动安装包，哪怕机器上已经有了，也留着备用。因为很多时候驱动是好的，只是 ollama 的 GPU 支持库缺失，这时候还要准备nvidia-container-toolkit的离线安装包，尤其是在 Docker 里跑 GPU 任务的场景。
5.5 我踩过几次坑之后的小结
离线部署这套东西，真正安装的时间可能只要半小时，但物料准备不齐、文件校验失败、IP 地址写错这些问题，每一样都能消耗掉大半天。我自己的习惯是拿到内网服务器的 IP、系统版本、显卡型号以后，先写一张物料清单，逐项打勾。清单里除了安装包和模型文件，还把校验值、部署命令、配置文件模板都一并写进去。到了现场就是照着清单执行，出问题也能快速定位到具体环节。
如果你也是第一次离线部署，强烈建议先用 1.5B 或 7B 的小模型把整条链路跑通，再换更大的模型。这套组合非常稳定，只要是按 GGUF 导入、容器内连接宿主机这两个核心点来操作，基本不会出大问题。
本文还有配套的精品资源，点击获取
