企业官网建设流程全解析

简介：DeepSeek自学手册以PDF电子文档形式整理，系统讲解DeepSeek V3与R1两大模型的训练原理与应用方法，适合想深入理解MoE架构、推理模型机制及提示词工程的AI学习者、开发者与提示词创作者。手册从模型训练切入，详细拆解V3的MLA多头潜在注意力、无额外损耗负载均衡、多Token预测策略，以及R1从基础模型到R1-Zero再至正式版的多阶段训练流程，并融入冷启动数据、强化学习与模型蒸馏等关键概念。同时给出R1后提示词的变与不变分析、四大使用技巧、13个官方提示词样例以及在线与本地部署的替代方案，能够帮助读者建立从理论到实战的完整认知。资源为单个PDF文件，压缩包大小为302.49MB，内容图文并茂，适合作为案头参考与反复研读材料。目前已有149人学习，是快速入门DeepSeek并落地应用的高密度自学资料。

1. DeepSeek 手册里最容易被忽略的一句话：R1 的提示词规则变了

先抛一个反常识的结论：DeepSeek R1 上线后，被吐槽最多的问题不是推理能力，而是“不会听话”——你用惯了 ChatGPT 或 V3 的那套提示词模板去喂 R1，效果反而会变差。这不是模型变笨了，而是 R1 的训练范式从“模仿人类回答”转向了“强化学习驱动推理”，它内部有一套自主的思考链条，你强行用 few-shot 示例去约束它，等于给一个会自己画草稿纸的选手塞了一张标准答题卡。

这本《DeepSeek 自学手册（截至 2025 年 2 月更新）》最值钱的部分，就是把 V3 与 R1 的训练差异、R1 后提示词的“变与不变”、官方 13 个提示词样例、以及在线与本地部署方案做了一次压缩。它适合三类人：想搞懂 MoE 与强化学习训练流程的算法工程师、正在把 DeepSeek 接入业务系统的后端开发者、以及每天跟提示词打交道但始终没搞清楚 R1 与 GPT 系模型行为差异的产品经理。读完这篇拆解，你能直接拿走可复现的提示词写法、蒸馏版本地部署命令，以及一套参数调优思路。

2. DeepSeek V3 与 R1 的训练骨架：MoE、MLA 与强化学习路径

2.1 V3 的 MoE 架构：为什么 600 万美元能训练出千亿级模型

V3 是一个典型的混合专家（MoE）语言模型，总参数量达到 671B，但每个 token 只激活部分专家，推理成本远低于同规模的稠密模型。手册里用“团队协作”来比喻 MoE：遇到问题时不是所有专家一起上，而是根据问题类型动态选择最合适的几个专家。这个思路落到工程实现上，就是门控网络（Gate）根据输入 token 的语义特征，从一组专家中选出 Top-K 个进行前向计算。

V3 在 MoE 基础上做了两项关键改造。第一项是无额外损耗的负载均衡（Auxiliary-Loss-Free Load Balancing），传统 MoE 训练时通常会加一个辅助损失函数来约束专家使用率，但辅助损失会干扰主任务优化目标。V3 的做法是引入一个偏置项动态调整每个专家的“被选中概率”，训练过程中持续监控各专家的 token 分配量，让过载专家的偏置降低、闲置专家的偏置升高。第二项是共享专家（Shared Expert）机制，部分专家对所有 token 生效，负责通用知识提取，其余专家做领域分化，避免所有专家都往高频特征上凑。

MLA（多头潜在注意力）值得单独拎出来说。传统 Transformer 推理时需要缓存每个 head 的 K 和 V 矩阵，长上下文场景下显存开销很大。MLA 的做法是把 KV 压缩到一个低维潜在向量中，推理时只需缓存这个压缩向量和对应的解耦 Rotary Position Encoding（RoPE）信息。以 64 层、128 个 attention head 的模型估算，传统 MHA 需要缓存 128 个 K/V 矩阵，MLA 只需缓存 1 个潜在向量加少量位置编码，长文本生成的吞吐量能提升数倍。这也是 V3 能处理 128K 上下文而显存占用可控的核心原因。

2.2 R1 的训练三步走：预训练、SFT 与 RL 的取舍

手册对 R1 的训练描述包含一个容易误读的点：很多人记住的是“R1-Zero 跳过了 SFT 直接做强化学习”，但完整版 R1 的训练并非如此。R1-Zero 是实验性验证路径，直接对 V3-Base 做 RL，结果模型虽然涌现出“顿悟时刻”（Aha Moment，即模型自发在推理中间步骤进行反思和纠错），但输出可读性差、语言混杂严重。

完整版 R1 走了三阶段路线：

• 冷启动 SFT：用数千条人工精心标注的高质量推理示例（包含详细的解题步骤和思维链）对 V3-Base 做监督微调，让模型先学会“像人一样组织推理过程”。
• 推理导向 RL：在 SFT 基础上，用 GRPO（Group Relative Policy Optimization）算法继续强化。GRPO 是 PPO 的简化变体，它不像 PPO 那样需要单独训练一个 Critic 模型来估计状态价值，而是通过对同一 prompt 采样多个输出、计算组内相对优势来更新策略。每组采样的输出数量一般设为 4 到 16，组内优势归一化后计算策略梯度。数学和代码任务采用规则奖励模型（根据答案是否正确直接打分，例如 LeetCode 判题结果），开放式任务则用基于模型的奖励模型。
• 通用能力对齐：最后混合写作、翻译、多轮对话等非推理数据继续微调，避免模型在强化推理能力的同时丢失通用能力。

这里的核心工程启发是：规则奖励模型比模型奖励模型更可控、更便宜。如果你正在训练自己的推理模型，先跑通规则可验证的任务（数学、代码、SQL 生成），再逐步扩展。

2.3 蒸馏策略：7B 模型为什么能打 GPT-4o

手册提到蒸馏版 R1 系列：用 R1 生成的 800K 高质量推理数据对 Qwen 和 Llama 系列小模型做 SFT，7B 版本在数学任务上能超过 GPT-4o，32B 版本接近 o1-mini。关键不是蒸馏本身多神奇，而是“教师模型”R1 的思考链数据质量足够高。

蒸馏版与满血版的差异在工程上很重要。蒸馏版 7B 模型在纯 CPU 环境下可运行，而满血 671B 的 R1 需要 4 卡 80G H100 才能勉强跑起来，显存需求超过 1.5TB（FP8 量化）。手册在第六部分铺垫的“替代方案”实际上就是蒸馏版小模型 + API 混合架构。做生产系统时的常见策略是：简单问答走 V3，复杂推理走 R1 API，中等复杂度的任务用本地蒸馏模型做兜底和限流。

3. R1 后提示词工程：失效与依然有效的七类技巧

3.1 失效的技术：few-shot 与显式 COT

R1 的官方技术报告明确给出一个令人意外的结论：少样本提示（few-shot）会持续降低模型性能。原因是 R1 在 RL 阶段已经学会了自主推理，外部示例反而会干扰它的推理路径。同样失效的还有显式要求“Let‘s think step by step”这类 COT 指令，R1 内部已经生成了隐藏思维链，你再去要求它展示推理过程，要么被拒答，要么输出冗长的“伪思维链”。

这里需要区分一个概念：R1 的思考过程是模型内部生成的，OpenAI 的 o1 系列用“隐藏思维链”做安全隔离，DeepSeek R1 虽然没有把思维链完全隐藏，但过度要求 COT 细节会触发模型的防御机制。正确做法是直接提出需求，让模型自行决定思考深度。

3.2 依然有效的基础技巧：清晰性、背景信息与占位符

手册里验证过在 R1 上依然有效的方法有三类：

第一类是清晰、具体地表达需求。对比“写一篇关于时间管理的文章”和“请写一篇关于如何提高个人时间管理能力的文章，要求包含三个具体的方法，并详细解释每个方法的实施步骤”，后者的回答质量明显更高——推理模型擅长把大问题拆成子问题，但前提是你先给它一个可拆的结构。

第二类是提供背景与规则。比如写产品推文时给出目标用户、产品特性、字数限制、风格要求，R1 能更好地理解约束边界。这类技巧和 V3 时代没有本质变化，因为 RL 训练本身就是通过奖励函数强化“符合约束条件”的输出。

第三类是占位符标记，让模型按 JSON 结构输出。这是工程场景中最实用的技巧：

{ "task": "总结文件内容", "output_format": { "title": "{{故事标题}}", "genre": "{{故事类型}}", "plot": "{{故事梗概}}", "characters": ["{{角色1}}", "{{角色2}}"], "settings": "{{故事背景或场景}}" } }

占位符起到了两个作用：一是明确输出格式，让 R1 的结构化生成能力得到发挥；二是把输出字段的语义限定住，避免模型自由发挥。实际调用时，直接把这段 JSON 作为 user prompt 发送，R1 会返回对应的 JSON 结构。

3.3 需要试探的边界：角色设定与示例使用

角色设定在 R1 上表现不稳定。手册指出：如果你让 R1 扮演“精通 Web 开发的高级工程师”，这是无效的，因为 R1 比人类更了解工程师应该掌握哪些技术栈，你列出的技术清单反而成了约束。但如果你让 R1 扮演“一个说话中英文夹杂、喜欢秀优越感的海归”，这种带鲜明人设特征的角色却有效。区别在于：前者是伪角色（工艺知识型），后者是真角色（语言风格型）。R1 对语言风格的模仿能力强，对知识能力的设定无感。

示例使用同理。如果示例是让 R1 模仿风格（比如小红书笔记），R1 通常比人类的示例写得更好，给了示例反而拉低上限；但如果示例是格式模板（比如公司报告摘要的固定结构），R1 会尊重格式约束。判断标准就是：示例是在教风格还是在教格式——要格式给格式，要风格不给风格。

4. 13 个官方提示词样例的结构化拆解：从模板到工程调用

4.1 提示词的四个通用层：任务、约束、输入、输出

手册列出的 13 个官方提示词样例，归纳下来都包含四个通用层，作结构化提示词时可以直接套用：

4.2 覆盖六类任务场景的样例样本

官方样例覆盖了办公写作、创意文案、编程开发、内容总结、商业分析、翻译润色六类场景。以商业分析报告摘要为例，官方的提示词模板结构如下：

附件是我司针对某领域的商业分析报告，请按照以下格式撰写报告摘要： 本报告针对……（商业问题或项目背景）进行了深入分析。 通过……（数据收集方法或市场调研手段），我们发现……（主要市场趋势或问题）。 基于这些发现，我们提出了……（解决方案或策略建议），预计能够实现……（预期效果或收益）。 报告还对……（潜在风险或挑战）进行了评估，并提出了相应的应对措施。

这个模板的价值在于它把商业报告的叙事逻辑直接暴露给了模型：背景→方法→发现→方案→预期→风险。R1 在推理模型的训练中已经吸收了这种分析框架，你给出框架骨架，它会用具体内容填充。对比直接用“帮我写一份报告摘要”，这种结构化的效果差异很大。

我改造提示词时的操作习惯是：如果任务需要模型做事实性分析（比如上传数据表让模型找异常），优先用“链式分解”的提问方式。不要一口气问“我的软件系统出现了性能瓶颈，请帮我分析如何定位和解决”，而是拆成多轮：先问“常见瓶颈可能出现在哪些环节”，再针对回答继续追问“如何定位数据库瓶颈”“如何验证优化效果”。每轮的问题聚焦到一个点上，R1 的推理深度和质量会更稳定。

4.3 从提示词到 API 调用：结构化输出的工程配置

提示词结构再清晰，落到工程调用时还需要配置参数保证输出稳定性。下面是一个完整的 API 调用示例，使用 DeepSeek 官方的 OpenAI 兼容接口：

curl https://api.deepseek.com/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $DEEPSEEK_API_KEY" \ -d '{ "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是一个商业分析助手，输出报告摘要时必须严格遵循用户给定的格式框架。"}, {"role": "user", "content": "附件是我司针对某领域的商业分析报告，请按照以下格式撰写报告摘要：……"} ], "temperature": 0.3, "top_p": 0.9, "max_tokens": 2048, "response_format": {"type": "json_object"} }'

参数选择逻辑如下：temperature设为 0.3 是推荐值，R1 的推理过程具备确定性，温度过高反而容易让推理偏离；top_p维持 0.9 控制采样的核范围；response_format强制 JSON 输出，配合提示词里的占位符模板，能得到稳定的结构化结果。需要说明的是，deepseek-chat指向 V3 模型，deepseek-reasoner指向 R1 模型。R1 的实际响应时间会比 V3 长 2 到 5 倍，因为内部要先生成推理链，对外体现为首 token 延迟较高，接入实时对话场景时要注意超时设置。

from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-reasoner", messages=[ {"role": "user", "content": "为一款配备AI动物识别系统的新型双筒望远镜写产品发布推文，字数800字，体现前沿科技感。"} ], temperature=0.3, max_tokens=2048 ) print(resp.choices[0].message.content)

这段 Python 代码的关键在base_url参数：DeepSeek 的接口完全兼容 OpenAI SDK，业务代码里的模型层替换成本极低。deepseek-reasoner返回的内容包含reasoning_content字段，存储模型的内部思考链。生产环境建议把reasoning_content单独落盘，一方面可以做推理过程审计，另一方面能沉淀为业务特征数据——比如客服场景中分析 R1 的思考链，能知道它对用户意图的判断依据。

实际开发中我遇到的一个典型问题是 R1 响应的max_tokens设置：R1 会先输出几百 token 的思考链再输出最终回答，如果max_tokens设置偏小（比如 512），答案还没写完就被截断。建议 R1 请求的max_tokens设置为 V3 的 1.5 到 2 倍，或者前端直接使用流式响应，边生成边展示。

5. R1 蒸馏版本地部署与 API 调用实践

5.1 部署选型：蒸馏版小模型还是满血版 API

手册第六部分提到了替代方案（在线与本地部署），这里给你一套选型判断依据。当前 DeepSeek 官方提供两种接入路径：

如果业务场景对数据隐私要求高（比如处理内部代码库、合同文本、医疗数据），必须走本地部署。最常见的操作是用 Ollama 快速拉起蒸馏版模型：

# 拉取 R1 蒸馏版 7B 模型的 Q4 量化版本 ollama pull deepseek-r1:7b # 运行模型，开启 OpenAI 兼容接口 ollama serve

Ollama 默认监听127.0.0.1:11434，启动后可用 curl 验证服务状态：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "请证明根号2是无理数"}], "temperature": 0.6 }'

对部署架构的一些建议：7B 蒸馏版在纯 CPU 环境下也能跑，但生成速度仅有 5 到 10 token/s，体感很差。生产环境至少需要一块 16GB 显存的 GPU（如 4090、A10、T4），或者使用 llama.cpp 加 AVX2 指令集的 CPU 推理。32B 蒸馏版用 Q4 量化后约 20GB 显存，单张 24GB 的 4090 或 L4 可以流畅运行。如果量化到 Q2，显存需求能压到 12GB 左右，但输出质量会明显下降，主要表现是推理链条断裂和中文表达能力衰减。

5.2 通过 Ollama 调用本地模型的工程参数

Ollama 提供了num_ctx参数控制上下文窗口大小，默认值 2048，对 R1 这类推理模型明显不够。R1 的推理过程需要同时在上下文窗口里保留用户问题、中间推理步骤和最终答案，建议至少设置为 8192：

ollama run deepseek-r1:7b --num-ctx 8192

如果需要更高的并发处理能力，用 Docker 方式独立部署推理服务，并绑定 GPU 资源：

docker run -d --gpus all \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name deepseek-local \ ollama/ollama

容器启动后进入交互环境拉取模型：

docker exec -it deepseek-local ollama pull deepseek-r1:32b

这里补充一个性能参数参考：7B Q4 模型在 4090 上约能跑到 80 token/s，32B Q4 约 30 token/s，满血 671B 的 R1 即使 8 卡 H100 集群也只有约 20 token/s。蒸馏版在吞吐量上对中小业务完全够用。手册强调的“省钱又高效”在工程层面对应的是成本模型：7B 模型在 A10 上单次请求的推理成本约为满血版 API 的百分之一。

5.3 V3 与 R1 的分流策略：一个简单的路由规则

生产环境中的常见问题是：所有流量都走 R1，成本和延迟都比较高；全部都走 V3，复杂推理任务又可能答错。可以用下面的规则做分流，基于modules和role字段判断：

def route_query(prompt: str) -> str: # 含数学表达式、代码题、逻辑推导类关键词 → 走 R1 if any(kw in prompt for kw in ["证明", "推导", "leetcode", "复杂度", "证明题"]): return "deepseek-reasoner" # 通用问答、写作、翻译、多轮对话 → 走 V3 return "deepseek-chat"

这个规则比较粗糙，为了更容易提升命中率，可以统计典型场景下 R1 与 V3 的 token 消耗比和用户满意度，按业务里实际的错误样例反推。规则路由的收益在于：R1 请求的 token 消耗通常是 V3 的 3 到 5 倍（思考链会额外产生大量 tokens），分流后整体成本能下降 40% 到 60%。

6. 温度参数与上下文窗口的调优与验证方法

6.1 不同任务类型的温度参数对照

R1 在训练上经过了大規模 RL 强化，推理时会生成内部思考链，因此对外采样的随机性控制尤为重要。温度参数直接决定 R1 输出的确定性程度：

做一次 A/B 对比能直观理解温度的影响：同一道数学题，temperature=0.1时 R1 用一段清晰的推理链给出正确答案；设为1.2后，模型容易在推理中途产生跳跃性错误。推理模型经过 RL 训练后已经内化了推理模式，减低温比“加更多提示词约束”更有效——这条经验在 V3 上不明显，但在 R1 上非常明显。

6.2 上下文窗口、温度与 beam search 的综合调优

R1 支持最大 128K 的上下文窗口，但在长文本任务中，窗口接近极限时模型性能会下降。原因是推理链 + 长上下文的注意力计算会分散模型的注意力资源。如果你需要处理超长上下文，建议分块处理而不是一把梭丢进单次请求。

结合之前部署章节的内容，完整参数配置建议如下：

resp = client.chat.completions.create( model="deepseek-reasoner", messages=[{"role": "user", "content": prompt}], temperature=0.3, max_tokens=4096, top_p=0.95 )

top_p=0.95对 R1 的收益在于：R1 的采样分布比 V3 更尖锐（因为强化学习让最优路径的概率更高），同样的 top_p 值下 R1 的多样性更低，正好适合推理任务。相比 V3 常用的temperature=0.7, top_p=0.9，R1 需要更低的温度来保证推理链的一致性。

6.3 用 MATH-500 样例做回归验证

在调整完参数后，推荐用一个固定的评测集做回归测试。手册提到 R1 在 MATH-500 上达到了开源模型最高水平，你可以直接取 MATH-500 的前 20 题作为基线，每次调整参数后重跑一遍：

# 使用简单的正则匹配，检查答案是否包含期望的数字结果 def eval_math(resp_text: str, expected_answer: str) -> bool: # 提取最终答案，R1 的输出通常包含 "final answer is ..." 之类的标记 match = re.search(r"final answer[:\s]*([\d.\-]+)", resp_text.lower()) if match: return abs(float(match.group(1)) - float(expected_answer)) < 1e-6 # 提取失败则视为不通过 return False

这个验证脚本的意义在于让参数调整有据可依。常见指标是 20 题中的正确题数：temperature=0.3时 7B 蒸馏版通常能答对 15 到 17 题，如果低于 14 题就需要检查模型版本、提示词是不是被截断、还是上下文窗口不足。

最后补一个容易踩的坑：不要在 system prompt 里写“你是一个擅长数学的 AI 助手，请一步步思考”之类的描述。R1 已内置推理模式，这类提示词不仅多余，还可能干扰它的任务理解。system prompt 只需要保留任务规则、输出格式和拒绝条件。把推理自由度留给模型隐藏的思考链，你只负责定义输入、约束和预期的输出形状。

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