简介：《深度解析DeepSeek大模型：技术解析篇-DeepSeek入门宝典》是一份系统讲解DeepSeek公司及其R1大模型技术脉络的PDF文档，适合自然语言处理研究人员、大模型开发者以及关注人工智能行业趋势的决策者阅读。文档先交代幻方量化创立DeepSeek的背景，梳理R1高性能推理、完全开源、极低成本三大特点，并比较官网、APP、API、本地部署、云平台五种使用方式，说明其刷新全球APP增长纪录的原因。核心部分聚焦R1的基座模型V3、三种变体与训练路径，详解强化学习、冷启动数据、监督微调、模型蒸馏等关键技术；同时总结R1与OpenAI o1在架构、训练方式、生态上的差别，展望增强通用性、语言混合、提示工程、软件工程任务四大进化方向。整包为单个PDF文件，大小2.33MB，内容精炼、图文搭配，已有696人学习。读完能建立起从基础模型到推理优化的完整认知，为团队设计高性能、低成本的人工智能应用提供参考。

1. DeepSeek 技术解析篇：为什么说这份入门宝典能帮你打通 R1 全链路

DeepSeek 入门宝典的技术解析篇，核心只回答一个问题：R1 凭什么又便宜又能打。这篇文档把 V3 基座、R1 的三种变体、冷启动、强化学习、蒸馏讲成了一条完整的技术链路，而不是零散的功能点罗列。它适合三类人：想搞懂推理大模型原理的开发者、要给团队做模型选型的架构师，以及只读过新闻但没翻过论文的产品经理。读完你能说清楚几个关键问题：MoE 里 671B 总参数与 37B 激活参数到底怎么配合、纯强化学习为什么能训出推理能力、蒸馏出来的小模型为什么能接近大模型的推理水平。带着这些问题去读，这份 PDF 的信息密度会高很多。

2. 从 V3 到 R1：基座模型、三种变体与训练路径全貌

2.1 V3 基座模型：671B 总参数与 37B 激活参数的真实关系

R1 不是从零训练的新模型，而是在 2024 年 12 月发布的 V3 基座上继续开发出来的。V3 是一个自研的 MoE（混合专家）模型，总参数规模在 671B 左右，和当时闭源旗舰模型处于同一数量级。但 MoE 的关键在于，它不会在处理每个 Token 时把所有参数都拉起来算一遍，而是通过路由机制只激活其中一部分专家网络。V3 每个 Token 计算时激活的参数大约是 37B，占总参数的十八分之一左右。

这里就产生了第一次认知升级：总参数决定模型的知识容量上限，激活参数决定单次推理的算力开销。671B 意味着它能装下足够多的领域知识，37B 激活意味着它每次生成的成本比同体量稠密模型低得多。这也是 V3 能在 14.8T token 上完成预训练，且训练成本可控的重要原因。文档里点得很到位：V3 的定位是对标同期旗舰闭源模型，靠的是工程优化，不是暴力堆卡。

对普通开发者来说，这条信息带来一个直接的硬件判断：你几乎不可能在消费级显卡上直接跑 V3 原版。MoE 虽然激活参数少，但每个专家网络都要常驻显存，671B 权重在 FP16 下光权重就要 1.3TB 左右，这个数量级不是一张 4090 能解决的问题。所以后面聊蒸馏模型，本质上就是在给这种部署困境找出口。

2.2 三种变体：R1-Zero、R1、蒸馏模型的定位差异

R1 系列并不只有单一体，文档把变体梳理成了三个方向。选型的时候先得搞清楚每种变体的定位，否则很容易出现"下了个 R1-Zero 当生产模型用"这种错配。

R1-Zero 是纯强化学习的产物，它的价值在于证明推理能力可以只靠 RL 激励涌现。但它的输出在早期阶段可读性差、格式混乱，不适合直接拿去做产品。R1 正式版是在 R1-Zero 验证可行之后，把工程经验反哺回来的结果，加了冷启动和两个阶段的监督微调，才变成稳定可用的模型。

蒸馏模型则是面向落地端的。文档里明确说蒸馏出了 6 个不同规格的小模型开源给社区，覆盖 1.5B 到 70B 的跨度。这些小模型承担了"在单卡上跑推理"的任务，也是 Ollama、vLLM 这类工具里最常见的部署对象。简而言之：要效果上正式版，要机制研究上 Zero，要本地部署上蒸馏。

2.3 整体训练路径：一条五阶段的渐进路线

把文档里的训练路径图翻译成文字，可以整理成五步。

第一步，确定基座为 V3。R1 没有换底座，而是在 V3 的预训练成果上继续做后训练，这省掉了动辄数千万美元的预训练开销。

第二步，构造冷启动数据。从 R1-Zero 生成的输出里挑选高质量的长思维链样本，形成小规模但质量极高的冷启动集合，让模型先学会像样地思考。

第三步，第一轮强化学习。主要奖励来自答案准确率和输出格式，模型在这个阶段不断探索推理路径，也因此出现了"啊哈时刻"这样的自我反思信号。

第四步，两阶段监督微调。先用拒绝采样拿到 RL 生成的高质量数据做第一轮 SFT，再结合通用对话数据与偏好数据做第二轮 SFT。

第五步，第二轮强化学习。微调完成后，再做一次 RL 进一步对齐，最终得到 R1 正式版。

蒸馏通常放在最后，用一个已经收敛的 R1 当老师，把推理行为拷贝给学生模型，而不是从头训练。这里经常有人误解，以为 R1 全程没有 SFT。其实只有 R1-Zero 是零 SFT，正式版是有两个 SFT 阶段的。理解了这个五阶段顺序，后面看蒸馏和部署就顺了。

2.4 R1 与同期闭源推理模型的三大区别

文档专门把 R1 和同期闭源的 o1 正式版做了对比，三个区别值得记下来。

架构上，R1 是在已有 V3 基座上做的后训练，属于"站在通用模型肩膀上做推理增强"；而 o1 走的是独立新架构路线，没有直接复用某个对话模型作为底座，相当于从设计之初就为推理做了定制。

训练方式上，R1-Zero 证明了仅靠强化学习就能激发推理能力，不需要监督微调也能让准确率稳定上升；另一个闭源模型则依赖监督微调与强化学习的结合。这是两条不同的技术信仰，也是这篇文档最有信息量的一页。

生态上，R1 开源且免费，权重和训练技术一并开放，开发者可以自行部署，也能基于它做蒸馏；闭源模型则需要订阅，权重不可访问。这种差异直接导致了社区生态的分化：一个是被大量第三方工具适配，一个是用户只能等官方更新。对想研究推理模型内部机制的工程师来说，开源是决定性优势。

3. 把训练过程拆开：冷启动数据、奖励设计与两阶段 SFT

3.1 冷启动数据：RL 训练开始前的"入门教程"

纯强化学习有一个尴尬的起点问题：模型在刚开始探索时，输出的自由度过高，可能用各种奇怪的格式、混合语言、碎片化表达进行推理。如果直接在 V3 上开跑 RL，前期会浪费大量采样在"不可读的输出"上。

文档给出的解法是冷启动数据。所谓冷启动，就是在强化学习开始之前，先用少量高质量推理样本给模型打样。这些样本通常是从 R1-Zero 的早期输出里挑出来的、具备完整思维链结构的回答，经过筛选和格式化，成为模型模仿的模板。它的作用很像作文课上的范文：不是告诉模型标准答案是什么，而是告诉模型"像样的推理过程长什么样"。

关键点在于"少量"两个字。冷启动数据不是多多益善，它的目标只是把输出的结构先矫正过来，解决格式和语言混杂问题，剩下更广泛的推理能力探索交给 RL。如果冷启动数据过多，模型反而会过早收敛到模仿路径，压缩 RL 的探索空间。这个度在实践里需要反复试，也是复现 R1 训练流程时最容易跑偏的地方。

3.2 奖励设计：一个可以照着实现的 Python 伪代码

文档把 R1 的强化学习奖励描述成模型的综合评分系统，模型中同一任务按照多个标准获得不同奖励信号。实际工程里，这套奖励系统可以拆成规则奖励和模型奖励两块。下面是一个简化但结构完整的伪代码，体现了奖励组合的常见写法。

def compute_reward(question, ground_truth, predicted, format_ok): """ 计算单个样本的强化学习奖励。 ground_truth: 标准答案; predicted: 模型输出; format_ok: 格式是否符合要求 """ reward = 0.0 # 1) 准确率奖励：答案比对，正确给 1.0，错误为 0 if is_correct(ground_truth, predicted): reward += 1.0 # 2) 格式奖励：要求输出包含 <reasoning> 和 <answer> 两个标签 if format_ok: reward += 0.5 # 3) 语言一致性惩罚：推理过程中中英文混杂时扣分 if has_mixed_language(predicted): reward -= 0.3 # 4) 冗余惩罚：思维链过长且重复内容多时轻微扣分 if is_redundant(predicted, max_len=2048): reward -= 0.1 return reward

这段伪代码里有四个参数值得注意。准确率奖励是主信号，决定了模型"答对题"这个基本方向；格式奖励的权重设为 0.5，目的是把可读性要求变成硬约束，否则模型会为了答对而输出一堆无法解析的内容。语言一致性惩罚是 R1 后续版本里被重点提到的方向，因为初版模型经常在中英文之间漂移。冗余惩罚则是工程经验补上去的，限制模型无限延长思维链。

实际训练时，奖励函数还会加入可验证的规则奖励（比如数学题通过代码执行判断结果）和模型奖励（用另一个模型判断回答质量）。文档里强调的就是这种"多条奖励信号并行"的结构，它避免了单一准确率奖励下模型走捷径或过拟合格式的反效果。

3.3 两阶段监督微调：为什么不是一次 SFT 就够

R1 正式版包含两个监督微调阶段，这一点与 R1-Zero 有本质区别。第一阶段微调，数据来自 R1-Zero 经过强化学习后的 checkpoint，通过拒绝采样筛选出高质量推理样本。第二阶段微调，则是在已有推理能力基础上，混入通用对话数据和偏好数据，让模型同时具备推理能力和良好的人机交互表现。

一个容易混淆的问题是：既然 R1-Zero 已经证明了纯 RL 可行，为什么正式版还要加 SFT？原因在于，R1-Zero 的目标是探索能力上限，它的输出对用户不友好，需要长时间后处理才能用。而正式版的目标是产品化，它必须让模型在数学题、代码题、通用对话中都保持稳定。两个 SFT 阶段相当于把 RL 训练出来的"野性推理"重新梳理成符合人类阅读习惯的表达。

理解这个设计，对后续使用很有帮助。如果你只是调用 API，不需要关心训练细节；但如果你想复现 R1 的训练路线，就一定要记住：R1-Zero 是实验证明，R1 正式版才是工程交付。两阶段 SFT 是那条从实验台走向生产环境的桥梁。

3.4 从"啊哈时刻"到 RL 训练的信号意义

文档里提到了 R1-Zero 在推理过程中突然停下来，说出"等等，这是个值得标记的时刻"这类自我反思话语。在移植到工程语境里，这通常被解读为模型涌现了自我纠正机制：它在推理中段发现前面的思路有问题，主动回溯并换一个方向。

对训练者来说，这个信号的实际意义是：当强化学习奖励曲线不再上升时，不要急着调参，先去看模型生成的思维链里是否出现了这类自我反思行为。如果出现了，说明模型已经超越了简单的模式匹配，开始在推理空间里做更复杂的搜索，后续训练效果会进入一个相对陡峭的上升期。

从评估角度，文档给出的量化结论是：随着 RL 训练逐步推进，R1-Zero 的性能稳定且持续提升。这给我们的操作启发是，评估 RL 训练进度不能只看某一个 checkpoint 的表现，要看趋势。单轮采样里的偶然高分可能是运气，连续多轮稳定上升才说明强化学习真正起作用了。

4. 从 671B 到 7B：蒸馏与本地部署的实际操作

4.1 蒸馏到底在蒸馏什么

蒸馏的基本逻辑是：大模型当老师，小模型当学生，老师把知识通过高质量数据传递给学生。R1 蒸馏的特别之处在于，它传递的不是死知识，而是推理行为。小模型学到的是大模型处理问题时"先分析、再验证、最后回答"的思维链路，而不只是记住了某些问题的标准答案。

文档里给出一个很漂亮的结论：用 R1 蒸馏出来的小模型，在部分推理任务上超过了同期的 o1-mini。这意味着，对于数学题、逻辑推理这类强规则任务，蒸馏模型的性价比极高。70B 的蒸馏版在部分评测里甚至能逼近 671B 老师的表现，而显存占用却只有它的十分之一左右。

但蒸馏也有边界。小模型参数量决定了它的知识容量上限，遇到需要广泛事实知识或长上下文推理的任务，蒸馏模型依然会露怯。文档最后提到的"想要突破当前智能的边界，可能仍需要更大规模的基础模型与强化学习"，就是在点这个行业共识。

4.2 Ollama 跑 7B 量化版：三分钟起一个推理模型

个人体验下来，用 Ollama 跑 R1 蒸馏版是最快的本地部署路径。下面的命令可以直接拉起一个 7B 量化模型。

# 拉取并运行 DeepSeek R1 蒸馏版 7B ollama run deepseek-r1:7b

这条命令会自动下载模型权重并启动交互式对话。Ollama 的优势是把管理员操作全封装了，不需要手动配置 Python 环境或 CUDA 依赖。参数层面，如果你显存紧张，可以在模型名后面加量化标识，比如deepseek-r1:7b-q4_K_M，用略低精度换取更小的显存占用。

运行起来后，我一般会先让它解一道二元一次方程题，观察输出里是否包含完整的推理链路，而不仅仅是最终答案。这比直接问"你好"更能验证推理模型是否真的加载成功。

4.3 vLLM 跑更大参数：并发与显存怎么权衡

如果是给团队搭内部服务，vLLM 是比 Ollama 更合适的选择。它可以做批量推理和连续 batching，吞吐量明显优于逐条对话的 Ollama。下面是一个典型的 32B 蒸馏模型启动命令。

# 启动 32B 蒸馏模型的 vLLM 服务，2 卡张量并行 vllm serve deepseek-ai/DeepSeek-R1-Distill-32B \ --tensor-parallel-size 2 \ --max-model-len 32768

这里--tensor-parallel-size 2表示把模型切分到两张 GPU 上推理，适合一张卡放不下 32B 权重的情况。--max-model-len 32768是上下文窗口长度，设置太大时 KV cache 会占用大量显存，建议按实际业务需求的 1.5 到 2 倍预留。启动后通过 HTTP 接口调用，OpenAI 兼容的 API 格式让迁移成本很低。

显存估算有个通用公式：模型权重大约等于参数量乘以每个参数占用的字节数。32B 模型在 FP16 下权重需要 64GB 左右，所以单张 48GB 卡放不下，两卡并行是合理的起点。

4.4 五种使用方式怎么选：从官网到云平台

文档列出的五种使用方式，覆盖了从尝鲜到生产的所有场景。官网和 App 适合普通用户，零成本体验完整版 R1，不需要任何硬件；API 适合开发者和企业，把 R1 的能力嵌入自己的应用；本地部署适合对数据安全有要求的团队，通过 Ollama、vLLM 等工具保证访问稳定性和扩展性；云平台则适合不想自建 GPU 集群的团队。

我的建议是，技术验证先用官网，接口联调用 API，真正生产部署前再考虑本地或云平台。不要一开始就扑到本地部署上，R1 完整版不是一块显卡能带动的。

5. 避坑指南：复现和使用 R1 最容易翻车的五个地方

这篇文档给的信息量足够撑起完整落地，但实际操作里坑也不少。以下五条来自我自己的踩坑总结，每一条都是先遇到了现象，再去文档里找原因，才最终解决。

5.1 R1 对提示敏感：加了 few-shot 示例，分数反而下降

现象：给 R1 输入一个数学题时，为了让模型理解要求，我在提示里加了两三条标准答案示例，结果模型的输出反而变差，推理链路混乱，甚至开始模仿示例里的错误格式。

原因：文档里明确说过，R1 对提示比较敏感，少量示例提示有时会降低性能。它的推理能力是在强化学习阶段建立起来的，模型已经习惯了直接从问题出发做推理，额外塞入的示例会干扰它的内部规划流程。

解决：在处理数学和逻辑推理任务时，我改用"只给一个问题 + 明确输出格式要求"的做法，不再加 few-shot。如果确实需要示例，控制在一条以内，并且放在输入最前面而不是问题后面。

5.2 把 R1-Zero 的早期输出误判为训练失败

现象：第一次尝试复现 R1-Zero 流程时，看到模型前几百步生成的推理内容几乎没有结构，中英文混杂，甚至出现重复的乱码，差点直接判定训练失败。

原因：R1-Zero 没有冷启动数据，也没有 SFT，模型在最开始就是在完全混乱的探索空间里乱撞。这是纯强化学习的开放探索期，不代表训练走错了方向。

解决：把评估周期拉长，不再看单轮输出，而是按 checkpoints 画准确率趋势线。文档里那张"随 RL 训练逐步推进，性能稳定且持续提升"的图表就是最好的判断工具。从那以后我复现任何 RL 训练，都会强制走一遍"只看趋势、不看单轮"的评估流程。

5.3 中英文语言混合：中文提问，英文思维链

现象：用中文向 R1 提问，模型的推理过程却大段变成英文，最后答案又切回中文，整体观感非常割裂。

原因：R1 的训练数据里中英文混合现象没有被完全消除。文档在四大进化方向里专门提了"语言混合"问题，承认 R1 在一些复杂任务上存在这类行为。

解决：在提示里显式要求"整个推理过程请使用中文"，这句话能在多数场景下抑制语言漂移。如果你的业务对输出语言有强要求，建议在提示工程层面加一道后置检查，而不是只依赖模型自觉。

5.4 蒸馏小模型的能力边界：把它当成万能模型用

现象：把 7B 蒸馏版模型部署后，发现它在数学题上表现不错，但在复杂代码生成和长文档理解上明显吃力，甚至不如一些通用对话模型。

原因：蒸馏模型学的是推理行为和特定任务模式，参数量限制了它的世界知识储备和长期依赖建模能力。文档里说的"蒸馏小模型的高性能证明了策略有效，但突破智能边界仍需大模型"，就是在定这个调。

解决：把蒸馏模型用在结构清晰、规则明确的推理任务上，比如数学题、逻辑题、代码 debug。需要宽泛知识或长上下文的场景，回退到 API 调用完整版。

5.5 部署显存与并发：激活参数少不等于显存少

现象：看到 V3 每个 Token 只激活 37B 参数，觉得 24GB 显卡能跑。实际部署时直接 OOM，模型根本加载不进去。

原因：MoE 模型虽然激活参数少，但所有专家网络都要常驻显存。671B 权重在 FP16 下超过 1TB，不做量化或蒸馏，消费级显卡完全没有可能性。

解决：三条路选一条走。第一，直接用蒸馏版小模型；第二，用bitsandbytes做 4bit 量化，把权重压下来；第三，上多卡张量并行。不要指望靠"激活参数少"来省显存，这是 MoE 最常见的误解。

6. 三个验证实验，确认你真的读懂了 R1

读技术文档最怕的是"眼睛会了，手不会"。我建议拿到这份入门宝典后，用三个小实验验证自己是否真正理解了 R1。

实验一，观察思维链。打开官网或 App，输入一道需要多步推导的数学题，不要只检查答案对不对，重点看推理过程里有没有出现自我修正。如果模型写了几步之后突然换方向，说明你看到的正是强化学习训练出来的反思能力。

实验二，验证提示敏感性。在同一个模型上，先直接提问一次，再在提问前加一条标准答案示例，对比两次的推理质量。如果你能明显感觉到加了示例后输出变差，说明你已经亲身验证了文档里"R1 对提示敏感"的结论。

实验三，本地部署一次。用 Ollama 拉起 7B 蒸馏版，测试它的推理速度和输出格式。对比它与网页完整版的差距，你就能直观理解蒸馏在性能和效果之间的取舍关系。

# 实验三辅助：通过 Ollama API 验证蒸馏模型是否正常返回推理链路 import requests resp = requests.post( url="http://localhost:11434/api/generate", json={"model": "deepseek-r1:7b", "prompt": "求 x: 3x + 5 = 20", "stream": False}, timeout=60, ) text = resp.json().get("response", "") print("包含推理标签:", "<reasoning>" in text) print("答案存在:", "x = 5" in text.replace(" ", ""))

这段脚本的逻辑很简单：请求 Ollama 本地接口，发送一道简单方程题，检查返回文本里是否包含推理标签和正确答案。如果你能看到<reasoning>标签，说明模型确实按推理格式输出；如果连这种题都答不对，优先检查模型是否没有正常加载。参数层面，model要和你ollama run时用的名字一致，stream: False表示等待完整输出后再返回。

从那以后，我每次拿到新模型的技术资料，都会强制自己先画一张训练路径图，再跑一个最小验证实验。这两个动作做完，文档才算真正读完了。希望这份拆解能帮你在 DeepSeek R1 这条技术链路上少走几步弯路。

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