这两年本地部署大模型几乎是每个做 AI 应用的技术团队都要过的坎。我们内部评估了几个方案最后还是选了 Docker 加 Ollama 的组合。这套方案最核心的价值就是把模型运行时封装成一个干净的黑盒宿主机上不需要装 Python、CUDA 全家桶也不会因为某个依赖版本冲突把开发环境搞坏。你只需要一个容器镜像、一个模型目录挂载、一个 API 端口整个模型服务就能按需启动、随时销毁、任意迁移。这篇文章我把从零到可用的全过程记录下来包括踩过的坑、参数调优的经验和日常维护要点适合两类人看一类是想在本地电脑上快速跑通一个对话模型做试验的开发者另一类是准备给团队或内部系统提供私有模型 API 的运维或后端同学。1. 为什么推荐 Docker 方式部署 Ollama1.1 Ollama 到底解决了什么问题Ollama 本质上是一个本地大模型运行时管理器。它把模型的下载、加载、推理、卸载这一整套生命周期都管起来对外暴露一个 OpenAI 兼容的 REST API端口默认 11434。你不需要关心模型文件存放在哪个目录、用什么采样参数、CUDA 层怎么初始化一条命令就能把模型跑起来。对比直接在 Python 里用 transformers 加载模型Ollama 的好处很明显首先是模型文件是分层的一层层校验和去重重复下载浪费少其次是它自带模型量化格式的支持同样的模型在消费级显卡上能跑的量级比原始 fp16 权重小很多再一个是 API 层非常稳定换模型不换接口上层应用不用改代码。1.2 Docker 部署和裸机安装怎么选我最早是在一台测试机上裸机装的 Ollama。安装确实简单一条 curl 脚本搞定但问题都出在后面升级 Ollama 版本时要担心会不会动到系统库多个项目共享一台机器时不同项目想用不同版本、不同模型目录直接冲突最麻烦的是换机器模型重下、环境重装半天就没了。Docker 方式把这些痛点一次解决。镜像版本和宿主机完全隔离升级就是换 tag 重建容器模型目录通过 volume 挂在宿主机上容器删了数据还在迁移时只要在目标机器上装好 Docker一条 docker run 就能恢复服务。如果团队里有人已经配好了一整套环境把 compose 文件发过去大家跑出来的结果完全一致。我个人的结论是如果你只是在自己电脑上偶尔玩玩裸机装的便利性确实更高但只要涉及多台机器、多人协作或者对外提供服务直接上 Docker省掉后面所有环境纠纷。2. 部署前的环境判断与镜像选型2.1 硬件评估先算清楚跑不跑得动很多人上来就问我要多大的机器其实这个问题可以拆成三部分模型规模、推理精度、并发需求。记忆容量是最硬的门槛。模型的加载占用大约等于参数量的两倍乘以精度权重7B 模型用 Q4_K_M 量化差不多需要 4-5GB 显存13B 量化后要 8-10GB32B 量化后大概 18-20GB。没有独显纯靠 CPU 跑也不是不行但速度会被内存带宽卡死7B 模型通常每秒只能出几个 token体验很差。所以我的建议是先用 ollama 自带的能力跑一下模型nvidia-smi 观察显存占用如果 OOM 就换更小量化或者干脆换更小的模型。并发需求影响的是显存的预算因为 Ollama 默认会缓存多个已加载模型的上下文。OLLAMA_MAX_LOADED_MODELS 控制同时加载几个模型OLLAMA_NUM_PARALLEL 控制每个模型同时处理几个请求。想同时服务几十个请求就别指望消费级显卡了老老实实上多卡或加多节点。2.2 官方镜像怎么选版本怎么锁定Ollama 官方在 Docker Hub 上维护了 ollama/ollama 镜像。我这里实操的时候习惯锁定具体版本而不用 latest因为模型服务的接口和参数在版本之间会有细微变化用 latest 等于把稳定性交给运气。镜像本身的体积很小基础层就几百 MB 的 Linux 运行时。我们用的 x86_64 架构只需要一个 tag如果你有 ARM 的 Mac 或者 ARM 服务器镜像会自动匹配对应架构。拉取的时候建议把 digest 也记下来特别是对公网镜像源有访问波动的环境锁定 digest 可以保证每次拉到的内容完全一致。3. 实战把 Ollama 容器跑起来的完整过程3.1 三条核心命令把服务拉起来先展示最基础的一行命令docker run -d \ --name ollama \ -v ollama_models:/root/.ollama \ -p 11434:11434 \ ollama/ollama:latest这里有三块值得说清楚。第一-v 挂载的是模型目录/root/.ollama 是容器内 Ollama 存放模型和配置的地方。注意我用的不是本机路径而是命名卷好处是路径不依赖宿主机具体结构备份迁移也更规范。第二-p 暴露端口宿主机 11434 映射容器 11434。如果你的宿主机 11434 已经被占改左边就行比如 11435:11434。第三容器默认会以 root 身份运行模型目录权限正常不需要额外处理。跑起来之后先确认服务活着curl http://localhost:11434如果返回 Ollama is running说明基本盘已经稳了。3.2 在容器里下载模型并跑第一个对话模型管理命令是在容器内部执行的所以要用 docker exec。下载并运行模型的命令是docker exec -it ollama ollama run qwen2.5:7b这里需要注意 ollama run 会把模型拉下来并进入交互式对话如果只想下载不进入对话就用 ollama pulldocker exec -it ollama ollama pull qwen2.5:7b-instruct-q4_K_M模型 tag 的命名里藏着关键信息。冒号前面的部分是模型系列后面是精度版本。同一个模型系列会有 0.5B、1.5B、3B、7B、14B 等多个尺寸以及 q4_K_M、q8_0、fp16 等不同量化。建议从 q4_K_M 起步验证链路稳定后再根据显存余量上调精度先把链路跑通永远比一步到位更重要。对话测试可以直接进交互模式问几句也可以走 APIcurl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 用一句话介绍自己, stream: false }返回的 JSON 里 response 字段就是模型输出。到这里一个可用的本地模型服务已经跑起来了。3.3 几个必须知道的环境变量Ollama 容器支持通过环境变量调整行为我实际调过比较多的有这几个环境变量作用我常用的值OLLAMA_HOST监听地址默认 0.0.0.0:11434一般不用改OLLAMA_MODELS模型存放路径配合卷挂载默认即可OLLAMA_KEEP_ALIVE模型保持加载的时间单位秒短任务设 5m常驻服务设 -1OLLAMA_NUM_PARALLEL单个模型并行处理请求数1-4根据显存调OLLAMA_MAX_LOADED_MODELS同时保持加载的模型数量1-2OLLAMA_KEEP_ALIVE 特别值得提一下。默认行为是模型在请求结束后继续驻留内存一小段时间避免频繁换入换出。但对那些每天只有零星请求的测试环境模型一直占着几个 G 显存很浪费。我把这个值设成 300让它在空闲 5 分钟后自动释放内存压力小很多。GPU 支持这块要在 docker run 里加 --gpus all并且宿主机上要装好 NVIDIA 容器工具包。这块我后面在问题排查里细讲。3.4 用 Compose 固定整套环境等项目稳定下来我不建议继续敲 docker run 记忆参数而是写一个 compose 文件把整套配置沉淀下来。下面是我常用的模板services: ollama: image: ollama/ollama:0.5.7 container_name: ollama volumes: - ollama_models:/root/.ollama ports: - 11434:11434 environment: - OLLAMA_KEEP_ALIVE300 - OLLAMA_NUM_PARALLEL2 deploy: resources: limits: memory: 32g restart: unless-stopped volumes: ollama_models:deploy.resources.limits 是给容器加内存上限的。这么做不是为了限制性能而是防止某个异常请求把内存吃满拖垮整台机器。restart: unless-stopped 保证宿主机重启后模型服务自动回来不用人肉 ssh 进去起容器。4. 高频问题与排查实录4.1 模型下载慢或者一直卡住最常见的现象是 ollama pull 的时候进度条半天不动或者下载到 95% 直接失败。这个问题的根源基本是模型文件碎片化分片多、单片校验失败就得重试。我的处理手法是先把网络环境的稳定性搞定找一个对目标源访问顺畅的时间窗口拉取万一失败多次不要反复在同一目录重试把断点缓存目录清理后重新 pull。如果网络环境确实不稳定还有一个好用的办法找一台连通性好或有镜像缓存的机器把模型拉好然后直接把整个模型目录打包拷贝到目标机器的 volume 里。因为模型文件本质上就是目录里的分层数据拷过去后 ollama pull 校验到本地已经有对应层就直接复用不会重新下载。这个方法在完全隔离的内网环境里尤其好用。4.2 容器起来了但 GPU 用不上docker run 里加了 --gpus all但 nvidia-smi 在容器里看不到显卡这类问题十有八九是宿主机缺 NVIDIA Container Toolkit。只装了显卡驱动是不够的Docker 默认不把 GPU 设备暴露给容器需要额外安装工具包并在 Docker 的 runtime 配置里把 nvidia 作为默认 runtime。装好之后简单验证docker run --rm --gpus all 镜像 nvidia-smi能看到显卡信息就说明通了。还有一种情况是驱动版本太旧和当前 CUDA 版本不兼容表现为容器能启动但 Ollama 加载模型时直接回退到 CPU。判断方法是看 Ollama 日志里有没有 NVIDIA GPU 相关的初始化记录没有就是没识别到。4.3 容器删除后模型不见了很多人第一次踩这个坑是因为创建容器时没挂载模型目录模型下到了容器可写层里。容器一删可写层直接被清掉模型全部报销。解决方式就是在创建容器时就用 -v 挂载 /root/.ollama这是唯一的持久化路径。如果已经踩坑了也不要慌。容器删除前如果还在可以先把模型目录 docker cp 出来再重建容器时挂回去模型不会丢。我最早一次迁移就是靠这个办法把几十 G 的模型从测试机搬到新机器上没有重新下载。4.4 显存溢出与并发调优Ollama 的默认行为是尽量把多个模型都留在显存里换来快速切换。但你同时加载 3 个 7B 模型显存可能直接爆炸。表现就是推理速度突然变得极慢或者进程被系统 OOM Kill。我的调优顺序是先看 nvidia-smi 确认每个模型的显存占用然后设置 OLLAMA_MAX_LOADED_MODELS1 让不用的模型尽快卸载再根据实际并发把 OLLAMA_NUM_PARALLEL 调低。另外一个隐蔽的参数是上下文长度越长越吃显存对话上下文可以设短一点批量摘要任务可以设长一点这需要按场景取舍。5. 让模型服务真正融入业务5.1 开放 API 给其他容器如果模型服务要对接业务后端最干净的方式是放到同一个 Docker 网络里容器间用服务名互相访问而不是走宿主机端口。在 compose 文件里加一段networks: app_net: ipam: config: - subnet: 172.20.0.0/24然后把 ollama 服务和业务服务都加入这个网络。业务容器里请求地址写成 http://ollama:11434Docker 内置 DNS 会自动解析既不用暴露端口给外网也少了一层 NAT 转发。5.2 接一个可用的 Web 界面纯 API 对开发友好但对业务同事或者拿来演示就不够直观。我们在内部环境接了一个开源的 Web UI 容器页面里能选模型、管理和切换对话本质上也是把 /api 接口包了一层前端。两个容器并排在 compose 里网络互通端口对外只暴露 Web 界面模型接口仍然留在内网。这类 Web UI 容器对接 Ollama 的方式很标准设置环境变量指向 ollama 服务的地址和端口启动后访问界面首次登录进去就能在模型列表里看到我们预先 pull 好的模型。5.3 日常维护和备份Ollama 的数据其实很轻主要就是模型分层的 blob 文件加少量配置。日常维护我把三件事做成习惯第一模型列表定期巡检docker exec ollama ollama list 看有没有不再用的大模型该删就删磁盘空间在模型目录下说没就没第二volume 的备份用 tar 打包命名卷就行恢复到新机器时 docker run -v 挂回去模型服务直接就起来了第三日志重点看模型加载和请求超时写一个简单的监控脚本把 /api/version 的响应时间作为健康指标异常就告警。我个人在这套方案上踩过最大的坑是早期没有锁定镜像版本某次升级后模型加载策略变了线上接口的响应时间翻了一倍。后来我把镜像版本、环境变量、模型清单全部沉淀成 compose 文件并做版本管理每次变更都留记录这个问题再没出现过。如果你也正准备把本地模型服务化建议不要在最开始追求大模型高精度先用一个小模型把 Docker 部署、API 调用、Web 界面这条链路全部跑通再逐步切换到业务真正需要的模型规格。这套路径我已经在多个项目里验证过上手成本低后续扩展也顺。