简介面向开发人员与技术爱好者的DeepSeek多平台部署指南系统梳理了本地、手机端及Open WebUI三条部署路径。内容以步骤化方式展开先介绍基于Ollama的本地环境搭建与模型拉取命令再针对iPhone与Android分别给出快捷指令、API Key配置及Termux编译运行方案最后讲解借助Docker Desktop、Ollama与Open WebUI完成容器化部署与模型试用的完整流程。资源为一份docx文档共1个文件压缩包约15KB适合希望快速上手DeepSeek的初学者及需要将模型集成到项目中的技术人员覆盖机器学习、深度学习与自然语言处理应用的轻量级部署场景。目前已有1521人学习下载文档中结合了命令行操作、依赖安装、版本验证与问题排查思路能帮助读者在不同设备上按图索骥地完成部署并为后续二次开发与调优提供参考。1. DeepSeek多平台部署到底在解决什么问题DeepSeek 多平台部署说白了就是同一个模型在本地电脑、手机端和 Web 界面里都能随时用起来。很多工程师一开始只会在命令行里ollama run模型跑起来了就以为完事了真到要把服务分享给同事、或者自己在外面用手机查资料时才发现模型在电脑上手机够不着网页又没界面。这篇文章把本地、手机端、Open WebUI 三条部署路径串起来讲透重点放在显存估算、服务监听地址、容器网络、上下文窗口这几个最容易翻车的地方。适合已经跑通过一次命令、但想把这套服务真正用起来的人也适合只想把 DeepSeek 放在自己机器上稳定用、不折腾云服务的开发者。读完你能照着落地而不是只记住几个零散命令。2. 本地部署模型选型、显存计算与最小服务命令2.1 你的机器到底跑得动哪个版本先算显存再动手本地部署 DeepSeek第一个要面对的问题不是命令而是“这台机器能不能跑起来”。DeepSeek 系列模型的参数量跨度很大从能塞进手机内存的小尺寸蒸馏版本到需要多卡并行的大模型版本都有。对绝大多数人来说真正合适的是量化过的尺寸版本而不是原版权重。常见做法是先用“模型文件体积 参数量 × 量化位数 ÷ 8 上下文开销”这个公式做粗算。例如 70 亿参数的模型用 Q4_K_M 量化权重体积大约 3.5GB如果还要开 8192 窗口KV cache 会再吃掉 12GB 甚至更多。所以判断标准不是“标称多少 G 显存”而是“模型文件 上下文开销 系统占用”是否低于你实际可用的内存。这里的可用内存不只是显卡显存。Ollama 在没有 GPU 时也会用 CPU 内存硬跑只是生成速度会慢到让人怀疑人生。选型建议可以列成一张经验表方便你对着自己的机器先预估。设备类型建议优先尝试代价8GB 内存的轻薄本7B 级别 Q4 量化能跑但长上下文和并发会吃力16GB 内存无独显7B14B 量化同时常驻一个模型别开太多并发16GB 显存独显14B32B 量化需要关注 KV cache 和并发请求数多卡或大显存服务器更大尺寸蒸馏版或完整能力版部署复杂度上升驱动和缓存策略是坑这张表不是硬指标。同一参数量不同量化等级、不同上下文长度实际占用差很远。所以落地前最好做一次“拉起服务 拉满上下文”的实测而不是只看模型下载页上的体积数字。我本地部署时习惯先拉 7B Q4 跑通链路再根据响应速度决定要不要换更大的量化版本。很多同学一上来就拉大模型结果连 prompt 都加载不出来那不是模型问题是选型没做。选型还要看用途。如果只是把 DeepSeek 当日常问答、代码片段生成7B 量化已经够用如果要做复杂指令跟随或长文档分析7B 的推理深度会明显不够这时更值得换大尺寸蒸馏版而不是在参数上硬调。记住一个原则显存决定能不能跑带宽和算力决定跑多快上下文决定能聊多长。三者都要满足缺一个都会让你觉得“模型变笨了”。2.2 用 Ollama 在本地起 DeepSeek 的最小命令选好尺寸后第一步是把模型拉到本地。常见做法是用 Ollama 这类本地推理运行时一条命令完成下载和加载。最小流程是这样# 拉取模型首次会下载到本机模型目录之后完全离线可用 ollama pull deepseek-r1:7b # 启动服务默认监听 127.0.0.1:11434 ollama serve第一条命令里的:7b是模型标签表示拉取 7B 量级版本机器配置更高就把标签换成 14b 或更大的存在版本。第二条命令ollama serve是让模型以 HTTP 服务方式跑起来后续手机端和 Open WebUI 都通过这个端口访问而不是再依赖ollama run的交互窗口。注意ollama pull和ollama serve是两个独立命令先 pull 是确保模型文件已就绪serve 只是启动服务。如果你需要同时服务多个客户端可以用环境变量控制并发和内存占用# 带参启动让单个模型同时处理 2 个请求并限制最多加载 1 个模型 OLLAMA_NUM_PARALLEL2 OLLAMA_MAX_LOADED_MODELS1 ollama serveOLLAMA_NUM_PARALLEL控制单个模型能同时处理几个请求设成 2 表示两路并发适合给同事做演示时避免排队。OLLAMA_MAX_LOADED_MODELS1表示同时只保留一个模型在内存里避免切换模型时把内存撑爆。默认情况下 Ollama 会自动保活最近用过的模型结果就是内存被长期占满。机器只有 16GB 内存、又不常切换模型时这个参数非常值得显式设置。启动后先别急着接 Web UI用命令行验证模型真的能出内容ollama run deepseek-r1:7b # 在交互窗口里输入 11?能看到回答就说明模型加载正常如果交互窗口能正常回答再退出继续下一步。这一步的意义是把“模型文件损坏”或“首次加载失败”这类问题挡在接入其他平台之前。很多人在这一步没验证直接去配 Open WebUI最后界面里看不到模型排查路径就长了很多。2.3 让局域网可访问与开机自启默认ollama serve只监听127.0.0.1也就是只有本机能访问。要让手机和 Open WebUI 能连必须让服务监听所有网卡。我一般会设置环境变量再启动# 监听所有网卡端口保持 11434 OLLAMA_HOST0.0.0.0:11434 ollama serve0.0.0.0表示不限网卡只要是这台机器收到的请求都接受。如果只想让特定网段访问可以写成192.168.1.10:11434这样只有通过该 IP 进来的请求能访问。对家庭和办公室局域网0.0.0.0更方便但也意味着同一个网络里的任何人都能访问你的模型服务。如果没有鉴权建议只在可信网络里这么开。要长期跑就不要每次手动起服务最好交给系统守护进程。Linux 下常见的做法是用 systemd 管理# 创建服务文件 sudo tee /etc/systemd/system/ollama.service /dev/null EOF [Unit] DescriptionOllama DeepSeek Local Service Afternetwork-online.target [Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_NUM_PARALLEL2 ExecStart/usr/local/bin/ollama serve Restartalways [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now ollama这段命令把 Ollama 变成开机自启服务环境变量全部写进 Unit。Restartalways是关键如果不写进程被系统杀掉后不会自动拉起来。ExecStart里的路径要以你which ollama的输出为准直接写死容易在升级时踩坑。配置好后用systemctl status ollama查看状态再用浏览器访问http://电脑局域网IP:11434能看到 Ollama 的运行提示就说明这一层已经通了。3. 手机端部署本地跑小模型还是连电脑服务3.1 先给结论手机直接跑 DeepSeek 是演示级玩法手机端部署听起来很酷但要有预期管理。手机跟电脑不一样内存虽然标得高但系统、相机、其他 App 会抢占大量内存真正能给模型用的很有限。再加上没有独立大显存DeepSeek 这类模型在手机上主要靠 CPU 或 NPU 算生成速度通常只有每秒几 token 到十几 token是“打字机速度”。这个体验拿来做个离线演示可以真要当日常助手用手机会发热、掉电快上下文稍长就慢得难受。所以做多平台部署时我更推荐把手机端当成“远程遥控器”让手机连回电脑上已经跑起来的本地服务。这样保留了手机端的输入体验又用上了完整算力。只有在你真的需要户外无网络、且不追求速度时才值得在手机本地塞模型。手机本地部署还有一个麻烦是模型文件管理。GGUF 文件动辄几个 GB手机存储、下载管道、版本更新都比电脑麻烦。很多 App 支持直接导入.gguf文件但不同的模型文件往往要匹配不同的对话模板导错就会出现乱码。从维护成本看手机全本地部署更像一个“玩”的方向而不是“用”的方向。想清楚这个边界再决定要不要往下走。如果你只是想在通勤时有手机对话框可聊天连局域网服务是性价比最高的方案。3.2 手机连局域网服务最快打通的多平台方案手机和电脑连同一个 Wi-Fi是成本最低的做法。先把电脑上的 Ollama 监听地址改成第 2 章里的0.0.0.0:11434然后在手机端安装支持 Ollama API 的聊天客户端配置一个自定义端点。通常只需要填三个值服务地址、端口、模型名称。服务地址填电脑的局域网 IP而不是localhost因为手机上的localhost指向手机自己不是电脑。先在电脑上查局域网 IP# 查看本机 IP手机端填写时要用 ipconfig # Windows ip a # Linux / macOS输出里找192.168.x.x或10.x.x.x那一项记下来。在手机聊天客户端的自定义连接页面按下面示例配置API 协议Ollama 服务地址http://192.168.1.20:11434 模型名称deepseek-r1:7b Keep Alive5m或默认Keep Alive是模型驻留时间。设为 5m表示 5 分钟没请求就卸载模型下次请求要重新加载首字延迟会明显变高设成30m或-1模型常驻内存响应快但持续占资源。如果 App 里没有这个选项就保持默认不用强求。手机连不上时不要先怀疑模型先在电脑上执行curl http://127.0.0.1:11434/api/tags。如果本机能通、手机不通就依次检查监听地址、防火墙、同一网段这三项。链路通了之后手机端就只是“换了个输入框”跟你电脑上的ollama run共用同一个模型状态。这里还要注意手机客户端最好支持流式输出因为 DeepSeek 推理时会先输出一段思考过程如果客户端一次性渲染看上去会像卡住了。3.3 手机全本地部署一个可复现的替代路径如果你确实需要脱离局域网方案就是直接在手机上跑小尺寸 GGUF 文件。操作上我一般不推荐在手机上从源码编译太容易翻车更稳妥的是找支持 GGUF 的移动端推理 App直接导入量化文件。流程可以归纳成下面几步1. 下载 Q4_K_M 量级的 7B 以下 GGUF 文件放到手机可访问的目录 2. 在移动推理 App 里导入该文件填写模型名称 3. 线程数先开 4跑通后再根据发热情况调整 4. 上下文长度先设 2048稳定后再逐步加大线程数很关键。手机 CPU 大核和小核性能差异很大全开线程会让手机瞬间发热、频率下降反而更慢。我一般先开到 4 线程试跑再根据每秒生成 token 数调整。上下文长度更要小心手机上的 KV cache 开销按 MB 算设太大可能启动时直接崩溃。这个路径的优势是完全离线、数据不出手机劣势是模型版本滞后、更新需要手动换文件而且很难跑超过 7B 的版本。如果你用的是支持 GGUF 的 App还要注意模型文件是否自带对话模板。有些发布者会把模板写在文件名里有些不会。导入后如果乱码不要急着重下文件先检查 App 的模板设置。把这个问题想清楚手机本地部署才不会变成一次性的“跑个热闹”。日常主力我还是建议连局域网服务手机全本地更适合固定网络环境之外的特殊演示。4. Open WebUI 部署把本地模型套上完整聊天界面4.1 为什么是 Open WebUI多用户与模型管理本地服务和手机端都打通后会发现还缺一个“给人用的界面”。命令行和手机 App 都绑定在单一用户视角而 Open WebUI 是现在把本地模型变成 Web 服务最常用的一层。它做的事情很清晰把 Ollama 后端的模型管理、对话记录、多用户登录、参数调节都收进一个浏览器页面。适合的场景是几个人共用一台机器或者你想在电脑浏览器里获得流畅的聊天体验。很多同学问手机客户端都有了为什么还要 Web UI原因有三个一是手机客户端一个人用一个Open WebUI 可以开账号隔离二是模型参数调节Web UI 上能可视化地改温度、上下文长度、系统提示词比命令行直观三是对话历史集中存储换手机不会丢。选型上Open WebUI 并不是唯一选择但它是跟 Ollama 配合度最高的一个。因为它原生支持 Ollama 协议不需要写胶水层环境变量配置好就能识别你本地的模型列表。如果你已经有 OpenAI 兼容网关它也能接只是会多一层调试。我通常只在不需要多用户、不需要界面时才绕过 Web UI 直接用 API 写工具。这一层部署本身不碰模型文件模型仍由 Ollama 管理Open WebUI 只是“读取模型列表 转发请求”。这个边界要清楚否则容器网络一有问题你很容易以为是模型坏了。4.2 Docker Compose 部署 Open WebUI 并接上本地 Ollama常见做法是用 Docker Compose 把 Open WebUI 跑起来再通过host.docker.internal这类宿主机别名连回本机 Ollama。下面是我常用的一份 Compose 文件services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - 3000:8080 extra_hosts: - host.docker.internal:host-gateway environment: - OLLAMA_BASE_URLhttp://host.docker.internal:11434 - ENABLE_OLLAMA_APItrue - DEFAULT_MODELdeepseek-r1:7b - WEBUI_AUTHfalse volumes: - ./open-webui-data:/app/backend/data restart: unless-stopped简单说明参数。ports把容器内 8080 映射到宿主 3000之后浏览器访问http://电脑IP:3000。extra_hosts是 Linux Docker 上让容器认识host.docker.internal的关键没有这行容器里解析不到宿主机。OLLAMA_BASE_URL告诉 Open WebUI 到哪找 Ollama这里不能写localhost因为容器内的 localhost 指向容器自己。ENABLE_OLLAMA_API开启内置 Ollama API 连接支持DEFAULT_MODEL让登录后默认选中 DeepSeekWEBUI_AUTHfalse是单机自用时的省事选项关掉登录页但如果服务有公网暴露风险应当改成 true。volumes用来持久化对话记录和用户信息不要省容器一旦重建没挂载卷的话所有聊天记录全没。启动命令和验证docker compose up -d curl http://127.0.0.1:3000/health/health返回OK说明 Web 服务起来了。然后打开http://127.0.0.1:3000如果界面右上角的模型下拉框能看到deepseek-r1:7b说明 Open WebUI 已经成功连上 Ollama。如果模型列表为空不要反复刷新先看容器日志docker logs open-webui里的连接错误多半是OLLAMA_BASE_URL写成了localhost。4.3 关键配置项模型管理、联网检索与用户权限模型管理层面Open WebUI 的模型下拉框来自 Ollama 的模型列表所以新增模型仍然是去 Ollama 里ollama pull界面会自动刷新。你还可以在“工作空间”里给同一个模型存多套系统提示词这比模型本体的参数更影响输出风格。联网检索是很多人想开的功能但要注意 Open WebUI 的联网搜索依赖可用的搜索后端。如果你所在网络环境访问不了默认搜索服务表现就是回答完还附一条“搜索失败”。我建议在没确认可用之前先关掉避免误导。用户权限方面WEBUI_AUTHtrue时首次注册账号默认是管理员其他注册用户可以通过管理面板改成只读或受限角色。还有一个容易被忽视的配置如果 Open WebUI 和 Ollama 不在同一台机器可以把OLLAMA_BASE_URL换成http://192.168.x.x:11434这样 Web UI 只做前端代理模型服务仍留在独立服务器。对多平台部署来说这个拓扑更合理手机和 Web UI 都只是客户端。4.4 如果不想用 Docker本地进程方式的参数对照部分机器没有 Docker或者公司环境不让你装。Open WebUI 也可以用 Python 直接起但我一般不推荐因为依赖安装容易把系统 Python 环境弄乱。如果坚持要跑建议至少建一个虚拟环境启动时用环境变量做同样映射。参数对照关系如下OLLAMA_BASE_URL在本地进程模式下写http://127.0.0.1:11434因为此时 Open WebUI 和 Ollama 在同一网络空间不需要host.docker.internal别名。WEBUI_AUTH、DEFAULT_MODEL与 Docker 模式同名。还需要注意端口冲突Open WebUI 默认用 8080如果你的机器已经有服务占用可以加--port 3000显式指定。无论用哪种方式核心原则不变Open WebUI 和后端模型之间必须网络可达端口必须开放模型必须已经在 Ollama 里 pull 过。先确认这三件事界面再花哨也不会出大问题。5. 多平台部署避坑指南显存、端口、token 与手机连接失败5.1 显存明明够拉起请求后 OOM 或速度骤降现象模型文件只有 4GB显卡显示剩余 8GB但一发起请求进程直接被杀掉或者前几个 token 很快、之后突然变慢。原因Ollama 不只加载权重还要分配 KV cache。上下文越长、并发请求越多KV cache 增长越猛。你看到的“剩余显存”是静态数值不是模型运行时的峰值占用。解决先限制并发和上下文再排查。把服务停掉用OLLAMA_NUM_PARALLEL1 ollama serve重启并在请求参数里把num_ctx降到 4096确认稳定后再逐步加。如果仍 OOM换更小量化版本或者把部分层放到 CPU。Ollama 里可以通过 API 参数控制 GPU 层数很多客户端也暴露了这个选项。不要一上来就开 16384 上下文那不是默认值是小马拉大车的典型翻车方式。5.2 服务起了手机 App 却连不上现象电脑上curl http://127.0.0.1:11434/api/tags正常手机填http://电脑IP:11434却超时或连接拒绝。原因通常有三个一是 Ollama 仍只监听127.0.0.1局域网请求进不来二是系统防火墙拦了 11434 端口三是手机和电脑不在同一个 Wi-Fi或者手机开着蜂窝数据。解决先看监听地址执行ss -tlnp | grep 11434。如果显示127.0.0.1:11434就用OLLAMA_HOST0.0.0.0:11434重启服务。然后在电脑防火墙里放行 TCP 11434。最后确认手机连接的 Wi-Fi 和电脑是同一个路由设备而不是访客网络。排查顺序很重要先本机 curl再局域网内用另一台电脑 curl最后才是手机。这样能把问题快速压缩到某一层。5.3 回答到一半突然停像被截断现象对话稍长一点模型的回答在明显没说完的地方停下没有任何报错提示。原因上下文窗口num_ctx默认偏小到达上限后模型停止生成。这不是模型“笨”是窗口塞满了。解决在请求里显式带上上下文参数例如options: {num_ctx: 8192}。同时要明白增大 num_ctx 会线性增加 KV cache 占用并且首字延迟会变高。不要一上来就设 65536先 8192 试看显存和速度都能接受再往上加。还有一点Open WebUI 每个对话有自己的上下文管理需要检查 Web UI 里的“上下文长度”设置而不是只在 Ollama 层调。两个位置不一致时表现就是有时候截断有时不截断非常玄学。5.4 Open WebUI 容器里看不到模型现象Open WebUI 能打开但右上角模型列表为空容器日志报connect ECONNREFUSED 127.0.0.1:11434。原因容器内的localhost指向容器自己不是宿主机。很多网上的配置示例写OLLAMA_BASE_URLhttp://localhost:11434这在 Docker 模式下是错的。解决把OLLAMA_BASE_URL改成http://host.docker.internal:11434并确保 Compose 文件里有extra_hosts: - host.docker.internal:host-gateway。macOS 的 Docker Desktop 自带这个别名但 Linux 上必须显式配置。如果你用的是 Podman别名方式类似但细节有差异建议直接看容器日志验证。这个问题我踩过不止一次每次都是因为“本地能通就顺手写了 localhost”后悔药就在环境变量里。5.5 手机导入 GGUF 后输出乱码或模板错乱现象手机端导入 GGUF 后能加载但回答语言混乱、出现大量替换符或者模型完全不知道自己在聊什么。原因模型文件没有包含对话模板或者 App 使用的模板与模型要求的模板不一致。对话模板决定了系统提示词、用户输入和助手输出怎么拼装拼错就是乱码。解决下载 GGUF 时注意文件说明里是否标注了“带 chat template”。如果仍乱码关掉 App 的自动模板识别手动选择与模型匹配的模板。这个坑在自己量化或从非正式渠道下载的文件里尤其常见。不要拿乱码去怪模型先用排除法换一个官方发布的量化文件试试通常能快速定位。6. 部署完怎么验证与调优压测脚本与我的部署习惯6.1 先跑一个最小请求确认完整链路接入 Open WebUI 之后不要急着聊功能先用 API 直接打一次后端确认模型、端口、上下文三条链路都正常curl http://127.0.0.1:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 只回复链路正常}], stream: false }stream: false是让服务一次性返回完整结果方便看耗时和报错。如果返回里有done: true说明服务端没问题。6.2 用并发请求看服务耐不耐用多人接入后单请求正常不代表并发正常。我一般会写一个很短的 Python 脚本同时开几个请求压一下import json import time import urllib.request from concurrent.futures import ThreadPoolExecutor url http://127.0.0.1:11434/api/chat payload { model: deepseek-r1:7b, messages: [{role: user, content: 数到 50}], stream: False, options: {num_ctx: 4096}, } def send_one(_): start time.time() req urllib.request.Request( url, datajson.dumps(payload).encode(), headers{Content-Type: application/json}, ) with urllib.request.urlopen(req, timeout60) as resp: json.loads(resp.read()) return time.time() - start with ThreadPoolExecutor(max_workers4) as pool: times list(pool.map(send_one, range(4))) print(耗时列表:, [round(t, 2) for t in times])脚本用ThreadPoolExecutor开 4 个并发请求分别记录每个请求的耗时。如果某个请求卡到 timeout说明并发能力不足优先检查OLLAMA_NUM_PARALLEL和上下文长度。这里的timeout60是最大等待时间不是模型生成预算千万理解清楚。6.3 我现在的部署习惯我现在的固定习惯是Ollama 作为唯一后端常驻Open WebUI 映射到 3000 端口手机端走同一局域网连 11434。三个客户端共用同一份对话模型不存在“手机一个版本、电脑一个版本”的割裂。版本更新时我只在 Ollama 里重新ollama pull对应标签Open WebUI 和手机端不需要改任何配置。之前有一次图省事把WEBUI_AUTHfalse挂着结果同事误改了系统提示词我花了一个下午才找回来。从那以后哪怕只是内网用我也会开最简单的登录鉴权。这不算安全加固只是给自己留个后悔药。部署这条路最怕的不是命令不会写而是每一层都“好像通了”最后串联时找不到断点。希望这篇指南能帮你少走这一段弯路。本文还有配套的精品资源点击获取