简介《DeepSeek应用手册》是一份面向深度学习与自然语言处理实践者的入门到进阶参考文档适合希望系统掌握DeepSeek使用技巧、API集成与私有数据接入的开发者、研究人员及内容工作者。手册围绕多模型协同、文件上传、联网搜索、常用指令集与万能提问模板展开并延伸到Cherry Studio、Ollama、Chatbox等工具的API与本地化部署路径同时解释参数规模、max_seq_len、hidden_size等配置项及蒸馏技术、思维链、Qwen与Llama差异等背景知识。整包仅含1个docx文件大小约207KB便于检索与随身查阅内容按使用技巧、使用场景、私有数据集和基础知识组织兼顾操作指引与概念梳理。目前已有287人学习适合需要快速建立DeepSeek应用框架、对照配置参数或在本地与远程环境中接入私有知识库的读者查漏补缺。1. 从聊天框到私有机房这份 DeepSeek 应用手册能省掉哪些弯路DeepSeek 应用手册这四个字很多人第一反应是又一个提示词合集。真拆开看它更像一张从「聊天框」走到「私有机房」的路线图前半段讲 R1 和 V3 怎么拆开用、联网什么时候开、文件怎么丢后半段直接进 API 集成建知识库、Ollama 本地跑、LoRA 微调、KTransformers 把 671B 塞进 24G 显存。适合的人群很明确——手里已经有 API key或者机房里躺着一张 4090却始终没把模型接进业务流程的开发者。下面按指令层、数据层、参数层、部署层四段拆每一步都给到能直接抄的命令和参数新手照着走能跑通熟手能直接跳到参数边界和踩坑那几节。2. 三段式协同与斜杠指令把 R1 和 V3 拆开用的具体写法2.1 为什么是 R1 拆框架、V3 出稿、R1 回炉同一个问题丢给 R1 和 V3体感差别很大R1 回得慢但结构清楚、会主动补边界条件V3 出字快一段话几秒钟就铺开但遇到多步推理容易跳步。根子在于输出 token 的构成——R1 会先把问题拆成若干步写出思维链再给结论输出长度往往是普通对话的两三倍V3 没有这段思维链首 token 快、单位时间产出高。把这两类模型的特性对上任务就有了手册里的三段式结构设计交给 R1长文扩写交给 V3最后再让 R1 做一次挑错。我一般会把三段的边界卡得很死。第一段只要框架明确写「只给标题不要正文」防止 R1 一上来就写三千字第二段把框架原样喂给 V3要求按节扩写温度调高一点让措辞不那么僵第三段把初稿丢回 R1只让它找参数矛盾和逻辑跳跃不要重写全文。三段跑下来总耗时通常比全程用 R1 少一半成稿质量又比全程 V3 高一截。import os from openai import OpenAI # 用环境变量接密钥和服务地址避免把凭据写死在脚本里 client OpenAI( api_keyos.environ[DEEPSEEK_API_KEY], base_urlos.environ[DEEPSEEK_BASE_URL], # 兼容 OpenAI 协议的服务地址 ) R1 os.environ.get(MODEL_R1, deepseek-reasoner) # 带思维链的推理模型 V3 os.environ.get(MODEL_V3, deepseek-chat) # 通用对话模型 def ask(model: str, prompt: str, temperature: float 0.7, max_tokens: int 2048) - str: resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperaturetemperature, # 推理和检查用低温扩写用高温 max_tokensmax_tokens, # R1 的思维链也计入输出要留够 ) return resp.choices[0].message.content # 第一段R1 只出框架明确禁止展开 outline ask( R1, 我要写一份面向运维的私有化部署方案先只给一级和二级标题框架不要正文不超过 12 个标题。, temperature0.3, ) # 第二段V3 按框架扩写速度优先 draft ask( V3, f按下面的框架逐节扩写每节 150 字左右保留标题层级\n{outline}, temperature0.8, max_tokens4096, ) # 第三段R1 回炉只挑错不重写 review ask( R1, f下面是一份部署方案初稿。逐条检查参数是否自相矛盾、步骤是否有遗漏 f按「问题 / 位置 / 修改建议」三列输出不要重写全文\n{draft}, temperature0.2, )逻辑上temperature在三段里的取值是有讲究的第一段和第三段需要模型收敛0.2 到 0.3 就够第二段是扩写0.8 左右能让措辞不那么模板化。max_tokens在 R1 那两段要特别留意思维链会吃掉不少额度设小了会出现「想到一半被截断」的情况这时候/续写指令就派上用场了。常见误用有两种。一是让 R1 一口气写五千字长文结果又慢又容易断还贵二是让 V3 做多步推理中间步骤经常被悄悄跳过看着通顺结论却是错的。把任务按「结构化」和「量产化」分开这两类问题基本就消失了。提示部分兼容层会忽略temperature字段甚至不认 system 角色。约束条件最好直接写进 user 内容里别指望参数生效。2.2 五个斜杠指令本质是提示词展开不是模型魔法手册里列的/续写、/简化、/举例、/步骤、/检查很多人以为是模型内置的能力。实际用下来它们更像客户端层面的快捷替换——你敲一个短词工具把它展开成一段完整提示词再发出去。理解这一点很重要如果客户端不解析模型看到的就是字面上的「/步骤」三个字回答自然是懵的。指令展开后的实际含义典型场景/续写从断点继续不重复已输出内容回答被max_tokens截断/简化改写成非专业读者能懂的话保留数字和结论把技术方案讲给业务方/举例针对结论各给一个可运行例子代码带注释学新框架、写 demo/步骤拆成有序步骤每步写清输入、动作、预期输出操作类任务/检查标出事实错误、参数矛盾、逻辑跳跃并给修正文档校审、代码 review最稳的做法是本地先展开再发送不依赖客户端支持SLASH { /续写: 上一条回答被截断了请从断点继续不要重复已经输出的内容。, /简化: 把上面的内容改写成非专业读者能读懂的话保留关键数字和结论。, /举例: 针对上面的每条结论各给一个可以运行的真实例子代码要带注释。, /步骤: 把上面的方案拆成按顺序执行的步骤每步写清输入、动作、预期输出。, /检查: 逐条检查上面的内容标出事实错误、参数矛盾和逻辑跳跃并给出修正。, } def expand(text: str) - str: # 长指令优先替换避免 /续写 被 /续 之类的短词误伤 for key in sorted(SLASH, keylen, reverseTrue): text text.replace(key, SLASH[key]) return text这段替换逻辑里按 key 长度倒序是个小细节如果以后加了/续写完整版这类更长的指令短词先替换会把长词拆坏。手册里给的两个练习——「/步骤 如何用手机拍摄美食照片」和「请解释量子计算然后 /简化」——用意也在这里前者验证步骤拆解后者验证同一段内容在简化前后的信息密度差异。跑一遍就能直观感受到指令的价值不在「神奇」而在「把一句模糊的话固定成一套明确的输出要求」。2.3 万能提问模板与文件上传的取舍手册给的模板是「背景 需求 约束条件」约束条件可省。这个结构看着朴素实际能解决大部分「答得太泛」的问题。对比一下「怎样提高英语水平」得到的是泛泛而谈「我家小孩读初一怎样提高他的英语水平不需要考虑口语问题」得到的方案会具体到词汇量和语法专项。背景决定了模型的先验从哪来约束决定了它往哪个方向收。上传文件这块四类格式的支持程度差别不小。纯文本和 Markdown 最省心结构清晰、解析无损Excel 适合带表头的数据模型能读懂行列关系图片走的是多模态通道适合截图、票据、手写笔记PDF 是最容易翻车的——带文字层的还行扫描件解析出来常常是空白或者乱序文本。我一般的做法是能拿到原始 docx 就不要导 PDF非要给 PDF 就先做一遍 OCR确认文字能选中再上传。2.4 联网搜索三个开启时机和一套固定问法联网开关不是越多越好。查询最新消息、需要实时数据、验证信息准确性这三种场景不开联网基本拿不到对的答案反过来让模型解释一个概念、改写一段文案、做逻辑推演开联网只会拖慢速度还可能把不相关的网页内容混进来。开启之后还有两步不能省。一是明确提出「需要最新信息」并在问题里带上时间范围比如「最近三个月」二是要求给出来源方便自己回查。我常用的固定问法是「请检索最近三个月内的公开资料回答下面的问题每条结论后面标注来源和时间找不到来源的直接说没有。」这句话一加胡编的概率会明显下降。手册里提到的实时数据分析属于更靠后的玩法基础篇先把这三步走顺后面接数据管道才有意义。3. 私有知识库的三条路Cherry Studio、Ollama、Chatbox 的边界与 API 集成步骤3.1 三条路的边界先想清楚数据能不能出网API 集成、本地部署、远程调用这三条路不是新旧关系而是适用场景不同。选错路的代价很大数据敏感的业务走了 API合规上过不去显存不够的机器硬上本地 32B跑一半 OOM团队共用一台机器却每人本地拉一份模型磁盘先炸。路线数据是否离开本机模型上限上手时间适合谁API Cherry Studio是走服务商官方最新版本十分钟想快速验证知识库效果Ollama 本地否受显存限制半小时数据不出内网、机器够用Chatbox 连远程 Ollama否走内网受服务器显存一小时团队共享一台推理机判断顺序我一般是这样先问数据能不能出网不能就排除 API再看本机显存够不够跑目标规模不够就走远程最后才考虑易用性。这个顺序反了后面一定要返工。3.2 API 方式Cherry Studio 建库的五步这条路的核心是把「模型」和「资料」分开模型走服务商的 API资料留在本地客户端里做检索。步骤不复杂但每一步都有容易忽略的点。下载安装 Cherry Studio在设置里填入 API key 和服务地址。地址填兼容 OpenAI 协议的那个不要填网页版地址。新建知识库命名按业务来比如「售后FAQ」「内部规范」不要都叫「知识库1」。上传文件。优先 docx、md、xlsx尽量别用 PDF尤其是扫描件。等待切分和向量化完成检查切分出来的片段是否通顺有没有整段乱码。对话时手动勾选对应的知识库。这一步最容易忘勾了和没勾的回答完全是两回事。文件格式这块值得单独说一句。PDF 的版面信息在解析时经常丢双栏排版会变成左右交错的两段话表格会变成一堆没有列名的数字。真要用 PDF先确认能用鼠标选中文字选不中的就是扫描件得先 OCR。Excel 反而好用表头清楚、行列关系明确模型读出来的数据不容易错位。3.3 本地方式Ollama 拉模型 Chatbox 接入本地路线的第一步是确认硬件。R1 的蒸馏版按参数量分了好几档显存需求差别很大先看清楚再拉不然几十 GB 下载完发现跑不动。# 先看显卡显存确认能放下多大的模型 nvidia-smi --query-gpumemory.total --formatcsv # 拉取指定规模的蒸馏版默认走 Q4 量化 ollama pull deepseek-r1:32b # 确认模型已经落地顺便看体积 ollama list # 前台启动监听所有网卡方便内网其他机器连 OLLAMA_HOST0.0.0.0:11434 ollama serveollama pull后面的标签决定了模型规模和量化等级32b指的是 320 亿参数的蒸馏版Q4 量化后权重在 20GB 上下加上 KV cache24G 显存的卡跑起来刚好上下文开太大还是会紧张。OLLAMA_HOST默认是127.0.0.1只允许本机访问改成0.0.0.0才能被内网其他机器连上这个改动只在当前会话生效重启就没了想持久化得改服务配置。拉完模型之后装 Chatbox在设置里选 Ollama 作为提供方地址填http://127.0.0.1:11434模型列表里会出现刚才拉的版本选中即可。如果 Chatbox 和 Ollama 不在同一台机器地址要换成服务器的内网 IP。3.4 远程方式改环境变量别改代码远程路线的本质是把 Ollama 从「只监听本机」改成「监听内网」再让 Chatbox 连过去。Linux 上改 systemd 配置是最稳妥的做法比每次启动前手敲环境变量可靠。# 用 drop-in 方式覆盖服务配置不动原始 unit 文件 sudo systemctl edit ollama.service[Service] # 监听所有网卡端口保持默认 EnvironmentOLLAMA_HOST0.0.0.0:11434 # 浏览器端跨域访问需要纯 API 调用可以不加 EnvironmentOLLAMA_ORIGINS*# 重载配置并重启 sudo systemctl daemon-reload sudo systemctl restart ollama # 从另一台机器验证连通性 curl http://192.168.1.10:11434/api/tagsOLLAMA_HOST决定监听地址OLLAMA_ORIGINS决定哪些来源能跨域访问后者在 Chatbox 这类带界面的客户端里经常是连不上的真正原因。改完之后一定要用curl从另一台机器验一次能看到模型列表才算通。Windows 上对应的是setx OLLAMA_HOST 0.0.0.0:11434设完要重启 Ollama 进程才生效。防火墙和端口放行这类事改完配置第一件事就是查别等到客户端报超时才回头找。3.5 分块与检索参数知识库效果的分水岭很多人以为知识库效果差是模型不行实际上大半问题出在切分。块太大检索命中一整页关键句被无关内容稀释块太小上下文断裂模型拿到半句话也答不上来。我一般用下面这组起步参数再按文档类型微调。参数起步值调整方向分块长度300500 字规范类文档取小叙述类取大块间重叠5080 字段落跨页多时调大召回条数 top_k35答非所问时先降到 3 看命中相似度阈值0.6 左右召回太多噪音就往上提调整的顺序是先看切分片段本身通不通顺再看召回的是不是相关段落最后才动 top_k 和阈值。跳过前两步直接调参数往往越调越乱。4. 参数与选型1.5B 到 671B 的显存账、CoT 与蒸馏4.1 参数量 B 到底意味着什么模型名字后面的1.5B、7B、32BB 是 billion指的是参数个数1.5B 就是 15 亿个参数。这个数字直接决定两件事权重占多少存储推理要多少显存。粗算方法是参数量乘以每个参数的字节数——FP16 每参数 2 字节Q4 量化每参数约 0.5 字节再留出 KV cache 和框架开销的余量。规模参数量FP16 权重Q4 权重建议显存含缓存1.5B15 亿约 3GB约 1GB4GB7B / 8B7080 亿约 1416GB约 45GB812GB14B140 亿约 28GB约 89GB1620GB32B320 亿约 64GB约 1820GB2432GB70B700 亿约 140GB约 40GB48GB 以上671B6710 亿约 1.3TB约 350400GB多卡或 CPU 卸载这张表是估算不是精确值。同样是 7B词表大小、层数、是否用 GQA 都会让实际占用差出几个 GB。选型时按表往下压一档更保险比如 24G 卡跑本文还有配套的精品资源点击获取
