简介：围绕多平台环境下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 列为准。

权重之外，KV cache 是第二个吃显存的大户，而且它随上下文长度线性涨。Ollama 里num_ctx是每个请求可用的上下文窗口，默认值通常在 2K～4K 量级，很多人抱怨「长文档一进去就答非所问」，本质是超长部分被悄悄截断了，根本没有进入模型。想把窗口拉到 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-8k

FROM指定底座，num_ctx是窗口，temperature对 R1 这类推理模型来说 0.5～0.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 兼容接口：路径多了 /v1，key 随便填，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_url="http://127.0.0.1:11434/v1", api_key="ollama") resp = client.chat.completions.create( model="deepseek-r1:7b", messages=[ {"role": "system", "content": "你是运维助手，回答控制在三句话内"}, {"role": "user", "content": "磁盘 inode 用满了会有什么现象"}, ], temperature=0.6, # 推理模型建议 0.5~0.7 max_tokens=512, # 只是上限，不是消耗量 stream=False, ) 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] # Environment="OLLAMA_HOST=0.0.0.0:11434" # Environment="OLLAMA_KEEP_ALIVE=30m" sudo systemctl daemon-reload && sudo systemctl restart ollama # 验证监听地址，别只看进程在不在 ss -lntp | grep 11434

OLLAMA_KEEP_ALIVE控制模型在内存里待多久，默认 5 分钟，超时后卸载，下一个请求要重新加载，冷启动几秒到几十秒不等，这也是「第一次慢第二次快」的成因。OLLAMA_MAX_LOADED_MODELS默认只留一个模型，多模型来回切会反复换出，反而更慢。放开监听之后，任何能连上这台机器的人都能免费用你的算力，内网也一样——鉴权放到反向代理层做，别裸奔。

3. Open WebUI 加 Docker：把终端对话变成同事能点开的网页

3.1 容器化选型：为什么不直接 pip install

Open 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-host=host.docker.internal:host-gateway \ -e OLLAMA_BASE_URL=http://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_URL=http://host.docker.internal:11434 volumes: - open-webui:/app/backend/data # 会话与知识库都在这 restart: unless-stopped volumes: open-webui:

docker compose up -d docker compose logs -f --tail=100

参数逐个说清。-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.db（SQLite），会话、用户、配置都在里面；上传的文档和向量库另有目录。备份就是停容器、把卷打 tar 包，或者在页面里导出会话。升级镜像之前先备份，这句是血泪经验——镜像标签跟着main走，某次升级改了数据库结构，回退旧镜像就打不开了。

3.4 多用户与反向代理的边界

内网几个人用，上面这套就够了。一旦要放到公网或者跨网段访问，边界问题就冒出来：Open WebUI 默认的注册是开放的，谁先注册谁是管理员这条规则在公网等于把钥匙挂在门上。稳妥的做法是提前关掉开放注册、手动建号，或者在前面加一层带鉴权的反向代理。

反向代理要处理三件事：WebSocket 升级（流式输出依赖它）、请求体大小（上传文档会超默认限制）、超时时间（长推理容易断）。Nginx 侧常见的配置是给/位置加proxy_set_header Upgrade $http_upgrade和proxy_read_timeout 300s，client_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.5b

go 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 2>&1 & # 排查时先看端口在不在，再看日志尾部 ss -lntp | grep 11434 tail -n 50 ollama.log

iPhone 那条路的边界更清晰：它完全不承担推理，只负责展示，所以性能问题变成了网络问题。局域网内延迟几十毫秒，体验接近本地；一旦离开那个网络就不可用，这是架构决定的，不是配置能绕过的。真要做移动场景的 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_TYPE=q8_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 done

eval rate是生成速度，prompt eval rate是预填充速度，后者低说明输入太长或上下文开太大。两轮对比时只看相对值，绝对值受机器状态影响。跑之前把机器上其他吃显存的程序关掉，浏览器开着几个标签页都能让数据飘。

还有一点常被忽略：R1 这类带推理的模型，temperature和输出长度要一起调。温度低但max_tokens太小，推理链会被截在半路，输出看起来像答到一半断了——很多人误以为是模型坏了。我一般把max_tokens设到预期正文长度的三倍以上，宁可多花点时间。

从那以后我每次换模型或改参数，都强制走一遍这 20 条基线，哪怕只是把num_ctx从 4096 调到 8192，也比事后被同事问「怎么昨天还行今天就不对了」强。这套流程不复杂，胜在每次都一样。希望帮到你。

本文还有配套的精品资源，点击获取