简介这份15KB的docx文档面向希望在个人电脑、手机和浏览器中部署DeepSeek大模型的研究人员、开发者与技术爱好者围绕Ollama本地运行、移动端接入和Open WebUI可视化使用三条路线整理跨平台部署方案与关键操作命令。文档按macOS、Linux、Windows、iPhone与Android等环境展开包含模型拉取、终端交互、快捷指令与API Key配置、Termux依赖安装及Ollama编译启动、Docker Desktop与Open WebUI集成管理等内容并附官方网址便于核对最新版本与支持资料。包内共1个docx文件压缩包约15KB篇幅精简但覆盖本地、移动端与Web端的主要落地路径。已有3771人学习下载适合需要快速搭建DeepSeek实验环境、对照命令排查部署问题或把NLP对话能力接入个人设备与业务流程的读者参考。1. 三端并存的需求先想清楚模型到底跑在哪上周有个做后端的朋友问我能不能在那台 16G 内存的笔记本上跑一个能离线对话的模型不联网、数据不出本机。这个需求往深了说其实是一整套多平台 DeepSeek 部署方案桌面端用 Ollama 拉模型起服务手机端用 Termux 或者系统快捷指令兜底浏览器端再套一层 Open WebUI 做成团队都能点开就用的界面。三条路线的差别不在模型本身而在推理跑在哪里、请求从哪发出去。搞不清这一点你会在手机上装完一堆东西最后发现跑的其实是别人的服务器。这篇按「先选型、再跑通、最后改」的顺序把这套 AI 模型部署的落地路径拆开讲新手照着能跑熟手能看到进程边界和接口设计。2. 三条路线的架构分层与选型账本2.1 从进程边界看谁在真正做推理把三条路线摆在一起看最容易混淆的是「客户端」和「推理端」的位置。桌面方案里Ollama 是一个常驻后台的服务进程默认监听127.0.0.1:11434命令行里敲的ollama run只是一个 HTTP 客户端它把对话内容 POST 给本地服务服务加载模型权重做前向计算再返回 token。模型和算力都在你自己的机器上断网照样能用。移动端要分成两种完全不同的东西。iPhone 上的快捷指令本质是一个图形化的 HTTP 请求构造器它自己不加载任何模型权重只负责把「你说的话」打包成 JSON发到一个兼容 OpenAI 格式的远程接口上再把返回的文本念出来或显示出来。它解决的是「手机上有个顺手的入口」而不是「手机上跑推理」。Android 上的 Termux 则相反它给你一个接近 Linux 的终端环境你可以把 Ollama 源码拉下来编译成可执行文件真正在 ARM 芯片上跑推理代价是编译门槛和内存天花板。Web 端是第三种形态。Open WebUI 是一个前后端一体的应用后端用 Python 写前端是浏览器页面中间通过 HTTP 去调 Ollama 的接口。它自己也不推理价值在于多会话管理、模型切换、提示词预设、多用户登录这些产品化能力。理解了这三层的分工后面每一步命令你都知道自己在动哪一块。提示判断一个「手机跑大模型」的教程靠不靠谱就看它有没有说清楚推理发生在本地还是远端。只让你填 API Key 的都是远端。2.2 模型规格与硬件账本Ollama 的模型名带 tag冒号后面是规格比如deepseek-r1:7b里的7b指 70 亿参数量级。参数量直接决定内存占用而内存是这三条路线里最先撞墙的资源。下面这张表是我在几种设备上实测后的粗略量级具体数值会随量化方式和上下文长度浮动但用来做选型判断够用。模型规格量化后权重大致体积建议可用内存典型落地设备1.5b12 GB4 GB 以上手机 Termux、低配轻薄本7b / 8b46 GB812 GB主流笔记本、台式机14b810 GB16 GB独显机器或大内存工作站32b 及以上18 GB 起32 GB 以上服务器、多卡环境选型逻辑很简单手机端不要碰 7b 以上Android 系统对单个应用的内存限制和后台杀进程机制会让你跑到一半被 OOM 干掉桌面端 16G 内存跑 7b 是甜点区再大就要看有没有独立显卡如果是团队共用模型放在一台常开的机器上其他设备全部走 HTTP 调用这才是 AI 模型部署里最省资源的拓扑。还有一点容易被忽略上下文长度也吃内存。Ollama 默认的上下文窗口不算大如果你在 WebUI 里把上下文调到很长同样的 7b 模型内存占用可能翻倍。显存不够时它会退到 CPU 推理速度掉一个数量级这个现象后面避坑章节会专门讲。2.3 安装 Ollama 并跑通第一句回复桌面端是所有路线的基准先把它跑通后面手机和 WebUI 才有东西可连。macOS 和 Linux 用官方脚本装最省事Windows 直接下安装包双击。# macOS / Linux一行脚本完成安装会自动注册系统服务 curl -fsSL https://ollama.com/install.sh | sh # 验证安装输出类似 ollama version 0.x.x ollama --version # 拉取并进入交互式对话第一次会下载权重文件 ollama run deepseek-r1:7bollama run这个命令做了两件事先检查本地有没有对应 tag 的模型没有就自动pull下载完成后启动推理并进入 REPL。第一次执行会看到分层的下载进度条每一层是模型文件的一个分片中断了重跑会续传已经下好的层不用从头再来。装完之后要确认服务状态。Linux 下安装脚本会创建 systemd 单元用systemctl status ollama看macOS 是 launchd 托管的菜单栏应用ps aux | grep ollama能看到ollama serve进程。如果你想让局域网内其他设备也能连需要让服务监听所有网卡# 仅限可信内网使用暴露到公网等于把模型算力白送人 OLLAMA_HOST0.0.0.0:11434 ollama serve这个环境变量是很多教程漏掉的一步。默认只绑127.0.0.1你在另一台机器上curl会直接连接被拒然后误以为是防火墙问题。改完之后用curl http://主机IP:11434/api/tags验证能返回 JSON 列表说明服务通了。这一步跑通桌面端的基础就打好了接下来两条路都是在它的接口之上做文章。3. 移动端落地iPhone 快捷指令与 Android Termux 编译3.1 iPhone 快捷指令把 HTTP 请求包成系统级入口捷径Shortcuts这个路子被很多教程写得很玄其实拆开就三个动作接收输入、发请求、展示结果。你在 Safari 里导入一个现成的快捷指令它内部是一个「获取 URL 内容」动作方法选 POST请求体是一段 JSON结构跟 OpenAI 的 Chat Completions 接口一致。{ model: deepseek-chat, messages: [ {role: system, content: 你是一个简洁的中文助手}, {role: user, content: 把这段话翻译成英文} ], temperature: 0.7, stream: false }model字段决定服务端用哪个模型messages是标准的多轮对话数组stream设成false是为了让快捷指令一次性拿到完整文本因为流式返回在捷径里处理起来很别扭。请求头里必须带Authorization: Bearer 你的Key和Content-Type: application/json少一个就是 401 或 415。这里要说清楚一件事快捷指令的便利性建立在「远端有服务」的前提上它跟本地部署是两条路。如果你确实需要离线就别在 iPhone 上折腾这条路直接把模型跑在桌面机上手机通过局域网访问那个 11434 端口虽然要保证同一网段但数据不出内网。注意API Key 写死在快捷指令里任何拿到你手机或者你分享出去的快捷指令的人都能直接看到明文。别用主账号的 Key单独申请一个限额的子 Key用完随时吊销。首次运行时系统会弹权限确认问你是否允许访问某个域名必须点允许否则请求会被静默拦截表现就是「点了没反应」。这个交互坑我在第一次配的时候卡了十几分钟最后是靠捷径的「显示结果」动作把错误码打出来才定位到的。建议你在调试阶段加一个显示返回内容的动作把 HTTP 状态码一起打出来。3.2 Android Termux从装依赖到编译出可执行文件Termux 是 Android 上最接近 Linux 的环境它不走 proot 那一套虚拟化而是直接跑在 Android 的 Linux 内核上所以编译出来的二进制能原生执行。整套流程分三步配环境、拉源码、编译。# 1. 更新包管理器并装编译工具链 pkg update pkg upgrade -y pkg install git cmake golang libjpeg-turbo -y # 2. 申请共享存储权限方便把模型文件放外置卡 termux-setup-storage # 3. 拉 Ollama 源码depth 1 只取最新一次提交省流量省时间 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # 4. 生成版本信息文件再编译出单文件二进制 go generate ./... go build .go generate这一步不能省它会跑//go:generate注释标记的脚本把版本号、构建时间之类的信息注入到源码里跳过它编译出来的程序在--version时会显示 dev 或者干脆报错。go build .在当前目录产出名为ollama的可执行文件第一次编译在手机上大概十几到三十分钟取决于芯片性能中途锁屏可能被系统挂起建议先执行termux-wake-lock拿一个唤醒锁。依赖里libjpeg-turbo容易被漏掉它是图像处理相关的库Ollama 的多模态能力会用到。缺了它编译过程不一定立刻报错但运行时加载模型可能崩这种延迟暴露的问题最难查。装依赖时留意终端有没有红色的E:开头错误有的话先解决依赖再往下走。3.3 启动服务与模型拉取验证编译完成后不要急着run先把服务单独起起来验证端口。# 后台启动服务 让它脱离当前终端 ./ollama serve # 验证服务是否在监听正常返回版本信息的 JSON curl http://127.0.0.1:11434 # 手机内存有限先拉最小规格的模型试水 ./ollama pull deepseek-r1:1.5b # 跑起来对话 ./ollama run deepseek-r1:1.5bcurl这一步是整个移动端部署里最重要的验证点。返回Ollama is running或者一段版本 JSON说明服务活着后面拉模型失败就只可能是网络或磁盘问题如果 curl 直接连接失败那就别往下走先看serve进程是不是被系统杀了。Android 的后台管理很激进切到别的应用几分钟Termux 的进程就可能被回收表现是「刚才还能用现在连不上」。长期使用的话在系统设置里给 Termux 加电池优化白名单。模型规格上老老实实选 1.5b。7b 在旗舰机上勉强能加载但一旦上下文变长就会触发内存回收回应到一半断掉这个体验比慢更糟。真要在手机上用大模型正确姿势是手机当客户端桌面机当推理端中间走局域网。4. Open WebUI 与 Docker浏览器里的模型工作台4.1 容器网络两个服务怎么互相看见Open WebUI 官方推荐用 Docker 跑因为它的依赖链比较长直接装 Python 环境容易和系统包打架。容器化之后有个关键问题WebUI 容器怎么访问 Ollama。有两条路。第一条是 Ollama 跑在宿主机上容器通过特殊域名回连宿主机。macOS 和 Windows 的 Docker Desktop 提供host.docker.internalLinux 上要用宿主机的实际内网 IP 或者172.17.0.1这个网桥地址。第二条是两个都放容器里用 Docker 的自定义网络让它们通过服务名互访这种方式最干净也方便整体迁移。services: ollama: image: ollama/ollama:latest ports: - 11434:11434 volumes: - ollama:/root/.ollama # 模型权重持久化删容器不丢模型 open-webui: image: ghcr.io/open-webui/open-webui:main ports: - 3000:8080 # 左边是宿主机端口右边是容器内端口 environment: - OLLAMA_BASE_URLhttp://ollama:11434 volumes: - open-webui:/app/backend/data # 会话记录、用户、配置都在这里 depends_on: - ollama volumes: ollama: open-webui:OLLAMA_BASE_URL里写的是服务名ollama这是 Docker 内置 DNS 解析的结果两个容器必须处在同一个 compose 网络里才生效。你要是把它改成localhost:11434容器里的 localhost 指的是容器自己会一直连不上这是最高频的翻车点。端口映射3000:8080里的 8080 是 WebUI 容器内监听的真实端口改成别的宿主机端口不影响容器内部。depends_on只保证启动顺序不保证 Ollama 已经准备好接受请求所以第一次打开页面时如果模型列表是空的等十几秒刷新一下就好不是配置错了。4.2 启动、初始化与模型拉取# 在 compose 文件所在目录执行-d 后台运行 docker compose up -d # 看两个容器的状态都应该是 running docker compose ps # 如果模型列表为空进容器手动拉一个 docker compose exec ollama ollama pull deepseek-r1:7b首次访问http://localhost:3000会引导你创建管理员账号账号信息存在/app/backend/data下的 SQLite 里所以这个目录必须挂卷否则重建容器就全丢了。登录之后进「设置 → 模型」能看到 Ollama 里已有的模型列表也可以直接在界面上填模型名拉取效果等同于命令行ollama pull。在界面里点「新建对话」选模型发一句话测试。如果转圈很久最后报连接错误八成是OLLAMA_BASE_URL配错了用docker compose logs open-webui看日志里那一行实际请求的地址。如果报模型不存在就是拉取没完成或者 tag 拼错注意deepseek-r1和deepseek-r1:7b是两个不同的引用前者会拉默认 tag。5. 避坑与排查五个真实翻车现场5.1 现象局域网设备连不上 11434宿主机自己能通原因Ollama 默认只绑127.0.0.1这是出于安全考虑的设计不是 bug。很多人以为装完就能被外部访问结果在另一台机器上 curl 一直是 connection refused转而去查防火墙白折腾。解决用OLLAMA_HOST0.0.0.0:11434重启服务。Linux 下如果是 systemd 托管的要改 unit 文件里的Environment再systemctl daemon-reload直接在 shell 里 export 对已经跑起来的服务无效。改完记得确认这台机器的 11434 没有暴露到公网Ollama 本身没有鉴权。5.2 现象容器里 WebUI 一直提示连不上模型服务原因OLLAMA_BASE_URL写成了localhost或127.0.0.1。容器有自己的网络命名空间localhost 指向容器自身而 Ollama 根本没跑在这个容器里。解决两个服务在同一 compose 网络时用服务名Ollama 在宿主机时macOS/Windows 用host.docker.internalLinux 用宿主机的内网 IP。改完docker compose up -d重建容器才生效只改 yml 不重启是没用的。5.3 现象Termux 里go build报错提示找不到某个 C 库原因Ollama 的部分依赖用到了 CGO需要系统里有对应的开发库。只装了 golang 没装cmake和libjpeg-turbo编译到链接阶段就断。解决pkg install cmake libjpeg-turbo -y补齐如果还报错看错误信息里cannot find -lxxx的库名pkg search xxx找对应的包。别去网上抄别人的完整依赖列表Termux 的包名和标准 Linux 发行版不一样抄错了会装一堆用不上的东西。5.4 现象模型拉到 90% 卡住或者报校验失败原因权重文件按层分片下载网络抖动会让某一层中断。Ollama 有续传机制但磁盘空间不足时它会先写后失败表现就是进度条卡死。解决先df -h看剩余空间7b 模型至少要留 10 GB 余量。空间够的话 CtrlC 中断重跑ollama pull已完成的层不会重下。反复失败就换ollama run直接触发拉取有时比单独 pull 的容错好一些。5.5 现象手机端请求返回 401 或 403原因Key 失效、额度耗尽或者请求头里的Authorization格式不对。Bearer 后面必须有一个空格少这个空格服务端解析不到 token。解决先用 curl 在电脑上直接打那个接口把请求头和请求体都带上确认 Key 本身有效。电脑能通手机不通问题就在快捷指令的变量替换上检查 Key 是不是被当成文本而不是变量填进了请求头。6. 二次开发把模型能力接进自己的业务逻辑跑通之后真正有价值的部分才开始。Ollama 暴露的/api/chat接口是最好用的接入点它跟 OpenAI 的格式基本兼容你原有的 NLP 应用代码几乎不用改只换 base_url 和模型名。import requests, json def chat(messages, modeldeepseek-r1:7b, hosthttp://127.0.0.1:11434): resp requests.post( f{host}/api/chat, json{ model: model, messages: messages, stream: False, # 关掉流式方便一次性拿完整结果 options: {temperature: 0.3, num_ctx: 4096} # 上下文别开太大吃内存 }, timeout120 # 本地推理慢超时要给足 ) resp.raise_for_status() return resp.json()[message][content] print(chat([{role: user, content: 用三句话说明什么是向量检索}]))options里的num_ctx是最值得调的参数它决定模型能看多长的上下文。默认值通常够用调大到 8192 以上会显著增加内存占用7b 模型在 16G 机器上很容易因此退到 CPU 推理。temperature做分类、抽取这类任务时压到 0.10.3 更稳做创意生成再拉到 0.8。改造时我一般会包一层自己的服务把模型调用、超时重试、日志记录收在一处业务代码只依赖这个包装层。好处是换模型只改一个地方而且能做降级大模型超时就切到 1.5b 的小模型先返回用户体验比直接报错好得多。验证方法很朴素写个脚本连续打 20 次接口记录 P95 延迟和失败率再把num_ctx和模型规格分别调一档对比数据会告诉你这台机器适合跑多大的模型。WebUI 那一层也有改造空间它自带 OpenAI 兼容的/api/v1/chat/completions意味着任何支持自定义 base_url 的第三方工具都能接进来。我在一个内部工具里就是这么做的前端不动后端把 base_url 从云端服务改成局域网地址数据不出内网这件事就自然满足了。踩过最疼的一次是没做超时控制一个批量任务把模型服务打满后面所有请求排队前端全部转圈看起来像服务挂了。从那以后我每次接模型接口都强制走一遍「单请求 → 压测 → 加超时和降级」这三步不管多急都不跳。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek多端部署：Ollama、Termux与Open WebUI实践
简介这份15KB的docx文档面向希望在个人电脑、手机和浏览器中部署DeepSeek大模型的研究人员、开发者与技术爱好者围绕Ollama本地运行、移动端接入和Open WebUI可视化使用三条路线整理跨平台部署方案与关键操作命令。文档按macOS、Linux、Windows、iPhone与Android等环境展开包含模型拉取、终端交互、快捷指令与API Key配置、Termux依赖安装及Ollama编译启动、Docker Desktop与Open WebUI集成管理等内容并附官方网址便于核对最新版本与支持资料。包内共1个docx文件压缩包约15KB篇幅精简但覆盖本地、移动端与Web端的主要落地路径。已有3771人学习下载适合需要快速搭建DeepSeek实验环境、对照命令排查部署问题或把NLP对话能力接入个人设备与业务流程的读者参考。1. 三端并存的需求先想清楚模型到底跑在哪上周有个做后端的朋友问我能不能在那台 16G 内存的笔记本上跑一个能离线对话的模型不联网、数据不出本机。这个需求往深了说其实是一整套多平台 DeepSeek 部署方案桌面端用 Ollama 拉模型起服务手机端用 Termux 或者系统快捷指令兜底浏览器端再套一层 Open WebUI 做成团队都能点开就用的界面。三条路线的差别不在模型本身而在推理跑在哪里、请求从哪发出去。搞不清这一点你会在手机上装完一堆东西最后发现跑的其实是别人的服务器。这篇按「先选型、再跑通、最后改」的顺序把这套 AI 模型部署的落地路径拆开讲新手照着能跑熟手能看到进程边界和接口设计。2. 三条路线的架构分层与选型账本2.1 从进程边界看谁在真正做推理把三条路线摆在一起看最容易混淆的是「客户端」和「推理端」的位置。桌面方案里Ollama 是一个常驻后台的服务进程默认监听127.0.0.1:11434命令行里敲的ollama run只是一个 HTTP 客户端它把对话内容 POST 给本地服务服务加载模型权重做前向计算再返回 token。模型和算力都在你自己的机器上断网照样能用。移动端要分成两种完全不同的东西。iPhone 上的快捷指令本质是一个图形化的 HTTP 请求构造器它自己不加载任何模型权重只负责把「你说的话」打包成 JSON发到一个兼容 OpenAI 格式的远程接口上再把返回的文本念出来或显示出来。它解决的是「手机上有个顺手的入口」而不是「手机上跑推理」。Android 上的 Termux 则相反它给你一个接近 Linux 的终端环境你可以把 Ollama 源码拉下来编译成可执行文件真正在 ARM 芯片上跑推理代价是编译门槛和内存天花板。Web 端是第三种形态。Open WebUI 是一个前后端一体的应用后端用 Python 写前端是浏览器页面中间通过 HTTP 去调 Ollama 的接口。它自己也不推理价值在于多会话管理、模型切换、提示词预设、多用户登录这些产品化能力。理解了这三层的分工后面每一步命令你都知道自己在动哪一块。提示判断一个「手机跑大模型」的教程靠不靠谱就看它有没有说清楚推理发生在本地还是远端。只让你填 API Key 的都是远端。2.2 模型规格与硬件账本Ollama 的模型名带 tag冒号后面是规格比如deepseek-r1:7b里的7b指 70 亿参数量级。参数量直接决定内存占用而内存是这三条路线里最先撞墙的资源。下面这张表是我在几种设备上实测后的粗略量级具体数值会随量化方式和上下文长度浮动但用来做选型判断够用。模型规格量化后权重大致体积建议可用内存典型落地设备1.5b12 GB4 GB 以上手机 Termux、低配轻薄本7b / 8b46 GB812 GB主流笔记本、台式机14b810 GB16 GB独显机器或大内存工作站32b 及以上18 GB 起32 GB 以上服务器、多卡环境选型逻辑很简单手机端不要碰 7b 以上Android 系统对单个应用的内存限制和后台杀进程机制会让你跑到一半被 OOM 干掉桌面端 16G 内存跑 7b 是甜点区再大就要看有没有独立显卡如果是团队共用模型放在一台常开的机器上其他设备全部走 HTTP 调用这才是 AI 模型部署里最省资源的拓扑。还有一点容易被忽略上下文长度也吃内存。Ollama 默认的上下文窗口不算大如果你在 WebUI 里把上下文调到很长同样的 7b 模型内存占用可能翻倍。显存不够时它会退到 CPU 推理速度掉一个数量级这个现象后面避坑章节会专门讲。2.3 安装 Ollama 并跑通第一句回复桌面端是所有路线的基准先把它跑通后面手机和 WebUI 才有东西可连。macOS 和 Linux 用官方脚本装最省事Windows 直接下安装包双击。# macOS / Linux一行脚本完成安装会自动注册系统服务 curl -fsSL https://ollama.com/install.sh | sh # 验证安装输出类似 ollama version 0.x.x ollama --version # 拉取并进入交互式对话第一次会下载权重文件 ollama run deepseek-r1:7bollama run这个命令做了两件事先检查本地有没有对应 tag 的模型没有就自动pull下载完成后启动推理并进入 REPL。第一次执行会看到分层的下载进度条每一层是模型文件的一个分片中断了重跑会续传已经下好的层不用从头再来。装完之后要确认服务状态。Linux 下安装脚本会创建 systemd 单元用systemctl status ollama看macOS 是 launchd 托管的菜单栏应用ps aux | grep ollama能看到ollama serve进程。如果你想让局域网内其他设备也能连需要让服务监听所有网卡# 仅限可信内网使用暴露到公网等于把模型算力白送人 OLLAMA_HOST0.0.0.0:11434 ollama serve这个环境变量是很多教程漏掉的一步。默认只绑127.0.0.1你在另一台机器上curl会直接连接被拒然后误以为是防火墙问题。改完之后用curl http://主机IP:11434/api/tags验证能返回 JSON 列表说明服务通了。这一步跑通桌面端的基础就打好了接下来两条路都是在它的接口之上做文章。3. 移动端落地iPhone 快捷指令与 Android Termux 编译3.1 iPhone 快捷指令把 HTTP 请求包成系统级入口捷径Shortcuts这个路子被很多教程写得很玄其实拆开就三个动作接收输入、发请求、展示结果。你在 Safari 里导入一个现成的快捷指令它内部是一个「获取 URL 内容」动作方法选 POST请求体是一段 JSON结构跟 OpenAI 的 Chat Completions 接口一致。{ model: deepseek-chat, messages: [ {role: system, content: 你是一个简洁的中文助手}, {role: user, content: 把这段话翻译成英文} ], temperature: 0.7, stream: false }model字段决定服务端用哪个模型messages是标准的多轮对话数组stream设成false是为了让快捷指令一次性拿到完整文本因为流式返回在捷径里处理起来很别扭。请求头里必须带Authorization: Bearer 你的Key和Content-Type: application/json少一个就是 401 或 415。这里要说清楚一件事快捷指令的便利性建立在「远端有服务」的前提上它跟本地部署是两条路。如果你确实需要离线就别在 iPhone 上折腾这条路直接把模型跑在桌面机上手机通过局域网访问那个 11434 端口虽然要保证同一网段但数据不出内网。注意API Key 写死在快捷指令里任何拿到你手机或者你分享出去的快捷指令的人都能直接看到明文。别用主账号的 Key单独申请一个限额的子 Key用完随时吊销。首次运行时系统会弹权限确认问你是否允许访问某个域名必须点允许否则请求会被静默拦截表现就是「点了没反应」。这个交互坑我在第一次配的时候卡了十几分钟最后是靠捷径的「显示结果」动作把错误码打出来才定位到的。建议你在调试阶段加一个显示返回内容的动作把 HTTP 状态码一起打出来。3.2 Android Termux从装依赖到编译出可执行文件Termux 是 Android 上最接近 Linux 的环境它不走 proot 那一套虚拟化而是直接跑在 Android 的 Linux 内核上所以编译出来的二进制能原生执行。整套流程分三步配环境、拉源码、编译。# 1. 更新包管理器并装编译工具链 pkg update pkg upgrade -y pkg install git cmake golang libjpeg-turbo -y # 2. 申请共享存储权限方便把模型文件放外置卡 termux-setup-storage # 3. 拉 Ollama 源码depth 1 只取最新一次提交省流量省时间 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # 4. 生成版本信息文件再编译出单文件二进制 go generate ./... go build .go generate这一步不能省它会跑//go:generate注释标记的脚本把版本号、构建时间之类的信息注入到源码里跳过它编译出来的程序在--version时会显示 dev 或者干脆报错。go build .在当前目录产出名为ollama的可执行文件第一次编译在手机上大概十几到三十分钟取决于芯片性能中途锁屏可能被系统挂起建议先执行termux-wake-lock拿一个唤醒锁。依赖里libjpeg-turbo容易被漏掉它是图像处理相关的库Ollama 的多模态能力会用到。缺了它编译过程不一定立刻报错但运行时加载模型可能崩这种延迟暴露的问题最难查。装依赖时留意终端有没有红色的E:开头错误有的话先解决依赖再往下走。3.3 启动服务与模型拉取验证编译完成后不要急着run先把服务单独起起来验证端口。# 后台启动服务 让它脱离当前终端 ./ollama serve # 验证服务是否在监听正常返回版本信息的 JSON curl http://127.0.0.1:11434 # 手机内存有限先拉最小规格的模型试水 ./ollama pull deepseek-r1:1.5b # 跑起来对话 ./ollama run deepseek-r1:1.5bcurl这一步是整个移动端部署里最重要的验证点。返回Ollama is running或者一段版本 JSON说明服务活着后面拉模型失败就只可能是网络或磁盘问题如果 curl 直接连接失败那就别往下走先看serve进程是不是被系统杀了。Android 的后台管理很激进切到别的应用几分钟Termux 的进程就可能被回收表现是「刚才还能用现在连不上」。长期使用的话在系统设置里给 Termux 加电池优化白名单。模型规格上老老实实选 1.5b。7b 在旗舰机上勉强能加载但一旦上下文变长就会触发内存回收回应到一半断掉这个体验比慢更糟。真要在手机上用大模型正确姿势是手机当客户端桌面机当推理端中间走局域网。4. Open WebUI 与 Docker浏览器里的模型工作台4.1 容器网络两个服务怎么互相看见Open WebUI 官方推荐用 Docker 跑因为它的依赖链比较长直接装 Python 环境容易和系统包打架。容器化之后有个关键问题WebUI 容器怎么访问 Ollama。有两条路。第一条是 Ollama 跑在宿主机上容器通过特殊域名回连宿主机。macOS 和 Windows 的 Docker Desktop 提供host.docker.internalLinux 上要用宿主机的实际内网 IP 或者172.17.0.1这个网桥地址。第二条是两个都放容器里用 Docker 的自定义网络让它们通过服务名互访这种方式最干净也方便整体迁移。services: ollama: image: ollama/ollama:latest ports: - 11434:11434 volumes: - ollama:/root/.ollama # 模型权重持久化删容器不丢模型 open-webui: image: ghcr.io/open-webui/open-webui:main ports: - 3000:8080 # 左边是宿主机端口右边是容器内端口 environment: - OLLAMA_BASE_URLhttp://ollama:11434 volumes: - open-webui:/app/backend/data # 会话记录、用户、配置都在这里 depends_on: - ollama volumes: ollama: open-webui:OLLAMA_BASE_URL里写的是服务名ollama这是 Docker 内置 DNS 解析的结果两个容器必须处在同一个 compose 网络里才生效。你要是把它改成localhost:11434容器里的 localhost 指的是容器自己会一直连不上这是最高频的翻车点。端口映射3000:8080里的 8080 是 WebUI 容器内监听的真实端口改成别的宿主机端口不影响容器内部。depends_on只保证启动顺序不保证 Ollama 已经准备好接受请求所以第一次打开页面时如果模型列表是空的等十几秒刷新一下就好不是配置错了。4.2 启动、初始化与模型拉取# 在 compose 文件所在目录执行-d 后台运行 docker compose up -d # 看两个容器的状态都应该是 running docker compose ps # 如果模型列表为空进容器手动拉一个 docker compose exec ollama ollama pull deepseek-r1:7b首次访问http://localhost:3000会引导你创建管理员账号账号信息存在/app/backend/data下的 SQLite 里所以这个目录必须挂卷否则重建容器就全丢了。登录之后进「设置 → 模型」能看到 Ollama 里已有的模型列表也可以直接在界面上填模型名拉取效果等同于命令行ollama pull。在界面里点「新建对话」选模型发一句话测试。如果转圈很久最后报连接错误八成是OLLAMA_BASE_URL配错了用docker compose logs open-webui看日志里那一行实际请求的地址。如果报模型不存在就是拉取没完成或者 tag 拼错注意deepseek-r1和deepseek-r1:7b是两个不同的引用前者会拉默认 tag。5. 避坑与排查五个真实翻车现场5.1 现象局域网设备连不上 11434宿主机自己能通原因Ollama 默认只绑127.0.0.1这是出于安全考虑的设计不是 bug。很多人以为装完就能被外部访问结果在另一台机器上 curl 一直是 connection refused转而去查防火墙白折腾。解决用OLLAMA_HOST0.0.0.0:11434重启服务。Linux 下如果是 systemd 托管的要改 unit 文件里的Environment再systemctl daemon-reload直接在 shell 里 export 对已经跑起来的服务无效。改完记得确认这台机器的 11434 没有暴露到公网Ollama 本身没有鉴权。5.2 现象容器里 WebUI 一直提示连不上模型服务原因OLLAMA_BASE_URL写成了localhost或127.0.0.1。容器有自己的网络命名空间localhost 指向容器自身而 Ollama 根本没跑在这个容器里。解决两个服务在同一 compose 网络时用服务名Ollama 在宿主机时macOS/Windows 用host.docker.internalLinux 用宿主机的内网 IP。改完docker compose up -d重建容器才生效只改 yml 不重启是没用的。5.3 现象Termux 里go build报错提示找不到某个 C 库原因Ollama 的部分依赖用到了 CGO需要系统里有对应的开发库。只装了 golang 没装cmake和libjpeg-turbo编译到链接阶段就断。解决pkg install cmake libjpeg-turbo -y补齐如果还报错看错误信息里cannot find -lxxx的库名pkg search xxx找对应的包。别去网上抄别人的完整依赖列表Termux 的包名和标准 Linux 发行版不一样抄错了会装一堆用不上的东西。5.4 现象模型拉到 90% 卡住或者报校验失败原因权重文件按层分片下载网络抖动会让某一层中断。Ollama 有续传机制但磁盘空间不足时它会先写后失败表现就是进度条卡死。解决先df -h看剩余空间7b 模型至少要留 10 GB 余量。空间够的话 CtrlC 中断重跑ollama pull已完成的层不会重下。反复失败就换ollama run直接触发拉取有时比单独 pull 的容错好一些。5.5 现象手机端请求返回 401 或 403原因Key 失效、额度耗尽或者请求头里的Authorization格式不对。Bearer 后面必须有一个空格少这个空格服务端解析不到 token。解决先用 curl 在电脑上直接打那个接口把请求头和请求体都带上确认 Key 本身有效。电脑能通手机不通问题就在快捷指令的变量替换上检查 Key 是不是被当成文本而不是变量填进了请求头。6. 二次开发把模型能力接进自己的业务逻辑跑通之后真正有价值的部分才开始。Ollama 暴露的/api/chat接口是最好用的接入点它跟 OpenAI 的格式基本兼容你原有的 NLP 应用代码几乎不用改只换 base_url 和模型名。import requests, json def chat(messages, modeldeepseek-r1:7b, hosthttp://127.0.0.1:11434): resp requests.post( f{host}/api/chat, json{ model: model, messages: messages, stream: False, # 关掉流式方便一次性拿完整结果 options: {temperature: 0.3, num_ctx: 4096} # 上下文别开太大吃内存 }, timeout120 # 本地推理慢超时要给足 ) resp.raise_for_status() return resp.json()[message][content] print(chat([{role: user, content: 用三句话说明什么是向量检索}]))options里的num_ctx是最值得调的参数它决定模型能看多长的上下文。默认值通常够用调大到 8192 以上会显著增加内存占用7b 模型在 16G 机器上很容易因此退到 CPU 推理。temperature做分类、抽取这类任务时压到 0.10.3 更稳做创意生成再拉到 0.8。改造时我一般会包一层自己的服务把模型调用、超时重试、日志记录收在一处业务代码只依赖这个包装层。好处是换模型只改一个地方而且能做降级大模型超时就切到 1.5b 的小模型先返回用户体验比直接报错好得多。验证方法很朴素写个脚本连续打 20 次接口记录 P95 延迟和失败率再把num_ctx和模型规格分别调一档对比数据会告诉你这台机器适合跑多大的模型。WebUI 那一层也有改造空间它自带 OpenAI 兼容的/api/v1/chat/completions意味着任何支持自定义 base_url 的第三方工具都能接进来。我在一个内部工具里就是这么做的前端不动后端把 base_url 从云端服务改成局域网地址数据不出内网这件事就自然满足了。踩过最疼的一次是没做超时控制一个批量任务把模型服务打满后面所有请求排队前端全部转圈看起来像服务挂了。从那以后我每次接模型接口都强制走一遍「单请求 → 压测 → 加超时和降级」这三步不管多急都不跳。希望帮到你。本文还有配套的精品资源点击获取