1. 为什么你需要一个本地化的AI开发环境？

最近几年，AI应用开发的门槛肉眼可见地降低了。以前想搞个智能对话机器人，你得从零开始搭后端、调API、处理并发，光是技术栈就能劝退一大半人。但现在，情况不一样了。像 Dify 这样的平台，把构建AI应用变成了“搭积木”，你只需要关心你的业务逻辑和创意就行。

但问题来了，很多朋友一开始会直接调用云上的大模型API，比如GPT-4、Claude这些。用起来是爽，速度快，效果也好。可时间一长，几个痛点就冒出来了：成本、数据隐私、网络延迟，还有模型的可控性。尤其是当你做一些内部工具，或者处理敏感数据的时候，把数据送到别人的服务器上，心里总是不太踏实。另外，频繁调用API的费用，对于个人开发者或者小团队来说，也是一笔不小的开销。

所以，把模型“请”到自己的电脑或者本地服务器上，就成了一个越来越香的选择。本地化部署意味着你可以完全掌控数据和模型，没有网络请求的延迟，一次部署，长期“白嫖”（当然，电费和硬件成本得自己承担）。而要实现这个目标，Ollama 和 vLLM 是目前最受欢迎的两个“搬运工”和“加速器”。

Ollama 就像一个贴心的模型管家，它让下载、运行和管理开源大模型变得跟安装手机App一样简单。一条命令，就能把 Llama 3、Qwen、Gemma 这些明星模型拉下来跑起来。而 vLLM 则是一个性能狂魔，它专注于推理阶段的极致优化，尤其是用了 PagedAttention 这样的黑科技，能让模型推理的速度飙升，同时大幅降低显存占用。简单说，Ollama 让你“有得用”，vLLM 让你“用得爽”。

那么，Dify 在这里面扮演什么角色呢？它就是你那个功能强大的“中央控制台”。你把本地的 Ollama 和 vLLM 接进来，Dify 就能为你提供可视化的Prompt编排、RAG知识库、智能体工作流等一系列高级功能。你不用再写一堆胶水代码去连接模型和业务，在Dify的界面上拖拖拽拽，一个智能应用的原型就出来了。今天，我就带你走一遍完整的流程，从零开始，在Dify里把 Ollama 和 vLLM 都给接上，打造一个完全属于你自己的、高性能的本地AI开发沙盒。

2. 基础环境搭建：让Dify先跑起来

万事开头难，但安装Dify其实一点也不难。官方最推荐的方式就是用 Docker Compose，这能帮你把所有依赖的服务，比如数据库、Redis、向量数据库Weaviate都一次性安排好，避免了你手动配置的种种坑。我自己的好几台测试机，从Ubuntu到Mac，都是这么装起来的，很稳。

在开始之前，咱们先看看你的机器够不够格。最低配置是2核CPU和4GB内存，但说实话，这只是能让Dify平台本身跑起来。如果你想同时跑模型，尤其是7B参数以上的模型，那配置得往上提。我个人建议，至少给到4核CPU和16GB内存，如果有NVIDIA显卡（显存8G以上）那就更好了，后续跑模型会快很多。操作系统方面，Linux（Ubuntu 20.04/22.04首选）、macOS，或者开启了WSL2的Windows都可以。

好了，我们正式开始。首先，打开你的终端，把Dify的最新代码拉到本地。我习惯在/opt目录下操作，你也可以放在任何你喜欢的地方。

# 拉取 Dify 的代码仓库
git clone https://github.com/langgenius/dify.git
cd dify/docker

进入docker目录后，你会看到一个.env.example文件，这是环境配置的模板。我们需要复制一份，生成我们自己的.env配置文件。这个文件里可以配置端口、数据库密码等，第一次我们先保持默认。

# 复制环境配置文件
cp .env.example .env

接下来，就是激动人心的启动时刻了。确保你在dify/docker这个目录下，然后运行一条命令：

# 启动所有服务（-d 代表后台运行）
docker compose up -d

这时候，Docker会开始拉取镜像并启动一系列容器。你会看到屏幕上刷刷地跑日志，最后出现“done”或者容器列表。这个过程取决于你的网速，可能需要几分钟。完成后，别急着关掉终端，我们检查一下所有容器是不是都健康地跑起来了。

# 查看所有容器的状态
docker compose ps

这个命令会列出一个表格。你需要重点检查api、worker、web这几个核心业务服务，以及db、redis、weaviate这些基础组件，它们的状态（STATUS）都应该是“Up”并且运行了一段时间。如果看到某个容器不断重启（Restarting），那可能是端口冲突或者资源不足，可以去查查日志docker compose logs [服务名]。

一切正常的话，恭喜你！Dify平台已经在本地运行了。默认情况下，它的Web界面就在http://localhost:80。如果你本地80端口被占用了（比如你装了Nginx或Apache），可以去修改.env文件里的NGINX_HTTP_PORT配置，然后重启服务。

第一次在浏览器打开http://localhost，你会看到一个初始化页面，让你设置管理员账号和密码。这个账号权力很大，务必记好。设置完成后，你就进入了Dify的仪表盘。到这里，我们的“控制台”就准备就绪了。接下来，我们要请出两位重量级嘉宾：Ollama和vLLM。

3. 部署本地模型引擎：Ollama 与 vLLM 双剑合璧

Dify自己并不提供模型，它是一个卓越的“模型调度中心”和“应用工厂”。所以，我们需要在本地部署真正的模型推理服务。Ollama和vLLM是两种不同风格但同样优秀的解决方案，我们可以根据需求选择，甚至同时使用。

3.1 安装Ollama：你的贴心模型管家

Ollama的哲学是极简。它的安装简单到令人发指。以Linux系统为例，通常一条命令搞定：

# 下载并运行安装脚本
curl -fsSL https://ollama.ai/install.sh | sh

安装完成后，Ollama服务会自动启动。你可以用systemctl status ollama查看状态。现在，你就可以用命令行像安装软件包一样安装模型了。比如，我想安装最新的Meta Llama 3 8B模型：

# 拉取并运行 Llama 3 8B 模型
ollama run llama3:8b

第一次运行会下载模型文件，可能需要一些时间。下载完成后，你就直接进入了一个交互式对话界面，可以跟模型聊天了。但这并不是我们最终目的。我们需要的是让Ollama作为一个HTTP API服务运行，这样Dify才能调用它。

Ollama默认的API服务地址是http://localhost:11434。你可以通过ollama serve命令来确保服务在后台运行。一个很重要的点：Dify运行在Docker容器里，而Ollama运行在宿主机上。在Dify的容器内部，“localhost”指的是容器自己，而不是宿主机。所以，Dify是无法直接用http://localhost:11434访问到宿主机的Ollama的。

解决这个问题有两个常用方法。方法一是修改Ollama的服务配置，让它监听0.0.0.0（所有网络接口），而不仅仅是127.0.0.1。可以通过设置环境变量来实现：OLLAMA_HOST=0.0.0.0 ollama serve。但这样会让Ollama暴露在本地网络上，请注意安全。方法二（更推荐在开发环境使用）是利用Docker的网络特性。在启动Dify的docker-compose.yml文件中，将Ollama的宿主IP（比如192.168.1.100）作为可访问地址。在后续Dify配置时，我们就需要填写这个宿主机对外的IP和端口。

3.2 安装vLLM：追求极致的推理性能

如果你的机器有一张不错的NVIDIA显卡，并且你对推理速度有极致要求，那么vLLM绝对是你的菜。它通过创新的PagedAttention算法，极大地优化了显存使用和推理吞吐量，尤其是在处理长文本和并发请求时，优势明显。

安装vLLM同样不复杂，但前提是你要有正确的CUDA环境。首先，确保你的机器安装了NVIDIA驱动和与你的显卡匹配的CUDA Toolkit（比如12.1）。然后，用pip安装即可：

# 使用 pip 安装 vLLM
pip install vllm

安装完成后，启动一个vLLM服务也非常直观。例如，我们要用vLLM来服务一个Qwen 1.5 7B的模型（你需要提前从Hugging Face下载好模型权重文件，或者指定HF模型名）：

# 启动 vLLM 服务，指定模型和API端口
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen1.5-7B-Chat \
    --served-model-name qwen-7b \
    --api-key token-abc123 \
    --port 8000

这条命令做了几件事：加载指定的模型，将其服务名称设为qwen-7b，设置一个简单的API密钥（用于基础验证），并在本地的8000端口启动一个兼容OpenAI API格式的服务。这意味着，任何能调用OpenAI API的工具（包括Dify），理论上都能无缝切换到你的本地vLLM服务。

这里有一个非常重要的实践细节：如果你的机器上同时运行了Ollama和vLLM，并且它们都需要使用GPU，你必须确保它们使用的是不同的GPU设备。例如，如果你有两张显卡，可以指定Ollama用CUDA_VISIBLE_DEVICES=0，vLLM用CUDA_VISIBLE_DEVICES=1。如果只有一张卡，同时运行两个需要大量显存的模型服务可能会爆显存。通常的实践是，在资源有限的单卡环境下，同一时间只运行一个主要的模型推理服务。

4. 在Dify中集成Ollama：像连接云API一样简单

平台跑起来了，模型服务也启动了，现在就是最关键的一步：让它们握手相连。Dify的设计非常人性化，它把对接各种模型供应商的过程做成了“插件化”的安装。我们首先来连接Ollama。

登录Dify后台，在左侧菜单找到 “设置” -> “模型供应商”。你会看到一个模型供应商市场，里面列出了数十种支持的服务，比如OpenAI、Anthropic，当然也有我们需要的 Ollama。找到它，点击“安装”。

安装完成后，它就会出现在“已安装的供应商”列表里。点击它下面的“添加模型”按钮，开始配置。这个配置页面需要你仔细填写，我结合自己的踩坑经验，把每个字段给你讲明白：

• 模型名称：这里不是随便起的名字，而是要填写Ollama服务里实际拉取和运行的模型名称。比如你在命令行用ollama run llama3:8b，那这里就填llama3:8b。不确定的话，随时在终端用ollama list命令查看。
• 模型类型：根据你的用途选择。如果是用于对话聊天，就选“LLM（大语言模型）”；如果是为了给文档做向量化嵌入（用于RAG），就选“Text Embedding（文本嵌入模型）”。这里我们先选LLM。
• 基础URL：这是最容易出错的地方！正如前面提到的，Dify在容器内，Ollama在宿主机。你不能填http://localhost:11434。需要填写宿主机在Dify容器网络内能访问到的地址。如果你在本地开发，宿主机IP可能是192.168.x.x。那么这里就填http://192.168.x.x:11434。你可以用ifconfig或ip addr命令查看本机IP。
• 模型上下文长度 & 最大Token上限：这两个值决定了模型能处理多长的文本。对于Llama 3 8B，上下文长度是8192。如果你不清楚，保守一点可以填4096。最大Token上限通常可以和上下文长度设成一样。
• 是否支持Vision & 函数调用：这取决于你选的模型能力。像Llama 3这样的纯文本模型，两者都选“否”。如果你用的是多模态模型（如BakLLaVA）或支持工具调用的模型，则需要开启对应选项。

填写完毕后，点击保存。如果配置正确，Dify会尝试连接你提供的URL，并验证模型是否可用。你可能会在页面上看到一个“测试”按钮，点击它可以发送一个简单的测试请求，确保连接畅通。

配置成功后，这个模型就会出现在你的模型列表中。接下来，我们就可以真正用它来创造应用了。进入“工作台”，点击“创建空白应用”，类型选择“聊天助手”。创建完成后，进入应用的“编排”界面。在右上角或者提示词编排的节点处，你会看到一个下拉框，里面可以选择模型。点开它，你应该能看到刚刚添加的、以Ollama为供应商的模型（例如llama3:8b）。选中它，现在你的聊天应用就已经接上了本地的Llama 3模型了！输入一句话测试一下，感受一下零延迟、零费用的本地对话吧。

5. 在Dify中集成vLLM：解锁高性能推理

接好了Ollama，我们再来把vLLM也接进去。vLLM的集成思路和Ollama类似，但因为vLLM提供了兼容OpenAI的API接口，所以在Dify里我们有两种方法接入它，我个人更推荐第二种，因为它更灵活通用。

方法一：使用“vLLM”供应商（如果列表中有） 和Ollama一样，去“模型供应商”里找找有没有名为“vLLM”的选项。如果有，直接安装并添加模型。配置方式大同小异：

• 模型名称：填写你在启动vLLM服务时用--served-model-name参数指定的名字，比如qwen-7b。
• 基础URL：填写vLLM服务的地址，例如http://宿主IP:8000（默认端口是8000）。
• API密钥：填写启动命令中--api-key参数设置的值，比如token-abc123。如果启动时没设，这里可以留空或随意填写（取决于vLLM服务是否强制验证）。

方法二：使用“OpenAI-API-compatible”供应商（更推荐） 这是更强大和通用的方法。因为vLLM的API格式和OpenAI完全兼容，所以我们可以把它当作一个“自定义的OpenAI端点”来用。在模型供应商里找到“OpenAI-API-compatible”并安装。

添加模型时的配置会有些不同：

• 模型名称：这里可以自由命名，比如my-fast-qwen，方便你在Dify里识别。
• 模型类型：选择“LLM”。
• API密钥：同样填写vLLM启动时设置的API Key。
• API Base URL：这是关键！填写你的vLLM服务的完整地址，例如http://192.168.x.x:8000/v1。注意，这里必须加上/v1路径，因为这是OpenAI API的标准路径，vLLM也遵循这个规范。
• 模型上下文长度：根据实际模型填写，比如Qwen1.5-7B-Chat是32768。

用这种方法的好处是，它不仅仅适用于vLLM，任何提供了OpenAI兼容API的服务，比如LMDeploy、Xinference，甚至是其他云厂商的兼容接口，都可以用这个方式接入Dify，一劳永逸。

添加成功后，你就可以在应用编排时，在模型选择列表里看到这个来自vLLM的模型了。选择一个对话型应用，分别用Ollama的模型和vLLM的模型回答同一个复杂问题，你可能会直观地感受到vLLM在生成速度上的优势，尤其是在连续对话和长文本生成场景下。

6. 实战应用与性能调优指南

环境搭好了，模型也接上了，但这只是开始。如何真正用好这个本地化环境，让它稳定、高效地为你工作，这里面还有不少门道。我结合自己搭建内部知识库助手和智能客服原型的经验，分享几个实战技巧。

第一个技巧：模型的选择与搭配。 不要一味追求大参数模型。在本地有限的资源下，7B-14B参数的模型往往是性价比之王，在效果和速度之间取得了很好的平衡。例如，对于一般的问答和文本总结，Llama 3 8B、Qwen 1.5 7B、Gemma 7B都是绝佳的选择。你可以同时在Ollama里安装多个模型，在Dify里配置多个供应商，根据不同的应用场景灵活切换。比如，一个需要快速响应的客服场景用vLLM驱动的Qwen，一个需要复杂推理的代码生成场景用Ollama管理的DeepSeek-Coder。

第二个技巧：关注显存和内存的使用。 本地部署最直接的约束就是硬件资源。运行一个7B模型，采用4-bit量化（Ollama和vLLM都支持），大概需要4-6GB的显存。如果你的显存不够，系统会使用内存进行交换，速度会急剧下降。强烈建议使用nvidia-smi（针对GPU）和htop（针对系统资源）命令实时监控资源占用。在Dify的“日志与监控”部分，你也可以观察API调用的耗时和错误率，判断是否是资源瓶颈。

第三个技巧：优化Dify的配置。 在docker-compose.yml或.env文件中，可以调整一些参数来提升性能。比如，增加api和worker服务的CPU和内存限制，确保它们有足够资源处理并发请求。如果你的知识库文档很多，也可以调整Weaviate向量数据库的资源配置。另外，将模型服务（Ollama/vLLM）和Dify部署在同一台机器的不同容器或进程中，并通过本地网络通信，可以最大程度减少网络延迟。

第四个技巧：构建真实的RAG应用。 Dify的强项之一就是其开箱即用的RAG（检索增强生成）引擎。现在你有了本地模型，可以完全在离线环境下构建一个安全的文档问答系统。在Dify中创建一个“知识库”，上传你的PDF、Word文档，Dify会自动用本地的嵌入模型（比如通过Ollama安装的nomic-embed-text模型）将文档切片、向量化，并存储到本地的Weaviate中。当用户提问时，系统会先从知识库检索相关片段，再连同问题一起发给你的本地大模型生成答案。整个过程，数据不出局域网，安全又高效。

我在给团队搭建内部技术文档查询助手时，就采用了这个架构：Dify + Ollama（运行llama3:8b做生成，nomic-embed-text做向量化）。效果非常好，不仅响应速度快，而且彻底打消了大家对敏感技术信息外泄的顾虑。这种掌控感，是使用云端API无法比拟的。

最后，记得定期更新。无论是Dify、Ollama还是vLLM，开源社区都非常活跃，更新频繁。关注它们的GitHub Release页面，定期拉取最新镜像或代码，可以让你获得性能提升、新功能和安全补丁。当然，升级前最好在测试环境先验证一下。本地化AI开发环境就像你的私人数字车间，一开始搭建需要花点时间，但一旦运转起来，它带给你的灵活性、安全性和成本优势，会让你觉得这一切都是值得的。