简介：《DeepSeek多平台部署指南：Ollama本地、移动端及Open WebUI环境配置》面向技术开发者、研究人员与AI爱好者，聚焦DeepSeek模型在桌面端、iOS/Android手机端及Web界面落地时的环境准备、工具协同和配置校验问题，适合具备一定命令行基础、希望系统梳理跨平台部署路径的读者。压缩包内仅含1个docx文档，整体约15KB，以部署说明、命令示例和关键链接组织内容，便于按平台检索与对照阅读。文档覆盖Ollama本地运行、iPhone快捷指令接入、Android端Termux环境搭建，以及Docker Desktop与Open WebUI配合使用等方案，并对组件依赖、服务启动验证、模型拉取与对话测试等关键节点给出说明；同时提示API Key填写、Ollama初始化检查等易错环节，有助于降低多端环境搭建中的反复试错成本。已有4127人学习，可作为快速了解多端部署思路、厘清工具链关系与查漏补缺的参考材料。

1. 从一次「模型下下来了但跑不起来」说起

DeepSeek 多平台部署这件事，看着是三套独立方案，实际卡人的地方高度重合：版本和 tag。我见过最典型的一次，Ollama 本地环境装好了，ollama run deepseekr1:8b直接回一句 manifest 不存在，人当场愣住——软件没坏，是仓库名少了一个连字符。同一份笔记里，Android 那边写的是termuxsetupstorage，真到 Termux 里敲下去是 command not found。这类问题不会在教程里写，只有装过一遍才知道。

这篇按我自己的落地顺序走：先定版本和硬件，再把 Ollama 本地跑通，然后挂 Open WebUI 做图形界面，最后处理 iPhone 快捷指令和 Android Termux 手编译这两条移动端路线，中间单开一章讲翻车排查。适合手里有台 16G 内存以上的机器、想把这套跨平台支持真正跑起来的人。

2. 装前定版：硬件门槛、模型 tag 与 Ollama 安装

动手之前有两件事必须先定死：跑哪个规模的模型、装哪个版本的 Ollama。这两件事定错了，后面所有步骤都白费。我一般不会先装软件，而是先把硬件账算清楚——本地部署最容易翻车的地方不是命令敲错，是模型下到 90% 发现内存装不下。

2.1 先按内存选模型规模，别按喜好选

DeepSeek-R1 在 Ollama 模型库里是一整个系列，从 1.5b 到 671b 都有，日常能落地的集中在前五档。量化之后的实际占用和标称参数量差得挺远，按下面这张表对号入座基本不会错：

这张表里 7b 和 8b 是最容易让人纠结的两个。它们不是同一个东西：7b 基于另一套蒸馏底座，8b 是另一套，体积接近但回答风格有差异。我一般建议先用 7b 把流程走通，等 Open WebUI 和 API 都验证过了，再决定要不要换 8b 对比。1.5b 只用来验证链路，不要拿它当生产力，回答质量差得比较明显。

至于 671b 那档，参数文件几百 GB，普通机器连下载都费劲，本地部署这条路基本可以跳过。真需要那个量级的输出，走云端 API 更现实——后面 iPhone 快捷指令那节讲的就是这条路线。

提示：上表里的"可用内存"指模型加载时能被系统调度的内存，不是硬盘剩余空间。内存刚好卡在临界值的时候，系统其它进程一抢就会触发换页，回答速度会掉到几秒一个字。

2.2 三个桌面平台装 Ollama 的具体走法

Ollama 是这套方案的地基，先把地基打平。三个平台装法不一样，但装完的验证动作是一致的：终端里敲ollama -v，能打出带版本号的字符串就算成。

macOS 我一般直接下 dmg 拖进应用程序目录，省事。喜欢命令行的走 brew：

# 用 Homebrew 安装，适合已经有 brew 的机器 brew install ollama # 装完确认版本，这条命令三个平台通用 ollama -v

Windows 下官方安装包双击一路下一步就行，装完记得重开一个 PowerShell 窗口，老的终端进程读不到新加进 PATH 的路径。装完同样用ollama -v确认。

Linux 服务器上我一般不走包管理器，直接用官网首页给的那条安装脚本，它会顺带把 systemd 服务单元写好：

# 官方 Linux 安装脚本，会创建 ollama 用户并注册 systemd 服务 curl -fsSL https://ollama.com/install.sh | sh # 服务默认是启动状态，确认一下 systemctl status ollama # 验证版本 ollama -v

安装脚本做的事情比想象中多：建独立用户、装二进制到/usr/local/bin、写/etc/systemd/system/ollama.service、启动服务并设开机自启。这就是为什么 Linux 上装完之后systemctl能直接管它，而 macOS 上是菜单栏图标——两套进程管理模型。

2.3 装完立刻改的四个环境变量

这一步很多人跳过，然后卡在后面 Open WebUI 连不上、模型下到系统盘撑爆盘。默认配置只适合单机本地随便玩玩，一旦要接 Docker 容器或者手机端访问，就得动环境变量。我常改的是这四个：

Linux 上通过 systemd 的 override 改，这是唯一不会在重启后丢失的改法：

# 生成 override 文件，不要直接改 /etc/systemd/system/ollama.service sudo systemctl edit ollama.service

在弹出的编辑器里写：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_KEEP_ALIVE=30m" Environment="OLLAMA_NUM_PARALLEL=2"

存盘之后必须重载并重启，否则配置不生效：

# 重载单元文件并重启服务 sudo systemctl daemon-reload sudo systemctl restart ollama # 确认新监听地址生效 ss -tlnp | grep 11434

OLLAMA_HOST改成0.0.0.0是这套流程里最关键的一步。后面的 Open WebUI 跑在 Docker 容器里，容器看到的127.0.0.1是容器自己，不是宿主机，所以宿主机的 Ollama 必须对外监听。同理，Android 手机要访问同局域网的模型服务，也得靠这个。

OLLAMA_KEEP_ALIVE属于体验优化项。默认 5 分钟没有请求就把模型从内存卸载，下次提问要重新加载，7b 模型加载大概几秒到十几秒，很打断思路。调到 30m 之后基本感知不到重载，代价是那 5 GB 内存一直占着。内存紧张的机器反而应该调小，甚至设成 0。

注意：OLLAMA_HOST放开到0.0.0.0等于对整个局域网开放，家里或公司内网没问题，公网机器上一定要配合防火墙限制来源，别裸奔。

3. 本地跑通 DeepSeek：拉取、Modelfile 参数与 API 调用

环境装好之后，接下来是把模型真正跑起来，并且让它以可复用的形式对外提供服务。命令行交互只是第一步，能通过 HTTP 被别的程序调用，这套环境才算真的可用。

3.1 第一次拉取与交互式对话

ollama run这个命令有点特殊：模型不存在时它会先拉取再运行，存在时直接进对话。所以严格来说不需要单独的 pull，但生产环境里我一般分开写，下载和运行分开报错更容易定位。

# 显式拉取模型，成功后会输出大小和 digest ollama pull deepseek-r1:7b # 查看本地已下载的模型清单 ollama list # 进入交互式对话 ollama run deepseek-r1:7b

进到对话界面之后，直接敲问题就行，/bye退出，/?看内置命令，/clear清空上下文。这里有个细节值得讲：交互模式下上下文是一直累积的，聊到几十轮之后单次响应会明显变慢，因为每次都要把历史重新喂进去。长对话中途换话题，先/clear一下，比等着它慢慢吐字强。

拉取这一步最常见的问题是 tag 写错。deepseek-r1和deepseekr1是两个完全不同的仓库名，后者会返回 manifest 不存在。稳妥的做法是先不写 tag 拉一次，让模型库给默认版本，再按ollama list里显示的全名去指定。

# 不确定具体 tag 时，先拉默认版本 ollama pull deepseek-r1

下载速度取决于网络，7b 大概 4.7 GB。中途断了重跑ollama pull会续传，不会从头开始，这个不用慌。

3.2 用 Modelfile 固化你的参数

直接ollama run用的是默认参数，上下文窗口、温度这些都偏保守。想固定一套自己的配置，用 Modelfile 派生一个新模型出来。这是把「能跑」变成「好使」的关键一步。

# 从已下载的 7b 模型派生，不改基础权重 FROM deepseek-r1:7b # 上下文窗口，默认偏小，长文档场景必须放大 PARAMETER num_ctx 8192 # 温度，推理类任务建议 0.5-0.7，太高会发散 PARAMETER temperature 0.6 # 核采样，配合温度一起调 PARAMETER top_p 0.95 # 常见结束符，防止模型自己续写不进停止状态 PARAMETER stop "<|endoftext|>" # 系统提示词，把角色和行为固定下来 SYSTEM "你是一名严谨的技术助理，回答先给结论再给依据，不确定的地方要明确说不确定。"

每一行的作用说清楚：

FROM指定底座模型，写ollama list里出现的完整名字。num_ctx是上下文窗口的 token 数，默认值一般 2048 到 4096，处理一篇长文或者一份长日志完全不够，8192 是 7b 在 16G 内存机器上比较安全的档位，再往上内存占用会陡增。temperature和top_p是采样控制，推理类任务别调高，我试过 0.9，模型会在中间步骤反复自我怀疑，输出变得又长又绕。

SYSTEM这一段是很多教程不写的。它决定了模型的基础人设，对输出稳定性影响比温度还大。固定下来之后，同一个问题每次问的格式就一致了，做应用接进去的时候不用在后处理里做兼容。

存成文件后创建并验证：

# 基于 Modelfile 创建派生模型，注意末尾有个点 ollama create ds-r1-custom -f ./Modelfile # 看看参数是不是真的写进去了 ollama show ds-r1-custom # 用新模型跑 ollama run ds-r1-custom

ollama show会打出模型架构、参数量、上下文长度和参数列表。如果num_ctx显示的还不是你设的值，说明 Modelfile 里写错了关键字或者文件名拼错，重来一次就行。派生模型不复制权重文件，只存参数和模板，所以不占额外空间，可以放心建多个变体。

3.3 用 HTTP API 把模型接进自己的程序

本地交互只能解决"我自己用"，真正的价值在于这个 11434 端口能对外提供接口。Ollama 提供两套 API：原生接口和 OpenAI 兼容接口。前者功能更全，后者方便无缝替换已有的调用代码。

原生生成接口：

# /api/generate 是单轮补全，适合问答式场景 curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用三句话说明什么是容器编排", "stream": false, "options": { "num_ctx": 4096, "temperature": 0.6 } }'

关键参数：model必须和ollama list里的名字完全一致，写成派生模型名也行；stream设false会等全部生成完一次性返回，调试接口时候有用，流式返回适合前端打字机效果；options里的参数优先级高于 Modelfile，做临时覆盖改这里就行，不用重建模型。

多轮对话走/api/chat，消息格式是标准的 role/content 结构：

# /api/chat 保持多轮上下文，messages 数组按顺序累积 curl http://localhost:11434/api/chat -d '{ "model": "deepseek-r1:7b", "messages": [ {"role": "system", "content": "你是一名运维工程师"}, {"role": "user", "content": "Ollama 默认监听哪个端口？"} ], "stream": false }'

messages里system放在第一条，之后是交替的user和assistant。和原生接口不同，这里的上下文由你手动维护，服务端不记忆，每次请求要把完整历史带上。会话很长的时候记得做截断，不然 token 数会一路涨到超过num_ctx。

如果手上已有基于 OpenAI SDK 写的代码，可以直接改 base_url，不用重写：

# 用 OpenAI 官方 SDK 打 Ollama 的兼容端点 from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", # 指向 Ollama 兼容层 api_key="ollama", # 占位值，本地不需要真 key ) resp = client.chat.completions.create( model="deepseek-r1:7b", messages=[{"role": "user", "content": "写一个 systemd 服务单元示例"}], ) print(resp.choices[0].message.content)

api_key这里必须传一个非空字符串，SDK 层会做校验，但 Ollama 本身不验证，写什么都行。这套兼容层对stream、temperature这些常用字段支持完整，冷门参数可能会被忽略，遇到行为不一致的情况直接换回原生接口排查。

4. 多端接入：Open WebUI 容器与手机端两种走法

本地命令行跑通之后，下一步是让不同人、不同设备都能用上。图形界面走 Open WebUI 加 Docker，移动端分两条路——iOS 用快捷指令接云端接口，Android 用 Termux 手编译，后者麻烦但能离线。

4.1 用 Docker 起 Open WebUI 并对接本地 Ollama

Open WebUI 的本质是一层 Web 前端加用户系统，它不跑模型，只负责把请求转发给 Ollama。所以部署它其实是两件事：把容器跑起来，把容器和 Ollama 之间的网络打通。

前置是 Docker Desktop 或 Docker Engine 装好，docker -v能出版本号即可。然后执行：

# 拉起 Open WebUI 容器，端口映射 3000 -> 8080 docker run -d \ -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main

逐项说明参数：

-p 3000:8080把宿主机 3000 映射到容器内 8080，浏览器访问http://localhost:3000。3000 被别的服务占了就换左边那个数字，右边不要动。

--add-host=host.docker.internal:host-gateway是 Linux 上必须加的。Docker Desktop 在 macOS 和 Windows 上自带host.docker.internal这个域名解析，Linux 原生 Docker 没有，不加这一行容器里连不上宿主机的 Ollama，界面会一直转圈报连接失败。这是我踩过最久的一次坑，排查了半天才发现是域名解析问题。

-v open-webui:/app/backend/data挂数据卷，用户账号、聊天历史、上传的知识库文件都在里面。不加这个，容器一删数据全没，后悔药都没得吃。

--restart always保证开机自启和崩溃重启。最后那个镜像地址是官方维护的 main 分支，介意稳定性的可以换成固定的版本 tag。

容器起完之后docker logs -f open-webui看启动日志，出现监听 8080 的提示就可以开浏览器了。首次访问会要求注册账号，第一个注册的自动成为管理员，这个账号密码记好，Open WebUI 没有找回密码的入口。

进入界面之后还差最后一步：把模型接上。管理员设置里找到模型连接配置，地址填http://host.docker.internal:11434，保存后点刷新，本地已下载的模型列表会同步过来。如果刷新不出来，先回宿主机确认curl http://localhost:11434/api/tags有返回，再回容器里docker exec -it open-webui curl http://host.docker.internal:11434测试，两边的结果能定位问题出在哪一层。

4.2 在 Open WebUI 里把模型管起来

模型接上之后，界面里可以直接新建对话，体验和常见聊天工具差不多。对多人共用的场景，我一般会做两件事。

一是给刚建的派生模型配一个显示名和头像，在管理员面板的模型设置里改。默认显示的是deepseek-r1:7b这种技术名称，非技术同事看到会懵。

二是把常用提示词存成预设。Open WebUI 支持在对话里保存提示词模板，把「总结这篇文档」「按这个格式改代码」这类重复输入固定下来，比每次手打省事。这部分配置都存在数据卷里，容器重建不丢。

知识库功能是很多人忽略的一块。上传的文档会做向量化后参与检索，7b 这个规模做简单问答够用。但要注意，向量化过程本身也吃内存，和模型加载抢资源，16G 的机器上不建议同时开大文档解析和长对话。

4.3 iPhone：快捷指令接云端接口

iPhone 这条路和前面完全不同。手机本地跑不动 7b 模型，所谓部署其实是用快捷指令做一个前端，把问题转发给某个接口再显示结果。这条路线的关键是准备一个可用的 API Key。

准备动作分三步：先在 Safari 里打开别人分享的快捷指令链接，点导入，快捷指令会出现在 App 里；再打开这个快捷指令，找到配置 API Key 的那一步，把你的 Key 填进去；最后首次运行时系统会弹权限申请，点允许访问网络，不然请求发不出去。

第一次跑的信号很容易误判。如果快捷指令一闪就结束、没有结果，八成是 Key 填错了或者被截断。复制粘贴的时候前后带空格是常见事故，重新输入一遍，注意别多带字符。还有一点，这类快捷指令依赖外部接口的可用性，接口变了或者 Key 过期，表现是长时间无响应而不是报错，遇到这种情况先换个简单的测试问题确认链路。

提示：API Key 属于凭据，别存在备忘录或者聊天记录里，更不要贴到公开的地方。快捷指令里填完之后，原始文本建议清掉。

4.4 Android：Termux 里手编译 Ollama

Android 这条路硬核得多，但好处是全离线，模型和推理都在手机上。前提是手机内存 8G 以上、存储留 10G 空间，不然编译到一半就 OOM。

先在手机浏览器里下载 Termux 的安装包并装好。注意别从应用商店装，商店里那个版本太旧，包管理器源已经不可用，pkg update会直接失败。装完打开，按顺序执行：

# 申请存储权限，注意命令带连字符 termux-setup-storage # 更新包索引并升级已装组件 pkg update && pkg upgrade -y # 装编译链和 Ollama 需要的依赖 pkg install git cmake golang libjpeg-turbo -y # 确认 Go 版本，Ollama 对 Go 版本有下限要求 go version

这里有两处必须纠正。第一处是存储权限命令，正确的是termux-setup-storage，写成termuxsetupstorage会提示 command not found，少两个连字符。第二处是依赖名libjpeg-turbo，中间要有连字符，写成libjpegturbo会找不到包。这两处是我在实际操作中卡住最久的地方，因为报错信息只说找不到命令，不说你拼错了。

依赖齐了开始拉源码编译：

# 浅克隆，只取最新一次提交，省流量省时间 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # 生成构建所需文件，会拉 llama.cpp 的源码 go generate ./... # 编译，产出当前目录下的 ollama 可执行文件 go build .

--depth 1这个参数在手机上很有必要，完整历史加上子模块能到几百兆，浅克隆只拿最新快照。go generate这一步会去拉 llama.cpp 的 C++ 源码，网络不稳会卡住，卡住了重跑一次即可，已经下好的部分不会重复下载。go build之后目录里会出现一个名为ollama的可执行文件，没有后缀，这就是成品。

启动服务并验证：

# 后台启动服务，& 让它不占当前终端 ./ollama serve & # 确认 11434 端口通，返回版本信息说明服务活着 curl http://localhost:11434 # 拉一个小模型先验证链路，1.5b 在手机上更现实 ./ollama pull deepseek-r1:1.5b # 运行 ./ollama run deepseek-r1:1.5b

手机上跑 7b 不是不行，但内存压力很大，稍微开点别的应用就会被系统杀掉。我这边的实际经验是 1.5b 做链路验证，能用；要正经用还是把请求打到局域网里那台跑 7b 的机器上，手机只当客户端——把 Termux 里的OLLAMA_HOST指向宿主机 IP 就能做到，比本地硬扛划算得多。

5. 翻车排查：五条最常见的问题

装了这么多遍，出问题的位置相当集中。下面五条按出现频率排，每条都写清楚现象、原因和解决方式，遇到对得上的直接照着改。

5.1 拉取报 manifest 不存在

现象：执行ollama run deepseekr1:8b或ollama pull deepseekr1:8b，返回pull model manifest: file does not exist。

原因：仓库名写错了。模型库里的名字是deepseek-r1，中间有连字符。少写连字符之后 Ollama 会去找一个叫deepseekr1的仓库，自然找不到。这份笔记里两处写法不一致，一处有连字符一处没有，跟着抄就会踩。

解决：统一用deepseek-r1:7b或deepseek-r1:8b。不确定的时候先不写 tag 执行ollama pull deepseek-r1，拉完用ollama list看实际名字。

5.2 Open WebUI 界面一直连不上模型

现象：容器起来了，浏览器能打开 3000 端口，但模型列表是空的，或者提示连接失败，docker logs 里反复出现连接超时。

原因：两个层面。一是OLLAMA_HOST还是默认的127.0.0.1，只监听回环地址，容器访问不到；二是 Linux 上缺少host.docker.internal的解析，容器里这个域名根本不存在。

解决：先把宿主机 Ollama 的OLLAMA_HOST改成0.0.0.0:11434并重启服务，再确认启动容器时带了--add-host=host.docker.internal:host-gateway。两步都做完还不行，就进容器里docker exec -it open-webui curl http://host.docker.internal:11434，有返回说明网络通了，问题在 Open WebUI 的配置项填错。

5.3 Termux 里命令找不到

现象：termuxsetupstorage提示 command not found，pkg install libjpegturbo提示找不到包。

原因：命令名和包名都写错了，少了连字符。Termux 的存储权限命令是termux-setup-storage，依赖包是libjpeg-turbo。

解决：逐字符对照。这类错误报错信息不会告诉你"你是不是拼错了"，只会说找不到，很容易往环境问题上想。

5.4 回答被截断或者中途停住

现象：模型输出到一半突然结束，句子不完整，或者长文档输入进去之后回答完全跑偏。

原因：num_ctx太小。默认上下文窗口一般 2048 到 4096 token，一份长日志或者一篇长文直接超了，超出的部分会被静默丢弃，表现就是答非所问。

解决：在 Modelfile 里把num_ctx调到 8192，或者请求时在options里临时覆盖。调大之后内存占用会涨，7b 模型 8192 上下文的峰值内存在 16G 机器上是安全的，再往上要看着来。

5.5 端口被占用导致服务起不来

现象：systemctl status ollama显示 failed，日志里有bind: address already in use；或者docker run直接报端口冲突。

原因：11434 或 3000 被别的进程占了。常见的是之前手动启动过一个ollama serve，和 systemd 的实例打架。

解决：先定位再处理，别急着杀进程。

# 查谁占了 11434 ss -tlnp | grep 11434 # 如果是残留的手动进程，按 PID 干掉 kill -9 <PID> # 换端口的话，改 OLLAMA_HOST 里的端口号并重启服务

Docker 那边同理，-p 3001:8080把左边换掉就行，容器内部的 8080 不要动。这种冲突在反复调试的环境里特别容易出现，每次重启前先看一眼端口状态，比事后排查省时间。

6. 装完怎么验证跑通

三套环境都装完之后，最容易犯的错是"看起来能用"就当成了。我一般不留这个模糊地带，按下面这套检查从头走一遍，每一环都有明确的通过标准。

第一步，确认服务和模型都在位：

# 服务版本 ollama -v # 本地模型清单，应该有 deepseek-r1 和你建的派生模型 ollama list # 接口是否活着，返回 JSON 说明 HTTP 层通了 curl -s http://localhost:11434/api/tags | head -c 200

第二步，跑一次真实推理，别用 "hello" 这种测试。用一句需要它输出结构化内容的问题，能同时验证模型加载、上下文窗口和参数生效：

# stream 关掉便于观察完整输出，options 里覆盖参数验证覆盖是否生效 curl -s http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "列出三条 Linux 上排查端口占用的命令，每条一行说明", "stream": false, "options": {"num_ctx": 4096} }' | head -c 500

第三步，看模型加载状态和内存占用：

# 正在运行的模型和它占用的显存/内存 ollama ps

ollama ps里的UNTIL那一列会显示模型还会驻留多久，这个值和OLLAMA_KEEP_ALIVE对应。如果显示的是几秒后就卸载，说明环境变量没生效，回去检查 systemd override 有没有 daemon-reload。

第四步，验证 Open WebUI 这一层。浏览器打开 3000 端口，登录之后发一条消息，能正常返回就算通。再进设置里点一次模型刷新，列表数量应该和ollama list对得上，对不上说明同步有问题。

第五步，手机端分开验。iPhone 那边跑一次快捷指令，看是否能拿到完整回复而不是空结果。Android 在 Termux 里curl http://localhost:11434有版本返回就算服务活着，再跑一次 1.5b 的对话确认推理正常。

这套检查我一般会存成一个脚本，每次改完配置跑一遍。听起来繁琐，但比"改了一个参数导致另一处挂了、上线之后才发现"要省事得多。从那以后我每次动 Ollama 的环境变量或者重建容器，都强制走一遍这五步，尤其是第三步的ollama ps——它是最容易被忽略又最能暴露配置没生效的一环。希望帮到你。

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