Dify本地部署完全指南：零基础搭建私有AI工作流平台

为什么选择 Dify 做大模型应用开发

在大模型应用开发的浪潮中，Dify 已成为企业和开发者的高频工具之一。Dify 是2023年兴起的开源LLMOps（大模型运维）平台。LLMOps是MLOps（机器学习运维）在大模型时代的延伸——MLOps诞生于2019年前后，旨在将DevOps工程实践引入机器学习生命周期，解决模型从实验室到生产环境的「最后一公里」问题。LLMOps在此基础上针对大语言模型的特殊性做出调整：传统MLOps关注结构化数据上的监督学习管线，LLMOps则需应对非结构化文本、超长上下文窗口、Prompt工程等新挑战，其评估维度也从准确率、AUC等可量化指标，演进为LLM-as-a-Judge等更接近人类判断的新型评测方法论。LLMOps专注于大语言模型从开发、测试到生产部署的全生命周期管理，涵盖Prompt版本控制、模型评估、数据集管理和监控告警等环节。

Dify的核心架构基于RAG（检索增强生成）管道和Agent编排引擎。RAG由Meta AI在2020年的论文中正式提出，是当前企业落地大模型最主流的技术路径之一。其工程实现通常分为离线索引和在线检索两个阶段：离线阶段将文档切分为固定大小的chunk（通常512-1024 token），通过Embedding模型将每个chunk转化为向量后存入向量数据库；在线阶段则对用户查询同样进行向量化，从数据库中检索Top-K个语义相近片段，拼接进Prompt发送给大模型。这一机制在模型生成答案前先从外部知识库中检索相关文档片段，将其作为上下文注入Prompt，从而弥补模型知识截止日期的局限，并大幅降低幻觉（Hallucination）风险。RAG的效果受chunk策略、Embedding模型质量、检索召回率和重排序（Reranking）算法等多个因素影响，这也是Dify提供可视化编排的核心价值所在——让开发者无需手写复杂的检索管线代码即可调优这些参数。

Dify支持对接OpenAI、Anthropic、本地Ollama等数十种模型提供商，并提供可视化的Prompt编排界面。它与 Coze 等产品同属低代码/无代码 AI 应用开发平台，但凭借开源特性和本地化部署能力，在企业级场景中占据独特优势。

Dify 最核心的价值在于：无需编写代码，即可快速构建 AI 应用。通过它，你可以搭建聊天机器人、创建智能体（Agent），或对接业务系统、编排复杂的工作流（Workflow）。对于希望快速验证 AI 想法、或在企业内部落地大模型应用的团队而言，Dify 大幅降低了技术门槛。

三种使用方式：为什么推荐本地部署

Dify 提供多种使用途径，最直接的是访问官方网站，点击「Get Started」进入在线工作界面。但在线方式存在两个明显短板：

第一，网络访问速度受限，尤其对国内用户而言，在线界面的加载和响应体验并不理想；第二，在线调用的模型均为云端服务，会显著影响开发调试效率，同时带来数据隐私和成本方面的隐患。

因此，对于正式开发场景，Dify 本地部署是更优选择。本地部署不仅摆脱网络限制，还能与本地大模型配合，构建完整的私有化 AI 开发环境。下面我们详细讲解 Dify 本地部署的完整流程。

本地部署的前置环境要求

Dify 本地部署基于 Docker 实现。Docker并非完整虚拟机，而是利用Linux内核的namespace（资源隔离）和cgroups（资源限制）特性实现进程级隔离——namespace将进程的视图隔离为独立的文件系统、网络栈和PID空间，cgroups则对CPU、内存、磁盘I/O进行精细配额控制。这使得容器启动仅需数秒，内存开销也低一个数量级。镜像采用分层联合文件系统（OverlayFS），多个容器可共享相同基础层，大幅节省存储空间，真正实现「一次构建，到处运行」。

Dify 本身依赖 Nginx（反向代理）、PostgreSQL（关系数据库）、Redis（缓存队列）、Weaviate（向量数据库）等多个组件。Weaviate承担着语义检索的核心职责——作为专为高维向量存储与近似最近邻（ANN）搜索优化的数据库，它采用HNSW（Hierarchical Navigable Small World）图算法构建索引，将搜索复杂度从线性O(n)降至对数级O(log n)，在百万量级向量中实现毫秒级近似检索。与传统关系型数据库按精确值匹配不同，它将文本内容转化为高维向量，通过计算向量间的余弦相似度（值域[-1, 1]，越接近1表示语义越相近）来衡量语义相近程度，是 RAG 流程中召回相关文档的关键基础设施。正是 Docker 的容器化能力让这套复杂依赖栈的本地部署变得简单可控。

开始前，需满足以下硬件与软件条件：

硬件要求

• CPU：不低于 2 核
• 内存（RAM）：不低于 4GB

软件环境

本地部署的核心依赖是 Docker 和 Docker Compose。Docker Compose 是用于定义和管理多容器应用的编排工具，通过 YAML 文件声明式地描述各服务间的依赖关系、网络和存储挂载配置——Dify将Nginx、PostgreSQL、Redis、Weaviate等服务分别封装为独立容器，通过Docker内部DNS按服务名互相访问，Docker Compose的YAML文件定义了这一完整拓扑，一条命令即可按正确顺序启动完整的多服务栈。启动命令本身极为简洁，本质上就是一条 docker compose up -d，但前提是本机已具备完整的 Docker Compose 环境。

因此，部署的第一步是安装 Docker，第二步是安装 Docker Compose，二者缺一不可。

Linux 环境下安装 Docker 与 Docker Compose

无论使用 Ubuntu 还是 CentOS，安装流程基本一致。

安装 Docker

在 Linux 环境下，可借助官方脚本一键完成 Docker 安装，脚本已包含 Docker 本体及镜像源配置。直接执行安装命令即可；若因网络原因脚本拉取缓慢，可先将脚本下载到本地再执行。

安装 Docker Compose

Docker 安装完成后，继续安装 Docker Compose。安装完毕后执行以下命令验证：

docker compose version

若能正确显示版本号，说明安装成功。如后续镜像拉取速度较慢，建议配置国内镜像代理以加速下载。

Windows 与 macOS 用户：使用 Docker Desktop

对于 Windows 用户，最便捷的方案是安装 Docker Desktop（桌面版）。Docker Desktop 将 Docker Engine、Docker Compose 及图形管理界面打包为一体，在 Windows 上通过 WSL 2（Windows Subsystem for Linux 2）运行 Linux 容器。

WSL 2于2019年随Windows 10 2004版本发布，其架构相较WSL 1发生了根本性变化。WSL 1通过将Linux系统调用翻译为Windows NT内核调用实现兼容，这种翻译层在处理复杂文件系统操作时存在明显性能瓶颈。WSL 2转而采用Hyper-V托管虚拟机方案，运行微软基于上游Linux内核定制的msft-kernel，实现了100%的系统调用兼容性；同时利用动态内存分配在空闲时自动释放内存归还给Windows，使Docker容器能以接近原生的性能运行，整个虚拟化过程对用户完全透明。macOS版则通过Apple Hypervisor实现同等效果。

操作步骤十分简单：前往 Docker Desktop 官网下载对应的安装文件（.exe），直接安装即可。macOS 用户同样适用这一方式。若本机已安装 Docker Compose，可跳过此步。

安装完成后打开 Docker Desktop，即可看到其主界面。你可能没注意到，Docker Desktop 内置了终端，你既可以在其中执行命令，也可以在系统命令行工具中操作，两者完全等效。

启动 Dify 服务的完整步骤

环境准备就绪后，即可正式启动 Dify。以下几个关键细节需特别注意。

第一步：进入正确的目录

从 GitHub 拉取 Dify 源码并解压后，必须进入源码中的 docker 目录再执行启动命令。该目录下存放着 Docker Compose 所需的配置文件（docker-compose.yaml），只有在此目录下命令才能正确执行。

第二步：处理环境变量文件

docker 目录下有一个 .env.example 文件，需手动将其重命名为 .env（去掉 .example 后缀）。这一设计遵循「十二要素应用」（The Twelve-Factor App）方法论——由Heroku工程师Adam Wiggins于2011年提出的云原生应用最佳实践，其第三要素「配置」明确要求将所有在不同部署环境中存在差异的配置项存储于环境变量，而非硬编码进源码。.env.example 的作用类似API契约：向新成员声明服务运行所需的全部配置项（包括PostgreSQL连接串、Redis密码、Secret Key等），同时不暴露任何真实密钥值。用户在本地创建真实的 .env 文件并填入实际密钥——该文件通常被加入 .gitignore 以避免意外提交到版本控制系统，从而有效防止密钥泄露的安全风险。这是新手容易忽略的细节，漏掉这一步将导致启动失败。

第三步：执行启动命令

完成上述准备后，执行：

docker compose up -d

-d 参数表示以**守护进程模式（daemon）**在后台运行容器。守护进程是操作系统中不依附于任何终端会话、持续在后台运行的进程——使用此模式后，关闭终端窗口服务依然存活，适合长期运行的服务场景。此时 Docker 将依次启动 Dify 所依赖的各项组件。

首次执行速度可能较慢，因为需要从网络拉取相关镜像，耐心等待即可。如已配置国内镜像代理，速度会明显提升。

首次访问与初始化配置

Dify 默认监听 80 端口，服务启动后，在浏览器中访问：

http://localhost/install

初始化设置流程

1. 切换语言：首次进入可将界面切换为中文；
2. 设置管理员账号：系统引导填写管理员邮箱、用户名和密码；
3. 登录系统：设置完成后进入登录界面，输入刚创建的账号密码即可登录。

登录成功后，你就正式进入了 Dify 工作台，本地部署至此完成。

下一步：接入本地大模型

Dify 本身是 AI 应用的编排框架，要真正构建可用的 AI 应用，还需关联推理模型或嵌入（Embedding）模型来完成实际任务。

既然已将 Dify 部署到本地，从数据隐私和开发效率的角度出发，理想做法是同步将大模型部署到本地，与 Dify 形成完整的私有化闭环。Ollama 是目前最流行的本地大模型运行工具之一，其核心是将llama.cpp推理后端封装为友好的CLI工具，并提供自动模型量化（GGUF格式）和GPU加速（CUDA/Metal）支持，支持 Llama 3、Qwen2、Mistral、Gemma 等主流开源模型，通过简单的 CLI 命令即可完成模型下载与推理服务启动。

值得一提的是，Ollama 从v0.1.14版本起完整实现了兼容 OpenAI Chat Completions API 格式的 REST 接口（默认运行在 localhost:11434），包括流式输出（Server-Sent Events）和Function Calling支持。OpenAI的API格式之所以能成为行业标准，在于其消息角色（system/user/assistant）的抽象足够通用，兼顾同步与异步、单轮与多轮对话场景。这意味着任何兼容该标准的框架（包括Dify）只需在模型提供商设置中将 API 端点替换为本地地址，无需任何额外适配即可完成对接，极大降低了私有化部署的迁移成本和技术选型的锁定风险。将 Ollama 与 Dify 组合使用，是搭建完整本地 AI 工作流的推荐路径。

总结

Dify 本地部署的整体流程并不复杂，核心步骤可概括为：准备 Docker 环境 → 拉取源码 → 配置 .env 文件 → 启动容器 → 浏览器初始化。相比在线版本，本地部署在访问速度、数据隐私和开发效率上均有明显优势。掌握这套基础流程后，你将拥有一个完全可控的私有 AI 应用开发平台，为后续接入本地大模型、搭建智能体和复杂工作流打下坚实基础。

核心要点

核心要点

核心要点