企业官网建设流程全解析

简介：这份面向个人知识库搭建入门者的部署教程文档，聚焦 ollama、deepseek、docker 与 Dify 的协同使用，帮助读者理解本地模型运行、容器化服务启动与知识库问答链路之间的衔接关系。压缩包内为 1 个 doc 文件，大小约 5.19MB，内容以分步图文、命令行示例和参数配置说明为主，覆盖 ollama 安装与版本检查、环境变量设置、deepseek 模型下载，以及 Dify 源码获取、docker-desktop 准备和 docker-compose 启动等环节；对模型规模选择、下载耗时、命令行保持运行等细节也有提示。文档已有 3400 人学习，具备一定的参考热度。其价值在于把知识库创建、分词方式选择、Ollama 接口地址填写、聊天应用模型选择与知识库上下文添加等关键节点串联起来，并保留安装包下载、容器运行状态确认和常见配置项等操作线索，便于读者按阶段对照实践、定位部署中的衔接问题。整体适合具备基础命令行操作能力、希望在本机走通 DeepSeek 个人知识库流程的学习者参考。

1. 一装就翻车的地方，往往不是模型本身

第一次在这台 Windows 10 机器上折腾 ollama + deepseek 部署个人知识库时，我以为最难的是模型，结果 deepseek-r1:1.5b 的包几分钟就下完了，真正卡住我的是 Docker 容器里那条http://127.0.0.1:11434——宿主机上 curl 得通，进了容器就指向容器自己。这类坑很典型：四个组件单独装都顺利，串起来处处不对缝。ollama 负责跑模型，deepseek-r1 是被跑的那颗模型，Docker 提供容器运行时，Dify 把模型和你的文档拼成一套能问答的知识库。这套组合适合手里攒了一堆 PDF、笔记、内部文档，想在本机做私有问答、又不想把内容往外传的人。下面从环境清单开始，一路写到装完怎么验证跑通。

2. 环境清单：Windows 10/11 + WSL2 上四个组件怎么排

2.1 四个组件各管什么，缺一个会怎样

先把职责分清，后面报错时才知道该去哪个窗口看日志。ollama 是本地模型运行时，装完会在后台起一个监听11434端口的服务，负责加载模型权重、对外暴露 HTTP 接口；deepseek-r1 只是被它加载的一份权重文件，本身不占进程，ollama list里能看到，ollama ps里能看它有没有被装进内存。这两者关系搞混，就会出现「模型装了但用不上」的错觉。

Docker Desktop 提供两层东西：一层是容器运行时，一层是跑容器用的轻量 Linux 环境（Windows 上走 WSL2 后端）。Dify 整套服务全部跑在容器里，没有 Docker 它一步都动不了。Dify 自身又是多个容器的组合：nginx 负责 80 端口的入口，api 处理业务请求，worker 跑异步任务（知识库解析就归它管），db 是 PostgreSQL，redis 做缓存和队列，外加一个向量库容器存索引。

所以链路是：浏览器 → Dify nginx → Dify api → 宿主机的 ollama:11434 → deepseek-r1。四个组件缺任何一个，链路就断在某一环，而每一环的报错长得完全不一样。新手最容易在最后一环懵掉，因为它不报红字，只是回答得驴唇不对马嘴。

2.2 硬件与系统前置条件核对表

装之前花十分钟对一遍表，比装到一半重装省事得多。下表是我在几台机器上总结出来的下限值，低于这个值不是装不上，是装上了也难用。

虚拟化那一项是硬门槛。BIOS 里没开，Docker Desktop 装完会一直转圈停在 starting，日志里报的是 WSL 相关错误，很多人误以为是 Docker 本身坏了。WSL2 没装的话，在管理员 PowerShell 里跑wsl --install，装完必须重启一次系统，不重启wsl --status仍然是空的。

# 管理员 PowerShell 下逐条执行 wsl --install # 安装 WSL 与默认发行版 wsl --set-default-version 2 # 确保新发行版走 WSL2，Docker 只认这个 wsl --update # 更新 WSL 内核，老内核会导致 Docker 启动失败

这三条的顺序不要调换。--set-default-version 2必须在发行版安装之后执行才生效；如果先装了发行版再改默认版本，已有的发行版不会自动迁移，得用wsl --set-version <发行版名> 2单独转。--update是最容易被跳过的一条，我的血泪经验是：Docker Desktop 三成以上的「启动失败」都是 WSL 内核版本太旧，跑完这条重启就好。

2.3 目录规划：模型、Dify 源码、镜像数据各放哪里

默认路径会把东西全塞进 C 盘，%USERPROFILE%\.ollama\models放模型，%LOCALAPPDATA%\Docker\wsl放镜像和数据卷。一个 14B 的模型接近 9 GB，Dify 全套镜像拉下来十几 GB，再加上知识库解析产生的向量数据，C 盘空间紧张的话两三天就红了。

我的做法是开工前先建三个目录，后面所有路径都指向它们：

D:\ai\models # ollama 模型权重，通过 OLLAMA_MODELS 指定 D:\ai\dify # Dify 源码，docker compose 在这个目录下执行 D:\ai\docker-data # Docker Desktop 的磁盘镜像位置（设置里改）

Docker Desktop 的数据目录在 Settings → Resources → Advanced 里改，改完会提示迁移，按提示走即可，迁移期间不要强退。三个目录最好在同一个盘上，方便统一做磁盘配额和备份；分散在不同盘也不是不行，只是清理时容易漏。路径里不要带中文和空格，Dify 的.env里有几处路径拼接对空格处理得不算好，遇到unexpected EOF那种玄学报错，八成是路径带空格引起的。

3. 安装 ollama 与拉取 deepseek-r1：从安装包到第一条命令

3.1 装 ollama 并让ollama --version真的能跑

从 ollama 官网下 Windows 安装包，双击一路下一步，安装程序会自动把ollama.exe放进%LOCALAPPDATA%\Programs\Ollama并写进用户 PATH。装完之后不要在原窗口直接敲命令，先win + R输入cmd开一个新窗口再验证，老窗口读的是旧的环境变量快照。

# 验证安装是否成功，正常输出形如 ollama version is 0.x.x ollama --version # 再看后台服务有没有起来，返回 JSON 说明 11434 端口已经可用 curl http://127.0.0.1:11434/api/tags

第一条命令只证明二进制存在，第二条才证明服务在跑。这两件事经常被混为一谈：ollama --version通过但 Dify 连不上，说明服务没起或者监听地址不对，去托盘区找那个羊驼图标，右键看有没有在运行。安装完成后 ollama 会自动注册为登录启动项，正常开机就在后台待着，不需要手动ollama serve。

动手ollama serve反而容易出事：命令窗口一关服务就没了，而托盘版和手动版同时启动会抢 11434 端口，第二个起来的会报address already in use。我一般只在排查时手动起，平时让托盘托管。

3.2 三个环境变量：OLLAMA_MODELS、OLLAMA_HOST、OLLAMA_KEEP_ALIVE

环境变量是这套部署里最值得花时间讲的部分，因为后面模型放错盘、Dify 连不上，八成都出在这里。在「编辑系统环境变量 → 环境变量 → 用户变量」里新建，改完必须完全退出 ollama 再重新启动（右下角托盘右键 Quit，然后从开始菜单重新打开），只关窗口不退出进程是不生效的。

# 变量名与变量值（按自己的盘符调整） OLLAMA_MODELS = D:\ai\models OLLAMA_HOST = 0.0.0.0:11434 OLLAMA_KEEP_ALIVE = 30m

OLLAMA_MODELS决定权重文件落哪，设了之后原有的 C 盘模型不会自动搬过去，需要手动把%USERPROFILE%\.ollama\models下的 blobs 和 manifests 两个目录整体剪切到新路径，或者干脆重新ollama pull一遍。OLLAMA_HOST默认是127.0.0.1:11434，只能本机访问；写成0.0.0.0:11434才允许其它网络接口访问，Docker 容器通过host.docker.internal进来时走的就是这条。这里有个取舍：开放到0.0.0.0意味着同一局域网内的机器也能访问你的模型接口，家庭网络无所谓，公司网络里我建议保持默认值，靠 Docker Desktop 的地址转发解决。

OLLAMA_KEEP_ALIVE控制模型在内存里闲置多久后卸载，默认5m。跑 1.5B 无所谓，跑 14B 时反复卸载重载很折磨，设成30m或-1（永不卸载）体验会好很多，代价是内存一直被占着。机器内存 16 GB 跑 7B 以上模型，建议10m左右，别设-1。

3.3 拉 deepseek-r1：1.5b、7b、14b 到底差在哪

到 ollama 官方的模型库里搜 deepseek-r1，页面上会列出多个尺寸。原文用的是 1.5b，这个选择对新手是对的：包小、下载快、CPU 也能跑，缺点是回答深度有限，容易答得笼统。尺寸和资源的大致对应关系如下，具体以本机实测为准。

拉模型的命令在官网页面上直接复制，回车后会自动下载：

# 拉取并进入交互问答，第一次会自动下载权重 ollama run deepseek-r1:1.5b # 只下载不进入交互，脚本化部署时用这条 ollama pull deepseek-r1:1.5b # 下完确认一下，SIZE 那列能看出实际占用 ollama list

ollama run在权重不存在时会先 pull 再加载，所以它同时承担下载和运行两个职责；ollama pull只下载不加载，适合先把模型备齐再统一启动。下载中断不用重来，ollama 支持断点续传，重新执行同一条命令会接着下。这里提醒一句：1.5b 通常几分钟，14b 在一般宽带下可能要一两个小时，别以为卡死了就 Ctrl+C，先看任务管理器里磁盘写入有没有在动。

3.4 命令行关了模型就没了？常驻服务的正确姿势

原文说「不要关闭这个命令行界面，关了模型就不运行了」，这个说法需要修正一下，否则后面接 Dify 时会一直提心吊胆。真正常驻的是 ollama 的后台服务进程，ollama run打开的只是一个交互式客户端。关掉那个黑窗口，服务还在，模型权重也还在磁盘上，只是当前会话结束、模型按KEEP_ALIVE计时后被卸载。下次需要时重新ollama run deepseek-r1:1.5b会直接加载，不会再下载。

判断服务是否还在，别靠眼睛看窗口，靠命令：

# 列当前已加载进内存的模型，空的说明都卸载了但服务仍在 ollama ps # 直接打接口，能返回 JSON 就说明服务和模型都在线 curl -X POST http://127.0.0.1:11434/api/generate ^ -d "{\"model\":\"deepseek-r1:1.5b\",\"prompt\":\"你好\",\"stream\":false}"

第二条命令在 Windows 的 cmd 里换行要用^，在 PowerShell 里要用反引号，直接粘成一整行最省事。返回里带response字段就说明整条推理链路是通的，这是接 Dify 之前必须确认的一步——如果这里就不通，Dify 里怎么配都没用。

4. 安装 Docker Desktop 并拉起 Dify：docker-compose up -d 之前要做的事

4.1 Docker Desktop 安装与 WSL2 后端确认

到 Docker 官网下 Windows 版安装包，双击安装，中间有个「Use WSL 2 instead of Hyper-V」的勾选项，保持默认勾选。装完直接点 Close and restart，重启后托盘出现鲸鱼图标，等它从橙色变绿色才算就绪。变绿之前点任何东西都没反应，别急着操作。

# 确认 Docker 引擎可用，输出 Client 和 Server 两段信息 docker version # 确认后端确实是 WSL2，输出里能看到 docker-desktop 发行版 wsl -l -v

docker version只输出 Client 段、Server 段报Cannot connect to the Docker daemon，说明引擎没起，去托盘右键 Restart。wsl -l -v里docker-desktop的 VERSION 列必须是 2，是 1 的话 Dify 的容器网络会各种异常。Docker Desktop 首次启动还会问是否登录账号，跳过就行，本地部署用不到。

4.2 镜像拉取慢：加速地址怎么配

Dify 一套镜像加起来体积不小，直连官方仓库经常卡在Pulling或者中途超时，报net/http: TLS handshake timeout。解决办法是配镜像加速地址，在 Docker Desktop → Settings → Docker Engine 里改 JSON，改完点 Apply & restart。

{ "registry-mirrors": [ "https://<你的加速地址>" ], "max-concurrent-downloads": 4 }

registry-mirrors填你自己能用的加速地址，各种云厂商的容器服务控制台里都能拿到专属地址，格式是带协议的域名。max-concurrent-downloads是并发拉取层数，默认 3，调到 4～6 能明显提速，但不要调到 10 以上，反而会因为连接数过多被限速。

加速地址只对 Docker Hub 的镜像生效，Dify 依赖里有个别镜像来自其它仓库，那部分还是会走直连。判断方法是看docker compose up -d的滚动日志：卡住的那一行如果是Pulling xxx且来源不是 Hub，配加速器也没用，只能等或者换个时间段。

4.3 Dify 源码解压后，.env 里必须改的几项

从 Dify 官方仓库下载源码压缩包解压，或者用 git 克隆到一个空目录。目录结构里有一个docker子目录，Dify 的编排文件docker-compose.yaml和配置模板.env.example都在里面。第一步永远是复制模板：

cd D:\ai\dify\docker # Windows 下用 copy，WSL 或 Git Bash 下用 cp copy .env.example .env

.env是真正被读取的配置文件，.env.example只是模板，直接改模板不会生效——这是新手第一个高频翻车点，改了半小时发现没反应，就是因为改错了文件。复制完之后打开.env，重点看这几项：

# nginx 对外暴露的端口，80 被 IIS 或其它服务占用时改成 8080 EXPOSE_NGINX_PORT=80 # 会话与加密用的密钥，必须换掉，长度要够 SECRET_KEY=<用 openssl 生成> # 本地单机部署这几项保持为空，留空会自动用相对路径 CONSOLE_API_URL= APP_WEB_URL=

SECRET_KEY不能留空也不能用默认值，Dify 启动时校验不过会直接退出。生成方法在 WSL 里跑一条命令最省事：

# 生成 42 字节的随机密钥，粘贴到 .env 的 SECRET_KEY 后面 openssl rand -base64 42

EXPOSE_NGINX_PORT是唯一需要改端口的地方，改了之后访问地址跟着变。Windows 上 80 端口常被系统组件或其它 Web 服务占着，启动阶段docker compose ps会看到 nginx 容器反复重启，日志里写着bind: address already in use，这种时候改端口比停服务快。

4.4 docker-compose up -d 之后看什么

在docker目录下执行启动命令。注意这里有个版本差异：Docker Desktop 较新版本自带的是 Compose V2 插件，命令是docker compose（中间是空格）；老版本或者单独装的 compose 才是docker-compose（连字符）。两条都试一下，哪条不报is not a docker command就用哪条。

# 前台看日志启动，第一次建议不加 -d，能看到全过程 docker compose up # 确认没问题后再后台启动 docker compose up -d # 看容器状态，重点看 STATUS 那列 docker compose ps

第一次执行会先拉镜像再起容器，十几分钟很正常，别中途 Ctrl+C。up -d成功后会看到六到七个容器，docker-api-1、docker-worker-1、docker-db-1、docker-redis-1、docker-weaviate-1、docker-nginx-1、docker-sandbox-1，Tag 版本号跟你不一致完全正常，拉的是最新镜像。

docker compose ps里出现restarting或exited的，用docker compose logs -f <容器名>单独看。worker 容器启动初期会反复重启一两次，因为它在等 db 就绪，属于正常现象；db 和 redis 一旦进重启循环，基本可以断定是数据卷权限或者.env里的密码字段没对齐。

5. 避坑与排查：五个真机上翻过的坑

5.1 现象：新开的 cmd 里ollama不是内部或外部命令

原因：安装程序写的是用户级 PATH，已经打开的命令行窗口读的是打开那一刻的环境变量快照，不会实时刷新；另一种情况是安装时选「仅为我安装」，PATH 写进了用户变量，而你用管理员身份开的窗口读的是系统变量。

解决：关掉所有 cmd 窗口重新开一个，echo %PATH%里能看到 Ollama 的安装路径就对了。还是没有的话去「环境变量 → 用户变量 → Path」手动加一条%LOCALAPPDATA%\Programs\Ollama，确定后重开窗口。别用管理员窗口测，普通窗口通过说明日常使用没问题。

5.2 现象：C 盘一夜之间少了二十几个 G

原因：没设OLLAMA_MODELS，权重全下在%USERPROFILE%\.ollama\models；同时 Docker 的虚拟磁盘%LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx只增不减，删了容器也不回收。

解决：先设OLLAMA_MODELS指向其它盘，退出 ollama 进程后把旧目录整体搬过去，再重启服务，ollama list能正常列出就说明迁移成功。Docker 那边在 Settings → Resources → Advanced 里改 Disk image location 并 Apply，它会自动迁移。虚拟磁盘膨胀严重时可以在 Docker Desktop 里执行 Clean / Purge data，代价是镜像要重拉、Dify 的本地数据会丢，做之前先把知识库源文件留好。

5.3 现象：Docker Desktop 一直卡在 starting，鲸鱼图标不变绿

原因：三种可能——BIOS 虚拟化没开、WSL 内核过旧、.wslconfig里给 WSL 分配的内存超过了物理内存。

解决：按顺序排查。任务管理器看虚拟化是否已启用，没开就进 BIOS 打开；然后管理员 PowerShell 跑wsl --update并重启；最后检查%USERPROFILE%\.wslconfig，里面的memory=不要超过物理内存的一半，我一般 16 GB 机器写memory=8GB。三招都不行就wsl --shutdown再启动 Docker，这个操作相当于给 WSL 断电重启，能解决大部分玄学问题。

5.4 现象：Dify 的模型供应商里填http://127.0.0.1:11434一直连不上

原因：Dify 的 api 容器有自己的网络命名空间，容器里的127.0.0.1指向容器自身，不是宿主机。宿主机 curl 得通不代表容器能通。

解决：Docker Desktop 环境下统一用http://host.docker.internal:11434，这个域名是 Docker Desktop 专门提供的宿主机回环地址。如果仍然不通，回头确认OLLAMA_HOST有没有设成0.0.0.0:11434——监听在127.0.0.1时，从容器侧进来的连接会被拒。这种情况值得单开一篇讲，因为它的报错信息特别模糊，只显示连接失败，没有任何提示指向地址解析。

5.5 现象：知识库显示「可用」，提问却完全不理文档

原因：绝大多数是索引阶段没走完或者 embedding 模型缺失。Dify 建知识库时需要指定一个嵌入模型来把文本转成向量，而 ollama 里的 deepseek-r1 是对话模型，不能当 embedding 用。没有可用的 embedding 模型时，索引任务会失败，但界面上的状态提示不够显眼。

解决：再拉一个专门的嵌入模型，然后在 Dify 的模型供应商里把它配成 Embedding 类型：

# 拉一个体积小、中文支持尚可的嵌入模型 ollama pull nomic-embed-text # 或 ollama pull bge-m3

拉完在 Dify → 设置 → 模型供应商 → Ollama 里添加模型，类型选 Text Embedding，填好模型名。回到知识库重新点一次索引，docker compose logs -f worker能看到解析进度滚动。索引没跑完就去提问，得到的永远是模型自由发挥的答案。

6. 保持可复现：装完之后怎么验证这套链路真的通了

装完不做验证，等于没装。我固定跑三段检查，每段都对应链路上的一环，出问题能立刻定位在哪一层。

第一段验证宿主机到 ollama。curl http://127.0.0.1:11434/api/tags返回 JSON 且能看到deepseek-r1:1.5b，说明模型和服务都在。第二段验证容器到宿主机：进 Dify 的 api 容器里发一次请求，能返回就说明host.docker.internal这条路是通的。

# 进入 api 容器执行，能打印 JSON 即为连通 docker compose exec api curl -s http://host.docker.internal:11434/api/tags

第三段验证应用层。浏览器打开http://127.0.0.1/signin（改过端口就是http://127.0.0.1:8080/signin），首次进入设置管理员账号，然后在工作室里建一个空的聊天助手应用，模型下拉框里能选到deepseek-r1:1.5b，发送一句「你好」有回复，链路就算通了。

最后一步是证明知识库真被引用，这一步最容易被跳过。往知识库里传一份自己写的文档，里面写一句只有你知道的话，比如「项目代号是青柠」，等索引跑完，在聊天里问「项目代号是什么」。回答里出现「青柠」并且带引用角标，才算真的跑通；回答不出来，或者答得像在猜,回去看 worker 的日志和 embedding 模型配置。这个验证方式比看任何状态灯都可靠——它验证的是从文档到向量到召回到生成的完整闭环。

从那以后我每次重装这套环境，都会在最后强制走一遍「青柠测试」，不管界面显示得多正常。这套东西的坑不在安装，在链路的最后一公里，而最后那一公里只有用一句你自己编的话才试得出来。希望帮到你。

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