简介这份《DeepSeek多平台部署指南》面向希望把DeepSeek模型落地到实际环境的开发人员与技术爱好者聚焦机器学习、深度学习模型部署及自然语言处理应用场景兼顾初学者与有一定基础的技术人员。文档围绕本地Ollama、iPhone快捷指令、Android Termux以及Open WebUI配合Docker等部署路径展开整理出较完整的操作指引、关键命令与常见问题处理思路并针对跨平台环境差异、依赖安装和模型拉取等环节给出提示便于读者按设备类型快速定位所需方案。资源包共1个docx文件大小约15KB内容紧凑适合作为部署前的路线参考和排错查阅材料。目前已有1521人学习说明其在不同平台部署DeepSeek的实际需求中具有一定参考价值。读者可从中获得多平台部署的整体框架、环境准备要点和问题应对思路用于个人研究、项目集成或日常使用。1. 一套模型三种装法为什么 DeepSeek 的部署路径没有“统一答案”很多人第一次接触 DeepSeek 部署会默认认为“装一次就能到处用”。实际跑一遍就会发现同一份模型权重在笔记本、手机和浏览器界面上对应的是三套完全不同的运行时契约。本地机器上你面对的是 Ollama 的进程、端口和量化策略手机上iOS 和 Android 又分成两条路一个把推理交给远端 API一个试图在终端里从源码编译到了 Open WebUI模型服务又退到容器后面前面盖一层网页界面。这三套路径的差异不是“操作步骤不同”这么表面而是各自受限于内存、沙箱、网络栈和进程模型。把这些约束搞清楚换平台时就不会把某条路径的经验硬套过去部署翻车时也能判断问题到底出在模型、运行时还是网络。2. 本地部署ollama run背后到底在做什么2.1 模型分发一条命令为什么能同时完成拉取和运行先看这条命令ollama run deepseek-r1:7b。很多人以为它只是“运行一个已经存在的模型”实际上这行命令至少做了四件事解析模型名和标签、检查本地模型库、必要时从远端拉取权重、加载模型并进入交互式会话。把“拉取”和“运行”合成一条命令是 Ollama 和直接下载 GGUF 文件最大的区别。常见的实现思路是Ollama 维护一个本地模型存储目录通常在用户主目录下的.ollama/models模型名里冒号后面的部分是标签标签决定拉取哪个量化版本。第一次执行时命令会阻塞在下载阶段下载完成后同样的命令才会进入对话模式。第二次执行时因为本地已有缓存启动时间会明显缩短。这里还有一个容易被忽略的分层结构模型存储通常分成 manifest 和 blob 两层。manifest 记录模型名、标签和分层引用关系blob 才是实际的权重文件。拉取时按层下载支持断点续传多个模型版本共享底层权重时还能省空间。理解这一点后面排查“拉取一半卡住”或者“磁盘被吃满”时就有方向了。模型名里的7b表示参数量约 70 亿。这个数字直接关系到内存占用。一个粗略的估算方式是在 4-bit 量化下每 10 亿参数大约需要 0.60.8GB 内存或显存7b 模型大致落在 46GB 区间具体取决于量化格式和上下文长度。如果机器内存不够模型会加载失败或者被系统换到极慢的路径上。提示先确认机器的可用内存再选模型标签。7b 是很多笔记本的甜点但 8GB 内存的机器同时开着浏览器和编辑器时留给模型的空间可能就不够了。2.2 量化与内存7b、8b 这些数字和显存的关系模型文件不是原样加载的。训练出来的权重通常是 16 位浮点直接加载会占用大量内存。量化就是把权重压到更低位数用精度换体积和速度。deepseek-r1:7b在模型库里通常对应 4-bit 量化版本这也是它能在消费级硬件上跑起来的前提。这里有个容易忽略的点量化不是无损的。4-bit 量化在多数对话任务上表现接近原始模型但在数学推理、长上下文和严格格式输出上可能退化。部署时如果发现模型“变笨了”先别怀疑模型本身检查一下拉取的是不是量化版本、量化位数是多少。量化位数大致体积7b内存需求适用场景4-bit约 4GB6GB 左右日常对话、普通问答8-bit约 7GB10GB 左右需要更高精度的推理16-bit约 14GB16GB 以上研究、对精度敏感的任务注意上表是量级估算实际体积还和模型结构、词表大小有关不同版本之间会有出入。另外上下文窗口越大推理时占用的缓存内存也越多长对话场景要额外留出空间。还有一个常被低估的部分是 KV 缓存。模型加载本身只占一部分内存推理过程中每轮对话都会累积上下文缓存这个缓存随上下文长度线性增长。7b 模型在较长上下文下缓存本身可能就要占用 12GB。所以“模型能加载”和“长对话能跑”是两回事部署时如果只按模型体积估算内存长对话阶段很容易翻车。2.3 交互式会话与 API 服务同一进程的双重身份ollama run启动的进程不只是一个终端对话框。它在本地默认监听一个端口通常是 11434对外提供 HTTP API。这意味着你在终端里敲的每一句话和用curl发出去的请求走的是同一个模型服务。这个设计让本地部署和后续的 WebUI 对接可以共用一套后端。验证服务是否起来的方式是# 检查 Ollama 服务是否在监听返回版本信息说明服务正常 curl http://localhost:11434如果返回一段包含版本号的文本说明服务进程在跑如果连接被拒绝说明服务没启动或者端口被改过。这里的关键是命令行交互和 API 访问不是两套东西而是同一个服务进程的两个入口。常见的实现思路是Ollama 启动时先拉起一个常驻服务进程命令行客户端再通过本地 HTTP 和这个服务通信。所以即使你没在终端里保持对话服务本身也可能在后台监听。部署到 Open WebUI 时正是这个常驻端口被容器网络访问到。HTTP API 支持流式输出客户端发送请求后逐块接收生成结果。这也是上层界面交互流畅的原因——它不用等整个回答生成完再渲染。理解这个流式机制后面排查“界面一直转圈但模型其实已经在生成”这类问题时会有帮助。3. 手机端部署iOS 快捷指令和 Android Termux 为什么走了两条路3.1 iOS 快捷指令加 API Key远端推理本地只做编排iPhone 上的方案不是“在手机上跑模型”而是“在手机上构造请求”。具体做法是安装一个快捷指令填入 API Key由快捷指令把用户输入发送到远端服务再把返回结果展示出来。模型推理发生在远端手机只承担输入、网络请求和结果渲染。为什么 iPhone 不能像 Android 那样在本地跑模型原因有几层。第一iOS 对后台进程和本地端口的限制很严普通应用很难长期维持一个监听服务。第二从源码编译并运行 Ollama 需要终端环境和包管理器这在非越狱环境下基本不可行。第三应用商店的分发模型也不允许随意加载任意二进制。所以 iOS 路径的本质是“客户端 远端推理”。快捷指令在这里扮演一个轻量编排层它负责发 HTTP 请求、处理 API Key、格式化输出。这里的 API Key 是访问远端服务的凭证需要妥善保管因为它直接对应调用配额。从机制上看快捷指令发出的请求和你在电脑上用curl调 API 没有本质区别只是把请求构造和结果展示包装成了一个可点击的动作。这条路径的边界也很清楚网络不通就没法用API Key 失效就报错远端服务的可用性决定了本地体验。它优化的是“打开就能问”代价是把控制权交给了远端。3.2 Android Termux在终端里从源码编译的可行性边界Android 路径完全是另一个方向。Termux 提供一个类 Linux 终端环境可以安装包、编译代码、运行服务。项目正文给出的流程是安装 Termux、设置存储权限、更新包管理器、安装依赖、克隆仓库、编译、启动服务、拉取模型。每一步都有明确的机制含义# 让 Termux 获得访问共享存储的权限 termux-setup-storage # 刷新包索引并升级已安装的包 pkg update pkg upgrade # 安装编译工具链和依赖 pkg install git cmake golang libjpeg-turbotermux-setup-storage让应用获得文件系统访问权限编译产物和模型缓存需要写入磁盘。pkg update刷新软件源索引pkg upgrade升级已有包避免依赖版本不一致导致编译失败。git用来拉代码cmake负责构建配置golang是编译 Ollama 主体的工具链libjpeg-turbo通常是处理图像输入时的依赖。接下来是克隆和编译# 只拉取最近一次提交减少下载体积和等待时间 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # 执行源码里定义的代码生成步骤 go generate ./... # 编译当前包产出可执行文件 go build .--depth 1表示浅克隆只拉最近一次提交省流量也省时间。go generate ./...执行源码里//go:generate注释标记的命令用于生成代码或资源。go build .把当前包编译成二进制。这两步分开是因为生成阶段可能依赖外部工具而编译阶段只依赖 Go 工具链。启动服务并验证# 后台启动 Ollama 服务 ./ollama serve # 探活返回版本信息说明服务在监听 curl http://localhost:11434把服务放到后台curl用来确认服务已经起来。然后拉取并运行模型# 拉取 8b 模型 ./ollama pull deepseek-r1:8b # 运行模型并进入交互模式 ./ollama run deepseek-r1:8bAndroid 路径用的是 8b 而不是 7b。8b 对内存要求更高手机能不能扛住取决于机型的 RAM 和系统对单个应用的内存限制。这条路径最现实的边界是编译能过不代表模型能加载模型能加载不代表推理速度可接受。手机上跑 8b 模型基本是在内存占用、发热和响应速度之间做平衡。另一个常被忽略的差异是架构手机大多是 ARM 架构和桌面 x86 在编译依赖、CGO 链接上并不完全一致遇到报错时先确认工具链是否匹配。3.3 编译链路拆解go generate 和 go build 在做什么go generate ./...和go build .是 Go 项目里两个不同阶段的动作。前者执行源码中//go:generate注释标记的命令用于生成代码或资源后者把包编译成二进制。把这两步分开是因为生成阶段可能依赖外部工具而编译阶段只依赖 Go 工具链。在手机端做这件事的风险在于生成阶段可能调用平台相关的工具编译阶段可能因为 CGO 或架构差异失败。常见的失败点包括缺少 C 编译器、依赖库路径不对、Go 版本不匹配。排查时应该先看go generate的输出再看go build的具体报错而不是一上来就怀疑模型本身。还有一个细节编译产出的二进制和模型文件都占用手机存储加上编译中间产物空间消耗会比预期大。部署前先确认剩余空间比编译到一半失败再回头清理要省事。4. Open WebUI 加 Docker模型服务和界面服务为什么要拆成两层4.1 容器与端口Docker 端口映射背后的网络模型Open WebUI 的部署方式是安装 Ollama、安装 Docker Desktop、安装 Open WebUI。这个顺序不是随意的。Ollama 提供模型推理服务Docker 提供隔离的运行环境Open WebUI 是浏览器端的交互界面。三者各司其职。容器有自己的网络命名空间里面的端口默认不对外暴露。要把容器里的服务暴露出来需要端口映射。Docker 的-p参数就是做这件事的-p 3000:8080表示把宿主机的 3000 端口映射到容器内的 8080 端口。映射之后访问宿主机的 3000 端口流量会被转发到容器内。这一步的常见误解是“容器里跑的服务宿主机直接就能访问”。实际上没有端口映射容器内的服务对宿主机是不可见的。端口映射本质上是在宿主机和容器之间建立一个转发规则。常见的网络模式有几种bridge 模式下容器有独立网络通过端口映射对外暴露host 模式下容器直接共享宿主机网络栈省掉映射但隔离性变弱none 模式则完全断网。部署 Open WebUI 时最常见的是 bridge 模式配合显式端口映射。理解模式差异排查“为什么端口映射了还是访问不到”时就不会乱猜。4.2 Ollama 与 Open WebUI 的对接API 端点的一致性Open WebUI 本身不跑模型它只是把用户输入转发给 Ollama。所以它需要知道 Ollama 的 API 地址。如果 Ollama 跑在宿主机上而 Open WebUI 跑在容器里容器内的localhost指的是容器自己不是宿主机。这时候需要把 Ollama 地址配置成宿主机可达的地址或者用 Docker 的网络机制让容器能访问宿主机。常见的实现思路是在启动 Open WebUI 容器时通过环境变量指定 Ollama 的地址。如果 Ollama 也在容器里可以用容器名或服务名作为地址因为 Docker 内置了 DNS 解析。这里的关键是Open WebUI 和 Ollama 之间是 HTTP API 关系只要地址对、端口通、认证通过两者就能对接。项目正文里描述的流程是打开 Docker Desktop在浏览器里看到 Ollama 的界面然后选择模型下载。这说明 Ollama 的端口已经被映射到宿主机浏览器才能访问到。换句话说界面服务和模型服务之间隔着一层网络转发任何一环配置不对表现都是“页面能开但模型用不了”。还有一个容易忽略的点是监听地址。如果 Ollama 只监听127.0.0.1那它只接受本机回环请求容器网络访问不到。需要让它监听0.0.0.0或者容器可达的地址。这个配置通常在启动参数或环境变量里改完要重启服务才生效。4.3 模型下载与存储数据卷和模型缓存的落点容器里的文件系统是临时的。容器删除后里面写入的文件也会丢失。模型文件体积大如果放在容器里每次重建容器都要重新下载这显然不合理。常见的做法是把模型缓存目录挂载成数据卷或者把 Ollama 的模型目录映射到宿主机的持久化路径。这样容器重建时模型文件仍然在宿主机上不需要重新拉取。Open WebUI 本身也有数据要持久化比如对话记录、用户配置、认证信息这些数据通常存放在容器内的数据库文件里同样需要挂载出来。部署时如果发现重启容器后对话记录没了大概率是数据卷没配对。注意Docker Desktop 在部分系统上对文件系统性能有影响模型文件体积大时挂载路径的选择会影响加载速度。把模型放在宿主机的本地磁盘上通常比放在网络挂载或虚拟文件系统上更稳。另外Docker Desktop 本身会限制容器可用的 CPU 和内存。模型加载时如果容器内存上限太低表现和宿主机本文还有配套的精品资源点击获取