企业官网建设流程全解析

简介：一份DeepSeek R1本地部署与本地知识库搭建的完整图文教程，面向需要脱离云端、在自有设备上运行大模型的开发者、研究人员和AI应用爱好者，也适合作为大模型入门实操参考。教程按四步递进方式组织：首先讲解Ollama开源工具的安装与命令行验证，其次介绍DeepSeek R1模型不同参数量版本的选择逻辑，并针对8GB、16GB、32GB内存设备分别给出7B、13B、33B模型选型建议；随后梳理Cherry-Studio界面工具从注册账号、创建API密钥到配置本地模型的完整流程，最后说明如何新建知识库、批量添加文件并在对话中启用知识库来提升回答准确性。整个流程覆盖安装、配置、调用、知识库整合四大环节，关键步骤均有界面说明和版本对照，降低上手门槛。资源包仅含1个docx文档，大小4.71MB，正文结构清晰、可直接按步骤操作，已有3084人学习下载，是本地化部署DeepSeek R1并构建私有知识库的实用教程。 把DeepSeek R1本地部署这件事，我前前后后折腾了快两周。从用Ollama本地部署DeepSeek R1开始，到解决GPU显存不够的问题，再到搭建本地知识库把私有文档接进模型，中间踩过的坑足够写一本小册子。这篇教程会覆盖整个链路：硬件选型、模型下载、运行调优、知识库工具对比、RAG检索配置，每一步都会说明为什么这么选，以及我实际踩过的坑。适合三类人看：不想把数据交给云端API的隐私敏感用户、手里有显卡但还没把性能吃透的玩家，以及想在公司内网搭一套私有知识问答系统的工程师。整个方案以开源工具为主，包括Ollama、Dify、bge-m3，优先保证离线可用和成本可控。

1. 装DeepSeek R1之前，先把这套账算明白

先看模型家族。DeepSeek R1的完整版是671B参数的MoE架构，不是普通个人电脑能跑的，不要对它有幻想。但官方蒸馏出一系列小尺寸版本：1.5B、7B、8B、14B、32B、70B，这些在Ollama上的标签分别是deepseek-r1:1.5b、deepseek-r1:7b、deepseek-r1:8b、deepseek-r1:14b、deepseek-r1:32b、deepseek-r1:70b。蒸馏版本保留了完整版R1的推理风格，模型会在正式回答前输出一段思考过程，这是它和其他对话模型体验上最大的区别。很多朋友第一次用本地DeepSeek R1会困惑"怎么还在输出",其实那不是卡顿，是它在内部推理。

1.1 不同规格模型到底要什么配置

我整理了一张配置表，按量化后的模型体积估算，能帮你快速判断自己的机器能跑到哪个级别。

注意了，量化体积只是权重文件大小，推理运行时还有KV Cache要吃显存或内存。上下文拉到16K时，7B模型额外占用约1~2GB，14B模型还要更多。所以表中"最低配置"我都建议再留2GB余量，不然一开长对话就OOM。这里解释一下KV Cache是什么：大模型生成每个token时都要重新计算前面所有token的注意力分数，KV Cache就是把中间结果缓存起来，避免重复计算。上下文拉得越长，缓存占得越多，这是显存压力的主要来源之一。

1.2 量化等级怎么选：Q4_K_M是性价比之王

本地部署绕不开量化概念。llama.cpp生态用GGUF格式存储模型，量化就是用降低数值精度的方法压缩模型体积。常见的Q4_K_M、Q5_K_M、Q8_0、F16，数字表示比特位数，后面的K_M表示混合精度策略。Q4_K_M体积小、质量损失在可接受范围，是社区默认推荐；Q8_0更接近原始精度但体积直接翻倍；F16体积最大，非旗舰显卡一般不用考虑。我的经验：DeepSeek R1蒸馏版在Q4_K_M下的回答质量和Q8_0差异很小，但显存需求差出一大截。比如7B模型，Q4_K_M约4.7GB，Q8_0约7.1GB，后者已经把8GB显存占满了。新手不要纠结，第一版先选Q4_K_M，等跑通了再做对比实验，把资源留给更有价值的分块和检索调优。

1.3 没有NVIDIA显卡也不是末日

部署前我特意问了几个只有AMD显卡或纯CPU的朋友，给出三条替代路线。第一，Apple Silicon Mac：统一内存架构在跑大模型上有天然优势，M系列芯片的MacBook Pro如果内存32GB，跑14B模型很流畅，64GB内存甚至可以摸一摸32B模型，Ollama在macOS下直接走Metal加速，体验不错。第二，AMD显卡：Ollama新版支持Vulkan后端，RX 6000/7000系列能加速一部分推理，但兼容性不如NVIDIA稳定，报错时可查的资料也少，建议用CPU兜底。第三，纯CPU加32GB以上内存：能跑7B/14B，速度大概每分钟几轮完整回答，适合离线批处理，不适合实时聊天。我自己的主力部署机是RTX 3060 12GB，后面所有实测数据都基于这台机器，大家参考时结合自己配置换算一下。

2. Ollama本地部署DeepSeek R1：最省心的命令行路线

2.1 为什么是Ollama而不是LM Studio

本地运行大模型的工具不少，LM Studio有图形界面，对新手友好但自动化能力弱，不方便脚本调用；llama.cpp性能极致但需要编译和手动折腾；Text-generation-webui功能全面但对只想跑模型的用户来说太重。Ollama的定位是"大模型的Homebrew"：一条命令装好、一条命令拉模型、一条命令起服务，底层自动调用llama.cpp完成推理优化，还自带一个OpenAI兼容的HTTP API，后面接Dify、写脚本、做Web应用都能直接用。我最终选择Ollama还是看中它的模型管理能力。本地模型不像云端服务，拉多了不管理就是灾难，Ollama的列表查看、删除、指定版本拉取都很直观，后面换模型只需改一个名字参数，这种低摩擦对迭代测试太重要了。

2.2 安装与拉取模型的完整步骤

macOS和Windows直接去Ollama官网下载安装包，双击安装即可。Linux服务器用一行命令：

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

安装完成后先确认版本：

ollama --version

然后拉取DeepSeek R1模型。个人建议第一台机器先用7B试水，先把链路跑通，再考虑更大的版本：

ollama pull deepseek-r1:7b

如果你的显存有16GB以上，可以直接上14B：

ollama pull deepseek-r1:14b

拉取完成后，在终端里对话：

ollama run deepseek-r1:7b "用一句话解释什么是RAG"

首次运行会加载模型到显存，需要等几秒。你会看到它确实有推理模型的风格，回答前有一段思考输出。这里有个很常见的坑：模型默认下载到~/.ollama/models，如果你的系统盘空间紧张，几个GB的模型很快会把盘塞满。建议提前设置模型存储路径。Linux和macOS在~/.bashrc或~/.zshrc里加一行：

export OLLAMA_MODELS=/your/data/dir/ollama

Windows下设置系统环境变量OLLAMA_MODELS即可。设置完重启Ollama服务再拉模型，不然路径不生效。

2.3 API接口验证：模型服务的真正价值

Ollama装好后会自动注册系统服务，启动后监听11434端口。除了在终端里对话，更关键的是API接口。先测试原生接口：

curl http://localhost:11434/api/chat -d '{ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "你好"}] }'

返回结果里会包含完整回答和token统计。也可以调用OpenAI兼容的接口：

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "你好"}] }'

这意味着你现有的OpenAI SDK代码，把base_url换成http://127.0.0.1:11434/v1就能切到本地模型，成本直接降到零。Ollama本身没有鉴权机制，如果机器对外开放，建议只监听127.0.0.1，或者在前面加一层反向代理做访问控制。我自己的做法是在防火墙层直接限制11434端口只允许内网访问，避免裸奔在公网上。

3. 跑起来只是开始：显存、上下文、速度的三项调优

3.1 显存不够时的补救方案

我第一台部署机是RTX 3060 12GB，跑14B时经常出现out of memory报错。首先要明白Ollama默认会在显存里缓存已加载的模型，多模型切换时容易相互挤占。调整环境变量能明显缓解：

export OLLAMA_MAX_LOADED_MODELS=1 export OLLAMA_NUM_PARALLEL=1

OLLAMA_MAX_LOADED_MODELS限制同时加载的模型数量，OLLAMA_NUM_PARALLEL限制同一模型并发请求数，两者都能减少显存缓存占用。如果还要省，可以把模型换成更小的量化版本，或者直接在CPU推理。一条命令查看显存占用：

nvidia-smi

推理过程中在另一个终端运行它，能清楚看到模型占了多少显存、KV Cache涨了多少。这些数据是调优的依据。我见过不少朋友报错半天，结果连NVIDIA驱动版本和CUDA版本都不匹配，白折腾。所以建议装完Ollama先跑一次nvidia-smi确认驱动正常，再开始拉模型。

3.2 上下文窗口与请求参数：别让长对话断片

DeepSeek R1单轮问题表现不错，但长对话或长文档分析时经常出现"记不住前面内容"的情况，大多不是模型笨，而是上下文窗口太小。Ollama默认上下文可能只有4K，超过就截断。通过OLLAMA_CONTEXT_LENGTH调整：

export OLLAMA_CONTEXT_LENGTH=16384

同时，单次请求也要设置参数。比如：

curl http://localhost:11434/api/chat -d '{ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "请总结这篇文章并提供三个要点"}], "stream": false, "options": { "temperature": 0.3, "num_predict": 2048 } }'

经验是：做知识库问答、数据抽取这类需要严谨的任务，temperature设低一些（0.2~0.5），追求稳定；做创意写作、头脑风暴时再调到0.8以上。num_predict控制最大生成token数，DeepSeek R1需要先输出一大段思考过程，输出长度预留要充足，否则答案会在中途被截断，看起来就像"话没说完"。

3.3 实测速度：多少token/s算可接受

我实测过几组数据（RTX 3060 12GB）：

注意，这是输出速度。DeepSeek R1因为先输出思考链，实际等待第一字的时间和整体请求时长会比普通对话模型长一些，这是推理模型的正常表现，别误以为卡了。如果你要把它接入聊天机器人，建议前端加一个"思考中"的状态提示，不然用户会以为系统挂了。

4. 本地知识库工具选型：Dify、FastGPT、MaxKB的取舍

模型部署好，只解决了一半问题。让它读你的私人文档、懂你公司的制度规章，这就是本地知识库的用途。它背后是RAG（检索增强生成）技术：把文档向量化存入向量库，用户提问时检索最相关片段，拼进提示词让模型参考回答。RAG的价值在于：大模型的参数知识是训练时固化的，它不可能知道你没公开的内部资料，知识库正好补齐这块短板。

4.1 三个开源工具的基本盘

市面上开源可自托管的知识库平台很多，我重点对比三个主流的：

三者都支持接入本地模型的OpenAI兼容API，但Dify对Ollama的原生支持最省事，配置界面里直接选Ollama供应商，填URL就行，不用在外部适配层上花时间。FastGPT和MaxKB虽然也能接，但要么需要手动配兼容层，要么对本地Embedding的支持不够彻底，文档向量化还得走云端API，隐私性大打折扣。

4.2 为什么最终选了Dify

原因有三条。第一，模型接入的灵活性：Dify能同时接LLM、Embedding、Rerank三种模型，而且都原生支持Ollama，这在开源工具里不多见。第二，应用层的完成度：Dify的对话型应用、Agent应用、工作流编排可以应对从简单问答到多轮工具调用的大部分需求，不用再从零开发。第三，社区和迭代速度：Dify的GitHub仓库更新频繁、文档完善，遇到问题比较容易搜到案例。如果只是快速给团队做个轻量问答，MaxKB确实更快；但如果想把知识库做成可持续迭代的产品，Dify的扩展空间更大。我最后选择Dify，本质上是给未来留余地。

5. 搭建本地知识库：从Embedding模型到RAG检索全流程

5.1 Dify部署与宿主机通信问题

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

首次启动需要拉取多个镜像，大约需要几分钟到十几分钟。完成后访问http://localhost/install设置管理员账号。这里有一个极其常见的坑：Dify容器化部署后，里面的服务访问宿主机的Ollama，不能用localhost，因为容器内的localhost是指容器本身。macOS和Windows的Docker Desktop用http://host.docker.internal:11434，Linux要用宿主机内网IP，比如http://172.17.0.1:11434。这个细节很多人栽过跟头，文档里不会特意写，先记住。

5.2 配置Ollama模型和Embedding模型

登录Dify后台：设置 → 模型供应商 → Ollama。填写API Endpoint地址（就是上面说的host.docker.internal或172.17.0.1路径），保存后把DeepSeek R1模型类型设为LLM。Embedding模型推荐bge-m3，这是中英双语效果都稳的嵌入模型，体积也不大。先在Ollama里拉取：

ollama pull bge-m3

然后在Dify的模型供应商Ollama下，新增Embedding类型，模型名填bge-m3。Dify会自动识别向量维度，不需要手动填数字。这一步完成后，Dify就有了"读文档"和"检索文档"的能力。很多人会问为什么Embedding必须单独配，因为大语言模型和Embedding模型是两个不同用途的模型，LLM负责生成文本，Embedding负责将文本转换成向量，两个任务需要不同的模型来实现，不能混用。

5.3 创建知识库并接入对话应用

按下面流程操作：第一步，在Dify左侧点"知识库"，创建知识库并上传PDF、TXT、Word、Markdown文档。第二步，分段设置，系统默认按每段500个token切分，第一次可以先保持默认。第三步，索引方式选"高质量"，走向量检索；选"经济"会退化成关键词匹配，质量差不少。第四步，创建应用时选"对话型应用"，在设置里把模型换成deepseek-r1:7b或14b。第五步，在应用页面添加知识库，选择刚创建的库。第六步，在"提示词编排"里加一段固定指令：请严格根据知识库内容回答，如果知识库中没有相关内容，明确说不知道，不要自行编造。然后点预览测试，问一个只有知识库里才有的问题，比如上传了产品手册，就问"这个产品的保修政策是什么"，看模型能否检索到对应片段并给出回答。

6. RAG检索质量调优：分块、召回、重排的实战经验

6.1 分块大小：最容易被忽略的变量

同样的文档，不同分块策略得出的回答质量能差两个级别。分块太大，比如一篇长文不分段整个塞进向量库，检索命中后带入大量无关信息，回答就会偏题。分块太小，比如按一两句话切，信息被割裂，模型拼不出完整答案，只能靠猜。我的经验值：技术文档、产品说明按350到500个token切，保留章节标题结构；法律合同、制度文件按250到350个token切，这类文本上下文依赖强，小块更精准；对话记录按200到300个token切，避免把多轮对话语义冲散。Dify里可以在知识库分段设置中调整最大分段长度，也可以自定义分隔符。改完分段后需要重新索引文档才会生效，测试时注意这一点，免得以为参数没生效。

6.2 TopK与相似度阈值怎么配

检索参数里两个最关键：TopK和Score Threshold。TopK决定召回多少片段给模型，Dify默认3。片段太少容易漏信息，太多就带噪音。我常用的初始值是TopK=4、Score Threshold=0.5。实际测试中阈值的取舍需要重点观察：阈值设到0.8，很多问题检索不到内容，模型就直接说"不知道"；阈值设到0.2，什么牛鬼蛇神都能进上下文，模型就会一本正经地胡说八道。0.5左右是多数场景的甜点区，然后再根据实际问答结果的偏差方向微调。测试时建议准备好二十个与知识库相关的真实问题，每次改完参数统一跑一遍，用通过率来评估效果，而不是凭一两个例子感觉调得好。我自己就是这么干的，没有问题集就谈不上系统调优。

6.3 重排序：把准确率再拉高的一步

向量检索本质是找语义相似的片段，它可以召回候选，但不擅长把最相关的排在最前面。这时Rerank模型就有用了：先粗召回20条候选，再用Rerank模型精排选出TopK交给大模型。Dify的检索设置里可以配置Rerank模型。如果你不愿意用云端API，也可以在本地部署bge-reranker系列模型。实测下来，在相似文档较多的场景，比如多份合同放一个知识库、产品型号相近的手册，开重排前后的准确率差距非常明显，能从80%出头升到90%以上。代价是多一次模型推理，响应时间稍长，但知识库场景里完全值得。如果只是想快速验证RAG效果，可以先用云端Rerank API跑通流程，再考虑本地化。

到这一步，一套完整的"本地DeepSeek R1加本地知识库"就落地了。最后提醒一句：本地部署方案虽然香，但别指望一次到位。我自己调分块、调阈值、换Embedding模型，前后花了两三天才把准确率提到满意的水平。如果只是个人玩，建议先用7B小模型把整个链路跑通，再根据实际效果换大模型，这个顺序省时省力，性价比最高。

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