企业官网建设流程全解析

简介：DeepSeek多平台部署指南是一份面向技术开发者、研究人员与AI爱好者的实战型文档，围绕跨平台部署这一核心问题，系统梳理了Ollama本地部署、iOS与Android移动端部署，以及基于Open WebUI的Docker容器化部署三条路线。文档先讲解Ollama在Windows/macOS/Linux上的安装、模型拉取与交互式对话；再分别给出iPhone快捷指令配置API Key、Android Termux编译Ollama并运行模型的详细步骤；最后结合Docker Desktop与Open WebUI完成可视化界面部署。资源为docx格式，共1个文件，压缩包大小仅15KB，便于下载后直接阅读，目前已有4126人学习。除完整步骤外，文档还附有具体链接、命令行脚本和关键配置注意事项，如API Key正确设置、Ollama初始化检查及端口验证方法。适合希望利用DeepSeek模型快速构建本地应用、开展实验研究的用户，无论是快速搭建本地实验环境，还是面向手机端的轻量部署，都能按图索骥，有效降低首次接触者的上手难度，提升部署成功率与实验效率。

1. 多平台部署 DeepSeek：不是玄学，是三条可以自己走通的路

把 DeepSeek 部署到自己的电脑、手机和 WebUI 上，听起来像是需要啃一堆文档的事，但实际走下来你会发现，核心就三件事：装好模型运行时、把模型文件拉下来、找一个顺手的交互入口。Ollama 解决前两件，快捷指令和 Termux 解决手机端，Docker 里的 Open WebUI 解决浏览器界面。这篇笔记把三条路的每一步都拆开讲，包括命令为什么这么写、参数改哪里、失败时看什么。适合想本地化部署深度学习模型的开发者、做移动端 AI 实验的研究人员，以及所有不想把数据交给云端的人。读完你能复现完整流程，也能避开我踩过的那些坑。

2. 本地部署选 Ollama：一条命令的背后是模型量化与运行时封装

2.1 为什么是 Ollama，而不是直接跑 Python 推理

很多人第一次接触 DeepSeek 部署，第一反应是去 Hugging Face 下载模型权重，然后写 Python 脚本加载。这个思路没毛病，但实际做起来会撞上几个问题：模型文件动辄几个 GB，显卡显存不够就得折腾 CPU 推理，依赖的 PyTorch、transformers 版本又容易打架。Ollama 把这一层封装掉了，它本身是一个模型运行时，内置了量化、显存管理和 API 服务能力，你只需要告诉它拉哪个模型，剩下的事它自己处理。

Ollama 默认会把模型量化后存放在本地，具体路径在 macOS 上是~/.ollama/models，Linux 和 Windows 上类似。量化意味着模型精度会有轻微损失，但换来的是普通家用电脑也能跑起来。对大多数人来说，用 Ollama 跑 DeepSeek 的 7B 或 8B 量化版，远比折腾一套完整的 Python 推理环境划算。我一般会先用 Ollama 做原型验证，如果后续要做精细调优，再考虑用原始权重接 transformers 跑。

2.2 安装与拉取：从官网装好到第一条对话，中间只有一条命令

安装 Ollama 没什么技术含量，去官网下载对应操作系统的安装包，macOS 和 Windows 是图形化安装，Linux 则是执行安装脚本。装完以后打开终端，输入这条命令：

ollama run deepseek-r1:7b

这条命令做了三件事：检查本地是否已有deepseek-r1:7b这个模型，没有就从模型库拉取；下载完成后启动模型服务；在当前终端进入交互式对话模式。首次拉取需要等待一段时间，7B 量化模型大约 4 到 5 GB，取决于网速。

参数说明：deepseek-r1:7b中的r1是模型系列名，:7b是参数量标签。Ollama 的模型标签体系是模型名:参数量，同一个模型名下面可能有 1.5b、7b、14b、32b 等多个尺寸，选哪个取决于你的内存和显存。我自己的经验是，8 GB 内存的笔记本跑 7B 勉强流畅，想要更快的响应就换 1.5B，想要更好的质量就上 14B，但内存低于 16 GB 不建议碰。

2.3 交互与后台服务：终端对话只是入口，真正的价值在 API 端口

模型下载完进入交互模式后，你可以在终端直接输入问题。但终端交互只是一个入口，Ollama 真正的价值在于它同时启动了一个本地 API 服务，默认监听11434端口。这意味着你可以用任何编程语言、任何工具去调用这个本地模型，而不必一直窝在终端里。

验证 API 是否正常的命令是：

curl http://localhost:11434

正常会返回类似Ollama is running的信息。如果你想在后台启动服务而不是进入交互模式，用：

ollama serve

这个命令会让 Ollama 以服务模式运行，终端可以干别的事。我一般会配合ollama list查看本地已有模型，用ollama pull单独拉取模型而不进入对话，这两个命令在后续的 Open WebUI 部署中会频繁用到。

3. iPhone 端部署：快捷指令的本质是 API 客户端，不是本地推理

3.1 快捷指令的工作机制：API Key 从哪来，请求怎么发

iPhone 上部署 DeepSeek，看起来是“装个快捷指令就能用”，但快捷指令本身不承载模型，它只是一个壳，真正的推理发生在远程服务器上。这个方案的本质是：快捷指令通过 HTTP 请求调用某个兼容 OpenAI 格式的 API 接口，把用户输入的文字发过去，拿到返回结果后显示在手机上。

所以整个流程的关键不是快捷指令本身，而是两件事：第一，找到一个能提供 DeepSeek 模型推理服务的 API 服务商，拿到一个 API Key；第二，把这个 Key 填进快捷指令的配置项里。快捷指令里通常会用“获取 URL 内容”这个动作来发请求，请求地址指向 API 服务的/v1/chat/completions端点，请求头里带Authorization: Bearer <你的API Key>，请求体是 JSON 格式的对话消息。

API 请求体长这样：

{ "model": "deepseek-r1", "messages": [ {"role": "user", "content": "用一句话解释什么是深度学习模型部署"} ], "temperature": 0.7 }

参数说明：model字段告诉服务商用哪个模型，messages是对话历史，temperature控制回复的随机性，数值越低越保守、越高越发散。快捷指令里需要把这段 JSON 作为请求体传出去，然后解析返回的choices[0].message.content字段作为回复文本。

3.2 配置与首次运行：权限弹窗、超时设置与 Key 的保管

在 iPhone 上拿到快捷指令链接后，用 Safari 打开并点击“获取快捷指令”，系统会自动跳转到快捷指令 App 完成安装。首次运行时，快捷指令会弹出一系列权限请求，包括“允许访问网络”“允许访问剪贴板”等。这些弹窗必须要点“允许”，否则请求发不出去。

配置 API Key 通常在快捷指令的“文本”动作里，你需要打开快捷指令的编辑界面，找到写着API Key字样的文本组件，把它替换成自己的 Key。这里有个容易翻车的细节：有些快捷指令版本里 API Key 是作为变量引用的，你要改的是变量的默认值，而不是直接改请求头里的内容。

关于超时设置，快捷指令里“获取 URL 内容”动作默认超时时间是 60 秒，但 DeepSeek 这类推理模型生成回复需要时间，长一点的回答可能超过 60 秒。遇到“请求失败”时，先别怀疑 Key 有问题，检查一下是否在动作设置里把超时时间拉长到 120 秒或更长。我自己的经验是，把超时设为 180 秒基本不会触发上限。

API Key 的保管是个容易被忽略的点。快捷指令可以分享给别人，如果你把 Key 直接写在文本组件里，对方打开编辑模式就能看到。我一般会把 Key 放在一个独立的“备注”里，然后在快捷指令中引用这个备注变量，这样分享出去的时候不会泄露。这个习惯虽然麻烦，但值得。

4. Android 端部署：Termux 里源码编译 Ollama，是三条路里最硬核的一条

4.1 环境准备：存储权限、软件包更新与依赖安装的先后顺序

Android 端的部署方案不依赖任何第三方壳应用，而是直接在 Termux 里从源码编译 Ollama。这个方案最大的优点是真正把模型跑在了手机本地，缺点是步骤多、耗时长、对手机性能有要求。整个过程可拆成三个阶段：Termux 环境准备、Ollama 源码编译、模型拉取与验证。

Termux 是一个运行在 Android 上的终端模拟器，它不像普通 App 那样有图形界面，所有操作都靠命令完成。安装完成后，第一件事是执行两条基础命令：

termux-setup-storage pkg update && pkg upgrade

逻辑说明：termux-setup-storage是让 Termux 获得访问手机存储的权限，后面如果需要把文件从电脑传到手机，或者把模型文件复制到其他目录，都得先过这一关。pkg update && pkg upgrade是更新软件源和已安装的软件包，Android 上的 Termux 软件源更新频率不高，但首次使用必须执行，否则后面安装依赖可能拉到旧版本。

接下来安装编译 Ollama 需要的依赖：

pkg install git cmake golang libjpegturbo

参数说明：git用于克隆代码仓库，cmake是 C 语言部分的构建工具，golang是 Ollama 主程序的语言运行时，libjpegturbo是图像处理依赖。如果之后编译时报缺头文件，大概率是这一步漏了包，回头补装就行。

4.2 克隆与编译：go generate 和 go build 各自解决什么问题

依赖安装完成后，开始克隆 Ollama 的源码仓库并编译：

git clone --depth 1 https://github.com/ollama/ollama.git cd ollama go generate ./... go build .

--depth 1参数表示只克隆最新一次提交，不拉取完整历史记录，这能显著减少下载时间和磁盘占用。go generate ./...是编译前的预处理步骤，它会执行代码里标注了//go:generate的指令，生成一部分运行时需要的代码文件。go build .才是真正的编译，产物是一个名为ollama的可执行文件。

这里有一个现实问题：手机端的编译速度取决于处理器性能。我在一台搭载骁龙处理器的手机上编译过，整个过程大概需要 15 到 30 分钟，期间手机会明显发热。这不是异常，是处理器在高负载下的正常表现。如果你用的是中低端处理器，编译时间可能更长，建议插上电源再操作。

编译完成后，当前目录下会多出一个ollama可执行文件。下一步是启动服务：

./ollama serve &

serve是启动服务模式，&是把进程放到后台运行，这样终端可以继续输入其他命令。验证服务是否启动成功，用 curl 检查本地端口：

curl http://localhost:11434

逻辑说明：Ollama 的服务端口固定是 11434，这个端口在电脑端和手机端是一样的。curl 命令会向这个端口发送一个 HTTP 请求，如果服务正常运行，会返回 Ollama 的版本信息；如果没有任何输出，说明服务没起来，最常见的原因是编译产物不完整或者后台进程被系统杀掉。

4.3 拉取与运行：模型名拼写错误是最低级的翻车

服务启动成功后，拉取 DeepSeek 模型：

./ollama pull deepseekr1:8b

注意这里的模型名是deepseekr1:8b，和本地部署时用的deepseek-r1:7b不一样。Ollama 模型库中的命名规则是名称:版本标签，不同来源的模型可能有不同的名称变体。如果拉取时提示模型不存在，先用./ollama search deepseek搜索模型库里可用的全部名称。

拉取完成后，运行模型进入对话：

./ollama run deepseekr1:8b

参数说明：run和本地部署时的run行为一致，会加载模型并进入交互模式。手机端运行 8B 模型对内存的要求不低，建议确保手机剩余运存至少在 6 GB 以上，否则可能出现响应极慢甚至直接被系统杀后台的情况。如果运行时报内存不足，换小一号的模型，比如deepseekr1:1.5b，流畅度会明显提升。

5. Open WebUI 部署：用 Docker 把 Ollama 包装成聊天界面

5.1 Docker Desktop 与 Open WebUI 的选型：为什么要多一层容器

本地部署用终端够了，但如果你想要一个图形化的聊天界面，或者想让实验室的其他人也能用浏览器访问模型，Open WebUI 是更合适的选择。它是一个开源的 Web 界面项目，以 Docker 容器的形式运行，通过 HTTP 请求与 Ollama 服务通信，把终端里那些冷冰冰的命令行交互替换成类似 ChatGPT 的对话页面。

这个方案需要三样东西：本地的 Ollama 服务、Docker Desktop、Open WebUI 容器。Ollama 负责加载模型和推理，Docker Desktop 负责运行容器，Open WebUI 负责提供界面。选 Docker 而不是直接跑 Python Web 服务，是因为 Open WebUI 依赖的前后端组件很多，手动搭环境容易出版本冲突，用容器可以一次封装、随处运行。

安装 Docker Desktop 的过程比较无聊，下载、安装、启动，确认右下角图标变绿就行。Docker Desktop 本身会附带一个轻量级的 Linux 虚拟机，容器都跑在虚拟机里，所以占用资源会比想象中的大，建议电脑内存不低于 16 GB。

5.2 部署与测试：端口映射和模型选择下拉框的配合

Open WebUI 的安装方式有两种：使用 docker 命令行拉取并运行容器，或者从 Docker Desktop 的图形界面直接搜索镜像并运行。命令行方式更适合反复部署，代码化、可重复：

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

参数说明：-d是后台运行容器，-p 3000:8080把容器的 8080 端口映射到宿主机的 3000 端口，浏览器访问http://localhost:3000就能打开界面；--add-host是让容器能通过host.docker.internal访问宿主机，因为 Open WebUI 需要连接宿主机的 Ollama 服务（Ollama 监听在 11434）；-v open-webui:/app/backend/data是持久化存储，否则容器重启后聊天记录全丢；--restart always让容器在 Docker 重启后自动拉起。

容器启动后，打开浏览器访问localhost:3000，首次进入需要注册一个管理员账号。在界面左下角的设置里找到模型管理，刷新模型列表，会看到 Ollama 中已下载的模型出现在下拉框中。如果列表为空，检查两件事：宿主机的 Ollama 服务是否在运行，以及容器内是否能访问host.docker.internal:11434。

选好模型后新建对话，输入问题测试。如果界面能正常返回结果，说明整个链路是通的：浏览器 → Open WebUI 容器 → 宿主机 Ollama → 模型推理 → 逐层返回。这套方案最适合团队共享一台部署了 Ollama 的服务器，其他人不需要安装任何东西，只用浏览器就能用上本地模型。

6. 跨平台部署避坑与排查：五个高频翻车点与一套验收习惯

这条部署路线上翻车的概率不低，且每个平台的坑都不一样。我把高频问题按“现象 → 原因 → 解决”三条线列在下面，都是我实际遇到过、也确认过解决方案的。

6.1 高频问题清单

问题一：ollama run提示无法连接服务

现象：终端输入ollama run deepseek-r1:7b后提示连接失败。

原因：Ollama 的客户端和服务端是分离的，run命令会尝试连接本地 11434 端口，但服务端可能没有启动。

解决：先执行ollama serve启动服务，再开一个新终端执行ollama run。如果serve启动后被系统杀掉，检查杀毒软件或安全策略是否拦截了 11434 端口的监听。

问题二：iPhone 快捷指令报错“请求失败”

现象：快捷指令运行时弹窗提示请求失败，API Key 确认无误。

原因：快捷指令里“获取 URL 内容”动作的默认超时时间太短，模型生成回复时间长于超时时间，请求被客户端主动取消。

解决：进入快捷指令编辑界面，点开“获取 URL 内容”动作，把超时时间改为 180 秒。同时检查请求头里是否有Content-Type: application/json，缺失这个会导致服务端返回 400。

问题三：Termux 编译 Ollama 时提示缺包

现象：go build .执行到一半报错，提示找不到某个头文件或库。

原因：依赖安装不全。Ollama 除了 Go 代码，还有一部分 C 代码需要编译，这些代码依赖额外的系统库。

解决：先确认已安装libjpegturbo，如果还报缺其他库，使用pkg search <库名>查找对应包再安装。编译报错信息里的“file not found”通常直接指明了缺失的库名，照着装就行。

问题四：Open WebUI 模型列表为空

现象：浏览器打开 Open WebUI，设置里的模型下拉框是空的。

原因：Open WebUI 容器无法访问宿主机的 Ollama 服务。Docker 容器默认使用 bridge 网络，宿主机 IP 不能直接用localhost访问。

解决：启动容器时带上--add-host=host.docker.internal:host-gateway参数，让容器可以通过host.docker.internal访问宿主机。如果 Ollama 本身没有监听所有网络接口，还需要设置环境变量OLLAMA_HOST=0.0.0.0后重启 Ollama。

问题五：手机端模型响应极慢或直接被中断

现象：在 Termux 里运行 8B 模型，输入问题后等待很久，或者回答到一半就卡住。

原因：手机内存不足。模型加载在内存里，推理过程需要持续读写，内存不足时系统会把进程切到后台甚至直接杀掉。

解决：关闭手机后台的其他应用，或者改用更小的模型，比如deepseekr1:1.5b。这个尺寸的模型对内存要求低很多，响应速度也有明显改善。

6.2 部署完成后的验收流程

每次部署完成，我都会强制走一遍下面的清单，大概两分钟就能确认整条链路是否可用：

ollama list

确认模型在本地；接着用 curl 确认服务端口在响应；然后发送一条测试对话，观察首次响应时间是否在可接受范围内；最后在 Open WebUI 界面里新建会话，确认图形界面能正常返回结果。这一套流程下来，端口、模型、交互入口三个环节都验证过，部署才算真正完成。

从那以后，我每次在任何一个新设备上部署 DeepSeek，都强制走一遍这个验收流程，不跳过任何一步。不是为了仪式感，而是踩过的坑足够多，知道漏掉哪一步都要付出时间代价去排查。希望这篇笔记能帮你少走几步弯路，也希望你部署顺利，玩得开心。

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