
简介面向开发者和技术爱好者的DeepSeek模型部署指南系统梳理了在PC、手机及浏览器端运行该大模型的具体路径覆盖Ollama本地部署、移动端快捷方案与Open WebUI容器化集成。资源以1个docx文档打包压缩包整体约15KB内容按桌面端、iPhone、Android、Web端四个场景组织每部分均给出明确的安装命令、依赖配置和官方资源链接。文档详细演示了从拉取DeepSeek-R1模型到终端交互再到Android设备通过Termux编译Ollama、以及利用Docker部署Open WebUI的完整流程并包含API Key配置、存储权限设置、服务状态验证等关键细节可帮助读者避开常见坑点、快速复现多平台部署。指南还解释了模型在本地启动、远程调用和浏览器界面管理中的工作机制适合想要低成本体验大模型、或将AI能力融入自有业务流程的入门与进阶读者。已有3769人学习下载对于配置自有设备和搭建轻量级NLP应用具有直接参考价值。1. 多平台部署 DeepSeek 不是选边站Ollama 本地、移动端、WebUI 是一条链路的三个出口多平台环境下部署 DeepSeek 模型最常见的误区是把 Ollama 本地部署、移动端接入、WebUI 当成三个独立方案去比较。实际它们是同一条链路的三个出口模型由本地 Ollama 加载推理对外暴露 HTTP 服务手机端和 WebUI 都只是客户端。链路打通后你可以在电脑上敲命令聊在手机上接续会话在网页里管理模型算力始终只在一台机器上。适合内存 16G 以上、最好有 6G 以上显存的人想离线使用、不依赖云端或想在局域网内共享算力的人。需要公网多租户生产服务的团队应该直接上云 API。下文先从 Ollama 拉起 DeepSeek 的最小命令讲起再展开移动端两条接入路线和 WebUI 容器化部署最后把联调时的高频坑按现象、根因、解法拆开。2. 本地是起点用 Ollama 拉起 DeepSeek 的命令、参数与局域网开放2.1 为什么选 Ollama量化模型、显存占用与选型对照Ollama 在这里不是大模型它是一个推理运行时加模型仓库客户端帮你把「下载权重、量化、GPU 卸载、上下文缓存」这些脏活封装掉。你只需要ollama pull deepseek-r1:7b它就会把 GGUF 量化好的文件按层分片拉下来放在~/.ollama/models下然后按需把层加载到显存。相比直接用 HuggingFace 那套自己写加载和 offload 脚本的做法Ollama 的启动成本低得多而且原生暴露了/api/chat和 OpenAI 兼容的/v1/chat/completions两套接口移动端和 WebUI 对接时不用再造轮子。DeepSeek 的 R1 系列是带思维链的推理模型数学和逻辑场景表现好但同样的参数量比普通对话模型更吃上下文缓存选型时不要把显存卡得太死。下表是我在不同机器上跑过的常见标签和资源占用对照显存需求按权重加 KV cache 的最低估计给实际还会受上下文长度影响模型标签常见量化显存需求内存需求典型定位deepseek-r1:1.5bQ4 默认约 2G4G 以上手机端、老笔记本deepseek-r1:7bQ4_K_M约 6G8G 以上日常对话、代码deepseek-r1:8bQ4_K_M68G812G日常对话主力deepseek-r1:14bQ4_K_M1012G16G 以上复杂推理、长文档deepseek-r1:32bQ4_K_M20G 以上32G 以上强推理、研究用途选型逻辑我一般这样定第一次上手从 8b 开始速度和质量最平衡显卡只有 6G 显存就老实上 7b 或 1.5b纯 CPU 机器只建议 1.5b7b 在纯 CPU 上每秒只能吐出两三个 token体验接近不可用。显存不足时 Ollama 不会直接报错而是把超出的层放到内存里跑ollama ps里能看到 PROCESSOR 列变成 CPU 和 GPU 混合速度会断崖式下降。2.2 最小可用命令拉取、运行、验证一条龙安装这一步没什么玄学Linux 和 macOS 都可以用官方安装脚本Windows 直接下载安装包双击即可。脚本会把 Ollama 注册成后台服务监听 11434 端口命令行工具会同步装好。# Linux/macOS 官方脚本安装Windows 下载安装包即可无需此步 curl -fsSL https://ollama.com/install.sh | sh # 验证版本顺便确认命令是否进 PATH ollama --version安装完成后 Ollama 默认在后台运行但只监听127.0.0.1也就是只有本机能访问。接下来拉模型# 拉取 DeepSeek-R1 8B 量化版标签里的数字是参数量 ollama pull deepseek-r1:8b # 查看本地已有哪些模型 ollama listollama pull会分片下载中断后重新执行会先做完整性校验已完成的 blob 不会重新下载所以网络断了别急着删缓存直接重跑就好。磁盘至少要预留模型体积一倍半的空间8b 的 Q4 文件大约 4.7G但临时文件和校验副本会额外占空间。# 交互式运行进入对话界面 ollama run deepseek-r1:8b # 非交互方式直接传一句话适合脚本和连通性验证 ollama run deepseek-r1:8b 用一句话解释什么是 Dockerollama run首次加载模型要冷启动后面进入常驻状态默认空闲 5 分钟后被卸载以释放显存。交互界面里可以用/set parameter num_ctx 8192临时调上下文但这是针对当前会话的想固化要配合/save生成一个新模型标签细节放在后面章节展开。# 查看当前驻留的模型、占用显存和加载位置 ollama ps这是排查性能问题最该先跑的命令看 PROCESSOR 列是 CPU 还是 GPU看 SIZE 列能确定当前模型占用如果和你预期不符说明有别的模型占着显存或者参数没生效。2.3 开放局域网接口OLLAMA_HOST 与 CORS 配置默认监听 127.0.0.1 对多平台部署是致命的因为手机和 WebUI 容器都得通过网络访问这台机器。所以要改绑定地址让 11434 端口对局域网可见。# 前台启动并监听所有网卡测试时用这个最直观 OLLAMA_HOST0.0.0.0:11434 ollama serve # Linux 上想常驻用 systemctl 编辑服务配置 sudo systemctl edit ollama # 在 [Service] 段写入 EnvironmentOLLAMA_HOST0.0.0.0:11434 后保存重启macOS 上用launchctl setenv OLLAMA_HOST 0.0.0.0:11434设置然后重启 Ollama 应用Windows 在系统环境变量里加 OLLAMA_HOST 后重开服务。改完环境变量要重启 Ollama 进程才生效这是最容易忽略的一步。# CORS 白名单局域网用 * 图省事生产环境建议写具体来源 OLLAMA_ORIGINS* OLLAMA_HOST0.0.0.0:11434 ollama serveOLLAMA_ORIGINS 是给浏览器用的。后面 WebUI 页面跑在 3000 端口Ollama 跑在 11434对浏览器来说这是跨域请求不配这个变量页面会报 CORS 错误。*适合家庭局域网公司环境建议写成具体的来源地址。验证服务是否对局域网可见# 本机检查服务状态 curl http://localhost:11434/api/tags # 局域网设备访问换成你的实际 IP先在本机确认 IP curl http://192.168.1.100:11434/api/tags # 用 chat 接口做一次最小调用确认推理链路正常 curl http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d {model:deepseek-r1:8b,messages:[{role:user,content:你好}]}第二、三步要在非本机的设备上执行才有意义。返回 JSON 里能看到 model 字段和 message 内容就说明局域网链路已通。手机浏览器直接打开http://192.168.1.100:11434看到 “Ollama is running” 也算通。注意监听 0.0.0.0 意味着同一网段内任何设备都能调用你的模型。如果所在网络不完全可信用防火墙只放行特定 IP 访问 11434 端口不要裸奔。3. 移动端部署手机本地直跑与局域网远程调用两条路线3.1 手机上直接跑 DeepSeek轻量模型与终端方案手机端目前没有官方发布的 Ollama 客户端但 Android 平台可以借终端模拟器跑 arm64 版 Ollama亲测在 12G 内存以上的旗舰机上能跑起来。iOS 平台限制多不建议本地直跑直接跳到 3.2 的远程调用更现实。# 在 Android 终端模拟器里先更新基础环境 pkg update pkg install curl # 安装 Ollamaarm64 平台脚本会自动识别 curl -fsSL https://ollama.com/install.sh | sh # 拉一个 1.5B 推理模型这是手机端的现实选择 ollama pull deepseek-r1:1.5b # 开聊 ollama run deepseek-r1:1.5b手机端 Ollama 装好后同样监听 11434手机上访问 127.0.0.1:11434 即可。1.5b 在旗舰机上大约每秒几十个 token日常问答够用但发热和耗电非常明显连续对话二十分钟以上会触发系统温控降频速度掉到原来的三分之一。所以手机直跑定位是碎片化问答别拿它做长文档分析。多数人其实不需要在手机上装 Ollama更实用的路线是装一个支持自定义接口的对话 App把接口地址填成电脑的http://192.168.x.x:11434/v1模型名填deepseek-r1:8b手机就变成了一个纯终端算力全在电脑上。这条路线的体验和稳定性都远好于手机直跑。3.2 远程调用路线让手机连上局域网里的 Ollama 服务走远程调用需要满足三个前提电脑上的 Ollama 已经监听 0.0.0.02.3 节做完的事手机和电脑在同一局域网电脑防火墙放行了 11434 端口。三者缺一现象就是手机连不上或者超时。# 在手机上用终端类工具发一条请求验证链路是否真的通 curl http://192.168.1.100:11434/api/chat \ -H Content-Type: application/json \ -d {model:deepseek-r1:8b,stream:false,messages:[{role:user,content:手机远程测试}]}这里刻意加了stream:false让服务端一次性返回完整 JSON比流式更容易判断链路是否正常。判断标准是 HTTP 状态码加返回结构看到message:{role:assistant,content:...}就说明整条链路通了不用等流式分片。两种手机接入方式各有取舍方式客户端实际工作模型体验特点手机浏览器浏览器直开 WebUI电脑上的任意模型页面完整、可管理会话对话 App自定义接口 App电脑上的任意模型原生对话体验、可语音输入远程调用最大的收益是手机不考虑显存电脑上跑 14b 甚至 32b 都行手机只负责收发文本。代价是依赖局域网稳定性和电脑持续开机电脑进休眠、手机切网络连接立刻断。这个路线不要开放到公网公网访问涉及安全策略不在本文范围。3.3 移动端参数取舍模型大小、上下文长度与连接稳定性移动端是最容易在参数上踩坑的场景上下文开太大显存被 KV cache 吃光推理慢到怀疑人生模型选太大手机直跑直接烫手。我整理了一张按场景选的对照表使用场景推荐模型num_ctx理由手机本地碎片问答deepseek-r1:1.5b2048省电省内存够短问答局域网远程日常对话deepseek-r1:8b4096质量和速度的平衡点远程长文档分析deepseek-r1:14b8192上下文越大输出越慢按需调num_ctx 的设置方式交互式对话里先/set parameter num_ctx 8192再/save myds14b固化成一个新模型标签以后用ollama run myds14b就能保持这个上下文长度。全局默认值则用环境变量 OLLAMA_CONTEXT_LENGTH但它影响所有模型不建议和不同场景混用。移动端连接稳定性有三条血泪经验。第一条手机锁屏后 Wi-Fi 进入省电模式TCP 长连接会被系统断开解决方法是给对话 App 关闭电池优化保持后台联网权限。第二条电脑休眠等于服务下线部署期间把电源计划设成插电不睡眠。第三条模型空闲 5 分钟后被 Ollama 卸载手机再打开时第一次请求要重新加载模型几十秒没响应很正常这是冷启动不是故障后面章节会给常驻配置。4. WebUI 部署用 Docker 把 DeepSeek 变成浏览器里的对话服务4.1 WebUI 选型Open WebUI 与轻量化替代怎么选WebUI 解决的是「没有客户端也能用」的问题浏览器打开一个地址注册账号就能像用云服务一样对话还能切换模型、管理会话。自部署方案里最常见的是 Open WebUI它的后端默认对接 Ollama 的接口配置一条环境变量就能联调同时自带了多用户权限和服务端会话存储。选型本质上是在问自己三个问题要不要多用户、要不要服务端存会话、要不要 Docker。单机自己用轻量方案足够要在局域网给几个人共用Open WebUI 省心得多。对比维度Open WebUI轻量替换方案部署方式Docker 首选一条命令单文件 HTML / Python 脚本多用户权限支持账号、管理员、关闭注册基本没有模型切换界面下拉直接选改配置或换 URL会话存储服务端数据库浏览器本地适用场景长期使用、多人共享临时演示、个人验证我一般只在临时演示时用轻量方案日常部署都走 Open WebUI。它还有一个好处模型管理在 Ollama 侧WebUI 自动发现拉一个新模型刷新页面就会出现不用改任何配置。4.2 用 Docker 部署 Open WebUI 并接上 Ollama 的完整命令前置条件只有两个Docker 已安装Ollama 已在宿主机正常运行并监听 11434 端口。这里最容易翻车的是「容器里的 localhost」——容器里访问 localhost 指向容器自己不是宿主机所以必须用 host 网桥或真实 IP 来指路。# Linux 上部署 Open WebUI注意 --add-host 是 Linux 的关键配置 docker run -d \ --name open-webui \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main # 跟踪启动日志看到运行日志说明启动完成 docker logs -f open-webui参数说明-p 3000:8080把容器内 8080 映射到宿主机 3000浏览器访问 localhost:3000OLLAMA_BASE_URL告诉 WebUI 去哪个地址找 Ollama--add-hosthost.docker.internal:host-gateway是 Linux 上的必需项它把容器内的 host.docker.internal 指向宿主机网卡macOS 和 Windows 的 Docker Desktop 自带这个解析可以不加-v open-webui:/app/backend/data持久化账号、会话和配置容器删了数据还在--restart always让容器跟随 Docker 自启。启动后浏览器打开http://localhost:3000第一次注册的账号就是管理员这一步没有验证码局域网里谁先注册谁是管理员所以部署完第一件事就是去设置里关闭开放注册。# 确认 Ollama 里已有模型WebUI 会自动发现 ollama list # 确认 WebUI 日志里没有连接错误 docker logs open-webui 21 | grep -i ollama如果 WebUI 页面模型列表为空回宿主机ollama pull拉好模型刷新页面就会出现。不用 Docker 的替代做法是pip install open-webui但依赖本机 Python 和 Node 环境升级维护成本高我一般只在没法装 Docker 的机器上应急用。4.3 模型切换、权限设置与连通性验证WebUI 顶部有模型下拉框列出的就是 Ollama 里所有已拉取的模型切换随时生效。新模型只需在宿主机执行ollama pull deepseek-r1:32b刷新 WebUI 列表即出现这是整套链路里最顺滑的一环。权限上我的建议很明确局域网多人共用时让手机和电脑都走 WebUI 的 3000 端口而不是直连 Ollama 的 11434。原因是 WebUI 自带账号体系你可以关闭开放注册、给每个人建账号裸 API 则没有任何身份校验网段内任何人拿到地址就能调你的模型。# 脚本化验证走 Ollama 的 OpenAI 兼容接口WebUI 底层也是同一套 curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:deepseek-r1:8b,messages:[{role:user,content:你好}]}返回 JSON 里choices[0].message.content有内容就算通。WebUI 页面上能发消息、模型下拉框里有模型、日志无异常联调就算完成。5. 多平台部署避坑记录5 个高频问题的现象、根因与解法5.1 模型拉取中断重新运行总是从头开始现象ollama pull到 60% 断掉再次执行后进度条又从头滚等半天还在原地。原因拉取是分片下载中断后重新执行先做完整性校验校验期间进度条会从 0 重新计数看起来像从头下载实际上已完成的 blob 还在本地。但如果网络持续抖动会在同一个分片反复卡住直观表现就是一直停滞。解决别手动删~/.ollama/models下的临时文件直接重新执行ollama pull等它校验跳过。如果反复在同一个进度点失败换更小参数模型或更低量化标签减小体积边拉模型边跑大任务是坏习惯磁盘 IO 被占满会加大失败概率。5.2 WebUI 报 connection refusedOllama 明明在跑现象Docker 容器起来了WebUI 页面能打开但一发消息就提示连不上模型日志里出现connection refused。原因容器里的 localhost 是容器自己不是宿主机或者 Linux 上没加--add-hosthost.docker.internal:host-gateway导致OLLAMA_BASE_URLhttp://host.docker.internal:11434解析不到宿主机。解决先在容器里验证宿主机是否可达# 容器内测试宿主机 Ollama返回 JSON 或空都不是 refused 才是问题 docker exec open-webui sh -c \ curl -s http://host.docker.internal:11434/api/tags || echo CONN_REFUSED如果确认 refused把OLLAMA_BASE_URL改成宿主机真实 IP 重建容器docker run -d --name open-webui \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://192.168.1.100:11434 \ -v open-webui:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main改成真实 IP 是绕过容器网络解析问题最稳的办法缺点是你换网段后要重建容器所以家庭动态 IP 场景反而推荐用 host.docker.internal 加 host-gateway 的组合。5.3 浏览器控制台报 CORS 错误WebUI 界面一直转圈现象WebUI 页面加载正常但一发消息接口就失败浏览器控制台有明显的 CORS 拦截提示Ollama is running页面又能打开。原因WebUI 跑在 3000 端口Ollama 跑在 11434对浏览器来说跨域了。Ollama 默认只允许 localhost 来源必须显式配置OLLAMA_ORIGINS。解决在启动 Ollama 的环境里设置并重启# 局域网省事方案 export OLLAMA_ORIGINS* # 精确控制方案只放开 WebUI 的来源 export OLLAMA_ORIGINShttp://localhost:3000,http://192.168.1.100:3000 # 重启 Ollama 服务让环境变量生效 ollama serve改完必须重启 Ollama 进程只写进配置文件不重启等于没改。这个坑在 macOS 上尤其容易踩因为 Ollama 常驻用的是 launchd环境变量改完要重启应用或执行launchctl kickstart。5.4 显存明明够却一直走 CPU推理慢得离谱现象模型能正常回答但速度只有每秒几个 tokenollama ps里 PROCESSOR 列是 CPU 或 CPU/GPU 混合。原因三个常见来源。一是其他程序把显存占了模型放不下只能落内存二是模型需求超过显存Ollama 把超出部分放内存这是量化选型问题三是显卡驱动不带 CUDA 支持Ollama 根本没识别到 GPU装驱动前白折腾。解决先跑ollama ps看模型实际加载位置和显存占用再查系统监控确认显存余量。模型太大就换小参数量或低量化版本比如 8b 换 7b-q4_0关掉浏览器硬件加速和其他占显存的应用新装系统先确认显卡驱动完整再装 Ollama顺序反了会白跑一套流程。NVIDIA 机器在ollama --version输出里能看到 GPU 相关信息没有就是驱动层的问题。5.5 手机远程访问时断时续第一次响应总是特别慢现象手机上午用得好好的过会再打开要么连不上要么等了一分钟才出第一个字来回折腾很烦。原因三个因素叠加。默认keep_alive只有 5 分钟模型空闲 5 分钟后被卸载冷启动要重新加载模型手机锁屏后 Wi-Fi 进入省电模式长连接被系统断开电脑休眠或网络切换整个服务就失联了。解决按顺序排查。电脑端设置OLLAMA_KEEP_ALIVE-1让模型常驻代价是显存一直占着设置OLLAMA_NUM_PARALLEL提高并发应对多设备同时连接手机端给对话 App 关闭电池优化最后把电脑电源计划设成插电不睡眠。90% 的手机掉线问题都在这三条里先解决电脑端的两条再解决手机端的一条。6. 从能跑调到好用连通性验证、并发参数与日常检查6.1 三层连通性验证脚本每次改完配置我会按三层顺序验证能定位 90% 的问题出在哪一层# 第一层本机服务是否正常 curl -s http://localhost:11434/api/tags | head # 第二层局域网设备能否访问手机、另一台电脑上执行 curl -s http://192.168.1.100:11434/api/tags | head # 第三层WebUI 页面发一条消息看回显和模型列表本机通、局域网不通查防火墙和绑定地址局域网通、手机不通查防火墙出站规则和手机网络手机浏览器通了但 App 不通查 App 里填的 Base URL 和模型名。链路分层排查比乱重启服务高效得多。6.2 三个最值得调的参数参数推荐值说明OLLAMA_KEEP_ALIVE-1 或 30m-1 常驻适合多人共享单机建议 30m 平衡资源OLLAMA_NUM_PARALLEL按显存设 24并行请求数显存吃紧时调回 1num_ctx4096 起步每翻一倍KV cache 显存占用也约翻倍这三个参数配合表并发开大又想让模型常驻显存余量至少要够模型本身加两倍上下文的缓存否则模型会被迫卸载或降级到 CPU得不偿失。6.3 我的固定检查习惯整套多平台部署做完我每天的收尾习惯固定是三步先ollama ps看一眼驻留模型和显存占用再用手机浏览器走一遍真实链路发一条消息确认连通最后翻一眼服务日志看有没有反复报错。最大的教训是别让手机长期直连 11434 的裸 API没有身份校验管理和安全都不可控统一走 WebUI 一层才是正路另一个教训是环境变量改了不重启等于白改这个坑我踩过不止三次。希望帮到你。本文还有配套的精品资源点击获取