简介针对幕僚云私有化部署DifyOllamaDeepSeek-r1全流程面向有数据安全与隐私保护需求的企业技术人员、AI平台运维人员目标是解决将外部大模型服务落地到内网环境的难题。压缩包共36个文件约97.99MB核心包含部署文档PDF、Docker离线安装包tgz、docker-compose编排文件、daemon.json与service系统服务配置以及30张操作过程截图覆盖从环境准备到组件启动的关键节点。已有4753人学习查看。读者可通过文档配合截图快速复现Dify、Ollama、DeepSeek-r1的私有化组合理解容器化部署、离线安装、服务注册等细节也可将docker-compose与配置文件作为模板迁移到其他机器避免重复踩坑。整套资料结构清晰适合正在规划内部知识库或智能问答平台的技术团队参考。 做幕僚云这个项目我首先面临的不是技术问题而是业务部门反复强调的那句话“数据绝对不能出内网。”这句话直接决定了后面的所有技术选型。云上API再方便在那一刻也基本被排除掉了。最后落地的方案是Dify加Ollama加DeepSeek-r1三层全部自托管模型跑在自己服务器上知识库存在自己的数据库里整个链路不碰公网。这篇文章就从选型逻辑写到部署排错把这个组合从头到尾捋一遍希望对准备做私有化知识库、企业内部助手、政务RAG这类项目的同学有点参考价值。1. 为什么是DifyOllamaDeepSeek-r1这个组合1.1 幕僚云场景的硬约束“幕僚”这个词很有意思它的职责是给决策者提供信息、分析、备选方案。放到系统里就是一个对内提供问答、总结、检索、分析能力的智能助理平台。这类平台最核心的诉求不是聊天而是把企业自己的文档、制度、报表、历史案例变成可以被问答的东西。这就带来三个绕不开的约束数据不出内网。制度文件、合同条款、财务摘要这些内容放在公有云上等于把底牌亮给人家。多种模型可替换。幕僚云不是一次性项目后面可能要接不同模型做不同任务系统不能绑死在一家模型厂商身上。业务人员也要能用。不是每个同事都会写Prompt、调API需要一套可视化的方式把模型能力封装成业务入口。Dify解决的是第3点和部分第2点它是一个开源的大模型应用开发平台知识库、工作流、Agent、模型管理都内置了。Ollama解决的是第1点它把模型推理完全拉到本地一行命令起服务。DeepSeek-r1则是当前在效果和资源消耗之间最平衡的推理模型。1.2 三层架构每一层都能单独换整个系统可以理解成三层的叠加最上层是Dify负责和用户打交道。它把知识库、Prompt模板、工作流编排统一管理起来业务人员在界面上就能配置不需要动代码。中间层是Ollama负责跑模型。它对外暴露一个兼容OpenAI规范的APIDify只需要把它当成一个模型供应商填进去就行。最底层是DeepSeek-r1模型文件负责真正地“思考”和“生成”。模型文件通过Ollama加载到显存里推理过程全在本地完成。这个结构最大的好处是每一层都解耦。哪天我觉得DeepSeek-r1效果不够好想换Qwen只需要在Ollama里拉一个新模型然后在Dify后台添加一个模型供应源工作流里把模型引用改一下其他全部不动。Dify整个坏了也不影响模型层Ollama可以单独对外提供API给别的系统调用。1.3 为什么选DeepSeek-r1而不是其他模型私有化部署最怕的就是模型太大服务器扛不住。DeepSeek-r1在开源模型里属于性价比很高的那类7B量级的版本在普通显卡上就能跑14B量级的版本用一张24G显存的卡也能带起来效果比同参数量的通用对话模型好不少。它本身的训练目标就是推理任务在处理知识库问答、多步分析这类场景时回答的结构性和逻辑性明显更好。更关键的是DeepSeek-r1的思维链reasoning特性非常适合作“幕僚”。它面对一个复杂问题时会先生成一段内部推理过程再给出结论。这在很多场景下是加分项——比如分析一份合同的风险点你不仅想知道“有没有风险”还想知道“为什么判断有风险”思维链正好可以变成答案的推导依据。后文会专门说怎么在Dify里优雅地处理它的思考模式。2. 模型落地的第一个坑下载慢、装哪、选哪个文件2.1 参数量与量化等级怎么选DeepSeek-r1在Ollama上提供的版本常见的有1.5B、7B、8B、14B、32B、70B这几个档位。从“幕僚云”的实际需求看7B和14B是最实用的区间。1.5B只能做玩具验证回答明显发飘不适合正式业务。7Bdeepseek-r1:7b16G内存的机器就能跑CPU推理稍有体验但速度能接受有8G以上显存的显卡会流畅很多。14B效果明显上了一个台阶分析类回答更完整但需要约16G显存或者32G内存跑纯CPU推理。32B及以上效果最好但已经超出普通服务器的承受范围一般要双卡或大显存专业卡。量化等级也要注意。Ollama上的模型一般默认提供Q4_K_M这种量化版本这是官方权衡速度和效果后的选择。如果你显存充足可以拉q8_0版本生成质量会更好一点但体积和显存占用都高出将近一倍。我的建议是先跑默认的q4_k_m版本验证整体链路再决定要不要换更高精度。2.2 通过国内镜像源把模型拉下来很多人在Ollama上用ollama pull deepseek-r1:7b这条命令时卡在下载不动或者几十KB每秒。这不是模型错了而是Ollama默认从海外仓库拉文件内网或者家宽环境下非常慢。解决办法是用国内可访问的镜像源。常见做法是设置环境变量OLLAMA_HOST之外再配置镜像站点。Ollama本身支持通过OLLAMA_BASE_URL调整模型仓库地址吗不支持它没有这么简单的变量。实际操作中有两种主流方式修改Ollama的模型仓库源Ollama支持在启动时指定OLLAMA_MODELS这只是模型存储目录不是仓库地址。要换源一般通过设置HF_ENDPOINT配合某些托管在Hugging Face上的GGUF模型来拉取或者直接用国内社区维护的安装源/镜像脚本。从镜像站下载模型文件后手动导入到一些公开的模型镜像站点下载deepseek-r1-7b-q4_k_m.gguf然后在Ollama中通过ollama create创建本地模型。我实际操作中更推荐第二种的变体找一个靠谱的镜像站点把GGUF文件下载到本地再用类似下面这样一条命令创建模型ollama create deepseek-r1-7b -f ModelfileModelfile内容也很简单FROM ./deepseek-r1-7b-q4_k_m.gguf TEMPLATE {{ .Prompt }}这样绕开了Ollama官方仓库速度取决于你本地带宽稳得多。2.3 把模型装到D盘别塞满C盘Ollama安装包本身不大但模型文件动辄4到8GBC盘很容易被塞爆。Windows下一定要在安装前或者安装后立刻把模型目录改掉。方法是设置环境变量setx OLLAMA_MODELS D:\ollama\models设置完以后重启Ollama服务才生效。在Windows上可以右键右下角托盘退出Ollama再重新启动或者用管理员权限打开PowerShell执行net stop ollama再net start ollama。然后你pull下来的模型就都进D盘了。Linux服务器上同理用export或者在systemd服务配置里加EnvironmentOLLAMA_MODELS/data/ollama/models这个细节如果一开始不做好后面跑起来再迁移模型目录会非常痛苦别问我怎么知道的。3. Ollama运行时的关键配置与API验证3.1 安装完成后先确认服务状态Ollama安装完以后会自动注册成系统服务。Windows上可以在终端跑ollama list看是否正常返回Linux上则需要确认服务在跑systemctl status ollama如果没起来多半是端口被占或者环境变量配置有问题。默认端口是11434检查一下有没有被其他程序占用netstat -ano | findstr 11434 # Windows ss -lntp | grep 11434 # Linux3.2 调整OLLAMA_HOST允许外部访问幕僚云项目里Dify和Ollama很可能不在同一台机器上。Dify通过容器跑在服务器AOllama跑在服务器B这时候Ollama就不能只监听本机回环地址了。Windows下修改环境变量setx OLLAMA_HOST 0.0.0.0Linux下修改systemd配置在[Service]段增加EnvironmentOLLAMA_HOST0.0.0.0:11434改完重启服务。这里有个安全提示Ollama本身没有认证机制监听0.0.0.0等于把接口暴露给了整个内网。建议通过防火墙规则限制只有Dify所在服务器IP能访问11434端口这一步千万别省。3.3 调用DeepSeek-r1时怎么关闭思考模式DeepSeek-r1是推理模型正常调用时它会先输出一段reasoning_content作为思维链再输出正式回答。在纯API调用的场景如果你不想要这段思维链可以在请求参数里加think: false模型会直接跳过推理过程只输出最终回答。Ollama环境里对应的用法是curl http://localhost:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 分析这份合同的主要风险}], think: false }不过实测下来“关闭思考”和“不输出思考”是两回事。关闭思考模式后回答速度会快不少但复杂问题的回答质量也会降一点。在幕僚云这种“辅助决策”的场景我反而建议开着思维链然后在后端把reasoning_content单独存一份只把最终回答展示给用户这样可以兼顾质量和体验。这块后面在Dify工作流里也有对应的处理方式。3.4 用OpenAI兼容接口把Ollama接到其他系统Ollama从某个版本开始提供了OpenAI兼容接口base_url直接填http://ollama地址:11434/v1即可这方便了一些不能直接适配Ollama原生协议的工具。比如在Dify里它的Ollama供应商走的是原生接口而Claude Code、VS Code插件这类工具往往只认OpenAI规范这时候Ollama的/v1路径就有用了。这也是整套架构的一个隐含优势模型层虽然是本地部署的但接口语义是TO B通用的后面不管是接内部SOP系统还是给其他业务平台用都能直接复用这一层能力。4. Dify部署与升级排错4.1 用Docker Compose一键拉起DifyDify官方推荐用Docker Compose部署这也是私有化场景最省心的一条路它把API服务、Worker、PostgreSQL、Redis、向量数据库、Nginx等组件一次性编排起来了。部署步骤很标准git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d这里有两个注意点。一是国内拉取镜像较慢时需要给Docker配置registry mirror把docker.io的镜像源换成国内可用的地址。二是在.env文件里要先把SECRET_KEY改掉默认值在公网上等于裸奔。启动完以后浏览器访问http://服务器IP/首次打开会要求设置管理员账号。Dify社区版从1.10版本开始支持多租户如果你要给不同部门隔离数据可以在初始化界面或者后期通过后台开启。4.2 升级之后知识库报internal server error的排查过程这是热词里出现频率很高的问题“dify升级后无法保存知识库或者修改知识库时报internal server error”。我们项目也踩过当时升级Dify版本后QA同事在后台新建知识库没问题但只要已存在的知识库一点“修改”就报500。我按下面的链路排查的第一步看API容器日志。Dify的前端请求会打到API容器所以先看日志docker compose logs -f api日志里发现一次请求抛出DatabaseError: relation upload_files does not exist。这个报错很关键说明数据库里缺了表基本可以断定是升级过程中数据库迁移没有完整执行。第二步检查API容器与Worker容器的启动状态。Dify的数据库迁移在API容器启动时执行正常情况下新版本起来会自动跑migration。但如果你在升级时没有清理旧容器或者API容器启动失败重试了很久迁移就可能在半路中断。第三步手动触发迁移。Dify的数据库迁移通过Flask CLI执行进入API容器手动跑一次docker compose exec api flask db upgrade执行完以后再次尝试修改知识库问题消失。这个案例给我们的教训很直接升级Dify不能只docker compose pull docker compose up -d就完事要盯着API容器日志确认迁移跑完。另外升级前备份数据库、备份.env文件都是必做项。我们一度因为贪图快直接pull了latest标签后来发现latest在某个提交上有个已知迁移问题所以现在固定使用明确的版本号镜像。4.3 Windows下Dify部署的额外注意点热词里有人问“dify平台在window上的安装”。Dify的Docker Compose部署在Windows上也是能跑的前提是装好Docker Desktop并切换到Linux容器模式。Windows下有个大坑是路径挂载。Compose文件里默认挂载./volumes如果项目克隆在D:\Docker Desktop需要确认共享盘符已经打开否则容器启动时会报“file not found”或者卷挂载为空。另一个坑是.env文件里的EXPOSE_NGINX_PORTWindows上如果80端口被占用改成8080再映射。EXPOSE_NGINX_PORT8080改完访问http://localhost:8080。Windows部署适合做开发验证真正到幕僚云这种生产环境还是建议放到Linux服务器上容器管理、日志排查、资源调度都方便太多。5. Dify接入Ollama和DeepSeek-r1的实操细节5.1 容器内如何访问宿主机上的OllamaDify跑在Docker容器里Ollama跑在宿主机上两者之间通信是第一个要解决的问题。如果直接在Dify后台填http://localhost:11434那是在容器内部找localhost必然不通。Docker容器访问宿主机服务有两个常见地址Linux上使用Docker Desktop的macOS/Windows环境用host.docker.internalLinux服务器上可以用172.17.0.1Docker默认网桥网关指向宿主机最稳的做法是在.env里定义一个变量然后在模型配置时填写# Linux服务器 OLLAMA_API_BASE_URLhttp://172.17.0.1:11434 # 或 macOS / Windows Docker Desktop OLLAMA_API_BASE_URLhttp://host.docker.internal:114345.2 在Dify后台添加Ollama模型供应商进入Dify后台右上角头像进入“设置”找到“模型供应商”添加Ollama。需要填的内容不多模型名称填deepseek-r1:7b必须和ollama list里显示的完全一致Base URL按上文填宿主机可达地址模型类型选“LLM”上下文长度DeepSeek-r1默认上下文一般是4096或8192建议按模型实际情况填写并同步检查Ollama的num_ctx参数是否匹配填完以后先点测试确认连通性和鉴权都没问题再保存。如果测试失败90%的情况是Base URL填错了先回到终端用curl验证一下地址能不能通。5.3 DeepSeek-r1的思考模式在Dify里的处理方案Dify的Ollama供应商有一个参数叫“是否开启思维链输出”新版本里也有对应开关。如果你在对话时发现模型返回的内容里混杂着一大段“嗯用户问的是...让我分析一下...”这类推理文字多半是思维链开关没有关掉。处理方式有两种在模型配置里关闭思维链输出适合大多数问答场景简单粗暴。保留思维链但通过工作流把推理内容和正式回答拆开。Dify的工作流节点里模型的输出会包含text和思考过程你可以用一个“变量聚合器”节点把正式回答传给最终输出把推理内容写入日志或者另一个字段。5.4 用工作流搭一个幕僚知识库问答助手Dify里最常用的流程是知识检索 大模型生成回答也就是RAG。幕僚云场景下我搭了一个包含“意图判断”的工作流开始节点接收用户问题。知识检索节点指定知识库配置检索方式为“向量检索”top_k设为4score阈值设0.3避免召回太分散。LLM节点在提示词里加入检索到的上下文并指定DeepSeek-r1作为模型系统提示词设定为“你是一个严谨的企业内部幕僚助手请基于提供的资料回答不得编造”。结束节点把LLM输出作为最终答复。这里要提醒一个容易忽略的地方知识检索的召回质量直接影响最终回答。Dify的文档分段和Embedding模型是配套的如果Embedding模型也是本地跑的小模型检索效果会温和一些分段大小要适当调小比如每段200到300字重叠50字这样召回率更高。我们最开始用默认的500字分段召回结果总是不够精准把分段调小以后效果提升非常明显。6. 知识库场景的调优与几个替代思路6.1 政务RAG、制度问答这类场景的落地体会热词里有“dify 完成政务 rag 知识库的实践项目”这类场景我们在幕僚云里也做了类似的事。政务制度和业务手册的特点是结构化差、每份文档篇幅大、问题往往需要跨文件回答。我的经验是不要直接在Dify里一股脑把PDF切一切、导进去就完事。建议先做一步文档清洗把扫描件OCR成文字、把表格转成Markdown、把重复的页眉页脚去掉再进Dify。这些预处理工作对最终效果的影响反而比换更大的模型更明显。另外这类场景一定要用提示词约束模型“当资料中找不到答案时明确回答‘资料中未提及’不要自行推断”。本地小模型在生成时天然有“讨好用户”的倾向容易编造内容提示词是最后的防线。6.2 数据分析平台这类延伸场景能不能做热词里还有一个“dify 搭建数据分析平台”这个我们团队也用Dify做过原型。思路是让模型把用户自然语言翻译成SQL查询语句然后通过Dify的代码节点执行查询最后把结果整理成报告输出。但一个诚实的提醒是本地部署的DeepSeek-r1在做SQL生成时效果比通用大模型稍弱表结构复杂的时候经常生成错误SQL。建议把这一步限定在“查询单表聚合数据”的范围内复杂多表关联还是走人工编写固化查询。Dify适合做的是把有限的几个查询场景包装成自然语言入口而不是完全动态生成任意SQL。6.3 数字人、Agent这类进阶玩法再往后走可以给幕僚云接上Agent能力。Dify的Agent节点支持让模型自主决定调用哪些工具比如查日程、对接内部API。本地模型做Agent的约束在于指令遵循能力DeepSeek-r1在简单工具调用场景还可以工具多了就容易乱选工具或者参数格式错误。建议先用工作流把调用链固定下来不要一上来就玩全自动Agent。固定工作流的好处是可控、可排查、出问题能明确到节点这对企业内部工具来说是压倒一切的需求。7. 整体资源规划与部署踩坑清单7.1 一台16G内存的服务器能干什么如果只用来跑幕僚云的MVP版本一台16G内存的机器就够了。部署方案是CPU推理跑deepseek-r1:7b16G内存勉强能跑但并发要限制在1到2个Dify整体容器占用约2G内存知识库的向量检索如果只用默认的weaviate内存占用再加几百兆如果预算允许建议直接上24G显存的消费级显卡比如RTX 3090或4090跑14B量化模型会流畅很多也能支撑3到5个并发。Ollama本身支持并发请求但显存不够时会把多个请求排队体验下降明显。7.2 Windows环境下Ollama装D盘之后还是读到C盘的解决这个坑我帮同事排过两次现象是已经设置了OLLAMA_MODELS到D盘但ollama list里显示模型依然存在C盘。原因基本是两个设置环境变量后没有重启服务Ollama只在启动时读取一次改完必须完全退出并重启。安装时已经用了旧版Ollama模型目录写在配置里。需要删掉C盘旧目录里的内容确认环境变量重新生效。还有一个偏门情况有些Windows环境变量配置在用户变量下但Ollama服务是以系统账户启动的它读的是系统变量。解决方法是把OLLAMA_MODELS同时写到系统变量里。7.3 稳定运行后的日常检查往上走到生产环境后有两件事我建议纳入日常巡检磁盘空间模型文件加Dify的日志和数据库磁盘涨得比你想象快。至少保留20%余量。Dify API容器的Docker日志docker compose日志默认不轮转跑几个月能攒好几个GB建议在/etc/docker/daemon.json里配置日志轮转{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }这个配置需要restart Docker生效建议在项目初期就配好等日志涨到几十GB再回头发愁就晚了。8. 一些值得沉淀的经验整套幕僚云部署下来最大的感受是私有化部署的门槛从来不在“安装”而在“配合和取舍”。Dify给了你编排一切的能力Ollama给了你本地跑模型的自由DeepSeek-r1给了你不错的推理质量但真正决定项目成败的是你对数据、场景和资源的理解。如果说还有什么建议我想说三点第一不要追求一步到位。先用7B模型、少量文档、最简单的问答工作流跑通让业务人员看到效果再逐步扩知识库、换更大模型这种增量式推进在企业里的成功率远高于憋大招。第二日志和监控前置。Dify和Ollama都支持日志输出务必备份好Docker容器日志关键时刻能救命。尤其Ollama开启访问日志后可以看清每个请求的耗时和token消耗对判断性能瓶颈帮助极大。第三默认情况下先关掉DeepSeek-r1的思考模式往外发但保留一段用于调试。当用户觉得回答不可信时你至少有推理过程可以回溯这在企业场景里很重要。这套架构从部署到运行已经在我们内部服务了好几个业务模块后续我打算继续把Dify工作流里的知识检索节点与公司的统一权限体系打通让不同部门只能看到授权范围内的文档。如果有机会再单独写一篇关于Dify工作流里权限控制实现的文章。本文还有配套的精品资源点击获取