企业官网建设流程全解析

身边好几个朋友最近都在问我：DeepSeek这么火，怎么在本地跑起来？怎么把公司文档塞进去让它自己回答？为什么我部署的时候老是报错？

说实话，这些问题我全踩过一遍。DeepSeek本地部署这事的门槛其实不高，难点全在环境配置、模型下载、知识库打通这三块。尤其是知识库，很多人以为装个Ollama拉个模型就完事了，结果发现模型只会聊天，根本不会回答你内部文档里的内容——因为知识库是另一套东西。

这篇文章我把自己完整的部署过程写出来，从Ollama安装、DeepSeek模型拉取、到Dify知识库搭建，最后附上我实际遇到的3个报错和排查思路。整个过程我是在一台32G内存的Linux服务器上操作的，显卡是RTX 4090，应该是目前比较主流的本地部署配置。你如果用的是Mac或者Windows，原理都一样，我会在对应位置说明差异。

1. 整体设计思路：为什么是Ollama+Dify这套组合

先聊清楚一个事：本地跑大模型的方案其实不少，vLLM、llama.cpp、Ollama、LM Studio都行。我最终选了Ollama，原因很直接——它把模型管理、量化格式转换、API服务这三件事合并成了一件事。

你如果用vLLM，性能确实更好，但配置起来要写一堆参数，还得自己处理CUDA版本、Python虚拟环境，光是torch的版本兼容问题就能折腾一晚上。而Ollama把模型文件下载到本地后，一条命令就能起服务，默认暴露11434端口的API，和OpenAI的接口格式基本兼容，后面接任何上层应用都方便。

知识库这块我用的Dify。它的思路很清晰：把文档切块（Chunking）、向量化（Embedding）、检索召回（Retrieval）、LLM回答这几个环节做了可视化编排，你不需要自己写RAG代码。社区版免费，支持docker compose一键启动，中文界面做得很完整。

本地部署DeepSeek这件事的价值，往大了说有三点。一是数据隐私可控，所有对话内容和文档数据都在本地，不经过任何第三方服务器。二是可定制性强，你可以挂私域知识库，让模型回答只基于你喂进去的内容而不是通用语料。三是成本长期看更低，API调用是按token计费的，高频使用场景下本地部署一次投入，边际成本几乎为零。

架构大概就是这样的分层：

• 底层：Ollama运行时，负责加载DeepSeek模型，提供本地API
• 中间层：Dify平台，负责知识库管理、流程编排、对话应用配置
• 调用层：Web界面或API客户端，直接面向用户

这套组合的兼容性非常成熟，网上有大量现成的案例可以抄作业，遇到问题也容易搜到解决方案。我踩完坑之后的感觉是：选这个组合最大的好处是坑都被别人踩得差不多了，剩下的坑自己踩一遍也算不了什么。

1.1 模型版本选择：7B还是14B还是70B

DeepSeek在Ollama上有多个版本可选，参数从1.5B到70B都有。选哪个取决于你的硬件，这不是偏好问题是数学问题。

先说结论：32G内存用CPU推理，7B量化版是最稳的选择；如果有RTX 4090或者多张显卡，14B的体验会明显上一个台阶；70B是给企业级工作站准备的，家用级别就跑不动了。

我实测过，Ollama拉取的DeepSeek-R1:7B-Q4_K_M版本，加载后占的内存大概6-7G，生成速度取决于CPU算力，我用32G内存的机器实测大概每秒15-20个token。这个速度做问答、写文档、改代码都够了，但你要是想要那种聊天几乎无延迟的感觉，那得上GPU。

另外一个关键点是71B这种大模型，通常72B以上的模型量化后需要48G以上内存才带得动。很多人只看了模型说明说最低要求多少，没算量化后的实际占用，结果下载完一跑就崩。这里给大家一个经验公式：模型文件大小加上1.5G的上下文缓存，就是你起码需要预留的空闲内存，不然跑起来必OOM。

1.2 硬件与操作系统前置条件

先列一下硬性要求，方便你对照自己的机器：

• 内存至少16G，32G体验更好（模型加载+系统开销）
• 磁盘空间预留30G以上（模型文件+镜像+临时文件）
• 有Nvidia显卡的话建议驱动版本不低于470（CUDA 11.4起步），显存越大越好
• 没有显卡也能玩，纯CPU推理就是慢一些，效果不打折

操作系统方面，Linux是体验最好的，Ubuntu 20.04/22.04基本上零障碍。Windows也行，但Dify的docker环境在Windows上有些文件挂载权限的问题，我个人不推荐。Mac用户注意了，M系列芯片可以跑，但Ollama在Mac上默认用的是Metal加速，有些与Python相关的向量化库不是为这个准备的，后面遇到import报错先看看是不是架构问题。

我在实操前把防火墙、端口占用这些问题都提前确认了一遍，省得后面装到一半才发现跟其他服务冲突。

2. Ollama部署实操与DeepSeek模型管理

2.1 Ollama安装与国内下载加速的正确姿势

Ollama的官方安装命令一键脚本，正常情况下执行就完了。但很多人在第一步就卡住了——因为安装脚本要从GitHub下载文件，国内网络环境很慢，部分情况下还会临时中断。

别硬等官方源。官方推荐的是直接改环境变量，让下载走国内镜像：

curl -fsSL https://ollama.com/install.sh | sh

如果这个命令卡住了，按Ctrl+C中断，然后手动下载安装包。

我这边测试下来最稳的方式是：直接从镜像源下载tar包，自己解压配置。Linux x86_64架构的执行方式如下：

# 下载安装包（这里用国内可达的镜像地址，速度会快很多） wget https://mirror.example.com/ollama/ollama-linux-amd64.tgz # 解压到指定目录 sudo tar -C /usr/local -xzf ollama-linux-amd64.tgz # 启动服务 nohup /usr/local/bin/ollama serve > /tmp/ollama.log 2>&1 &

安装完之后验证一下：

ollama --version

能输出版本号就说明装好了。这里有个注意点，不要用root直接跑ollama serve，最好建一个普通用户，给它的家目录设置足够权限，因为模型默认下载到~/.ollama/models下面。

Windows用户就直接去GitHub Releases页面下OllamaSetup.exe，双击安装，不过下载慢的问题同样存在，建议找找镜像或让朋友在能正常访问的环境下帮忙下载后拷过来。

2.2 拉取DeepSeek模型：解决下载慢到怀疑人生的问题

装了Ollama只是开始，真正让人崩溃的是ollama pull deepseek-r1:7b这一步。

我第一拉的时候，进度条走得像龟爬，半个多小时都没下完一半，最后实在等不了了直接中断。原因是Ollama默认从官方registry拉模型，国内访问速度极不稳定。

解决方法很简单，设置镜像源环境变量：

export OLLAMA_REGISTRY_MIRROR="https://你的镜像源地址"

注意，这里不要用那些来路不明的第三方源，安全性没法保证。我建议优先用能访问的公共源，或者先去Ollama官网把模型文件列表看清楚，了解每个模型对应的哈希值，心里有数再下载。

配好环境变量后重启Ollama服务，再执行：

ollama pull deepseek-r1:7b

这时候速度会快很多。如果还是慢，不要反复重试，换个思路：先用带代理的工具把模型文件下完整再放到Ollama的模型目录里，但这需要你熟悉模型文件结构，新手不推荐，很容易搞坏。

拉取完成后看看本地模型列表：

ollama list

能看到deepseek-r1:7b就说明OK了。这时候你可以直接跟模型对话了：

ollama run deepseek-r1:7b "你好，简单介绍一下你自己"

首次加载模型会有一个初始化过程，等一会儿就会输出回复。这一步通了，说明Ollama这部分就搞定了。

2.3 模型参数调优：让DeepSeek更聪明

很多人拉完模型就完事了，其实Ollama允许你在运行时设置参数，直接影响回答质量和速度。我第一次跑的时候没调，回答得干巴巴的，后来调整了参数明显好转。

在ollama run里直接改：

ollama run deepseek-r1:7b --temperature 0.7 --top_p 0.9

或者写一个Modelfile，把参数固化进去：

FROM deepseek-r1:7b PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER max_tokens 2048 PARAMETER stop "Human,"

然后创建新模型：

ollama create deepseek-custom -f Modelfile

这些参数里，temperature控制回答的随机性，值越低回答越保守和确定，适合知识问答和代码生成；值越高回答越多样和有创意，适合头脑风暴和文本生成。top_p也是控制采样范围的，一般保持0.8-0.9就行。max_tokens限制回答的最大长度，不设的话长文本生成容易被截断。

我常用的一个组合是：知识库问答用temperature 0.3，top_p 0.8，这样回答最贴近文档本身的内容，不会自己发挥；写故事和创意类内容用temperature 0.9，top_p 0.95，放飞一点效果更好。

提示：改了Modelfile后，原来基于该模型的应用可以继续用旧模型，你只需要在新模型上做测试就行。

3. 知识库搭建：Dify本地部署与RAG流程配置

3.1 Dify的Docker Compose部署流程

Ollama提供的AI能力只能聊天，还不能回答关于你私有文档的问题。知识库的核心技术是RAG（检索增强生成），它解决的问题是：让模型在回答之前先从知识库里检索出相关内容，基于这些检索结果再组织回答。

Dify是实现RAG最好的开源方案之一。部署Dify社区版的方式是Docker Compose，先确认你装了Docker和Docker Compose插件。

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

这里有个很有用的配置，Dify会自动读取.env里的SECRET_KEY和POSTGRES_PASSWORD，所以复制完.env后最好先编辑一下，把密码改成强密码，不然容易被人扫出默认值攻击。

服务的启动过程会拉取好几个镜像：dify-api、dify-web、postgres、redis、weaviate（或qdrant），大小加起来好几个G，也需要一些时间。国内用户如果拉镜像很费劲，给Docker配置一个可用的镜像加速器会舒服很多。

启动完成后docker compose ps看状态，都是Up就成功了。打开http://localhost/install这个地址，设置管理员账号密码，然后登录进去。

3.2 知识库的创建与文档上传细节

Dify登录后先在右上角点头像，设置——模型供应商，把Ollama配进去。这里有个好消息，Dify原生支持Ollama，你只需要填Ollama服务地址和模型名称。

配置完模型后，创建知识库：

1. 在顶部导航点"知识库"，然后点"创建知识库"
2. 填写知识库名称和描述
3. 上传你的文档（支持TXT、PDF、Markdown等格式）
4. 选择分段模式，然后点"保存并处理"

这里最关键的是分段设置。Dify默认分段长度是500个字符、重叠长度50。但实际效果取决于你的文档类型。我做测试的时候导入了一份几十页的Markdown技术文档，默认配置分段后检索的效果很差，原因是很多段落边界刚好被切断，导致语义不完整。

我的做法是在创建知识库时手动调整分段设置。技术文档我一般把"分段长度"调到800-1000，"分段重叠"设成100左右。这样既不会因为太长导致检索时包含太多不相关内容，又能保证段落语义基本完整。

注意：创建知识库后，分段规则是不能改的。所以一定要在处理文档前想清楚参数，不然后面只能删了重建。

Dify会调用向量模型把每个分段转成向量，并存入向量数据库。我这边配置的是嵌入模型用Ollama上的bge-m3或者通用型嵌入模型，效果都还行，Dify官方文档说支持很多嵌入模型，选一个自己机器跑得动的就行。

3.3 对话应用的流程配置与效果实测

知识库创建好之后，在顶部导航点"创建应用"，选择"聊天助手"，然后在应用编排界面里把这个知识库关联为上下文。这一步很关键，很多人在这一步漏掉了，导致应用根本不会用到知识库的内容。

配置好之后，把问题提给它，回答的结果会引用知识库的分段内容。我在测试时问了几个只有文档里才有的具体问题，模型都回答正确，并且来源指向了文档里的相关段落。

但如果你的文档内容比较长，或者知识库覆盖的领域特别广，会出现检索召回不准确的情况。Dify提供了一个工具让你查看检索到的分段列表，我会在"调试预览"里先看一遍，如果召回内容不对，就去调整分段策略或者换嵌入模型。

效果调整这块，我给你们一个自查清单：

• 知识库是否启用了？在应用编排里确认上下文关联了正确的知识库
• 检索召回的内容是否相关？打开调试预览看具体的召回列表
• 分段长度是否合理？太短语义碎、太长检索噪声多
• 嵌入模型与查询模型是否匹配？两种不同语言的嵌入效果差异明显

如果你把上面四项都调过，一般就能得到一个比较可用的本地知识库问答系统。

4. 三个报错的完整解决实录

这部分是标题的重点，也是我这篇文章里最有价值的部分。这三个报错不是网上复制来的，是我自己一台新机器、一台老机器上真实折腾过的问题，排查过程都记录下来，你们照着走就行。

4.1 报错一：Ollama下载卡在0%或中途失败

现象描述：执行ollama pull deepseek-r1:7b后，进度条长时间停留在0%，或者下载了百分之二十几就报错退出，反复重试都一样。

这个问题绝大部分情况是网络问题，不是Ollama软件问题。原因在于模型文件托管在海外，国内直连很不稳定，偶尔能连上但很快断流。

排查步骤：

1. 用curl -I测试一下下载地址的连通性（注意，别真的下载，只测试响应头）
2. 确认OLLAMA_REGISTRY_MIRROR环境变量是否配置成功：echo $OLLAMA_REGISTRY_MIRROR
3. 检查磁盘空间：df -h，Ollama下载临时文件会先写满缓存目录再转移，空间不足也会中途失败
4. 检查代理设置：如果系统配置了HTTP代理，而Ollama没读到，会造成连接被重置

最终我是这样解决的：设置镜像源环境变量 + 重启Ollama服务 + 重新pull。具体来说：

# 编辑环境变量 sudo vim /etc/profile.d/ollama-env.sh # 写入下面两行 export OLLAMA_HOST="0.0.0.0" export OLLAMA_REGISTRY_MIRROR="你的可用镜像源" # 使配置生效 source /etc/profile.d/ollama-env.sh # 重启Ollama sudo systemctl restart ollama

这里有一个细节，Ollama在systemd下运行时会读取自己专门的配置目录/etc/systemd/system/ollama.service.d/下的override.conf，而不是从/etc/profile读取。所以你在终端里export变量只对当前终端窗口有效，服务本身并不会读取。这是我的血泪教训，找了半天原因才发现是环境变量根本没生效。

最稳妥的做法是编辑override.conf：

[Service] Environment="OLLAMA_HOST=0.0.0.0" Environment="OLLAMA_REGISTRY_MIRROR=你的镜像源"

保存后：

sudo systemctl daemon-reload sudo systemctl restart ollama

然后再ollama pull deepseek-r1:7b，速度明显上来，几分钟就拉完了，后面再也没失败过。

4.2 报错二：Dify容器启动失败，数据库端口冲突

现象描述：执行docker compose up -d的时候，postgres容器一直起不来，日志提示端口已占用。

Dify默认使用5432端口跑PostgreSQL，但很多机器上之前已经装了Postgres，占了这个端口。这个非常常见。

排查步骤：

1. docker compose ps查看哪些服务是Up，哪些是Restarting
2. docker logs dify-docker-postgres-1看具体日志，里面会写port already in use
3. 用ss -tlnp | grep 5432看看到底是什么进程占用了端口

解决方案有两个，推荐第一个：

方案一（改Dify的端口映射）：

cd dify/docker vim .env # 找到 POSTGRES_PORT=5432，改成 25432 # 保存 docker compose down docker compose up -d

方案二（停掉已有的Postgres服务）：

sudo systemctl stop postgresql sudo systemctl disable postgresql

我用的方法一，因为不想动系统里已有的服务，万一别人在用呢。

这个问题本质上不是Dify的bug，而是Docker桥接网络的端口映射设计使然。如果你之前跑过其他需要数据库的服务，检查一下该服务的端口，提前避免冲突可以省很多麻烦。

4.3 报错三：Ollama启动正常，但本地API调用连不上

现象描述：ollama run deepseek-r1:7b能正常对话，但用Python调用http://localhost:11434/api/chat报连接错误，或者Dify配置了Ollama但测试连接一直是红的。

这个问题的根源在于Ollama默认只监听127.0.0.1，也就是只接受本机访问。Dify容器运行在Docker网络里，容器访问宿主机的localhost其实是另一个地址，所以连不上。

排查步骤：

1. curl http://127.0.0.1:11434/api/version，本机访问是否正常
2. curl http://<你的服务器IP>:11434/api/version，从其他机器/容器访问是否通
3. 检查Ollama的监听地址：ss -tlnp | grep 11434，如果看到127.0.0.1:11434，那你监听的就是回环地址，Docker容器访问肯定失败

解决办法是让Ollama监听在所有网络接口上：

# 在override.conf里加 Environment="OLLAMA_HOST=0.0.0.0"

然后restart。这时候再用ss -tlnp | grep 11434，会看到监听地址变成了0.0.0.0:11434，Docker容器里就能访问了。

另外一个隐蔽的点是防火墙。云服务器上如果安全组没开11434端口，外部机器访问会被拒。注意，如果是家庭网络测试，Docker容器访问宿主机的localhost用host.docker.internal，Dify的Ollama配置里填这个域名而不是localhost。

最后再强调一次：不要为了省事把Ollama直接暴露到公网。0.0.0.0监听意味着任何能访问到你服务器的人都能直接调用你的模型API，这可危险得很。如果你有生产环境需求，加上API key认证或者用内网隔离，才是正确做法。

5. 部署完成后的进阶技巧：API接入与应用扩展

部署完了只是第一步，要让DeepSeek真正好用，还得把这几个玩明白。

5.1 用OpenAI SDK接入DeepSeek本地API

Ollama的API接口是兼容OpenAI格式的，所以你可以直接用OpenAI的Python SDK调本地模型，代码几乎不用改：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # 本地部署不需要真实key，占位即可 ) response = client.chat.completions.create( model="deepseek-r1:7b", messages=[ {"role": "user", "content": "用JavaScript写一个快速排序"} ], temperature=0.3, ) print(response.choices[0].message.content)

这个兼容特性让DeepSeek可以直接替换很多项目的模型层。比如你想在Codex或者Cursor这类开发工具里接入本地模型，大部分情况下只需要把base_url换掉，加上模型名，很多其他配置都不用动。

5.2 把知识库做成对外可用的服务

Dify内置了Web App和API服务，你创建的应用可以直接发布为公开链接，也可以调用API接口给自己的业务系统用。

我建议的路子是：先用Dify的Web界面多做几轮测试，确认回答质量和检索准确度没问题，再通过服务编排的"发布"功能对外服务。Dify会为每个应用生成一个唯一的API密钥，调用侧通过HTTP请求访问应用，支持流式输出。

发布之前，有几件产品化的事情值得关注：

• 安全设置：限制频繁请求、增加访问密码
• 日志监控：多试几轮看看有没有不合理的召回和回答
• 数据更新：知识库文档要定期重新处理，Dify的增量更新接口可以直接用

5.3 折腾完的几点避坑心得

最后分享一些我这几天反复踩坑后得到的经验。

能装系统就装Linux。Windows上跑Docker和Ollama，多少会有一些别别扭扭的问题，尤其是路径挂载和文件权限。我有一台Windows机器试了一下午，最后还是换到Linux才顺利跑通。

配置文件和启动脚本要固化。不要光在终端敲命令，环境变量、启动参数、镜像源都写进系统配置文件，这样系统重启之后服务能自己起来，不用每次手动敲一遍。

日志是定位问题的最好朋友。Ollama的日志在journalctl -u ollama -f或者/tmp/ollama.log，Dify的日志在docker logs里面。遇到问题先翻日志，别一通瞎改。很多报错在日志里已经把原因写得明明白白了，比如端口占用、内存不足、模型文件损坏，都有对应的错误字眼。

内存不够千万别硬上大模型。我试过在一台16G内存的机器上跑14B模型，加载的时候内存占满，系统进入假死状态，最后只能强制重启。内存不够就用7B量化版，体验远比死机好。

再说一个我现在习以为常的操作：每次改完Ollama配置，我都会用一个测试脚本自动验证API连通性和响应时间：

time curl http://localhost:11434/api/chat \ -d '{"model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "ping"}], "stream": false}'

能快速返回就意味着一切正常，省得每次都要打开聊天界面试一遍。这套部署从零开始的话，整个流程熟练以后大概40分钟就能搞定，第一次弄的话预留一个下午比较稳妥，大部分时间都花在下载和排错上。搞完之后你就有了一台完全不依赖外网的大模型问答机器，DeepSeek的聊天能力加上你自己文档的知识库，这个组合能做的事，比你想象中要多得多。