离线部署大模型三件套:Ollama + DeepSeek + Open WebUI 实战指南
2026/9/6 14:42:15 网站建设 项目流程

简介:面向需要在内网或离线环境私有化部署大语言模型的开发与运维人员,这份PDF系统梳理了ollama、deepseek与open-webui三组件的安装、配置与联调方法。内容涵盖不同操作系统的安装方式、硬件选型建议(如运行1.5B模型至少4GB内存、33B模型需32GB内存)、各版本deepseek模型的CPU/内存/显存推荐配置,以及基于Docker的部署方案和离线安装步骤。对于模型启动失败、服务响应慢等常见问题,文档给出了基于日志的排错思路,并提醒数据隐私安全与合规注意事项。资源共1个PDF文件,压缩包约915KB,内容组织紧凑、可直接按章节查阅,适合已有一定命令行基础的读者对照实操。已有855人学习下载。 最近越来越多的团队开始需要在断网环境里用上大模型,不管是业务数据不能出内网,还是机房部署条件受限,核心需求就一句话:把模型的运行能力完全放在本地。我在自己的内网环境里完整落地过一套,用的就是标题里提到的三件套:Ollama 做运行时,DeepSeek 提供模型能力,Open WebUI 做交互界面。整条链路走通之后,局域网里的同事打开浏览器就能用上对话大模型,完全不需要外网连接。

这套方案最大的价值在于:它把“大模型部署”这件事真正做成了离线可交付的产品。不需要云服务,不需要公网 API Key,只要有一台配置还行的机器,就能在隔离网络里跑起一个私有的大模型服务。对刚接触本地模型部署的同学来说,这套组合也是最容易上手、坑最少的一条路线。下面我把安装、使用、踩坑的经历原原本本写出来,希望能帮你少走几趟弯路。

1. 方案核心思路:为什么选这三件套

1.1 三个组件各扮演什么角色

先把分工理清楚。Ollama 是一个本地大模型运行器,它负责模型文件的管理、加载和推理,同时对外提供统一的 API 接口。DeepSeek 是模型本身,我用的主要是 DeepSeek-R1 系列和 DeepSeek-V2 系列的量化版权重文件。Open WebUI 则是一个开源的网页前端,它把 Ollama 的 API 包了一层,在浏览器里提供类似 ChatGPT 的聊天界面,支持多用户、知识库、对话历史管理等功能。

之所以把这三者组合在一起,是因为它们的职责边界非常清晰,相互之间通过标准 HTTP API 通信,替换任何一环都不会牵连其他部分。Ollama 本身自带一个简易的命令行交互模式,但说实话,如果给团队里非技术的同事用,命令行根本不可行。加上 Open WebUI 之后,体验直接从“程序员玩具”变成“可交付的内部工具”。而模型层用 DeepSeek,主要是因为它在中英文场景下的综合表现足够好,开源许可也相对友好,商用场景不用太担心授权问题。

1.2 离线部署要解决的核心问题

离线部署和在线部署最大的差别在于:一切依赖都需要提前准备好,任何一步缺失都可能卡住整个流程。具体来说有三个核心问题要解决。

第一是模型文件从哪来。模型权重动辄几个 GB 到几十个 GB,在有网环境下拉取都很耗时,离线环境下更要提前把模型文件下载好、打包好,再拷贝到目标机器。第二个问题是运行环境依赖怎么装。Ollama 本身是一个编译好的二进制文件,相对好处理,但如果用 Docker 方式部署 Open WebUI,就需要提前准备镜像包。第三个问题是要考虑局域网里的多人访问。部署完成之后,不止是本地自己玩,要让同一内网里的其他人都能通过浏览器访问,这就需要在硬件选型和配置上做规划。

我见过不少人在这里翻车:模型下载好了,Ollama 也装好了,最后发现 Open WebUI 的镜像没提前导出,只能干等外网。所以后面所有的安装步骤,我都会把“离线准备”和“目标机安装”分开讲。

2. 安装准备:先把离线资源备齐

2.1 硬件配置怎么选

先说我实际用的机器配置:CPU 是 16 核,内存 64GB,GPU 是一块 24GB 显存的显卡,硬盘预留了 200GB 空间。在这个配置上跑 DeepSeek-R1-Distill-Qwen-14B 的 Q4 量化版本,推理速度完全够用,多用户并发刷网页也不会明显卡顿。

如果你的机器配置更低,也有办法。硬件条件对应的模型选型建议大致如下:

硬件条件推荐模型规格说明
16GB 内存,无独显7B 量化模型速度偏慢,仅适合个人测试
32GB 内存,8GB 显存7B~14B 量化模型日常对话可用
64GB 内存,24GB 显存14B~32B 量化模型多用户使用流畅
128GB 内存,48GB 显存70B 量化模型接近中等规模商用体验

这里有个重要原则:显存不够就靠内存来凑,Ollama 支持 GPU 和 CPU 混合推理,但完全依赖 CPU 推理的速度会比较慢,只适合对实时性要求不高的场景。

2.2 三样东西要提前备好

离线部署前,你需要在有网的机器上准备三样东西:

第一是 Ollama 的安装包。直接去官方网站下载对应操作系统的二进制安装包,Linux 和 Windows 版本都有,下载完压缩打包。

第二是模型文件。这一步很多人容易搞混:不是下载一个单独的 .gguf 模型文件放到目录里就行,而是要用 Ollama 的模型创建机制来导入。最简单的做法是在有网机器上先安装好 Ollama,然后用ollama pull deepseek-r1:14b把模型拉到本地缓存,再从缓存目录把模型文件复制出来。模型文件通常存放在~/.ollama/models路径下,把这整个目录打包带走。如果只拿到了 .gguf 文件,那需要写 Modelfile 再导入,操作上多一步,后面我会详细说。

第三是 Open WebUI 的 Docker 镜像。在有网机器上执行docker pull ghcr.io/open-webui/open-webui:main,拉取成功后用docker save导出为 tar 压缩包,这样可以方便地拷到目标机器上离线导入。

3. 安装与配置:一步步走通

3.1 目标机安装 Ollama 并导入模型

在离线目标机器上安装 Ollama 很简单。以 Linux 为例,把安装包解压出来,将ollama二进制文件放到/usr/local/bin目录,然后执行:

ollama serve

启动服务后,Ollama 默认监听127.0.0.1:11434。把之前备份的models目录直接解压到目标机器的~/.ollama/路径下。注意不要覆盖现有的配置目录,而是把模型文件合并进去。

然后验证模型是否可见:

ollama list

如果能看到你拷贝的模型列表,说明导入成功。这里有一个非常关键的细节:如果模型是在别的机器上通过ollama pull下的,它的 manifest 文件里记录的路径信息通常是相对路径,直接拷贝到新机器一般没问题。但如果你手动移动过模型文件,manifest 里的路径就失效了,这时候要检查一下~/.ollama/models/manifests里的内容是否指向正确位置。

如果只有 .gguf 文件,正确的手动导入方式是写一个 Modelfile:

FROM ./deepseek-r1-14b.Q4_K_M.gguf

然后在同目录执行:

ollama create deepseek-r1:14b -f Modelfile

这样就会在本地注册一个新的模型。这个方法在拿到了第三方量化好的模型文件时会非常实用,不需要对被导入的 GGUF 格式有什么特殊要求。

3.2 让 Ollama 服务被局域网访问

默认情况下 Ollama 只监听本机回环地址,如果希望局域网内的其他机器能够访问,需要设置环境变量。启动前执行:

export OLLAMA_HOST=0.0.0.0

这样 Ollama 就会监听所有网卡地址。对于 Windows 用户,可以在系统环境变量里添加OLLAMA_HOST,值设为0.0.0.0

有一个安全性的问题需要提醒。在大范围开放网络环境中要注意访问控制,而内网环境中,即便服务暴露在局域网内问题也不大,但如果有大量敏感数据,建议在反向代理或 Open WebUI 层做好访问认证。因为 Ollama 本身默认没有任何认证机制,任何拿到你 IP 的人都能直接调用 API,不止是聊天,连模型文件的下载接口也都是开放的。

3.3 离线导入 Open WebUI 镜像

把之前在有网机器上用docker save导出的镜像包拷贝到目标机,然后执行:

docker load -i open-webui.tar

镜像加载后,启动容器的命令如下:

docker run -d \ --name open-webui \ -p 3000:8080 \ -v open-webui-data:/app/backend/data \ -e OLLAMA_BASE_URL=http://<目标机IP>:11434 \ --restart always \ ghcr.io/open-webui/open-webui:main

几个参数的含义说一下:

  • -p 3000:8080:把容器的 8080 端口映射到宿主机 3000 端口,浏览器访问http://<目标机IP>:3000即可打开界面。
  • -v open-webui-data:/app/backend/data:数据卷持久化,保存用户账号、聊天记录、配置等数据。这一步不能省,否则容器一删数据全丢。
  • -e OLLAMA_BASE_URL:告诉 Open WebUI 去哪个地址找 Ollama 服务。这里如果填了http://localhost:11434那就错了,因为 localhost 是容器自身,而不是宿主机。应该填宿主机的局域网 IP,或者如果用--network host模式启动,那才能用 localhost。

启动后打开浏览器,第一次访问会提示创建管理员账号。创建完账号,进入设置页面,确认模型列表里能正常显示 DeepSeek 的模型,就可以开始对话了。

4. 实际使用与性能优化

4.1 浏览器与 API 双通道

Open WebUI 界面本身很像 ChatGPT,左侧是历史会话列表,底部是输入框,支持 Markdown 渲染、代码高亮。多人使用时,每个注册用户的数据互相隔离。这里我建议按团队规模先预创建账号,而不是全部放开注册,这在后续权限管理上会省很多事。

还有一条通道是 API 直接调用,非常适合把模型能力集成到自己的脚本或应用里。比如用 Python 调用:

import requests response = requests.post( "http://<目标机IP>:11434/api/generate", json={"model": "deepseek-r1:14b", "prompt": "用一句话介绍你自己"}, stream=True ) for line in response.iter_lines(): if line: print(line.decode())

Ollama 的 API 遵循 OpenAI 兼容格式,很多现成的工具直接就支持。比如在开发调试时,把 OpenAI 的 Base URL 换成本地http://<目标机IP>:11434/v1,模型名改成deepseek-r1:14b,就能无缝接入到老项目里,这个兼容性设计很值得点赞。

4.2 推理速度的关键因素

用下来最直观的感受是:推理速度主要受显存容量和模型量化精度两个因素影响。模型能全部塞进显存时,速度可以达到每秒 20 到 40 token;一旦显存不足,部分层退到 CPU 运算,速度会断崖式下跌到每秒不到 10 token。所以尽量选择能在当前显卡显存下完整加载的量化版本。

还有一个容易忽略的参数是上下文长度。Ollama 默认上下文长度不一定够用,遇到长文档分析时经常报错“context length exceeded”。可以在运行时通过环境变量或请求参数来调整。命令行启动时加--num-ctx 8192,API 调用时传options

json={"model": "deepseek-r1:14b", "prompt": "...", "options": {"num_ctx": 8192}}

上下文长度增大后,显存占用也会相应上涨,选多大需要自己权衡。

5. 常见问题与排查思路

5.1 模型下载接口一直报错

有网环境中拉取模型时速度极慢,或者直接超时,这是热度最高的一个问题。核心原因是模型文件分片较多,默认下载源在国内的连接质量很不稳定。我自己踩过的坑是直接 pull 几十 GB 的模型,跑了一个小时还在百分之十几。后来发现 Ollama 支持配置镜像源,在启动服务前设置环境变量:

export OLLAMA_MODELS=https://你的镜像地址

设置完重启 Ollama 服务,速度就正常了。镜像站之间的同步时效性不太一样,有时模型版本不全,找不到目标模型就换一个镜像试试。如果是完全离线的环境,那就必须走前面说的“有网机器拉取再拷贝”的方案,这个是最稳妥的。

5.2 容器里连不上 Ollama

Open WebUI 启动后报错,日志里显示连接不到 Ollama 服务。排查步骤可以按顺序走一遍:

  1. 检查 Ollama 宿主机的防火墙是否放行了 11434 端口。
  2. 在 Open WebUI 容器内部测试连通性:docker exec open-webui curl http://<宿主机IP>:11434,如果通则说明网络正常,不通就是防火墙或 IP 配置问题。
  3. 确认OLLAMA_HOST环境变量确实设成了0.0.0.0,而不是留空或默认值。

这类问题 80% 都是因为忽略了容器和宿主机之间 localhost 不通这个基本点。

5.3 模型回答质量不稳定或频繁中断

如果同一个问题多次询问,回答长度和内容差异极大,多半是采样参数默认值导致的。比如 temperature 等参数,Ollama 的默认配置不一定适配你的使用场景。在 Open WebUI 的高级参数面板里,可以调整 temperature 到 0.6、top_p 到 0.9 附近,回答稳定性会好很多。频繁中断则要检查显存占用,如果服务运行过程中出现内存不足导致的进程被杀,十有八九是模型规格超出硬件承载能力了。

最后分享一个我在实际部署中的体会:这套三件套组合最理想的应用场景,是网络隔离但有硬件资源的组织内部——数据不出内网,模型能力却一点不少。如果你要交付的也是类似的离线环境,务必要把模型文件、Docker 镜像、安装包这三样东西提前准备好,缺一样都会非常被动。第一次部署的时候,我在模型文件转移上反复拷贝了好几遍,后来干脆写了一键推送的脚本,把整条链路变成标准交付流程,后面的实施就轻松多了。

本文还有配套的精品资源,点击获取

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询