简介围绕多平台环境下DeepSeek模型部署的实用指南面向希望把大模型落到个人设备或业务流程中的开发者、研究人员与技术爱好者覆盖从本地终端到移动端、浏览器端的多种落地路径。压缩包内为1个docx文档大小约15KB篇幅精炼便于按平台查阅与复现。内容围绕Ollama在macOS、Linux、Windows上的安装、模型拉取与终端交互展开并延伸到iPhone快捷指令配置API Key、Android借助Termux安装依赖、编译并启动Ollama服务及运行DeepSeek-R1模型同时说明用Docker Desktop与Open WebUI搭建浏览器访问界面的思路。文中给出较明确的操作命令、配置要点和官方链接可帮助读者理解不同硬件与系统下的部署差异掌握环境准备、服务验证和常见环节排错方法。已有3772人学习适合需要快速上手多端部署实践的技术读者参考。1. 从一次三方需求说起终端调试、浏览器共用、手机随时问上个月帮一个做客服系统的朋友评估本地化方案诉求特别具体把 DeepSeek 模型部署在自己机器上白天在终端里调 prompt晚上让同事从浏览器点开就能用出差路上还想在手机上问两句。三件事分别指向 Ollama 本地部署、Docker 里的 Open WebUI以及移动端Mobile的两条绕法——iPhone 快捷指令和 Android Termux。这套组合真正的价值在于「跑得住」权重只存一份对外只露一个 11434 端口三种客户端复用同一个模型文件。哪一步没配对上症状长得几乎一样转圈、超时、答非所问。下面按路径拆先在本地把模型拉下来并算清显存账再用 Docker 起网页界面然后处理手机端最后把五类真会卡住人的坑和一套验证手法摆出来。7B 的运行环境与 70B 的运行环境读法完全不同。2. Ollama 本地部署从拉模型到 OpenAI 兼容接口2.1 选 Ollama 的理由把量化、显存、加载策略一起打包自己搭推理栈当然可以transformers 加 vLLM 或 llama.cpp 都行但那是另一个工作量模型量化要自己转 GGUF、GPU 层数要自己算、Mac 上的 Metal 和 Windows 上的 CUDA 要分别处理、模型加载和卸载要自己写调度。Ollama 把这几件事压成了一个二进制加一个 HTTP 服务代价是并发能力弱——默认同一时刻基本只服务一个推理请求多用户场景会排队。我一般这么判断单人或小团队、单机、消费级显卡或统一内存的 Mac用 Ollama 省下来的时间足够抵掉它的性能损失要做对外服务的多租户 NLP 应用那是 vLLM 的地盘别硬扛。Ollama 的另一个好处是模型即配置一个 Modelfile 就把权重、对话模板、采样参数捆在一起换上下文长度不用改代码。它的自动分层策略值得说清楚模型加载时按可用显存把 transformer 层尽量塞进 GPU塞不下的留在内存里走 CPU。ollama ps那列 PROCESSOR 显示的100% GPU、40/60 CPU/GPU就是这个分配结果它是判断「为什么慢」的第一手证据比看任务管理器靠谱得多。2.2 三平台安装与首次拉取模型Linux 和 macOS 用脚本装Windows 走安装包装完确认服务在跑再拉模型。# Linux官方脚本安装并自动注册 systemd 服务 curl -fsSL https://ollama.com/install.sh | sh # 确认服务状态与版本 systemctl status ollama --no-pager ollama --version # macOS 装完是常驻菜单栏 App命令行直接可用 brew install ollama ollama serve # 前台起服务调试期方便看日志 # 拉取模型pull 只下载run 会先 pull 再进交互 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b # 查看本地已有模型与运行中的模型 ollama list ollama ps# Windows PowerShell装完安装包后 Ollama 会常驻托盘 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b # 服务端口被占用或要改监听地址时先改用户环境变量再重启托盘程序 [Environment]::SetEnvironmentVariable(OLLAMA_HOST,0.0.0.0:11434,User)命令本身没什么玄学容易翻车的是三处。第一run和pull的区别要记住run在模型不存在时会自动下载下载过程只有进度条没有提示看起来像卡死实际在写盘。第二模型标签选错比装错更常见deepseek-r1下面从 1.5b 到 70b 是蒸馏版本671b 才是完整版671b 在个人设备上基本没有可运行的可能看到磁盘只剩 20G 还去拉 70b 就是自找。第三Mac 上的ollama serve和托盘 App 会抢 11434 端口报address already in use时先看菜单栏有没有那只羊驼图标。拉完之后先别急着接程序在终端里问一个带推理的问题确认输出正常。R1 系列在较新版本里会把思考过程单独放进thinking字段终端交互时用灰色块展示如果你的输出里混着...和正文说明走的是老版本或老模板后面接前端时要不要过滤得提前想好。2.3 算力账模型体积、显存与上下文的换算部署失败九成不是命令错是没算账。权重、KV cache、运行时开销三块要一起看下表是按 Q4_K_M 量化Ollama 默认档位的粗略值实际以ollama ps的 SIZE 列为准。模型标签参数量权重大小约建议可用显存/内存典型感受deepseek-r1:1.5b1.5B1.1 GB4 GB笔记本轻量可用复杂推理偏弱deepseek-r1:7b7B4.7 GB8 GB单机甜点位8G 显卡刚好deepseek-r1:8b8B4.9 GB8 GB与 7b 差别不大看底座适配deepseek-r1:14b14B9 GB16 GB长文档摘要开始有明显提升deepseek-r1:32b32B20 GB24 GB24G 显卡的分水岭deepseek-r1:70b70B43 GB48 GB需要大显存或多卡或接受 CPU 降速权重之外KV cache 是第二个吃显存的大户而且它随上下文长度线性涨。Ollama 里num_ctx是每个请求可用的上下文窗口默认值通常在 2K4K 量级很多人抱怨「长文档一进去就答非所问」本质是超长部分被悄悄截断了根本没有进入模型。想把窗口拉到 8192 或 16384得先估算 KV cache 是否放得下别闭着眼睛写 128k。要做固定配置用 Modelfile 派生子模型比每次请求传参稳定# 基于已有的 7b 派生一个上下文 8K 的变体 cat Modelfile EOF FROM deepseek-r1:7b PARAMETER num_ctx 8192 PARAMETER temperature 0.6 EOF ollama create deepseek-r1-8k -f Modelfile ollama run deepseek-r1-8kFROM指定底座num_ctx是窗口temperature对 R1 这类推理模型来说 0.50.7 比较稳调高会让推理链条发散、答非所问的概率上升。派生出来的模型和底座共享权重层磁盘不会翻倍但加载时按新参数走。改完用ollama show deepseek-r1-8k --modelfile回看确认参数真的写进去了。2.4 把 11434 端口变成 OpenAI 兼容接口Ollama 自带两套 API原生的/api/chat、/api/generate和 OpenAI 兼容的/v1/chat/completions。后者是接入现成工具的关键绝大多数客户端只认这一套。# 原生接口/api/chat返回结构里带 thinking 与统计字段 curl http://127.0.0.1:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 用两句话说明 inode 耗尽的现象}], stream: false } # OpenAI 兼容接口路径多了 /v1key 随便填Ollama 不校验 curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer ollama \ -d {model:deepseek-r1:7b,messages:[{role:user,content:你好}],stream:false}Python 侧直接用 openai SDK 就能接不用改任何业务代码结构from openai import OpenAI # api_key 是占位符Ollama 不做鉴权但 SDK 要求非空 client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keyollama) resp client.chat.completions.create( modeldeepseek-r1:7b, messages[ {role: system, content: 你是运维助手回答控制在三句话内}, {role: user, content: 磁盘 inode 用满了会有什么现象}, ], temperature0.6, # 推理模型建议 0.5~0.7 max_tokens512, # 只是上限不是消耗量 streamFalse, ) print(resp.choices[0].message.content)三个参数最容易被误用。base_url结尾一定要带/v1漏了会 404这是移动端和网页端配置时最高频的低级错误。max_tokens只截断输出不影响输入长度输入超窗口是被num_ctx截的两个概念别混。stream打开后R1 的思考内容会先流式吐出来前端如果没做状态处理用户会看到一大段「自言自语」然后才出正文体验很像上一个时代的打字机。服务默认只监听127.0.0.1同一局域网的其他设备访问不到。要放开Linux 改 systemd 单元的环境变量macOS 用 launchctl 注入改完必须重启进程——只改配置文件不重启是白改。# Linux追加环境变量后重载执行器 sudo systemctl edit ollama.service # 在打开的编辑器里写入 # [Service] # EnvironmentOLLAMA_HOST0.0.0.0:11434 # EnvironmentOLLAMA_KEEP_ALIVE30m sudo systemctl daemon-reload sudo systemctl restart ollama # 验证监听地址别只看进程在不在 ss -lntp | grep 11434OLLAMA_KEEP_ALIVE控制模型在内存里待多久默认 5 分钟超时后卸载下一个请求要重新加载冷启动几秒到几十秒不等这也是「第一次慢第二次快」的成因。OLLAMA_MAX_LOADED_MODELS默认只留一个模型多模型来回切会反复换出反而更慢。放开监听之后任何能连上这台机器的人都能免费用你的算力内网也一样——鉴权放到反向代理层做别裸奔。3. Open WebUI 加 Docker把终端对话变成同事能点开的网页3.1 容器化选型为什么不直接 pip installOpen WebUI 支持 pip 安装但它的依赖链重——前后端同仓、前端需要构建产物、还要连数据库和向量库。本机 pip 装升级一次就可能把 Python 环境污染掉回滚很痛苦。官方主推的路径是容器镜像环境隔离、数据卷独立、升级只换镜像标签这是我选 Docker 的核心原因。它和 Ollama 是分工关系不替代Ollama 负责推理Open WebUI 负责账号、会话历史、文件上传、模型切换这些事情。两者可以跑在同一台机器上也可以分开。容器方案唯一的额外认知成本是网络命名空间——容器里的localhost是容器自己不是宿主机这个点坑掉的人比想象中多。数据落盘也要提前确认容器的/app/backend/data里存着 SQLite 数据库、上传的文档和向量索引不挂卷的话删容器等于清空所有会话。这个后悔药我吃过一次之后每个部署都先把卷命名写死。3.2 docker run 与 compose 两套起法先确认 Docker Desktop 或 Docker Engine 在跑再拉镜像。下面是单条命令的起法适合快速验证# 拉取 Open WebUI 主镜像 docker pull ghcr.io/open-webui/open-webui:main # 起容器3000 是宿主机端口8080 是容器内端口 docker run -d \ --name open-webui \ --restart unless-stopped \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main # 看启动日志等出现 Uvicorn running 再访问 docker logs -f open-webui长期用的场景我一般直接上 compose参数可见、可版本管理services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - 3000:8080 extra_hosts: - host.docker.internal:host-gateway # Linux 上必须否则解析不到宿主机 environment: - OLLAMA_BASE_URLhttp://host.docker.internal:11434 volumes: - open-webui:/app/backend/data # 会话与知识库都在这 restart: unless-stopped volumes: open-webui:docker compose up -d docker compose logs -f --tail100参数逐个说清。-p 3000:8080左边是你在浏览器里敲的右边是镜像约定改左边不影响应用。--add-host和extra_hosts是同一件事的两种写法作用是把host.docker.internal解析到宿主机网关Linux 上不加这个容器里的localhost和host.docker.internal都指不到你宿主机上的 Ollama表现就是页面能开、模型列表空白。OLLAMA_BASE_URL写错了不会报错只会静静地连不上这是排查时第一个要看的东西。如果你的 Ollama 也跑在容器里就把两个服务放进同一个 compose 文件、同一个自定义网络OLLAMA_BASE_URL改成http://ollama:11434服务名即主机名彻底绕开 host-gateway 的麻烦。3.3 登录、模型列表刷新与数据落盘第一次访问http://机器IP:3000会进入注册页注册的第一个账号自动成为管理员后面所有人的账号由它审批。这个细节要提前告诉同事否则一堆人抢着注册。登录后在设置里能看到连接状态模型下拉框应该列出你ollama list里已有的模型。模型列表空的情况分两种。一种是连接没通设置页的 Ollama 地址那里会显示红字或加载失败另一种是连接通了但没有模型那就是还没ollama pull。前者去容器里执行curl http://host.docker.internal:11434/api/tags验证能返回 JSON 就说明网络通、问题在页面配置。# 在容器内部验证到 Ollama 的连通性这一步比看页面日志直接 docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags # 确认数据卷挂载位置与会话文件是否落盘 docker inspect open-webui --format {{range .Mounts}}{{.Name}} - {{.Destination}}{{\n}}{{end}} docker exec -it open-webui ls -lh /app/backend/data数据卷里最重要的是webui.dbSQLite会话、用户、配置都在里面上传的文档和向量库另有目录。备份就是停容器、把卷打 tar 包或者在页面里导出会话。升级镜像之前先备份这句是血泪经验——镜像标签跟着main走某次升级改了数据库结构回退旧镜像就打不开了。3.4 多用户与反向代理的边界内网几个人用上面这套就够了。一旦要放到公网或者跨网段访问边界问题就冒出来Open WebUI 默认的注册是开放的谁先注册谁是管理员这条规则在公网等于把钥匙挂在门上。稳妥的做法是提前关掉开放注册、手动建号或者在前面加一层带鉴权的反向代理。反向代理要处理三件事WebSocket 升级流式输出依赖它、请求体大小上传文档会超默认限制、超时时间长推理容易断。Nginx 侧常见的配置是给/位置加proxy_set_header Upgrade $http_upgrade和proxy_read_timeout 300sclient_max_body_size放到 50M 以上。Caddy 省事一些反代和证书两行配置搞定。另外提醒一句Open WebUI 的账号体系和 Ollama 本体是两套东西。页面里登录了不代表 Ollama 那个 11434 端口有保护同网段任何人直接打 API 照样能白嫖算力。要么把 Ollama 绑回 127.0.0.1 只让容器访问要么在中间放一层带 token 的网关。这个认知错位在小团队里非常普遍。4. 移动端部署iPhone 快捷指令与 Android Termux 的真实差异4.1 iPhone 路线快捷指令本质是个 HTTP 客户端iOS 上不可能真的把 7B 权重跑在手机里所谓「iPhone 部署」其实是把手机做成一个远程客户端快捷指令负责拼 JSON、发请求、渲染结果。想清楚这点后面所有配置都是 HTTP 细节。最常见也最稳的做法是三条路径里的第二条在局域网内找一台常开的机器跑 Ollama前面套一层带 Bearer 鉴权的反向代理然后让快捷指令指向这个地址。快捷指令里用「获取 URL 内容」动作方法选 POST请求头加Content-Type: application/json和Authorization: Bearer 你的token请求体用 JSON{ model: deepseek-r1:7b, messages: [ {role: system, content: 回答控制在 100 字以内}, {role: user, content: 输入的问题} ], stream: false, temperature: 0.6 }关键点有三个。stream必须设成false快捷指令处理流式响应很别扭非流式一次拿完整 JSON 再取值最省事。路径要写全/v1/chat/completions只写 IP 和端口会 404。返回值用「获取字典值」取choices.1.message.content下标从 1 开始这是快捷指令的坑用 0 会取空。API Key 从哪来这是最需要泼冷水的地方。官方的开放平台接口是正路按量计费、有文档、有 SLA。网上流传的那些第三方中转店铺链接本质是别人转卖的额度便宜、开箱即用但同时意味着你的每一句提问都经过别人的服务器——限速、断供、跑路、日志留存都是现实风险涉密或客户数据千万别往里贴。我自己只用自建的那条路局域网 反向代理 固定 token出门在外用不了但数据不出门。首次运行快捷指令时系统会弹「允许访问本地网络」必须点允许否则请求直接被系统拦掉表现是一闪而过的失败没有任何错误码。这个坑没有报错信息只能靠记。4.2 Android 路线Termux 里编译 Ollama 的完整链路Android 理论上可以在本地跑模型前提是接受「小参数 慢」。Termux 提供一个类 Linux 环境能装 Go 工具链把 Ollama 从源码编出来。下面是完整链路命令按顺序执行# 1. 基础环境更新源、装编译依赖 pkg update pkg upgrade -y pkg install -y git cmake golang libjpeg-turbo # 2. 授予存储权限方便后面读模型和导出日志 termux-setup-storage # 3. 拉源码--depth 1 只取最新提交省流量省时间 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # 4. 生成代码并编译这一步在手机上要跑十几分钟 go generate ./... go build -o ollama . # 5. 后台起服务并验证 ./ollama serve sleep 3 curl -s http://127.0.0.1:11434/api/tags # 6. 只拉小参数模型手机内存扛不住 7B 以上 ./ollama pull deepseek-r1:1.5b ./ollama run deepseek-r1:1.5bgo generate ./...里的./...表示当前目录及所有子包漏了会编译失败go build -o ollama .的-o指定输出文件名不加就默认用目录名。termux-setup-storage是申请共享存储权限少了它后面无法读取下载目录里的文件。这条链路失败率不低我遇到的分三类。第一类是 Go 编译时内存被打爆手机剩 2G 内存基本别想go build会直接被系统杀掉日志里只有一句 Killed。第二类是缺后端依赖某些 GPU/NNAPI 相关的构建在 Android 上跑不通报找不到符号。第三类是编出来了但加载模型崩溃通常是内存不够。所以我的建议是先试预编译包pkg install ollama在较新的 Termux 源里已经有能装包就别自己编省下的时间够你调十次参数。装不上再走编译或者退一步用 llama.cpp 直接加载 GGUF 文件链路更短、依赖更少。这三条路的优先级别搞反了。跑起来之后的用法和桌面端一致ollama serve占着一个 Termux 会话切到另一个会话ollama run或者手机浏览器访问127.0.0.1:11434也行。注意 Termux 的localhost只在 Termux 内部有效其他 App 访问不到。4.3 手机端性能边界与保活手机跑模型的瓶颈不在算力峰值在持续输出和散热。1.5B 的 Q4 模型在 8G 内存的机器上能跑首 token 要等几秒之后每秒几个 token问长一点的问题要等半分钟。7B 在 8G 内存的 Android 上基本是奢望——系统本身占掉大半模型加载直接 OOM。温度上来之后降频很明显同一个问题前三次和第十次的耗时能差一倍。想跑长任务摘掉壳、别充电、放在凉的地方比调任何参数都有效。保活是另一个坎。Android 的后台管理会杀 Termux切出去几分钟回来服务就没了。Termux 里用termux-wake-lock申请唤醒锁再在系统设置里把 Termux 的电池优化关掉能撑住大部分场景。# 申请唤醒锁避免息屏后进程被冻结 termux-wake-lock # 用 nohup 挂后台日志落到文件方便回看崩溃原因 nohup ./ollama serve ollama.log 21 # 排查时先看端口在不在再看日志尾部 ss -lntp | grep 11434 tail -n 50 ollama.logiPhone 那条路的边界更清晰它完全不承担推理只负责展示所以性能问题变成了网络问题。局域网内延迟几十毫秒体验接近本地一旦离开那个网络就不可用这是架构决定的不是配置能绕过的。真要做移动场景的 NLP 应用正确姿势是服务端统一部署、移动端只做客户端而不是指望手机自己算。5. 避坑与排查五个真会卡住人的问题5.1 连接与服务监听类问题现象一终端里ollama run一切正常自己写的程序调 11434 却报 connection refused。原因基本是服务只监听在127.0.0.1或者ollama serve只跑在某个前台会话里、关掉终端就没了。解决分两步先确认监听地址ss -lntp | grep 11434看是127.0.0.1:11434还是0.0.0.0:11434再确认服务形态Linux 上应该由 systemd 托管Mac 上是常驻 App 或前台 serve。要跨机访问就把OLLAMA_HOST改成0.0.0.0:11434并重启进程改完再验一次端口。只改环境变量不重启是最常见的无效操作。现象二Open WebUI 页面能打开模型下拉框是空的日志里没有明显报错。原因是容器里的OLLAMA_BASE_URL指向了localhost或127.0.0.1而容器内的回环地址是容器自己不是宿主机。另一种可能是 Linux 上没加host-gateway域名解析不到。先docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags返回 JSON 说明网络通、问题在页面配置里报解析失败就补extra_hosts报连接拒绝说明 Ollama 没放开监听回到上一条。5.2 上下文与性能类问题现象三长文档喂进去模型回答跟原文对不上或者明显只处理了开头一段。原因是输入超过了num_ctx超出部分被静默截断没有任何报错。这是最阴的一类因为模型会给出一本正经的错误答案。处理方式是把num_ctx显式调到能覆盖输入的长度比如 8192 或 16384然后ollama ps看总占用是否还在显存内。放不下就得换小参数模型或者先做文本切分再喂。盲目写 128k 只会让 KV cache 把显存吃干净最后退化成 CPU 推理慢到无法使用。现象四第一次回答很慢第二次很快换个模型又变慢来回切时尤其明显。这是模型换出。OLLAMA_MAX_LOADED_MODELS默认只保留一个模型切换时会卸载上一个、加载下一个加载时间从几秒到几十秒不等。OLLAMA_KEEP_ALIVE默认 5 分钟超时也卸载。解决方法是把常用的那个模型固定住调大OLLAMA_KEEP_ALIVE或者在业务流程里只用一个模型、用 Modelfile 派生不同参数的变体来区分场景避免在模型名层面来回跳。5.3 容器与移动端的坑现象五Android 上编译 Ollama 到一半进程消失日志只有 Killed。原因是 Go 编译的峰值内存超过手机可用量被系统 OOM Killer 干掉了。这不是命令写错。解决顺序是先试pkg install ollama的预编译包不行就退到 llama.cpp 加载 GGUF非编不可就先关掉其他 App、清理后台并且别在编译时充电。编完了跑模型还要再过一次内存关1.5B 是安全线7B 以上别试。再补一个移动端的隐性问题iPhone 快捷指令第一次运行会请求本地网络权限拒绝之后不会有任何提示只是每次执行都失败。排查时先看系统设置里快捷指令的本地网络开关再抓请求。抓不到就用「显示提醒」动作把每一步的返回体打出来比猜快得多。6. 进阶量化档位怎么选以及一套二十分钟能跑完的验证模型能跑起来只是开始能不能稳定用在业务里取决于你有没有一套固定的验证动作。我一般分两步走先把量化档位和上下文定死再跑一轮固定题目的回归。量化档位不要迷信「越高越好」。Q4_K_M 是体积和质量的平衡点7B 到这个档位损失已经很小Q8_0 体积翻倍收益在短问答里基本感知不到除非你在做代码补全或长链条推理这种对精度敏感的任务。真要更高质量正确做法是升参数规模7B 换 14B而不是在同一规模上堆量化精度。上下文同理够用就行num_ctx每翻一倍KV cache 也翻一倍。KV cache 本身还能压缩。较新版本的 Ollama 支持通过OLLAMA_KV_CACHE_TYPEq8_0把缓存量化显存能省下一截代价是极长上下文下的一致性略降。这个开关在显存吃紧又必须开大窗口时特别有用但别默认开先用基线跑一遍再对比。验证手法不用复杂固定 20 条覆盖不同任务类型的问题短问答、长文档摘要、多步推理、代码改写跑一轮记录耗时和输出质量改完参数再跑一轮对比。速度数据直接从--verbose里拿# 每次运行结束会打印 eval rate 等统计重点看 tokens/s 和总耗时 ollama run deepseek-r1-8k --verbose 把下面这段日志里的错误码提取成 JSON... # 想批量验证用脚本循环打 API把耗时和输出都落盘 for i in $(seq 1 20); do start$(date %s%3N) curl -s http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {\model\:\deepseek-r1-8k\,\messages\:[{\role\:\user\,\content\:\用例 $i\}],\stream\:false} \ baseline.jsonl echo case $i: $(( $(date %s%3N) - start )) ms timing.log doneeval rate是生成速度prompt eval rate是预填充速度后者低说明输入太长或上下文开太大。两轮对比时只看相对值绝对值受机器状态影响。跑之前把机器上其他吃显存的程序关掉浏览器开着几个标签页都能让数据飘。还有一点常被忽略R1 这类带推理的模型temperature和输出长度要一起调。温度低但max_tokens太小推理链会被截在半路输出看起来像答到一半断了——很多人误以为是模型坏了。我一般把max_tokens设到预期正文长度的三倍以上宁可多花点时间。从那以后我每次换模型或改参数都强制走一遍这 20 条基线哪怕只是把num_ctx从 4096 调到 8192也比事后被同事问「怎么昨天还行今天就不对了」强。这套流程不复杂胜在每次都一样。希望帮到你。本文还有配套的精品资源点击获取
简介围绕多平台环境下DeepSeek模型部署的实用指南面向希望把大模型落到个人设备或业务流程中的开发者、研究人员与技术爱好者覆盖从本地终端到移动端、浏览器端的多种落地路径。压缩包内为1个docx文档大小约15KB篇幅精炼便于按平台查阅与复现。内容围绕Ollama在macOS、Linux、Windows上的安装、模型拉取与终端交互展开并延伸到iPhone快捷指令配置API Key、Android借助Termux安装依赖、编译并启动Ollama服务及运行DeepSeek-R1模型同时说明用Docker Desktop与Open WebUI搭建浏览器访问界面的思路。文中给出较明确的操作命令、配置要点和官方链接可帮助读者理解不同硬件与系统下的部署差异掌握环境准备、服务验证和常见环节排错方法。已有3772人学习适合需要快速上手多端部署实践的技术读者参考。1. 从一次三方需求说起终端调试、浏览器共用、手机随时问上个月帮一个做客服系统的朋友评估本地化方案诉求特别具体把 DeepSeek 模型部署在自己机器上白天在终端里调 prompt晚上让同事从浏览器点开就能用出差路上还想在手机上问两句。三件事分别指向 Ollama 本地部署、Docker 里的 Open WebUI以及移动端Mobile的两条绕法——iPhone 快捷指令和 Android Termux。这套组合真正的价值在于「跑得住」权重只存一份对外只露一个 11434 端口三种客户端复用同一个模型文件。哪一步没配对上症状长得几乎一样转圈、超时、答非所问。下面按路径拆先在本地把模型拉下来并算清显存账再用 Docker 起网页界面然后处理手机端最后把五类真会卡住人的坑和一套验证手法摆出来。7B 的运行环境与 70B 的运行环境读法完全不同。2. Ollama 本地部署从拉模型到 OpenAI 兼容接口2.1 选 Ollama 的理由把量化、显存、加载策略一起打包自己搭推理栈当然可以transformers 加 vLLM 或 llama.cpp 都行但那是另一个工作量模型量化要自己转 GGUF、GPU 层数要自己算、Mac 上的 Metal 和 Windows 上的 CUDA 要分别处理、模型加载和卸载要自己写调度。Ollama 把这几件事压成了一个二进制加一个 HTTP 服务代价是并发能力弱——默认同一时刻基本只服务一个推理请求多用户场景会排队。我一般这么判断单人或小团队、单机、消费级显卡或统一内存的 Mac用 Ollama 省下来的时间足够抵掉它的性能损失要做对外服务的多租户 NLP 应用那是 vLLM 的地盘别硬扛。Ollama 的另一个好处是模型即配置一个 Modelfile 就把权重、对话模板、采样参数捆在一起换上下文长度不用改代码。它的自动分层策略值得说清楚模型加载时按可用显存把 transformer 层尽量塞进 GPU塞不下的留在内存里走 CPU。ollama ps那列 PROCESSOR 显示的100% GPU、40/60 CPU/GPU就是这个分配结果它是判断「为什么慢」的第一手证据比看任务管理器靠谱得多。2.2 三平台安装与首次拉取模型Linux 和 macOS 用脚本装Windows 走安装包装完确认服务在跑再拉模型。# Linux官方脚本安装并自动注册 systemd 服务 curl -fsSL https://ollama.com/install.sh | sh # 确认服务状态与版本 systemctl status ollama --no-pager ollama --version # macOS 装完是常驻菜单栏 App命令行直接可用 brew install ollama ollama serve # 前台起服务调试期方便看日志 # 拉取模型pull 只下载run 会先 pull 再进交互 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b # 查看本地已有模型与运行中的模型 ollama list ollama ps# Windows PowerShell装完安装包后 Ollama 会常驻托盘 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b # 服务端口被占用或要改监听地址时先改用户环境变量再重启托盘程序 [Environment]::SetEnvironmentVariable(OLLAMA_HOST,0.0.0.0:11434,User)命令本身没什么玄学容易翻车的是三处。第一run和pull的区别要记住run在模型不存在时会自动下载下载过程只有进度条没有提示看起来像卡死实际在写盘。第二模型标签选错比装错更常见deepseek-r1下面从 1.5b 到 70b 是蒸馏版本671b 才是完整版671b 在个人设备上基本没有可运行的可能看到磁盘只剩 20G 还去拉 70b 就是自找。第三Mac 上的ollama serve和托盘 App 会抢 11434 端口报address already in use时先看菜单栏有没有那只羊驼图标。拉完之后先别急着接程序在终端里问一个带推理的问题确认输出正常。R1 系列在较新版本里会把思考过程单独放进thinking字段终端交互时用灰色块展示如果你的输出里混着...和正文说明走的是老版本或老模板后面接前端时要不要过滤得提前想好。2.3 算力账模型体积、显存与上下文的换算部署失败九成不是命令错是没算账。权重、KV cache、运行时开销三块要一起看下表是按 Q4_K_M 量化Ollama 默认档位的粗略值实际以ollama ps的 SIZE 列为准。模型标签参数量权重大小约建议可用显存/内存典型感受deepseek-r1:1.5b1.5B1.1 GB4 GB笔记本轻量可用复杂推理偏弱deepseek-r1:7b7B4.7 GB8 GB单机甜点位8G 显卡刚好deepseek-r1:8b8B4.9 GB8 GB与 7b 差别不大看底座适配deepseek-r1:14b14B9 GB16 GB长文档摘要开始有明显提升deepseek-r1:32b32B20 GB24 GB24G 显卡的分水岭deepseek-r1:70b70B43 GB48 GB需要大显存或多卡或接受 CPU 降速权重之外KV cache 是第二个吃显存的大户而且它随上下文长度线性涨。Ollama 里num_ctx是每个请求可用的上下文窗口默认值通常在 2K4K 量级很多人抱怨「长文档一进去就答非所问」本质是超长部分被悄悄截断了根本没有进入模型。想把窗口拉到 8192 或 16384得先估算 KV cache 是否放得下别闭着眼睛写 128k。要做固定配置用 Modelfile 派生子模型比每次请求传参稳定# 基于已有的 7b 派生一个上下文 8K 的变体 cat Modelfile EOF FROM deepseek-r1:7b PARAMETER num_ctx 8192 PARAMETER temperature 0.6 EOF ollama create deepseek-r1-8k -f Modelfile ollama run deepseek-r1-8kFROM指定底座num_ctx是窗口temperature对 R1 这类推理模型来说 0.50.7 比较稳调高会让推理链条发散、答非所问的概率上升。派生出来的模型和底座共享权重层磁盘不会翻倍但加载时按新参数走。改完用ollama show deepseek-r1-8k --modelfile回看确认参数真的写进去了。2.4 把 11434 端口变成 OpenAI 兼容接口Ollama 自带两套 API原生的/api/chat、/api/generate和 OpenAI 兼容的/v1/chat/completions。后者是接入现成工具的关键绝大多数客户端只认这一套。# 原生接口/api/chat返回结构里带 thinking 与统计字段 curl http://127.0.0.1:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 用两句话说明 inode 耗尽的现象}], stream: false } # OpenAI 兼容接口路径多了 /v1key 随便填Ollama 不校验 curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer ollama \ -d {model:deepseek-r1:7b,messages:[{role:user,content:你好}],stream:false}Python 侧直接用 openai SDK 就能接不用改任何业务代码结构from openai import OpenAI # api_key 是占位符Ollama 不做鉴权但 SDK 要求非空 client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keyollama) resp client.chat.completions.create( modeldeepseek-r1:7b, messages[ {role: system, content: 你是运维助手回答控制在三句话内}, {role: user, content: 磁盘 inode 用满了会有什么现象}, ], temperature0.6, # 推理模型建议 0.5~0.7 max_tokens512, # 只是上限不是消耗量 streamFalse, ) print(resp.choices[0].message.content)三个参数最容易被误用。base_url结尾一定要带/v1漏了会 404这是移动端和网页端配置时最高频的低级错误。max_tokens只截断输出不影响输入长度输入超窗口是被num_ctx截的两个概念别混。stream打开后R1 的思考内容会先流式吐出来前端如果没做状态处理用户会看到一大段「自言自语」然后才出正文体验很像上一个时代的打字机。服务默认只监听127.0.0.1同一局域网的其他设备访问不到。要放开Linux 改 systemd 单元的环境变量macOS 用 launchctl 注入改完必须重启进程——只改配置文件不重启是白改。# Linux追加环境变量后重载执行器 sudo systemctl edit ollama.service # 在打开的编辑器里写入 # [Service] # EnvironmentOLLAMA_HOST0.0.0.0:11434 # EnvironmentOLLAMA_KEEP_ALIVE30m sudo systemctl daemon-reload sudo systemctl restart ollama # 验证监听地址别只看进程在不在 ss -lntp | grep 11434OLLAMA_KEEP_ALIVE控制模型在内存里待多久默认 5 分钟超时后卸载下一个请求要重新加载冷启动几秒到几十秒不等这也是「第一次慢第二次快」的成因。OLLAMA_MAX_LOADED_MODELS默认只留一个模型多模型来回切会反复换出反而更慢。放开监听之后任何能连上这台机器的人都能免费用你的算力内网也一样——鉴权放到反向代理层做别裸奔。3. Open WebUI 加 Docker把终端对话变成同事能点开的网页3.1 容器化选型为什么不直接 pip installOpen WebUI 支持 pip 安装但它的依赖链重——前后端同仓、前端需要构建产物、还要连数据库和向量库。本机 pip 装升级一次就可能把 Python 环境污染掉回滚很痛苦。官方主推的路径是容器镜像环境隔离、数据卷独立、升级只换镜像标签这是我选 Docker 的核心原因。它和 Ollama 是分工关系不替代Ollama 负责推理Open WebUI 负责账号、会话历史、文件上传、模型切换这些事情。两者可以跑在同一台机器上也可以分开。容器方案唯一的额外认知成本是网络命名空间——容器里的localhost是容器自己不是宿主机这个点坑掉的人比想象中多。数据落盘也要提前确认容器的/app/backend/data里存着 SQLite 数据库、上传的文档和向量索引不挂卷的话删容器等于清空所有会话。这个后悔药我吃过一次之后每个部署都先把卷命名写死。3.2 docker run 与 compose 两套起法先确认 Docker Desktop 或 Docker Engine 在跑再拉镜像。下面是单条命令的起法适合快速验证# 拉取 Open WebUI 主镜像 docker pull ghcr.io/open-webui/open-webui:main # 起容器3000 是宿主机端口8080 是容器内端口 docker run -d \ --name open-webui \ --restart unless-stopped \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main # 看启动日志等出现 Uvicorn running 再访问 docker logs -f open-webui长期用的场景我一般直接上 compose参数可见、可版本管理services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - 3000:8080 extra_hosts: - host.docker.internal:host-gateway # Linux 上必须否则解析不到宿主机 environment: - OLLAMA_BASE_URLhttp://host.docker.internal:11434 volumes: - open-webui:/app/backend/data # 会话与知识库都在这 restart: unless-stopped volumes: open-webui:docker compose up -d docker compose logs -f --tail100参数逐个说清。-p 3000:8080左边是你在浏览器里敲的右边是镜像约定改左边不影响应用。--add-host和extra_hosts是同一件事的两种写法作用是把host.docker.internal解析到宿主机网关Linux 上不加这个容器里的localhost和host.docker.internal都指不到你宿主机上的 Ollama表现就是页面能开、模型列表空白。OLLAMA_BASE_URL写错了不会报错只会静静地连不上这是排查时第一个要看的东西。如果你的 Ollama 也跑在容器里就把两个服务放进同一个 compose 文件、同一个自定义网络OLLAMA_BASE_URL改成http://ollama:11434服务名即主机名彻底绕开 host-gateway 的麻烦。3.3 登录、模型列表刷新与数据落盘第一次访问http://机器IP:3000会进入注册页注册的第一个账号自动成为管理员后面所有人的账号由它审批。这个细节要提前告诉同事否则一堆人抢着注册。登录后在设置里能看到连接状态模型下拉框应该列出你ollama list里已有的模型。模型列表空的情况分两种。一种是连接没通设置页的 Ollama 地址那里会显示红字或加载失败另一种是连接通了但没有模型那就是还没ollama pull。前者去容器里执行curl http://host.docker.internal:11434/api/tags验证能返回 JSON 就说明网络通、问题在页面配置。# 在容器内部验证到 Ollama 的连通性这一步比看页面日志直接 docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags # 确认数据卷挂载位置与会话文件是否落盘 docker inspect open-webui --format {{range .Mounts}}{{.Name}} - {{.Destination}}{{\n}}{{end}} docker exec -it open-webui ls -lh /app/backend/data数据卷里最重要的是webui.dbSQLite会话、用户、配置都在里面上传的文档和向量库另有目录。备份就是停容器、把卷打 tar 包或者在页面里导出会话。升级镜像之前先备份这句是血泪经验——镜像标签跟着main走某次升级改了数据库结构回退旧镜像就打不开了。3.4 多用户与反向代理的边界内网几个人用上面这套就够了。一旦要放到公网或者跨网段访问边界问题就冒出来Open WebUI 默认的注册是开放的谁先注册谁是管理员这条规则在公网等于把钥匙挂在门上。稳妥的做法是提前关掉开放注册、手动建号或者在前面加一层带鉴权的反向代理。反向代理要处理三件事WebSocket 升级流式输出依赖它、请求体大小上传文档会超默认限制、超时时间长推理容易断。Nginx 侧常见的配置是给/位置加proxy_set_header Upgrade $http_upgrade和proxy_read_timeout 300sclient_max_body_size放到 50M 以上。Caddy 省事一些反代和证书两行配置搞定。另外提醒一句Open WebUI 的账号体系和 Ollama 本体是两套东西。页面里登录了不代表 Ollama 那个 11434 端口有保护同网段任何人直接打 API 照样能白嫖算力。要么把 Ollama 绑回 127.0.0.1 只让容器访问要么在中间放一层带 token 的网关。这个认知错位在小团队里非常普遍。4. 移动端部署iPhone 快捷指令与 Android Termux 的真实差异4.1 iPhone 路线快捷指令本质是个 HTTP 客户端iOS 上不可能真的把 7B 权重跑在手机里所谓「iPhone 部署」其实是把手机做成一个远程客户端快捷指令负责拼 JSON、发请求、渲染结果。想清楚这点后面所有配置都是 HTTP 细节。最常见也最稳的做法是三条路径里的第二条在局域网内找一台常开的机器跑 Ollama前面套一层带 Bearer 鉴权的反向代理然后让快捷指令指向这个地址。快捷指令里用「获取 URL 内容」动作方法选 POST请求头加Content-Type: application/json和Authorization: Bearer 你的token请求体用 JSON{ model: deepseek-r1:7b, messages: [ {role: system, content: 回答控制在 100 字以内}, {role: user, content: 输入的问题} ], stream: false, temperature: 0.6 }关键点有三个。stream必须设成false快捷指令处理流式响应很别扭非流式一次拿完整 JSON 再取值最省事。路径要写全/v1/chat/completions只写 IP 和端口会 404。返回值用「获取字典值」取choices.1.message.content下标从 1 开始这是快捷指令的坑用 0 会取空。API Key 从哪来这是最需要泼冷水的地方。官方的开放平台接口是正路按量计费、有文档、有 SLA。网上流传的那些第三方中转店铺链接本质是别人转卖的额度便宜、开箱即用但同时意味着你的每一句提问都经过别人的服务器——限速、断供、跑路、日志留存都是现实风险涉密或客户数据千万别往里贴。我自己只用自建的那条路局域网 反向代理 固定 token出门在外用不了但数据不出门。首次运行快捷指令时系统会弹「允许访问本地网络」必须点允许否则请求直接被系统拦掉表现是一闪而过的失败没有任何错误码。这个坑没有报错信息只能靠记。4.2 Android 路线Termux 里编译 Ollama 的完整链路Android 理论上可以在本地跑模型前提是接受「小参数 慢」。Termux 提供一个类 Linux 环境能装 Go 工具链把 Ollama 从源码编出来。下面是完整链路命令按顺序执行# 1. 基础环境更新源、装编译依赖 pkg update pkg upgrade -y pkg install -y git cmake golang libjpeg-turbo # 2. 授予存储权限方便后面读模型和导出日志 termux-setup-storage # 3. 拉源码--depth 1 只取最新提交省流量省时间 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # 4. 生成代码并编译这一步在手机上要跑十几分钟 go generate ./... go build -o ollama . # 5. 后台起服务并验证 ./ollama serve sleep 3 curl -s http://127.0.0.1:11434/api/tags # 6. 只拉小参数模型手机内存扛不住 7B 以上 ./ollama pull deepseek-r1:1.5b ./ollama run deepseek-r1:1.5bgo generate ./...里的./...表示当前目录及所有子包漏了会编译失败go build -o ollama .的-o指定输出文件名不加就默认用目录名。termux-setup-storage是申请共享存储权限少了它后面无法读取下载目录里的文件。这条链路失败率不低我遇到的分三类。第一类是 Go 编译时内存被打爆手机剩 2G 内存基本别想go build会直接被系统杀掉日志里只有一句 Killed。第二类是缺后端依赖某些 GPU/NNAPI 相关的构建在 Android 上跑不通报找不到符号。第三类是编出来了但加载模型崩溃通常是内存不够。所以我的建议是先试预编译包pkg install ollama在较新的 Termux 源里已经有能装包就别自己编省下的时间够你调十次参数。装不上再走编译或者退一步用 llama.cpp 直接加载 GGUF 文件链路更短、依赖更少。这三条路的优先级别搞反了。跑起来之后的用法和桌面端一致ollama serve占着一个 Termux 会话切到另一个会话ollama run或者手机浏览器访问127.0.0.1:11434也行。注意 Termux 的localhost只在 Termux 内部有效其他 App 访问不到。4.3 手机端性能边界与保活手机跑模型的瓶颈不在算力峰值在持续输出和散热。1.5B 的 Q4 模型在 8G 内存的机器上能跑首 token 要等几秒之后每秒几个 token问长一点的问题要等半分钟。7B 在 8G 内存的 Android 上基本是奢望——系统本身占掉大半模型加载直接 OOM。温度上来之后降频很明显同一个问题前三次和第十次的耗时能差一倍。想跑长任务摘掉壳、别充电、放在凉的地方比调任何参数都有效。保活是另一个坎。Android 的后台管理会杀 Termux切出去几分钟回来服务就没了。Termux 里用termux-wake-lock申请唤醒锁再在系统设置里把 Termux 的电池优化关掉能撑住大部分场景。# 申请唤醒锁避免息屏后进程被冻结 termux-wake-lock # 用 nohup 挂后台日志落到文件方便回看崩溃原因 nohup ./ollama serve ollama.log 21 # 排查时先看端口在不在再看日志尾部 ss -lntp | grep 11434 tail -n 50 ollama.logiPhone 那条路的边界更清晰它完全不承担推理只负责展示所以性能问题变成了网络问题。局域网内延迟几十毫秒体验接近本地一旦离开那个网络就不可用这是架构决定的不是配置能绕过的。真要做移动场景的 NLP 应用正确姿势是服务端统一部署、移动端只做客户端而不是指望手机自己算。5. 避坑与排查五个真会卡住人的问题5.1 连接与服务监听类问题现象一终端里ollama run一切正常自己写的程序调 11434 却报 connection refused。原因基本是服务只监听在127.0.0.1或者ollama serve只跑在某个前台会话里、关掉终端就没了。解决分两步先确认监听地址ss -lntp | grep 11434看是127.0.0.1:11434还是0.0.0.0:11434再确认服务形态Linux 上应该由 systemd 托管Mac 上是常驻 App 或前台 serve。要跨机访问就把OLLAMA_HOST改成0.0.0.0:11434并重启进程改完再验一次端口。只改环境变量不重启是最常见的无效操作。现象二Open WebUI 页面能打开模型下拉框是空的日志里没有明显报错。原因是容器里的OLLAMA_BASE_URL指向了localhost或127.0.0.1而容器内的回环地址是容器自己不是宿主机。另一种可能是 Linux 上没加host-gateway域名解析不到。先docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags返回 JSON 说明网络通、问题在页面配置里报解析失败就补extra_hosts报连接拒绝说明 Ollama 没放开监听回到上一条。5.2 上下文与性能类问题现象三长文档喂进去模型回答跟原文对不上或者明显只处理了开头一段。原因是输入超过了num_ctx超出部分被静默截断没有任何报错。这是最阴的一类因为模型会给出一本正经的错误答案。处理方式是把num_ctx显式调到能覆盖输入的长度比如 8192 或 16384然后ollama ps看总占用是否还在显存内。放不下就得换小参数模型或者先做文本切分再喂。盲目写 128k 只会让 KV cache 把显存吃干净最后退化成 CPU 推理慢到无法使用。现象四第一次回答很慢第二次很快换个模型又变慢来回切时尤其明显。这是模型换出。OLLAMA_MAX_LOADED_MODELS默认只保留一个模型切换时会卸载上一个、加载下一个加载时间从几秒到几十秒不等。OLLAMA_KEEP_ALIVE默认 5 分钟超时也卸载。解决方法是把常用的那个模型固定住调大OLLAMA_KEEP_ALIVE或者在业务流程里只用一个模型、用 Modelfile 派生不同参数的变体来区分场景避免在模型名层面来回跳。5.3 容器与移动端的坑现象五Android 上编译 Ollama 到一半进程消失日志只有 Killed。原因是 Go 编译的峰值内存超过手机可用量被系统 OOM Killer 干掉了。这不是命令写错。解决顺序是先试pkg install ollama的预编译包不行就退到 llama.cpp 加载 GGUF非编不可就先关掉其他 App、清理后台并且别在编译时充电。编完了跑模型还要再过一次内存关1.5B 是安全线7B 以上别试。再补一个移动端的隐性问题iPhone 快捷指令第一次运行会请求本地网络权限拒绝之后不会有任何提示只是每次执行都失败。排查时先看系统设置里快捷指令的本地网络开关再抓请求。抓不到就用「显示提醒」动作把每一步的返回体打出来比猜快得多。6. 进阶量化档位怎么选以及一套二十分钟能跑完的验证模型能跑起来只是开始能不能稳定用在业务里取决于你有没有一套固定的验证动作。我一般分两步走先把量化档位和上下文定死再跑一轮固定题目的回归。量化档位不要迷信「越高越好」。Q4_K_M 是体积和质量的平衡点7B 到这个档位损失已经很小Q8_0 体积翻倍收益在短问答里基本感知不到除非你在做代码补全或长链条推理这种对精度敏感的任务。真要更高质量正确做法是升参数规模7B 换 14B而不是在同一规模上堆量化精度。上下文同理够用就行num_ctx每翻一倍KV cache 也翻一倍。KV cache 本身还能压缩。较新版本的 Ollama 支持通过OLLAMA_KV_CACHE_TYPEq8_0把缓存量化显存能省下一截代价是极长上下文下的一致性略降。这个开关在显存吃紧又必须开大窗口时特别有用但别默认开先用基线跑一遍再对比。验证手法不用复杂固定 20 条覆盖不同任务类型的问题短问答、长文档摘要、多步推理、代码改写跑一轮记录耗时和输出质量改完参数再跑一轮对比。速度数据直接从--verbose里拿# 每次运行结束会打印 eval rate 等统计重点看 tokens/s 和总耗时 ollama run deepseek-r1-8k --verbose 把下面这段日志里的错误码提取成 JSON... # 想批量验证用脚本循环打 API把耗时和输出都落盘 for i in $(seq 1 20); do start$(date %s%3N) curl -s http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {\model\:\deepseek-r1-8k\,\messages\:[{\role\:\user\,\content\:\用例 $i\}],\stream\:false} \ baseline.jsonl echo case $i: $(( $(date %s%3N) - start )) ms timing.log doneeval rate是生成速度prompt eval rate是预填充速度后者低说明输入太长或上下文开太大。两轮对比时只看相对值绝对值受机器状态影响。跑之前把机器上其他吃显存的程序关掉浏览器开着几个标签页都能让数据飘。还有一点常被忽略R1 这类带推理的模型temperature和输出长度要一起调。温度低但max_tokens太小推理链会被截在半路输出看起来像答到一半断了——很多人误以为是模型坏了。我一般把max_tokens设到预期正文长度的三倍以上宁可多花点时间。从那以后我每次换模型或改参数都强制走一遍这 20 条基线哪怕只是把num_ctx从 4096 调到 8192也比事后被同事问「怎么昨天还行今天就不对了」强。这套流程不复杂胜在每次都一样。希望帮到你。本文还有配套的精品资源点击获取
