简介这份由清华大学新闻与传播学院新媒体研究中心团队编写的《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 总参数为什么推理只激活 37BDeepSeek 的主力大模型采用 MoEMixture of Experts混合专家结构。总参数高达几百亿甚至六百多亿但每一个 token 只会激活其中极小一部分专家。设计目的是把模型容量做大同时把单次推理的计算成本压下来。这里最常见的理解偏差是「只激活 37B那我 24GB 显存是不是就够了」不是。权重必须完整加载进显存激活参数只影响算力消耗不影响存储占用。MoE 省的是计算量不是显存。所以部署选型的核心动作是先把总权重显存算清楚。全量 FP16 权重按「参数量 × 2 字节」估算再留出 KV cache 和激活值的余量。一张 24GB 单卡能比较舒服跑的是 14B 量化版或 32B 高压缩量化版本地开发调试阶段我更推荐 7B 或 8B 的蒸馏小模型理由后面会说。为方便直观对照我按常见做法整理了选型参考模型规模权重大小估算可用部署方式建议场景1.5B~3BFP16 约 3~6GB纯 CPU 可跑低显存卡也行分类、抽取、函数调用7B~8B 蒸馏版FP16 约 14~16GBQ4 量化后 8GB 显存可跑开发调试、小并发服务14B~32BFP16 约 28~64GBQ4 量化后 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连续批处理——多个请求的动态步长被塞进同一个 batchGPU 利用率能成倍提升。启动命令长这样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_urlhttp://localhost:8000/v1, # 本地 vLLM 或 Ollama 的服务地址 api_keyEMPTY # 本地部署不需要真实密钥 ) response client.chat.completions.create( modelDeepSeek-R1-Distill-Qwen-32B, messages[ {role: system, content: 请先分步推导再用『最终答案』标记结论。不确定时明确说不确定。}, {role: user, content: 某商店进了一批笔进价每支 5 元售价每支 8 元。卖出 60% 后按七折清仓全部卖完共盈利 620 元。问一共进了多少支笔} ], temperature0.3, top_p0.9, max_tokens4096 ) print(response.choices[0].message.content)这段代码里base_url指向本地服务api_key用占位字符串即可temperature0.3适合数学这类确定性任务top_p0.9在采样时做概率截断兜底max_tokens4096给思考链留足空间。几个参数组合起来的效果是推理过程稳定、结论不跑偏、长推导不截断。这里还要提醒一点本地服务返回的内容里思考过程有时直接嵌在message.content里有时单独放在扩展字段。产品层面要不要把思考过程展示给终端用户需要你们自己拍板。我的做法是思考过程写入审计日志端到端用户只看到「最终答案」之后的内容避免过度暴露模型的内部推导引起信任问题。4.3 三种场景的推荐参数对照表场景temperaturetop_pmax_tokens提示词要点数学解题0.2~0.40.94096要求分步推导、写公式、最后验算代码生成0.4~0.60.954096~8192先写思路和复杂度再给实现代码客服与文档问答0.6~0.80.952048~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」确认全部层都进了 GPUOllama 用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_DEVICES0 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 权重合并回基础模型导出再做推理验证。验证不要只看一两个样例要留出测试集算 pass1 或格式正确率。我的习惯是微调前用同一批测试集先跑一遍基线微调后对比提升幅度同时人工检查输出里是否还保留了「推理过程 最终答案」的结构。如果结构丢了多半是数据格式或模板没对齐先修数据再调参数。我自己在微调上吃过不少亏最大的教训是别一上来就微调。先用提示词把效果压到极限再判断缺口到底在推理能力还是领域知识。很多场景下一个写好的 system prompt 加几个 few-shot 示例效果不比花几小时训出来的 LoRA 差。希望帮到你。本文还有配套的精品资源点击获取