简介：面向企业技术团队、运维人员与正在选型大模型私有化方案的开发者，这份幕僚云私有化部署 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核 | 32GB | RTX 4070 及以上 16GB | deepseek-r1:7b + embedding，同时服务几个团队 |
| 生产增强 | 16核以上 | 64GB | RTX 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.internal：
http://host.docker.internal:11434如果 Dify 不是 Docker 部署，而是和 Ollama 在同一台机器上，那用 127.0.0.1 就行。
模型类型建议分别配置 LLM 和 Embedding 两种。LLM 模型填 deepseek-r1:7b，Embedding 模型我推荐 bge-m3 或 nomic-embed-text，按需选择即可。配置完成后点一下“测试”，能看到连通成功，就表示 Dify 已经能调用本地模型了。
3.3 DeepSeek-r1 关闭思考模式的正确姿势
用 DeepSeek-r1 这类推理模型时，很多人会发现回答前面多了一大段思考过程。在 Dify 里如果不做处理，这段内容会直接输出给用户，很不友好。
处理方式取决于 Dify 版本和 Ollama API。常见做法有两种。第一种，在 Dify 的模型配置或提示词中显式告诉模型“不要输出思考过程”，但这对推理模型不一定完全有效；第二种，在调用时关闭思考模式，不同版本 Ollama 支持的参数名有差异，可能是 think=false，也可能是 include_reasoning=false。我们实测下来，关闭思考模式后响应速度提升明显，输出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_PARALLEL=1、OLLAMA_MAX_LOADED_MODELS=1，避免多模型同时驻留显存导致频繁换入换出。
- 关闭 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、关键配置和踩坑记录写进项目文档，下次升级或重建环境时能省下大量排查时间。希望这份记录也能帮你在自己的部署路上少走几步弯路。
本文还有配套的精品资源，点击获取
