简介：这份由清华大学新闻与传播学院新媒体研究中心团队编写的《DeepSeek：从入门到精通》PDF，是一份面向AI研发人员、工程师及对国产开源大模型感兴趣学者的技术指南。资源共1个PDF文件，大小4.83MB，围绕DeepSeek-R1推理模型展开，系统讲解智能对话、文本生成、代码生成、语义理解等典型应用场景。内容重点对比推理模型与非推理模型的能力差异，结合CoT链式思维说明如何按任务选择合适模型，并给出指令驱动、需求导向、混合模式、启发式提问等提示语策略与常见设计陷阱的应对方法。已有218人学习下载，适合企业开发者降低应用成本，也可帮助个人提升复杂问题处理能力，同时为学术研究提供技术参考。
1. DeepSeek：把「会推理的国产开源模型」从展柜搬进生产环境
当模型能在一张 8GB 显存的消费级显卡上先写完整推理过程、再给出正确答案时，国产开源通用人工智能推理模型这个标签才算真正有了工程意义。DeepSeek 最打动我的不是榜单分数，而是它把「先思考再作答」变成了可观察的默认行为：数学题会分步推导，代码会先列思路，复杂指令不再硬着头皮直接答。对应用工程师来说，这带来三个直接好处：权重开源可以自主部署，蒸馏小模型让本地跑通成为现实，输出过程可见让排查不再靠猜。
适合谁读：想低成本落地智能问答、代码生成、文档结构化处理的开发者，以及被闭源 API 账单和黑匣子一样的响应逻辑反复折腾过的团队。下面按「原理 → 部署 → 调优 → 避坑 → 微调」五步推进，把整条落地路径讲清楚，重点放在能直接抄走的命令和参数上。
2. 先看懂 DeepSeek 的推理机制与 MoE 架构：选型和部署前的必修课
2.1 强化学习逼出来的「思考链」：R1 为什么不一样
传统大模型的训练路径是「预训练 + 指令微调 + 人类偏好对齐」，学到的行为模式是「用户问一句，模型直接给答案」。DeepSeek 在 R1 这条线上换了个思路：先让模型在数学、代码、逻辑这类有明确对错的任务上做强化学习，用规则校验答案正确性作为奖励信号，完全不给人工标注的推理步骤。结果模型自己「涌现」出了长思考链——为了答对题，它学会了把问题拆开、逐步推导、自我检查。这个发现后来被做成 R1 系列，并在思考链前后加上明确的开始结束标记。
对使用者的直接含义有三条。第一，推理不是免费的：思考过程消耗大量 token，同一道题可能比传统模型多花 3 到 5 倍的长度。第二，思考链是「可以被提示触发的」：只要在系统提示里写明「先分步推理再给答案」，即便是蒸馏出来的小模型，推理稳定性也会明显改善。第三，思考风格可以调：有些场景要保守推导，有些场景要快速出答案，这主要靠解码参数控制，第四章专门讲。
2.2 MoE 架构的真实账本：671B 总参数，为什么推理只激活 37B
DeepSeek 的主力大模型采用 MoE（Mixture of Experts，混合专家）结构。总参数高达几百亿甚至六百多亿，但每一个 token 只会激活其中极小一部分专家。设计目的是把模型容量做大，同时把单次推理的计算成本压下来。这里最常见的理解偏差是：「只激活 37B，那我 24GB 显存是不是就够了？」不是。权重必须完整加载进显存，激活参数只影响算力消耗，不影响存储占用。MoE 省的是计算量，不是显存。
所以部署选型的核心动作是：先把总权重显存算清楚。全量 FP16 权重按「参数量 × 2 字节」估算，再留出 KV cache 和激活值的余量。一张 24GB 单卡能比较舒服跑的是 14B 量化版或 32B 高压缩量化版；本地开发调试阶段，我更推荐 7B 或 8B 的蒸馏小模型，理由后面会说。为方便直观对照，我按常见做法整理了选型参考：
| 模型规模 | 权重大小估算 | 可用部署方式 | 建议场景 |
|---|---|---|---|
| 1.5B~3B | FP16 约 3~6GB | 纯 CPU 可跑，低显存卡也行 | 分类、抽取、函数调用 |
| 7B~8B 蒸馏版 | FP16 约 14~16GB | Q4 量化后 8GB 显存可跑 | 开发调试、小并发服务 |
| 14B~32B | FP16 约 28~64GB | Q4 量化后 24GB 单卡 | 生产级中等并发 |
| 671B MoE 全量 | FP16 权重超 1.2TB | 多机多卡 | 研究、离线批处理、当教师模型 |
这张表的数字是工程估算，具体以实际下载的模型文件大小为准。选型还要看第二件事：激活参数量决定推理吞吐上限。32B 蒸馏模型的激活参数就是 32B，而 671B MoE 每个 token 只激活约 37B——所以显存管够的多卡集群上，大 MoE 反而有更好的单位成本效率，这也是不少团队宁可多卡跑大模型、也不愿单卡跑蒸馏版的原因。但对多数团队，单卡跑蒸馏版的价值是「立刻能开始」，先把链路跑通，比什么选型理论都重要。
注意：蒸馏版是从大模型能力「压缩」出来的，不是简单砍参数。请把它当「一个擅长推理的小模型」看待，别指望它复刻 671B 的全部水平。
3. 本地部署 DeepSeek 的最小复现路径：从 Ollama 到 vLLM
部署工具我习惯倒着选：先用 Ollama 把模型跑起来验证效果，再按并发和延迟需求决定要不要上 llama.cpp 或 vLLM。不要一上来就搭一套复杂的服务编排，很多项目死在「还没跑通一条 prompt，先搭了三层平台」。
3.1 用 Ollama 跑起 7B 蒸馏版：两条命令加一个 API 验证
Ollama 是目前本地跑推理模型最省事的方案，把模型下载、量化、运行时和对话补全接口都打包好了：
# 拉取 DeepSeek 7B 蒸馏版（默认 Q4_K_M 量化） ollama pull deepseek-r1:7b # 交互式对话，直接敲问题体验 ollama run deepseek-r1:7b第一条命令里deepseek-r1:7b是模型仓库的命名规则，冒号前是模型族，冒号后是规模标签；不带标签拉取会下载推荐版本。第二条命令进入交互式终端，适合快速验证模型能否正常输出中文、思考链有没有被触发。
但交互终端不是给程序用的，想接应用必须把服务跑起来：
ollama serve curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "为什么先思考再回答更不容易出错？"}], "temperature": 0.6, "stream": false }'ollama serve启动一个监听 11434 端口的本地服务，接口采用业界常见的 Chat Completions 格式，程序里只需要把 SDK 的 base_url 指向这里。temperature: 0.6是推理模型的保守起点；不设置时 Ollama 有自己的默认值，但推理任务不建议用默认的高随机配置。显存不足时 Ollama 会自动回退到 CPU 推理，速度会断崖式下跌，这坑留到第五章细说。
3.2 想要更低延迟和更细粒度的控制：换 llama.cpp 的 GGUF 路线
Ollama 的问题在于控制粒度不够：层数搬去 GPU 的比例、线程数、上下文长度都被封装了。当你发现显存利用不合理、想精确压榨单机性能时，常见做法是换 llama.cpp。它是 C/C++ 实现的推理框架，GGUF 是它的量化模型格式，对消费级显卡很友好：
llama-server \ -m DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf \ --n-gpu-layers 99 \ --ctx-size 8192 \ --temp 0.6 \ --port 8080-m指定 GGUF 模型文件路径，文件需要先从模型社区下载；--n-gpu-layers 99表示把模型层全部放进 GPU，显存不够就调小，让一部分层跑 CPU，术语叫 offload；--ctx-size 8192是上下文窗口长度，它直接决定 KV cache 占用，8K 是本地调试的安全起点；--temp 0.6是采样温度。启动后访问http://localhost:8080/v1/chat/completions，接口格式和 Ollama 一致。
和 Ollama 相比，llama.cpp 更适用于你明确知道自己要什么量化、要多少层 offload、需要多长上下文的情况。它的显存占用更透明，启动日志会直接打印模型加载占了多少、剩余多少，方便你逐项把参数顶到极限。代价是模型文件要自己下载、量化格式要自己认，上手成本高一些。
3.3 生产环境要吞吐：vLLM 才是 DeepSeek 的正确打开方式
请求并发一旦超过个位数，Ollama 和 llama.cpp 的调度能力就不够看了。vLLM 是当前主流的生产级推理引擎，核心优势是 PagedAttention 的 KV cache 管理加 continuous batching（连续批处理）——多个请求的动态步长被塞进同一个 batch，GPU 利用率能成倍提升。启动命令长这样：
vllm serve DeepSeek-R1-Distill-Qwen-32B \ --tensor-parallel-size 1 \ --max-model-len 16384 \ --gpu-memory-utilization 0.9 \ --port 8000--tensor-parallel-size 1表示单卡推理，模型超过单卡显存就改成 2 或 4，对应多卡张量并行；--max-model-len 16384限制上下文上限，注意 vLLM 启动时会按这个值预分配显存，设得过高会导致模型加载失败；--gpu-memory-utilization 0.9表示允许 vLLM 用到 90% 显存，剩下留给 CUDA context 等固定开销。启动成功会打印服务地址和模型名，请求时保持与注册名一致即可。
vLLM 对显存胃口很大，32B 模型在单张 24GB 卡上如果量化不足很容易 OOM。生产前务必把量化格式、--max-model-len和并发上限一起压测。我的习惯是先用 7B 模型把服务链路跑通，再换 32B 调显存参数，这样排查问题时有对照。
4. 应用优化：提示词、解码参数和思考链的调优组合
4.1 提示词设计：让 DeepSeek 稳定进入推理状态的三个句式
DeepSeek 的蒸馏小模型在闲聊场景下表现和普通模型差别不大，但一旦你明确要求「先推理再回答」，稳定性会有肉眼可见的提升。这是训练目标决定的：它对「推理过程 + 最终答案」的格式最敏感。我一般会在 system prompt 里放三件套：
句式一，过程可见：「请先输出你的推导过程，再给出最终结论，结论用『最终答案：』开头标记。」这句话直接触发思考链，并且把结论固定到可解析的位置，方便程序取用。句式二，角色约束：「你是资深算法工程师，回答要严谨，不确定时必须明说。」这类角色的价值是压低幻觉倾向。句式三，边界兜底：「如果信息不足，请列出还需要补充什么，不要猜测。」这一句对客服和文档问答场景尤其管用。
注意提示词语言要和输出语言一致。模型看到中文提示词才会倾向于用中文走完整个思考链，这个细节直接影响体验，后面避坑章节还会说。
4.2 解码参数：temperature、top_p 与 max_tokens 的真实配合
temperature 是推理模型里最值钱的旋钮。原版 R1 技术报告给出的建议是 temperature 0.6、top_p 0.95，这是官方评估后的最优区间。蒸馏小模型没那么娇气，但原理一致：temperature 低，采样趋近贪心，推理链稳定但容易重复；temperature 高，探索更多但也更容易走岔路。数学题、代码题这类有标准答案的任务，我一般用 0.2 到 0.4；开放性问题用 0.6 到 0.8。超出这个范围往上调，基本就是玄学碰运气了。
max_tokens 是第二个坑。推理模型要先写思考过程，同样的题长度可能是普通模型的三倍以上。很多人第一次接入时 max_tokens 还按以前的 512 或 1024 设，结果答案被腰斩。通用建议：复杂任务 4096 起步，长文档任务 8192。对接生产环境时，把思考过程和最终答案分开处理，答案部分单独设上限。
from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", # 本地 vLLM 或 Ollama 的服务地址 api_key="EMPTY" # 本地部署不需要真实密钥 ) response = client.chat.completions.create( model="DeepSeek-R1-Distill-Qwen-32B", messages=[ {"role": "system", "content": "请先分步推导，再用『最终答案：』标记结论。不确定时明确说不确定。"}, {"role": "user", "content": "某商店进了一批笔，进价每支 5 元，售价每支 8 元。卖出 60% 后按七折清仓，全部卖完共盈利 620 元。问一共进了多少支笔？"} ], temperature=0.3, top_p=0.9, max_tokens=4096 ) print(response.choices[0].message.content)这段代码里base_url指向本地服务，api_key用占位字符串即可；temperature=0.3适合数学这类确定性任务，top_p=0.9在采样时做概率截断兜底，max_tokens=4096给思考链留足空间。几个参数组合起来的效果是：推理过程稳定、结论不跑偏、长推导不截断。
这里还要提醒一点：本地服务返回的内容里，思考过程有时直接嵌在message.content里，有时单独放在扩展字段。产品层面要不要把思考过程展示给终端用户，需要你们自己拍板。我的做法是：思考过程写入审计日志，端到端用户只看到「最终答案：」之后的内容，避免过度暴露模型的内部推导引起信任问题。
4.3 三种场景的推荐参数对照表
| 场景 | temperature | top_p | max_tokens | 提示词要点 |
|---|---|---|---|---|
| 数学解题 | 0.2~0.4 | 0.9 | 4096 | 要求分步推导、写公式、最后验算 |
| 代码生成 | 0.4~0.6 | 0.95 | 4096~8192 | 先写思路和复杂度，再给实现代码 |
| 客服与文档问答 | 0.6~0.8 | 0.95 | 2048~4096 | 要求引用原文、不猜测、答案带依据 |
这张表是我在多种任务上随手可用的起始配置，不是银弹。每个场景微调 0.1 的 temperature、增减 1024 的 max_tokens，跑一批真实样本对比就能找到你自己的最优值。千万别照抄别人的数——模型版本不同、量化不同、提示词不同，最优参数都会漂。
5. 避坑指南：跑 DeepSeek 最常见的 4 个翻车现场与排查路径
以下问题全部来自真实使用经验，现象、原因、解决三步说透。遇到问题先对号入座，能少走很多弯路。
5.1 显存没爆，推理却慢成了「打字机」
现象：模型跑起来了，但每个字吐出要半秒，并发一多直接卡死。
原因：模型层没有完全加载进 GPU，一部分层在 CPU 上算；或者用 Ollama 时显存接近上限，触发了自动 CPU 回退。CPU 算大模型的延迟是 GPU 的几十倍，表现就是「一个字一个字蹦」。
解决：llama.cpp 把--n-gpu-layers调大，启动日志里会打印「offloaded X/XX layers to GPU」，确认全部层都进了 GPU；Ollama 用ollama ps查看当前模型的显存占用，关闭无关的常驻进程；如果显存确实不够，换更小的量化版本或更小规模模型，不要硬扛。
5.2 思考过程洋洋洒洒几百字，最终答案却被截断
现象：回答开头是「首先，我们设未知数 x…」，推导还没完就戛然而止，完全没有结论。
原因：max_tokens 不够，思考链把 token 预算全部吃光，模型还没写到「最终答案」就被强制停止。这是接入推理模型最常见的新手翻车点，因为以前用普通模型从不需要考虑「模型会自己写这么长的草稿」。
解决：把 max_tokens 提到 4096 甚至 8192；或者在提示词里主动约束「思考过程不超过 300 字，直接给出结论」。显存允许的话，加长上下文窗口比压缩输出质量更省事。
5.3 temperature 调高后，推理过程开始一本正经地胡扯
现象：同一个问题问两次，第二次给出了一个看起来很严谨、但完全经不起推敲的编造公式。
原因：temperature 过高导致采样随机性偏大，推理链上每一步的小偏差被逐步放大，最终产出幻觉。这事在推理模型上比普通模型更隐蔽，因为它输出的错误也被包装成「经过推导」的样子，用户更难识别。
解决：标准答案类任务 temperature 压到 0.3 以下；需要多样性的开放任务也不要超过 0.8；同时保持 top_p 0.9 左右兜底。永远不要让 temperature 和 top_p 两个随机旋钮同时开到最大。
5.4 蒸馏小模型中文答非所问，有时还中英混杂
现象：用户用中文提问，思考过程却是英文，最终答案半中半英，读起来非常别扭。
原因：蒸馏底座模型本身以英文语料为主，中文是被「教」出来的；当对话模板语言和提示词语言不一致时，模型容易切回高置信度的英文模式。
解决：在 system prompt 里明写「始终使用简体中文回复，包括完整的思考过程」；few-shot 示例也用中文写；如果仍然混杂，把 temperature 降到 0.3 以下，通常立刻见效。
5.5 并发一上来，首字延迟暴涨
现象：5 个并发时体验正常，20 个并发时每个请求都要等很久才出第一个字。
原因：Ollama 和 llama.cpp 的批处理能力弱，请求排队时间长；vLLM 如果--max-num-seqs与显存不匹配，也会频繁触发重新调度。
解决：高并发场景直接换 vLLM，不要在 Ollama 上死磕；vLLM 显存有富余时调大--max-num-seqs，显存吃紧时调低--max-model-len给 KV cache 腾空间。压测要用真实业务 prompt，不要用 Hello World 式的短文本测试，因为长上下文下的显存行为完全不同。
6. 进阶：用 LoRA 把 DeepSeek 调成领域专属推理模型
当提示词怎么压榨都达不到业务要求时，就该考虑微调了。对 DeepSeek 这类开源模型，LoRA 是性价比最高的微调方案：只训练一小部分低秩矩阵，显存占用量级可控，训练完就是一个几十到几百 MB 的增量权重文件。
6.1 准备带推理链的微调数据
微调数据要贴合 DeepSeek 的训练格式：一条样本包含用户问题、完整推理过程、最终答案三部分，而不是传统 SFT 那种「问题—答案」两句式。常见做法是先用高水平的模型当教师，在你自己的业务数据上批量生成推理链，再人工抽检修正。数据规模不需要很大，几千条高质量样本足够让一个小模型学会「你的领域该怎么思考」。
JSONL 数据格式大致长这样：字段包括指令、推理过程和答案，推理过程放在答案之前。加载数据时确认工具支持该字段映射，否则推理过程会被当成普通输出的一部分，训出来的模型不会「先说理再答题」。
6.2 训练命令与验证路径
用开源的微调工具跑 LoRA，命令行模式如下：
CUDA_VISIBLE_DEVICES=0 llamafactory-cli train \ --model_name_or_path DeepSeek-R1-Distill-Qwen-7B \ --stage sft \ --finetuning_type lora \ --dataset domain_cot \ --lora_rank 8 \ --lora_alpha 16 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --cutoff_len 2048--lora_rank 8控制低秩矩阵的维度，rank 越大可学习容量越大但过拟合风险也越高，8 到 16 是常见区间；--lora_alpha 16是缩放系数，一般设为 rank 的 1 到 2 倍；--learning_rate 2e-4是 LoRA 常见起点，比全量微调的 1e-5 高一两个数量级；--cutoff_len 2048决定单条样本最大长度，推理链长的任务要适当加大。训练完成后，把 LoRA 权重合并回基础模型导出，再做推理验证。
验证不要只看一两个样例，要留出测试集算 pass@1 或格式正确率。我的习惯是：微调前用同一批测试集先跑一遍基线，微调后对比提升幅度；同时人工检查输出里是否还保留了「推理过程 + 最终答案」的结构。如果结构丢了，多半是数据格式或模板没对齐，先修数据再调参数。
我自己在微调上吃过不少亏，最大的教训是：别一上来就微调。先用提示词把效果压到极限，再判断缺口到底在推理能力还是领域知识。很多场景下，一个写好的 system prompt 加几个 few-shot 示例，效果不比花几小时训出来的 LoRA 差。希望帮到你。
本文还有配套的精品资源，点击获取
