Docker部署Ollama踩坑：3個配置參數讓GPU利用率翻倍

國內開發者跑本地大模型，Ollama幾乎是默認選項。但單機裸裝和團隊級部署之間，隔著一道Docker Compose的門檻——跨過去，版本管理、模型持久化、GPU調度才能變成可復現的工程問題。

本文只解決一件事：用Docker Compose拉起一個帶GPU加速、模型不丟、配置可版本控制的Ollama服務。不講Docker基礎，不扯HTTPS反向代理，那些另有專文。

為什么裸裝不夠用了

個人開發機上一行命令就能跑，但場景稍微復雜一點，裸裝的脆弱就暴露出來。

團隊環境里，你把`ollama serve`塞進了systemd還是tmux？模型存在哪個目錄？下次換機器怎么同步？Compose把這些變成一份可review的YAML文件。單節點服務器場景，升級變成改個鏡像tag重啟，模型權重躺在volume里不動。更現實的是，Ollama很少單獨跑——旁邊總掛著Web UI、向量庫、鑒權網關，Compose的`docker compose up`比手動起一堆容器省心太多。

官方鏡像的設計也配合這個思路：默認執行`ollama serve`，暴露11434端口，狀態目錄設計成可掛載。

兩個前置決策：版本鎖定與存儲路徑

動手之前先定兩件事。

版本鎖定用`.env`文件，把`OLLAMA_IMAGE_TAG`從`latest`釘到具體版本。存儲路徑官方文檔指向`/root/.ollama`，掛成named volume或bind mount都行，核心是別讓模型隨容器重建而消失。

以下是一份經過生產驗證的Compose配置，關鍵參數都抽成了環境變量：

services: ollama: image: ollama/ollama:${OLLAMA_IMAGE_TAG:-latest} container_name: ollama restart: unless-stopped ports: - "${OLLAMA_BIND_IP:-127.0.0.1}:11434:11434" volumes: - ollama:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0:11434 - OLLAMA_KEEP_ALIVE=${OLLAMA_KEEP_ALIVE:-5m} - OLLAMA_NUM_PARALLEL=${OLLAMA_NUM_PARALLEL:-1} - OLLAMA_MAX_LOADED_MODELS=${OLLAMA_NUM_PARALLEL:-1}

端口綁定默認鎖在127.0.0.1，需要外網訪問時再改`OLLAMA_BIND_IP`。`OLLAMA_HOST`在官方鏡像里已經是0.0.0.0，顯式寫出來是為了后續覆蓋時不踩坑。

GPU支持：NVIDIA Runtime的配置細節

GPU不是鏡像里自帶的，靠Docker的NVIDIA Container Runtime注入。Compose里加一段`deploy.resources.reservations`：

deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]

這里`count: 1`是保守策略，單卡機器夠用。多卡環境可以改成`count: all`或指定device ID。`capabilities: [gpu]`不能省略，這是NVIDIA Runtime識別設備類型的標記。

宿主機需要提前裝好NVIDIA Docker Toolkit，驗證命令是`docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi`。這一步不過，容器里看不到卡。

三個調參杠桿：內存、并發、模型駐留

官方鏡像暴露的環境變量里，有三個直接影響服務行為。

`OLLAMA_KEEP_ALIVE`控制模型在內存里駐留多久，默認5分鐘。調長可以減少冷啟動，調短可以騰顯存給別的任務。`OLLAMA_NUM_PARALLEL`決定單個模型同時處理多少請求，超過會排隊。`OLLAMA_MAX_LOADED_MODELS`限制同時駐留的模型數量，和顯存容量直接掛鉤。

這三個參數的組合沒有萬能公式。8G顯存跑7B模型，`MAX_LOADED_MODELS`設1，`NUM_PARALLEL`設2是安全線。24G顯存可以嘗試同時駐留兩個不同模型，或者把并行度拉到4。

持久化驗證：模型到底存哪了

配置完先跑一遍拉模型流程，驗證volume掛載是否生效。

`docker compose exec ollama ollama pull llama3.1:8b`之后，在宿主機執行`docker volume inspect ollama_ollama`，看`Mountpoint`指向的目錄里有沒有`models`子目錄。有，說明持久化成功；沒有，檢查volume名稱是否和Compose里的命名一致。

升級鏡像時，改`.env`里的tag，執行`docker compose up -d`。容器重建，模型不動，服務無縫切換。這是Compose相比裸裝最核心的優勢。

最后留個開放問題：你的Ollama部署里，`OLLAMA_KEEP_ALIVE`設了多久？是傾向于省顯存的多模型切換，還是省時間的單模型常駐？