简介面向企业技术团队、运维人员与正在选型大模型私有化方案的开发者这份幕僚云私有化部署 Dify、Ollama 与 DeepSeek-r1 的资源包聚焦于在数据不出内网的前提下搭建可用的 LLM 应用服务解决隐私保护、安全合规与个性化落地问题。包内共 36 个文件约 97.99MB核心包括 PDF 部署说明、docker-compose-linux-x86_64 编排文件、daemon.json 与 docker.service 配置以及 docker-27.4.1.tgz 离线安装包另有 30 张按执行顺序命名的关键步骤截图能够完整还原从环境准备、组件安装到联调验证的操作现场覆盖 Docker 离线安装与资源配置等细节。目前已有 4753 人学习下载。通过对照 PDF 与截图读者可以梳理 Dify 应用编排、Ollama 模型运行和 DeepSeek-r1 推理服务的协作关系。结合系统需求分析、环境搭建、安装配置、集成测试等私有化部署要点可帮助少走弯路为后续大模型应用开发与运维打下基础。 我先把话放在前面在企业内部做AI应用落地“私有化部署”这四个字听起来简单真正动手才发现从硬件选型、模型运行到应用编排每一层都有说道。这次项目的代号是“幕僚云”本质是一套完全运行在内网的智能体平台技术栈选了 Dify Ollama DeepSeek-r1。简单说DeepSeek-r1 负责动脑子Ollama 负责把模型在当地跑起来Dify 负责把模型变成业务里能用的应用。数据不出域、模型权重自主可控、应用形态可编排这套组合基本覆盖了政务、金融、企业内部知识库等场景的核心诉求。这篇文章不是什么官方文档复述而是我在真实部署“幕僚云”过程中的完整记录包括需求拆解、环境准备、组件接入、应用落地和问题排查。中间会穿插不少我自己的选型逻辑和踩坑经历。如果你也打算在本地搭一套可用的 AI 应用平台或者正卡在 Dify 与 Ollama 的联通上可以参考这套实操路径。1. 需求拆解与方案选型为什么偏偏是这三个组件1.1 先搞清楚项目真正卡在哪个环节不管项目叫什么名字私有化部署最大的坑是一上来就装环境。装了三天发现模型跑不起来跑起来了又发现业务根本用不上这才是最常见的翻车模式。我在做“幕僚云”的时候第一件事不是装软件而是画了一张需求地图把问题拆成四个维度数据主权文档和数据能不能出内网答案是不能这是底线。模型可控性业务方是否需要基于开源模型做调整、量化、替换需要所以不能绑定闭源API。应用形态要的是无代码快速搭建还是允许团队写代码深度定制希望业务人员也能参与。运维成本这个系统有没有专门的团队长期维护没有尽量选社区活跃、文档成熟的方案。这一通拆完之后方案基本就被推到了“本地模型运行时 开源应用平台”这条路上。再往细了选模型运行层、应用编排层、模型本身的选型就成了三个并列的关键决策点。1.2 三个组件的分工谁做发动机谁做驾驶舱如果把整个系统比作一支决策团队DeepSeek-r1 是出主意的核心大脑Ollama 负责让大脑在本地环境里正常运转Dify 则是把大脑能力输出成业务动作的操作台。先看 DeepSeek-r1。它在数学推理、逻辑分析、代码生成这类任务上表现非常出色而且开放了不同尺寸的权重。我们生产环境常用的 deepseek-r1:7b 量化版对消费级显卡非常友好显存占用可控推理质量在同等规模模型里属于第一梯队。对一个私有化项目来说这是性价比很高的选择。再看 Ollama。它的价值是把“部署模型”这件事从折腾 Python 环境、CUDA 版本、推理框架变成了几条命令。模型下载、启动、API 暴露全部管理好对外提供一个兼容 OpenAI 格式的接口。这样一个轻量级运行层让后续无论接 Dify 还是接其他应用都变得很简单。最后是 Dify。它承担的是最复杂的“应用层”工作知识库管理、RAG 流水线、工作流编排、Agent 机制、模型统一接入、API 发布、多租户权限。我自己写过 LangChain 项目灵活但业务人员上手基本是不可能的Dify 把这种能力可视化相当于给了团队一个可以用鼠标搭建智能体的操作台。1.3 选型对比优势不是每项最强而是组合最省心模型运行层我对比过 llama.cpp、vLLM、TGI。llama.cpp 适合极限低资源环境但接口和生态简陋vLLM 吞吐强但环境依赖重交付成本高Ollama 赢在“够用且简单”一条命令后面就是完整服务。应用平台层也横向看过 FastGPT、MaxKB 和 LangChain 系自研路线。FastGPT 偏知识库问答MaxKB 偏客服场景LangChain 偏开发框架都不是很契合“一个平台承载多个智能体应用”的预期。Dify 工作流、知识库、Agent、插件、多租户都有社区版还免费正好贴合我们的中期规划。模型侧我并非没考虑过 Qwen 和 Llama。Qwen 中文能力很强Llama 生态成熟但结合实际测试DeepSeek-r1 在推理类任务上给到的“过程可解释性”更强再配上较小的量化体积在 16GB 显存级别机器上能做到令人满意的响应速度和输出质量。最后强调一句选型没有最好只有最适合你们的数据和预算。2. 部署前置准备硬件、系统、Ollama 一个都不能省2.1 硬件配置怎么算才够用很多人在第一步就被“配置”劝退。先给一套我实测过的参数参考分为三档档位CPU内存GPU适用场景入门测试8核16GB无/集成显卡deepseek-r1:7b CPU 推理单用户体验推荐标准16核32GBRTX 4070 及以上 16GBdeepseek-r1:7b embedding同时服务几个团队生产增强16核以上64GBRTX 4090 24GB 或更高7b/14b 模型并行、多应用并发、较大知识库做这个表之前我简单算过一道账deepseek-r1:7b 的 Q4_K_M 量化权重约 4.7GB加上 KV Cache 和推理中间态单模型实际占用大概 6-8GB 显存再加上一个 embedding 模型比如 nomic-embed-text 或 bge-m3占几百 MB 到 1GB 左右。所以 8GB 显存是起步线16GB 才会从容。如果你们只是临时验证用 CPU 跑 7B 也不是不行就是响应时间会明显拉长。2.2 系统与 Docker 环境怎么搭生产环境我强烈建议用 Linux。Ubuntu 22.04 LTS 是我测试过最稳的能避开不少 Windows 下容器网络和磁盘权限的坑。Docker 和 Docker Compose V2 必须提前装好。如果你在内网或访问官方源不稳定就提前配好镜像加速器不然后面拉镜像会非常痛苦。磁盘规划也要提前想清楚。Dify 的容器镜像不大但 Docker 日志、向量库数据、模型文件会慢慢膨胀。我们第一次部署就把模型目录放在系统盘结果系统盘直接被占满。后来把 Ollama 模型目录和 Docker 数据目录都挪到了独立的数据盘。Windows 环境下Ollama 可以通过设置 OLLAMA_MODELS 指向 D 盘这样下载的模型就不会堆积在 C 盘。2.3 Ollama 安装、模型下载与目录迁移实操Ollama 的安装没有太多花活按照官方脚本走就行。Linux 常用这一条curl -fsSL https://ollama.com/install.sh | shWindows 直接下载安装包一直点下一步。安装完成后先启动服务再拉模型ollama serve另开一个终端拉取模型ollama pull deepseek-r1:7b这里要说一个实际体验国内网络环境拉模型可能会比较煎熬。我的应对策略是在有条件的内网环境直接通过镜像源下载模型文件然后手动导入到 Ollama 的模型目录。具体方法不复杂下载好模型文件后放到 OLLAMA_MODELS 指定的目录或者用 Docker 方式离线导入。总之不要干等官方源换镜像和内网分发才是正解。再补两个我踩过不少坑的细节。第一Ollama 默认下载目录在 C 盘建议安装前就设置好环境变量 OLLAMA_MODELS指到容量较大的数据盘第二如果服务器需要对外提供模型 API建议设置 OLLAMA_HOST 指定监听地址默认 127.0.0.1 不怕暴露但如果部署的 Dify 在另一台机器就必须改成局域网地址或 0.0.0.0。3. Dify 平台部署与 Ollama 模型接入3.1 Dify 社区版安装步骤Dify 的部署同样不复杂。以 Docker 方式为例先克隆代码然后进 docker 目录启动服务git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d首次启动会创建一组容器包括 API、Worker、Web、PostgreSQL、Redis、Weaviate 或 Qdrant 等。整个过程取决于镜像下载速度正常情况等几分钟就能在浏览器里打开 Dify 界面。默认端口是 80如果你机器上已经有服务占用可以在 .env 里改端口映射比如把 80 改成 8080。升级这块特别容易翻车。社区版更新很快我一开始为了偷懒只拉最新代码然后 docker compose up -d结果版本不一致导致一堆问题。后来老老实实按官方流程来备份数据、docker compose down、重新构建镜像、启动后检查迁移日志。升级失败的锅七八成都是因为跳版本升级或者数据库迁移没跑完。3.2 在 Dify 中配置 Ollama 模型供应商Dify 界面登录后依次进入“设置 - 模型供应商”找到 Ollama点击添加模型。这里最容易卡住的就是 Base URL。如果你是 Docker 部署 Dify容器内部访问宿主机不能直接写 localhost要使用 host.docker.internalhttp://host.docker.internal:11434如果 Dify 不是 Docker 部署而是和 Ollama 在同一台机器上那用 127.0.0.1 就行。模型类型建议分别配置 LLM 和 Embedding 两种。LLM 模型填 deepseek-r1:7bEmbedding 模型我推荐 bge-m3 或 nomic-embed-text按需选择即可。配置完成后点一下“测试”能看到连通成功就表示 Dify 已经能调用本地模型了。3.3 DeepSeek-r1 关闭思考模式的正确姿势用 DeepSeek-r1 这类推理模型时很多人会发现回答前面多了一大段思考过程。在 Dify 里如果不做处理这段内容会直接输出给用户很不友好。处理方式取决于 Dify 版本和 Ollama API。常见做法有两种。第一种在 Dify 的模型配置或提示词中显式告诉模型“不要输出思考过程”但这对推理模型不一定完全有效第二种在调用时关闭思考模式不同版本 Ollama 支持的参数名有差异可能是 thinkfalse也可能是 include_reasoningfalse。我们实测下来关闭思考模式后响应速度提升明显输出token数大幅下降尤其适合对延迟敏感的场景。这里我想多说一句思考模式不是必须关闭。如果业务本身就是做推理问答比如代码分析、数学解题保留思考过程反而能让用户看到模型得出结论的依据但如果是知识库问答、客服场景思考内容就是干扰建议关闭。4. 从模型到应用知识库、工作流与多租户落地4.1 RAG 知识库流水线怎么搭最稳“幕僚云”上线后的第一个应用就是企业内部知识库问答。Dify 里的知识库功能非常直观创建数据集上传文档设置分段规则和索引方式然后把它接到应用里就完成了最基础的 RAG 链路。但“能跑”跟“好用”是两回事。文档分段如果只图省事选自动分段长文档会被切得七零八落检索召回时经常命中断层内容。我建议稍微花点时间自定义分段规则按标题层级或段落边界切分并设置一定重叠让上下文信息更连续。索引模式建议选“高质量”需要用到 embedding 模型语义检索效果远好于关键词匹配。检索策略上我们用的是“向量检索 关键词召回”混合方案对政务类的长表格、专业术语文本尤其管用。早期只开向量检索经常出现关键词完全匹配但语义排序靠后的问题混合后召回率提升了不少虽然会多花一点检索时间但体验上完全可以接受。4.2 工作流搭建实例从知识库到智能问答历史文档接入后我在 Dify 里搭了一个典型的“知识库问答”工作流节点顺序如下开始节点接收用户提问。知识库检索节点在数据集里做混合检索取 Top K 结果作为上下文。LLM 节点调用 deepseek-r1:7b提示词里把用户问题和检索结果一起发给模型。结束节点把 LLM 的输出整理成最终回答。提示词我写得很直白你是一名企业内部智能助手请严格依据提供的上下文资料回答用户问题。 如果资料中没有相关信息请明确说明“资料中未找到”。 不要编造内容不要输出思考过程。 上下文 {{context}} 用户问题 {{query}}这种工作流的价值在于业务人员不需要知道 RAG 的原理只需要在界面里拖拽节点就能把知识库变成可用的业务工具。Dify 的调试面板也很方便单节点输入测试数据、查看每一步的输出结果排查问题效率比瞎猜高得多。4.3 多租户与权限管理怎么做当一个平台开始服务多个团队时权限和隔离就成了刚需。Dify 社区版从 1.10 开始支持多租户体系管理员可以创建多个组织不同组织的成员、应用、知识库相互隔离每个空间可以单独配置模型和 API Key。在实际落地中我建议把“项目隔离”落实在组织层面而不是让所有人挤在一个默认组织里。部门 A 的知识库、工作流、应用和部门 B 互相不可见既避免数据误读也减少误操作。成员角色设为管理员、编辑者、只读成员等按需分配普通成员不给管理权限。对外发布应用时再单独生成 API Key不要复用管理员账号的密钥。如果你对权限要求更严格比如要做到单点登录或细粒度审计可以在前面加一层反向代理和统一身份认证Dify 本身负责应用逻辑身份认证交给更专业的组件。5. 部署过程中踩过的坑与排查方法5.1 Ollama 下载太慢、模型装到 C 盘怎么办这个问题出现频率极高我自己也经历过。总结下来核心就是三步优先用国内镜像或内网分发别在官方源上死等改环境变量 OLLAMA_MODELS把模型目录指到数据盘下载完成后用 ollama list 确认模型是否被正确识别。再补充一个隐蔽问题如果你用 Docker 方式跑 Ollama 容器模型目录不是宿主机的普通目录而是容器挂载卷这时候就算设置了环境变量也要确认挂载路径和权限正确。很多报错并不是模型本身有问题而是容器内找不到目标路径。5.2 Dify 升级后知识库保存时报 internal server error这个坑我印象极深。某次 Dify 升级后用户点“保存知识库”或者修改文档时直接报 500。第一反应以为是代码逻辑问题排查半天最后发现是数据库表结构和旧数据没对齐。我的处理思路可以做一个参考先看 API 容器日志重点找 SQL 错误或索引异常然后检查数据库迁移是否执行完整如果没有明显报错再尝试 docker compose down 后重新构建启动容器。注意升级前一定要做数据备份至少要把 Postgres 和向量库的数据目录完整拷一份不然重建容器时数据丢失哭都来不及。这个问题的根子往往是 Dify 新版本引入了新的知识库元数据字段旧的数据库记录没有默认值写入时触发非法约束。解决办法倒不复杂但必须按步骤来跳过任何一步都可能把环境搞得更乱。5.3 调用 DeepSeek-r1 响应慢、并发低怎么办本地模型响应慢通常不是模型本身菜而是资源没分配好。我常用的优化手段是在 Ollama 环境变量中设置 OLLAMA_NUM_PARALLEL1、OLLAMA_MAX_LOADED_MODELS1避免多模型同时驻留显存导致频繁换入换出。关闭 DeepSeek-r1 的思考模式大幅降低输出 token 数。在 Dify 的应用设置里把流式输出打开用户看到首字时间会更短。如果并发需求确实高一定要上更好的 GPU甚至考虑多卡部署或者改用 vLLM 这类吞吐更强的推理框架。如果你是纯 CPU 环境跑 7B 模型我的建议是别强撑团队内部测试可以真上生产会很难受。5.4 端口冲突和安全暴露问题默认部署下Dify 监听 80 端口。如果机器上有 Nginx 或其他 Web 服务很可能冲突。解决方式是在 .env 中修改端口映射比如把 80 改为 8080再由 Nginx 反向代理到统一域名。安全方面还有几个细节提醒一下Ollama 的 API 尽量只监听内网地址不要直接暴露公网Dify 前必须有 HTTPS 和基本的访问控制应用的 API Key 不要硬编码在代码里通过环境变量保存。私有化部署不是放到内网就万事大吉内网同样有数据泄露和越权风险。写到这儿我个人在“幕僚云”项目里最大的感受是这套组合的技术门槛其实没有想象中高真正的难点在于把模型能力嵌进业务并且让团队愿意持续使用。Dify 最大化降低了应用搭建成本Ollama 让模型运行变得干净利落DeepSeek-r1 提供了可靠的推理底座。实际操作时多备份、看日志、按步骤升级比盲目追逐新版本更稳妥。最后再分享一个小习惯我每次部署完都会把当时的 .env、关键配置和踩坑记录写进项目文档下次升级或重建环境时能省下大量排查时间。希望这份记录也能帮你在自己的部署路上少走几步弯路。本文还有配套的精品资源点击获取