企业官网建设流程全解析

简介：针对本地部署 DeepSeek 并搭建私有知识库的需求，这份教程适合具备一定技术背景的初学者，也适合希望将大模型能力落地到内部服务的研发团队。它以 Ollama 为核心工具，覆盖 Windows 环境下的软件下载、安装校验、后台运行确认，到 DeepSeek R1 各尺寸模型的安装与对话测试，完整走通本地部署链路；教程按 1.5b、7b、14b、32b、70b 等量级分别给出命令和硬件配置建议，例如不同算力显卡对应不同模型规格，帮助读者按自身设备合理选型，同时说明修改模型保存路径、删除模型等维护操作。在此基础上，进一步引入 Cherry Studio 搭建私有知识库，实现基于内部文档的定制化问答，并提醒通过 API 键连接云端服务及防范安全风险的替代方案。资源包共 1 个 docx 文档，约 2.8MB，采用章节式编排，步骤、命令和界面说明清晰，可边看边操作；已有 16452 人学习下载，适合想要低成本体验本地大模型并建立私有知识库的读者。

1. DeepSeek本地部署：把模型装进自己的电脑，数据不出门

DeepSeek本地部署最近几乎成了本地大模型玩家绕不开的一课。借助Ollama，一条命令就能把DeepSeek-R1的各版本拉到本机运行，再套上ChatBox图形界面，日常问答体验和云端版相差不大。私有知识库解决的是另一件事：内部文档不必上传到公开服务，通过Cherry Studio把文件切片、向量化，聊天时模型直接引用本地资料作答，数据全程留在自己手里。这套链路适合不想把资料交给云端的个人开发者和内网小团队。先跑通1.5b小模型验证环境，再按显卡内存升级，别一上来就想跑70b。本文按Windows实测流程写，AMD VEGA 56这类中端显卡也能带得动7b。

2. Ollama：把DeepSeek R1装进本地，先跑通链路再谈优化

2.1 软硬件需求：先想清楚能跑哪个版本

DeepSeek R1是一组蒸馏模型，从1.5b到70b再到671B满血版，体积跨了两个数量级。很多人一上来就想装最大的版本，结果显存爆了，或者推理慢到不如用云端。选型的正确顺序是：先看内存，再看显卡，最后定版本。

我自己这台机器是AMD VEGA 56，属于中端偏老的显卡，在Ollama里跑7b版本，速度谈不上快，但日常问答、写摘要、改文案完全够用。N卡在Ollama上的兼容性普遍更好，A卡也能跑，不用被配置贴劝退。

671B满血版本普通人基本装不了，光是硬盘占用就是几百GB，先不惦记。个人部署的主流区间是1.5b到32b，7b是最多人的选择。内存低于16GB的机器建议只跑1.5b，否则模型加载后整个系统都会变得很卡。

2.2 Ollama安装与验证：装完先跑这两条命令

Ollama安装没有太多玄学，官网下载OllamaSetup.exe一路下一步即可。值得多花十秒的是安装完成后的验证，我见过有人没验证就直接跑模型，最后绕了一大圈才发现是Ollama本身没起来。

# 查看Ollama版本，确认安装成功且已写入PATH ollama -v # 浏览器访问下面的地址，看到 Ollama is running 说明后台服务正常 # http://localhost:11434/

第一条命令如果提示"不是内部或外部命令"，先别急着重装，关掉当前cmd窗口重新开一个。Ollama安装时会写入用户环境变量，新开的终端才会加载。浏览器验证那条是访问Ollama内置的健康检查接口，返回正常文本就说明后台服务在运行，后面所有模型的下载和推理都依赖它。

2.3 部署DeepSeek-R1：ollama run 这条命令到底做了什么

Ollama没有用户界面，所有操作在命令行完成。安装模型用的就是ollama run加模型标签，不同的标签对应不同参数规模的蒸馏版本。

# 先用1.5b版本跑通全流程，任何配置都能带得动 ollama run deepseek-r1:1.5b # 硬件允许再切到7b，对话质量提升明显 ollama run deepseek-r1:7b # 大显存机器可以尝试32b蒸馏版 ollama run deepseek-r1:32b

ollama run的执行逻辑是：先检查本地models目录有没有同名模型缓存，没有就自动从官方源下载，下载完成后直接进入交互式对话。终端里没有"安装完成"这类提示，看到模型开始回复问题就是装好了。模型文件默认放在C:\Users%username%.ollama\models。

冒号后面的数字是参数规模，1.5b最小，适合旧电脑和纯验证；7b是个人使用最多的档位；32b起对内存要求明显提升，低于32GB内存不建议尝试。推荐先下载1.5b把整个教程链路跑通，再根据实际硬件的对话速度决定要不要升级版本。

2.4 改模型存储路径：C盘红了才想起来就晚了

默认路径在C盘用户目录下，两个大模型一装，C盘空间肉眼可见地掉。建议在下载第一个模型之前就把存储路径改好，省得后面再迁移。

# Windows系统环境变量里新增以下配置： # 变量名：OLLAMA_MODELS # 变量值：D:\OllamaModels（按自己的盘符调整）

具体操作路径：右键"此电脑"→ 属性 → 高级系统设置 → 环境变量 → 系统变量 → 新建。变量值建议用纯英文路径，中文路径在某些版本的Ollama里解析会出问题，Linux和macOS做法相同，替换成/home/用户名/models这类Unix风格路径即可。

改完必须重启Ollama进程才生效，任务管理器里结束Ollama进程后重新运行。环境变量只对新启动的进程生效，不重启等于白改。另一个常见误解是改路径后老模型会自动迁移，实际上环境变量只管新下载的模型。想迁移就手动把.ollama\models里的内容拷贝到新目录，再删除旧目录，实测可行。

2.5 命令行对话与模型清理：ollama run、/?、ollama rm

模型装好后，命令行直接就能聊天，验证安装是否成功最直接的方式就是进去说句话。

# 进入对话模式 ollama run deepseek-r1:7b # 对话中输入 /? 查看帮助 /? # 退出对话 /bye

对话模式支持多轮上下文，输入/?能看到退出命令。不想要的模型用ollama rm删除，释放磁盘空间。

# 查看已安装模型列表和占用 ollama list # 删除指定模型，删除不可逆，确认后再执行 ollama rm deepseek-r1:7b

删除是不可逆操作，模型文件会直接从磁盘移除，建议确认不再需要或磁盘确实紧张时再删。官方源下载大模型失败的情况不少，删了再重下又是一遍时间成本。删除之前可以用ollama list确认模型名称，避免误删。

3. ChatBox：图形界面接入DeepSeek，两条通道按需选

3.1 纯命令行不够用，图形界面补上体验

Ollama命令行能对话，但没有历史记录管理，上下文不直观，界面也不友好。ChatBox的作用是把模型聊天包装成主流对话应用的形态，支持桌面版和网页版。更重要的是它同时支持两类接入：直连本地Ollama服务，或者走云端API，取哪个取决于你的机器性能和数据敏感性。

如果你是纯新手，建议先用方案A把链路跑通，确认Ollama和模型都正常，再注册API走方案B。这样出了问题能判断是哪一段配置错了，不至于几个变量混在一起抓瞎。ChatBox官网提供中文界面，下载包很小，装完没有任何多余配置，打开就是对话窗口。

3.2 方案A：ChatBox直连Ollama本地模型

机器性能允许时，直接在ChatBox里连接本地Ollama，数据不出本机，配置也是几条固定的参数。

关键点：本地直连时API Key随便填，ChatBox不会真的校验。模型名称必须和Ollama里装的完全一致，填错会提示找不到模型。端口11434是Ollama的默认监听端口，OpenWebUI、Dify这类工具接Ollama时用的也是这个端口，改动过端口的话这里要同步修改。

方案A的缺点是推理速度完全取决于本机显卡，AMD VEGA 56跑7b大概是一秒几个token的节奏，长对话要等一会儿。回复速度不能接受的话，切到方案B用云端算力，本地只负责收发请求。

3.3 方案B：ChatBox接硅基流动API，绕开官方服务波动

官方API入口不稳定时，兼容OpenAI接口的托管平台是务实的选择。正文里推荐的是硅基流动，价格与官方一致，注册登录后左侧菜单栏找到API秘钥，右上角生成再复制，拿到的是以sk开头的密钥字符串。

# 先用curl验证密钥是否有效，不用启动ChatBox curl https://api.siliconflow.cn/v1/models \ -H "Authorization: Bearer <你的API密钥>"

返回模型列表说明密钥有效，报401就是密钥复制错了或者已过期。这个验证动作能帮你把问题定位在密钥本身还是ChatBox配置，省得两边反复试错。

ChatBox里的关键配置如下：

模型名称要带deepseek-ai/这个前缀，这是托管平台的命名规范，不要随手简写成DeepSeek-R1，会报模型不存在。API Host末尾的/v1也不是可有可无的补丁，硅基流动兼容OpenAI接口规范，/v1是标准路径前缀，漏了它ChatBox会一直提示连接失败。

密钥管理有个细节值得注意：API密钥控制台明文展示，复制之后别随手发到群里或贴进公开仓库。使用频率高的话，控制台支持按需生成多个密钥分开绑定不同用途，哪一路泄漏了可以单独吊销，不用整体更换。

3.4 汉化和首次对话验证

ChatBox左下角Settings里把界面语言切成中文，然后新建对话发一条简单测试消息。链路验证的本质是确认四环：请求从ChatBox发出、API Host解析正确、密钥鉴权通过、模型正常返回。

四环都通但回答内容明显不对劲，比如答非所问，多半是模型档位和问题复杂度不匹配。1.5b在复杂逻辑问题上确实会露怯，这不是配置问题，是模型本身的能力边界。先小模型验证链路，再换大模型评价效果，顺序别搞反。

4. Cherry Studio：把私有知识库真正搭起来

4.1 为什么是Cherry Studio：知识库入口比ChatBox更完整

ChatBox解决的是聊天问题，Cherry Studio解决的是带着自己资料聊天的问题。它内置知识库管理，功能上可以替代ChatBox，下载地址在官网，按系统选择对应版本即可。ChatBox的主要定位是通用聊天客户端，知识库需要依托本地管理界面独立搭建，Cherry Studio把导入、切片、检索全部做成内置功能，一个窗口里全搞定。

知识库的底层本质是RAG检索增强生成：先用嵌入模型把文档切片转成向量存入本地索引，提问时把问题也转成向量做相似度检索，再把命中的文本片段连同问题一起交给对话模型生成回答。模型默认不会读你的文档，知识库的作用是替它把相关段落找出来。

如果你只是要个图形聊天界面，ChatBox够用。一旦有内部文档问答的需求，直接上Cherry Studio，省得后面迁移。团队协作场景里，常见操作、产品手册、员工FAQ沉淀成知识库，新人入职不用到处问人，搜一下就有答案。

4.2 接API：对话模型和嵌入模型，一个都不能少

打开Cherry Studio设置界面，选择硅基服务，填入刚才申请好的API密钥，然后添加模型。这里最常见的翻车点：只加了对话模型，没加嵌入模型，导致后面知识库搜索永远为空。

# 对话模型，负责回答用户问题 deepseek-ai/DeepSeek-R1 # 嵌入模型，负责把文档变成可检索的向量 BAAI/bge-m3（或硅基流动平台提供的embedding模型）

对话模型和嵌入模型是两个不同职责的模型。对话模型生成回答，嵌入模型处理文档向量化，不是冗余配置。嵌入模型的选择也会影响检索效果，bge-m3是开源嵌入模型里中文效果均衡的选择，硅基流动这类服务商一般会直接托管。如果知识库以英文文档为主，可以换英文优化过的嵌入模型；中文文档用bge-m3基本不会出错。

加完两个模型后，先回聊天窗口发一条消息验证对话链路通，再做知识库测试，分步确认哪一段出了问题。跨过这一步直接建知识库，导入几百篇文档后发现搜索为空，排查成本会大很多。

4.3 从文档到知识库：导入、切片与检索验证

知识库的搭建顺序是固定的：新建知识库→导入文档→等待向量化完成→搜索验证→在对话中关联。

# 用一份几百字的团队FAQ测试知识库链路 1. 新建知识库，命名为"团队FAQ" 2. 导入一份300字左右的txt文档 3. 等待状态显示向量化完成 4. 在知识库搜索框输入文档中出现过的短语 5. 确认命中后，新建对话并关联该知识库 6. 提问"报销流程是什么"，观察回答是否引用了文档内容

导入前先处理文档格式：纯文本和Markdown兼容性最好，PDF要看具体版本，扫描版PDF必须先做OCR才能被检索到。文档字数少一点，检索更快，问题也容易定位。直接拿几千页的手册测试，出了问题分不清是嵌入模型没配还是切片参数不对。

切片的粒度直接影响检索准确率。FAQ类短问答建议200-300字的切片，一问一答刚好完整存下；技术文档长文章可以放到500字左右，既保留上下文又不会让向量太稀疏。Cherry Studio的默认切片参数多数场景够用，等检索命中率明显下降时再考虑调整。

提示：知识库对话的token消耗比普通对话高，每次提问都要附带检索到的文档片段。个人使用控制导入文档的数量，长文档先拆分再导入，效果好也省token。

关联知识库后正常提问即可，不需要特殊指令。模型收到问题后会先检索再回答，答非所问时回知识库页面确认检索是否正常命中，通常问题出在切片粒度而不是模型本身。

4.4 现状边界：纯本地知识库还没有成熟落地

正文里明确写了"基于ollama实现本地知识库，待完成"，说明纯离线方案仍在探索阶段。目前这套部署的形态是：模型推理走API，文档检索在本地，中间通过接口连接。如果你对数据出网有严格限制，比如金融、医疗这类行业，这套方案还不够，需要额外部署本地嵌入模型和向量数据库，工作量会大不少。

如果文档总量只有几十页，搜索一下就够用，没必要搭知识库。知识库适合文档量大到人工翻不过来、且需要重复问答的场景，比如产品手册、员工FAQ、项目沉淀。小数据集硬上知识库，收益抵不上配置成本。

5. 避坑与排查：本地部署必踩的五个翻车现场

5.1 模型下载到一半失败，或速度慢到怀疑人生

现象：ollama run执行后进度条长时间不动，或下载到某个百分比直接报错中断，重试还是同样位置失败。

原因：Ollama官方模型源在境外，国内网络环境不稳定是常态，跟机器配置无关。大模型动辄几个GB，传输时间越长失败概率越大，中断后残留的临时文件还可能干扰下一次重试。

解决：Ollama本体用官方GitHub release的离线安装包装好，模型文件优先走国内镜像源拉取，或者把已经完整下载的models目录直接放到指定位置。反复重试同一个源成功率不会变高，换镜像源或离线包才是正解。

5.2 ollama -v 提示"不是内部或外部命令"

现象：Ollama安装完成后，打开cmd执行ollama -v报错，终端不识别这个命令。

原因：最常见的是终端没有重启，安装时写入的PATH环境变量没有被当前会话加载。其次是Ollama安装路径含空格或中文，导致PATH里的条目解析异常。

解决：关掉cmd重新开一个新终端，多数情况直接解决。还是不行就手动确认ollama.exe所在目录是否被写入PATH，Windows 11可以在搜索框直接搜"环境变量"进入设置，不用一层层点系统属性。

5.3 设置了OLLAMA_MODELS，模型却依旧装进C盘

现象：环境变量配置完成，重新下载模型后C盘空间照旧减少，新目录里什么都没有。

原因：Ollama进程没有重启，环境变量只对新进程生效。另一个常见原因是变量名拼错，少写了末尾的S，或者变量值路径在系统里不存在，Ollama回退到了默认目录。

解决：任务管理器里结束所有Ollama进程再重新启动，核对变量名是OLLAMA_MODELS而不是OLLAMA_MODEL。用命令确认当前值：

# 查看OLLAMA_MODELS当前值，确认设置已生效 echo %OLLAMA_MODELS%

输出结果应该是你设置的路径，不是空或者默认值。确认路径存在且是纯英文后再重新运行ollama run，下载完成后用ollama list核对模型落盘位置。

5.4 ChatBox报401或model not found

现象：API密钥填入ChatBox，发消息后返回认证失败或模型不存在的错误，换个密钥问题依旧。

原因：复制密钥时带入了多余空格或换行；模型名称简写成了DeepSeek-R1，缺了deepseek-ai/前缀；API Host漏掉了末尾的/v1路径。这三个问题经常同时出现，报错信息会指向其中一环。

解决：回硅基流动控制台重新复制完整密钥，确认无多余字符。模型名按deepseek-ai/DeepSeek-R1格式填写，API Host写完整的https://api.siliconflow.cn/v1。先用curl验证密钥有效，再回ChatBox排查客户端配置，两步分开做，别混在一起猜。

5.5 知识库建好了，搜索却一直返回空

现象：文档导入成功，状态显示正常，但在知识库搜索框输入关键词后没有结果返回。

原因：没有添加嵌入模型，导入的文档根本没有被向量化，检索自然无结果。也可能是文档格式问题，导入了扫描版PDF或加密文档，提取不到有效文字。

解决：回到设置里补充添加嵌入模型，重新导入并等待向量化完成。导入前把PDF转成纯文本或Markdown，扫描版先做OCR。知识库命名不要用特殊字符，某些版本对特殊字符的索引处理不稳定。最后用一份短文档测试链路，能命中再导入完整资料。

6. 进阶：换模型前先做三件事，验证顺序别再错

换模型是本地部署里最常见的后续操作。我的习惯是每次更换模型标签之前，强制走一遍固定流程，先把环境状态看清楚再动手。

# 第一步：看清本机已装模型和磁盘占用 ollama list # 第二步：确认Ollama进程状态 tasklist | findstr ollama # 第三步：用最小的模型验证链路可用 ollama run deepseek-r1:1.5b

这三条命令对应三个检查点：模型清单和大小明确，进程在跑，最小模型能正常输出。链路验证不过，直接换大模型大概率翻车，先解决环境问题再升级模型。磁盘空间也要提前算好，模型文件大小约等于部署后的实际占用，7b预留至少10GB，32b至少30GB。下载过程中磁盘写满会报错，这种报错经常被误判成网络问题，白查半天网络配置。

我的个人教训是，以前换模型时总是直接跑ollama run，网络、磁盘、环境变量几个问题交织在一起，报错信息也分不清是哪一类，反复重试浪费了不少时间。现在强制先跑1.5b小模型，多花两分钟，省下来的全是下载大模型失败重试的时间。这个顺序看起来慢，实际是最高效的路径，希望帮到你。

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