Docker Model Runner终结了我的本地AI工具链

我曾经的本地AI配置堪称灾难。Ollama作为后台服务运行。给LangChain实验单独建了一个Python虚拟环境。另一个终端跑着llama.cpp，因为我想测试量化模型。三种不同的API格式，三个不同的端口号，三个每次macOS更新都会独立崩溃的东西。

然后Docker推出了Model Runner，我把这些全删了。

Model Runner到底是什么

它内置于Docker Desktop，无需单独安装。拉取模型的方式和拉取镜像一样：

docker model pull ai/llama3.1

docker model pull ai/phi3-mini

docker model pull ai/mistral

运行推理：

docker model run ai/llama3.1 "Explain NUMA topology in two sentences"

或者直接调用API端点，兼容OpenAI格式：

curl http://localhost:12434/engines/llama3.1/v1/chat/completions \

-H "Content-Type: application/json" \

"messages": [{"role": "user", "content": "What is OKE?"}],

"max_tokens": 100

就这样。不需要Python，不需要虚拟环境，不需要pip install，不需要CUDA驱动（Mac上用Metal，其他平台用CPU）。直接就能跑。

为什么我从Ollama切换过来

Ollama还行。我用了好几个月。但有几件事让我烦：

端口冲突。Ollama默认占用11434。我总是忘了它在运行，然后纳闷11434端口怎么被占用了。Docker Model Runner跑在Docker虚拟机内部，不会以同样方式占用宿主机端口——它通过一个固定的端点访问。

更新管理。Ollama是单独的二进制文件，得单独更新。Model Runner的更新跟着Docker Desktop走。少操一份心。

API兼容性。我在OKE生产环境部署的是vLLM。vLLM暴露的是OpenAI兼容API。Model Runner也暴露OpenAI兼容API。我的客户端代码在本地和生产环境之间不用改。用Ollama的时候，我得不断在Ollama原生格式和OpenAI格式之间转换。

Docker上下文。Model Runner的模型可以在Docker Compose文件和Dockerfile里引用。这意味着我的本地开发栈可以把LLM作为服务，和API服务器、数据库、缓存放在一起——一个docker compose up全起来。

在Docker Compose里用Model Runner

这部分真正改变了我的工作流：

# docker-compose.yml

services:

api:

build: .

ports:

- "8080:8080"

environment:

- LLM_ENDPOINT=http://host.docker.internal:12434/engines/llama3.1/v1

depends_on:

- db

db:

image: postgres:16-alpine

environment:

POSTGRES_PASSWORD: dev

我的API服务器通过host.docker.internal:12434和Model Runner通信。在OKE生产环境，那个环境变量指向我的vLLM服务。同样的客户端代码，同样的prompt格式，不同的后端。

// 同样的代码，本地用Model Runner，OKE上用vLLM

func callLLM(prompt string) (string, error) {

endpoint := os.Getenv("LLM_ENDPOINT") + "/chat/completions"

body := map[string]interface{}{

"messages": []map[string]string{

{"role": "user", "content": prompt},

},

"max_tokens": 200,

jsonBody, _ := json.Marshal(body)

resp, err := http.Post(endpoint, "application/json", bytes.NewBuffer(jsonBody))

环境变量切换，代码不动。本地开发完，直接上生产。

实际体验

第一次跑docker model pull ai/llama3.1的时候，我以为会等很久。结果比想象中快。模型存在Docker的存储层里，和镜像共用一套管理机制。磁盘占用、清理、版本控制，都是熟悉的那套。

Metal后端在M3 Pro上的表现：7B模型推理速度够用，13B模型稍微慢一点，但能接受。没有量化模型的精细控制，但省下来的配置时间远超这点损失。

最意外的是稳定性。过去三个月macOS更新了两次，以前每次都得重新折腾Ollama和llama.cpp的依赖。这次什么都没坏。

谁适合用这个

如果你已经在用Docker Desktop，这是白送的功能。不用额外装任何东西，学习成本几乎为零。

如果你还在用Ollama但经常被端口冲突和格式转换烦到，值得试试。切换成本很低，docker model pull完就能跑。

如果你需要精细控制量化级别、自定义推理参数、或者跑特别大的模型，可能还是得用llama.cpp或者vLLM本地部署。Model Runner走的是"够用就好"的路线。

我的判断：本地AI工具链正在从"拼配置"转向"拼集成"。Docker把模型当成另一种容器资源来管理，这个抽象层省掉的心力，比多出来的那点性能损失值钱得多。