★ FEATURED ARTICLE 简介《DeepSeek应用手册》是一份面向深度学习爱好者、微调技术研究者及AI应用开发者的操作型资料聚焦DeepSeek大模型在日常使用与私有化部署中的实际落地。手册内容覆盖多模型协同R1与V3分工、文件上传与联网搜索技巧、万能提问模板并详解通过Cherry Studio、Ollama与Chatbox接入API或本地私有数据集的流程同时对max_batch_size、max_seq_len、hidden_size等关键参数给出通俗解释并说明蒸馏技术如何将大模型能力迁移至轻量模型既适合零基础用户快速掌握使用技巧也能帮助进阶用户优化本地部署参数与性能。资源包内为1个docx文档压缩包大小207KB文件体量轻量便于下载后直接阅读或按章节检索。目前已有285人学习内容由作者从实战角度提炼整理尤其适合希望将DeepSeek融入写作、任务拆解、私有知识库构建等场景的读者参考。1. 装一套能跑的 DeepSeek 环境先分清三条路再动手第一次部署 DeepSeek 时我栽得挺结实照着教程装好 Ollama兴致勃勃敲下ollama run deepseek-r1:32b然后屏幕上一行红字——显存不足。整份 deepseek 应用手册翻完才发现问题不在命令而在参数量和显存需求的关系被我搞混了。1.5B 是 15 亿参数32B 直接翻到 320 亿这还没算推理时 KV Cache 占掉的那块显存。对多数人来说本地跑 DeepSeek 不是“装个软件”就完事而是路径选择想轻量跑走 Ollama 全家桶改配置就能玩想带私有数据走 Cherry Studio 或 API 做知识库想到微调和满血部署就得碰 LoRA 和 KTransformers 这类重装备。这篇按我的实操顺序拆开讲适合正卡在“装什么、怎么配、坏了怎么救”的开发者。2. 本地跑起来Ollama 部署与 Chatbox 接入2.1 先选模型尺寸1.5B 到 32B 怎么定Ollama 是本地跑 DeepSeek 最省事的入口装上之后一条ollama run就能把模型拉下来。但我见过太多人栽在第一步不看显存直接拉最大的模型然后看着 OOM 报错发呆。DeepSeek-R1 后面跟的参数 XX B意思就是 XX 乘上 10 亿个参数1.5B 是 15 亿参数32B 是 320 亿参数。参数越大能力越强显存和内存占用也直线上升。模型尺寸参数量常见部署方式所需显存参考deepseek-r1:1.5b15 亿Ollama / 普通笔记本2 GB 左右deepseek-r1:32b320 亿Ollama / 工作站20 GB 以上DeepSeek-R1 满血版6710 亿KTransformers 等框架24 GB 显卡可跑配合 CPU 卸载我一般这样选手头只有 8 GB 显存的卡老老实实用 1.5B适合跑通流程有 24 GB 的 4090可以上 32B流畅度和智能程度平衡得比较好。满血 671B 单卡 24 GB 能跑能但要走 KTransformers 这类 CPU 卸载方案后面第五章专门讲。选尺寸这件事本质是“先定硬件预算再挑模型”反过来选必然翻车。2.2 安装 Ollama 并下载 DeepSeek-R1Linux 服务器上我习惯用官方安装脚本一步到位# Linux / macOS 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 下载并运行 DeepSeek-R1 32B 模型 ollama run deepseek-r1:32bWindows 用户直接去官网下载OllamaSetup.exe双击安装完CMD 里同样能跑ollama run deepseek-r1:32b。这条命令的逻辑是先检查本地有没有 deepseek-r1:32b 这个模型没有就自动从模型库拉取拉完直接进入交互式对话界面。我第一次跑的时候没注意终端里那一大串下载进度还以为是卡住了其实是 32B 模型十几个 GB 在慢慢下。模型默认存在用户目录下Linux 是/root/.ollama/modelsWindows 是C:\Users\用户名\.ollama\models。这个路径后面配知识库、做微调经常要手动指定建议提前记住。下载速度一般取决于网络国内环境偶尔会断断了重跑ollama run会接着断点续传不用清缓存重来。2.3 用 Chatbox 接入本地模型Ollama 自带的终端交互够用但很多人想要个能保存会话、有界面的工具我用的搭配是 Ollama 当推理引擎Chatbox 当前端。安装 Chatbox 之后进入设置界面模型提供方选“Ollama API”API 地址填http://127.0.0.1:11434模型选deepseek-r1:32b保存就能聊天。关键点是不要填错地址。本地 Ollama 服务默认监听 11434 端口地址写成http://localhost:11434或http://127.0.0.1:11434都行但不要随手填成https本地服务走的是明文 HTTP。Chatbox 里填完地址可以先点一下“检查连接”能读到模型列表说明通了。连不上时先回终端确认 Ollama 服务活着再查端口有没有被占用。Chatbox 的设置页里还能调一组参数第一次接触的人容易懵。核心几个是max_batch_size控制模型一次能处理的最大样本数默认就行max_seq_len定义最长输入序列长度填太小长文档会被截断填太大爆内存temperature控制随机性写代码我习惯调到 0.2 以下做头脑风暴调到 0.8 以上。这些参数属于“调坏了大不了重置”的类型别怕大胆试。3. 私有数据集接入Cherry Studio 与 API 两条路3.1 Cherry Studio 安装与 API Key 导入本地跑模型解决的是“模型能力”问题但如果想让它回答你手里的 Excel、Word、TXT 这些私有资料就得走知识库路线。我用的工具是 Cherry Studio它对非技术用户比较友好不用写代码界面操作就能建知识库。安装 Cherry Studio 后第一步是导入 API Key。官方 Key 和第三方中转 Key 都能用区别在于官方稳定但额度有限第三方便宜但得挑口碑好的。导入位置在设置里的“模型服务”一栏把 Key 粘进去再选择你要用的模型DeepSeek 的 API 网关会自动识别模型名。这里有个容易踩的坑有些第三方服务商把模型名改成别名比如deepseek-r1-pro这种导入后选不到得去服务商的文档里查真实的模型标识。3.2 用本地文件构建知识库为什么尽量别用 PDF知识库支持文本文档、PDF、Excel 表格和图片。但我自己的经验是能用 Word 和 Excel就别用 PDF。PDF 在知识库场景里是个坑货。扫描版 PDF 本质是图片没有文字层解析出来全是乱码文字版 PDF 也常因为分栏、页眉页脚被切得七零八落。我踩过一次把一份 PDF 合同丢进知识库问“违约金比例是多少”模型答了个风马牛不相及的条款后来排查发现是 PDF 解析时把两页内容拼在了一起。Excel 和 Word 是结构化文本切分干净检索准确率高得多。如果手头只有 PDF建议先用工具转成 Word 或 TXT 再进知识库。知识库的构建逻辑不算复杂文件上传后Cherry Studio 会做文本切分和向量化生成一个个“片段”存起来。使用时勾选“知识库”开关模型先检索相关片段再结合片段内容回答。这里要提醒一句知识库不是万能的它做的是检索增强生成如果文档本身就没写清楚模型也编不出来。所以提问时尽量带上上下文语境“根据《XX合同》第 3 条违约金怎么计算”而不是干巴巴问“违约金多少”。3.3 远程接入把 Ollama 服务地址改到服务器如果你有一台远程服务器在跑模型想在本地 Chatbox 里用操作也不复杂。核心思路就一句话让 Ollama 监听所有网卡然后把本地 Chatbox 的服务地址指向服务器 IP。# 在远程服务器上设置监听地址 OLLAMA_HOST0.0.0.0:11434 ollama serve # 如果重启后失效写入服务配置 # Linux systemd 服务编辑 /etc/systemd/system/ollama.service # 在 [Service] 段加入 EnvironmentOLLAMA_HOST0.0.0.0:11434 sudo systemctl daemon-reload sudo systemctl restart ollama远程服务器上跑完这两步本地 Chatbox 里把 API 地址从127.0.0.1:11434改成http://服务器IP:11434模型选同一个名字就能远程调用了。注意这不是什么代理纯粹是把 Ollama 的监听范围从只允许本机访问改成允许局域网访问。有两件事必须做一是确认服务器防火墙放行了 11434 端口二是如果服务器有安全组策略也需要去控制台放行。否则本地会一直卡在“连接超时”我当初排查了两个小时最后才发现是安全组没放行。4. 避坑指南部署过程中最常见的五个坑4.1 模型秒退或启动即失败现象运行ollama run deepseek-r1:32b模型加载到一半直接退出或者刚进入对话界面就崩溃。 原因显存不足是主因其次是模型文件损坏。 解决先看报错有没有OOM或CUDA out of memory。有就换小模型比如ollama run deepseek-r1:1.5b。如果报错是“文件不完整”删掉模型重新拉一遍ollama rm deepseek-r1:32b后再ollama run。还有个常见情况是 Windows 上显存充足但共享内存不够去核显设置里多分点共享显存。4.2 显存占用比预期高很多现象32B 模型官方说 20 GB 显存能跑实际一启动直接吃满 24 GB还报了 OOM。 原因上下文长度默认值太大。Ollama 默认给 2048 tokens 的上下文但很多前端会把它改到 4096 或 8192KV Cache 随上下文长度线性增长显存自然水涨船高。 解决在 Ollama 里设置OLLAMA_CONTEXT_LENGTH2048同时把前端设置里的max_seq_len调小。跑长文档时再临时调大不跑就调回来。从那以后我跑 32B 都会先设 2048 验证能通再逐步加大。4.3 Chatbox 提示连接失败现象设置填了http://127.0.0.1:11434点保存后提示“连接失败”或“无法获取模型列表”。 原因八成是端口写错或 Ollama 没在运行少数情况是系统代理把本地流量劫持走了。 解决先ollama list确认服务活着再netstat -ano | grep 11434看端口监听状态。如果开了代理检查代理设置里有没有把127.0.0.1排除在外很多代理工具会默认拦截本地请求导致连接失败。4.4 知识库问答答非所问现象勾选了知识库问文档相关内容模型给的答案和文档对不上。 原因要么是 PDF 解析质量太差导致切分碎片化要么是提问时没指定文档范围。 解决把 PDF 优先转成文本再导入知识库。提问时把范围说清楚比如“根据《产品需求文档》中关于登录模块的描述列出主要功能点”让检索阶段能精准命中片段。还有一个细节知识库多个文件混合时问题和答案之间容易被模型“二次加工”带偏遇到答非所问先确认勾选的是不是目标知识库。4.5 Windows 下模型路径和环境变量设置后不生效现象设置了OLLAMA_MODELS指向 D 盘重启后发现模型还是下载到 C 盘。 原因Windows 的 Ollama 以服务方式运行只改用户环境变量没用服务读取的是系统环境变量或服务配置。 解决在系统环境变量里新增OLLAMA_MODELS设置完到“服务”里重启 Ollama 服务不是简单关掉终端窗口。验证方式ollama list确认路径已变更。这个坑我反复踩过后来总结出一句话Windows 上凡是 Ollama 配置不生效先去重启服务别怀疑配置语法。5. 进阶操作LoRA 微调与低成本部署满血 R15.1 在 Linux 上准备 LoRA 微调环境到了进阶这一步部署目标从“能跑”变成“会适应你的业务”。微调不是训练大模型它是在预训练模型基础上做少量参数适配。LoRA 的核心思路是只更新低秩矩阵不碰原始权重好处是显存占用低、训练快、存储占用小。我在 Linux 服务器上做 LoRA 微调参考的是某开源微调指南项目里的 Qlora 方案整体流程不复杂但对环境整洁度要求高。先准备一个干净环境# 创建独立 conda 环境避免污染系统 Python conda create -n llama-factory python3.10 -y conda activate llama-factory pip install llama-factory transformers datasets accelerate # 准备数据集JSON 格式alpaca 风格数据集格式是关键。LoRA 微调的数据集一般是 JSON每条包含instruction、input、output三个字段。instruction是任务描述input是输入材料output是期望输出。我从业务里抽了 200 条真实问答做数据集微调出来的效果比通用模型贴近业务得多。注意数据质量和多样性要兼顾全是同一模板的数据模型会学成复读机。数据集准备这一块网上的教程很细但多数默认你已经懂 JSON 格式规范我见过不少初学者栽在少一个逗号导致解析失败上建议写完数据先python -m json.tool验证一遍。5.2 用 KTransformers 跑满血 DeepSeek-R1如果目标是跑满血版 DeepSeek-R1也就是 671B 参数那版常规思路得一堆 A100显存算下来天价。但有了 KTransformers 框架单张 4090 24 GB 也能跑核心原理是“混合推理”把计算量最大的 FFN 层放到 CPU 上跑只有 attention 层留在显卡。这样显存压力大减代价是 CPU 和内存要够强。参考配置是双路 Xeon 64 核 480 GB DDR5 内存 4090 24 GB。这个配置的合理之处在于FFN 卸载到 CPU 后CPU 核心数和内存带宽直接决定推理速度。我用过 32 核的机器跑速度慢到没法用换 64 核后基本能稳定在可接受范围。部署步骤大致是拉取 KTransformers 源码下载量化好的模型权重然后启动服务。# 以 4bits 量化权重为例启动推理服务 python -m ktransformers.local_chat --model_path ./DeepSeek-R1-Q4_K_M --gguf_path ./DeepSeek-R1-Q4_K_M.gguf启动参数里--model_path指向解压后的模型目录--gguf_path指向量化后的权重文件。启动日志里会显示“放置到 CPU 的层数”和“放置到 GPU 的层数”这个信息很重要如果 FFN 层没有识别到 CPU实际上还是在 GPU 上跑24 GB 会瞬间打满然后崩溃。第一次启动时间会比较长因为需要做权重转换和缓存预热不是卡死。5.3 微调后的 LoRA 权重和部署怎么衔接微调完的 LoRA 权重一般是一个几百 MB 的小文件使用时要加载回基座模型。Chatbox 这类前端工具默认不直接加载 LoRA 权重我一般有两种处理方式一是用ollama create把基座模型和 LoRA 合并生成一个新模型二是通过后端推理脚本加载 LoRA 权重再暴露 API。前者适合快速验证后者适合正式接入应用。# 方式一用 Modelfile 合并 LoRA 权重ollama create FROM deepseek-r1:7b ADAPTER ./lora-output/adapter_model.bin合并后新模型会出现在ollama list里和普通模型一样用。方式一的好处是简单坏处是每次微调迭代都要重新合并方式二更灵活但需要写 Python 加载逻辑适合本身就有后端服务的场景。微调这一步没有捷径核心可靠建议只有一个每次微调前备份基座权重LoRA 合并前验证数据集质量否则调出来的模型会比原版还难用。6. 验证跑通模型是不是真能用几项检查一做便知装完一套环境最怕的就是界面能聊天但真正用起来全是问题。我给自己定了一套验证清单每次部署完强制走一遍几十秒就能确认环境是不是真的健康。第一项是冷启动时间。模型加载完第一次输入文字到开始吐出第一个字的时间我一般记录这个值。Ollama 加载 32B 模型在 24 GB 显存的机器上冷启动通常在 10 秒左右如果超过 30 秒多半是磁盘读取慢或者显存被别的进程占了。验证命令先跑一次ollama run deepseek-r1:32b 你好数一下从回车到出字的秒数。第二项是推理质量。随便找一道需要推理的数学题丢进去比如“一根绳子剪成两段第一段比第二段长 20%两段一共长 90 米每段各长多少米”然后观察模型的思维链输出。DeepSeek-R1 系列会把完整的推理过程展示出来如果看到它先定义变量再逐步解方程说明模型工作正常如果思维链乱跳或直接给结论就要检查量化参数是不是压太狠了。第三项是私有知识库实测。在 Cherry Studio 里勾选知识库问一个文档里有明确答案的问题比如“售价在 100 元以上的商品有哪些”。如果回答能准确引用文档里的字段名和数值流程就算通。第四项是微调效果对比。同一个问题问微调前和微调后的模型看答案是不是更贴近业务口径。如果差异不明显先检查 LoRA 权重有没有正确加载再检查数据集有没有在学习阶段跑进模型。最后别忘了看一眼日志。Ollama 的终端日志里会有显存占用、token 生成速度等指标速度稳定在每秒钟 10 到 20 个 token 属于合理范围太低就要排查 CPU 过载或内存带宽瓶颈。我从那以后每次部署完都强制自己把这一套流程完整走一遍哪怕只是换了一个模型版本也会重跑因为上线后才发现模型在糊弄你那才是真的血亏。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
