简介这份资源面向需要在企业内部落地大模型应用的技术团队与运维人员围绕 Dify、Ollama 与 DeepSeek-r1 三件套提供一套可离线运行的私有化部署方案解决数据不出内网、模型自主可控与业务集成的问题。压缩包共 36 个文件约 97.99MB包含 30 张 png 部署过程截图、1 份 pdf 说明文档、docker-compose-linux-x86_64 编排文件、docker-27.4.1.tgz 安装包、daemon.json 与 docker.service 配置以及 json、tgz 等辅助文件覆盖环境准备、容器编排到服务注册的完整链路。目前已有 4766 人学习下载说明该组合在企业内网场景中关注度较高。读者可借助截图与配置样例还原部署流程理解 Dify 与 Ollama 的对接方式、DeepSeek-r1 模型加载要点及 Docker 环境调优思路适合作为私有化 AI 平台搭建的参考底稿也可用于排查容器网络、镜像拉取与服务启动中的常见问题。1. 从一台闲置服务器说起DifyOllamaDeepSeek-r1 私有化部署到底能干什么很多团队手里都有一两台闲置的 GPU 服务器或者一台配置还行的开发机想跑个大模型做内部知识库、客服辅助、文档摘要但一上来就被三件事劝退数据不能出内网、API 调用成本不可控、现成 SaaS 平台功能太死。Dify 加 Ollama 加 DeepSeek-r1 这套组合恰好把这三个问题一次性解决——Dify 负责编排工作流和前端界面Ollama 负责本地模型推理DeepSeek-r1 负责提供推理能力。整套东西跑在你自己的机器上数据不出门模型可换流程可改。适合谁适合有基本 Linux 操作能力、手里有至少一张 16GB 显存显卡、想快速搭一套内部 AI 应用的开发者或小团队。下面我把这套东西从零到跑通的完整路径拆开讲包括我踩过的坑和参数怎么调。2. 组件选型与资源规划为什么是 Dify Ollama DeepSeek-r12.1 三个组件各自解决什么问题先把角色分清楚不然后面配置容易乱。Dify 是一个 LLM 应用开发平台提供可视化工作流编排、知识库管理、API 发布和 Web 前端。你可以把它理解成一个“AI 应用的操作台”不写前端也能快速搭出对话机器人、文档问答、Agent 流程。Ollama 是一个本地模型运行和管理的工具它把模型下载、加载、推理服务封装成几条命令支持 REST API 调用省去了自己写推理服务的时间。DeepSeek-r1 是模型本身推理能力强尤其在数学、逻辑和代码任务上表现突出有多个蒸馏版本可以适配不同显存。选这套组合而不是其他方案核心理由有三条。第一Dify 对 Ollama 的原生支持比较成熟在模型供应商里直接选 Ollama 填地址就行不需要额外写适配层。第二Ollama 的模型管理足够简单ollama pull和ollama run两条命令就能完成下载和测试对不熟悉推理框架的人友好。第三DeepSeek-r1 的蒸馏版本覆盖了从 1.5B 到 70B 的参数量小显存也能跑起来后续换模型不用改架构。2.2 硬件资源怎么估算显存是硬约束。DeepSeek-r1 的蒸馏版本常见的有 1.5B、7B、8B、14B、32B、70B。量化方式不同显存占用差别很大。我一般按下面这个表来估算实际部署时留 20% 余量模型版本FP16 显存需求Q4 量化显存需求推荐显卡1.5B约 3GB约 1.5GB任意 4GB 以上7B/8B约 16GB约 6GBRTX 3060 12GB14B约 28GB约 10GBRTX 4080 16GB32B约 64GB约 20GB双卡 309070B约 140GB约 40GB多卡 A100内存方面Ollama 加载模型时会把权重读进内存再传到显存建议系统内存不低于显存的两倍。磁盘空间上每个模型文件从几 GB 到几十 GB 不等预留 100GB 以上比较稳妥。CPU 推理也能跑但速度会慢一个数量级只适合验证流程不适合实际使用。2.3 部署架构与网络规划典型部署架构是这样的Dify 以 Docker Compose 方式运行包含 API 服务、Worker、Web 前端、PostgreSQL 和 Redis。Ollama 可以跑在宿主机上也可以跑在另一台 GPU 服务器上。Dify 通过 HTTP 调用 Ollama 的 11434 端口。如果 Ollama 在另一台机器需要确保 Dify 容器能访问到那个地址。我一般会这样规划端口Dify Web 用 80 或 3000Dify API 用 5001Ollama 用 11434。如果服务器有防火墙这几个端口要按需放行。内网部署的话建议把 Ollama 的监听地址设为 0.0.0.0否则默认只监听 127.0.0.1Dify 容器访问不到。提示如果 Ollama 和 Dify 不在同一台机器Ollama 启动时设置OLLAMA_HOST0.0.0.0否则跨机调用会连接被拒。3. 动手部署Ollama 装模型、Dify 起服务、打通调用链路3.1 Ollama 安装与 DeepSeek-r1 模型拉取Linux 下安装 Ollama 最省事的方式是官方脚本一行命令搞定# 下载并安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 设置监听地址允许其他机器访问如果 Dify 在同机可跳过 export OLLAMA_HOST0.0.0.0 # 启动 Ollama 服务 systemctl start ollama systemctl enable ollama # 验证服务状态 systemctl status ollama安装完成后拉取 DeepSeek-r1 的蒸馏版本。以 7B Q4 量化为例# 拉取 DeepSeek-r1 7B 蒸馏版默认 Q4 量化 ollama pull deepseek-r1:7b # 查看已下载的模型列表 ollama list # 命令行测试推理是否正常 ollama run deepseek-r1:7b 用一句话解释什么是递归ollama pull会自动选择适合当前硬件的量化版本如果想指定量化级别可以用deepseek-r1:7b-q8_0这样的标签。ollama run进入交互模式后输入问题能正常返回就说明模型加载和推理没问题。测试时注意看首次加载时间7B 模型在 SSD 上一般 10 到 30 秒如果超过两分钟检查磁盘 IO 和内存是否吃紧。3.2 Dify 的 Docker Compose 部署Dify 官方提供了 docker-compose.yaml直接克隆仓库然后启动# 克隆 Dify 仓库 git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量模板 cp .env.example .env # 编辑 .env重点改这几个参数 # EXPOSE_NGINX_PORT80 # Web 访问端口 # CONSOLE_API_URL # 留空则用默认 # DB_PASSWORDyour_password # 数据库密码 # 启动所有服务 docker compose up -d # 查看容器状态确认全部 running docker compose ps启动完成后浏览器访问http://服务器IP首次进入会要求设置管理员账号。登录后在右上角头像进入“设置”找到“模型供应商”选择 Ollama填入模型服务地址。如果 Ollama 在本机填http://host.docker.internal:11434如果在另一台机器填http://那台机器的IP:11434。填完后点“保存”Dify 会自动拉取模型列表。如果列表为空说明网络不通或者 Ollama 没监听正确地址。常见排查步骤先在 Dify 容器内curl http://host.docker.internal:11434/api/tags看能不能返回 JSON如果不能检查 Ollama 的OLLAMA_HOST设置和防火墙规则。3.3 模型参数配置与工作流接入模型接入后在 Dify 里创建应用时选择“聊天助手”或“工作流”模型选deepseek-r1:7b。几个关键参数需要根据场景调参数作用推荐值说明Temperature控制随机性0.3~0.7知识问答用 0.3创意生成用 0.7Top P采样范围0.9一般不动Max Tokens最大输出长度2048~4096根据显存和需求调Context Size上下文窗口4096~8192越大越吃显存DeepSeek-r1 有个特点它在推理时会输出思维链thinking 部分Dify 默认会把完整输出展示出来。如果只想看最终答案可以在提示词里加一句“只输出最终答案不要展示推理过程”或者在 Dify 的模型配置里关闭“显示思维链”选项。工作流接入时把 Ollama 模型节点拖进画布连接好输入输出就可以像搭积木一样组合知识库检索、条件判断、HTTP 请求等节点。我一般会先跑一个最简单的“输入→模型→输出”流程验证链路确认没问题再加复杂逻辑。4. 避坑与排查部署过程中最容易翻车的五个地方4.1 坑一Ollama 默认只监听本地Dify 容器连不上现象Dify 模型供应商里填了地址保存后模型列表为空日志显示 connection refused。原因Ollama 默认监听127.0.0.1:11434Docker 容器内的host.docker.internal虽然指向宿主机但宿主机上 Ollama 只接受本地回环连接。解决设置环境变量OLLAMA_HOST0.0.0.0后重启 Ollama。systemd 管理的服务可以编辑/etc/systemd/system/ollama.service在[Service]段加EnvironmentOLLAMA_HOST0.0.0.0然后systemctl daemon-reload systemctl restart ollama。4.2 坑二显存不够导致模型加载失败或推理中断现象ollama run时卡在加载阶段或者推理到一半报 CUDA out of memory。原因模型量化版本选大了或者上下文窗口设得太大KV Cache 占用超出显存。解决换更小的量化版本比如从 q8_0 降到 q4_K_M或者把 Context Size 从 8192 降到 4096。如果还是不够用nvidia-smi看是否有其他进程占用显存先释放再试。4.3 坑三Dify 容器内无法解析 host.docker.internal现象Dify 日志报 DNS 解析失败找不到 host.docker.internal。原因这个主机名在 Linux 版 Docker 上不是默认支持的需要手动加映射。解决在 docker-compose.yaml 的 Dify 服务里加extra_hosts: - host.docker.internal:host-gateway然后重启容器。或者直接用宿主机的局域网 IP 代替 host.docker.internal。4.4 坑四模型响应慢首字延迟高现象提问后要等十几秒才出第一个字后续输出也慢。原因模型首次加载需要时间或者 CPU 推理没走 GPU或者上下文太长导致注意力计算量大。解决确认 Ollama 是否在用 GPUollama ps可以看到模型加载在哪个设备上。如果显示 CPU检查 CUDA 驱动和 Ollama 版本是否匹配。另外把 Max Tokens 和 Context Size 适当调小能明显降低首字延迟。4.5 坑五Dify 升级后数据丢失现象重新docker compose up -d后之前配置的应用和知识库全没了。原因Dify 的数据存在 PostgreSQL 和 Redis 的 Docker Volume 里如果升级时用了docker compose down -vVolume 会被删除。解决升级前先备份 Volume用docker compose down不加-v然后docker compose pull docker compose up -d。重要数据定期用pg_dump导出 PostgreSQL 数据。5. 进阶技巧让这套私有化部署真正好用5.1 用 Nginx 做反向代理和 HTTPSDify 默认跑在 HTTP 上内网用没问题但如果要给团队成员访问最好加一层 Nginx 做反向代理并配 HTTPS。配置片段如下server { listen 443 ssl; server_name your-domain.internal; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass http://127.0.0.1:80; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }这样团队成员通过域名访问不用记 IP 和端口。证书可以用内部 CA 签发或者用自签名证书加浏览器信任。5.2 模型切换与多模型共存Ollama 支持同时加载多个模型但显存有限时只能跑一个。我一般会准备两个模型一个 7B 用于日常问答一个 1.5B 用于简单分类任务。在 Dify 里可以针对不同应用选不同模型不用改 Ollama 配置。切换模型时Ollama 会自动卸载当前模型再加载新的首次切换有加载延迟。如果显存够大可以设置OLLAMA_MAX_LOADED_MODELS2让 Ollama 同时保留两个模型在显存里切换时零延迟。但要注意总显存不能超。5.3 验证部署是否真正可用部署完成后我习惯用三个测试来验证第一在 Dify 里建一个聊天助手问一个需要推理的问题比如“一个水池有甲乙两个进水管甲管单独注满需要 6 小时乙管单独注满需要 4 小时两管同时开需要多久”看它能不能给出正确推理和答案。第二上传一个 PDF 文档到知识库建一个文档问答应用问文档里的具体内容验证 RAG 链路是否通。第三用 Dify 的 API 功能通过 curl 调用一次确认外部系统能集成。# 测试 Dify API 是否可用 curl -X POST http://your-dify-host/v1/chat-messages \ -H Authorization: Bearer app-your-api-key \ -H Content-Type: application/json \ -d { inputs: {}, query: 测试一下, response_mode: blocking, user: test-user }返回 JSON 里有 answer 字段就说明 API 正常。这一步很多教程会跳过但实际集成到内部系统时API 能不能通比界面能不能用更关键。从那以后我每次部署完这套东西都会强制走一遍“推理测试→RAG 测试→API 测试”三步少一步都可能在上线后才发现问题。希望帮到你。本文还有配套的精品资源点击获取