Docker Model Runner,一个将要颠覆Ollama的新方案 - 文章 - 开发者社区

当你需要在本地环境频繁切换各种开源模型测试功能时，会发现这是个比想象中更折腾的过程。内存不够装多个模型，手动启停服务，各种环境配置——这些琐碎的管理工作往往比实际的模型调用更耗费精力。

Docker 最近推出的 Model Runner 工具提供了一个相当优雅的解决方案。

核心设计理念

Docker 团队在设计 Model Runner 时有一个很清晰的目标：让 AI 模型成为 Docker API 中的"一等公民"。模型有着与容器截然不同的执行生命周期——它们不适合塞进传统的 /containers 端点，但又重要到需要单独的 API 资源类型。

这促成了一套新的 /models 端点，在设计上参考了 /images 端点，但又保持独立。

picture.image

架构上分成三个独立组件——model runner、model distribution、model CLI，每个都开源。小团队能并行开发，API边界清晰，迭代速度快。

Model Runner 提供两套不同风格的 API：

Docker 风格的 API （管理操作）：

  
POST /models/create     # 拉取模型  
GET /models            # 列出模型    
GET /models/{namespace}/{name}  # 模型元数据  
DELETE /models/{namespace}/{name}  # 删除模型

OpenAI 兼容的 API （推理操作）：

  
GET /engines/{engine}/v1/models  
POST /engines/{engine}/v1/chat/completions  
POST /engines/{engine}/v1/embeddings

这种双 API 设计让模型既能享受 Docker 生态的管理便利，又能无缝集成现有的 AI 工具链。

解决了什么问题

1. 硬件加速的无缝集成

在 Mac 上通过直接调用 Metal 引擎，推理进程运行在宿主机而非容器内，避免了跨 VM 边界传递 GPU 的复杂性
Linux 环境下通过优化的容器镜像支持 NVIDIA CUDA
不需要手动配置各种 --gpus all 参数

2. 智能模型调度 这是最有意思的部分。Model Runner 包含调度器、加载器和运行器组件，能协调模型的内存加载和卸载：

当系统内存不足以同时运行多个模型时，会自动排队处理请求
模型闲置时会自动卸载（默认 5 分钟超时）
需要新模型时先卸载当前模型再加载目标模型
API 服务器会保持请求直到资源可用，而不是返回 503 错误

3. 多后端架构 Docker 明智地选择了不重新发明轮子。他们设计了支持多后端的架构，目前使用 llama.cpp 作为默认推理引擎，但 API 中预留了 /engines/{name} 路径，为未来支持 vLLM、MLX、ONNX 等其他后端做准备。

基本使用

根据官方文档，使用流程包含几个步骤：

1. 启用 Docker Model Runner

在 Docker Desktop 中：

进入设置 → Beta features
勾选 "Enable Docker Model Runner"
Windows 用户还可以选择 "Enable GPU-backed inference"

picture.image

在 Docker Engine 中：

  
# Ubuntu/Debian  
sudo apt-get update  
sudo apt-get install docker-model-plugin  
  
# 测试安装  
docker model version

2. 拉取模型

  
# 从 Docker Hub 拉取  
docker model pull ai/smollm2:360M-Q4\_K\_M  
  
# 也可以从 HuggingFace 拉取  
docker model pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF  
  
# 查看本地模型  
docker model list

3. 运行模型

拿前几天最小模型举个例子：

Google 推出超小杯 AI：Gemma 3 270M！可进手机和浏览器

  
docker model run ai/gemma3-qat:270M-F16"Hi"  
# 交互式  
docker model run ai/gemma3-qat:270M-F16

picture.image

4. API访问

根据平台不同：

Docker Desktop ：通过 model-runner.docker.internal 或 Docker socket
Docker CE ：默认在 localhost:12434 ，容器内通过 172.17.0.1:12434 访问

  
curl http://model-runner.docker.internal/engines/llama.cpp/v1/chat/completions \  
    -H "Content-Type: application/json" \  
    -d '{  
        "model": "ai/smollm2",  
        "messages": [  
            {  
                "role": "system",  
                "content": "You are a helpful assistant."  
            },  
            {  
                "role": "user",  
                "content": "Please write 500 words about the fall of Rome."  
            }  
        ]  
    }'

与 Docker Compose 的深度整合

Model Runner 最令人兴奋的功能之一是与 Compose 的原生集成。你可以在 compose.yaml 中声明式地定义模型依赖：

  
services:  
  chat-app:  
    image:my-chat-app  
    models:  
      -llm  
  
models:  
llm:  
    model:ai/smollm2  
    context\_size:4096  
    runtime\_flags:  
      -"--temp"  
      -"0.7"  
      -"--top-p"  
      -"0.9"

这种方式让 AI 应用的部署变得标准化，也更容易在不同环境间迁移。更重要的是，它为从开发到生产的一致性体验奠定了基础。

与 Ollama 的对比

提到本地模型运行，很多人会想到 Ollama，它可以快速启动一个本地 LLM 服务，让用户获得本地与云端一致的模型服务。

Ollama 的优势在于起步较早，拥有活跃的开源社区和丰富的模型库。然而，Docker 正在快速补齐这些能力差距，并且在生态完整性方面展现出更强的优势。对于需要在 CI/CD 流水线中集成模型推理并推向生产环境的场景，Docker Model Runner 显然是更为自然的选择。

之前笔者在《》书中提到过，Ollama的设计本质上就是docker的设计，因为Ollama就是docker出走的开发者开发的，因此设计理念基本一致，这使得当时Ollama在推广上借到了docker的力，而现在都得还回来。因此，从ollama再迁回来更是完全无门槛。开发者本身就熟悉 Docker 工具链，过去为了使用模型推理还需要额外安装 Ollama，现在则可以统一在 Docker 生态内完成。

在此之前，我们还介绍了Docker在MCP上的布局。

picture.image

MCP安装太麻烦，安全性不高，Docker出手了

从长远来看，回过神来的Docker将会对 Ollama 而言将构成不小的挑战。

路线图亮点

Docker 团队的规划相当有野心：

containerd 集成 ：更好地整合模型存储、执行和沙箱机制
Kubernetes 支持 ：提供从开发到生产的一致体验
vLLM 后端 ：响应生产环境的实际需求
扩展的 OpenAI API 兼容性 ：支持更多端点和参数

小结

Docker Model Runner 的价值不仅在于技术实现，更在于它对 AI 开发工作流程的重新定义。它把模型从"需要特殊照顾的异类"变成了"开发栈中的标准组件"。

对于那些厌倦了手动管理模型生命周期、在各种推理框架间折腾环境配置的开发者来说，这确实是个优雅的解决方案。更重要的是，它为 AI 应用的容器化和标准化部署开辟了一条实用的道路。

当你可以像管理 Docker 镜像一样管理 AI 模型时，整个开发体验就变得不一样了。

关注公众号回复“进群”入群讨论。