简介：针对DeepSeek大规模模型的多环境部署，此份15KB的docx文档提供了一套跨平台操作指南。资源面向希望将AI模型落地到本地电脑、手机或浏览器场景的开发者、研究者及技术爱好者，覆盖Ollama本地部署、iPhone与Android移动端接入、Docker+Open WebUI浏览器访问三条路径。内容既包含macOS、Linux、Windows下Ollama从官网安装到终端拉取模型的完整命令，也详解iPhone快捷指令绑定API Key的配置步骤，以及Android在Termux中更新软件包、安装依赖、编译Ollama并运行DeepSeek R1模型的具体过程；同时介绍基于Docker Desktop部署Open WebUI，通过浏览器选择DeepSeek模型并开始对话的操作细节。文档以1个docx文件打包，容量仅15KB，结构紧凑、命令明确，并附有相关官方链接，便于查阅更新。目前已有3769人学习下载，适合需要快速验证DeepSeek能力或搭建跨平台AI服务的专业人士，也适合希望深入理解模型部署与运行机制的爱好者。
1. 多平台 DeepSeek 部署到底在解决什么问题
在云平台排队、页面转圈、请求被限流之后，越来越多团队开始认真考虑把 DeepSeek 模型放到自己可控的环境里跑。最常见的诉求并不是“我要训模型”，而是“我要在不同设备上稳定地用同一个模型”——公司电脑上随时问答、手机上出门也能用、浏览器里还要有完整的聊天界面。这其实就是标题里说的“多平台环境下 DeepSeek 部署”：用 Ollama 做本地推理底座，把模型装进一台主机，再通过 Open WebUI 补上网页端，最后让手机通过局域网甚至安全的外网入口访问。
这篇文章适合两类人：一类是想在办公网内部署私有模型、又不想被各家云平台接口绑定的工程师；另一类是手里有 GPU 或高配主机、希望把 DeepSeek 变成“自己服务”的个人开发者。我会把选型理由、最小命令、参数细节和踩过的坑一起讲清楚，照着走，大概一小时能把三端全跑通。
2. Ollama 本地部署：选型、最小命令与存储调整
2.1 为什么先选 Ollama 当本地底座，而不是 vLLM 或 llama.cpp
DeepSeek 官方在部署建议里常提到 vLLM，尤其在追求高并发、大批量请求的生产环境里，这没有错。但 vLLM 的完整形态对工程要求不低：你要理解 PagedAttention 这类显存优化机制，要处理张量并行拆分，还得自己设计模型加载队列。对于“团队内部几个人用”甚至“个人使用”的场景，这一整套东西远远超出实际需求。
llama.cpp 是另一条线，适合纯 CPU 推理、嵌入式设备、或者你希望直接用 GGUF 单文件跑模型的场景。但它的多平台接入能力偏弱，在移动端和 WebUI 生态里，多半还得自己搭一层 API 壳。
Ollama 真正占便宜的地方是两点。第一，它把模型管理、量化选择、服务监听和 OpenAI 兼容接口全部封装好了，一条命令拉模型、一条命令起服务，实践成本极低。第二，它在开发者和开源社区里的生态很拥挤，Open WebUI、Dify、各类移动客户端几乎原生适配它，这就省掉了“自己在手机端写协议适配”的大量工作。
所以我的常见选择是：个人开发者、中小团队、以及“把 DeepSeek 部署成公司内部服务”这类场景，默认用 Ollama 当底座；只有当并发量到几十甚至几百、必须上多卡推理管线时，才转向 vLLM。下文的所有部署方案，也都以 Ollama 作为唯一推理后端来展开。
2.2 最小可用命令：安装、拉模型、跑会话
在 Linux 主机上，Ollama 的安装非常省事。官方提供了一键脚本，适用于绝大多数常见发行版。如果是 Windows 或 macOS，也可以直接从官方站点下载对应安装包，但后续所有命令和目录结构对得上，没有本质区别。
# 在线安装（Linux/macOS 通用） curl -fsSL https://ollama.com/install.sh | sh # 启动服务，默认监听 127.0.0.1:11434 ollama serve & # 查看版本，确认安装成功 ollama --version # 拉取 DeepSeek 蒸馏模型（7B 量化版） ollama pull deepseek-r1:7b # 跑一句对话，验证从拉取到推理的全链路 ollama run deepseek-r1:7b "用 Python 实现一个快速排序，并解释关键行"这段命令里，ollama serve是核心。它会启动一个监听在11434端口的本地服务，后续 Open WebUI、移动端、API 调用全部走这个端口。ollama pull里的deepseek-r1:7b表示拉取 7B 参数的蒸馏版，默认量化格式对大多数消费级显卡友好，显存占用大概在 4～6GB。如果你手里是 24GB 显存以上的机器，可以换deepseek-r1:14b或更大参数版本，推理质量会明显更好，但响应速度也会成比例下降。
这里有个新手容易忽略的点：ollama run之后，模型虽然已经加载，但服务不会自动常驻后台。我用ollama serve &把它放到后台，技能不够稳就交给 systemd 托管，后面第五节会讲。第一次拉模型时如果发现下载速度很慢，先别急着反复重试，优先检查默认仓库的连通性，或者直接走 2.3 节的离线包方案。
2.3 模型存储路径迁移与离线包：解决“C盘爆了”和“内网拉不动”
ollama pull默认会把模型文件存到用户主目录下，Linux 是~/.ollama/models，macOS 是~/.ollama/models，Windows 在C:\Users\<用户名>\.ollama\models。模型动辄几个 GB，系统盘空间很容易被吃尽。“修改模型存储路径”几乎是每个部署过的人都会遇到的需求，在 Linux 系统里，常见的做法是给 Ollama 的 systemd 服务注入一个环境变量。
# 假设新增了一块数据盘 /data mkdir -p /data/ollama/models # 把已经下载的模型目录搬过去 mv ~/.ollama/models /data/ollama/models # 通过 systemd override 注入环境变量 sudo systemctl edit ollama在打开的编辑窗口里写入以下内容，然后保存退出：
[Service] Environment="OLLAMA_MODELS=/data/ollama/models"sudo systemctl daemon-reload sudo systemctl restart ollama # 验证新的存储路径是否生效 ollama list如果ollama list还能看到原有模型，说明搬迁成功；如果列表空了一截，大概率是环境变量注入的位置不对，或者旧目录没完全移动过去。另一种常见场景是完全离线的内网服务器，没法直接访问模型仓库。应付这种情况，我一般会在能联网的机器上拉好模型，然后把整个models目录打包拷贝过去：
tar -czf ollama-models-backup.tar.gz ~/.ollama/models拿到目标机器后解压到对应位置，再设置OLLAMA_MODELS指向它，最后重启 Ollama。注意模型文件本身和目录结构要完整保留，不要只拷单个.bin文件，否则服务启动后可能读不到索引，这个问题自己手动打包的人很容易踩到。
3. 用 Open WebUI 把 DeepSeek 变成网页应用：Docker 部署与联通
3.1 WebUI 选型：为什么优先考虑 Open WebUI
Ollama 本身只提供命令行交互，真正面向日常使用的还得是网页界面。市面上接入 Ollama 的 WebUI 不少，最常拿来做对比的是 Dify 和 LobeChat。Dify 的核心定位是“LLM 应用编排平台”，更适合做知识库、工作流和 Agent 类的复杂应用，部署结构也更重，不仅依赖 API 服务，还要配套数据库。LobeChat 偏 C 端体验，界面漂亮、插件丰富，适合个人玩具或展示项目，但它对本地模型的深度控制弱一些，很多高级配置要绕到设置项背后去改。
Open WebUI（有段时间叫 Ollama WebUI）从一开始就是跟着 Ollama 的需求长起来的，它最大的价值是和本地推理引擎的匹配度：
- 安装时只要指定 Ollama 的 API 地址就能直接对话；
- 页面里可以实时切换本地已下载的不同模型，不需要改配置；
- 自带会话管理、附件上传、Markdown 渲染和权限控制；
- 默认模型列表通过 Ollama API 自动拉取，不需要手填模型名。
对大多数团队来说，Open WebUI 是最省心的一条路：精心装饰可能不如 LobeChat，复杂编排能力不如 Dify，但它覆盖了“把 DeepSeek 部署成多平台可访问服务”这个目标里最高的比例。如果后续要做知识库和 workflow，再在其上叠加 Dify 也不迟。
3.2 用 Docker 部署 Open WebUI 的最小配置
Docker 方式部署 Open WebUI 是最常见的模式，因为镜像环境相对干净，升级也方便。如果目标机器没有 Docker，先装好 Docker Engine 和 Docker Compose 插件，再执行下面这套配置。
# 创建一个 compose 文件 mkdir -p ~/open-webui && cd ~/open-webui cat > docker-compose.yml << 'EOF' services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: always ports: - "3000:8080" volumes: - ./data:/app/backend/data environment: - OLLAMA_BASE_URL=http://host.docker.internal:11434 extra_hosts: - "host.docker.internal:host-gateway" EOF docker compose up -d这里需要解释一个关键点：容器内部无法直接用localhost访问宿主机的 Ollama，因为localhost指向的是容器自己。OLLAMA_BASE_URL把它指到host.docker.internal这个 Docker 提供的特殊域名，再由extra_hosts将它映射回宿主机的网络栈，这样容器就能访问到宿主机的11434端口。
./data卷用来持久化 Open WebUI 的配置、会话记录和上传文件。如果删掉容器重来，只要这个目录还在，聊天记录就不会丢。首次启动后，浏览器访问http://服务器IP:3000，填管理员账号完成初始化，然后在设置里找到模型选择，确认能看到本地已经拉取的 DeepSeek 模型。看不到模型的排查方法，在 3.3 节和 5.2 节会专门讲。
3.3 联通配置：OLLAMA_BASE_URL、宿主监听地址与模型列表
很多人在完成 Docker 安装后卡在“页面打不开”“模型列表是空的”这些环节，大部分问题出在联通配置上。Open WebUI 通过两个维度感知模型：一个是OLLAMA_BASE_URL指向的 API 地址，另一个是 Ollama 自己的监听配置。
先检查宿主机上 Ollama 是否监听了所有网卡地址。默认情况下，Ollama 只绑定127.0.0.1:11434，容器通过host.docker.internal访问时实际走的还是宿主机的回环接口，所以通常没问题。但如果同一个 Open WebUI 要连接另一台机器上的 Ollama，那么那台机器的 Ollama 必须改成监听指定局域网地址：
# 让 Ollama 监听所有网卡 OLLAMA_HOST=0.0.0.0:11434 ollama serve注意不要漏掉模型列表的“模型开关”这一步。Open WebUI 默认会把 Ollama 里所有模型都拉进来，但部分版本在模型选择时有“启用/停用”的隐藏逻辑。打开页面左上角模型选择器，确认 DeepSeek 模型已经被勾选。如果仍然为空，最简单的方法是看宿主机上ollama list是否有输出，再确认OLLAMA_BASE_URL环境变量是否拼写正确、容器是否重新启动过。
还有一个容易被忽略的细节：Open WebUI 的OLLAMA_BASE_URL只负责后端调用，前端浏览器的资源加载走的是3000端口，同一台机器的防火墙需要放开3000端口对外访问，否则从其他电脑或手机打开页面会卡在空白界面。这个坑很多人容易误判成 API 配置问题，其实只是端口没有放行。
4. 移动端接入 DeepSeek：三种方案与局域网访问配置
4.1 方案怎么选：移动浏览器、原生 App 还是 API 直连
移动端接入 DeepSeek 的方案，落到实践层其实就是三选一：直接打开手机浏览器访问 Open WebUI；安装第三方 Ollama 客户端；或者在自己的应用里调 Ollama/Open WebUI 的接口。三者的使用范围不同，成本和体验也差别很大。
移动浏览器访问是最省事、最稳的一条路。只要电脑上已经把 Open WebUI 跑起来，手机和电脑在同一局域网内，浏览器输入http://<主机IP>:3000就能用。所有会话、模型切换、文件上传能力都保留，不需要额外装任何 App。适合团队内部快速验证、临时演示这种轻量场景。
原生 App 的体验最好，手机上有独立入口、消息推送、本地会话管理，整体感觉更像一个“真正的应用”。但它需要依赖社区客户端对 Ollama API 的兼容程度，不同客户端对模型能力的支持并不一致，遇到问题也难以快速排查。适合个人长期使用，但不太适合在企业内部统一推广。
API 直连要留给有研发能力的团队。Ollama 提供了 OpenAI 兼容接口，Open WebUI 也暴露了后端 API，移动应用直接以/v1/chat/completions的格式请求即可。这样做的好处是完全掌控产品体验，代价是需要自建鉴权、并发控制和服务端监控。如果团队目标是做出一个对外产品，从第一天就该按这个路子设计，WebUI 和本地客户端反而只适合做内部演示。
4.2 让手机在同一局域网内访问 Ollama：防火墙与端口准备
手机能顺利访问的关键是“入口一致、端口畅通”。我推荐统一以 Open WebUI 的3000端口作为移动端的唯一入口，而不是把 Ollama 的11434端口开放给手机。直接暴露 Ollama API 的问题在于，它没有任何身份认证，任何拿到端口的人都能发起对话请求，在可控性上是灾难。
# 查看宿主机在局域网里的 IP（Linux） ip -4 addr show # macOS 查 IP 的方式 # ipconfig getifaddr en0 # 如果开了 ufw，放行 WebUI 端口 sudo ufw allow 3000/tcp # 如果用的是 firewalld（CentOS/RHEL 系常见） sudo firewall-cmd --permanent --add-port=3000/tcp sudo firewall-cmd --reload完成上述操作后，手机和主机连同一个 Wi-Fi，手机浏览器访问http://192.168.x.x:3000，正常情况下会出现 Open WebUI 登录页。这一步里最常见的失败原因是“主机和手机不在同一网段”，例如手机走的是 4G/5G 蜂窝网络，或者路由器开启了 AP 隔离。验证方法很简单：在手机浏览器里直接 ping 主机 IP 不现实，看主机的 IP 网段和手机在路由器管理页里的 IP 是否属于同一段即可。
如果公司网络有更严格的安全策略，比如不同业务网段之间默认禁止互访，那就需要找网络管理员给主机所在网段和移动网段之间放行端口，这种情况下自己临时改防火墙往往踢到铁板。
4.3 如果要出门也能用：安全前置与常见习惯
“移动端部署”到这里，很多人的下一步是把服务暴露到公网，期望手机在外网也能访问。这个需求合理，但一定不要在公网裸奔 Ollama 或 Open WebUI，尤其是直接做全端口映射。团队内部一般会采用两层结构：外层是可信入口（比如带访问控制的安全网关、云服务的安全组白名单），内层才放 Open WebUI；Ollama 始终只监听内网，不参与对外通信。
安全组的配置逻辑是：把3000端口只放行到你们办公室出口 IP 或已知可信 IP 段，其他来源一律丢弃。这一步要配合 HTTPS 使用，至少保证登录过程不经过明文，否则管理员账号密码很容易在中间环节被截获。如果你只是个人使用，最简单的办法是把访问限制在自家路由器内网，外面有没有需求，就提醒自己“没必要做的，不做就不会坏”。
5. 避坑清单：从下载缓慢到 GPU 吃不满的 5 类现场问题
5.1 模型一直卡在“拉取镜像”，进度条不动
现象：执行ollama pull deepseek-r1:7b后，长时间停在pulling manifest或显示极慢，进度条几乎不动。
原因：默认仓库的连通性受网络环境影响很大。国内网络环境下访问外部镜像源经常出现连接不稳定，内网服务器更是如此，DNS 解析超时也比较常见。
解决：优先用离线包方案，在公司内网里这是最稳的解法。如果你只是单机网络慢，可以考虑更换可用的镜像仓库地址，这是社区常见的做法，但镜像地址的可用性和时效性都变化快，不适合作为长期依赖。更稳妥的长期方案是找一台网络正常的机器把模型拉好，按第二节的tar打包方式复制到目标主机。别反复重试同一个下载任务，连续重试大概率还是同一个结果。
5.2 Open WebUI 容器里连不上 Ollama
现象：Open WebUI 页面能打开，但新建对话后直接提示 “connection refused” 或 “Ollama 服务不可用”。
原因：OLLAMA_BASE_URL被设置成了http://localhost:11434，容器里访问的是容器自己的回环地址，压根摸不到宿主机。
解决：确认 Dockerfile 里环境变量指向http://host.docker.internal:11434，并补齐extra_hosts配置。如果使用--network host模式启动容器，那反而可以直接用http://127.0.0.1:11434，因为容器共享宿主机的网络命名空间。调整完毕后先重启容器，再确认宿主机ollama list能正常输出，最后回 WebUI 刷新页面。
5.3 手机访问时白屏、超时或“拒绝连接”
现象：电脑上打开 Open WebUI 完全正常，同一台主机换成手机访问就白屏或连接超时。
原因：最常见的是手机的网段与主机网段不一致，其次是 3000 端口被防火墙拦截。还有一种情况是路由器的 AP 隔离或访客网络策略阻止了设备间互访。
解决：先核对主机 IP 与手机 IP 是否在同一网段，例如都处于192.168.1.x。接着在手机上用http://<主机IP>:3000而不是http://localhost:3000。最后检查宿主机防火墙和路由器策略。如果是公司网络下的多网段场景，不要试图自己改防火墙硬破，直接找网络管理员开端口。
5.4 GPU 没吃满，生成速度上不去
现象：部署在带 N 卡的机器上，却发现生成速度很慢，CPU 占用很高，GPU 利用率反而低。
原因：Ollama 对 NVIDIA GPU 支持依赖驱动版本和 CUDA 环境。如果显卡驱动太旧、显存不够，或者 Ollama 启动时没识别到 GPU，它会自动回退到 CPU 推理。
解决：先运行ollama ps查看当前模型是否标注为GPU或CPU/GPU，再看输出里有没有明确提到100% GPU。如果显示 CPU 推理，就检查驱动是否正常，安装适配当前内核的 NVIDIA 驱动，然后重启 Ollama。也可以临时设置OLLAMA_NUM_GPU=1强制启用一张卡，但这个参数要谨慎，显存不足时反而会因为换页把性能拖垮。
5.5 修改存储路径后模型全部“消失”
现象：给 systemd 服务注入了OLLAMA_MODELS环境变量，重启后ollama list输出为空，之前拉好的模型全不见了。
原因：新路径下是空的，旧路径下虽然有模型文件，但服务已经不再索引旧目录。
解决：在切换环境变量之前，先把原~/.ollama/models完整移动到新目录。如果已经忘了一步，直接ollama run触发重新下载，等于把时间浪费在一次全量下载上。更好的做法是高危操作前先备份models目录。如果你是通过移动硬盘或挂载盘切换，也确认新路径挂载正常、有读写权限，systemctl edit注入环境变量的方式比直接改/usr/lib/systemd/system/ollama.service更不容易被升级覆盖。
6. 把三端串起来：一套能直接用的启动脚本与验收方法
前面每个环节单独跑通后，剩下的工作就是把这些碎片拼成一个可重复执行的部署脚本。下面这版脚本是我在类似环境下常用的收尾形态，适合 Linux 主机加 Docker 的场景，拆开每一步都能独立运行。
#!/usr/bin/env bash set -e # 1. 指定模型存储路径，避免系统盘爆掉 export OLLAMA_MODELS=${OLLAMA_MODELS:-/data/ollama/models} export OLLAMA_HOST=0.0.0.0:11434 # 2. 安装并启动 Ollama（联网环境） if ! command -v ollama &> /dev/null; then curl -fsSL https://ollama.com/install.sh | sh fi ollama serve & sleep 3 # 3. 拉取 DeepSeek 模型 ollama pull deepseek-r1:7b ollama list # 4. 部署 Open WebUI cd ~/open-webui docker compose up -d # 5. 验收 curl -s http://127.0.0.1:11434/v1/models验收时我有两个固定动作。第一个是确认curl http://127.0.0.1:11434/v1/models输出里包含 deepseek 模型名，这代表 Ollama 侧正常。第二个是从手机浏览器打开http://<主机IP>:3000，完整走一遍登录、选模型、发消息三个动作，这代表整条链路真正通起来了，而不是只看页面加载成功就急着收工。
这套方案看起来简单，但实际部署时真正占用时间的往往不是命令本身，而是网络环境、防火墙策略和各类环境变量的细节。我自己的习惯是先把每个端口单独验证明白，再组合成脚本，避免把一次失败归因成复杂的多因素问题。如果你也跟着搭到一半卡住了，回到对应章节对着现象找原因，大概率比重新随机试配置要省时间。希望帮到你。
本文还有配套的精品资源，点击获取
