企业官网建设流程全解析

简介：针对技术开发者、研究人员及AI爱好者，DeepSeek模型跨平台部署指南系统整理了该模型在桌面端、移动端及Web端三类场景下的部署方案。桌面部分基于Ollama讲解安装、拉取deepseek模型及交互式对话；移动端分iOS与Android两条路径，iPhone需通过Safari下载快捷指令并配置API Key测试，Android则利用Termux安装依赖、编译Ollama源码并加载模型；Open WebUI部署部分则串联Ollama、Docker Desktop与Open WebUI的安装与协作流程。包体为单个docx文档，大小约15KB，内容包含各平台操作步骤、命令行脚本及官方链接，并提醒API Key填写与Ollama初始化检查等易错事项。资源已有4122人浏览学习，可帮助初次接触者按图索骥完成环境配置，提升DeepSeek本地化部署的成功率。

1. 第一台本地大模型的起点不在显卡，而在“多平台协同”

把 DeepSeek 跑在本地这件事，很多人第一反应是看显存、看算力，结果一台 16GB 内存的笔记本就足够把 7B 量化模型跑得很流畅。真正花时间的不是模型本身，而是把 Ollama、Open WebUI 和手机端串成一条完整链路：Ollama 负责推理，Open WebUI 提供像网页版聊天一样的交互界面，手机端则负责把碎片时间利用起来。这篇部署指南就围绕这三个环节展开，目的是让你在半小时内从零开始，在自己的电脑上完成一套可用的 DeepSeek 环境，并且让手机在同一局域网下也能直接访问。适合有基础命令行操作能力、想脱离云端 API 限制的开发者，也适合想在本地体验开源模型的学生党。

2. Ollama 本地部署：从模型拉到 API 就绪的最小路径

2.1 先选模型再装环境：为什么 7B/14B 量化是本地部署的起步配置

Ollama 拉取模型时，默认下载的是经过 GGUF 量化的版本。量化简单说就是把模型权重从 16 位浮点数压缩到 8 位甚至 4 位整数，换来的是体积和内存占用的大幅下降。DeepSeek 的 7B 模型在 Q4 量化后大约 4-5GB，14B 模型大约 8-9GB，这样的体积对消费级显卡和 16GB 内存的笔记本都比较友好。

选择模型时，我不建议一上来就追最大参数，而是按你的硬件内存来定：16GB 内存跑 7B 量化模型比较从容，32GB 内存可以尝试 14B 模型，再往上就需要多卡或大显存设备了。Ollama 在拉取模型时会自动选择适合当前硬件的量化版本，你不需要手工指定 Q4 或 Q8，直接使用默认配置即可。

还有一个容易忽略的点：Ollama 拉取的模型会缓存在本地目录，重复部署时可以先看看本地有哪些模型，避免反复下载浪费流量。用ollama list查看即可。

2.2 用命令行跑通 Ollama：模型下载、运行和退出

安装 Ollama 的方式很简单，官网提供 Linux、macOS 和 Windows 三个平台的安装包，装完后服务默认在后台运行。接下来用命令行完成模型拉取和运行，整个过程应该控制在几分钟内。

# 拉取 DeepSeek 7B 模型，Ollama 会自动选择适合硬件的量化版本 ollama pull deepseek-r1:7b # 运行模型，进入交互式对话界面 ollama run deepseek-r1:7b # 列出本地已有的模型，确认是否安装成功 ollama list # 退出对话界面 /bye # 停止模型释放内存，模型文件仍保留在本地 ollama stop deepseek-r1:7b

代码逻辑说明：ollama pull负责下载模型到本地缓存目录，这一步只做网络传输，不消耗太多 CPU；ollama run会加载模型并进入交互模式，首次运行需要等待几秒到几十秒的加载时间，取决于硬盘读写速度和内存。ollama list用于查看本地模型清单，确认模型 ID、大小和已加载状态。

参数说明：模型标签deepseek-r1:7b其中7b是参数量标记，如果你对模型体积有硬性要求，比如磁盘剩余空间不足，可以换用更小的deepseek-r1:1.5b版本，只是对话质量会明显下降。生产环境建议保持 7B 起步。

2.3 让 API 固定可访问：OLLAMA_HOST 与端口绑定

默认情况下 Ollama 只监听本机回环地址127.0.0.1:11434，这意味着只有本机的程序能访问它。后面要接 Open WebUI 和手机端，就必须把它绑定到局域网地址。在 Linux 和 macOS 上，通过环境变量控制：

# 让 Ollama 监听所有网络接口，允许局域网内设备访问 API export OLLAMA_HOST=0.0.0.0:11434 # 启动 Ollama 服务（Linux/macOS） ollama serve

在 Windows 上稍微不同，需要在系统环境变量里新建OLLAMA_HOST，值为0.0.0.0:11434，然后重启 Ollama 桌面程序。如果你用的是 Windows 11，也可以在已运行的 Ollama 托盘图标上右键退出，再重新启动，环境变量会在下次启动时读取。

绑定到0.0.0.0后有一个安全问题：同一局域网内的任何设备都能访问 API，意味着别人可以直接调用你的模型接口。好在 Open WebUI 默认自带账号鉴权，只要先用它做前端入口，不直接暴露裸 API 给手机端，风险就可控。

3. Open WebUI 环境配置：让本地模型有一个可操作的浏览器界面

3.1 直接连 Ollama：Open WebUI 的安装方式与连接参数

Open WebUI 是一个开源的网页界面项目，它通过 HTTP 请求调用 Ollama 的 API，把命令行对话变成图形界面。安装方式推荐用 Docker，因为 Open WebUI 依赖 Python 环境和一堆前端构建产物，自己手动装容易踩版本依赖的坑。前提是你机器上已经装好了 Docker。

# 拉取 Open WebUI 镜像并启动，前后端都跑在 3000 端口 docker run -d \ --name open-webui \ -p 3000:8080 \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ --add-host=host.docker.internal:host-gateway \ ghcr.io/open-webui/open-webui:main

这段命令的参数说明：-p 3000:8080把容器内的 8080 端口映射到宿主机 3000 端口，之后浏览器访问http://localhost:3000；OLLAMA_BASE_URL指定 Ollama 服务地址，host.docker.internal是一个特殊域名，从容器内部访问宿主机时使用，配合--add-host参数在 Linux 上才能正确解析；-v open-webui:/app/backend/data把数据目录挂载到宿主机 Docker 卷，用户账号和聊天记录都存在这里，升级容器不会丢数据。

如果你没装 Docker，也可以用 Python 的 pip 方式安装，但需要确认 Python 版本 >= 3.11，并且建议使用虚拟环境：

# 创建虚拟环境并安装 Open WebUI python3 -m venv webui-env source webui-env/bin/activate pip install open-webui # 启动服务，指定 Ollama 的地址 open-webui serve --host 0.0.0.0 --port 3000

3.2 环境变量与首次启动：关联模型、服务地址、鉴权开关

首次启动 Open WebUI 时，浏览器访问http://localhost:3000，会要求注册第一个账号。这个账号就是管理员账号，之后的所有用户都由它创建，注册入口只会出现一次。

连接 Ollama 时除了OLLAMA_BASE_URL，还需要确认 Open WebUI 是否能在界面的模型列表里看到 Ollama 中的 DeepSeek。如果看不到，检查两种可能：第一，Ollama 服务是否在运行，执行curl http://localhost:11434/api/tags看返回的是否有模型 JSON 数据；第二，OLLAMA_BASE_URL是否配置正确，尤其注意 Docker 容器内不能直接写localhost，要写host.docker.internal。

一个重要提示：如果你在 Open WebUI 环境下开启了用户注册，且绑定了0.0.0.0，那么同网段其他人都可以注册账号并消耗你的模型资源。个人使用建议注册完管理员账号后，在管理面板中关闭用户注册功能，只保留管理员账号，或者给手机端单独创建一个子账号。

# 在 Open WebUI 容器中验证 Ollama 连通性，排查网络层问题 docker exec open-webui curl http://host.docker.internal:11434/api/tags

如果这条命令返回 JSON 列表，说明容器到 Ollama 的网络是通的，问题就出在 Open WebUI 的配置层；如果超时，先去检查宿主机防火墙是否拦截了 11434 端口。

3.3 多模型切换与用户管理：部署完整后的日常使用配置

Open WebUI 界面左上角会有一个模型选择器，能从 Ollama 中加载的模型列表里切换。如果同时拉取了多个规模的 DeepSeek，可以在界面上按需切换，不需要每次切换都去敲命令行。

用户管理方面，在管理员面板——也就是右上角头像处进入——可以分配普通用户、管理员角色。手机端访问建议用一个独立子账号，权限只保留基础对话功能，避免误操作管理配置。对话记录默认保存在 Docker 卷中，换容器版本后重新挂载同一个卷，历史消息不丢。

4. 移动端接入：让手机通过局域网访问本地模型

4.1 移动端不跑模型，只做消息转发

需要先明确一个认知：绝大多数的“移动端部署”，在本地部署语境下不是指在手机里跑推理，而是拿手机当客户端，通过局域网或者远程通道访问你已经部署好的 Ollama + Open WebUI 服务。

手机浏览器访问http://你的电脑局域网IP:3000，输入子账号，就能直接打开和电脑上一样的对话界面。这种方式零安装成本，也不涉及审核问题。如果你希望通知栏推送、离线消息这种原生体验，可以寻找支持自定义服务地址的第三方客户端，但这类客户端大多面向个人开发者搭建的服务，配置起来需要填 API 地址和密钥，反而没有浏览器直接访问省事。

4.2 局域网访问的关键参数：IP 绑定、防火墙放行与端口

手机访问电脑上的 Open WebUI，前提条件有三个，缺一个都不行：

第一，电脑的局域网 IP 是固定可达的，比如192.168.1.100。可以登录路由器后台为电脑分配静态 IP，避免 DHCP 租约到期导致手机下次连不上。

第二，Windows 防火墙要放行 3000 端口。若未放行，手机访问会一直卡在加载中或者直接超时。放行方法：控制面板 → Windows Defender 防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口 → TCP 3000 → 允许连接。Linux 则用ufw allow 3000/tcp或 firewalld 放行。

第三，手机和电脑最好在同一网段，即同一个 WiFi 或同一个局域网交换机。如果跨 VLAN 或跨网段，需要额外配置路由策略，不属于基础部署的范畴。

4.3 证书与密码：Open WebUI 在移动端的安全访问方式

局域网内传输默认是明文 HTTP，如果只是在家用，风险尚可接受。但如果你在公司或公共 WiFi 环境，建议至少做一层密码保护——Open WebUI 的账号系统已经提供了这层保护，但要注意默认情况下不强制 HTTPS。若要强制加密，Open WebUI 可以在反向代理层加证书，比如用 Nginx 或者 Caddy 做 TLS 终结，但这需要额外的域名和证书管理，个人使用可以跳过，后面进阶章节会再提一个更轻量的方案。

5. 多平台部署避坑指南：三个平台最容易翻车的地方

5.1 模型下载到一半中断，再启动却报错

现象：ollama pull执行到 80% 左右网络断开，重新执行拉取命令发现进度从头开始，且偶发校验错误。

原因：Ollama 的模型文件是分块下载的，中断后未完成的块被标记为脏数据，重新拉取时会校验本地缓存，发现不完整就开始重下。但有时脏块校验策略不彻底，导致报错。

解决：删除本地缓存中的对应模型，再重新拉取。执行ollama rm deepseek-r1:7b后重新ollama pull deepseek-r1:7b。如果依然出错，使用ollama pull时加上--insecure参数测试是否是 HTTPS 证书问题，但这只是排查手段，不建议长期使用。

5.2 手机端改了 IP 就连不上，问题不在防火墙

现象：手机昨天还能访问192.168.1.100:3000，今天突然连不上，检查电脑防火墙、Open WebUI 容器都正常，进程也在跑。

原因：大概率是电脑的局域网 IP 变了。路由器 DHCP 默认租约时间可能只有 24 小时，电脑重启后分配到新 IP，手机上缓存的还是旧地址。

解决：在路由器后台将电脑的 IP 绑定到 MAC 地址，实现静态 IP 分配。如果路由器后台没有这个功能，退而求其次——手动把电脑网卡 IP 配置成固定地址，注意不要和局域网内其他设备冲突。

5.3 Open WebUI 界面是英文，或者启动后白屏

现象：打开http://localhost:3000后页面白屏，控制台一堆 404 或者 JS 报错；偶尔界面加载出来但是全英文。

原因：白屏通常是前端静态资源未编译好，常见于 pip 安装方式下版本不匹配；全英文则可能因为浏览器的语言偏好不是中文，或者 Open WebUI 的语言包未随版本更新。

解决：pip 安装的使用open-webui serve --update升级到最新版本；Docker 部署的重新docker pull ghcr.io/open-webui/open-webui:main并重建容器。语言设置在「设置 → 通用 → 语言」里改成简体中文即可，不同版本菜单名略有差异。

5.4 显卡没吃满，CPU 却在疯狂转

现象：跑 DeepSeek 7B 模型时，GPU 利用率只有 30%，CPU 却 100%，对话响应速度明显变慢。

原因：Ollama 默认只在显存不够时才部分卸载到内存，但如果OLLAMA_GPU_LAYERS环境变量没设置，某些硬件配置下会优先用 CPU 推理；还有一个常见原因是显卡驱动太旧，Ollama 无法正确识别 GPU 设备。

解决：在启动 Ollama 前设置环境变量，强制指定 GPU 层数：

# 强制至少 20 层在 GPU 上运行，减少 CPU 负担 export OLLAMA_GPU_LAYERS=20 ollama serve

参数说明：模型层数因模型而异，7B 模型一般在 30 层左右，设置 20 表示 GPU 承载前面 20 层，剩余层在 CPU 上计算。这个值需要根据显存大小反复调整——显卡 8GB 显存可以尝试 20 到 24，4GB 显存建议只让 12 层上 GPU，否则会显存溢出报错。

6. 进阶：把本地模型服务化，给同网段的其他人共享

当你已经能把手机接入本地 DeepSeek 后，下一步的自然需求是让同一局域网的其他设备——比如宿舍同学的笔记本、办公室同事的电脑——也能用上这套服务。最简单的方式是：把 Open WebUI 的访问地址直接分享给其他人，他们用浏览器打开，注册自己的账号即可。

不过当你开始共享，就需要考虑一个资源分配问题。Ollama 同时只能服务一个请求队列中的任务，如果有人跑长文本生成，其他人的请求会排队等待。Ollama 本身不支持并发多模型并行，所以建议限制账号数量，或者在模型选择上让不同人用不同规模的模型，减少冲突。

另一个值得做的配置是给 Open WebUI 加一层便于记忆的访问路径。比如在路由器后台做端口转发，把http://你的电脑IP:3000映射成一个更短的路径，或者用 Home Assistant、Nginx Proxy Manager 这类工具统一管理反向代理。这里我不是推荐具体产品，而是提供一个思路：既然是服务化，就应该把入口收敛，让别人访问的是一个稳定地址而不是一串 IP 加端口。

我自己的习惯是：每台设备部署完整套环境后，第一时间导出 Open WebUI 的配置备份；换机或重装系统后，先恢复备份再拉模型，整个恢复过程不超过十分钟。这也是踩过好几次重装翻车换来的动作。希望这篇部署指南能帮你少走点弯路。

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