企业官网建设流程全解析

简介：这份资源面向希望本地搭建个人知识库的开发者与AI爱好者，围绕ollama、deepseek、docker与Dify四件套的协同部署展开，适合对大模型本地运行、容器化部署有初步了解、想打通「模型接入—知识库构建—问答应用」完整链路的中级学习者。压缩包内为1个doc文档，约5.19MB，以图文步骤形式记录从ollama安装、环境变量与模型下载，到docker-desktop配置、Dify项目启动、知识库分词与聊天应用接入deepseek的全过程，并附有各环节的界面截图与命令示例。资源已有3396人学习，说明该部署路线具备一定参考价值。读者可据此对照复现本地知识库环境，理解ollama接口与Dify模型供应商的对接方式，掌握知识库解析、上下文引用与问答测试的排错思路，减少在环境变量、容器启动和端口配置上反复试错的成本。

1. 从一次“模型跑起来了，知识库却连不上”说起

上周帮一位做技术文档的朋友收拾他笔记本上的烂摊子：ollama 装好了，deepseek-r1:1.5b也能在命令行里一问一答，可一进 Dify 就卡在模型供应商那一步，端口填了127.0.0.1:11434死活连不上。这类“单机跑得欢、容器里全抓瞎”的场面，在本地部署个人知识库时太常见了。这套 ollama + deepseek + docker + Dify 的组合，本质是把模型推理、容器编排、知识库检索三件事拼到一台 Windows 机器上，任何一环的路径、端口、环境变量写错，后面全白搭。这篇笔记按我实际装机的顺序走一遍，版本、参数、翻车点都写清楚，适合想在自己电脑上搭一套离线问答知识库的开发者，新手照着能跑通，熟手能直接抄环境变量和端口配置。

2. 装前把环境列清：Windows 10/11、WSL、Docker Desktop 与模型档位

动手之前先把家底摸清，比装到一半发现 WSL 没开要省事得多。这套方案对机器不算苛刻，但几个前置条件缺一不可，尤其是 Windows 上跑 Docker 的那层虚拟化。

2.1 硬件与系统的最低门槛

我一般按下面这张表给机器做体检，低于这个线就别硬上大模型，1.5B 都跑得费劲：

模型档位要单独说一句。原文用的是deepseek-r1:1.5b，这是权衡后的选择：参数量小、下载快、纯 CPU 也能出结果。7B 以上没有独立显卡基本是自虐，下载动辄两三个小时，推理一句话等半分钟。第一次搭环境，先用 1.5B 把链路跑通，后面换模型只是改一个 tag 的事。

2.2 先把 WSL2 和虚拟化打开

Windows 上 Docker Desktop 默认走 WSL2 后端，这一步没开，后面docker-compose up会直接报引擎未启动。以管理员身份打开 PowerShell：

# 启用 WSL 与虚拟机平台功能，装完必须重启 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启后把 WSL 默认版本设为 2 wsl --set-default-version 2 # 确认虚拟化已开启，输出里 Virtualization 应为 Enabled systeminfo | findstr /i "Virtualization"

dism两条命令分别打开 Linux 子系统和虚拟机平台，/norestart是让两条命令连着跑完再统一重启，省一次重启。wsl --set-default-version 2很关键，默认若是 1，Docker 的容器网络行为会不一样，端口映射容易出玄学问题。systeminfo那条是自查，如果显示 Disabled，得进 BIOS 把 VT-x 打开，软件层面救不回来。

2.3 Docker Desktop 的安装与国内镜像源

去 Docker 官网下 Windows 版安装包，双击一路 Next，装完点 Close and restart。第一次启动会弹服务条款，接受后等鲸鱼图标变绿。这里有个血泪经验：默认拉取镜像走的是境外仓库，docker-compose up卡在 pulling 半小时不动是常态。装完先配镜像加速，在 Docker Desktop 的 Settings → Docker Engine 里改 JSON：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com" ], "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } } }

registry-mirrors是镜像拉取的备用地址，按顺序尝试，第一个超时会自动换下一个；defaultKeepStorage控制构建缓存上限，设 20GB 防止磁盘被旧层塞满。改完点 Apply & Restart，等引擎重启完再继续。注意镜像源地址会变，配完可以docker pull hello-world试一下，能拉下来就说明通了。

3. 装 ollama 与拉取 deepseek-r1：环境变量和模型目录别写错

ollama 是这套链路里最“傻瓜”的一环，但环境变量那步写错，模型会默认塞进 C 盘用户目录，几十 GB 下去系统盘直接告急。

3.1 安装 ollama 并验证版本

官网下载 Windows 安装包，双击 Install，等进度条走完。装完Win + R输入 cmd，跑一条：

# 查看版本，能输出版本号即安装成功 ollama --version # 查看服务是否在监听，默认 11434 curl http://127.0.0.1:11434

ollama --version输出类似ollama version is 0.x.x就说明二进制装好了。第二条curl是验证后台服务，返回Ollama is running才算真正就绪——很多人只看了版本号就以为完事，结果 Dify 连不上，其实是服务没起。ollama 装完会自动注册一个开机自启的后台服务，正常情况下不用手动开。

3.2 环境变量：模型存放路径与监听地址

这是原文里最容易照抄出错的地方。右键“此电脑”→ 属性 → 高级系统设置 → 环境变量，在“系统变量”里新建两条：

OLLAMA_MODELS指向一个提前建好的空文件夹，路径别带中文和空格，否则个别情况下加载会失败。OLLAMA_HOST设成0.0.0.0:11434是为了让 Docker 容器能通过宿主地址访问到它——只监听127.0.0.1的话，容器里的 Dify 是够不着的，这正是开头那个朋友踩的坑。改完环境变量必须重启 ollama 服务：任务管理器里结束ollama.exe，再重新打开一个 cmd 跑ollama list，服务会自动拉起。

3.3 拉取 deepseek-r1:1.5b 并保持会话

# 拉取并进入交互式对话，首次会自动下载 ollama run deepseek-r1:1.5b # 另开一个窗口确认模型已落地 ollama list

ollama run第一次执行会先 pull 再进入对话，1.5B 大概 1 GB 出头，网速正常几分钟完事。进入>>>提示符后随便问一句验证。这里有个操作习惯要养成：这个命令行窗口别关，关了模型会话就断了；不过模型文件已经落盘，下次ollama run deepseek-r1:1.5b是秒起，不用重新下载。ollama list能看到模型名和大小，确认它躺在你设的OLLAMA_MODELS目录里，就说明环境变量生效了。

4. 用 Docker 拉起 Dify：compose 启动与端口映射

Dify 是整套知识库的门面，它自己不带模型，靠接 ollama 的接口干活。用官方 compose 起最省事，但目录、端口、首次启动的等待时间都有讲究。

4.1 获取源码与进入 docker 目录

从 Dify 的 GitHub 仓库下载源码包解压，或者本地有 git 就直接克隆：

# 克隆到空目录，没有 git 就去仓库页下载 zip 解压 git clone https://github.com/langgenius/dify.git # 进入 docker 编排目录，compose 文件在这里 cd dify/docker

解压后的目录里，docker子目录才是我们要的，里面有docker-compose.yaml和.env.example。很多人直接在根目录跑 compose，报找不到文件，就是没进这一层。进目录后先复制环境文件：

# Windows cmd 下用 copy，PowerShell 用 Copy-Item copy .env.example .env

.env里管着数据库密码、端口、密钥，默认值能跑，但生产用一定要改SECRET_KEY和数据库密码。本地自用先不动，把链路跑通再说。

4.2 docker-compose up 启动与容器状态检查

# 后台启动全部服务，首次会拉镜像，耐心等 docker-compose up -d # 查看容器状态，全部 Up 才算成功 docker-compose ps

-d是后台运行，不加的话日志会刷满终端。首次执行要拉 api、worker、db、redis、nginx 等一堆镜像，加上镜像源，十几分钟很正常，别以为卡死了就 Ctrl+C。docker-compose ps里重点看api、worker、db三个是不是Up，有Restarting或Exit的，用docker-compose logs api看具体报错。常见的是 db 初始化慢导致 api 反复重启，等两分钟自己会稳。新版 compose 命令是docker compose（中间空格），老版是docker-compose，报 command not found 就换另一种写法。

4.3 首次登录与管理员账号初始化

容器全绿后，浏览器开http://127.0.0.1/signin。第一次访问会跳设置页，让你建管理员账号，邮箱密码自己定，记牢。这一步只在数据库为空时出现，后面再进就是普通登录页。如果打开是 502，多半是 nginx 起了但 api 还没就绪，等一分钟刷新；一直 502 就docker-compose logs nginx看上游地址对不对。登录进去能看到“知识库”“应用”几个入口，说明 Dify 本体没问题了，接下来才是接模型。

5. 避坑排查：端口、容器网络与知识库解析的五条实录

这一章是我自己和小范围帮人装下来攒的翻车记录，每条都按现象、原因、解决写，照着对号入座能省不少时间。

5.1 Dify 填 127.0.0.1:11434 连不上 ollama

现象：模型供应商里填http://127.0.0.1:11434，点保存报连接失败或超时。原因：Dify 跑在容器里，容器内的127.0.0.1指的是容器自己，不是你的 Windows 宿主机。解决：地址改成http://host.docker.internal:11434，这是 Docker Desktop 给容器访问宿主机预留的域名；同时确认 ollama 的OLLAMA_HOST是0.0.0.0:11434，两者缺一不可。

5.2 模型列表为空，添加模型时下拉没东西

现象：Ollama 供应商添加成功，但模型下拉框是空的。原因：ollama 后台服务没在跑，或者模型没拉下来。解决：另开 cmd 跑ollama list确认模型在；不在就ollama run deepseek-r1:1.5b重新拉。服务没起就结束ollama.exe再触发一次。Dify 是通过接口实时读模型列表的，接口不通自然空。

5.3 docker-compose up 卡在 pulling 不动

现象：命令行停在Pulling api ...十几分钟没进展。原因：默认仓库拉取慢或超时。解决：按 2.3 配registry-mirrors，配完docker-compose down再up -d。还不行就单独docker pull langgenius/dify-api:latest看具体报错，有时是某个层校验失败，重试即可。

5.4 知识库文档上传后一直“解析中”

现象：文档传上去，状态卡在解析，向量迟迟不出。原因：解析和 embedding 由 worker 容器干，worker 挂了或 embedding 模型没配。解决：docker-compose ps看 worker 是否 Up，docker-compose logs worker看报错；另外 Dify 默认的 embedding 需要模型支持，接 ollama 时要在系统设置里把 embedding 模型也指到 ollama 拉一个 embedding 模型，否则解析队列会堵。

5.5 重启电脑后 Dify 打不开、ollama 也没了

现象：第二天开机，浏览器 502，命令行ollama提示不是内部命令。原因：Docker Desktop 没设开机自启，ollama 服务被安全软件拦了。解决：Docker Desktop 设置里勾 Start Docker Desktop when you sign in；ollama 重新跑一次安装包修复，或在服务里确认 ollama 服务是自动启动。养成习惯：开机先看鲸鱼图标绿没绿，再ollama list确认模型在，最后开浏览器。

6. 装完怎么验证：从模型直连到知识库引用的三步自检

装完不等于跑通，我习惯按“模型层 → 接口层 → 应用层”三层各验一次，任何一层不过就停在那层查，别急着往下走。

第一步验模型层，纯命令行确认推理正常：

# 直接调接口，不走交互界面，验证服务与模型都在 curl http://127.0.0.1:11434/api/generate -d "{\"model\":\"deepseek-r1:1.5b\",\"prompt\":\"用一句话说明什么是向量检索\",\"stream\":false}"

返回 JSON 里response字段有内容，说明模型和服务都健康。这一步排除了 Dify 的干扰，是最干净的基线。

第二步验接口层，在 Dify 的模型供应商里点 Ollama 的“测试”或添加模型后发一条测试消息，能收到回复就说明host.docker.internal这条路通了。第三步验应用层，建一个聊天助手应用，挂上刚建的知识库，问一个只有你文档里才有的问题，比如文档里写的某个内部编号。回答里出现引用片段、且内容对得上，才算真正跑通——这一步能同时验证检索、向量化和模型生成三段链路。

有个细节值得单独提：知识库问答答非所问，八成不是模型笨，是分段和召回参数没调。Dify 默认分段按固定长度切，技术文档里表格和代码多，切碎了检索就偏。我一般把分段长度调大、重叠留一点，再在召回设置里把 Top K 从默认值往上提一档，命中率肉眼可见地好。这套参数没有标准答案，得拿自己的文档试几轮。

从那以后我每次搭这套环境，都强制按“模型层 curl 通 → 接口层测试通 → 应用层带引用答对”走一遍，任何一层不过绝不往下配，省得后面在 Dify 里瞎猜是模型问题还是网络问题。这套组合的坑基本都在路径、端口和容器网络这三处，把环境变量和host.docker.internal记牢，剩下的就是等镜像和模型下载。希望帮到你。

本文还有配套的精品资源，点击获取