简介这份指南围绕 DeepSeek 的多平台部署展开面向希望将大模型落地到实际环境的开发人员与技术爱好者覆盖机器学习、深度学习与自然语言处理场景下的模型部署需求。内容以单份 docx 文档交付压缩包约 15KB共 1 个文件便于快速查阅和按需检索。现有 1521 人学习说明其在 AI 工具实践群体中具备一定参考价值。文档按平台组织操作路径本地环境先安装 Ollama 并拉取运行 DeepSeek 模型iPhone 通过快捷指令配合 API Key 完成调用Android 借助 Termux 配置依赖、编译并启动 Ollama 服务Open WebUI 方案则结合 Docker 与 Ollama 搭建可视化交互界面。各环节给出明确命令、配置顺序与验证方式并提示可能遇到的问题及处理思路适合初学者按步骤实践也方便有经验的开发者快速比较不同部署方案的适用条件为个人研究或业务集成提供可操作的参考。1. 一条命令背后模型文件之外还藏着什么大多数人第一次执行ollama run deepseek-r1:7b时会以为自己在“下载一个模型”。实际下载的只是几 GB 字节流真正的重头戏在之后这些字节要先被 mmap 映射进虚拟内存再由推理引擎按层做矩阵乘最后由一个常驻进程把生成结果切成 token 流式吐回终端。模型部署的难点从来不在“拿到文件”而在权重的数值格式、内核能不能吃满你手里那块芯片、以及服务层怎么把一次对话拆成可中断的请求。把这三层拆开看你才会明白为什么同一个模型在笔记本上秒回、在手机上卡成幻灯片、在容器里又连不上——这些现象背后是同一套机制在不同约束下的表现。2. 权重格式与推理引擎Ollama 凭什么用一行命令跑起 7B 模型2.1 GGUF 与量化14GB 的权重是怎么缩到 4GB 的先把账算清楚。一个 7B 参数的模型如果每个权重用 fp162 字节存光权重就是 7×10⁹×2 ≈ 14GB。这个体积对消费级设备是致命的16GB 内存的笔记本装得下但没法留出 KV cache 的空间手机更是直接出局。所以任何能在本地跑的模型第一步都是量化——把浮点权重压成低比特整数。量化的原理不复杂但细节决定了画质。最朴素的做法是整层共用一个 scalew_int round(w / scale)反量化时再乘回去。问题是一层里权重的动态范围可能差好几个数量级全局 scale 会被少数大权重绑架小权重全被压成 0模型直接“变傻”。所以工业实现普遍走分块量化把连续的 256 个权重划成一个 super-block块内单独算 scale 和 min块与块之间互不干扰。Q4_K_M 这类名字里的K指的就是这套 k-quant 分块方案M表示中等粒度混合——部分关键张量比如 attention 的 value 投影用更高比特其余用 4 bit。常见的实现思路大致是这样一个 Q4_K 的 super-block 存 256 个 4 bit 权重128 字节外加 6 bit 的 scale 和 6 bit 的 min摊下来约 4.5 bit/权重。7B 参数乘 4.5 bit 约 3.9GB再加上不参与量化的 embedding 和输出层最终落在 4.4GB 上下。量化类型每权重比特7B 模型体积质量损失主观F1616~14GB无基准Q8_08.5~7.2GB几乎不可感知Q5_K_M5.7~5.1GB轻微长文推理略降Q4_K_M4.8~4.4GB可接受日常问答无感Q4_04.5~3.9GB明显代码与数学题掉点Q2_K2.6~2.7GB严重不建议生产用选哪一档不是玄学是内存预算倒推出来的模型体积 KV cache 必须小于可用内存的 70% 左右否则系统会在你聊到第三轮时把进程杀掉。GGUF 这个容器格式的设计动机也在这儿。它是一个单文件自描述格式文件头写明版本和 tensor 数量紧跟一段 key-value 元数据架构名、层数、head 数、上下文长度、tokenizer 词表然后是每个 tensor 的名字、维度、类型、偏移量最后才是连续排布的权重数据。这样做的直接好处是可以 mmap——推理时不需要把 4GB 一次性读进 RAM而是把文件映射到虚拟地址空间用到哪一页就缺页加载哪一页。这就是为什么ollama run看起来“秒启动”它只是打开了文件真正耗时的是首次推理时把权重页逐块换入。2.2 内容寻址存储磁盘上的模型其实是 manifest 加一堆 blob如果你去翻 Ollama 的数据目录会发现里面没有deepseek-r1-7b.gguf这种直白命名的文件而是一堆以sha256-开头的无后缀文件。这不是设计得晦涩是在抄容器镜像那套内容寻址存储CAS文件名就是内容的哈希内容变一个字节名字就变。# Linux/macOS 下的默认位置Windows 在 %USERPROFILE%\.ollama\models tree -L 3 ~/.ollama/models # ├── blobs/ # │ ├── sha256-3f9a... # 模型权重层最大的那个 # │ ├── sha256-8c21... # 模板与参数配置层 # │ └── sha256-a04e... # 许可证/说明等小层 # └── manifests/ # └── registry.ollama.ai/library/deepseek-r1/7b # 一个 JSON 清单manifest 的结构和 OCI 镜像清单几乎同构{ schemaVersion: 2, mediaType: application/vnd.docker.distribution.manifest.v2json, config: { mediaType: application/vnd.docker.container.image.v1json, digest: sha256:8c21..., size: 4821 }, layers: [ { mediaType: application/vnd.ollama.image.model, digest: sha256:3f9a..., size: 4401234567 } ] }config指向的那个小 blob 里存的是模板chat template、默认参数temperature、stop 序列和系统提示。layers里的 model 层才是 GGUF 数据。这样拆的好处是层可复用同一个底座的不同微调版本如果 tokenizer 和模板没变共享同一份小层甚至不同 tag 如果指向同一个权重 blobollama pull会直接跳过下载。这也是为什么你拉第二个相近模型时速度会快得让人怀疑它没下载完。ollama create加 Modelfile 的玩法就建立在这套结构上# Modelfile 里的 FROM 可以指向已有模型PARAMETER 会写进新的 config 层 cat Modelfile EOF FROM deepseek-r1:7b PARAMETER temperature 0.6 PARAMETER num_ctx 8192 SYSTEM 你是一个只讲实现细节的工程师 EOF ollama create my-r1 -f Modelfile这里的关键是新模型不会复制 4.4GB 权重它只是生成一份新 manifest权重层仍然指向原来那个 blob 的哈希。改温度、改系统提示这种操作磁盘成本接近零。理解了这一点你就不会在磁盘快满时去删blobs里的“重复文件”——按哈希命名意味着物理上根本不存在重复。2.3 从 HTTP 到 token一次 /api/chat 请求在 11434 端口里走了什么ollama run只是个 CLI 壳子真正干活的是一个常驻的 HTTP 服务默认监听127.0.0.1:11434。你可以直接拿 curl 打它看到的东西比 CLI 更接近本质curl http://localhost:11434/api/chat -d { model: deepseek-r1:7b, messages: [ {role: user, content: 用一句话说清楚 KV cache 的作用} ], stream: true, options: {num_ctx: 4096, temperature: 0.6} }响应不是一段完整 JSON而是一串换行分隔的 JSON 对象NDJSON每行带一个message.content片段最后一行done: true并附上统计字段{model:deepseek-r1:7b,message:{role:assistant,content:KV},done:false} {model:deepseek-r1:7b,message:{role:assistant,content: cache},done:false} {model:deepseek-r1:7b,done:true,total_duration:8123456789,eval_count:37,eval_duration:5210000000}eval_count / eval_duration就是常说的 token/s这是判断“跑得动跑不动”最硬的指标比任何主观感受都可靠。一次请求在服务内部的路径大致是五步。第一步HTTP 层解析请求体校验模型名是否已在本地 manifest 里注册没注册就直接返回 404不会偷偷去下载。第二步进入调度器它检查目标模型是否已经加载已加载就看keep_alive有没有过期默认 5 分钟过期就等待回收未加载则拉起一个runner 子进程。第三步runner 进程把 GGUF 映射进内存按num_ctx预分配 KV cache然后开始 prefill——把整段 prompt 一次性过一遍前向填满 KV cache。第四步逐 token 解码每生成一个就通过管道回传给主进程。第五步主进程把它包装成 NDJSON 写回 HTTP 响应体。这里有两个容易被忽略的机制。其一runner 是独立进程而非线程模型加载失败、显存不足、推理崩溃都只会杀掉 runner主服务还活着所以你能看到ollama ps里模型状态变了但 API 仍在响应。其二KV cache 是预分配的num_ctx8192意味着即使你只问了一句“你好”也有一块对应 8192 token 的缓存被占住。粗略估算32 层、8 个 KV head、head_dim 128、fp16 存 K 和 V8192 token 下约 2×32×8×128×8192×2 byte ≈ 1GB。这个数字直接解释了后面所有的“内存不够”问题——模型 4.4GB 只是入场券KV cache 才是隐形开销。提示OLLAMA_KEEP_ALIVE、OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS这三个环境变量决定了调度器行为。并行数每加一KV cache 就翻一倍笔记本上把它设成 4 是自找麻烦。3. 手机端的两条岔路iPhone 为什么只发请求Android 却要自己编译3.1 快捷指令的本质一个跑在系统里的 HTTP 客户端iPhone 那条路线看起来最“不像部署”安装一个快捷指令填入 API Key就能对话。很多人以为这是某种黑科技其实拆开看快捷指令就是一个plist 描述的动作序列里面的核心动作叫“获取 URL 内容”支持指定 method、headers 和 request body。换句话说它做的就是把你的输入拼成一个 JSONPOST 出去再把返回的 JSON 解析出文本显示出来。请求体长这样和你在电脑上 curl 的东西一模一样{ model: deepseek-r1, messages: [ {role: system, content: 回答尽量简短}, {role: user, content: 快捷指令里填的这段文字} ], stream: false }返回后用“获取字典值”动作按路径choices.0.message.content取内容。stream: false是有意为之——快捷指令处理流式响应很别扭不如等一次性返回。这条路线能成立的前提是推理发生在远端。手机侧不加载任何权重不占内存不发热代价是每次对话都要走网络且你的输入文本离开了设备。这个取舍在工程上是合理的一台中端手机的算力跟一台带独显的机器差两个数量级硬要在端上跑 7B 模型体验会很差。快捷指令真正的价值在于系统级入口它可以挂到分享菜单在任意 App 里选中文字直接问、挂到 Siri、放到主屏或锁屏小组件把“打开网页、登录、输入”压缩成一次点击。这是纯 Web 页面做不到的事。3.2 Termux 编译链路为什么 Android 上必须自己 go buildAndroid 那条路完全是另一回事。官方没有发布 Android/arm64 的预编译二进制所以你只能拿源码自己编。这不是作者偷懒是编译链的约束Ollama 的服务层是 Go但推理内核是 C/C 写的ggml 那一套中间靠 cgo 连接。cgo 一旦介入就不再是“设个 GOOS/GOARCH 就能交叉编译”的纯 Go 场景了——你得有匹配目标平台的 C 工具链、C 标准库、以及正确版本的链接器。Termux 提供的正好是这样一个用户态环境一个跑在 Android 上、不依赖 root 的 Linux 前缀所有包都装在/data/data/com.termux/files/usr下。整个流程的第一步不是装依赖而是拿存储权限# 申请访问共享存储成功后会在 ~ 下建立 storage 符号链接 termux-setup-storage # pkg 是 apt 的包装先同步索引再升级已有包 pkg update pkg upgrade -y # 编译 Ollama 需要 git 拉源码、golang 编译、cmake 构建 C 部分、 # clang 提供 cgo 所需的 C/C 编译器 pkg install -y git cmake golang clang libjpeg-turbotermux-setup-storage的作用常被误解成“给 Termux 开权限”实际上它做的是把/storage/emulated/0也就是文件管理器里看到的内部存储软链到~/storage同时触发系统的运行时权限弹窗。不做这一步git clone到~没问题但你想把编译好的二进制或模型文件放到能被其他 App 访问的位置就会失败。接下来是拉源码和编译# --depth 1 只取最新一次提交仓库历史对编译毫无用处能省几百 MB git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # go generate 会跑代码生成器产出 cgo 需要的头文件绑定和内嵌资源 go generate ./... # 单线程构建手机上并行编译极易被系统 OOM Killer 干掉 go build -p 1 -o ollama .go generate ./...这一步不能跳。它执行的是源码里//go:generate注释标记的命令负责生成 cgo 的桥接代码和把一些静态资源嵌进二进制。跳过它go build会在链接阶段报一堆 undefined symbol报错信息还完全不指向真正的原因。编完之后启动服务并验证# 后台启动 让它脱离当前 shell ./ollama serve # 根路径会返回一句存活提示能拿到就说明 HTTP 层起来了 curl http://localhost:11434 # 拉模型、跑模型命令与桌面端完全一致 ./ollama pull deepseek-r1:8b ./ollama run deepseek-r1:8b这里有个血泪经验Android 的后台管理比桌面激进得多挂起来的进程在息屏后几分钟就可能被冻结甚至回收。跑长任务前先执行termux-wake-lock拿一个唤醒锁用完termux-wake-unlock释放否则你会遇到“明明启动成功了切个 App 回来就 Connection refused”的诡异现象。3.3 8B 模型塞进手机的物理上限内存、带宽与 token/s编译成功不等于能用。手机端本地推理的天花板由两个硬件指标决定跟软件优化关系不大。第一个是内存容量。8B 模型 Q4 量化约 4.9GB加上 4K 上下文的 KV cache 约 0.5GB再算上 Termux 自身、Android 系统、其他后台应用实际需要 7GB 以上的可用内存。8GB RAM 的手机理论够实际常常不够——Android 的 LMK低内存杀手会在可用内存跌破阈值时按优先级杀进程你的ollama大概率排在列表前列。这就是为什么很多人第一次pull完模型run的时候直接闪退日志里什么都没有。第二个是内存带宽。自回归解码每生成一个 token都要把全部权重从内存读一遍batch1 时矩阵乘退化成向量乘算力不是瓶颈带宽才是。手机 LPDDR5 的带宽在 3060GB/s 量级4.9GB 权重除以 50GB/s 约 0.1 秒理论上限 10 token/s。实际还要扣掉散热降频、系统调度抖动、非连续访存的开销落到 25 token/s 是常态。对比之下同样模型在带独显的机器上跑 30 token/s 毫不费力。所以手机端的定位要摆正它是“离线可用、隐私可控、随时能问一句”的方案不是“替代电脑”的方案。真要在这个尺寸上追求响应速度正确做法是把推理放到远端手机只做入口——也就是 iPhone 那条路的思路。这也是为什么同一份部署指南里两个平台给出了完全不同的技术路线不是作者偏心是硬件约束把人逼到了两个方向。4. 前后端解耦Open WebUI 与 Ollama 之间的那条网络边界4.1 两个容器、两个网络命名空间localhost 为什么会指错Open WebUI 的部署命令看起来平平无奇但里面每个参数都在解决一个具体的网络问题docker run -d \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main-p 3000:8080是端口映射容器内的 WebUI 监听 8080它自己的默认端口映射到宿主机的 3000。浏览器访问localhost:3000时流量进的是宿主机网卡Docker 的 iptables 规则把它转给容器。--add-hosthost.docker.internal:host-gateway是这条命令里最关键、也最容易被抄漏的一项。容器有独立的网络命名空间容器里的localhost指的是容器自己不是宿主机。所以你在 WebUI 的配置里填http://localhost:11434它找来的是 WebUI 容器内部那个 11434 端口——那里什么都没有于是报连接失败。host.docker.internal是 Docker 提供的一个特殊主机名host-gateway告诉它解析到宿主机的网关 IP这条--add-host就是往容器的/etc/hosts里写一行映射。Linux 上不加这个参数这个名字根本不存在。还有一层坑即使地址写对了Ollama 默认也只绑127.0.0.1:11434。宿主机上跑着的 Ollama 收到来自 Docker 网桥通常是172.17.0.1的连接时会因为监听地址不匹配而拒绝。解决办法是启动 Ollama 时设OLLAMA_HOST0.0.0.0:11434让它监听所有网卡。# 桌面端让 Ollama 对外暴露容器才连得进来 export OLLAMA_HOST0.0.0.0:11434 ollama serve另一条更干净的路是把两个容器放进同一个自定义网络用服务名互访完全不碰宿主机docker network create ai-net docker run -d --name ollama --network ai-net \ -v ollama:/root/.ollama -p 11434:11434 ollama/ollama docker run -d --name webui --network ai-net -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://ollama:11434 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main在ai-net里Docker 内置的 DNS 会把ollama这个名字解析成对应容器的 IPOLLAMA_BASE_URL直接指过去就行。这也是我现在更倾向的方式不依赖宿主机的监听配置换机器时只需改网络名。4.2 OLLAMA_BASE_URL 与数据卷WebUI 究竟保存了什么-v open-webui:/app/backend/data这行决定了你的聊天记录能不能活过容器重建。镜像本身是无状态的删掉容器再起一个新的所有数据灰飞烟灭挂上卷之后/app/backend/data这个目录被持久化到宿主机里面主要是三样东西webui.dbSQLite存用户、会话、消息、模型配置、vector_db/RAG 用的向量库默认 Chroma、以及上传的文件。几个环境变量的作用值得单独说清楚变量作用常见取值OLLAMA_BASE_URL后端调用 Ollama 的地址http://ollama:11434OPENAI_API_BASE_URL接入 OpenAI 兼容端点时的地址任意兼容服务WEBUI_SECRET_KEY会话签名密钥多副本部署必须一致随机长字符串DATA_DIR数据目录默认/app/backend/data与挂载点保持一致WEBUI_SECRET_KEY这一项在单机玩的时候无所谓一旦你起两个副本做负载均衡不统一这个值就会表现为“登录成功但立刻掉线”——JWT 是副本 A 签的请求被转到副本 B 验证失败。这种问题排查起来非常费劲因为它看起来像前端 bug。4.3 点一下“下载模型”到底发生了什么WebUI 对 /api/pull 的转发与 RAG 注入WebUI 的管理界面里有个“拉取模型”的下拉框选中 DeepSeek 点下载进度条就开始走。这个过程里 WebUI 没有做任何下载逻辑它只是替浏览器发了一个请求给 Ollama# WebUI 后端转发模型拉取请求的等价写法 import requests, json def pull_model(name: str): # Ollama 的 /api/pull 返回 NDJSON 流每行一个进度事件 with requests.post( http://ollama:11434/api/pull, json{name: name, stream: True}, streamTrue, timeoutNone, # 大模型下载可能几十分钟不能设短超时 ) as resp: for line in resp.iter_lines(): if not line: continue evt json.loads(line) # status 形如 pulling manifest / downloading # completed/total 是当前层的字节进度 print(f{evt.get(status)} {evt.get(completed, 0)}/{evt.get(total, 0)})关键点在于streamTrue和timeoutNone。Ollama 的拉取接口是按层流式返回进度的如果后端用了默认超时一个大模型下到一半连接就被掐断前端看到的进度条会卡在某个百分比然后报错。很多人以为是网络问题其实只是超时配置。WebUI 真正增值的地方在编排层不是皮肤。它把模型当成可路由的资源你可以在同一个界面里挂本地 Ollama、远端兼容端点、甚至多个不同尺寸的模型按会话切换。它还维护了 RAG 链路——上传的文档被切片、调用 embedding 模型转向量、塞进向量库每次提问先检索 top-k 片段拼进 prompt。这条链路里的 embedding 调用同样走 Ollama 的/api/embeddings所以一个nomic-embed-text之类的小模型是必需品只拉对话模型会发现文档问答功能用不了。理解了这一层你就知道 WebUI 为什么值得单独跑一个容器它是有状态的编排器和纯算子的 Ollama 职责完全不同。5. 部署避坑五条在终端里真实翻车的记录5.1 拉模型卡在 pulling manifest 或者下到 90% 断掉现象ollama pull运行几十分钟进度条走到某个百分比后长时间不动最终报unexpected EOF或直接退出重跑又从零开始。原因拉取是按层分块下载 边下边校验 sha256 的。任何一块校验不过整个层作废。网络抖动、磁盘写满、或者目标分区剩余空间不足blob 需要完整落盘后才改名都会触发。Ollama 的断点续传能力有限某些版本对中断的临时文件处理不干净。解决先df -h看模型目录所在分区的剩余空间至少要留出模型体积 1.5 倍再确认~/.ollama/models/blobs里没有残留的巨大临时文件最后重试网络不稳就换时间段。实在反复失败用ollama pull拉一个更小的量化 tag 验证链路能成功说明是体积问题不是网络问题。5.2 模型加载到一半进程消失日志里什么都没有现象ollama run后终端打印几行加载信息就退出dmesg里能看到Out of memory: Killed process但 Ollama 自己的日志干净得像没事发生。原因Linux 的 OOM Killer 在内存耗尽时按 oom_score 杀进程被选中时进程收到 SIGKILL没有任何机会写日志。触发点通常是“模型权重 预分配 KV cache”超过了可用内存尤其是num_ctx设得很大或者OLLAMA_NUM_PARALLEL大于 1 的时候。解决把num_ctx从默认值降到 20484096 试一次换更低的量化档Q4_0 比 Q4_K_M 少几百 MB确认OLLAMA_NUM_PARALLEL1。用free -h在加载前看 available 而不是 freepage cache 是可回收的。如果是在 Docker 里跑还要检查容器有没有内存上限docker stats看 LIMIT 那一列。5.3 容器里的 WebUI 死活连不上 Ollama现象WebUI 界面能打开但一发消息就报错日志里是Connection refused或Max retries exceeded而宿主机上curl localhost:11434一切正常。原因两个独立问题叠加。一是容器内的localhost指向容器自身不是宿主机二是即使地址写对了Ollama 默认只绑127.0.0.1来自 Docker 网桥的连接会被拒。解决优先用自定义网络 服务名http://ollama:11434一步解决解析和监听两个问题。只能用 host 模式时两边都要改Ollama 侧设OLLAMA_HOST0.0.0.0:11434WebUI 侧加--add-hosthost.docker.internal:host-gateway并把地址改成http://host.docker.internal:11434。改完在容器里curl一下验证别靠界面报错猜。5.4 Termux 里 go build 报一堆 undefined symbol现象go build跑到链接阶段失败错误里全是undefined reference to之类指向一些看起来像 C 函数的名字。原因漏了go generate ./...。cgo 的桥接代码不是手写的是生成出来的不生成Go 侧和 C 侧的函数签名对不上链接器自然找不到符号。另一种可能是pkg install clang没装或者装了一半。解决严格按pkg install clang→go generate ./...→go build -p 1 -o ollama .的顺序走一步不跳。-p 1限制并行编译数手机上并行编译的内存峰值很容易触发 OOM报错信息还会伪装成编译器内部错误。编译失败时先清go clean -cache再来一遍别在脏缓存上反复试。5.5 tag 写错拉到的模型和预期不是一个东西现象文档里一处写deepseek-r1:7b另一处写deepseek-r1:8b两条命令都能跑但一个 4.4GB 一个 4.9GB跑起来内存表现完全不同或者直接报manifest unknown。原因模型 tag 是精确匹配的:7b和:8b是两个独立 manifest指向不同的权重 blob。manifest unknown说明这个 tag 在注册表里根本不存在可能是版本号记错了或者模型已改名。解决拉之前先ollama list看本地已有的用ollama show model看参数量和量化类型确认是不是你要的。写部署脚本时把模型名抽成变量别在多处硬编码。移动端尤其要注意8B 在手机上比 7B 更容易被系统杀掉文档里的两处不一致不是笔误就是历史遗留按自己设备的实际内存选小的那一档。6. 取舍把推理放在本地还是远端取决于你愿意付哪一笔账走完这几条路线会发现它们不是“同一个东西的不同装法”而是三个不同位置的取舍。本地 Ollama 买的是数据不出机器付的是内存、磁盘和一次性的环境配置成本手机快捷指令买的是随时随地可用付的是网络依赖和文本离开设备Open WebUI 加容器买的是多模型编排和知识库付的是多一层网络边界的排查成本。维度本地 Ollama手机端远端 APIOpen WebUI 容器数据位置完全本地出端到服务方本地含本地向量库首次成本装运行时 拉 GB 级权重填一个 Key两个镜像 网络配置响应速度取决于本机带宽与算力取决于网络 RTT同本地多一层转发离线可用是否是主要故障点内存不足、量化选错Key 失效、超时容器网络、监听地址我一般会这么判断如果对话内容涉及不能外发的资料本地这条路没有替代品剩下的只是把量化档位和num_ctx调到不 OOM 的平衡点如果只是想要一个随手能问的入口手机端那条最省事但要清楚它本质是远端推理的封装别指望断网还能用如果需求是“团队共用一套、能传文档问”那 WebUI 的编排价值就压过了它的部署复杂度。验证是否真的搭对了别只看界面能不能打开。三个动作按顺序做curl http://地址:11434/api/tags能返回模型列表说明服务和注册都正常curl打一次/api/chat看返回里eval_count/eval_duration的比值这是你这套环境的真实吞吐最后跑一个长上下文的问题比如让它总结一篇几千字的文档看内存曲线会不会顶到天花板——短对话能跑、长上下文崩是最常见的“假成功”。从那以后我每次部署完都会强制走一遍这三步再交付不再相信“界面出来了就是好了”。很多所谓的环境问题其实是在第一步就没通只是被前端友好的错误提示盖住了。希望帮到你。本文还有配套的精品资源点击获取 从GGUF量化到KV cache：Ollama本地推理部署避坑
简介这份指南围绕 DeepSeek 的多平台部署展开面向希望将大模型落地到实际环境的开发人员与技术爱好者覆盖机器学习、深度学习与自然语言处理场景下的模型部署需求。内容以单份 docx 文档交付压缩包约 15KB共 1 个文件便于快速查阅和按需检索。现有 1521 人学习说明其在 AI 工具实践群体中具备一定参考价值。文档按平台组织操作路径本地环境先安装 Ollama 并拉取运行 DeepSeek 模型iPhone 通过快捷指令配合 API Key 完成调用Android 借助 Termux 配置依赖、编译并启动 Ollama 服务Open WebUI 方案则结合 Docker 与 Ollama 搭建可视化交互界面。各环节给出明确命令、配置顺序与验证方式并提示可能遇到的问题及处理思路适合初学者按步骤实践也方便有经验的开发者快速比较不同部署方案的适用条件为个人研究或业务集成提供可操作的参考。1. 一条命令背后模型文件之外还藏着什么大多数人第一次执行ollama run deepseek-r1:7b时会以为自己在“下载一个模型”。实际下载的只是几 GB 字节流真正的重头戏在之后这些字节要先被 mmap 映射进虚拟内存再由推理引擎按层做矩阵乘最后由一个常驻进程把生成结果切成 token 流式吐回终端。模型部署的难点从来不在“拿到文件”而在权重的数值格式、内核能不能吃满你手里那块芯片、以及服务层怎么把一次对话拆成可中断的请求。把这三层拆开看你才会明白为什么同一个模型在笔记本上秒回、在手机上卡成幻灯片、在容器里又连不上——这些现象背后是同一套机制在不同约束下的表现。2. 权重格式与推理引擎Ollama 凭什么用一行命令跑起 7B 模型2.1 GGUF 与量化14GB 的权重是怎么缩到 4GB 的先把账算清楚。一个 7B 参数的模型如果每个权重用 fp162 字节存光权重就是 7×10⁹×2 ≈ 14GB。这个体积对消费级设备是致命的16GB 内存的笔记本装得下但没法留出 KV cache 的空间手机更是直接出局。所以任何能在本地跑的模型第一步都是量化——把浮点权重压成低比特整数。量化的原理不复杂但细节决定了画质。最朴素的做法是整层共用一个 scalew_int round(w / scale)反量化时再乘回去。问题是一层里权重的动态范围可能差好几个数量级全局 scale 会被少数大权重绑架小权重全被压成 0模型直接“变傻”。所以工业实现普遍走分块量化把连续的 256 个权重划成一个 super-block块内单独算 scale 和 min块与块之间互不干扰。Q4_K_M 这类名字里的K指的就是这套 k-quant 分块方案M表示中等粒度混合——部分关键张量比如 attention 的 value 投影用更高比特其余用 4 bit。常见的实现思路大致是这样一个 Q4_K 的 super-block 存 256 个 4 bit 权重128 字节外加 6 bit 的 scale 和 6 bit 的 min摊下来约 4.5 bit/权重。7B 参数乘 4.5 bit 约 3.9GB再加上不参与量化的 embedding 和输出层最终落在 4.4GB 上下。量化类型每权重比特7B 模型体积质量损失主观F1616~14GB无基准Q8_08.5~7.2GB几乎不可感知Q5_K_M5.7~5.1GB轻微长文推理略降Q4_K_M4.8~4.4GB可接受日常问答无感Q4_04.5~3.9GB明显代码与数学题掉点Q2_K2.6~2.7GB严重不建议生产用选哪一档不是玄学是内存预算倒推出来的模型体积 KV cache 必须小于可用内存的 70% 左右否则系统会在你聊到第三轮时把进程杀掉。GGUF 这个容器格式的设计动机也在这儿。它是一个单文件自描述格式文件头写明版本和 tensor 数量紧跟一段 key-value 元数据架构名、层数、head 数、上下文长度、tokenizer 词表然后是每个 tensor 的名字、维度、类型、偏移量最后才是连续排布的权重数据。这样做的直接好处是可以 mmap——推理时不需要把 4GB 一次性读进 RAM而是把文件映射到虚拟地址空间用到哪一页就缺页加载哪一页。这就是为什么ollama run看起来“秒启动”它只是打开了文件真正耗时的是首次推理时把权重页逐块换入。2.2 内容寻址存储磁盘上的模型其实是 manifest 加一堆 blob如果你去翻 Ollama 的数据目录会发现里面没有deepseek-r1-7b.gguf这种直白命名的文件而是一堆以sha256-开头的无后缀文件。这不是设计得晦涩是在抄容器镜像那套内容寻址存储CAS文件名就是内容的哈希内容变一个字节名字就变。# Linux/macOS 下的默认位置Windows 在 %USERPROFILE%\.ollama\models tree -L 3 ~/.ollama/models # ├── blobs/ # │ ├── sha256-3f9a... # 模型权重层最大的那个 # │ ├── sha256-8c21... # 模板与参数配置层 # │ └── sha256-a04e... # 许可证/说明等小层 # └── manifests/ # └── registry.ollama.ai/library/deepseek-r1/7b # 一个 JSON 清单manifest 的结构和 OCI 镜像清单几乎同构{ schemaVersion: 2, mediaType: application/vnd.docker.distribution.manifest.v2json, config: { mediaType: application/vnd.docker.container.image.v1json, digest: sha256:8c21..., size: 4821 }, layers: [ { mediaType: application/vnd.ollama.image.model, digest: sha256:3f9a..., size: 4401234567 } ] }config指向的那个小 blob 里存的是模板chat template、默认参数temperature、stop 序列和系统提示。layers里的 model 层才是 GGUF 数据。这样拆的好处是层可复用同一个底座的不同微调版本如果 tokenizer 和模板没变共享同一份小层甚至不同 tag 如果指向同一个权重 blobollama pull会直接跳过下载。这也是为什么你拉第二个相近模型时速度会快得让人怀疑它没下载完。ollama create加 Modelfile 的玩法就建立在这套结构上# Modelfile 里的 FROM 可以指向已有模型PARAMETER 会写进新的 config 层 cat Modelfile EOF FROM deepseek-r1:7b PARAMETER temperature 0.6 PARAMETER num_ctx 8192 SYSTEM 你是一个只讲实现细节的工程师 EOF ollama create my-r1 -f Modelfile这里的关键是新模型不会复制 4.4GB 权重它只是生成一份新 manifest权重层仍然指向原来那个 blob 的哈希。改温度、改系统提示这种操作磁盘成本接近零。理解了这一点你就不会在磁盘快满时去删blobs里的“重复文件”——按哈希命名意味着物理上根本不存在重复。2.3 从 HTTP 到 token一次 /api/chat 请求在 11434 端口里走了什么ollama run只是个 CLI 壳子真正干活的是一个常驻的 HTTP 服务默认监听127.0.0.1:11434。你可以直接拿 curl 打它看到的东西比 CLI 更接近本质curl http://localhost:11434/api/chat -d { model: deepseek-r1:7b, messages: [ {role: user, content: 用一句话说清楚 KV cache 的作用} ], stream: true, options: {num_ctx: 4096, temperature: 0.6} }响应不是一段完整 JSON而是一串换行分隔的 JSON 对象NDJSON每行带一个message.content片段最后一行done: true并附上统计字段{model:deepseek-r1:7b,message:{role:assistant,content:KV},done:false} {model:deepseek-r1:7b,message:{role:assistant,content: cache},done:false} {model:deepseek-r1:7b,done:true,total_duration:8123456789,eval_count:37,eval_duration:5210000000}eval_count / eval_duration就是常说的 token/s这是判断“跑得动跑不动”最硬的指标比任何主观感受都可靠。一次请求在服务内部的路径大致是五步。第一步HTTP 层解析请求体校验模型名是否已在本地 manifest 里注册没注册就直接返回 404不会偷偷去下载。第二步进入调度器它检查目标模型是否已经加载已加载就看keep_alive有没有过期默认 5 分钟过期就等待回收未加载则拉起一个runner 子进程。第三步runner 进程把 GGUF 映射进内存按num_ctx预分配 KV cache然后开始 prefill——把整段 prompt 一次性过一遍前向填满 KV cache。第四步逐 token 解码每生成一个就通过管道回传给主进程。第五步主进程把它包装成 NDJSON 写回 HTTP 响应体。这里有两个容易被忽略的机制。其一runner 是独立进程而非线程模型加载失败、显存不足、推理崩溃都只会杀掉 runner主服务还活着所以你能看到ollama ps里模型状态变了但 API 仍在响应。其二KV cache 是预分配的num_ctx8192意味着即使你只问了一句“你好”也有一块对应 8192 token 的缓存被占住。粗略估算32 层、8 个 KV head、head_dim 128、fp16 存 K 和 V8192 token 下约 2×32×8×128×8192×2 byte ≈ 1GB。这个数字直接解释了后面所有的“内存不够”问题——模型 4.4GB 只是入场券KV cache 才是隐形开销。提示OLLAMA_KEEP_ALIVE、OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS这三个环境变量决定了调度器行为。并行数每加一KV cache 就翻一倍笔记本上把它设成 4 是自找麻烦。3. 手机端的两条岔路iPhone 为什么只发请求Android 却要自己编译3.1 快捷指令的本质一个跑在系统里的 HTTP 客户端iPhone 那条路线看起来最“不像部署”安装一个快捷指令填入 API Key就能对话。很多人以为这是某种黑科技其实拆开看快捷指令就是一个plist 描述的动作序列里面的核心动作叫“获取 URL 内容”支持指定 method、headers 和 request body。换句话说它做的就是把你的输入拼成一个 JSONPOST 出去再把返回的 JSON 解析出文本显示出来。请求体长这样和你在电脑上 curl 的东西一模一样{ model: deepseek-r1, messages: [ {role: system, content: 回答尽量简短}, {role: user, content: 快捷指令里填的这段文字} ], stream: false }返回后用“获取字典值”动作按路径choices.0.message.content取内容。stream: false是有意为之——快捷指令处理流式响应很别扭不如等一次性返回。这条路线能成立的前提是推理发生在远端。手机侧不加载任何权重不占内存不发热代价是每次对话都要走网络且你的输入文本离开了设备。这个取舍在工程上是合理的一台中端手机的算力跟一台带独显的机器差两个数量级硬要在端上跑 7B 模型体验会很差。快捷指令真正的价值在于系统级入口它可以挂到分享菜单在任意 App 里选中文字直接问、挂到 Siri、放到主屏或锁屏小组件把“打开网页、登录、输入”压缩成一次点击。这是纯 Web 页面做不到的事。3.2 Termux 编译链路为什么 Android 上必须自己 go buildAndroid 那条路完全是另一回事。官方没有发布 Android/arm64 的预编译二进制所以你只能拿源码自己编。这不是作者偷懒是编译链的约束Ollama 的服务层是 Go但推理内核是 C/C 写的ggml 那一套中间靠 cgo 连接。cgo 一旦介入就不再是“设个 GOOS/GOARCH 就能交叉编译”的纯 Go 场景了——你得有匹配目标平台的 C 工具链、C 标准库、以及正确版本的链接器。Termux 提供的正好是这样一个用户态环境一个跑在 Android 上、不依赖 root 的 Linux 前缀所有包都装在/data/data/com.termux/files/usr下。整个流程的第一步不是装依赖而是拿存储权限# 申请访问共享存储成功后会在 ~ 下建立 storage 符号链接 termux-setup-storage # pkg 是 apt 的包装先同步索引再升级已有包 pkg update pkg upgrade -y # 编译 Ollama 需要 git 拉源码、golang 编译、cmake 构建 C 部分、 # clang 提供 cgo 所需的 C/C 编译器 pkg install -y git cmake golang clang libjpeg-turbotermux-setup-storage的作用常被误解成“给 Termux 开权限”实际上它做的是把/storage/emulated/0也就是文件管理器里看到的内部存储软链到~/storage同时触发系统的运行时权限弹窗。不做这一步git clone到~没问题但你想把编译好的二进制或模型文件放到能被其他 App 访问的位置就会失败。接下来是拉源码和编译# --depth 1 只取最新一次提交仓库历史对编译毫无用处能省几百 MB git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # go generate 会跑代码生成器产出 cgo 需要的头文件绑定和内嵌资源 go generate ./... # 单线程构建手机上并行编译极易被系统 OOM Killer 干掉 go build -p 1 -o ollama .go generate ./...这一步不能跳。它执行的是源码里//go:generate注释标记的命令负责生成 cgo 的桥接代码和把一些静态资源嵌进二进制。跳过它go build会在链接阶段报一堆 undefined symbol报错信息还完全不指向真正的原因。编完之后启动服务并验证# 后台启动 让它脱离当前 shell ./ollama serve # 根路径会返回一句存活提示能拿到就说明 HTTP 层起来了 curl http://localhost:11434 # 拉模型、跑模型命令与桌面端完全一致 ./ollama pull deepseek-r1:8b ./ollama run deepseek-r1:8b这里有个血泪经验Android 的后台管理比桌面激进得多挂起来的进程在息屏后几分钟就可能被冻结甚至回收。跑长任务前先执行termux-wake-lock拿一个唤醒锁用完termux-wake-unlock释放否则你会遇到“明明启动成功了切个 App 回来就 Connection refused”的诡异现象。3.3 8B 模型塞进手机的物理上限内存、带宽与 token/s编译成功不等于能用。手机端本地推理的天花板由两个硬件指标决定跟软件优化关系不大。第一个是内存容量。8B 模型 Q4 量化约 4.9GB加上 4K 上下文的 KV cache 约 0.5GB再算上 Termux 自身、Android 系统、其他后台应用实际需要 7GB 以上的可用内存。8GB RAM 的手机理论够实际常常不够——Android 的 LMK低内存杀手会在可用内存跌破阈值时按优先级杀进程你的ollama大概率排在列表前列。这就是为什么很多人第一次pull完模型run的时候直接闪退日志里什么都没有。第二个是内存带宽。自回归解码每生成一个 token都要把全部权重从内存读一遍batch1 时矩阵乘退化成向量乘算力不是瓶颈带宽才是。手机 LPDDR5 的带宽在 3060GB/s 量级4.9GB 权重除以 50GB/s 约 0.1 秒理论上限 10 token/s。实际还要扣掉散热降频、系统调度抖动、非连续访存的开销落到 25 token/s 是常态。对比之下同样模型在带独显的机器上跑 30 token/s 毫不费力。所以手机端的定位要摆正它是“离线可用、隐私可控、随时能问一句”的方案不是“替代电脑”的方案。真要在这个尺寸上追求响应速度正确做法是把推理放到远端手机只做入口——也就是 iPhone 那条路的思路。这也是为什么同一份部署指南里两个平台给出了完全不同的技术路线不是作者偏心是硬件约束把人逼到了两个方向。4. 前后端解耦Open WebUI 与 Ollama 之间的那条网络边界4.1 两个容器、两个网络命名空间localhost 为什么会指错Open WebUI 的部署命令看起来平平无奇但里面每个参数都在解决一个具体的网络问题docker run -d \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main-p 3000:8080是端口映射容器内的 WebUI 监听 8080它自己的默认端口映射到宿主机的 3000。浏览器访问localhost:3000时流量进的是宿主机网卡Docker 的 iptables 规则把它转给容器。--add-hosthost.docker.internal:host-gateway是这条命令里最关键、也最容易被抄漏的一项。容器有独立的网络命名空间容器里的localhost指的是容器自己不是宿主机。所以你在 WebUI 的配置里填http://localhost:11434它找来的是 WebUI 容器内部那个 11434 端口——那里什么都没有于是报连接失败。host.docker.internal是 Docker 提供的一个特殊主机名host-gateway告诉它解析到宿主机的网关 IP这条--add-host就是往容器的/etc/hosts里写一行映射。Linux 上不加这个参数这个名字根本不存在。还有一层坑即使地址写对了Ollama 默认也只绑127.0.0.1:11434。宿主机上跑着的 Ollama 收到来自 Docker 网桥通常是172.17.0.1的连接时会因为监听地址不匹配而拒绝。解决办法是启动 Ollama 时设OLLAMA_HOST0.0.0.0:11434让它监听所有网卡。# 桌面端让 Ollama 对外暴露容器才连得进来 export OLLAMA_HOST0.0.0.0:11434 ollama serve另一条更干净的路是把两个容器放进同一个自定义网络用服务名互访完全不碰宿主机docker network create ai-net docker run -d --name ollama --network ai-net \ -v ollama:/root/.ollama -p 11434:11434 ollama/ollama docker run -d --name webui --network ai-net -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://ollama:11434 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main在ai-net里Docker 内置的 DNS 会把ollama这个名字解析成对应容器的 IPOLLAMA_BASE_URL直接指过去就行。这也是我现在更倾向的方式不依赖宿主机的监听配置换机器时只需改网络名。4.2 OLLAMA_BASE_URL 与数据卷WebUI 究竟保存了什么-v open-webui:/app/backend/data这行决定了你的聊天记录能不能活过容器重建。镜像本身是无状态的删掉容器再起一个新的所有数据灰飞烟灭挂上卷之后/app/backend/data这个目录被持久化到宿主机里面主要是三样东西webui.dbSQLite存用户、会话、消息、模型配置、vector_db/RAG 用的向量库默认 Chroma、以及上传的文件。几个环境变量的作用值得单独说清楚变量作用常见取值OLLAMA_BASE_URL后端调用 Ollama 的地址http://ollama:11434OPENAI_API_BASE_URL接入 OpenAI 兼容端点时的地址任意兼容服务WEBUI_SECRET_KEY会话签名密钥多副本部署必须一致随机长字符串DATA_DIR数据目录默认/app/backend/data与挂载点保持一致WEBUI_SECRET_KEY这一项在单机玩的时候无所谓一旦你起两个副本做负载均衡不统一这个值就会表现为“登录成功但立刻掉线”——JWT 是副本 A 签的请求被转到副本 B 验证失败。这种问题排查起来非常费劲因为它看起来像前端 bug。4.3 点一下“下载模型”到底发生了什么WebUI 对 /api/pull 的转发与 RAG 注入WebUI 的管理界面里有个“拉取模型”的下拉框选中 DeepSeek 点下载进度条就开始走。这个过程里 WebUI 没有做任何下载逻辑它只是替浏览器发了一个请求给 Ollama# WebUI 后端转发模型拉取请求的等价写法 import requests, json def pull_model(name: str): # Ollama 的 /api/pull 返回 NDJSON 流每行一个进度事件 with requests.post( http://ollama:11434/api/pull, json{name: name, stream: True}, streamTrue, timeoutNone, # 大模型下载可能几十分钟不能设短超时 ) as resp: for line in resp.iter_lines(): if not line: continue evt json.loads(line) # status 形如 pulling manifest / downloading # completed/total 是当前层的字节进度 print(f{evt.get(status)} {evt.get(completed, 0)}/{evt.get(total, 0)})关键点在于streamTrue和timeoutNone。Ollama 的拉取接口是按层流式返回进度的如果后端用了默认超时一个大模型下到一半连接就被掐断前端看到的进度条会卡在某个百分比然后报错。很多人以为是网络问题其实只是超时配置。WebUI 真正增值的地方在编排层不是皮肤。它把模型当成可路由的资源你可以在同一个界面里挂本地 Ollama、远端兼容端点、甚至多个不同尺寸的模型按会话切换。它还维护了 RAG 链路——上传的文档被切片、调用 embedding 模型转向量、塞进向量库每次提问先检索 top-k 片段拼进 prompt。这条链路里的 embedding 调用同样走 Ollama 的/api/embeddings所以一个nomic-embed-text之类的小模型是必需品只拉对话模型会发现文档问答功能用不了。理解了这一层你就知道 WebUI 为什么值得单独跑一个容器它是有状态的编排器和纯算子的 Ollama 职责完全不同。5. 部署避坑五条在终端里真实翻车的记录5.1 拉模型卡在 pulling manifest 或者下到 90% 断掉现象ollama pull运行几十分钟进度条走到某个百分比后长时间不动最终报unexpected EOF或直接退出重跑又从零开始。原因拉取是按层分块下载 边下边校验 sha256 的。任何一块校验不过整个层作废。网络抖动、磁盘写满、或者目标分区剩余空间不足blob 需要完整落盘后才改名都会触发。Ollama 的断点续传能力有限某些版本对中断的临时文件处理不干净。解决先df -h看模型目录所在分区的剩余空间至少要留出模型体积 1.5 倍再确认~/.ollama/models/blobs里没有残留的巨大临时文件最后重试网络不稳就换时间段。实在反复失败用ollama pull拉一个更小的量化 tag 验证链路能成功说明是体积问题不是网络问题。5.2 模型加载到一半进程消失日志里什么都没有现象ollama run后终端打印几行加载信息就退出dmesg里能看到Out of memory: Killed process但 Ollama 自己的日志干净得像没事发生。原因Linux 的 OOM Killer 在内存耗尽时按 oom_score 杀进程被选中时进程收到 SIGKILL没有任何机会写日志。触发点通常是“模型权重 预分配 KV cache”超过了可用内存尤其是num_ctx设得很大或者OLLAMA_NUM_PARALLEL大于 1 的时候。解决把num_ctx从默认值降到 20484096 试一次换更低的量化档Q4_0 比 Q4_K_M 少几百 MB确认OLLAMA_NUM_PARALLEL1。用free -h在加载前看 available 而不是 freepage cache 是可回收的。如果是在 Docker 里跑还要检查容器有没有内存上限docker stats看 LIMIT 那一列。5.3 容器里的 WebUI 死活连不上 Ollama现象WebUI 界面能打开但一发消息就报错日志里是Connection refused或Max retries exceeded而宿主机上curl localhost:11434一切正常。原因两个独立问题叠加。一是容器内的localhost指向容器自身不是宿主机二是即使地址写对了Ollama 默认只绑127.0.0.1来自 Docker 网桥的连接会被拒。解决优先用自定义网络 服务名http://ollama:11434一步解决解析和监听两个问题。只能用 host 模式时两边都要改Ollama 侧设OLLAMA_HOST0.0.0.0:11434WebUI 侧加--add-hosthost.docker.internal:host-gateway并把地址改成http://host.docker.internal:11434。改完在容器里curl一下验证别靠界面报错猜。5.4 Termux 里 go build 报一堆 undefined symbol现象go build跑到链接阶段失败错误里全是undefined reference to之类指向一些看起来像 C 函数的名字。原因漏了go generate ./...。cgo 的桥接代码不是手写的是生成出来的不生成Go 侧和 C 侧的函数签名对不上链接器自然找不到符号。另一种可能是pkg install clang没装或者装了一半。解决严格按pkg install clang→go generate ./...→go build -p 1 -o ollama .的顺序走一步不跳。-p 1限制并行编译数手机上并行编译的内存峰值很容易触发 OOM报错信息还会伪装成编译器内部错误。编译失败时先清go clean -cache再来一遍别在脏缓存上反复试。5.5 tag 写错拉到的模型和预期不是一个东西现象文档里一处写deepseek-r1:7b另一处写deepseek-r1:8b两条命令都能跑但一个 4.4GB 一个 4.9GB跑起来内存表现完全不同或者直接报manifest unknown。原因模型 tag 是精确匹配的:7b和:8b是两个独立 manifest指向不同的权重 blob。manifest unknown说明这个 tag 在注册表里根本不存在可能是版本号记错了或者模型已改名。解决拉之前先ollama list看本地已有的用ollama show model看参数量和量化类型确认是不是你要的。写部署脚本时把模型名抽成变量别在多处硬编码。移动端尤其要注意8B 在手机上比 7B 更容易被系统杀掉文档里的两处不一致不是笔误就是历史遗留按自己设备的实际内存选小的那一档。6. 取舍把推理放在本地还是远端取决于你愿意付哪一笔账走完这几条路线会发现它们不是“同一个东西的不同装法”而是三个不同位置的取舍。本地 Ollama 买的是数据不出机器付的是内存、磁盘和一次性的环境配置成本手机快捷指令买的是随时随地可用付的是网络依赖和文本离开设备Open WebUI 加容器买的是多模型编排和知识库付的是多一层网络边界的排查成本。维度本地 Ollama手机端远端 APIOpen WebUI 容器数据位置完全本地出端到服务方本地含本地向量库首次成本装运行时 拉 GB 级权重填一个 Key两个镜像 网络配置响应速度取决于本机带宽与算力取决于网络 RTT同本地多一层转发离线可用是否是主要故障点内存不足、量化选错Key 失效、超时容器网络、监听地址我一般会这么判断如果对话内容涉及不能外发的资料本地这条路没有替代品剩下的只是把量化档位和num_ctx调到不 OOM 的平衡点如果只是想要一个随手能问的入口手机端那条最省事但要清楚它本质是远端推理的封装别指望断网还能用如果需求是“团队共用一套、能传文档问”那 WebUI 的编排价值就压过了它的部署复杂度。验证是否真的搭对了别只看界面能不能打开。三个动作按顺序做curl http://地址:11434/api/tags能返回模型列表说明服务和注册都正常curl打一次/api/chat看返回里eval_count/eval_duration的比值这是你这套环境的真实吞吐最后跑一个长上下文的问题比如让它总结一篇几千字的文档看内存曲线会不会顶到天花板——短对话能跑、长上下文崩是最常见的“假成功”。从那以后我每次部署完都会强制走一遍这三步再交付不再相信“界面出来了就是好了”。很多所谓的环境问题其实是在第一步就没通只是被前端友好的错误提示盖住了。希望帮到你。本文还有配套的精品资源点击获取