1. 为什么要在本地跑 LlamaDockerOllamaDify 能解决什么很多人第一次接触大模型都是从网页对话框开始的。用起来确实方便但一旦你想做点“自己的东西”问题就来了数据要传到别人服务器、模型版本不能自己选、想微调一个行业模型根本没入口、接口调用还有额度和费用限制。尤其是做企业内部知识库、代码助手、客服机器人这类场景数据不出内网几乎是硬性要求。本地部署大模型核心诉求其实就三个数据可控、模型可换、成本可预期。而 Docker Ollama Dify 这套组合恰好把这三件事都覆盖了。Ollama 负责把模型跑起来提供类似 OpenAI 的 HTTP 接口Docker 负责环境隔离避免把本机 Python、CUDA 版本搞乱Dify 负责上层应用编排让你用可视化界面就能搭出对话机器人、知识库问答、Agent 工作流。这套方案特别适合几类人一是个人开发者想在自己笔记本上验证想法没有独立显卡也能跑二是中小企业技术团队想在内网搭一个可用的 LLM 服务又不想一上来就买 A100三是学生和爱好者想搞清楚大模型推理服务到底是怎么一回事从拉模型到发请求全流程走一遍。CPU 能不能玩能。Llama 3.1 8B 的 Q4 量化版本大概 4.7GB在 16GB 内存的普通笔记本上用 Ollama 跑起来做单轮对话响应速度大概每秒几个 token虽然比不上 GPU但用来做功能验证、接口联调、Prompt 调试完全够用。如果你只是想让 Dify 里有个能用的模型而不是追求生产级吞吐CPU 方案是性价比最高的起点。我试过在一台没有独显的迷你主机上跑这套组合Docker 起 Ollama拉 llama3.1:8b 的量化版再起 Dify整个流程走下来大概 20 分钟中间主要时间花在镜像拉取和模型下载上。下面我把每一步拆开讲配置可以直接复制。2. 前置准备Docker 环境与 Ollama 镜像拉取常见报错在开始之前你需要确认本机已经装好 Docker 和 Docker Compose。Windows 和 macOS 直接装 Docker Desktop 就行Linux 用官方脚本或者包管理器安装。验证命令docker --version docker compose version如果docker compose version报错说明你装的是老版本需要单独装 compose 插件。Ubuntu 下可以这样sudo apt-get update sudo apt-get install docker-compose-plugin接下来是镜像拉取。国内网络直接拉ollama/ollama和dify相关镜像可能会很慢甚至超时。你可以给 Docker 配置镜像加速编辑/etc/docker/daemon.jsonWindows/macOS 在 Docker Desktop 设置里改{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com ] }改完重启 Dockersudo systemctl restart docker然后拉取 Ollama 镜像docker pull ollama/ollama这一步常见的报错是Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: TLS handshake timeout基本都是网络问题换镜像源或者多试几次。另一个报错是no space left on device说明磁盘不够Ollama 镜像加上模型文件建议至少留 20GB 空间。如果你打算用 GPU还需要装 NVIDIA Container Toolkit然后验证docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smiCPU 用户跳过这步直接往下走。Dify 的代码建议 clone 到本地方便改配置git clone https://github.com/langgenius/dify.git cd dify/docker如果 git clone 慢可以用 gitee 的镜像仓库或者直接下载 zip 包。进到dify/docker目录后先别急着up把.env.example复制成.envcp .env.example .env这个文件里定义了 Dify 用到的数据库密码、端口、向量库类型等。默认配置够用但如果你本机 80 端口被占用需要改EXPOSE_NGINX_PORT。3. 可复制配置docker-compose 启动 Ollama 与 Dify 接入参数先起 Ollama。我建议单独写一个docker-compose-ollama.yml和 Dify 分开管理这样模型服务重启不影响 Dify。services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - 11434:11434 volumes: - ollama_data:/root/.ollama environment: - OLLAMA_KEEP_ALIVE24h - OLLAMA_HOST0.0.0.0 volumes: ollama_data:如果你有 NVIDIA GPU在services.ollama下加deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu]启动docker compose -f docker-compose-ollama.yml up -d然后拉模型。Llama 3.1 8B 的量化版对 CPU 友好docker exec -it ollama ollama pull llama3.1:8b如果下载慢可以先拉小一点的llama3.2:3b做验证docker exec -it ollama ollama pull llama3.2:3b拉完后确认模型列表docker exec -it ollama ollama list接下来起 Dify。在dify/docker目录下docker compose up -d默认会启动 api、worker、web、postgres、redis、weaviate、nginx 这几个容器。等一两分钟访问http://localhost看到 Dify 登录页就成功了。第一次需要注册管理员账号。登录后点右上角头像 → 设置 → 模型供应商 → 找到 Ollama → 添加模型。关键参数参数值说明模型名称llama3.1:8b必须和ollama list里一致Base URLhttp://host.docker.internal:11434Docker 内访问宿主机模型类型LLM对话模型选这个上下文长度8192Llama 3.1 支持 128K但 CPU 跑建议调小最大 token2048根据内存调整Linux 下host.docker.internal可能不生效需要改成宿主机 IP或者在 Dify 的 compose 文件里给 api 和 worker 加extra_hostsextra_hosts: - host.docker.internal:host-gateway保存后Dify 会测试连接。如果显示绿色成功说明 Ollama 的 API 已经能被 Dify 访问到。4. 验证请求用 curl 和 Dify 对话确认 Llama 服务可用先绕过 Dify直接测 Ollama 的 API确认模型本身没问题curl http://localhost:11434/api/generate -d { model: llama3.1:8b, prompt: 用一句话解释什么是 Docker, stream: false }如果返回 JSON 里有response字段说明 Ollama 正常。CPU 机器上第一次请求会慢一些因为要加载模型到内存大概等 10 到 30 秒。之后请求会快很多因为OLLAMA_KEEP_ALIVE24h让模型常驻。再测 OpenAI 兼容接口curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: llama3.1:8b, messages: [{role: user, content: 你好介绍一下你自己}] }这个接口格式和 OpenAI 一样方便你后面用其他工具接入。然后回到 Dify创建一个“聊天助手”应用模型选刚才添加的llama3.1:8b在对话框里输入“你好”如果能看到流式输出说明整条链路通了。Dify 里还可以看到每次请求的 token 消耗、耗时。CPU 环境下8B Q4 模型大概每秒 3 到 8 个 token3B 模型能到每秒 10 到 20 个 token。如果你觉得慢可以在 Ollama 的 Modelfile 里调参数比如减小num_ctxdocker exec -it ollama ollama run llama3.1:8b /set parameter num_ctx 2048 /save llama3.1:8b-fast然后在 Dify 里把模型名改成llama3.1:8b-fast。如果你需要更稳定的 API 服务或者想在内网多台机器之间共享模型可以考虑用 TaoToken 的 API 网关做统一入口。它的 API 地址是https://taotoken.net/api支持标准的 OpenAI 兼容协议适合把本地 Ollama 和云端模型做统一路由。具体接入方式可以参考官方文档https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 在控制台里创建 API Key 后把 Base URL 填到 Dify 的自定义模型里就行。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节列几个我实际踩过的坑基本都是配置问题不是模型本身的问题。报错一401 Unauthorized如果你在 Dify 里接的是 OpenAI 兼容接口但没填 API Key或者 Key 填错就会报 401。Ollama 本地默认不需要 Key但 Dify 的某些模型类型会强制要求填一个。解决办法在 Dify 的模型配置里API Key 随便填一个非空字符串比如ollama因为 Ollama 不校验。如果你用的是 TaoToken 这类网关401 通常意味着 Key 无效或过期去控制台重新生成一个https://taotoken.net/api-keys 。报错二local proxy failed 或 connection refusedDify 容器里访问http://localhost:11434会失败因为 localhost 指的是容器自己不是宿主机。必须用host.docker.internal或者宿主机局域网 IP。Linux 下如果host.docker.internal不解析按前面说的加extra_hosts。另一个可能是 Ollama 没监听0.0.0.0。检查docker exec -it ollama env | grep OLLAMA_HOST如果没有输出说明没设默认只监听 127.0.0.1容器外访问不了。在 compose 里加上OLLAMA_HOST0.0.0.0重启。报错三reading choices 或 JSON decode error这个通常出现在 Dify 调用模型后解析响应时。原因可能是 Ollama 返回的不是标准 OpenAI 格式或者模型输出被截断。检查 Dify 的模型配置里模型类型选的是“LLM”还是“Text Embedding”。对话模型必须选 LLM。另外把max_tokens调大一点避免输出被截断导致 JSON 不完整。报错四OAuth 相关错误Dify 本身不涉及 OAuth但如果你接的是某些云厂商的模型可能会遇到。本地 Ollama 场景下这个报错一般是因为你在 Dify 里选错了模型供应商比如选了“OpenAI”却填了 Ollama 的地址。正确做法是选“Ollama”供应商或者选“OpenAI-API-compatible”并手动填 Base URL。报错五模型加载失败提示 out of memoryCPU 跑 8B 模型内存至少 16GB。如果只有 8GB建议换llama3.2:3b或者qwen2.5:3b。另外Docker Desktop 默认给虚拟机的内存可能只有 2GB需要在设置里调到 8GB 以上。报错六Dify 容器启动后访问 502等 30 秒再刷新Dify 的 api 容器启动需要初始化数据库。如果一直 502看日志docker compose logs -f api常见原因是.env里数据库密码和 postgres 容器不一致或者端口冲突。6. 从本地验证到长期使用模型管理与接入建议本地跑通之后你可能会想这套东西怎么长期用我的建议是分三层管理。第一层是模型层。Ollama 的模型都存在ollama_data卷里你可以定期备份docker run --rm -v ollama_data:/data -v $(pwd):/backup alpine tar czf /backup/ollama_data.tar.gz -C /data .恢复的时候反过来解压。如果你微调了自己的模型用ollama create导入docker exec -it ollama ollama create my-model -f ./ModelfileModelfile 里写FROM ./my-model.gguf和参数。第二层是应用层。Dify 的工作流、知识库、Prompt 都可以导出成 DSL 文件方便迁移和版本管理。在应用设置里点“导出 DSL”就行。第三层是接入层。如果你只是自己用Dify 的 Web 界面够了。但如果要给团队用或者要接入其他系统建议统一走 API 网关。TaoToken 的 Coding Plan 适合长期编码和 Agent 场景模型对话适合快速验证不同模型的效果接入文档里有详细的 Base URL 和参数说明https://taotoken.net/doc 。把本地 Ollama 和云端模型都注册到网关里上层应用只认一个入口切换模型不用改代码。最后说一个实用技巧CPU 跑模型Prompt 长度对速度影响很大。同样一个问题500 token 的 Prompt 和 2000 token 的 Prompt首 token 延迟能差好几倍。所以在 Dify 里做知识库检索时把 top_k 调小比如 3 到 5召回片段长度控制在 500 字以内整体响应会快很多。如果你想让 Ollama 在后台常驻并且开机自启Docker 的restart: unless-stopped已经够了。但要注意模型加载到内存后不会自动释放如果内存紧张可以设OLLAMA_KEEP_ALIVE5m让模型 5 分钟无请求后卸载。整套流程走下来你会发现本地大模型服务没那么神秘。Docker 解决环境Ollama 解决推理Dify 解决应用三者各司其职。CPU 方案虽然慢但作为开发验证环境成本低、可控性强值得每个想深入 LLM 应用的人搭一遍。