企业官网建设流程全解析

简介：这是一份DeepSeek多平台部署的操作指南，面向希望将大语言模型快速落地到本地电脑、手机或网页端的开发者、技术人员及AI爱好者。内容以Ollama为核心，系统梳理了三种部署路径：基于命令行的本地部署，包括安装Ollama、拉取模型及终端交互；针对iPhone的快捷指令与API Key配置方案；以及Android下通过Termux编译、运行Ollama并加载模型的方法。同时，还介绍了基于Docker与Open WebUI的容器化部署，让用户可通过可视化界面管理模型。资源为单个docx文档，压缩包仅15KB，篇幅精简，但步骤完整，包含每步的具体命令、链接和验证方式，并专门给出了常见问题的排错思路，即使零基础读者也能按文档顺序完成环境搭建与模型调用。目前已有1521人学习下载，是快速上手DeepSeek部署、减少踩坑的实用参考。

1. DeepSeek 部署到底怎么选：三条路线一次讲清

OpenAI 之外的国产大模型里，DeepSeek 是少数把「本地跑」和「手机用」都做到位的选择，但它的部署方式极其分散——命令行、快捷指令、Termux、Docker 各管一段，很多人卡在第一步不知道该走哪条路。实际上按使用场景分只有三条线：电脑上追求低延迟和隐私走 Ollama 本地部署，随手问答和不占本地资源走手机端 API 转发，想要开箱即用的图形界面走 Open WebUI 容器化部署。本文按这三条线展开，每一条都给出可复现的命令、参数和坑点，覆盖从入门到接脚本的真实需求。适合想快速试点 AI 应用的开发者和想摸清部署边界的爱好者阅读。

2. 本地部署：Ollama 拉取 deepseek-r1 与命令行交互

2.1 安装 Ollama 与模型选择

Ollama 是目前部署本地模型最省心的工具，本质是一个模型运行时加模型管理器的组合体。官方提供了 macOS、Windows、Linux 三个平台的安装包，Windows 和 macOS 直接去官网下载 dmg 或 exe 安装即可，Linux 服务器则推荐用官方安装脚本，省去手动配置 systemd 服务的麻烦：

curl -fsSL https://ollama.com/install.sh | sh

脚本会完成三件事：把 Ollama 二进制放到/usr/local/bin，创建专用的ollama用户，注册一个开机自启的 systemd 服务。安装完成后先验证版本，再拉取模型：

ollama --version ollama run deepseek-r1:7b

ollama run是「拉取并进入交互」的合并命令。首次执行会自动从模型库下载约 4.7GB 的权重文件（具体大小视标签而定），下载完直接进入对话模式。模型名里的7b指 7B 参数量，这是权衡性能和资源占用的甜点值；如果机器内存只有 8GB，建议选 7b 而非 8b，后者的量化体积和内存占用都更高。跑起来后在终端输入问题即可对话，输入/bye退出交互，输入/help查看所有斜杠命令。

一个常被忽略的点：模型下载位置默认在用户目录下的.ollama/models，如果你系统盘不大，提前改环境变量OLLAMA_MODELS指向数据盘，可以避免后续磁盘满的尴尬。常见做法是在~/.bashrc里追加：

export OLLAMA_MODELS=/data/ollama/models

参数说明：OLLAMA_MODELS控制模型存储路径，OLLAMA_HOST控制服务监听地址，默认只监听 127.0.0.1，需要局域网其他设备访问时再改成0.0.0.0:11434。改完环境变量后，每条 PATH 里的命令都要用source ~/.bashrc刷新，否则不生效。这条血泪经验来自我一次把模型下载到根目录、系统盘直接满了的经历。

2.2 服务模式与本地 API 调用

交互模式适合人肉测试，真正要接程序时要用服务模式。先启动后台服务：

ollama serve

服务默认监听 11434 端口，验证方式是用 curl 打 API 接口：

curl http://localhost:11434/api/chat -d '{ "model": "deepseek-r1:7b", "messages": [ {"role": "user", "content": "用一句话解释什么是梯度下降"} ] }'

返回的 JSON 里会带message.content字段，这就是模型生成的回答。这里的messages数组结构与传统聊天接口一致，role可以是system、user、assistant三种。实际项目中我一般先ollama serve放到后台，再写脚本调 API，这样任何语言都能接入，不依赖命令行交互。

额外提一个接口差异：/api/chat是聊天补全，/api/generate是纯文本补全。前者适合多轮对话，后者适合单次文本生成任务。如果你分不清，一律用/api/chat没错，DeepSeek 本身是对话模型，纯补全接口反而要额外拼 prompt 才能达到同样效果。

3. 手机端部署：iOS 快捷指令与 Android Termux 编译

3.1 iOS：快捷指令加 API Key 的轻量方案

iPhone 部署 DeepSeek 并不需要装大模型，思路是「快捷指令转发到云端 API 再返回结果」，这个方案把计算压力放在服务端，手机只做 UI 壳。操作分两步：先在 Safari 里打开系统快捷指令库的共享链接，点击获取快捷指令并完成安装；然后在手机浏览器打开 API 服务商页面，注册获取 API Key。

安装好后打开快捷指令 App，会看到一个类似对话框的组件，点击展开设置项，把 API Key 粘贴进去。首次运行时会弹出「允许访问」的权限询问，这里要全部点允许，否则后续请求会被系统拦截。实际踩坑点有两个：一是复制 Key 时容易带上换行符或空格，导致鉴权失败，建议粘贴后用键盘删除键清掉末尾不可见字符；二是快捷指令内部如果写死了模型名，一定要确认和 API 服务商提供的模型标识一致，常见的是deepseek-chat，但不同中转服务命名可能不同，以你购买页面的实际值为准。

这个方案的优点是极轻量，iPhone 不占存储；缺点是依赖第三方 API 服务，存在欠费和接口变动风险。我的建议是把 Key 保存在备忘录并开启 iCloud 同步，换机重装时不用再找回记录。

3.2 Android：Termux 里编译 Ollama 的完整流程

Android 端官方没有提供 Ollama 安装包，社区方案是在 Termux 环境里从源码编译。Termux 是 Android 上的终端模拟器，需要先到官方 GitHub Release 页下载 APK（注意选择arm64-v8a版本，非 arm 架构会编译失败）。安装后打开，按顺序执行：

termux-setup-storage pkg update && pkg upgrade -y pkg install git cmake golang libjpegturbo -y

termux-setup-storage申请存储权限，pkg update刷新软件源，pkg install安装编译链。四个依赖缺一不可：git用于克隆仓库，cmake和golang是 Ollama 的编译工具链，libjpegturbo是图像处理库。装完后克隆仓库并编译：

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

--depth 1只拉取最新提交，避免下载完整历史拖慢速度。go generate会生成部分内嵌代码，go build输出名为ollama的可执行文件。编译过程在手机上可能要 10 到 20 分钟，期间手机会明显发热，这是正常的，但建议插上电源并关闭其他后台应用。翻车的常见原因是 Termux 的包管理器缓存目录占满空间，编译中途报no space left on device，可以先pkg clean清缓存再重试。

编译成功后在 ollama 目录下启动服务：

./ollama serve & curl http://localhost:11434

&让服务在后台运行，curl返回类似Ollama is running的版本信息即表示成功。最后拉取并运行模型：

./ollama pull deepseek-r1:8b ./ollama run deepseek-r1:8b

注意此处模型名写的是 8b，与电脑端 7b 不同。如果你的手机运行内存小于 8GB，强烈建议把模型名换成 7b，否则加载权重时可能直接被杀进程。跑起来后 Termux 里的交互体验和电脑端一致，但受限于手机算力，生成速度明显偏慢，这是硬件天花板，调不了。

3.3 双端部署的公共注意点

无论 iOS 还是 Android，部署完成后都要做好「后悔药」：定期记录环境版本。iOS 快捷指令更新时需要重新配置 Key，Android 的 Termux 滚动更新可能破坏编译产物。我的习惯是在 Termux 里写一条.bash_history备份，把安装过的包和编译命令存进文本，重装系统后一键恢复。

另一个共性问题是权限：Android 上 Termux 需要存储权限才能访问下载目录，iOS 快捷指令需要网络权限。这类权限弹窗经常被当作「恶意请求」被用户拒绝，导致功能异常。遇到问题优先检查权限设置，不要急着重装。

4. Open WebUI 部署：Docker 容器化图形界面

4.1 Docker Desktop 与镜像启动

本地命令行虽然能用，但对话体验比较原始。Open WebUI 是社区维护的开源对话前端，提供类似 ChatGPT 的界面，支持多模型切换、会话历史、文件上传等功能。它能同时管理多个本地模型，适合把 DeepSeek 和其他模型统一收纳。

部署前提是 Docker Desktop 和 Ollama 都已安装。先在 Docker Desktop 上确认 Docker 引擎运行正常，然后拉取镜像：

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 端口；--add-host是关键，让容器内能通过host.docker.internal域名访问宿主机的 Ollama 服务，这是容器网络与宿主机通信的桥梁；-v创建持久化数据卷保存数据库和配置；--restart always保证重启后自动拉起。Docker 镜像首次启动会自动检测 Ollama 状态，访问http://localhost:3000就能看到 Open WebUI 的欢迎页。

如果有 GPU 且想用显卡加速推理，在 Docker Desktop 设置里开启 GPU 后追加参数：

docker run -d -p 3000:8080 --gpus all --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

提示：没有 NVIDIA GPU 的机器不要加--gpus all，Docker 会直接报错无法创建容器。用 Intel 核显或 Apple Silicon 的开发者走纯 CPU 方案即可，7b 模型推理速度足够日常使用。

4.2 首次注册与模型下载

容器启动后第一次访问会要求注册账号。Open WebUI 的注册机制是「首个注册用户自动成为管理员」，后续用户需要管理员审批才能进入。这个设计解决了很多团队部署里的账号管理问题，但个人使用也意味着你要牢记首个账号的密码，遗忘了只能通过删除 Docker 数据卷重置，没有找回通道。

登录后在左下角打开设置，进入「模型」选项卡，这里会列出 Ollama 已下载的全部模型。如果列表为空，点击模型管理右上角的刷新按钮同步 Ollama 模型库。选择deepseek-r1:7b点击下载，等待进度条完成后即可在会话页面新建对话，模型下拉框里选择 DeepSeek 开聊。Open WebUI 默认不下载模型，必须手动触发，这也是新手最容易困惑的地方——明明容器起来了却没模型可用。

4.3 端口冲突与数据清理

Open WebUI 默认占用 3000 端口，如果被其他服务占用，容器会启动失败，日志里会出现bind: address already in use。解决方法是换一个宿主映射端口，比如-p 3001:8080，之后访问http://localhost:3001。如果之前已经创建过容器，要先删掉再重启：

docker stop open-webui && docker rm open-webui

不要直接docker run同名容器，会报名字冲突。需要彻底重置配置时，删除数据卷:

docker volume rm open-webui

这个命令会清空所有会话记录和用户账号，相当于工厂重置。慎用，但遇到注册账号卡死这类问题时它就是唯一的后悔药。

5. 避坑与排查：四个高频翻车点及修复思路

5.1 模型下载卡在 5% 不动

现象：ollama run deepseek-r1:7b执行后进度条长时间停在 5% 或 12%，网络速率显示为 0，等待半小时无变化。

原因：Ollama 下载权重文件使用分块拉取，网络波动时容易挂起；另一种常见情况是磁盘写入过慢，系统盘 IO 饱和导致下载线程被阻塞。

解决：先 Ctrl+C 中断当前命令，然后检查磁盘空间df -h，确认剩余空间大于 10GB。再执行ollama rm deepseek-r1:7b清掉损坏的下载缓存，重新运行ollama run deepseek-r1:7b。如果还卡，把OLLAMA_MODELS改到机械硬盘以外的路径，SSD 读取速度对恢复断点有帮助。不要用 Ctrl+Z 挂起任务，残留的下载锁会导致下次拉取直接报file exists。

5.2 Termux 编译时进程被杀

现象：Android 手机上执行go build .，编译到一半 Termux 崩溃退出，或系统提示「存储空间不足」。

原因：手机运行内存被编译进程耗尽，系统低内存管理机制杀掉了 Termux 进程。8GB 运存的机器编译 Ollama 也比较紧张，go build峰值内存占用可能超过 4GB。

解决：编译前先清理后台应用，关闭 Chrome、微信等常驻进程；给 Termux 设置前台优先，部分 Android 系统在最近任务列表里锁定应用可防止被杀。另一个有效手段是降低并行编译粒度，go build -p 1强制单核编译，时间变长但峰值内存下降 40% 以上。实测-p 2是性能与内存的折中值。如果设备还是撑不住，就放弃编译，改用安装第三方 Termux 包管理器里的预编译 Ollama，这个方案对老设备更友好。

5.3 Open WebUI 连不上 Ollama

现象：Open WebUI 界面启动成功，但新建对话时提示「Ollama connection failed」或「Failed to connect to model backend」。

原因：容器内访问localhost:11434指向的是容器自身而非宿主机，宿主机上运行的 Ollama 服务在容器视角里是不可见的。

解决：在docker run命令里添加--add-host=host.docker.internal:host-gateway，然后在 Open WebUI 的环境变量里把 Ollama 地址设为http://host.docker.internal:11434。如果是用 docker-compose 管理，对应配置为：

extra_hosts: - "host.docker.internal:host-gateway" environment: OLLAMA_BASE_URL: "http://host.docker.internal:11434"

改完环境变量后重建容器才生效。提示：检查宿主机 Ollama 是否真的在运行，curl http://localhost:11434返回内容为空时，先在宿主机把ollama serve拉起来再排查容器网络。

5.4 iOS 快捷指令返回鉴权失败

现象：快捷指令运行后报「Unauthorized」或「Invalid API Key」，但网页端测试同一个 Key 是正常的。

原因：快捷指令的文本输入框在粘贴时带入了隐藏换行符，HTTP 请求的 Authorization 头把换行符也发过去了，服务端解析头信息失败。

解决：在快捷指令设置页面对 Key 字段执行「全选 → 删除 → 重新粘贴」，粘贴后手动按一次退格键删除可能的末尾换行。如果仍失败，用备忘录中转一次：先在备忘录里粘贴 Key 再复制出来，这个过程会清除大部分不可见字符。这类问题很玄学，但 80% 都是不可见字符惹的祸。

5.5 内存不足导致推理直接退出

现象：手机端或低配电脑上运行模型，对话到一半进程闪退，终端显示killed或signal: killed。

原因：模型权重加上下文缓存的总内存需求超过物理内存，操作系统触发 OOM Killer 把进程杀掉。7b 模型量化后权重约 4.7GB，加上默认 2048 token 的上下文窗口，实际需要至少 6GB 可用内存。

解决：换更小模型或减小上下文窗口。Ollama 支持运行时指定上下文大小：/set parameter num_ctx 1024，把上下文减半可释放约 0.5GB 内存。最稳妥的方案是改用 4bit 量化级别更低的模型标签，比如deepseek-r1:7b-q4_0，体积更小且质量损失有限。我的习惯是部署前先用free -h看一眼可用内存，低于 8GB 直接选小模型，不折腾。

6. 进阶验证：把本地模型接进自己的脚本

6.1 用 Python 调用本地 Ollama API

部署完成后，最常用的姿势是写脚本批量调用。下面是 Python 端调用/api/chat的最小示例：

import requests import json url = "http://localhost:11434/api/chat" payload = { "model": "deepseek-r1:7b", "messages": [ {"role": "system", "content": "你是一个熟悉 Python 代码审查的助手。"}, {"role": "user", "content": "帮我找一下这段代码的潜在 bug：\nprint(x)"} ], "stream": False } resp = requests.post(url, json=payload, timeout=120) data = resp.json() print(data["message"]["content"])

stream参数必须显式写False，否则 API 会按流式返回 SSE 格式，脚本拿到的是分片而非完整 JSON。timeout要设到 120 秒以上，7b 模型在 CPU 机器上生成一段 100 字回复就可能耗时 30 秒。返回结构里message.content是文本结果，eval_count是真实生成 token 数，eval_duration是耗时，可以用来估算推理速度。

6.2 参数调优与系统提示词注入

生产环境里直接跑默认参数往往不够，推荐先做一次「温度测试」：把temperature从 0 到 1 按 0.2 步进各生成一次回复，对比结果稳定性。代码审查、数据提取等任务选 0.1 到 0.3 的低温度，创意的文案生成再考虑 0.8 以上。上下文大小num_ctx默认值随模型定义，但可以通过 payload 覆盖："options": {"num_ctx": 4096}，注意上下文越大内存占用越高，7b 模型开到 4096 需要额外约 1GB 内存。

最后说一个 MUST 的验证习惯：部署完成后不要急着开 WebUI 聊天，先跑一次curl /api/chat确认模型推理正常，再跑一个计划内的真实请求确认输出质量，最后才对外开放服务。我吃过一次亏，WebUI 看起来一切正常，结果后端模型早被删了，直到用户投诉才发现。从那以后我每次部署 DeepSeek 都强制走完「curl 验证 → 脚本调用 → 压力测试」三步。这套流程花不了五分钟，但能帮你避开大量日后排查的暗坑，希望帮到你。

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