基于docker-compose的Ollama GPU部署指南：从环境配置到性能优化-代码聚汇网

基于docker-compose的Ollama GPU部署指南：从环境配置到性能优化

小鹅通·2026-08-31·阅读 22 GEO检测（免费）

docker-composeOllamaGPU

|难度：普通|阅读约 44 分钟

1. 为什么我坚持用docker-compose跑Ollama：三个痛点换来一个yaml

1.1 裸机安装的三个不爽

我最早是在Windows上直接装Ollama官方安装包的，双击一下就能用，下载模型也简单，一个ollama run qwen2.5就完事。但用了一周左右，三个问题越来越明显。

第一个是升级麻烦。Ollama发版很勤，每次想升级都得去官网重新下载安装包，覆盖安装后还得确认老版本是否清理干净。在服务器上更麻烦，不能每次都用curl | sh这种在线脚本，安全审计也过不去。

第二个是模型目录不透明。Ollama把所有模型文件放在~/.ollama/models下面，Windows上就是C:\Users\你的用户名\.ollama\models。模型越下越多，C盘体积一路飙红。我想把模型挪到D盘或者独立数据盘，得翻文档找环境变量，还要处理系统服务重启后变量丢失的问题。

第三个是资源控制能力为零。Ollama服务一跑起来就是全速，多挂几个模型，内存和显存被吃干净，同一台机器上其他容器直接卡死。裸机安装没有简单的办法去限制CPU、内存，生态里也缺一个统一的配置入口。

1.2 docker-compose带来的改变

换到docker-compose之后，上面三个问题基本都消失。

一个docker-compose.yml文件就能把镜像版本、端口映射、卷目录、环境变量、GPU设备、资源限制全部锁定下来。部署新机器只需要把这份yaml和模型目录拷过去，docker compose up -d就能复现一套完全一致的环境，不再依赖"当时安装时手动点了什么选项"这种不可复现的记忆。

组合编排能力也很关键。我现在主要把Ollama当作私有模型API服务，旁边还要跑Dify、向量库、前端服务，所有这些都写进同一个compose项目里，一个网络、一套启动顺序。换机器的时候，整个LLM工具链一起搬走，这个收益在裸机安装方案里是不可能有的。

1.3 这套方案的适用边界

我得先泼一盆冷水：如果你只是在自己电脑上跑个模型玩玩，不折腾多服务组合，不关心部署可复现性，那直接用官方安装包，一条ollama run就够，没必要上docker-compose，别给自己增加复杂度。

但如果你属于下面几类情况，docker-compose几乎是刚需：

在服务器或远程开发机上部署，需要可复现、可回滚、可审计；
同一台机器上还要跑Dify、FastGPT、n8n或其他服务，需要统一编排；
模型目录和日志必须放到指定数据盘，而不是跟随用户目录；
多人共用一台GPU服务器，需要限制Ollama能用的CPU、内存和GPU数量。

1.4 部署前的软硬件检查清单

正式动手前，我建议先花十分钟把环境底数摸清楚，避免后面排查问题时分不清是配置错还是环境错。以下是我每次部署都过一遍的清单：

检查项	命令/方法	预期结果
显卡驱动	宿主机执行 `nvidia-smi`	正常输出显卡型号和驱动版本
Windows版本/WSL版本	`wsl --status`、`wsl -l -v`	WSL 2，内核版本较新
Docker版本	`docker version`	Server端正常，支持Compose v2
Compose插件	`docker compose version`	正常输出版本号
磁盘空间	`df -h`	要预留模型体积的1.5倍以上
显存/内存	`nvidia-smi` / `free -h`	明确7B模型大概占4-6GB显存

检查完这些再往下走，后面每一步的坑都能快速定位到具体环节。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 环境准备阶段最深的坑：WSL1与WSL2、Docker Runtime、NVIDIA工具链的配合关系

2.1 那个wsl 1 distro报错，其实是两个问题的叠加

很多人在Windows上装完Docker Desktop，然后在WSL终端里敲docker-compose up，会弹出一句很迷惑的提示：

code复制The command 'docker-compose' could not be found in this WSL 1 distro.
We recommend the conversion of this distro to WSL 2 as soon as possible.

这句话把两个问题混在一起了。

第一，docker-compose命令不在PATH里。Docker Desktop自带的compose插件通常只在特定distro里注册，换到自己装的Ubuntu发行版里，docker-compose这个命令并不存在，需要检查docker compose（带空格）是否可用。

第二，这个distro是WSL 1。WSL 1本质上是一个系统调用翻译层，没有真正的Linux内核，Docker需要的cgroups、overlayfs这些底层能力它给不了。Docker Desktop检测到WSL 1之后只能给出警告，不会正常联动。

我说的"致命"，是因为WSL 1不仅跑不了Docker，更不可能支持GPU直通。NVIDIA在WSL 2里做的GPU paravirtualization方案，WSL 1完全不支持。所以只要你的distro停留在WSL 1，后面所有关于CUDA、GPU容器的工作都无从谈起。

把distro升级到WSL 2的方法：

bash复制# Windows PowerShell（管理员）
wsl -l -v
wsl --set-version <distro名称> 2
wsl --set-default-version 2

如果升级失败，常见原因是磁盘空间不足或者Windows版本太老。有时候必须wsl --unregister重装distro，注意这会清空该发行版内的数据，操作前先备份。

2.2 两种Docker安装路线的取舍

我部署过两种路线，说下实际差异。

路线A：Windows装Docker Desktop，WSL distro直接调docker命令。

优点是真的快，Docker Desktop会自动帮你管理WSL后端、也会把compose插件暴露到默认的distro里，很多教程的截图都是这个方案。缺点是Docker Desktop吃内存，后台跑几个虚拟机进程，16GB内存的机器会有点喘。另外，大公司在商业授权上对这个工具有顾虑，需要额外确认。

路线B：在WSL 2或者纯Linux服务器里装Docker Engine和docker compose插件。

我用的就是这条。在Ubuntu 22.04的WSL里执行Docker官方安装脚本：

bash复制curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo apt-get install -y docker-compose-plugin
sudo usermod -aG docker $USER

之后需要重新登录一下终端，使sudo组权限生效。Debian系（包括Debian 12）方法基本一致。这个方案跟生产环境服务器完全同构，不会有"本机能跑、服务器上跑不起来"的割裂感。

注意一个细节：WSL里的Docker Engine，其daemon就是跑在WSL 2里的Linux虚拟机内部，性能比Docker Desktop的独立虚拟机方案更纯粹，GPU透传也更直接。

2.3 NVIDIA Container Toolkit：GPU进入容器的关键一步

很多人以为Docker容器天然就能用GPU，其实不是。Docker的默认runtime是runc，它根本不知道CUDA或者GPU设备是什么。要让容器里看到GPU，需要靠一个专门的runtime，也就是nvidia-container-runtime。

NVIDIA Container Toolkit正是封装了这一整套逻辑的工具。它会把宿主机的GPU设备、驱动库和CUDA运行库按需挂载进容器。安装步骤在Linux发行版上是一套标准流程：

bash复制# 添加软件源
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

# 关键一步：把nvidia runtime注册到Docker
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

nvidia-ctk runtime configure这一步很关键，它会修改Docker的daemon配置，在/etc/docker/daemon.json里加入nvidia runtime的条目。改完之后可以用下面命令验证：

bash复制docker info | grep -i runtime

正常会看到Runtimes: nvidia runc。接下来跑一个最小的CUDA容器验证连通性：

bash复制docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

这条命令能正常输出GPU信息，说明GPU到容器的链路已经通了。如果这步失败，后续Ollama容器无论怎么配都不会生效，所以这个验证值得认真做一遍。

3. compose文件里GPU配置的逐段拆解：光复制粘贴不说明白，换了机器还是会翻车

3.1 一份能用的完整配置

下面这份docker-compose.yml是我当前在用的简化版本，可以直接抄，但我会在后面把每个关键字段讲透：

yaml复制services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - /data/ollama/models:/root/.ollama/models
    environment:
      - OLLAMA_HOST=0.0.0.0
      - OLLAMA_MODELS=/root/.ollama/models
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_NUM_PARALLEL=1
      - OLLAMA_MAX_LOADED_MODELS=1
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "bash", "-c", "ollama list"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

注意，现代docker compose已经不需要写version字段了，写了反而会有一个过时提示。这个配置在Docker Engine 24 + Compose v2环境里实测稳定运行。

3.2 deploy.resources.reservations.devices到底在说什么

这个字段是Compose里面对应docker run --gpus all的声明式写法。理解它需要拆成三层。

deploy.resources是Compose规范里管理资源的地方，其中reservations表示"预留"，devices表示需要映射进容器的设备。driver: nvidia指定使用NVIDIA runtime，capabilities: [gpu]是必要条件，少了这个，NVIDIA runtime不会把GPU设备注入容器。count: all表示把所有GPU都映射进去。

如果机器上有多个GPU，想只让Ollama用其中一张，可以改成：

yaml复制    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids:
                - "0"
              capabilities: [gpu]

device_ids: ["0"]对应宿主机nvidia-smi里的GPU编号。这个写法的好处是显存隔离更明确，多个服务各用各卡，互不干扰。

实际使用中我还发现一个点：有些老版本的docker-compose（v1，Python版）对deploy.resources字段的解析不够完整，在非Swarm模式下容易静默忽略GPU配置。所以一律建议用docker compose v2，也就是docker compose（空格）这个命令。

3.3 环境变量、卷映射和健康检查里的细碎经验

OLLAMA_HOST=0.0.0.0 是让Ollama服务监听所有网卡接口。如果只在宿主机本地访问，写成127.0.0.1更安全；要让Dify或其他容器通过服务名访问，必须用0.0.0.0。

OLLAMA_MODELS 指定模型存储路径。因为我把模型目录通过volume映射出来了，这个环境变量要和volume路径保持一致，避免容器内外路径错乱。

OLLAMA_KEEP_ALIVE 控制模型在内存/显存中的驻留时间，默认是5分钟。这个变量太重要了，我在Dify联动部分会展开讲。设为24h能减少"模型频繁被卸载、重新加载"的等待时间。

OLLAMA_NUM_PARALLEL 控制每个模型并行处理的请求数，默认1。这个值不是越大越好，并行数太高加上显存不够，会直接OOM。没经过压测不建议调高。

OLLAMA_MAX_LOADED_MODELS 限制最多同时加载几个模型，默认3。在多模型切换场景，这个值太大可能把显存打满，我一般设成1，确保当前模型独占显存。

卷映射方面，/data/ollama/models:/root/.ollama/models把容器内部/root/.ollama/models映射到宿主机/data/ollama/models。这样容器升级、重建都不会丢模型，备份也只需要备份宿主机的/data/ollama/models一个目录。

healthcheck这里有个坑。我一开始用的探测命令是curl -f http://localhost:11434/api/tags，结果发现ollama/ollama官方镜像里默认没有安装curl，容器一直处于unhealthy状态。排查了半天，最后换成ollama list，它本来就是一个相对轻量的子命令，用来探测服务存活是够用的。

3.4 版本兼容的坑：镜像tag、Compose版本、Docker版本

先说镜像tag。ollama/ollama:latest默认打包了CUDA和CPU支持，NVIDIA GPU可以直接用。但如果你用的是AMD显卡，这个镜像不会生效，需要换成ollama/ollama:rocm。有朋友在AMD Ryzen AI 9 HX 370这类带RDNA核显的设备上折腾Ollama，默认镜像拉下来后发现推理还是走CPU，换成rocm镜像才识别出GPU。所以，先确认你的显卡阵营，再决定tag。

Compose版本方面，Compile v2对deploy.resources的支持是完整的，v1在非Swarm模式下经常出问题。安装时请确保是docker-compose-plugin包，而不是老的docker-compose（v1）。

最后是Docker版本。NVIDIA Container Toolkit要求Docker Engine 19.03以上才能用--gpus选项，20.10以上的--gpus和Compose的deploy.resources映射都比较成熟。如果容器一直报could not select device driver "nvidia"，优先查两件事：daemon.json里有没有正确注册nvidia runtime，以及docker是否因为配置改动真正重启过。

4. 启动之后别急着用：三步确认GPU真的在干活

4.1 三步验证法：日志、设备、运行模型

很多人docker compose up -d之后看到容器是running，就以为GPU生效了，实际可能Ollama一直在安静地用CPU跑。我总结了一套三步验证法。

第一步，看容器日志：

bash复制docker logs ollama --tail 50

如果GPU可用，日志里会出现类似inference compute id: GPU或者[gpu]的段落；如果你看到的是no GPU detected或者using CPU，说明GPU没被识别。

第二步，进容器执行nvidia-smi：

bash复制docker exec -it ollama nvidia-smi

这一步能确认容器内是否真的能看到GPU设备和驱动。如果在容器里找不到nvidia-smi，试试nvidia-smi被安装的完整路径，或者检查工具链是否安装。

第三步，也是最关键的：真正加载一个模型后执行ollama ps。

bash复制docker exec -it ollama ollama ps

ollama ps会列出当前加载的模型，并且标注它跑在什么设备上。如果显示PROCESSOR列有GPU字样，说明模型推理确实走了GPU；如果显示CPU，说明GPU链路有问题。

4.2 一个对照实验：CPU模式 vs GPU模式的差距

只看日志可能不够直观，我建议做一个简单的对照测试。

先在不映射GPU的情况下启动一个Ollama容器，加载一个7B参数、Q4量化级别的模型（比如qwen2.5:7b），发一个固定长度的问题，记录生成速度。再切回GPU配置的容器，同样问题再来一轮。我实测下来，7B模型在CPU上大概是每秒10-20个token，换成GPU（消费级显卡）之后能到每秒50-70个token甚至更高，差距非常明显。

更关键的是首token延迟。CPU模式下，模型加载加计算，可能好几秒才蹦出第一个字，GPU模式下基本是秒回。在Dify这类平台里配置Ollama时，这个差距直接决定会不会超时。

这个对照实验还有一个价值：它能帮你确认"GPU配置是否真的改变了推理路径"。如果两个模式耗时几乎一样，那说明GPU根本没起作用，按下面链路排查。

4.3 GPU不生效时的排查链路

我踩过不少坑，按照下面的顺序排查，基本能兜底：

宿主机GPU驱动是否正常：先在宿主机执行nvidia-smi。如果这个命令都报错，先修驱动，后面全都不用看。
Docker是否注册了nvidia runtime：执行docker info | grep -i runtime，看有没有nvidia runtime。
能不能用命令行方式跑通GPU容器：执行docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi，如果失败，问题在工具链层面，和compose文件无关。
compose配置有没有被正确解析：执行docker compose config，在输出里检查deploy.resources.reservations.devices是否完整存在。有时候缩进错误会导致这个配置被静默忽略。
容器日志有没有报错：重点搜索CUDA error、GPU not found、no compatible devices关键词。
显存是否被占满：如果机器上已经跑了其他模型或进程，显存不够时Ollama会主动回退到CPU。执行nvidia-smi看看显存占用。
镜像是否选对：AMD显卡错用latest镜像，永远识别不了GPU，必须用rocmtag。

4.4 CPU/GPU切换的误区

网上经常有人问"Ollama怎么切换GPU模式"，在我看来这个问法有点误导。Ollama本身并没有一个--gpu或者--cpu的启动开关，它的策略是启动时自动检测有没有可用GPU，有就优先GPU，没有就CPU。所谓"切到GPU模式"，其实就是把环境配到让Ollama能检测到GPU，也就是前面说的NVIDIA Container Toolkit + compose里正确映射设备。

反过来，如果某个场景你确实想强制跑CPU（比如显存被别的任务占满了），最简单的办法就是不要映射GPU设备，把compose里的deploy.resources段落去掉，Ollama自然就会用CPU。

多GPU场景下想控制用哪张卡，优先用device_ids指定，而不是在容器里设置CUDA_VISIBLE_DEVICES。因为NVIDIA runtime在注入设备时会覆盖或忽略后者的部分行为，直接在compose层面控制更可靠。

5. 模型下载慢的三种合规提速办法：改路径、导模型、配镜像加速

5.1 为什么下载这么慢

Ollama官方模型仓库的模型文件托管在境外对象存储上，国内网络直连时，建立连接慢、传输不稳定，几十GB的模型经常下到一半就断。这个客观情况是很多人第一次用Ollama就卡住的点。

需要说明的是，这里讨论的提速办法不涉及任何代理工具，全部是合规且在国内网络环境下真实可操作的方案。

5.2 先把模型目录挪到数据盘

Windows用户经常遇到"Ollama怎么安装到D盘"的问题，本质就是模型目录默认在C盘用户目录。最好的解决办法是用环境变量OLLAMA_MODELS指向D盘或其他数据盘。

在Windows裸机场景，可以在系统环境变量里新增：

code复制OLLAMA_MODELS=D:\ollama\models

然后重启Ollama服务。注意：这个变量只影响新下载的模型，之前已经下好的模型需要手动移动目录。

在docker-compose场景，则是用卷映射解决。我给一个统一的约定：模型目录放/data/ollama/models，日志放/data/ollama/logs，跟代码目录分开。好处是容器随便重建、版本随便升级，模型永远不丢；而且如果哪天想换回裸机Ollama，直接把OLLAMA_MODELS指向这个目录就行，两个方案可以无缝切换。

5.3 用Modelfile导入本地GGUF模型

这个方法特别适合"想用某个模型但官方仓库下载太慢"的情况。核心思路是：模型文件不一定非要从Ollama官方仓库拉，可以从国内可正常访问的开源模型平台下载GGUF格式文件，再用Modelfile导入Ollama。

以ModelScope（魔搭）为例，平台上有很多模型的GGUF版本，比如Qwen2.5-7B-Instruct-GGUF。找一个带q4_k_m标识的量化文件，这个量化级别在质量和体积之间比较均衡，7B模型大概4GB多。下载到服务器或者Windows本地后，写一个Modelfile：

dockerfile复制FROM ./qwen2.5-7b-instruct-q4_k_m.gguf

如果需要对模型参数做调整，可以在Modelfile里增加：

dockerfile复制FROM ./qwen2.5-7b-instruct-q4_k_m.gguf

TEMPLATE """{{- if .System }}system
{{ .System }}
{{- end }}
user
{{ .Prompt }}
assistant
"""

PARAMETER temperature 0.7
PARAMETER top_p 0.8
PARAMETER num_ctx 4096

然后在Ollama里创建模型：

bash复制docker exec -it ollama ollama create qwen2.5:7b -f /path/to/Modelfile

创建完成后，ollama run qwen2.5:7b就能正常使用，和从官方仓库拉下来的效果没有区别。

这个方案我强烈推荐，因为国内平台下载速度稳定得多，而且不受Ollama官方仓库的流量波动影响。唯一注意点是：下载的GGUF文件必须是支持Ollama的格式，一般带-ollama后缀或明确标注支持Ollama的才是标准兼容版本；普通GGUF通常也能用，但有时需要调整模板参数。

5.4 给docker pull配置镜像加速器

这个方案针对的是另一个"慢"：docker pull ollama/ollama这个镜像本身拉不下来。注意，Docker镜像加速器只影响Docker镜像的拉取，不影响Ollama模型文件的下载，别搞混了。

配置方法是在/etc/docker/daemon.json里增加registry-mirrors：

json复制{
  "registry-mirrors": ["https://你的加速器地址"]
}

这个地址从哪来？各大云厂商的容器镜像服务控制台会为每个用户分配一个专属加速地址，登录后复制过来填进去就行。部分社区也提供公开加速地址，但稳定性取决于维护者，我自己用下来觉得云厂商分配的地址最稳。

改完重启docker：

bash复制sudo systemctl restart docker

验证是否生效：

bash复制docker info | grep -A 1 "Registry Mirrors"

看到自己配置的地址就说明生效了。之后docker pull ollama/ollama:latest的速度应该会有明显改善。

6. 从单机demo到多服务联动：资源限制、超时治理、日志备份与生产选型

6.1 用compose限制CPU和内存

在多人共用的GPU服务器上，如果不对Ollama做资源限制，它很容易把整机内存吃满。Compose里限制资源的写法如下：

yaml复制    deploy:
      resources:
        limits:
          cpus: '4'
          memory: 8G
        reservations:
          cpus: '2'
          memory: 4G
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

这里limits.cpus: '4'限制容器最多使用4核CPU，memory: 8G限制最多8GB内存。reservations.cpus和reservations.memory是预留量，表示至少保证这么多资源。

有一个认知误区要说清楚：memory限制的是系统内存，管不到显存。显存是NVIDIA runtime直接映射进容器的，Compose没有提供显存限制字段。控制显存靠的是Ollama自身的环境变量，特别是OLLAMA_MAX_LOADED_MODELS=1，这能防止多个模型同时驻留把显存塞爆。

6.2 和Dify等平台联动时的"模型处理超时"

Dify里配置Ollama，模型列表能正常加载，但一发起对话就报"模型处理超时"，这个问题的根因我排查过好几次，基本逃不出三个因素。

第一个是首次加载时间过长。Ollama启动后，第一个请求要先把模型从磁盘加载到内存/显存。一个7B Q4模型大概是4-5GB的文件，从慢速磁盘加载可能耗时几十秒，而Dify侧对上游模型的请求超时通常只有几十秒，于是断了。

第二个是模型被反复卸载。Ollama默认OLLAMA_KEEP_ALIVE=5m，也就是模型空闲5分钟就会被卸载。你在Dify里测完一轮，过一会儿再测，又要重新加载。这种场景下继续用默认配置，超时几乎是必然。

第三个是推理本身太慢。如果GPU没生效、模型在CPU上跑，7B模型生成一句话可能好几秒甚至十几秒，叠加前面的加载时间，轻轻松松超过平台超时阈值。

推荐解法组合：

OLLAMA环境变量设置OLLAMA_KEEP_ALIVE=24h，模型常驻，避免重复加载；
把OLLAMA_NUM_PARALLEL保持为1，别在硬件不支持的情况下强行并发；
Dify侧调大模型连接的超时时间，路径一般在模型配置的高级设置里；
部署完成后先手动发一个请求"预热"，让模型加载完，再接入Dify业务流程。

6.3 日志轮转、备份与升级策略

Ollama容器不像业务系统那样会产生大量日志，但时间长了日志文件也会膨胀，尤其是调试期间反复打CUDA错误日志的时候。Compose里配置日志轮转是一个好习惯：

yaml复制    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

备份方面，最重要的就是模型目录。因为模型是从开源平台重新下载的，理论上不备份也能重新拉，但几十GB的文件重复下载太折磨人。我的习惯是定时用rsync把/data/ollama/models同步到另一块磁盘或者NAS：

bash复制rsync -av --progress /data/ollama/models/ /backup/ollama/models/

升级Ollama容器也很简单：

bash复制docker compose pull
docker compose up -d

升级前先看一眼新版本镜像的日志和发行说明，确认没有破坏性变更。实测下来，模型文件跨版本兼容性一般没问题，但保险起见，升级前备份模型目录准没错。

6.4 和vLLM的选型对比

Ollama和vLLM是两类不同的工具，选型时不能只看热度。Ollama的核心优势是简单易用、API兼容、部署链路短，适合内部工具、个人开发、小团队使用。vLLM的核心优势是高吞吐、生产级并发调度，它用PagedAttention等机制做显存优化，在多并发、长文本场景下吞吐量远高于Ollama。

如果你要服务大量外部用户、追求极致吞吐，那Ollama不是最优解，应该考虑vLLM，它同样可以用docker-compose做生产部署。我的建议是：先用Ollama做快速原型验证，确认模型效果和业务方向；等并发量真的上来了、需要通过压测指标来优化吞吐时，再迁移到vLLM。两者的模型文件管理方式不同，迁移时注意重新加载模型格式，这个步骤我在实际迁移中吃过教训，提前转换能省很多时间。

最后分享两个我现在的固定习惯。第一，模型目录永远放在独立数据盘，路径固定为/data/ollama/models，所有机器保持一致，备份只rsync这一个目录。第二，每次升级Ollama前先docker compose pull，看新镜像日志再决定是否切换，绝不无脑改tag就重启。这套docker-compose方案跑稳定之后，我才真正体会到"部署是一次性的，运维才是长期的"这句话的含义。