Docker Model Runner + Open WebUI 本地预检：先确认 docker model 真的存在
我这轮本地预检先卡在最前面的一条命令：docker model version。截至 2026-05-21，在一台 Darwin arm64 主机上，我本地的 Docker 版本已经是 client=29.4.0 server=29.4.0，但执行结果仍然是 docker: unknown command: docker model。这已经足够回答大多数人真正想问的问题：如果你的环境连 docker model 入口都没有，就还没到排 Open WebUI、模型下载或显存的阶段。
如果你准备把 Docker Model Runner 接到 Open WebUI，本篇更适合当一份 开跑前预检清单：先判断自己是不是已经站在官方文档的起跑线上，再决定要不要继续拉模型或调 UI。
先说清一个容易混淆的点：本文里的产品名是 Docker Model Runner（DMR）。按 Docker 官方 Docker Model Runner 文档 当前写法，它是一层负责拉取、运行、暴露模型接口的能力，不是“装了 Docker 就天然多出来的几条 AI 命令”。同一套官方文档也把当前 Open WebUI 集成单独放在 Open WebUI integration 页面里；这点很重要，因为不少旧帖子和演示还在混用更早的命名、命令和 hostname。
如果你之前看过我写的 Hugging Face Docker Space 能跑 ARM64 吗？先查这 3 个兼容性卡点，这次的判断逻辑很像：先验环境边界，再决定要不要继续跟官方教程。类似地，我在 Cloudflare Dynamic Workflows 上线前先过哪 5 关？ 里做的也是同一件事：先补一轮最小验收，而不是把“文档存在”直接当成“你的机器 ready”。如果你平时也会给本地工具链做入口验收，另一篇 代码 Agent 沙箱怎么做最小验收 也可以一起看，核心都是先查控制面，再查功能面。
先给结论：Docker Model Runner + Open WebUI 现在值不值得继续往下跑？
短答案：先跑 4 条预检，再决定。 如果 docker model version 能返回版本、你也确实在 Docker 官方支持的发行路径里，那才值得继续看 Open WebUI 配置和模型下载；如果第一步就报 docker: unknown command: docker model，而且连 Docker Desktop 文档里的插件源路径都不存在，那你当前该查的是 发行形态和 CLI 插件来源，不是模型本身。
第一步先验什么：不是模型，而是 docker model
Docker 官方当前的 Docker Model Runner 文档 先写清了前提：它要求的是 Docker Engine，或者 Docker Desktop（Windows 4.41+ / macOS 4.40+）。它还明确说明，DMR 会通过 OpenAI / Ollama 兼容接口 暴露模型服务。
所以这题最该先跑的不是 docker model pull，而是下面这几条环境命令：
uname -sm
# Darwin arm64
docker version --format 'client={{.Client.Version}} server={{.Server.Version}}'
# client=29.4.0 server=29.4.0
docker model version
# docker: unknown command: docker model
对我这轮测试来说，这组输出已经足够下结论：当前环境还没进入 Docker Model Runner 可用阶段。 如果入口命令都不存在，后面再去排 Open WebUI、Stable Diffusion 或 API 参数，只会把排错方向越带越偏。
第二步要分清：你是“少了软链”，还是“根本不是那条发行路径”
Docker 官方文档在 Known issues 里专门写了一个已知问题：如果你看到 docker: 'model' is not a docker command，说明 Docker 找不到插件，因为它不在预期的 CLI plugins 目录里。官方给出的修复动作是：
ln -s /Applications/Docker.app/Contents/Resources/cli-plugins/docker-model ~/.docker/cli-plugins/docker-model
但这条修复命令有一个很容易被忽略的前提：你的机器上真的存在 Docker Desktop 自带的 docker-model 插件文件。 我这轮继续往前查，结果是：
[ -e ~/.docker/cli-plugins/docker-model ] && echo exists || echo missing
# missing
[ -e /Applications/Docker.app/Contents/Resources/cli-plugins/docker-model ] && echo exists || echo missing
# missing
这说明我当前缺的不是“忘了补软链”，而是 Docker Desktop 这条修复路径本身就不适用于我这台机器的当前发行形态。这一步如果不先分清，你很容易把“官方提供了 fix”误读成“照抄就一定能修好”。
第三步别把旧演示里的 hostname 当成通用模板
这里还有一个很容易踩坑的产品命名/文档漂移问题。
很多更早的 Docker Model Runner 演示，会把 Open WebUI 连到一个看起来像 model-runner.docker.internal 的地址；但 截至 2026-05-21，Docker 官方当前的 Open WebUI integration 页面，默认示例更强调的是：
- Ollama 兼容接口走
OLLAMA_BASE_URL=http://host.docker.internal:12434 - OpenAI 兼容接口走
OPENAI_API_BASE_URL=http://host.docker.internal:12434/...
这不只是一个字符串差异，而是在提醒你：Docker Model Runner + Open WebUI 的连通方式，本来就和你的运行形态、接口模式、文档版本强相关。 所以如果你是从旧博客、旧 demo、旧 gist 开始跟，不要把里面的 hostname 原样当成跨环境通用模板。
第四步再看后端：能有 DMR，不等于你现在就能顺利跑图片模型
Docker 官方主文档也把推理后端拆得很清楚：llama.cpp、vLLM、Diffusers 不是一回事。尤其你如果看的不是聊天模型，而是想把 Open WebUI 接到本地图像生成链路上，那实际牵涉的是 Diffusers 路线、模型拉取、接口暴露，以及更具体的硬件前提。
所以靠谱顺序应该是：
- 先确认
docker model version能跑通 - 再确认自己是不是 Docker 官方支持的发行路径
- 再确认 Open WebUI 要接的是 Ollama 兼容接口还是 OpenAI 兼容接口
- 最后才去执行模型拉取、inspect 和 UI 启动
Docker Model Runner + Open WebUI 本地预检：按这 5 步走
1）先查宿主和 Docker 版本
uname -sm
docker version --format 'client={{.Client.Version}} server={{.Server.Version}}'
验收通过： 你知道自己是在 Darwin / Linux / Windows 哪一侧，也知道 Docker 版本。
常见失败： Docker daemon 都没起来，那这题先别往 DMR 上扯。
2）直接验 docker model 命令入口
docker model version
验收通过： 返回 DMR 版本信息，可以继续。
常见失败： 报 docker: unknown command: docker model，这时优先排 CLI 插件或发行形态，不要先怪模型或 Open WebUI。
3）如果文档提示软链修复，先查源路径是否真的存在
[ -e /Applications/Docker.app/Contents/Resources/cli-plugins/docker-model ] && echo exists || echo missing
[ -e ~/.docker/cli-plugins/docker-model ] && echo exists || echo missing
验收通过： 至少有源插件路径可链接。
常见失败： 源路径都不存在，说明你不是“漏建软链”，而是当前发行形态本来就不是这条 Docker Desktop 路径。
4）确认 Open WebUI 走哪条接口配置
- 走 Ollama 兼容接口：看
OLLAMA_BASE_URL - 走 OpenAI 兼容接口：看
OPENAI_API_BASE_URL - 当前 Docker 官方 Open WebUI 集成页示例默认围绕
host.docker.internal:12434展开
验收通过： 你知道后续该配哪个 base URL。
常见失败： 把旧演示里的 hostname 或接口变量直接抄进当前环境。
5）只有前四步都过了，才值得继续拉模型和起 UI
docker model pull ai/llama3.2
# 或按你的目标模型替换
如果你要继续按 Docker 官方 Open WebUI 集成页往下跑，再进入 compose / OPENAI_API_BASE_URL / OLLAMA_BASE_URL 那一层；如果你前四步还没过，这一步先别急着做。
验收通过： 模型能被拉取，Open WebUI 能连上正确接口。
常见失败： 入口命令还没解决，就提前进入模型和 UI 层排错。
谁现在该继续，谁先停一下
如果你已经能正常跑 docker model version，并且确认自己就在 Docker 官方支持的发行路径里，那现在值得继续看 Open WebUI 的 compose 配置、接口模式和模型选择。
如果你和我这轮一样，第一步就碰到 docker: unknown command: docker model，而且文档里的 Docker Desktop 插件路径也不存在，那你现在更该做的是 确认发行形态、插件来源和文档版本，而不是继续往模型下载、显存占用或 UI 配置层面排错。
FAQ
Docker Model Runner 和普通 Docker 到底差在哪？
普通 Docker 解决的是容器打包与运行；Docker Model Runner 解决的是模型拉取、推理后端管理，以及把这些模型通过 OpenAI / Ollama 兼容接口暴露出来。看官方文档时，别把它当成“任意 Docker 环境天然就有的一层能力”。
只要 docker version 正常，就说明我能继续跑 Open WebUI 吗？
不说明。对这类 Docker Model Runner 教程，真正该先看的不是 docker version，而是 docker model version。入口命令没出现，后面的模型和 UI 步骤都还不是主排错方向。
docker: unknown command: docker model 一定是我装坏了吗？
不一定。Docker 官方文档已经把它列成已知问题。但你要先区分：你是 Docker Desktop 的插件路径没接上，还是当前运行形态根本不是文档里那条插件分发路径。
Docker Model Runner 接 Open WebUI 时，到底该看 host.docker.internal 还是旧的 model-runner.docker.internal？
先看你跟的是哪一版官方文档。截至 2026-05-21，Docker 官方当前 Open WebUI integration 页面重点示例围绕 host.docker.internal:12434 展开；如果你看到别的 hostname，先别照抄，先确认那是不是旧演示、旧博客或另一种接口模式。
如果我只是想跑本地聊天模型，不做图片生成，这篇还适用吗？
适用。只是重点会往接口模式、模型拉取和本地服务连通性偏，而不是图像生成链路本身。换句话说，入口验收这一步对聊天模型和图片模型都一样重要。
最后一句
这篇 Docker Model Runner + Open WebUI 教程不是不能跟，而是 先别把它当成“有 Docker 就能跑”的命令清单。截至 2026-05-21，我这台 Darwin arm64 + Docker 29.4.0 环境给出的最有价值结论，不是模型效果好不好，而是：在 docker model 还没出现之前，你甚至还没真正站到 Docker Model Runner 这条教程的起跑线上。
