简介面向AI开发者与技术爱好者的DeepSeek模型多平台部署实操指南聚焦从本地到移动端再到Web端的完整落地路径。内容以Ollama为核心覆盖macOS、Linux、Windows下环境安装、模型拉取与终端交互针对手机用户给出iPhone快捷指令调用与Android Termux编译运行的特定方案同时讲解借助Open WebUI与Docker容器化实现浏览器访问的集成部署。资源为单个docx文档压缩包大小约15KB结构紧凑适合快速查阅。目前已有3766人学习浏览。文档中提供了明确的命令行操作、官方下载链接、环境配置与验证步骤读者可对照完成DeepSeek-R1系列模型的部署与对话测试减少踩坑成本同时也能理解多设备协同使用大模型的基本思路适合将AI能力快速融入个人设备或业务实验环境。1. 多平台部署 DeepSeek 没有唯一路径但 Ollama 是最好的起点如果你手上已经有一份 DeepSeek 的模型权重或者只是想在笔记本上跑通一次对话最快的方式不是去读 Hugging Face 上的推理脚本而是先装一个 Ollama。它把模型下载、量化、显存调度和 OpenAI 兼容 API 全部收敛进一个本地守护进程之后无论接手机 App 还是 Open WebUI本质上都是往这个进程上挂客户端。本篇就按「本地 Ollama → API 暴露 → 移动端接入 → WebUI 容器化」的顺序推进覆盖从零部署到联调排错的完整链路。适合正在选型本地大模型方案的后端工程师也适合想在局域网里给团队搭一个私有对话服务的运维同学。读完你应该能回答三个问题模型下不动怎么办手机怎么连上局域网里的 DeepSeek以及 Open WebUI 和 Ollama 之间到底怎么建立关联。2. Ollama 安装与 DeepSeek 模型拉取先解决下载慢的问题2.1 安装 Ollama 的三种方式与国内镜像加速Linux 服务器上最常见的做法是执行官方安装脚本它会自动识别 CUDA、ROCm 或纯 CPU 环境并安装对应运行时。macOS 和 Windows 直接下载安装包即可Windows 版安装后会常驻后台并默认暴露127.0.0.1:11434。安装完成后先确认守护进程状态curl -fsSL https://ollama.com/install.sh | sh systemctl status ollama ollama --version第一条命令通过管道把远端脚本交给 sh 执行装完后 systemd 会自动拉起ollama serve。ollama --version用来确认 CLI 与守护进程版本一致。如果服务器在国内且拉取脚本超时可以改用离线安装包或者直接到镜像站下载对应架构的二进制文件解压到/usr/local/bin。下载模型慢是本地部署里最常被卡住的一步。Ollama 默认从registry.ollama.ai拉取模型层国内网络下经常只有几十 KB/s。常见的绕行方案是设置镜像环境变量后重启服务export OLLAMA_HOST0.0.0.0 export OLLAMA_MODELS/data/ollama/models export OLLAMA_NUM_PARALLEL4OLLAMA_HOST设为0.0.0.0是让局域网内其他设备能访问 API默认只监听回环地址。OLLAMA_MODELS把模型存储目录从系统盘迁到大容量数据盘避免~/.ollama/models塞满根分区。OLLAMA_NUM_PARALLEL控制并发请求数显存充足时可适当调大。如果下载仍然不稳定还有一个可靠兜底从 ModelScope 下载 GGUF 格式权重再用本地 Modelfile 导入 Ollama。2.2 用 ModelScope 下载 GGUF 后导入 OllamaModelScope 上有社区维护好的 DeepSeek 量化版本下载速度远快于官方 registry。先安装modelscopePython SDK然后指定模型仓库和缓存目录拉取文件pip install modelscope modelscope download --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B-GGUF --local_dir /data/models/deepseek参数说明--model指定仓库 ID--local_dir决定文件落盘位置。下载完成后写一份Modelfile指向 GGUF 文件并声明对话模板FROM /data/models/deepseek/deepseek-r1-distill-qwen-7b-q4_k_m.gguf TEMPLATE {{- if .System }}system: {{ .System }}{{ end }} user: {{ .Prompt }} assistant: PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER stop |im_end|在 Modelfile 所在目录执行ollama create deepseek-r1:7b-q4 -f ModelfileOllama 会读取 GGUF 头信息生成模型版本名自定义为7b-q4。之后ollama run deepseek-r1:7b-q4就能正常对话。这个导入流程的意义在于它把模型获取与模型运行解耦凡是能拿到 GGUF 的渠道都能变成 OLLAMA_MODELS 的合法来源不需要动 Ollama 本身的 registry 配置。2.3 显存选型不同量化级别怎么选本机资源不同能跑的模型大小完全不同。DeepSeek 系列蒸馏模型在 Ollama 里有多个 tag选择依据只有一个你的 GPU 显存和内存带宽。下面这张表按经验值列出常见规格量化等级统一为 Q4_K_M模型参数占用显存(约)最低硬件适合场景1.5B1.5 GB纯 CPU/低端卡意图识别、文本分类7B5 GBGTX 1660 6G日常问答、代码补全14B10 GBRTX 4080 16G长文档、逻辑推理32B22 GB双卡或 4090 48G复杂推理、Agent 任务70B42 GBA100 80G生产级对话、蒸馏上限有独立显卡但显存不足时Ollama 会把部分层 offload 到 CPU但性能会断崖式下降。纯 CPU 环境跑 7B 模型速度约 5 token/s只适合验证流程。Q8 量化比 Q4 更接近原模型效果但显存占用几乎翻倍。移动端接入场景下建议直接使用 Q4 量化版本因为最终瓶颈在局域网传输和手机内存。3. Open AI 兼容 API 与模型管理移动端和 WebUI 都靠它3.1 Ollama 的 API 端点与请求结构Ollama 的值钱之处在于它内置了 OpenAI 兼容接口监听在11434端口。移动端 App、Open WebUI、甚至codex这类开发工具都只需要配置一个base_url就能接入不需要各自实现一套模型加载逻辑。先看最常用的两个端点。对话补全端点POST /api/chatcurl http://localhost:11434/api/chat -d { model: deepseek-r1:7b-q4, messages: [ {role: user, content: 用 SWIG 包装一个 C 类} ], stream: false }返回 JSON 里的message.content就是最终回答。stream: false表示完整结果一次返回适合脚本调用移动端交互场景建议设true走 SSE 流式输出用户等待时间会变短。生成参数端点POST /api/generate则更接近纯文本补全适合做单轮提示词模板实验。OpenAI 兼容端点位于v1/chat/completionsbase_url写作http://host:11434/v1。这也是 codex 等工具接入 Ollama 的入口配置model_provider指向本地地址即可。它的 body 结构和 OpenAI 保持一致Ollama 会负责把temperature、top_p等参数映射到内部采样器。3.2 模型生命周期拉取、热切换与内存释放运行时经常需要同时管理多个模型比如deepseek-r1:7b负责对话nomic-embed-text负责 WebUI 里的向量检索。Ollama 默认把最近使用的模型保持在显存中长时间不调用会按 LRU 策略自动卸载。手动干预用三条命令ollama pull deepseek-r1:7b ollama rm deepseek-r1:7b-old ollama show deepseek-r1:7b --modelfilepull是增量下载已存在且 hash 一致的层会跳过rm同时删除对应的层文件释放磁盘show能查看模型架构、参数量、嵌入长度和量化信息排查奇偶层问题时会用。若多个模型并发占用导致显存溢出可以在请求体里加keep_alive: 5m让模型在 5 分钟无请求后主动退出显存。3.3 与 codex / OpenAI SDK 对接的参数联调向量化地讲Ollama 暴露的 OpenAI 兼容层没有完全实现 OpenAI 的全部字段但核心的messages、temperature、max_tokens、stream都已覆盖。用 Python 的openaiSDK 对接时只需要替换base_url和api_keyfrom openai import OpenAI client OpenAI(base_urlhttp://192.168.1.20:11434/v1, api_keyollama) resp client.chat.completions.create( modeldeepseek-r1:7b-q4, messages[{role: user, content: 解释一下 num_ctx 的作用}], max_tokens512, temperature0.6 ) print(resp.choices[0].message.content)不要怀疑api_key为什么写ollama这个字段在本地模式下会被忽略但 SDK 要求非空。num_ctx是 Ollama 特有参数控制上下文窗口长度默认 2048调高到 8192 会显著增加显存占用。temperature在代码生成任务里建议设低0.20.4对话任务设 0.7 左右平衡创造性。4. 移动端接入局域网暴露、App 选型与性能优化4.1 通过局域网 API 让手机访问本地 DeepSeek移动端要连的是 Ollama 的 API 端口而不是 SSH 或文件共享。先确保服务端绑定了非回环地址然后从手机侧用浏览器或 curl 验证连通性# 服务端查看监听地址 ss -tlnp | grep 11434 # 手机端或者局域网另一台机器验证 curl http://192.168.1.20:11434/api/tags/api/tags返回当前已下载的模型列表连得通就说明网络层没有隔离问题。注意OLLAMA_HOST改完后必须重启 Ollama 进程systemd 模式下执行systemctl restart ollama。手机和服务器最好在同一广播域如果跨 VLAN 要放行 TCP 11434 端口。不建议直接把端口映射到公网因为 API 默认无鉴权任何人都能调用你的算力。4.2 移动端常用的三套客户端方案移动端大体有三类接入方式各适合不同需求原生 App 类如 Maid、Enchanted内置 Ollama 连接配置填入http://局域网IP:11434即可适合快速体验。通用 AI 对话 App如 Chatbox 移动版在设置里选择自定义 API 类型填 base_url 与模型名适合同时接多家服务。自研 H5 / React Native 应用通过 WebSocket 或 fetch 调用 OpenAI 兼容端点适合集成进业务系统。自研场景下有个浏览器兼容问题手机上非 HTTPS 页面访问局域网 HTTP 接口会被混合内容拦截。开发环境可以用 iOS 的 ATS 例外或 Android 的usesCleartextTraffic放行但正式环境建议用 PWA 或原生壳包装。其次是 CORS 问题Ollama 默认允许跨域但生产环境建议在前面加一层 Nginx 反向代理统一处理 CORS、限流和 HTTPS 证书。4.3 React Native 与 H5 调用的最小请求示例下面是一个基于 fetch 的最小对话实现兼容 React Native 和浏览器 H5async function chat(question) { const resp await fetch(http://192.168.1.20:11434/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: deepseek-r1:7b-q4, messages: [{ role: user, content: question }], max_tokens: 256, stream: false }) }); const data await resp.json(); return data.choices[0].message.content; }代码里有两个关键点一是模型名必须与服务器上的ollama list结果完全一致否则返回 404二是stream: false在弱网环境下体验较差建议改成 SSE 流式并解析data:前缀事件。React Native 如果遇到网络请求失败优先检查 Android 的网络安全配置和 iOS 的本地网络权限这两个是移动端连局域网服务最典型的坑。移动端性能优化的核心不在端上而在服务端。手机渲染一个 token 一次网络往返7B 模型在 1050Ti 级别的 GPU 上生成速度可能只有 20 token/s体验会比较拖沓。换个思路用 1.5B 模型做摘要或意图提取再用 7B 模型做精细回答把耗时的推理放在 Wi-Fi 环境移动端只负责展示。5. Open WebUI 部署Docker 容器化与 Ollama 关联配置5.1 用 Docker 拉起 Open WebUI 并连接已有 OllamaOpen WebUI 是目前 Ollama 生态里最流行的自托管对话界面提供用户注册、多会话管理、Markdown 渲染、RAG 等功能。官方镜像托管在ghcr.io用 Docker 部署时建议用 named volume 持久化数据。先看最小可用配置docker run -d --name open-webui \ -p 3000:8080 \ -v open-webui:/app/backend/data \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -e WEBUI_AUTHFalse \ --restart always \ ghcr.io/open-webui/open-webui:main参数拆开讲-p 3000:8080把宿主机 3000 端口映射到容器内 8080-v open-webui:/app/backend/data用 Docker volume 存 SQLite 数据库和上传文件重启容器不丢OLLAMA_BASE_URL是连接 Ollama 的关键Docker Desktop 环境下用host.docker.internal指代宿主机Linux 原生 Docker 需要改成--networkhost或用宿主机 IP。WEBUI_AUTHFalse表示跳过登录页适合内网家庭环境若多人使用删掉这个环境变量即可开启邮箱注册和密码登录。启动后用宿主机浏览器访问http://localhost:3000首次进入会看到模型选择下拉框里面应该已经出现 Ollama 里的模型列表。如果列表为空先检查OLLAMA_BASE_URL能否在容器内访问docker exec -it open-webui curl http://host.docker.internal:11434/api/tags5.2 模型管理与 RAG 知识库的依赖关系Open WebUI 浏览 Ollama 模型走的是它内置的模型发现逻辑。它不仅能把 Ollama 现有模型展示出来还能在界面上直接拉取新模型相当于调用了 Ollama 的/api/pull接口。管理员面板里可以设置模型权限哪些模型对普通用户可见哪些作为管理员专属。开启 RAG 对话时Open WebUI 需要两个额外组件一个嵌入模型和一个向量数据库。嵌入模型默认从 Ollama 拉取nomic-embed-text或bge-m3向量数据库在 Docker 单机模式下自动切换到内置的 Chroma不需要额外部署。若数据量大或者要跨容器共享才考虑接 Qdrant。Windows 用户常见的问题是docker run卡在 pulling layers这通常与镜像 ghcr.io 拉取速度有关可通过配置镜像加速器或设置 Docker 代理环境变量解决。5.3 用户权限与多模型隔离的落地配置当多人共用一台 GPU 服务器时推荐开启用户注册并关掉匿名访问。在容器启动参数中不设置WEBUI_AUTH首次访问会让你创建管理员账户。之后每个用户都能创建自己的会话但模型仍由所有物理设备共享。如果你希望 A 组只能用 7B 模型、B 组只能用 32B就需要在 Open WebUI 的管理后台里建立分组并限制可访问模型。这个功能本质上是让 Open WebUI 在生成请求时做模型名白名单校验而不是真正的显存隔离因此不能让用户独自占用模型资源。6. 把 Ollama 注册成系统服务并用 curl 验证全链路模型和界面都部署好后最后一步是把 Ollama 的启动从手动ollama serve变成开机自启并用一次完整的 HTTP 请求验证「手机/浏览器 → Open WebUI → Ollama → 模型」的链路是否通畅。Linux 上安装脚本已经注册好 systemd但手动编译安装的需要自己写 unit 文件[Unit] DescriptionOllama Service Afternetwork-online.target [Service] EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_MODELS/data/ollama/models ExecStart/usr/local/bin/ollama serve Restartalways RestartSec3 [Install] WantedBymulti-user.target把文件放到/etc/systemd/system/ollama.service然后执行systemctl daemon-reload systemctl enable --now ollama。注意ExecStart的二进制路径要和which ollama一致OLLAMA_MODELS路径要提前建好并且给运行用户写权限。配置完成后用curl -i检查响应头确认 WebUI 能正常转发请求curl -s http://localhost:3000/api/health返回true表示 Open WebUI 本身健康。接着访问http://localhost:3000/api/models看模型列表是否完整。即便走的是 GUI这两条 curl 也能在排查问题时分清是界面层还是模型服务层出错。部署完成后有一个实测技巧在 WebUI 里新建聊天反复发送同样的问题同时用ollama ps观察模型是否常驻在显存中——如果频繁加载说明keep_alive设得太短建议在环境变量中设置OLLAMA_KEEP_ALIVE30m拉长热驻留时间减少首次回答延迟。本文还有配套的精品资源点击获取
