简介面向AI初学者与注重数据安全的用户这份PDF教程系统讲解DeepSeek本地部署全流程帮助读者避开官方服务器繁忙限制防止数据外泄。教程先介绍DeepSeek-Coder、DeepSeek-Chat、DeepSeek-MoE等版本特点及内置提示词库再分析本地部署的必要性并列出适合人群需要保密的程序员、希望蒸馏大模型的企业、练习技术的大学生及求职者。实操部分以Ollama为核心从官网下载exe安装、验证版本、配置OLLAMA_MODELS环境变量到利用软链接将模型安装路径迁移至非C盘全程给出命令示例与执行异常提示如文件已存在、权限不足的解决方法随后结合Chatbox搭建可视化对话界面构建私人本地知识库。资源共1个PDF文件压缩包仅1.99MB内容图文结合步骤清晰既覆盖环境配置细节也提供常见问题排错思路。已有988人学习下载适合需要离线使用AI、保护隐私数据的程序员、企业用户及学生快速上手。1. 为什么说「deepseek本地部署 ollama chatbox」是构建私人知识库最稳的组合把 deepseek 本地部署在笔记本上用 ollama 管理模型和推理再用 chatbox 打开一个顺手的对话窗口最后把私人文档变成可检索的本地知识库——这套组合是当前本地 AI 方案里门槛最低、回报最直接的一条路。不需要额外买服务器不需要把数据交给任何在线平台8GB 内存的机器也能跑出能用的效果。这篇笔记适合三类人担心数据出本机的从业者、想研究大模型但暂时不想买卡的开发者、以及被在线服务限流烦透的普通用户。我会把从装环境到知识库能用的每一步写成能直接复制的命令顺便把那些让人翻车的地方标出来。2. 选对模型和硬件ollama 本地部署 deepseek 前的功课2.1 ollama 做了什么以及量化模型参数为什么重要ollama 本质上是一个本地模型运行时。它负责把模型权重下载到本机启动推理进程暴露一个 HTTP 接口供外部调用。你不需要自己处理 Python 环境、CUDA 版本、显存分配这些琐事一条命令就能把模型跑起来。对于不想折腾底层推理框架的人来说这是最省心的选择。模型选型是本地部署里最关键的一步。同一个 deepseek 模型会有不同参数量版本比如 1.5b、7b、14b、32b这里的“b”指的是模型参数量billion十亿。参数量越大回答质量越高但对内存和显存的要求也越高。ollama 拉取默认是量化版本量化相当于把模型权重的精度从 16 位压缩到 4 位左右体积缩小到原来的四分之一推理速度更快质量损失在可接受范围内。选型逻辑并不复杂先看你的内存总量再看有没有独立显卡。没有显卡时纯 CPU 推理也能跑只是速度慢一些有显卡时模型会优先加载到显存速度明显更快。我一般不建议在 8GB 内存的机器上跑超过 7B 的模型否则系统会频繁交换内存体验反而更差。内存 / 显存推荐模型使用体验8GBdeepseek-r1:1.5b适合简单问答和知识库检索测试速度尚可16GBdeepseek-r1:7b日常对话可用知识库问答质量明显提升32GBdeepseek-r1:14b回答更连贯能处理更复杂的指令64GB 以上deepseek-r1:32b接近云端小模型体验但需要耐心等待推理2.2 安装 ollama 并拉取 deepseek 模型的完整命令ollama 的安装在不同系统上做法不同。常见做法是去它的官网下载对应系统的安装包macOS 和 Windows 都有图形化安装程序Linux 则直接解压安装。安装完成后打开终端输入ollama --version能看到版本号就说明装好了。服务默认不会自动启动需要手动拉起。然后在另一个终端窗口里拉取模型。这里以 7B 量化版为例# 启动 ollama 后台服务默认监听 127.0.0.1:11434 ollama serve # 新开一个终端窗口拉取 deepseek 7B 量化模型 ollama pull deepseek-r1:7b # 拉取完成后直接跑一句对话确认模型能正常响应 ollama run deepseek-r1:7b 你好用一句话介绍你自己参数说明ollama serve是启动服务的前置步骤如果之前已经启动过它会提示端口被占用这时直接用下面的命令即可。ollama pull负责下载权重文件下载完成后模型会缓存在本地之后离线也能用。ollama run会进入一个交互式对话框输入你好能看到模型回复说明链路已经通了。下载过程通常需要几分钟到几十分钟取决于网络状况和模型大小。如果进度条长时间不动不要反复中断重试先停掉换个时段再拉一次。这条命令常见的一个误区是直接ollama run deepseek-r1不带参数量后缀ollama 会默认拉取最新版可能不是你想要的规格建议每次显式写明版本。2.3 验证部署可用用 curl 打一次本地 APIollama run能对话只说明模型本身没问题但后面 chatbox 和知识库服务走的是 HTTP 接口所以还需要确认 API 能正常响应。ollama 默认提供两个接口路径/api/chat是原生接口/v1/chat/completions是兼容 OpenAI 格式的接口。chatbox 会用到后者。curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [{role: user, content: 你好}], stream: false }逻辑说明这条命令向本地 API 发送一个标准 chat 补全请求model字段要和你pull时写的名字完全一致messages是对话历史stream设为 false 表示等完整结果返回而不是流式输出。如果返回的 JSON 里有choices字段就说明 API 层完全正常。到这里本地模型已经能通过接口对外服务了。接下来要做的是给它配一个像样的前端窗口也就是 chatbox。3. 让 deepseek 有个「对话窗口」chatbox 接入本地服务的参数配置3.1 为什么在前端选 chatbox 而不是直接敲命令行命令行模式适合验证不适合日常使用。ollama run进去之后没有历史记录管理、没有多会话隔离、没有图形化展示更没办法对接知识库。chatbox 是一个开源的桌面聊天客户端支持 Windows、macOS、Linux界面清爽配置灵活最关键的是它允许你填入任意的 OpenAI 兼容 API 地址。在本地这套方案里chatbox 扮演的是“显示层”。模型跑在 ollama 里chatbox 负责把用户输入发过去再把模型返回的内容渲染成好看的对话流。它本身不参与推理也不存储知识库所以换任何一款支持自定义 API 地址的客户端都可以但 chatbox 的配置项做得直白对新手最友好。3.2 新建对话配置接口地址、模型名与密钥的正确写法打开 chatbox 的设置页找到“模型提供方”或“API 配置”入口选择“OpenAI API 兼容”类型。这一步有三个字段要填填错任何一个都会导致连接失败。配置项填写内容说明API 地址http://127.0.0.1:11434/v1注意结尾要带/v1不要只写到端口号API 密钥ollama或任意字符串本地服务不校验密钥但不能留空模型名称deepseek-r1:7b必须和ollama pull时的名字完全一致常见的一个坑是 API 地址写成了http://localhost:11434而漏掉/v1chatbox 拼接请求路径时会变成/chat/completionsollama 返回 404。另一个坑是模型名写错比如写成deepseek-r1少了:7b请求会直接报 model not found。保存配置后新建一个对话窗口发送“你好”测试能收到回复就说明配置成功。3.3 影响回答质量的三个配置项温度、上下文长度与流式输出chatbox 的高级设置里通常有几个参数很多新手不动它们结果回答质量忽高忽低。温度temperature控制生成随机性取值范围一般是 0 到 2。做知识库问答时建议调到 0.1 到 0.3数值越低模型越倾向于重复检索到的内容而不是自由发挥日常闲聊可以放到 0.7 左右。上下文长度context length 或 max tokens决定模型一次能看到的文本量。deepseek-r1:7b 的默认上下文长度足够日常使用但你如果给它塞入一大段知识库资料就要把上限调高否则系统提示词被截断回答会变得莫名其妙。流式输出建议打开这样文字逐字出现体感上快很多。以下三个参数是这套方案里最值得反复调节的参数知识库场景推荐值作用temperature0.1 - 0.3越低越忠于资料越高越有创造性top_p0.5 - 0.8控制候选词范围配合温度使用上下文长度4096 以上保证知识片段加提示词能完整容纳到这一步你已经有了一个能聊天的本地模型和一个看得见的对话窗口。但“私人本地知识库”还差最关键的一块让模型能根据你自己的文档回答问题而不是背通用知识。4. 从「聊天」到「知识库」构建本地检索服务的完整链路4.1 知识库的构成文档切分、向量化、检索与上下文注入很多人以为“把文档丢给模型读”就是知识库实际不是。模型有上下文长度限制你不可能把整套文档塞进一次对话里。知识库的标准做法是检索式问答先把文档切成小段每段转成向量一串表示语义的浮点数存入本地用户提问时把问题也转成向量在库中找出语义最接近的几段最后把这几段文本作为背景资料拼接进提示词让模型基于它们回答。这个链路里向量化的质量决定了检索的准确度。ollama 本身不提供向量接口需要拉一个专门的 embedding 模型来做这件事。常用的轻量模型是 all-minilm它体积小CPU 就能跑对中文支持尚可。文档切分讲究策略切太碎语义不完整切太大单块包含噪声。我习惯按 300 字切块、相邻块重叠 50 字这样既保住了段落边界又不会漏掉跨块的关键信息。4.2 写一个 OpenAI 兼容的本地中转服务把 ollama 和知识检索串起来这里有一个关键点chatbox 本身不管理知识库需要有一个中转服务把“检索 对话”合并成一个 OpenAI 兼容接口chatbox 不直接连 ollama而是连这个中转服务。下面是一份可以抄作业的最小实现用 FastAPI 写的启动后相当于一个本地 AI 网关对外暴露/v1/chat/completions。# kb_server.py —— 本地知识库中转服务 # 对外暴露 OpenAI 兼容接口供 chatbox 连接 import os import requests import numpy as np from fastapi import FastAPI from pydantic import BaseModel from typing import List, Dict app FastAPI() DOC_DIR ./kb_docs # 你的知识库文档目录 CHUNK_SIZE 300 # 每个文本块的最大字符数 OVERLAP 50 # 相邻文本块的重叠字符数 TOP_K 3 # 每次检索返回的文本块数量 EMBED_MODEL all-minilm # ollama 中的 embedding 模型 CHAT_MODEL deepseek-r1:7b # 对话模型 OLLAMA_URL http://127.0.0.1:11434 # ---------- 向量库构建 ---------- def embed(text: str): resp requests.post( f{OLLAMA_URL}/api/embed, json{model: EMBED_MODEL, input: text} ) return resp.json()[embeddings][0] def chunk_text(text: str): step CHUNK_SIZE - OVERLAP return [text[i:i CHUNK_SIZE] for i in range(0, len(text), step)] def build_index(): chunks, vecs [], [] for name in os.listdir(DOC_DIR): path os.path.join(DOC_DIR, name) with open(path, encodingutf-8) as f: text f.read() for piece in chunk_text(text): if len(piece.strip()) 20: continue chunks.append(piece) vecs.append(embed(piece)) return chunks, np.array(vecs) CHUNKS, MATRIX build_index() print(f[kb_server] 已加载 {len(CHUNKS)} 个文本块) def search(query: str, k: int TOP_K): q np.array(embed(query)) scores MATRIX q / ( np.linalg.norm(MATRIX, axis1) * np.linalg.norm(q) 1e-9 ) top_idx scores.argsort()[-k:][::-1] return [CHUNKS[i] for i in top_idx] # ---------- OpenAI 兼容接口 ---------- class ChatReq(BaseModel): model: str messages: List[Dict[str, str]] stream: bool False app.post(/v1/chat/completions) def chat(req: ChatReq): # 取用户最新一条消息作为检索 query user_content req.messages[-1][content] hits search(user_content) context \n\n.join(hits) system_prompt ( 你是一个本地知识库问答助手。请只根据下面的资料回答 不要使用资料之外的知识如果资料中确实没有答案 请直接说“知识库中未找到”。\n\n f资料如下\n{context} ) payload { model: CHAT_MODEL, stream: False, messages: [{role: system, content: system_prompt}] req.messages, } resp requests.post(f{OLLAMA_URL}/api/chat, jsonpayload) answer resp.json()[message][content] return { id: chatcmpl-local-1, object: chat.completion, created: 0, model: CHAT_MODEL, choices: [{ index: 0, message: {role: assistant, content: answer}, finish_reason: stop, }], usage: {prompt_tokens: 0, completion_tokens: 0, total_tokens: 0}, }代码逻辑说明build_index在服务启动时扫描kb_docs目录下的所有文本文件逐个切块并计算向量全部保存在内存里。search把用户问题向量化后用余弦相似度找出最接近的 TOP_K 个文本块。chat接口拿到用户消息后先检索再拼系统提示词最后转调 ollama 的/api/chat拿到答案按 OpenAI 格式返回给 chatbox。参数说明CHUNK_SIZE控制切块大小资料偏专业术语时建议降到 200避免单块包含太多无关内容OVERLAP控制重叠量文档里经常出现跨块长句时加大到 80TOP_K控制检索返回块数知识库内容少时设 2 就够了内容丰富可以加到 5太多会让提示词过长且引入噪声。启动前需要准备环境并拉取向量模型# 安装依赖 pip install fastapi uvicorn requests numpy # 拉取轻量 embedding 模型 ollama pull all-minilm # 准备知识库目录把 txt/md 文档放进去 mkdir -p kb_docs # 启动中转服务监听 127.0.0.1:8000 python kb_server.py启动后看到 “已加载 N 个文本块” 就说明索引构建完成。之后可以用 curl 测试一次完整问答请求打到 8000 端口看返回内容是否引用了知识库里的段落。如果答非所问优先检查kb_docs里的文档是否是纯文本格式PDF 和 Word 需要先转成 txt不可直接放进去。4.3 让 chatbox 指向中转服务用提示词约束模型不自由发挥中转服务跑起来后把 chatbox 的 API 地址从http://127.0.0.1:11434/v1改成http://127.0.0.1:8000/v1模型名保持deepseek-r1:7b不变中转服务内部会忽略这个字段真正调用的模型写在代码的CHAT_MODEL里。这样每次对话都会先走本地检索再让模型基于检索结果生成回答。提示词的质量直接影响回答风格代码里已经内置了一版但你可以按需调整。核心约束有三条第一限定回答来源只允许依据提供的资料第二规定无答案时的行为直接承认而不是编造第三如果希望答案更精简可以在提示词里加一句“用不超过 200 字回答”。注意修改提示词后要重启服务才会生效。5. 本地知识库部署的 5 个高频坑现象、原因、解决办法5.1 现象下载 deepseek 模型时进度条卡住不动拉取模型时进度条长时间停在某个百分比重试几次依然如此。原因多半是网络波动导致连接中断ollama 的下载断点续传机制在这种情况下会表现为“看似卡住”。解决按CtrlC中断重新执行ollama pull deepseek-r1:7bollama 会从断点继续而不是重新下载。如果反复断直接改用参数量更小的deepseek-r1:1.5b下载体积小一大半先跑通链路再说。5.2 现象chatbox 能连上但提示“模型不存在”或“not found”配置检查了两遍API 地址和密钥都对但请求就是失败。原因通常是模型名不匹配。ollama pull时写的名字和 chatbox 里填的名字必须逐字符一致注意冒号后面的版本标签。解决在终端执行ollama list查看本机已安装模型的完整名称把这个名称原样复制到 chatbox 的模型字段里不要手动敲。5.3 现象模型回答时大量复述检索片段读起来像拼贴知识库里的内容被原封不动搬进回答甚至出现“根据资料如下”这样的残留字样。原因是提示词里没有要求“用自己的话组织”且温度设得过高或过低都会放大这个问题。解决温度调到 0.2 左右在系统提示词中追加一句“请基于资料内容重新组织语言不要直接复制原文”。如果仍然复述检查TOP_K是否过大——返回块数越多模型越容易整段照抄。5.4 现象检索结果答非所问问 A 答 B问题本身没问题但检索出来的文本块与问题无关。两个主要原因一是文档切块太大单块包含多个主题向量相似度被无关内容拉低二是 embedding 模型对中文支持有限all-minilm 的语义理解能力一般碰到专业术语容易跑偏。解决先把CHUNK_SIZE降到 200OVERLAP升到 60重新启动服务。效果不明显就换一个中文表现更好的 embedding 模型在 ollama 里搜一下相关模型替换EMBED_MODEL字段。5.5 现象CPU 推理慢到没法用一句话等两三分钟模型选得太大或者 ollama 没有充分利用 CPU 资源。解决执行ollama ps查看当前加载的模型大小如果模型体积接近内存总量就换更小的量化版本比如从 14b 换到 7b。另外在启动 ollama 服务前可以通过环境变量调整线程数让 CPU 满载推理。还有一个被低估的因素kb_docs里文件过多时启动阶段向量化会耗时很长看起来像卡死实际是在建索引日志里会打印进度。6. 用一组「召回测试」验证知识库质量再把本地 deepseek 服务交给别的应用知识库搭好之后不要急着正式用。我习惯先准备 10 到 15 个从真实文档中提炼的问题一个个去问统计其中有多少个回答能对应到正确的资料段。这个做法叫召回测试能快速暴露分块和检索参数的明显问题。某开发者把公司内部手册拆成 200 段测下来发现技术术语类问题命中率不到五成把 embedding 模型换掉后提升到八成以上。你不需要这么正式的评估流程但至少准备三五个问题跑一遍重点看“明明资料里有却没有被检索到”的情况。召回测试通过后这套服务就不只属于 chatbox 了。任何一个会发 HTTP 请求的工具都可以调你的本地知识库因为中转服务暴露的是标准 OpenAI 接口。用 curl 直接调也可以curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [ {role: user, content: 根据本地知识库产品的退货政策是什么} ], stream: false }所谓“开放给别的应用”其实就是换一个调用方脚本、定时任务、内部工具都能用同一个接口。唯一要注意的是并发ollama 默认同时只能处理一个推理请求多人同时用会出现排队。遇到这种情况可以在启动 ollama 前设置并行参数让多个请求共享显存并发推理但要注意这会增加单次响应时间。最后说一个我养成的习惯每次改完分块参数或提示词都重启一次服务并用同一批测试问题重新跑一遍记录命中率。本地方案的调试成本低改一个参数几十秒就能看到效果多试几轮就知道自己的文档适合什么配置。知识库这种东西没有一套万能参数只有不断根据实际文档调整出来的那一套。希望这篇笔记能帮你少走一点弯路把 deepseek 本地部署这条路走顺早日拥有一套完全属于自己、不依赖外部服务的知识系统。本文还有配套的精品资源点击获取