DeepSeek R1 本地部署全路线：Ollama、移动端与 Web 界面实战

简介《DeepSeek多平台部署指南》是一份面向开发人员、技术爱好者及企业技术人员的实践型文档围绕深度学习模型在本地电脑、手机端和 Open WebUI 环境中的部署展开兼顾个人研究、教学演示与业务集成等场景。文档共1个 docx 文件压缩包约15KB篇幅紧凑便于作为模型部署流程的速查与入门参考内容涉及机器学习、自然语言处理、Docker 等技术点并覆盖 Ollama 本地运行、iPhone 快捷指令、Android Termux 与 Open WebUI 等不同实现路径。已有1521人学习说明其在多平台部署主题上具备一定的参考价值。读者可从中了解不同设备与工具组合下的部署思路、关键环节、环境准备要点和常见问题的处理方向尤其适合希望快速建立 DeepSeek 多端部署认知、再按自身设备条件选择方案的技术人员也可为后续模型应用集成提供基础参照。1. DeepSeek 模型部署的三条路线先想清楚你要在哪台机器上跑很多人第一次接触 DeepSeek 部署是在一台内存 16G 的轻薄本上照着命令敲ollama run然后盯着进度条等二十分钟最后发现模型跑起来了但每秒钟只吐两三个字。问题不在命令写错了而在路线选错了。DeepSeek 的部署大致分三条路一是基于 Ollama 的本地部署模型权重落在你自己的磁盘上断网可用、数据不出机器二是手机端Android 靠 Termux 把 Ollama 编译出来iPhone 走快捷指令调远端 API三是 Open WebUI 加 Docker把模型包装成一个多人可用的 Web 界面。三条路的技术栈、硬件门槛和适用人群完全不同选错了后面全是无用功。这篇笔记按「本地跑通 → 移动端兜底 → Web 界面封装 → 踩坑排查 → 进阶调优」的顺序拆面向的是想把自然语言处理能力真正落到自己项目里的开发者和技术爱好者。模型部署这件事机器学习和深度学习背景能帮你理解量化与显存的关系但真正让你少走弯路的是对操作系统、编译链和容器网络的理解。2. Ollama 本地部署模型标签、量化等级与 API 暴露的三个决策点Ollama 的价值在于它把 llama.cpp 那一套推理后端、模型格式转换、显存分配全部封装掉了你只需要一条ollama run。但封装得越厚出问题时越像黑匣子。所以这一章不只给命令还把每条命令背后在做的事拆开讲清楚你才知道失败时该看哪里。2.1 装之前先量三件事内存、磁盘、显卡很多人跳过这一步直接装结果拉到一半磁盘满了或者模型加载时报 OOM。装 Ollama 之前先把三个数确认一遍。第一是可用内存模型加载时权重会整块进内存或显存7B 参数在 4-bit 量化下大约需要 4~5 GB再留出 KV Cache 和系统开销16 GB 内存的机器跑 7B 是舒服的跑 14B 就紧张了。第二是磁盘剩余空间Ollama 默认把模型放在用户目录下的.ollama/models一个 7B 量化模型单文件就是几个 GB多拉几个标签很容易吃掉几十 GB。第三是有没有独立显卡有 CUDA 或 Metal 的话推理速度是数量级的差别。下面这张表是我自己在选标签时的对照参数量和量化等级决定了你到底能不能跑标签示例参数量量化后体积量级建议最低内存典型场景deepseek-r1:1.5b1.5B1~2 GB8 GB手机端、低配本、快速验证deepseek-r1:7b7B4~5 GB16 GB日常问答、代码补全deepseek-r1:8b8B5~6 GB16~24 GB比 7b 略强的通用任务deepseek-r1:14b14B9~10 GB32 GB复杂推理需显卡更稳deepseek-r1:32b32B20 GB 上下64 GB 或 24G 显存高质量推理工作站级这张表里的体积是量级估算具体会随量化方式浮动。判断标准很简单模型体积乘以 1.2 到 1.5就是你实际需要腾出来的内存余量。低于这个数加载阶段就会开始报错或者疯狂走 swap表现为「模型加载成功但生成极慢」这是最容易被误判成「模型不行」的情况。2.2 拉取与交互ollama run到底做了什么确认硬件够用之后装 Ollama 本身没什么技术含量官网下载对应平台的安装包macOS 和 Windows 双击Linux 走一条安装脚本。装完先确认两件事可执行文件在 PATH 里后台服务已经起来。# 1) 确认版本同时验证 PATH 配置正确 ollama --version # 2) 确认本地服务已经监听默认端口 11434 curl http://127.0.0.1:11434 # 3) 首次拉取并进入交互式对话模型不存在时会自动下载 ollama run deepseek-r1:7b # 4) 已经拉过的模型第二条命令直接进交互不再下载 ollama run deepseek-r1:7b第三条命令的执行过程值得说清楚因为它是新手最容易困惑的地方。ollama run实际上做了三件事检查本地有没有deepseek-r1:7b这个标签对应的模型清单没有就去远端仓库拉取 manifest 和分层 blob下载完成后做完整性校验然后启动一个推理会话把终端接到标准输入输出上。所以第一次运行时你会看到分段下载的进度条之后再用就是秒开。如果中途 CtrlC 打断下次会续传已下载的分层不会从头来过。第四条命令的curl返回的是纯文本Ollama is running不是 JSON也不是版本号。这一点在原文里被描述成「返回版本信息」实际排查时如果你预期看到 JSON 就会误以为服务没起来。想拿版本号应该用ollama --version想验证服务活着就用上面这条 curl。交互模式里还有几个隐含行为要知道。输入/bye退出/clear清空上下文/show info看当前模型的参数和量化信息。上下文默认长度有限长文档问答时如果发现模型「记不住前面说的话」大概率是 num_ctx 太小这个在第六章用 Modelfile 固化。2.3 标签写错是最高频的翻车点模型标签的格式是模型名:标签冒号后面那部分是 tag。DeepSeek R1 系列的官方标签是deepseek-r1中间带连字符。很多教程和口口相传的版本会写成deepseekr1:8b或者deepseek_r1:7b这两种写法在 Ollama 的模型库里查不到对应条目直接报pull model manifest: file does not exist或者not found。血泪经验是报这个错的时候八成不是你网络有问题是名字写错了。正确的做法是先查再拉# 列出本地已有的模型确认标签拼写 ollama list # 想看某个模型的具体信息参数量、量化方式、模板 ollama show deepseek-r1:7b # 查看运行中的模型和它们占用的资源 ollama psollama ps这条命令在调试时特别有用它会告诉你模型是跑在 GPU 上还是 CPU 上以及卸载倒计时。如果你发现明明有显卡但模型显示 100% CPU那就是驱动或者 CUDA 运行时没被识别到跟模型本身无关。还有一个容易被忽略的点7b和8b是两个不同的标签对应不同来源的权重不是同一个模型的不同精度。有人在这两个之间反复横跳觉得 8b 应该比 7b 强一点点实际上它们的推理风格、上下文长度、模板都可能不同。选一个跑通、跑稳比反复换标签有意义得多。2.4 把服务暴露出去OLLAMA_HOST 与端口规划默认情况下 Ollama 只监听127.0.0.1:11434只有本机能访问。如果你打算让局域网内其他设备、或者 Docker 容器里的 Open WebUI 连过来就得改监听地址。# Linux / macOS临时生效仅当前 shell 会话 export OLLAMA_HOST0.0.0.0:11434 ollama serve # Windows PowerShell临时生效 $env:OLLAMA_HOST0.0.0.0:11434 ollama serve这里的参数含义要说清。0.0.0.0表示监听所有网卡11434是端口。改成0.0.0.0之后同网段的机器就能用http://你的内网IP:11434访问。但这一步有安全含义Ollama 的 API 没有任何鉴权机制暴露到公网等于把你的算力开放给所有人。我的习惯是只在可信内网里这么干外网访问一律走反向代理加认证或者干脆不暴露。想让它开机自启并且永久生效Linux 下用 systemd 覆盖配置macOS 下用 launchctl 设置环境变量Windows 下在系统环境变量里加。这些配置方式各平台不同但核心就一个环境变量名OLLAMA_HOST记住这个名字比记三套配置路径有用。顺手验证一下 API 能不能用后面接 Open WebUI 和写脚本都靠它# 用 API 发起一次对话不走交互模式 curl http://127.0.0.1:11434/api/generate -d { model: deepseek-r1:7b, prompt: 用一句话解释什么是量化, stream: false }stream设成false表示等模型生成完一次性返回方便脚本处理设成true则是流式输出适合做打字机效果。model字段必须和ollama list里的标签完全一致包括大小写。3. Android 端 Termux 编译 Ollama依赖清单、构建顺序与进程保活手机端部署要分成两种完全不同的情况来谈。Android 是有 Linux 内核的Termux 提供了一个接近标准 Linux 的用户空间理论上可以把 Ollama 编译出来跑在本地iPhone 没有这种自由度快捷指令本质是个 HTTP 客户端模型其实跑在远端。把这两者混为一谈是很多教程让人产生误解的地方。3.1 Termux 的依赖账包名写错就卡在第一步Termux 装好之后第一件事是配存储权限和更新软件源这两步不做后面pkg install会因为索引过期而失败。# 授予 Termux 访问共享存储的权限执行后会弹系统授权框 termux-setup-storage # 更新包索引并升级已安装的包-y 表示自动确认 pkg update pkg upgrade -y # 安装编译 Ollama 需要的工具链 pkg install -y git cmake golang libjpeg-turbo这里有两个原文里写错、照着敲一定失败的地方值得单独点出来。第一是权限命令正确写法是termux-setup-storage中间是连字符不是连写的termuxsetupstorage。第二是 JPEG 库的包名Termux 仓库里叫libjpeg-turbo连字符分隔写成libjpegturbo会报Unable to locate package。这类错误看起来低级但在手机小屏幕上输入出错概率比你想的高得多。四个依赖各自的作用也说一下方便你判断报错时缺了哪个。git用来克隆源码cmake是 llama.cpp 那部分的构建系统golang是 Ollama 主体服务的语言工具链libjpeg-turbo处理多模态输入里的图像解码。少任何一个构建阶段都会在链接时报 undefined reference。还要提醒一点Termux 从 Google Play 装的版本已经停止更新很多包会装不上。常见做法是从项目自己的发布页拿 APK 手动安装装完再执行上面的更新流程。3.2 编译过程go generate和go build的顺序不能反源码拉下来之后构建分两步顺序不能颠倒。# 浅克隆只取最新一次提交省流量省时间 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # 第一步生成 C 语言绑定和嵌入资源内部会调用 cmake 编译 llama.cpp go generate ./... # 第二步编译 Go 主程序产物是当前目录下的 ollama 可执行文件 go build -o ollama .原文里写的是git clone depth 1少了两个连字符git 会把depth当成仓库地址的一部分直接报错。正确写法是--depth 1。go generate ./...这一步是整条链上最慢、最容易失败的地方。它内部会调用 cmake 去编译 llama.cpp 的 C/C 源码在手机上这个阶段可能跑十几分钟到半小时期间 CPU 满载、机身发烫属于正常现象。如果它在中途被杀掉通常不是编译错误而是 Termux 被系统省电策略挂起了或者内存不够触发 OOM Killer。go build -o ollama .里的-o ollama是指定输出文件名.表示编译当前目录的包。不加-o的话产物名字由包名决定也是ollama但显式写出来更清楚。这一步如果报找不到符号八成是上一步go generate没跑完。3.3 启动服务、拉模型与进程保活编译出可执行文件之后先启动服务再拉模型顺序和桌面端一致。# 后台启动服务日志重定向到文件 放后台 ./ollama serve ~/ollama.log 21 # 验证服务是否真的起来了返回 Ollama is running 即成功 curl http://127.0.0.1:11434 # 手机上别贪大1.5b 是能跑起来且响应可接受的选择 ./ollama pull deepseek-r1:1.5b # 进入交互 ./ollama run deepseek-r1:1.5b原文这里有两处需要注意。一是模型标签写成了deepseekr1:8b缺连字符会拉取失败原因在 2.3 节已经说过。二是手机端的模型选择8b 在多数手机上会因为内存不足在加载阶段就被杀掉或者勉强加载后每个 token 要等好几秒。1.5b 才是这个场景下现实的选择参数量小、量化后体积小配合手机的 ARM CPU 跑出可用的响应速度。进程保活是 Android 特有的坑。Termux 在后台待一会儿就会被系统回收ollama serve的进程随之消失表现为「刚才还能用锁屏一会儿再打开就连接失败」。解决办法是拿一个 wake lock# 获取唤醒锁阻止系统在 Termux 有任务时休眠 termux-wake-lock # 用完释放 termux-wake-unlock同时去系统设置里把 Termux 的电池优化关掉允许后台活动。这两步做完服务才能稳定常驻。想确认服务状态看日志文件比反复敲 curl 更直接# 实时查看服务日志CtrlC 退出 tail -f ~/ollama.log日志里能看到模型加载、请求进来、生成完成的完整过程出问题时这是唯一的线索来源。3.4 iPhone 的边界快捷指令是客户端不是推理端iPhone 上没有 Termux 这样的自由环境做不到把模型权重下载到本地跑推理。原文给出的方案是安装快捷指令加配置 API Key这个方案的实质是快捷指令负责收集你的输入、发一个 HTTP 请求出去、把返回的结果展示出来模型跑在提供 API 的那一端。想清楚这一点很多问题就有答案了。它不需要你有很强的手机性能但需要网络它的响应速度取决于远端服务的排队情况和网络延迟你的输入内容会离开设备所以不适合处理敏感信息。配置流程本身不复杂装好快捷指令之后第一次运行会向你要 API Key填进去然后系统会弹权限确认框允许它访问网络。原文提到首次运行要点「允许访问」这一步不能跳过跳过之后快捷指令会在后台静默失败表现是「点了没反应」。配置 API Key 有几个习惯我建议养成。第一别把 Key 直接写死在别人分享的快捷指令里分享出去等于把 Key 分享出去了用自己的 Key 重新配一遍。第二Key 要能随时吊销选择服务时优先看有没有用量控制和吊销机制。第三别用来路不明的中转服务处理任何真实业务数据。这些跟技术无关但翻车的时候比技术问题更麻烦。4. Open WebUI 加 Docker容器参数、数据卷与多用户接入本地命令行跑通之后下一个需求通常是「让团队里不写代码的同事也能用」。Open WebUI 就是干这个的它把 Ollama 的 API 包装成一个类似聊天产品的 Web 界面支持多用户、对话历史、模型切换。装它的方式有 pip 和 Docker 两种我一般直接上 Docker理由后面说。4.1 为什么选 Docker 而不是 pip 直装pip 装 Open WebUI 也能跑但会往你的全局 Python 环境里塞几十个依赖版本冲突的时候很难清理。Docker 把整个运行时封在镜像里升级就是换镜像标签回滚就是换回旧标签数据放在命名卷里不受影响。对于「装一次长期用」的工具这个隔离性值回票价。前置条件有两个装好 Ollama 并且服务在跑第二章已经完成装好 Docker Desktop 或者 Docker Engine。Windows 和 macOS 用 Docker DesktopLinux 用 Docker Engine 加 compose 插件。Windows 上要注意 Docker Desktop 默认走 WSL2 后端第一次启动会要你确认装完重启一次再验证。# 验证 Docker 装好了能输出版本号即正常 docker --version # 验证 Docker 守护进程在跑能输出 hello world 即正常 docker run --rm hello-world第二条命令如果报Cannot connect to the Docker daemon是守护进程没起来Windows 和 macOS 上把 Docker Desktop 打开等它转完Linux 上systemctl start docker。4.2 一条docker run拆开看每个参数官方给的启动命令看起来长其实每个参数都有明确用途。把它拆开逐条解释你才知道哪一条能改、改了会怎样。docker run -d \ --name open-webui \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main-d是后台运行不加的话容器会占住当前终端。--name open-webui给容器起名字后面重启、看日志、删容器都用这个名字比记容器 ID 方便。-p 3000:8080是端口映射冒号左边是宿主机端口、右边是容器内端口容器内固定是 8080宿主机这边 3000 被占了可以改成 3001、8080 任意空闲端口。--add-hosthost.docker.internal:host-gateway这一条在 Linux 上不能省。Docker Desktop 在 Windows 和 macOS 上自带host.docker.internal这个域名解析容器里用它就能访问宿主机Linux 的 Docker Engine 默认没有得靠这个参数把宿主机网关映射进去。少了它Open WebUI 里配 Ollama 地址时会一直连不上。-v open-webui:/app/backend/data是命名卷挂载把容器的数据目录持久化到 Docker 管理的卷里。这一条关系到「后悔药」不挂卷的话容器一删所有用户、对话记录、配置全部消失。用命名卷而不是绑定宿主机目录是因为权限问题少Docker 自己管。--restart always让容器在 Docker 启动时自动拉起机器重启后不用手动敲命令。ghcr.io/open-webui/open-webui:main是镜像地址main是标签跟着主线走。GPU 推理的话换成 CUDA 标签并加--gpus alldocker run -d \ --gpus all \ --name open-webui-gpu \ -p 3001:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui-gpu:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:cuda--gpus all需要宿主机装好 NVIDIA 驱动和 NVIDIA Container Toolkit缺一个就会报could not select device driver。这一步在 Windows 上还要 WSL2 里也装好驱动链条比较长跑不通就先退回 CPU 版本界面功能是一样的。4.3 从浏览器进界面到接上模型容器起来之后浏览器打开http://localhost:3000。第一次访问会让你注册一个账号第一个注册的账号自动成为管理员这一步别让别人先注册了。原文里有个说法容易误导说打开 Docker Desktop 点 ports 看到的是 Ollama 的用户界面。实际上 3000 端口对应的是 Open WebUI 的界面Ollama 本身没有图形界面它的 11434 是纯 API。想确认两个服务都在分别访问各自的地址# 确认 Ollama 在跑 curl http://127.0.0.1:11434 # 确认 Open WebUI 在跑返回 HTML 即正常 curl -I http://127.0.0.1:3000进界面之后管理员设置里的连接配置Ollama 的地址填http://host.docker.internal:11434。这个地址是站在容器内部看的视角不是宿主机的127.0.0.1。填错的话界面上模型列表会是空的或者在保存时报连接超时。地址填对之后模型下拉框里会列出你在 Ollama 里已经拉过的所有标签。如果列表是空的先在宿主机上ollama list确认模型确实存在再回来刷新。模型也可以在界面里直接拉走的是同一个 Ollama API效果等价于命令行ollama pull。多用户场景还有两个设置值得调。一是关闭新用户自助注册避免内网里谁都能开账号二是给不同用户组分配不同的模型权限小模型给普通用户、大模型只给需要的人避免所有人一起拉满显存。5. 部署避坑与排查五条踩过的记录这一章是纯粹的失败记录每条都按「现象 → 原因 → 解决」写遇到对应的症状可以直接对号入座。第一条模型加载成功但生成极慢风扇狂转。现象是ollama run之后能对话但每个 token 要等好几秒ollama ps显示模型跑在 CPU 上。原因通常是有显卡但驱动或运行时没被识别Ollama 静默退回了 CPU 推理。解决是先确认显卡驱动版本NVIDIA 用nvidia-smi看能不能正常输出然后确认 Ollama 版本支持你的卡。确认没问题后重启一次 Ollama 服务让它重新探测设备。如果确实没有独显那就接受现实换更小的标签。第二条curl http://localhost:11434返回的不是预期内容误判服务挂了。现象是敲完 curl 看到一行Ollama is running以为出错了因为预期是 JSON。原因是这个根路径就是个存活探针只返回纯文本。解决办法是别用根路径判断改用/api/tags拿模型列表返回 JSON 才说明 API 层是通的curl http://127.0.0.1:11434/api/tags第三条Android 上编译到一半进程消失没有报错。现象是go generate ./...跑了十几分钟突然中断终端回到提示符没有任何错误信息。原因是系统省电策略把 Termux 挂起了或者内存不足触发了 OOM Killer。解决是提前执行termux-wake-lock去系统设置里关掉 Termux 的电池优化并且保证编译期间屏幕别长时间熄灭。编译前先free -h看一眼可用内存不够就先杀掉其他应用。第四条删了容器重新跑用户和对话全没了。现象是执行docker rm之后重新docker run界面回到初始注册页。原因是启动命令里没挂数据卷所有数据写在容器的可写层容器一删就没了。解决是启动时必须带-v 卷名:/app/backend/data已经丢了的话只能重建。养成习惯任何带状态的容器先想清楚数据放哪再敲 run。第五条Open WebUI 里模型列表永远是空的。现象是界面正常打开但下拉框里一个模型都没有手动填地址保存也失败。原因有三个常见分支一是地址填成了127.0.0.1:11434在容器里这个地址指向容器自己二是 Linux 上漏了--add-host参数host.docker.internal解析不了三是宿主机防火墙拦了 11434。排查顺序是先docker exec进容器curl一下宿主机地址能通就是配置问题不通就是网络问题。6. 进阶用 Modelfile 固化参数用 API 压出真实吞吐命令行跑通、界面能用之后真正决定这套部署好不好用的是两件事参数能不能固化下来以及你到底知不知道它的真实速度。前者靠 Modelfile后者靠一段几十行的压测脚本。6.1 Modelfile把系统提示和采样参数变成可复用的模型每次对话都手动敲一遍系统提示、每次都要在界面上调 temperature这种事做三次就该厌烦了。Modelfile 允许你基于已有模型派生出一个带固定配置的新模型。# 基于已有的 7b 标签派生 FROM deepseek-r1:7b # 采样温度越低越确定代码类任务建议 0.2~0.4 PARAMETER temperature 0.3 # 上下文窗口长文档问答时调大代价是吃更多内存 PARAMETER num_ctx 8192 # 固定系统提示定义角色和输出格式 SYSTEM 你是一名严谨的技术文档助手。回答时先给结论再给依据不确定的内容明确说明不确定。FROM指定基础模型必须是ollama list里存在的标签。PARAMETER可以写多个常用的是 temperature、num_ctx、top_p、repeat_penalty。SYSTEM后面跟三引号包裹的多行文本会成为每次对话的隐藏前缀。有了文件之后创建并运行# 在当前目录用 Modelfile 创建名为 doc-helper 的新模型 ollama create doc-helper -f ./Modelfile # 运行验证此时系统提示已经内置 ollama run doc-helper # 查看派生模型的完整配置确认参数生效 ollama show doc-helper --modelfileollama create这一步通常很快因为它只是写一份新的 manifest底层权重是共享的不会复制几个 GB 的文件。这也是 Modelfile 比「每次手动调参」优雅的地方派生十个模型磁盘占用几乎不变。6.2 一段脚本量出真实的 tokens/s「感觉挺快的」不是指标。想知道这套部署的真实吞吐用 API 拿eval_count和eval_duration算一下这两个字段是 Ollama 在响应里直接给的。import json import time import urllib.request def bench(model: str, prompt: str, rounds: int 3) - None: url http://127.0.0.1:11434/api/generate speeds [] for i in range(rounds): payload json.dumps({ model: model, prompt: prompt, stream: False, # 一次性返回方便取统计字段 options: {num_predict: 128} # 限制生成长度保证可比 }).encode(utf-8) req urllib.request.Request( url, datapayload, headers{Content-Type: application/json} ) t0 time.time() with urllib.request.urlopen(req, timeout300) as resp: data json.loads(resp.read().decode(utf-8)) wall time.time() - t0 # eval_duration 单位是纳秒 gen_tokens data.get(eval_count, 0) gen_ns data.get(eval_duration, 1) tps gen_tokens / (gen_ns / 1e9) speeds.append(tps) print(fround {i1}: {gen_tokens} tokens, f生成 {tps:.2f} tok/s, 端到端 {wall:.2f}s) print(f平均生成速度: {sum(speeds)/len(speeds):.2f} tok/s) if __name__ __main__: bench(deepseek-r1:7b, 用三句话说明什么是 KV Cache。)这段脚本只用了标准库不用装 requests。几个参数值得注意num_predict限制生成 token 数不限制的话不同轮次生成长度差异太大速度没法比stream设成 false 才能一次性拿到统计字段timeout给到 300 秒慢机器上别让它提前断。eval_count是实际生成的 token 数eval_duration是纯生成耗时纳秒两者相除就是生成速度不含模型加载和 prompt 处理的时间。第一轮通常偏慢因为要加载模型所以跑三轮取平均。我一般会跑两组对比一组 7b 在 GPU 上一组 1.5b 在 CPU 上把数字记下来。以后换了驱动、升级了 Ollama、调了 num_ctx再跑一遍就知道是快了还是慢了。没有基线任何「感觉变快了」都是玄学。6.3 上线前过一遍的检查清单最后给一份我自己每次部署完都会走一遍的清单五分钟能过完能挡住大部分低级问题。检查项命令或动作通过标准服务存活curl 127.0.0.1:11434/api/tags返回 JSON 模型列表模型可用ollama ps目标模型在列且设备正确生成速度跑 6.2 的脚本记录基线与预期量级相符端口占用lsof -i :3000或netstat -ano无冲突进程数据持久化docker volume ls命名卷存在容器自启重启 Docker 后访问界面无需手动启动这张表里最容易被跳过的是「数据持久化」那一行。它平时不会有任何反馈直到你删了容器才发现问题。从那以后我每次跑docker run之前都会先把带-v的那一行单独抄出来确认一遍再补--restart always最后才敲回车。这个习惯是从一次误删容器、丢掉两周对话记录之后养成的。部署这件事跑起来只是及格线跑得可复现、可回滚、有基线才算真正落地。希望帮到你。本文还有配套的精品资源点击获取