小鹅通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服务器里装Doc