简介：这份文档面向希望在个人设备上落地大模型的开发者、研究人员与技术爱好者，系统梳理了多平台环境下 DeepSeek 模型的部署路径。内容覆盖基于 Ollama 的 macOS、Linux、Windows 本地部署，iPhone 快捷指令与 Android Termux 的移动端方案，以及借助 Docker 与 Open WebUI 搭建浏览器访问环境的完整思路，帮助读者把前沿 NLP 能力转化为可用的本地服务。资源包为 1 个 docx 文档，约 15KB，以图文步骤与命令说明为主，结构紧凑便于对照查阅。目前已有 3770 人学习下载，适合需要快速验证部署流程、理解不同硬件与系统适配差异的读者参考，也可作为团队内部搭建 AI 聊天机器人时的入门指引。
1. 多平台部署 DeepSeek：从终端到手机，三条路怎么选
很多人第一次接触本地大模型，卡在第一步不是模型本身，而是“我到底该用哪种方式跑起来”。手头一台笔记本、一部手机、一台常年开机的迷你主机，硬件条件不同，部署路径完全不一样。这份资源把 DeepSeek 的部署拆成了三条线：Ollama 本地命令行、手机端 Termux 或快捷指令、以及 Open WebUI 的浏览器方案。它解决的核心问题是让同一个模型在不同算力条件下都能跑起来，而不是只给一套“万能教程”。适合手里有 Mac、Linux 或 Windows 机器，想先把模型跑通再考虑接入业务流程的开发者；也适合想用手机做轻量推理验证的移动端开发者。下面按实际落地顺序，把每条路的参数、命令和坑讲清楚。
2. Ollama 本地部署：从拉取到交互的完整链路
Ollama 是目前在个人设备上跑 DeepSeek 最省心的方案，没有之一。它把模型下载、量化版本管理、推理服务启动和 API 暴露打包成了一条命令，省掉了手动编译和依赖配置的麻烦。但省心不等于没有坑，尤其是模型 tag 的选择和显存占用，选错了要么跑不起来，要么跑起来慢到没法用。
2.1 安装 Ollama 与模型 tag 的选型逻辑
Ollama 官方提供了 macOS、Linux、Windows 三个平台的安装包，安装过程没有特殊配置，一路默认即可。装完之后第一件事不是急着拉模型，而是先确认版本和可用模型列表。
# 查看 Ollama 版本，确认安装成功 ollama --version # 查看当前已拉取的模型 ollama list # 搜索 DeepSeek 相关模型 tag ollama search deepseekollama search会列出所有可用的 DeepSeek 变体，常见的有deepseek-r1:7b、deepseek-r1:8b、deepseek-r1:14b等。这里的数字代表参数量，单位是十亿。选型逻辑很直接：7B 和 8B 适合 16GB 内存的笔记本或 8GB 显存的台式机；14B 起步需要 32GB 内存或 12GB 以上显存；再往上走，消费级硬件基本不用考虑。我一般会先拉 7B 版本做功能验证，确认业务流程跑通后再根据实际响应质量决定是否升级。
# 拉取并运行 DeepSeek-R1 7B 模型 ollama run deepseek-r1:7b这条命令做了两件事：先从 Ollama 模型库下载模型文件到本地，然后直接进入交互式对话模式。下载时间取决于网络带宽，7B 模型大约 4-5GB，首次拉取需要耐心等待。下载完成后终端会出现>>>提示符，直接输入问题即可。
2.2 终端交互与 API 服务模式切换
交互式对话适合快速测试，但真正要接入应用，需要的是 API 服务模式。Ollama 默认在11434端口暴露 HTTP 接口，启动服务后可以用 curl 或任何 HTTP 客户端调用。
# 后台启动 Ollama 服务 ollama serve & # 验证服务是否正常，返回版本信息即成功 curl http://localhost:11434 # 通过 API 调用模型生成 curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用一句话解释什么是量化", "stream": false }'stream参数控制是否流式返回，设为false时一次性返回完整结果，适合脚本调用；设为true时逐 token 返回，适合做打字机效果的聊天界面。model字段必须和ollama list中的名称完全一致，大小写敏感。如果返回model not found，先确认模型是否拉取成功。
注意：Windows 下
ollama serve默认以系统服务方式运行，不需要手动加&。如果端口被占用，可以通过环境变量OLLAMA_HOST修改监听地址。
2.3 模型文件存储与多版本共存管理
Ollama 把模型文件存在用户目录下的.ollama/models文件夹里，macOS 和 Linux 在~/.ollama/models，Windows 在C:\Users\用户名\.ollama\models。这个目录会随着模型数量增加快速膨胀，7B 模型占 4-5GB，14B 占 8-9GB，如果同时保留多个版本，硬盘空间要提前规划。
# 查看模型存储路径 ollama show deepseek-r1:7b --modelfile | head -5 # 删除不再需要的模型版本 ollama rm deepseek-r1:7b # 复制模型并重命名，用于保留特定版本 ollama cp deepseek-r1:7b deepseek-r1:7b-backupollama cp这个命令很多人不知道，它可以在不重新下载的情况下复制模型并打上自定义 tag。我一般会在升级模型前先cp一份旧版本，万一新版本效果不如预期可以快速回滚。删除模型时ollama rm会直接清空对应文件，没有回收站，操作前确认清楚。
3. 手机端部署：Termux 编译与快捷指令两条路
手机跑大模型听起来像玄学，但确实有两条可行的路。一条是 Android 上用 Termux 编译 Ollama 源码，另一条是 iPhone 上用快捷指令调用远程 API。两条路的思路完全不同：前者是把推理能力搬到本地，后者是把手机当客户端。选哪条取决于你的手机平台和实际需求。
3.1 Android Termux 环境准备与依赖安装
Termux 是一个 Android 终端模拟器，不需要 root 权限就能提供完整的 Linux 环境。但默认安装的 Termux 没有存储权限，也没有编译工具链，需要先做初始化。
# 设置存储权限，让 Termux 能访问手机文件系统 termux-setup-storage # 更新软件包列表并升级已安装的包 pkg update && pkg upgrade -y # 安装编译 Ollama 所需的依赖 pkg install git cmake golang libjpeg-turbo -ytermux-setup-storage会弹出系统权限请求，必须点允许，否则后续无法读写模型文件。pkg upgrade在首次运行时可能提示配置文件冲突，选择保留当前版本即可。golang是编译 Ollama 的核心依赖，libjpeg-turbo用于图像处理相关的模型功能，cmake负责构建流程。这四个包缺一不可，少一个都会在编译阶段报错。
3.2 编译 Ollama 源码与启动验证
Ollama 官方没有提供 Android 的预编译二进制，所以只能从源码编译。这个过程在手机上耗时较长，中端机型大约需要 10-15 分钟。
# 克隆 Ollama 仓库，depth 1 只拉取最新提交，节省时间和空间 git clone --depth 1 https://github.com/ollama/ollama.git # 进入源码目录 cd ollama # 生成必要的构建文件 go generate ./... # 编译生成可执行文件 go build .--depth 1这个参数很关键，完整克隆会拉取全部历史提交，在手机网络环境下可能超时。go generate ./...会执行源码中定义的代码生成逻辑，生成一些平台相关的绑定文件。go build .在当前目录生成名为ollama的可执行文件。如果编译过程中报out of memory，说明手机内存不足，可以尝试关闭后台应用后重试，或者换用go build -ldflags="-s -w"减小二进制体积。
# 后台启动 Ollama 服务 ./ollama serve & # 验证服务是否启动成功 curl http://localhost:11434 # 拉取 DeepSeek-R1 8B 模型 ./ollama pull deepseek-r1:8b # 运行模型进入交互模式 ./ollama run deepseek-r1:8bcurl http://localhost:11434返回版本信息说明服务正常。./ollama pull下载模型到手机存储，8B 模型大约 5GB，确保手机剩余空间充足。./ollama run进入交互模式后，输入问题即可看到模型回复。手机端推理速度受限于 CPU 和内存带宽，7B 模型在骁龙 8 系芯片上大约每秒 2-5 个 token，适合短文本问答，不适合长文生成。
3.3 iPhone 快捷指令配置与 API Key 管理
iPhone 没法本地跑模型，但可以通过快捷指令调用远程 API 实现类似体验。这个方案的本质是把手机当瘦客户端，推理在远端完成。
快捷指令的配置分三步：先从分享链接导入快捷指令模板，然后获取 API Key 并填入指定位置，最后首次运行时授权网络访问。API Key 一般从服务提供方的开发者页面获取，填入快捷指令的文本变量中。首次运行会弹出“允许访问”提示，点允许即可。
注意：API Key 等同于账户凭证，不要截图分享或提交到公开仓库。快捷指令中的 Key 存储在本地，但 iCloud 同步开启时会上传到云端，敏感场景建议关闭同步。
这个方案的优势是手机端零算力消耗，响应速度取决于网络质量；劣势是依赖外部服务，离线不可用。适合把手机作为临时验证终端，不适合对数据隐私要求高的场景。
4. Open WebUI 部署：Docker 容器化与浏览器访问
命令行交互适合开发者，但如果是团队共用或者需要给非技术同事使用，浏览器界面更合适。Open WebUI 是一个开源的 Web 前端，可以对接 Ollama 的 API，把命令行能力包装成类似 ChatGPT 的聊天界面。Docker 部署是官方推荐方式，省去了 Python 环境配置的麻烦。
4.1 Docker 环境准备与 Open WebUI 容器启动
Docker Desktop 的安装按官方指引操作即可，Windows 需要开启 WSL2 后端，macOS 和 Linux 相对简单。装完后确认 Docker 服务正常运行。
# 确认 Docker 版本和服务状态 docker --version docker ps # 拉取 Open WebUI 镜像 docker pull ghcr.io/open-webui/open-webui:main # 启动 Open WebUI 容器，映射 3000 端口 docker run -d -p 3000:3000 \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main-d让容器后台运行，-p 3000:3000把容器内的 3000 端口映射到宿主机，-v open-webui:/app/backend/data创建数据卷持久化聊天记录和配置，--restart always确保宿主机重启后容器自动拉起。启动完成后浏览器访问http://localhost:3000即可看到登录界面，首次使用需要注册一个本地账户，这个账户只存在本地数据库中，不涉及外部服务。
4.2 对接 Ollama 模型与界面功能验证
Open WebUI 启动后默认会尝试连接http://localhost:11434的 Ollama 服务。如果 Ollama 跑在同一台机器上，通常不需要额外配置。如果 Ollama 在另一台设备上，需要在设置中修改 API 地址。
# 确认 Ollama 服务在宿主机上可访问 curl http://localhost:11434/api/tags # 如果 Ollama 在另一台机器，启动 Open WebUI 时指定地址 docker run -d -p 3000:3000 \ -e OLLAMA_BASE_URL=http://192.168.1.100:11434 \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:mainOLLAMA_BASE_URL环境变量指定 Ollama 服务的地址，替换成实际 IP 即可。进入 Open WebUI 后，左下角设置里选择模型，下拉列表中会显示 Ollama 已拉取的所有模型。选中deepseek-r1:7b后新建对话，输入问题测试响应。界面支持多轮对话、对话历史、模型切换，基本覆盖了日常使用场景。
4.3 数据持久化与多用户隔离配置
Open WebUI 的数据卷挂载是必须的，否则容器重建后所有聊天记录和账户信息都会丢失。-v open-webui:/app/backend/data把容器内的数据目录映射到 Docker 卷，即使删除容器，数据仍然保留。
# 查看数据卷信息 docker volume inspect open-webui # 备份数据卷内容 docker run --rm -v open-webui:/data -v $(pwd):/backup \ alpine tar czf /backup/open-webui-backup.tar.gz -C /data . # 恢复数据卷 docker run --rm -v open-webui:/data -v $(pwd):/backup \ alpine tar xzf /backup/open-webui-backup.tar.gz -C /data备份命令把数据卷打包成 tar.gz 文件存到当前目录，恢复时反向操作。多用户场景下，Open WebUI 支持管理员创建多个账户，每个账户的对话历史独立存储。管理员可以在设置中控制模型访问权限，比如只允许特定用户使用 14B 模型，避免算力被占满。
5. 避坑与排查：部署过程中最容易翻车的五个点
部署过程中遇到的问题，八成集中在模型拉取、端口冲突、内存不足、权限配置和版本兼容这五类。下面按“现象 → 原因 → 解决”的结构逐条拆开。
现象一：ollama run卡在 pulling manifest 不动。原因通常是网络到模型库的连接不稳定，或者 DNS 解析有问题。解决方法是先确认curl https://ollama.com是否可达，如果超时，检查本机 DNS 设置。另一个常见原因是磁盘空间不足，df -h确认剩余空间大于模型体积的两倍。
现象二：Termux 编译时报go: cannot find GOROOT。原因是 Go 环境变量没有正确设置。Termux 安装的 Go 不会自动配置 GOROOT 和 GOPATH。解决方法是手动导出环境变量：export GOROOT=$PREFIX/lib/go和export GOPATH=$HOME/go，然后重新执行go build .。
现象三：Open WebUI 容器启动后浏览器无法访问。先确认容器是否在运行：docker ps查看状态。如果容器已退出，用docker logs open-webui看错误日志。常见原因是 3000 端口被占用，换成-p 3001:3000重新启动即可。另一个原因是防火墙拦截，Linux 下检查ufw status。
现象四：手机端模型加载后闪退。Android 系统对后台进程有内存限制，Ollama 加载模型时如果超过阈值会被系统杀掉。解决方法是关闭所有后台应用，并在 Termux 中执行termux-wake-lock防止 CPU 休眠。如果仍然闪退，说明手机内存确实不够，换用更小参数量的模型。
现象五：API 调用返回connection refused。Ollama 服务没有启动，或者监听地址不对。ollama serve默认只监听127.0.0.1，如果从另一台机器调用，需要设置OLLAMA_HOST=0.0.0.0:11434后重新启动。注意这样会暴露服务到局域网，确保网络环境可信。
注意：每次修改环境变量后都需要重启 Ollama 服务才能生效，直接
ollama serve不会读取新的变量值。
6. 进阶技巧：模型量化选择与推理速度调优
模型跑通之后，下一步是让它跑得更快、更省资源。Ollama 默认拉取的模型已经是量化版本，但量化等级有区别。deepseek-r1:7b默认使用 Q4_K_M 量化，在精度和体积之间取平衡。如果硬件条件紧张，可以手动指定更低精度的量化版本。
# 拉取 Q4_0 量化版本，体积更小但精度略降 ollama pull deepseek-r1:7b-q4_0 # 拉取 Q8_0 量化版本，精度更高但体积翻倍 ollama pull deepseek-r1:7b-q8_0量化等级的选择逻辑：Q4_0 体积最小，适合 8GB 内存设备；Q4_K_M 是默认推荐，精度损失可控；Q8_0 接近原始精度，但需要 16GB 以上内存。我一般会在 16GB 内存的笔记本上用 Q4_K_M，在 32GB 的台式机上用 Q8_0，实际体验差距在短文本问答中不明显，长文生成时 Q8_0 的连贯性更好。
推理速度的另一个关键参数是num_ctx，控制上下文窗口大小。默认值是 2048，增大到 4096 会显著增加内存占用，但能处理更长的对话历史。
# 启动时指定上下文窗口和线程数 OLLAMA_NUM_PARALLEL=2 ollama serve # 在 API 调用中指定 num_ctx curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "解释一下注意力机制", "options": { "num_ctx": 4096, "num_thread": 8 } }'num_thread设置为 CPU 物理核心数，超过核心数反而会因线程切换降低效率。OLLAMA_NUM_PARALLEL控制并发请求数，设为 2 表示同时处理两个请求，适合多人共用的场景，但每个请求的响应速度会下降。
验证调优效果的方法很简单：用同一个 prompt 分别在不同参数下跑三次，记录生成时间和输出质量。我习惯用time curl命令包裹 API 调用，直接看总耗时。
# 计时测试单次推理耗时 time curl -s http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "写一段 100 字的自我介绍", "stream": false }' > /dev/null从那以后我每次部署新模型，都会先用time跑一遍基准测试，再根据结果调整num_ctx和num_thread，而不是凭感觉猜。这套流程帮我在不同硬件上快速找到最优参数组合，希望帮到你。
本文还有配套的精品资源，点击获取
