企业官网建设流程全解析

简介：面向开发者和技术爱好者的DeepSeek模型部署指南，系统梳理了在PC、手机及浏览器端运行该大模型的具体路径，覆盖Ollama本地部署、移动端快捷方案与Open WebUI容器化集成。资源以1个docx文档打包，压缩包整体约15KB，内容按桌面端、iPhone、Android、Web端四个场景组织，每部分均给出明确的安装命令、依赖配置和官方资源链接。文档详细演示了从拉取DeepSeek-R1模型到终端交互，再到Android设备通过Termux编译Ollama、以及利用Docker部署Open WebUI的完整流程，并包含API Key配置、存储权限设置、服务状态验证等关键细节，可帮助读者避开常见坑点、快速复现多平台部署。指南还解释了模型在本地启动、远程调用和浏览器界面管理中的工作机制，适合想要低成本体验大模型、或将AI能力融入自有业务流程的入门与进阶读者。已有3769人学习下载，对于配置自有设备和搭建轻量级NLP应用具有直接参考价值。

1. 多平台部署 DeepSeek 不是选边站：Ollama 本地、移动端、WebUI 是一条链路的三个出口

多平台环境下部署 DeepSeek 模型，最常见的误区是把 Ollama 本地部署、移动端接入、WebUI 当成三个独立方案去比较。实际它们是同一条链路的三个出口：模型由本地 Ollama 加载推理，对外暴露 HTTP 服务，手机端和 WebUI 都只是客户端。链路打通后，你可以在电脑上敲命令聊，在手机上接续会话，在网页里管理模型，算力始终只在一台机器上。

适合内存 16G 以上、最好有 6G 以上显存的人；想离线使用、不依赖云端，或想在局域网内共享算力的人。需要公网多租户生产服务的团队，应该直接上云 API。

下文先从 Ollama 拉起 DeepSeek 的最小命令讲起，再展开移动端两条接入路线和 WebUI 容器化部署，最后把联调时的高频坑按现象、根因、解法拆开。

2. 本地是起点：用 Ollama 拉起 DeepSeek 的命令、参数与局域网开放

2.1 为什么选 Ollama：量化模型、显存占用与选型对照

Ollama 在这里不是大模型，它是一个推理运行时加模型仓库客户端，帮你把「下载权重、量化、GPU 卸载、上下文缓存」这些脏活封装掉。你只需要ollama pull deepseek-r1:7b，它就会把 GGUF 量化好的文件按层分片拉下来，放在~/.ollama/models下，然后按需把层加载到显存。相比直接用 HuggingFace 那套自己写加载和 offload 脚本的做法，Ollama 的启动成本低得多，而且原生暴露了/api/chat和 OpenAI 兼容的/v1/chat/completions两套接口，移动端和 WebUI 对接时不用再造轮子。

DeepSeek 的 R1 系列是带思维链的推理模型，数学和逻辑场景表现好，但同样的参数量比普通对话模型更吃上下文缓存，选型时不要把显存卡得太死。下表是我在不同机器上跑过的常见标签和资源占用对照，显存需求按权重加 KV cache 的最低估计给，实际还会受上下文长度影响：

选型逻辑我一般这样定：第一次上手从 8b 开始，速度和质量最平衡；显卡只有 6G 显存就老实上 7b 或 1.5b；纯 CPU 机器只建议 1.5b，7b 在纯 CPU 上每秒只能吐出两三个 token，体验接近不可用。显存不足时 Ollama 不会直接报错，而是把超出的层放到内存里跑，ollama ps里能看到 PROCESSOR 列变成 CPU 和 GPU 混合，速度会断崖式下降。

2.2 最小可用命令：拉取、运行、验证一条龙

安装这一步没什么玄学，Linux 和 macOS 都可以用官方安装脚本，Windows 直接下载安装包双击即可。脚本会把 Ollama 注册成后台服务，监听 11434 端口，命令行工具会同步装好。

# Linux/macOS 官方脚本安装；Windows 下载安装包即可，无需此步 curl -fsSL https://ollama.com/install.sh | sh # 验证版本，顺便确认命令是否进 PATH ollama --version

安装完成后 Ollama 默认在后台运行，但只监听127.0.0.1，也就是只有本机能访问。接下来拉模型：

# 拉取 DeepSeek-R1 8B 量化版，标签里的数字是参数量 ollama pull deepseek-r1:8b # 查看本地已有哪些模型 ollama list

ollama pull会分片下载，中断后重新执行会先做完整性校验，已完成的 blob 不会重新下载，所以网络断了别急着删缓存，直接重跑就好。磁盘至少要预留模型体积一倍半的空间，8b 的 Q4 文件大约 4.7G，但临时文件和校验副本会额外占空间。

# 交互式运行，进入对话界面 ollama run deepseek-r1:8b # 非交互方式：直接传一句话，适合脚本和连通性验证 ollama run deepseek-r1:8b "用一句话解释什么是 Docker"

ollama run首次加载模型要冷启动，后面进入常驻状态，默认空闲 5 分钟后被卸载以释放显存。交互界面里可以用/set parameter num_ctx 8192临时调上下文，但这是针对当前会话的，想固化要配合/save生成一个新模型标签，细节放在后面章节展开。

# 查看当前驻留的模型、占用显存和加载位置 ollama ps

这是排查性能问题最该先跑的命令：看 PROCESSOR 列是 CPU 还是 GPU，看 SIZE 列能确定当前模型占用，如果和你预期不符，说明有别的模型占着显存或者参数没生效。

2.3 开放局域网接口：OLLAMA_HOST 与 CORS 配置

默认监听 127.0.0.1 对多平台部署是致命的，因为手机和 WebUI 容器都得通过网络访问这台机器。所以要改绑定地址，让 11434 端口对局域网可见。

# 前台启动并监听所有网卡，测试时用这个最直观 OLLAMA_HOST=0.0.0.0:11434 ollama serve # Linux 上想常驻，用 systemctl 编辑服务配置 sudo systemctl edit ollama # 在 [Service] 段写入 Environment="OLLAMA_HOST=0.0.0.0:11434" 后保存重启

macOS 上用launchctl setenv OLLAMA_HOST "0.0.0.0:11434"设置，然后重启 Ollama 应用；Windows 在系统环境变量里加 OLLAMA_HOST 后重开服务。改完环境变量要重启 Ollama 进程才生效，这是最容易忽略的一步。

# CORS 白名单：局域网用 * 图省事，生产环境建议写具体来源 OLLAMA_ORIGINS="*" OLLAMA_HOST=0.0.0.0:11434 ollama serve

OLLAMA_ORIGINS 是给浏览器用的。后面 WebUI 页面跑在 3000 端口，Ollama 跑在 11434，对浏览器来说这是跨域请求，不配这个变量页面会报 CORS 错误。*适合家庭局域网，公司环境建议写成具体的来源地址。

验证服务是否对局域网可见：

# 本机检查服务状态 curl http://localhost:11434/api/tags # 局域网设备访问（换成你的实际 IP，先在本机确认 IP） curl http://192.168.1.100:11434/api/tags # 用 chat 接口做一次最小调用，确认推理链路正常 curl http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-r1:8b","messages":[{"role":"user","content":"你好"}]}'

第二、三步要在非本机的设备上执行才有意义。返回 JSON 里能看到 model 字段和 message 内容，就说明局域网链路已通。手机浏览器直接打开http://192.168.1.100:11434看到 “Ollama is running” 也算通。

注意：监听 0.0.0.0 意味着同一网段内任何设备都能调用你的模型。如果所在网络不完全可信，用防火墙只放行特定 IP 访问 11434 端口，不要裸奔。

3. 移动端部署：手机本地直跑与局域网远程调用两条路线

3.1 手机上直接跑 DeepSeek：轻量模型与终端方案

手机端目前没有官方发布的 Ollama 客户端，但 Android 平台可以借终端模拟器跑 arm64 版 Ollama，亲测在 12G 内存以上的旗舰机上能跑起来。iOS 平台限制多，不建议本地直跑，直接跳到 3.2 的远程调用更现实。

# 在 Android 终端模拟器里先更新基础环境 pkg update && pkg install curl # 安装 Ollama，arm64 平台脚本会自动识别 curl -fsSL https://ollama.com/install.sh | sh # 拉一个 1.5B 推理模型，这是手机端的现实选择 ollama pull deepseek-r1:1.5b # 开聊 ollama run deepseek-r1:1.5b

手机端 Ollama 装好后同样监听 11434，手机上访问 127.0.0.1:11434 即可。1.5b 在旗舰机上大约每秒几十个 token，日常问答够用，但发热和耗电非常明显，连续对话二十分钟以上会触发系统温控降频，速度掉到原来的三分之一。所以手机直跑定位是碎片化问答，别拿它做长文档分析。

多数人其实不需要在手机上装 Ollama，更实用的路线是装一个支持自定义接口的对话 App，把接口地址填成电脑的http://192.168.x.x:11434/v1，模型名填deepseek-r1:8b，手机就变成了一个纯终端，算力全在电脑上。这条路线的体验和稳定性都远好于手机直跑。

3.2 远程调用路线：让手机连上局域网里的 Ollama 服务

走远程调用需要满足三个前提：电脑上的 Ollama 已经监听 0.0.0.0（2.3 节做完的事）；手机和电脑在同一局域网；电脑防火墙放行了 11434 端口。三者缺一，现象就是手机连不上或者超时。

# 在手机上用终端类工具发一条请求，验证链路是否真的通 curl http://192.168.1.100:11434/api/chat \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-r1:8b","stream":false,"messages":[{"role":"user","content":"手机远程测试"}]}'

这里刻意加了"stream":false，让服务端一次性返回完整 JSON，比流式更容易判断链路是否正常。判断标准是 HTTP 状态码加返回结构，看到"message":{"role":"assistant","content":"..."}就说明整条链路通了，不用等流式分片。

两种手机接入方式各有取舍：

远程调用最大的收益是手机不考虑显存，电脑上跑 14b 甚至 32b 都行，手机只负责收发文本。代价是依赖局域网稳定性和电脑持续开机，电脑进休眠、手机切网络，连接立刻断。这个路线不要开放到公网，公网访问涉及安全策略，不在本文范围。

3.3 移动端参数取舍：模型大小、上下文长度与连接稳定性

移动端是最容易在参数上踩坑的场景：上下文开太大，显存被 KV cache 吃光，推理慢到怀疑人生；模型选太大，手机直跑直接烫手。我整理了一张按场景选的对照表：

num_ctx 的设置方式：交互式对话里先/set parameter num_ctx 8192，再/save myds14b固化成一个新模型标签，以后用ollama run myds14b就能保持这个上下文长度。全局默认值则用环境变量 OLLAMA_CONTEXT_LENGTH，但它影响所有模型，不建议和不同场景混用。

移动端连接稳定性有三条血泪经验。第一条，手机锁屏后 Wi-Fi 进入省电模式，TCP 长连接会被系统断开，解决方法是给对话 App 关闭电池优化，保持后台联网权限。第二条，电脑休眠等于服务下线，部署期间把电源计划设成插电不睡眠。第三条，模型空闲 5 分钟后被 Ollama 卸载，手机再打开时第一次请求要重新加载模型，几十秒没响应很正常，这是冷启动，不是故障，后面章节会给常驻配置。

4. WebUI 部署：用 Docker 把 DeepSeek 变成浏览器里的对话服务

4.1 WebUI 选型：Open WebUI 与轻量化替代怎么选

WebUI 解决的是「没有客户端也能用」的问题：浏览器打开一个地址，注册账号，就能像用云服务一样对话，还能切换模型、管理会话。自部署方案里最常见的是 Open WebUI，它的后端默认对接 Ollama 的接口，配置一条环境变量就能联调，同时自带了多用户权限和服务端会话存储。

选型本质上是在问自己三个问题：要不要多用户、要不要服务端存会话、要不要 Docker。单机自己用，轻量方案足够；要在局域网给几个人共用，Open WebUI 省心得多。

我一般只在临时演示时用轻量方案，日常部署都走 Open WebUI。它还有一个好处：模型管理在 Ollama 侧，WebUI 自动发现，拉一个新模型刷新页面就会出现，不用改任何配置。

4.2 用 Docker 部署 Open WebUI 并接上 Ollama 的完整命令

前置条件只有两个：Docker 已安装；Ollama 已在宿主机正常运行并监听 11434 端口。这里最容易翻车的是「容器里的 localhost」——容器里访问 localhost 指向容器自己，不是宿主机，所以必须用 host 网桥或真实 IP 来指路。

# Linux 上部署 Open WebUI，注意 --add-host 是 Linux 的关键配置 docker run -d \ --name open-webui \ -p 3000:8080 \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main # 跟踪启动日志，看到运行日志说明启动完成 docker logs -f open-webui

参数说明：-p 3000:8080把容器内 8080 映射到宿主机 3000，浏览器访问 localhost:3000；OLLAMA_BASE_URL告诉 WebUI 去哪个地址找 Ollama；--add-host=host.docker.internal:host-gateway是 Linux 上的必需项，它把容器内的 host.docker.internal 指向宿主机网卡，macOS 和 Windows 的 Docker Desktop 自带这个解析，可以不加；-v open-webui:/app/backend/data持久化账号、会话和配置，容器删了数据还在；--restart always让容器跟随 Docker 自启。

启动后浏览器打开http://localhost:3000，第一次注册的账号就是管理员，这一步没有验证码，局域网里谁先注册谁是管理员，所以部署完第一件事就是去设置里关闭开放注册。

# 确认 Ollama 里已有模型，WebUI 会自动发现 ollama list # 确认 WebUI 日志里没有连接错误 docker logs open-webui 2>&1 | grep -i ollama

如果 WebUI 页面模型列表为空，回宿主机ollama pull拉好模型，刷新页面就会出现。不用 Docker 的替代做法是pip install open-webui，但依赖本机 Python 和 Node 环境，升级维护成本高，我一般只在没法装 Docker 的机器上应急用。

4.3 模型切换、权限设置与连通性验证

WebUI 顶部有模型下拉框，列出的就是 Ollama 里所有已拉取的模型，切换随时生效。新模型只需在宿主机执行ollama pull deepseek-r1:32b，刷新 WebUI 列表即出现，这是整套链路里最顺滑的一环。

权限上我的建议很明确：局域网多人共用时，让手机和电脑都走 WebUI 的 3000 端口，而不是直连 Ollama 的 11434。原因是 WebUI 自带账号体系，你可以关闭开放注册、给每个人建账号；裸 API 则没有任何身份校验，网段内任何人拿到地址就能调你的模型。

# 脚本化验证走 Ollama 的 OpenAI 兼容接口，WebUI 底层也是同一套 curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-r1:8b","messages":[{"role":"user","content":"你好"}]}'

返回 JSON 里choices[0].message.content有内容就算通。WebUI 页面上能发消息、模型下拉框里有模型、日志无异常，联调就算完成。

5. 多平台部署避坑记录：5 个高频问题的现象、根因与解法

5.1 模型拉取中断，重新运行总是从头开始

现象：ollama pull到 60% 断掉，再次执行后进度条又从头滚，等半天还在原地。

原因：拉取是分片下载，中断后重新执行先做完整性校验，校验期间进度条会从 0 重新计数，看起来像从头下载，实际上已完成的 blob 还在本地。但如果网络持续抖动，会在同一个分片反复卡住，直观表现就是一直停滞。

解决：别手动删~/.ollama/models下的临时文件，直接重新执行ollama pull等它校验跳过。如果反复在同一个进度点失败，换更小参数模型或更低量化标签减小体积；边拉模型边跑大任务是坏习惯，磁盘 IO 被占满会加大失败概率。

5.2 WebUI 报 connection refused，Ollama 明明在跑

现象：Docker 容器起来了，WebUI 页面能打开，但一发消息就提示连不上模型，日志里出现connection refused。

原因：容器里的 localhost 是容器自己，不是宿主机；或者 Linux 上没加--add-host=host.docker.internal:host-gateway，导致OLLAMA_BASE_URL=http://host.docker.internal:11434解析不到宿主机。

解决：先在容器里验证宿主机是否可达：

# 容器内测试宿主机 Ollama，返回 JSON 或空都不是 refused 才是问题 docker exec open-webui sh -c \ "curl -s http://host.docker.internal:11434/api/tags || echo CONN_REFUSED"

如果确认 refused，把OLLAMA_BASE_URL改成宿主机真实 IP 重建容器：

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

改成真实 IP 是绕过容器网络解析问题最稳的办法，缺点是你换网段后要重建容器，所以家庭动态 IP 场景反而推荐用 host.docker.internal 加 host-gateway 的组合。

5.3 浏览器控制台报 CORS 错误，WebUI 界面一直转圈

现象：WebUI 页面加载正常，但一发消息接口就失败，浏览器控制台有明显的 CORS 拦截提示，Ollama is running页面又能打开。

原因：WebUI 跑在 3000 端口，Ollama 跑在 11434，对浏览器来说跨域了。Ollama 默认只允许 localhost 来源，必须显式配置OLLAMA_ORIGINS。

解决：在启动 Ollama 的环境里设置并重启：

# 局域网省事方案 export OLLAMA_ORIGINS="*" # 精确控制方案，只放开 WebUI 的来源 export OLLAMA_ORIGINS="http://localhost:3000,http://192.168.1.100:3000" # 重启 Ollama 服务让环境变量生效 ollama serve

改完必须重启 Ollama 进程，只写进配置文件不重启等于没改。这个坑在 macOS 上尤其容易踩，因为 Ollama 常驻用的是 launchd，环境变量改完要重启应用或执行launchctl kickstart。

5.4 显存明明够，却一直走 CPU，推理慢得离谱

现象：模型能正常回答，但速度只有每秒几个 token，ollama ps里 PROCESSOR 列是 CPU 或 CPU/GPU 混合。

原因：三个常见来源。一是其他程序把显存占了，模型放不下只能落内存；二是模型需求超过显存，Ollama 把超出部分放内存，这是量化选型问题；三是显卡驱动不带 CUDA 支持，Ollama 根本没识别到 GPU，装驱动前白折腾。

解决：先跑ollama ps看模型实际加载位置和显存占用，再查系统监控确认显存余量。模型太大就换小参数量或低量化版本，比如 8b 换 7b-q4_0；关掉浏览器硬件加速和其他占显存的应用；新装系统先确认显卡驱动完整，再装 Ollama，顺序反了会白跑一套流程。NVIDIA 机器在ollama --version输出里能看到 GPU 相关信息，没有就是驱动层的问题。

5.5 手机远程访问时断时续，第一次响应总是特别慢

现象：手机上午用得好好的，过会再打开，要么连不上，要么等了一分钟才出第一个字，来回折腾很烦。

原因：三个因素叠加。默认keep_alive只有 5 分钟，模型空闲 5 分钟后被卸载，冷启动要重新加载模型；手机锁屏后 Wi-Fi 进入省电模式，长连接被系统断开；电脑休眠或网络切换，整个服务就失联了。

解决：按顺序排查。电脑端设置OLLAMA_KEEP_ALIVE=-1让模型常驻，代价是显存一直占着；设置OLLAMA_NUM_PARALLEL提高并发，应对多设备同时连接；手机端给对话 App 关闭电池优化；最后把电脑电源计划设成插电不睡眠。90% 的手机掉线问题都在这三条里，先解决电脑端的两条，再解决手机端的一条。

6. 从"能跑"调到"好用"：连通性验证、并发参数与日常检查

6.1 三层连通性验证脚本

每次改完配置，我会按三层顺序验证，能定位 90% 的问题出在哪一层：

# 第一层：本机服务是否正常 curl -s http://localhost:11434/api/tags | head # 第二层：局域网设备能否访问（手机、另一台电脑上执行） curl -s http://192.168.1.100:11434/api/tags | head # 第三层：WebUI 页面发一条消息，看回显和模型列表

本机通、局域网不通，查防火墙和绑定地址；局域网通、手机不通，查防火墙出站规则和手机网络；手机浏览器通了但 App 不通，查 App 里填的 Base URL 和模型名。链路分层排查比乱重启服务高效得多。

6.2 三个最值得调的参数

这三个参数配合表：并发开大又想让模型常驻，显存余量至少要够模型本身加两倍上下文的缓存，否则模型会被迫卸载或降级到 CPU，得不偿失。

6.3 我的固定检查习惯

整套多平台部署做完，我每天的收尾习惯固定是三步：先ollama ps看一眼驻留模型和显存占用，再用手机浏览器走一遍真实链路发一条消息确认连通，最后翻一眼服务日志看有没有反复报错。最大的教训是别让手机长期直连 11434 的裸 API，没有身份校验，管理和安全都不可控，统一走 WebUI 一层才是正路；另一个教训是环境变量改了不重启等于白改，这个坑我踩过不止三次。希望帮到你。

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