企业官网建设流程全解析

1. 为什么要在本地跑DeepSeek：从数据主权到响应速度的权衡

很多人第一次听到“本地部署大模型”会觉得这是极客的玩具，实际用起来才发现，它解决的是几个非常具体的痛点。我在过去一年里帮三四个团队搭过本地知识库，最核心的驱动力从来不是“技术炫技”，而是数据不出内网和响应延迟可控这两件事。

先说数据。你把一份合同、一份内部技术文档丢给在线大模型，本质上是在把敏感信息交给第三方。对于法务、医疗、金融这类行业，这几乎是不可接受的。本地部署之后，所有推理都在你自己的机器上完成，数据从磁盘到显存再到输出，全程不经过任何外部网络。这一点在合规审查时是硬性门槛。

再说延迟。在线API的响应时间受网络波动影响很大，尤其是长文档的RAG（检索增强生成）场景，一次问答可能要调用好几次模型。本地部署之后，首次加载模型会慢一些，但后续的推理延迟基本稳定在几百毫秒到几秒之间，不会因为网络抖动而突然卡住。

那为什么选DeepSeek而不是别的模型？我实测下来，DeepSeek系列在中文理解和代码生成上的表现，同参数量级里属于第一梯队。尤其是它的推理模型，在处理需要多步逻辑的问题时，输出质量明显比同尺寸的通用模型更稳。而Ollama是目前把“下载模型、加载模型、暴露API”这三件事做得最顺手的工具，没有之一。它把模型权重、推理引擎、服务接口打包成一个命令行工具，你不需要懂CUDA、不需要配环境变量，一条命令就能跑起来。

这套组合的适用人群其实很广：个人开发者想搭一个私有的代码助手，小团队想做一个内部文档问答系统，甚至只是想在断网环境下有个能用的AI，都可以照着下面的流程走。我接下来会从环境准备开始，把每一步的意图和坑都讲清楚，最后重点拆解三个最常见的报错。

2. 环境准备：Ollama安装与模型拉取的完整链路

2.1 安装Ollama：别急着敲命令，先看磁盘和显卡

Ollama的安装本身很简单，但安装之前的准备工作决定了你后面会不会遇到“模型加载失败”或者“推理速度慢到无法忍受”的问题。我见过太多人直接下载安装包，结果发现C盘爆了，或者模型跑在CPU上慢得像蜗牛。

磁盘空间是第一道门槛。一个7B参数的模型，量化后大约4到5GB，加上Ollama本身的缓存和日志，建议至少预留20GB的可用空间。如果你打算跑14B或32B的模型，空间要翻倍甚至更多。Windows用户特别注意，Ollama默认把模型存在C:\Users\你的用户名\.ollama\models，这个路径可以改，但要在安装前通过环境变量OLLAMA_MODELS指定，装完再改会麻烦很多。

显卡是第二道门槛。Ollama会自动检测NVIDIA显卡并尝试用GPU推理，但需要你的驱动版本足够新。我遇到过驱动太旧导致Ollama回退到CPU的情况，推理速度从每秒几十个token掉到每秒两三个token，体验完全不一样。检查方法很简单，在命令行里跑nvidia-smi，能看到显卡型号和驱动版本就行。AMD显卡的支持要弱一些，部分型号需要额外配置，这里不展开。

安装过程本身没什么好说的，官网下载对应系统的安装包，双击下一步。Linux用户可以用一行脚本搞定：

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

安装完成后，在终端输入ollama --version，能输出版本号就说明装好了。这时候Ollama的服务已经在后台跑起来了，默认监听11434端口。

2.2 拉取DeepSeek模型：模型标签里的门道

Ollama的模型库里有多个DeepSeek的版本，标签不同，参数量和量化方式都不同。直接跑ollama run deepseek会拉取默认标签，但默认标签不一定适合你的机器。我建议先想清楚两件事：你的显存有多大，你的任务对质量要求有多高。

显存和模型大小的对应关系，我整理了一个粗略的参考表：

拉取模型的命令是ollama pull deepseek-r1:7b这样的格式。这里有个细节：pull只下载不运行，run是下载完直接进入交互。如果你只是想先把模型准备好，用pull更合适。下载速度取决于你的网络，国内用户可能会遇到下载慢的问题，这个后面在报错部分会专门讲。

模型拉下来之后，用ollama list可以看到本地已有的模型列表，包括名称、大小和修改时间。第一次加载模型到显存会花几秒到几十秒，之后再次调用会快很多，因为Ollama会保持模型在内存里一段时间。

2.3 验证服务：用curl和Python各测一次

装完不验证，等于没装。我习惯用两种方式确认服务正常。第一种是命令行直接调API：

curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用一句话解释什么是RAG", "stream": false }'

如果返回一段JSON，里面response字段有内容，说明服务通了。第二种是用Python脚本，因为后面搭知识库大概率要用Python调：

import requests response = requests.post( "http://localhost:11434/api/generate", json={ "model": "deepseek-r1:7b", "prompt": "用一句话解释什么是RAG", "stream": False } ) print(response.json()["response"])

这两种方式都跑通，说明Ollama和DeepSeek模型都就绪了。注意stream参数，设为False会等模型生成完一次性返回，设为True会流式输出。知识库场景下通常用流式，用户体验更好。

3. 知识库搭建：从文档切片到检索增强的落地细节

3.1 知识库的核心逻辑：为什么不能直接把文档丢给模型

很多人以为本地知识库就是“把PDF传给模型，让它读”。这个理解偏差会导致两个问题：一是模型上下文窗口有限，一本几百页的手册根本塞不进去；二是即使塞进去了，模型对长文本中间部分的注意力会衰减，回答质量反而下降。

RAG的思路是把这件事拆成两步：先检索，再生成。具体来说，你的文档被切成一个个小片段，每个片段通过嵌入模型转成一个向量，存进向量数据库。用户提问时，问题也被转成向量，在数据库里找最相似的几个片段，把这些片段和问题一起拼成提示词，再交给DeepSeek生成答案。这样模型只需要处理几个相关片段，而不是整本手册。

这个流程里，切片策略是最容易被忽视但影响最大的环节。切得太碎，片段缺乏上下文，检索出来的东西答非所问；切得太粗，一个片段里混了好几个主题，模型容易被无关信息干扰。我的经验是，中文文档按300到500字切片比较合适，同时保留10%到20%的重叠，避免关键信息刚好被切断。

3.2 嵌入模型的选择：别用生成模型兼职做嵌入

嵌入模型和生成模型是两回事。DeepSeek是生成模型，负责“写答案”；嵌入模型负责“找资料”。用生成模型去做嵌入，效果通常不好，而且速度慢。Ollama支持专门的嵌入模型，比如nomic-embed-text，体积小、速度快，中文效果也够用。

拉取嵌入模型：

ollama pull nomic-embed-text

然后在代码里调用嵌入接口：

def get_embedding(text): response = requests.post( "http://localhost:11434/api/embeddings", json={ "model": "nomic-embed-text", "prompt": text } ) return response.json()["embedding"]

这个向量维度通常是768或1024，存进向量数据库后，用余弦相似度做检索。向量数据库的选择很多，轻量级场景用Chroma或FAISS就够了，不需要上Milvus这种重型方案。Chroma的优势是自带持久化，几行代码就能跑起来。

3.3 检索与生成的拼接：提示词模板决定回答质量

检索出相关片段后，怎么把它们和问题拼成提示词，直接决定了回答的质量。我见过最粗糙的做法是直接把片段和问题用换行拼在一起，结果模型分不清哪些是资料、哪些是问题。好的提示词模板应该明确区分角色和任务：

prompt_template = """你是一个知识库助手。请根据以下参考资料回答用户问题。 如果参考资料中没有相关信息，请直接说"资料中没有提到"，不要编造。 参考资料： {context} 用户问题：{question} 请用简洁的中文回答："""

这个模板里，“不要编造”这句话很关键。本地模型在缺乏约束时，容易把检索到的无关片段强行拼凑成看似合理的答案。加上这句约束后，模型在资料不足时会更倾向于承认不知道，而不是胡编。

拼接时还要注意片段数量。检索出太多片段会挤占上下文窗口，而且引入噪声。我的经验是取相似度最高的3到5个片段，每个片段控制在500字以内。如果问题比较复杂，可以适当增加到8个，但再多就适得其反了。

4. 三个高频报错的完整排查链路

4.1 报错一：模型加载失败，提示显存不足

这个报错通常长这样：Error: model requires more system memory than is available。第一次遇到会以为是内存不够，其实大概率是显存不够，Ollama回退到内存又发现内存也不够。

排查的第一步是确认模型实际需要多少资源。用ollama show deepseek-r1:7b可以看到模型的参数规模、量化方式和上下文长度。7B的Q4模型大约需要5GB显存，如果你同时开着浏览器、IDE和其他应用，8GB显卡可能就不够了。

第二步是检查当前显存占用。Windows用任务管理器看“专用GPU内存”，Linux用nvidia-smi。如果显存已经被其他进程占了大半，要么关掉那些进程，要么换更小的模型。

第三步是确认Ollama是否真的在用GPU。在Ollama的日志里搜索offload关键字，如果看到offloading 0 layers to GPU，说明模型完全跑在CPU上。这种情况要么是驱动问题，要么是Ollama版本太旧不认你的显卡。更新驱动和Ollama到最新版通常能解决。

如果硬件确实不够，最实际的方案是换更小的量化版本。比如从deepseek-r1:7b换成deepseek-r1:1.5b，资源需求直接降到十分之一。质量会下降，但至少能跑起来。另一个方案是调整Ollama的并行数，用OLLAMA_NUM_PARALLEL=1环境变量限制同时处理的请求数，减少显存峰值。

4.2 报错二：下载模型卡住或速度极慢

ollama pull卡在某个百分比不动，或者速度只有几十KB每秒，这是国内用户最常遇到的问题。原因不复杂，模型文件托管在境外，网络链路不稳定。

最直接的缓解方式是配置镜像源。Ollama支持通过OLLAMA_HOST环境变量指定镜像地址，但更通用的做法是在系统层面配置代理。这里要注意，代理配置只影响下载过程，不影响本地推理，推理全程还是在你自己机器上。

如果镜像源也不稳定，可以手动下载模型文件再导入。Ollama的模型文件是GGUF格式，你可以在其他渠道找到对应的GGUF文件，然后用Modelfile导入：

# 创建一个Modelfile echo 'FROM ./deepseek-r1-7b-q4.gguf' > Modelfile # 导入模型 ollama create deepseek-local -f Modelfile

这个方式的优势是下载可以断点续传，用下载工具比ollama pull更可控。缺点是你要自己确认GGUF文件的来源和完整性，下错了文件会导致模型行为异常。

还有一个容易被忽视的点：磁盘写入速度。模型下载完成后要解压和校验，如果磁盘是机械硬盘或者剩余空间不足，这个过程会非常慢，看起来像是卡住了。确保目标磁盘有足够空间，并且不是满载状态。

4.3 报错三：API调用返回500，日志显示llama-server进程异常

这个报错信息比较模糊，500 internal server error只是表象，真正的原因在Ollama的日志里。日志位置因系统而异，Linux在journalctl -u ollama，Windows在%LOCALAPPDATA%\Ollama\下面。

我遇到过的触发原因主要有三类。第一类是模型文件损坏，通常是下载过程中断导致的。表现是加载模型时直接崩溃，日志里有failed to load model之类的字样。解决办法是删掉模型重新拉：ollama rm deepseek-r1:7b然后重新pull。

第二类是端口冲突。Ollama默认用11434端口，如果这个端口被其他程序占了，服务启动会失败。用netstat -ano | findstr 11434（Windows）或lsof -i:11434（Linux）检查端口占用，然后要么关掉占用程序，要么改Ollama的端口：OLLAMA_HOST=0.0.0.0:11435 ollama serve。

第三类是上下文长度超限。当你传入的提示词加上模型要生成的token数超过了模型的最大上下文，llama-server会直接报错。DeepSeek的默认上下文通常是4096或8192，知识库场景下拼接多个片段很容易超。解决办法是在API调用时显式设置num_ctx参数：

response = requests.post( "http://localhost:11434/api/generate", json={ "model": "deepseek-r1:7b", "prompt": prompt, "num_ctx": 8192, "stream": False } )

注意num_ctx调大会增加显存占用，要在显存允许的范围内调整。如果显存不够，宁可减少检索片段数量，也不要硬撑大上下文。

排查这类报错的通用思路是：先看日志定位到具体是加载阶段还是推理阶段出错，加载阶段出错多半是文件或资源问题，推理阶段出错多半是参数或输入问题。把日志里的关键错误信息拿去搜索，通常能找到具体的解决方案。

5. 让知识库真正好用的几个调优经验

5.1 切片重叠不是越多越好

前面提到切片要保留重叠，但重叠比例需要控制。我试过20%的重叠，结果检索时经常返回两个高度相似的片段，浪费了上下文窗口。后来降到10%左右，检索结果的多样性明显改善。具体操作上，如果按500字切片，重叠50字就够了，不需要更多。

另外，切片时尽量按语义边界切，而不是机械地按字数。比如按段落切，或者按Markdown的标题层级切。这样每个片段内部的主题更集中，检索时的相关性更高。LangChain的RecursiveCharacterTextSplitter支持按分隔符优先级切分，中文场景下把\n\n和\n放在分隔符列表前面，效果比纯按字数切好很多。

5.2 检索结果要重排序

向量检索返回的Top-K片段，相似度分数高不代表真的相关。我遇到过很多次，某个片段因为包含问题里的关键词而被检索出来，但内容其实答非所问。解决办法是加一层重排序，用一个专门的交叉编码器模型对检索结果重新打分。

Ollama本身不直接提供重排序模型，但可以用嵌入模型做粗排，再用一个小的生成模型做精排。具体做法是把问题和每个候选片段拼在一起，让模型判断“这个片段是否包含回答问题的信息”，按判断结果排序。这个步骤会增加一些延迟，但对回答质量的提升很明显，尤其是知识库文档主题比较分散的时候。

5.3 给模型加“不知道”的出口

本地模型最大的风险是幻觉。在线API通常有更严格的安全对齐，本地模型在这方面的约束弱一些。除了在提示词里明确要求“不知道就说不知道”，还可以在检索阶段加一个相似度阈值。如果最高相似度低于某个值，直接返回“没有找到相关资料”，不进入生成阶段。

这个阈值需要根据你的嵌入模型和文档特点来调。我的经验是先用一批测试问题跑一遍，观察正确回答和错误回答的相似度分布，找一个能区分两者的临界值。通常余弦相似度在0.7以上比较可靠，低于0.5的基本可以判定为不相关。这个值不是绝对的，不同嵌入模型的分数分布不一样，需要自己标定。

5.4 定期清理和更新向量库

知识库不是搭完就一劳永逸的。文档更新后，对应的向量也要更新，否则检索到的还是旧内容。Chroma支持按ID删除和更新，但批量更新时要注意一致性，避免出现新旧向量混杂的情况。我的做法是给每个文档分配一个版本号，更新时先删掉旧版本的所有片段，再插入新片段，这样不会出现半新半旧的状态。

另外，向量库的体积会随着文档增加而膨胀。如果文档量很大，检索速度会下降。定期做一次全量重建，把不再需要的文档清理掉，能保持检索性能稳定。重建的时机可以选在文档变动较大的时候，比如一个项目结束后。

6. 关于硬件和模型选择的个人体会

跑本地大模型这件事，硬件决定了你能玩多大的模型，但软件调优决定了你能玩多好。我见过用16GB显存跑7B模型效果还不如别人用8GB显存跑同样模型的情况，差别就在切片策略、提示词模板和检索参数上。

如果你刚开始尝试，我的建议是从最小的模型开始，先把整个流程跑通，再逐步换大模型。deepseek-r1:1.5b虽然质量一般，但加载快、显存占用低，适合用来验证代码逻辑。流程跑通后，换成7B或14B，感受一下质量提升，再决定要不要上更大的模型。

硬件方面，如果只是个人使用，一张12GB显存的显卡加上32GB内存，跑14B的Q4模型做知识库问答已经够用了。不需要追求顶级显卡，瓶颈往往在检索和拼接环节，而不是模型推理本身。真正影响体验的是检索的准确率和提示词的质量，这两件事跟硬件无关，跟你的调优投入有关。

最后分享一个我踩过的坑：不要同时跑多个模型。Ollama默认会保持模型在显存里一段时间，如果你先跑了DeepSeek又去跑嵌入模型，两个模型会争抢显存，导致其中一个被挤到内存里，速度骤降。解决办法是设置OLLAMA_MAX_LOADED_MODELS=1，让Ollama一次只加载一个模型，用完再换。切换模型会有几秒的加载时间，但比两个模型互相拖累要好得多。