简介面向需要在企业内网搭建私有化AI服务的程序员幕僚云私有化部署DifyOllamaDeepSeek-r1提供了一套可复现的落地资料。资源包内共36个文件包含docker-27.4.1.tgz离线安装包、docker-compose-linux-x86_64编排文件、docker daemon.json与docker.service配置并附一份详细部署说明PDF及30张关键操作截图便于对照检查安装与集成过程。整套资料约97.99MB已有4763人学习下载。读者可按照从环境准备、容器离线导入、服务编排到功能联调的路径逐项推进理解这三者在私有化场景下的协作逻辑快速完成大模型应用平台交付同时保障企业数据隐私与后续运维可控性。1. 幕僚云私有化部署DifyOllamaDeepSeek-r1 的落地取舍做幕僚云这个企业知识助手时我先把方案定在了私有化部署三件套Dify、Ollama、DeepSeek-r1。原因很实际——企业数据不能出内网满血 DeepSeek-r1 的 671B 权重又不是普通预算跑得起的蒸馏版的 7B/14B 落在本地 GPU 上配合 Dify 的知识库和工作流已经能承担大量内部问答与文档检索。这套组合适合手里有一张 8GB 以上显存卡、想把大模型真正跑在内网里的团队。下面从选型、装机、踩坑拆到验证每步给出可直接抄的配置。2. 三件套的分工与选型为什么是 DifyOllama 而不是 vLLM2.1 Dify 管应用Ollama 管推理r1 管脑子在一套私有化部署里三个组件的边界要划清。Dify 是 LLMOps 平台负责应用编排、可视化工作流、知识库RAG、Agent 和对外 API它本身不跑模型只把模型封装成“模型供应商”。Ollama 是模型推理服务ollama serve监听 11434 端口对外提供 /api/generate 和 /api/chat 这类 REST 端点同时自带模型仓库一条ollama pull就能把权重拉到本地。DeepSeek-r1 是推理模型数学、代码和逻辑题上表现强Ollama 仓库里放的是它的蒸馏版1.5B、7B、8B、14B、32B、70B 都有其中 7B 和 14B 的 q4_k_m 量化版对消费级显卡最友好。幕僚云的实际负载是内部知识问答加文档辅助写作核心链路是用户提问→知识库召回→大模型生成。这条链路里Dify 的知识库流水线和 API 发布正好覆盖Ollama 的本地推理保证数据不出内网DeepSeek-r1 蒸馏版在中文指令和推理题上的表现比同体积的通用模型更稳。三者不是并列关系是应用层、推理层、模型层各管一段。拆清楚这条链路后边排错时才知道问题出在哪一层。这三层在运维上的关注点也不一样。模型层要盯显存、量化位宽和上下文长度推理层要盯监听端口、并发数和模型驻留策略应用层要盯知识库的召回质量和对外 API 的鉴权。幕僚云排障时我习惯先分图层应用报错先看 Dify 日志Dify 里报模型超时就查 Ollama两头都正常再怀疑权重文件。分层之后问题定位基本不会超过十分钟。2.2 为什么不选 LM Studio、vLLM 或 Sglang跑本地大模型不止 Ollama 一条路LM Studio、vLLM、Sglang 我都试过。LM Studio 适合 Windows 桌面单人调试图形界面舒服但做服务端要暴露 API、管理并发得额外折腾vLLM 的吞吐和高并发确实强但依赖严格版本的 CUDA 和显存规划中小团队的部署成本偏高Sglang 性能好社区资料却少遇到问题不好查。Ollama 最大的优势是模型管理贴近 Docker 镜像安装、拉取、切换模型都是命令级操作还带一个兼容 OpenAI 的 API 形态Dify 接起来非常顺。选型还要看团队的维护能力。幕僚云这类项目通常不是专职算法团队在维护可能是运维或后端顺手管。Ollama 的升级方式和排错路径比 vLLM 短得多社区检索量也大。后面如果真要支撑几百并发再迁 vLLM 不迟第一步私有化Ollama 是阻力最小的路径。还有一点要提Ollama 直接暴露了 /v1/chat/completions 这个兼容端点任何按 OpenAI 协议写的客户端都能指过来。幕僚云里有一个 FastAPI 写的内部小工具原本面向 OpenAI 接口开发切换成本只是改一下 base_url这比换 vLLM 之后要重写客户端调用省事得多。2.3 模型规格怎么定7B、14B 还是 32B蒸馏版 r1 拉进本地前要先算显存账。q4_k_m 量化下7B 权重约 4.7GB14B 约 9GB32B 约 20GB还要给 KV cache 和中间激活留余量。我在给幕僚云选型时用的是这张对照表模型规格q4_k_m权重体积建议显存适用场景deepseek-r1:1.5b约 1.1GB4GB 或纯 CPU日志分类、简单抽取deepseek-r1:7b约 4.7GB8GB 以上知识库问答、常规 RAGdeepseek-r1:14b约 9GB16GB 以上复杂推理、长文档总结deepseek-r1:32b约 20GB24GB 以上高质量问答、代码生成幕僚云最后同时跑了两个模型知识库主链路用 deepseek-r1:7b需要多步推理时切到 14b。原因是 7B 响应延迟低日常问答体感好32B 在 24GB 卡上能跑但并发一上来 KV cache 会吃掉不少显存小团队没必要赌这个余量。注意这些体积是量化后的近似值以ollama list显示为准。显存不够时优先换更小量化而不是加层数。3. 部署实操从 Ollama 装机到 Dify 接上本地模型3.1 Ollama 安装、离线包与模型存储路径在内网服务器上装 Ollama最快是官方脚本curl -fsSL https://ollama.com/install.sh | sh脚本会自动检测 NVIDIA 驱动、创建 systemd 服务并启动。安装完先确认版本和服务状态ollama --version systemctl status ollama内网没有外网时官方脚本跑不动改用离线安装包。在有网的机器上下载对应架构的 tgz 包amd64 或 arm64拷进内网后解压sudo tar -C /usr -xzf ollama-linux-amd64.tgz解压完手动建 systemd 服务或直接前台跑ollama serve。我习惯是离线装也补一个服务方便开机自启和日志查看。默认模型目录是 ~/.ollama/models系统盘空间紧张时必须改。编辑 systemd 服务配置sudo systemctl edit ollama.service在 [Service] 段写入两行EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_HOST0.0.0.0:11434OLLAMA_MODELS 把权重挪到大分区OLLAMA_HOST 让 Ollama 监听所有网卡而不是只有 localhost这也是后边 Dify 容器访问宿主机的前置条件。改完重启sudo systemctl daemon-reload sudo systemctl restart ollama然后拉模型幕僚云主用 7B 蒸馏版ollama pull deepseek-r1:7b拉完确认权重和显存占用ollama list ollama psollama ps显示当前加载在 GPU 上的模型如果 SIZE 为 0 或跑在 CPU 列表说明驱动没生效或显存不足。再用nvidia-smi看进程Ollama 的进程应出现在 GPU 进程列表里。这一步是“Ollama 怎么调用显卡”的最直接排查点。提示A 卡走 ROCm纯 CPU 也能跑只是慢。先看进程落在哪个设备再怀疑模型本身。3.2 Docker 拉起 Dify 社区版Dify 官方推荐 Docker Compose 部署需要先装好 Docker 和 compose 插件。幕僚云的机器是 Ubuntu 22.04Docker 24 以上执行git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d复制.env这步很多新手会跳过不复制就起服务默认端口和持久化路径会不对。容器起来后看状态docker compose ps等容器全部 healthy打开 http://服务器IP/install 创建管理员账号。Dify 社区版 1.10 之后带工作空间能力多业务线各建一个空间幕僚云直接拿它当多租户边界省掉了自己写的权限层。3.3 在 Dify 控制台注册 Ollama 模型供应商进“设置→模型供应商→Ollama”配置项不多但有几个容易填错模型类型LLM 模型名称deepseek-r1:7b Base URLhttp://host.docker.internal:11434 API KeyollamaBase URL 是最大的坑。Dify 跑在容器里容器内的 localhost 指向自己而不是宿主机。macOS 和 Windows 的 Docker Desktop 自带 host.docker.internalLinux 上不一定有最稳的是填宿主机内网 IP。先确认地址ip addr show eth0 | grep inet拿到 192.168.x.x 的地址后Base URL 填http://192.168.x.x:11434。API Key 在 Ollama 里没有Dify 表单又必填随便填非空字符串比如ollama。保存后点测试如果提示 credentials validation 错误多半是 Base URL 或网络问题下一章展开。同一个 Ollama 供应商下还能添加 Embedding 模型nomic-embed-text 或 bge-m3给知识库用第五章会用到。提示生产环境不要把 Ollama 直接暴露公网让 Dify 和 Ollama 走内网或加反向代理鉴权第六章给做法。4. 避坑记录五个让部署翻车的问题4.1 An error occurred during credentials validation现象Dify 测试 Ollama 模型时右侧直接报一行红字 An error occurred during credentials validation。原因这个报错是 Dify 在保存模型供应商时向后端发了一次连通性测试。十次里有八次是 Base URL 填了 localhostDify 容器访问不到宿主机另一种是 Ollama 只监听 127.0.0.1还有一种是防火墙挡了 11434 端口。解决先在宿主机用 curl 确认 Ollama 本身健康curl http://localhost:11434/api/tags返回 JSON 结构说明服务正常。再查监听地址ss -tlnp | grep 11434如果只有 127.0.0.1:11434按 3.1 节加 OLLAMA_HOST0.0.0.0:11434 并重启。最后把 Dify 的 Base URL 换成宿主机内网 IP重新测试。这条报错在社区被问得最多本质是容器网络和宿主机的 localhost 语义不一致不是模型问题。4.2 Dify SSL 错误https 反代和后端 http 的矛盾现象Dify 用 Nginx 做了 HTTPS 域名反代打开应用页报 SSL 错误或模型调用日志里出现证书相关报错。原因链路不统一。Dify 对外走 HTTPS但 Dify 容器到 Ollama 之间是内网 HTTP一旦模型配置里的 Base URL 被写成 httpsOllama 不支持 TLS握手直接失败。有一部分报错也来自浏览器缓存了旧的重定向记录应用页反复跳转后证书不匹配。解决Ollama 不做 TLS 终结Dify 容器访问宿主时始终用 http外部的 HTTPS 由 Nginx 负责。当时幕僚云是把 Ollama 的 Base URL 误写成了 https 开头改回 http 后问题消失。注意在 Dify 的模型配置或环境变量里看到以 https 指向 Ollama 的地方一律改成 http。Ollama 原生不开 TLS。4.3 工作流上下文超长num_ctx 没跟上现象Dify 工作流把一篇三四千字的 PDF 正文传给 deepseek-r1:7b调用失败日志提示 request too large 或上下文超长。原因Ollama 默认上下文只有 2048 token。推理模型生成时还要吐思维链用户正文加上 CoT 很容易顶穿窗口。解决给 Ollama 注入全局上下文长度sudo systemctl edit ollama.service在 [Service] 段加入EnvironmentOLLAMA_CONTEXT_LENGTH32768重启服务后生效。也可以对单个模型写 ModelfileFROM deepseek-r1:7b PARAMETER num_ctx 32768构建成自定义模型名再用。改完回到 Dify在模型参数里把 max_tokens 设到 4096 到 8192context window 填 32768让 Dify 侧元数据和 Ollama 实际能力对齐否则前端还会按旧窗口截断。4.4 Ollama 下载慢镜像与 GGUF 手工导入现象ollama pull deepseek-r1:7b卡在 pulling manifest或速度只有几十 KB/s。原因默认模型源在海外内网和部分网络环境很慢。拉取是断点续传反复重试没有意义耐心等或换方案。解决首选方案是从 ModelScope 这类国内平台下载 GGUF 文件再本地导入整个过程不依赖公网仓库。把下载好的 GGUF 放到 /data/models 下写一个 ModelfileFROM /data/models/deepseek-r1-7b-q4_k_m.gguf然后执行ollama create deepseek-r1:7b-local -f Modelfile导入后ollama list会出现 deepseek-r1:7b-localDify 里的模型名对应填它即可。这个方法同时解决了内网无外网时的模型获取配合离线安装包整条链路可以完全不依赖公网。4.5 知识库排队中与 ollama serve 段错误现象Dify 知识库上传文档后一直“排队中”索引任务不执行另一台机器上 ollama serve 偶发段错误退出。原因知识库排队通常是 Dify 的 worker 容器没起来或嵌入模型不可用Ollama 段错误一般是模型文件损坏或 CUDA 驱动与 Ollama 版本不匹配。解决先查 Dify 侧docker compose ps docker compose logs worker --tail 100worker 异常就重启嵌入模型走 Ollama 的话先用 curl 测 /api/embed 接口是否通。Ollama 段错误分两步第一步ollama rm deepseek-r1:7b再重新 pull排除文件损坏第二步看 nvidia-smi 驱动版本驱动太老直接升级。我遇到过两次段错误一次是手动导入的 GGUF 不完整一次是旧驱动不兼容新版 Ollama重拉和升驱动后都恢复了。5. 知识库流水线与工作流编排让 DeepSeek-r1 真正干活5.1 分段、嵌入与检索参数Dify 知识库的流水线是上传文档→分段→嵌入→建索引→检索。分段和嵌入的质量直接决定 RAG 效果。给幕僚云设计知识库时用的是这组参数配置项推荐值说明分段方式自动分段按段落空行分割比固定长度自然最大分段长度500 token中文场景 500 左右过长召回噪声大分段重叠50 token避免语义被切在中间索引方式高质量走嵌入模型生成向量检索策略混合检索向量 全文召回再合并TopK5召回 5 段给模型拼接Score 阈值0.5低于阈值的片段直接丢弃嵌入模型挂在同一个 Ollama 供应商下模型类型选 Embedding填 nomic-embed-text 或 bge-m3。bge-m3 中文更好但体积大纯内网小团队用 nomic 也够。文档量到几百份时高质量索引要几分钟不要反复重传。提示混合检索会把向量和全文结果合并适合幕僚云这种既有技术文档又有会议纪要的混合知识库。5.2 工作流节点把知识库和模型串起来Dify 工作流的典型拓扑是“开始→知识检索→LLM→结束”。知识检索节点选择建好的知识库把用户问题作为查询变量LLM 节点选 deepseek-r1:7b或 7b-local提示词里把检索结果拼成上下文。我在幕僚云里用的模板sys_prompt 你是幕僚云知识助手。 基于下面的参考资料回答问题 参考资料 {{#context#}} 要求 1. 如果参考资料没有答案直接回答资料库中暂未收录不要编造。 2. 回答控制在 300 字以内按条理列出。 工作流里{{#context#}}是知识检索节点输出的变量拼成的大文本。这里有个容易被忽略的点知识检索节点要打开“查询变量”绑定用户提问否则检索的是空字符串模型只能瞎答。5.3 思考过程的保留与关闭DeepSeek-r1 是推理模型回答前会先吐一大段思维链在 Dify 应用里可能直接暴露给用户。不想让用户看到思考过程有几个做法一是提示词里加一句“不要输出推理过程直接给出最终答案”对蒸馏版有效但偶尔还会带出短推理二是用工作流出参设置在 LLM 节点后加一个处理节点过滤推理标记三是在 Ollama 侧自定义 Modelfile把模型模板改成引导直接输出的形式。如果你之前调过其他推理模型的思考逻辑思路相同——本质是控制输入模板和输出解析不是改权重。幕僚云最后用了第一招加第二招提示词约束住大部分工作流出口再做规范化把多余推理文本拦掉。6. 验证链路与运维进阶迁移、反向代理和一个习惯6.1 三步验证法部署完不是能聊天就算完。我每次都会跑一条固定链路先 curl 直连 Ollama 确认模型可用curl http://localhost:11434/api/generate -d {model:deepseek-r1:7b,prompt:11?,stream:false}响应里有 response 字段说明模型正常。第二步进 Dify 发布一个 WebApp走一遍“提问→知识库召回→生成”的完整链路。第三步看ollama ps和nvidia-smi确认模型驻留 GPU、显存有余量。三段都过才算交付。6.2 Dify 迁移与模型目录备份Dify 迁移最省事的是打包数据卷恢复到新机器docker compose down docker run --rm -v dify_app_data:/data -v $(pwd):/dest alpine tar czf /dest/dify_backup.tar.gz -C /data .新机上解开恢复OLLAMA_MODELS 目录整个拷走、路径保持一致。权重几十 GB 的话不必重复拷贝重新 pull 或从镜像源导入更快。6.3 Nginx 反代 Ollama 并加 API KeyOllama 没有原生鉴权暴露给内网其他系统时建议加一层 Nginx。CherryStudio 或 FastAPI 调用时统一走这个入口location /ollama/ { proxy_pass http://127.0.0.1:11434/; if ($http_authorization ! Bearer your-secret-key) { return 401; } }配置后请求地址变成 http://内网IP/ollama/带上 Authorization 头才能通过避免了裸奔风险。整套部署的脚本和配置我整理在幕僚云项目里了按这篇笔记走一遍能省下大半周翻文档的时间。这次部署之后我养成了个习惯不管谁交付这套组合强制先走一遍 curl 直连、WebApp 问答、ollama ps 三段验证这让我避开了两次镜像源切换后模型加载不出来的事故。希望帮到你。本文还有配套的精品资源点击获取