简介《清华大学DeepSeek从入门到精通》是由清华大学新闻与传播学院团队整理的一份PDF资料目前已有396人学习全包仅1个PDF文件大小约5.37MB。文档以DeepSeek公司及其开源推理模型DeepSeek-R1为主线介绍这款国产免费推理模型在智能对话、文本生成、语义理解、代码生成补全等场景的应用能力并说明联网搜索、深度思考模式及上传图片与文件等实用功能。内容重点对比推理模型与通用模型在优势领域、运算原理、决策能力、人机互动等维度的差异帮助读者理解“快思慢想”的模型选择逻辑。同时结合数学证明、创意写作、代码生成等具体任务讲解指令驱动、需求导向、混合模式、启发式提问等提示语策略并给出有效提示与需避免策略的实例对照。读者可借此系统掌握国产AGI模型的应用方法学会按任务需求选择推理或通用模型从下达指令进阶到清晰表达需求适合有一定AI基础并希望深入实践的研究人员和技术爱好者。1. 国产大模型的研发与应用从「能用」到「用得值」的完整路径国产大模型的研发与应用现在最火的那条路已经不再是「更大的对话模型」而是把「思考过程」也训练出来的推理模型。A同学第一次在本地跑通量化版时说了句话让我印象很深它不像在回答问题像在自言自语地把题做出来。这正好点出了这类模型的本质——输出质量来自显式的思维链也来自强化学习带来的自我纠错而不仅仅是参数堆叠。这篇文章写给两类人一类要把模型接进业务系统的应用工程师一类想在私有数据上做微调的算法同学。读完你会清楚它是什么、怎么跑、微调该防哪些坑、以及最后怎么评估值不值得投入。2. 模型选型与架构底牌MoE、MLA 与思维链推理在本地怎么落地先把一个反直觉的结论放在前面这类开源推理模型研发侧的核心竞争力不是「比谁参数多」而是「让模型学会在给出答案前多思考一步」。这个能力来自训练管线里一个关键环节——用可验证的奖励比如数学题的最终答案是否正确做大规模强化学习模型在反复试错中学会了自我纠错。理解这一点你后面调参、微调、部署才会知道哪些开关能动、哪些不能动。2.1 先分清三件事推理模型、对话模型和蒸馏模型差在哪我接触过不少团队方案评审时把这三类模型混为一谈导致选型翻车。它们的训练管线、输出风格、适用场景完全不同先看一张对比表类型训练管线典型输出适合场景成本特征对话模型预训练 SFT 偏好对齐RLHF/DPO直接给出回答简短自然客服、闲聊、通用问答训练成本中等推理快推理模型预训练 SFT 大规模强化学习GRPO 等先输出思维链再给最终答案数学、代码、逻辑推理、复杂决策训练成本高推理 token 消耗大蒸馏模型用推理模型的输出做 SFT 数据训练小参数模型有时带短推理有时直接回答低成本场景、边缘部署训练便宜推理质量接近大模型但深度有限注意最后一行蒸馏模型不是「小号推理模型」。它是把大模型思考后的答案当作标准答案去模仿所以常见现象是——简单题很像样一到需要多步推理的难题就露馅。做技术选型时如果你的业务 80% 是短问题、短回答蒸馏模型性价比极高如果业务里全是长文档分析、复杂代码生成老老实实上满血推理模型。提示判断你手上的是哪一类最直接的办法是问一个需要多步推理的数学题看输出里有没有独立的思考过程。另一个容易忽略的点是 MoE混合专家架构。这类开源推理模型不少采用 MoE比如总参数 600B 级别、单次推理只激活 30B~40B 参数。这带来两个直接后果显存占用按总参数算推理速度按激活参数算。也就是说它跑起来比同等体量的稠密模型快不少但量化、切分时不能只盯着「激活参数」要按总参数规划显存。2.2 最小硬件方案用 Ollama 与 llama.cpp 跑通量化版的最小命令功能验证阶段我一般不建议直接上部署框架先用量化版把模型跑起来、把业务问题丢进去看看效果。8GB 显存的消费级显卡就能起步办法是选蒸馏版或小参数量化版。第一步用 Ollama 拉取并交互式运行# 拉取模型模型名以你所在开源仓库的 tag 为准 ollama pull 模型名 # 交互式运行进入后直接输入问题即可 ollama run 模型名这段命令背后的逻辑Ollama 会自动选择适合本机的量化等级并做显存管理对新手最友好。ollama pull是拉取权重ollama run是启动交互式对话。如果你在run之后发现显存不足优先换更小的量化版本而不是关机加硬件。第二步如果你需要更细的控制比如指定 GPU 层数、固定温度用 llama.cpp# -m 指定量化权重路径-ngl 99 表示把所有层都卸载到 GPU # -t 8 是线程数按 CPU 核心数调整--temp 0.6 是采样温度 llama-cli -m 量化模型路径 -ngl 99 -t 8 --temp 0.6-ngln-gpu-layers是 GPU 卸载层数99 表示全部放 GPU显存不够时往下降到 30~50让部分层跑在 CPU速度会慢一些但能跑通。--temp这里我直接给 0.6推理模型在低温下质量更稳原因后面避坑章会展开。跑通之后你做一件小事把平时最难的问题、最常见的业务问题各准备 5 个逐个问一遍。这一步不是测功能是建立「这个模型在我这个领域到底几斤几两」的基线印象后续所有优化都拿这个基线对比。2.3 从「能跑」到「跑好」量化等级、上下文长度与显存规划跑通之后紧接着的问题是「能不能跑得更多、跑得更长」。这里先给显存估算的经验公式再解释为什么推理模型比对话模型更吃上下文预算。显存的大头有四块模型权重、KV cache、激活值、中间缓冲。简化估算就看权重大小和 KV cache模型规模参考Q4_K_M 量化约需显存FP16/BF16 约需显存建议运行方式7B~8B 级5~6 GB15~16 GB消费级显卡可跑量化版14B 级9~10 GB28~30 GB量化版适合 16G 显存30B~32B 级18~20 GB60~65 GB需要多卡或大显存600B 级 MoE350~400 GB 起步1T必须多卡分布式或 API 调用对推理模型来说KV cache 的压力比对话模型大得多。原因很直白一个 1000 token 的思维链KV cache 要随序列长度线性增长如果业务里每个请求都带长上下文KV cache 会反超权重成为显存第一大户。缓解办法里有三个方向值得注意。一是量化等级Q4_K_M 日常够用Q5_K_M 质量更稳Q8_0 接近原始精度但显存涨得快按实际效果选别盲目上高精度。二是上下文长度别把max-length设成模型上限设成「你业务里最长输入 最长思维链的 1.5 倍」就够了多余的部分纯耗显存。三是架构红利这类开源推理模型不少用了 MLA多头潜在注意力它能把 KV cache 压缩一个量级同样上下文下显存远小于传统 Transformer这也是它能在消费级显卡上跑长上下文的原因之一。我一般会先拿小参数蒸馏版把完整业务流程跑通确认「模型效果本身过关」之后再评估要不要上更大规模。跳过这一步直接追求满血大模型很容易陷入「显存不够、量化太狠、效果反而变差」的循环。3. 用 vLLM 把模型部署成服务生产级推理的三件套配置本地跑通只是热身生产环境要面对的是并发、长连接、多用户。我常用的部署路径是用 vLLM 把权重加载成服务暴露标准聊天补全接口然后由业务侧统一接入。这一章讲为什么选它以及三个必调参数怎么设。3.1 为什么生产环境选 vLLM连续批处理与分页注意力推理模型有一个特点每个请求的思维链长度差异极大。简单请求 200 token复杂请求可能 5000 token。这种「长短混杂」的负载对推理框架的调度能力要求很高。vLLM 解决这个问题的核心是连续批处理continuous batching。传统批处理要等一批请求全部完成后一起返回慢的那一个拖死整批连续批处理是每个请求完成后立刻让出资源下一个请求无缝补上。配合分页注意力PagedAttentionKV cache 像内存分页一样按需分配显存碎片大幅减少。实测下来在长短请求混合的业务负载里吞吐量比朴素实现高出一截。另外我前面提到 MLA 对 KV cache 的压缩在生产环境还有一个隐藏红利KV cache 占用变小意味着单卡能同时容纳更多并发请求这对成本的影响比模型权重量化更明显。如果你的业务场景是几千个用户在线提问KV cache 优化带来的收益通常比换一张更大的卡更划算。3.2 最小部署命令加载开源权重并暴露标准接口假设你已经把权重下载到本地目录部署一条命令就能启动# 启动一个 OpenAI 兼容的 API 服务端口默认 8000 python -m vllm.entrypoints.openai.api_server \ --model 权重目录路径 \ --served-model-name my-server \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --enable-thinking \ --reasoning-parser 按模型系列选择 \ --gpu-memory-utilization 0.90 \ --port 8000参数含义按重要程度说明--model权重目录路径vLLM 会自动识别目录里的配置文件。如果是从开源模型仓库下载的原始权重启动前确认目录里包含必要的模型配置文件。--served-model-name对外暴露的模型名调用方实际请求时用这个名字。起一个业务相关的名字方便后续做模型灰度切换。--tensor-parallel-size张量并行度单卡填 1两张卡填 2。它会把模型按层切到多卡上显存翻倍但通信开销也涨能用单卡就不用多卡。--enable-thinking开启思维链支持。这一步很关键不开的话模型可能不输出独立的思考过程推理质量直接打折。--reasoning-parser按模型系列选择对应的解析器把「思考过程」和「最终回答」拆成两个字段。不同模型模板不一样选错会解析不到内容。--gpu-memory-utilizationGPU 显存使用率上限0.90 是保守值给后续请求留缓冲。启动完成后用一条 curl 验证服务是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: my-server, messages: [{role: user, content: 两个质数的和是20乘积是91求这两个质数。}], temperature: 0.6, max_tokens: 2048 }返回的 JSON 里通常会有两个内容字段一个装思考过程reasoning 相关字段一个装最终回答。生产接入时思考过程只做日志分析不要直接上屏更不要把它当成最终答案返回给用户。3.3 生产必调的三个参数max-model-len、tensor-parallel-size 与 gpu-memory-utilization很多团队部署完「能出结果」就上线了结果业务一上量就开始报错十有八九是这三个参数没调对。第一个是max-model-len。它决定模型能接受的最大序列长度提示词 思维链 最终答案。默认值往往偏小推理模型的思维链动不动几千 token截断了就是「只见思考不见答案」。我一般的做法是拿业务里最长的样本实测记录完整输出需要多少 token然后乘 1.5 倍留余量。比如你的业务最长完整输出是 5000 tokenmax-model-len设 8192 合适但如果你设成 32768单请求显存占用会显著上升并发能力跟着下降。第二个是tensor-parallel-size。它的选择逻辑很简单权重 KV cache 在单卡放不下时才从 1 往上加。两块卡选 2四块卡可以选 4但要注意多卡间的通信会成为新瓶颈。小模型强行多卡切分速度不升反降这是常见误用。第三个是gpu-memory-utilization。我建议的区间是 0.85~0.92低于 0.85显存利用率太低白花钱高于 0.92遇到突发长请求很容易 OOM。0.90 是个稳妥起点压测后再微调。提示如果你确认业务不需要思考过程不要用改温度的方式去「屏蔽思考」正确做法是切换成不输出思维链的对话模型或按模型模板走关闭推理的接口。三个参数调完之后做一轮压测并发 10 个请求混合长短问题盯住两个指标——端到端延迟和显存峰值。压测过了再谈上线这一步省不掉。4. 微调与对齐用 LLaMA-Factory 做增量训练数据配比是玄学研发侧的高频诉求是用私有数据让模型「更懂自己的业务」。但推理模型的微调和对话模型不一样最大的区别在于你不仅要教它「答案是什么」还要保证它「思考过程不乱」。这一章讲 LoRA 与全量微调的选型、一份能跑通的配置以及对齐阶段的三个隐蔽陷阱。4.1 选 LoRA 还是全量微调显存清单与恢复成本我的建议很直接没有多卡集群的团队别碰全量微调。先看显存量级再决定微调方式7B~8B 级显存14B 级显存30B 级显存恢复成本LoRArank 3212~16 GB24~32 GB48~64 GB低只存适配器权重QLoRA4bit 基座6~10 GB12~20 GB24~40 GB低只存适配器权重全量微调BF1630~40 GB60~80 GB120 GB高保留全量权重快照LoRA 的原理是冻结原模型权重只训练一小部分低秩适配矩阵显存占用小、训练快而且「后悔药」便宜——原权重没动过删掉适配器就是原模型。QLoRA 在 LoRA 基础上把基座模型量化到 4bit显存门槛更低但我建议你有条件还是优先 LoRA量化基座在训练中偶尔会引入精度抖动。对推理模型做微调LoRA rank 不要太小。rank 16 适合风格类任务rank 32 是复杂任务的起点rank 64 适合数据量大、任务难的情况。rank 越高可学习的参数量越大但过拟合风险和显存占用也同步上升。4.2 一份能跑通的 LoRA 训练配置从 yaml 到命令我用 LLaMA-Factory 的场景最多它的配置文件是 YAML 格式可读性好也方便团队内部流传。先看一个能直接改路径就跑的配置# lora_sft.yaml推理模型的 LoRA 增量训练配置 model_name_or_path: /path/to/base-model # 基座模型路径 stage: sft # 训练阶段SFT finetuning_type: lora # 微调方式LoRA lora_rank: 32 # 低秩矩阵的秩 lora_alpha: 64 # LoRA 缩放系数 dataset: business_sft_data # 数据集名称对应 data 配置 template: 按模型系列选择模板 # chat template 类型 cutoff_len: 4096 # 单样本最大长度 learning_rate: 5.0e-5 # 学习率 num_train_epochs: 3.0 # 训练轮数 per_device_train_batch_size: 1 # 单卡 batch gradient_accumulation_steps: 8 # 梯度累积步数 bf16: true # BF16 混合精度 output_dir: outputs/lora-business # 输出目录几个关键参数展开说lora_rank和lora_alphaalpha 一般设为 rank 的 2 倍即 32 配 64。alpha/rank 的比值影响 LoRA 的更新幅度比值越大微调对原模型的影响越强。cutoff_len必须大于「提示词 思维链 最终答案」的总长度。推理模型的训练样本天然比对话模型长4096 是起点如果样本里大量出现截断要往上调。template必须和基座模型对应的 chat template 一致选错会导致训练时格式错乱。learning_rate推理模型微调推荐 2e-5~5e-5比对话模型的常见区间1e-4~5e-4低一个量级原因后面讲。gradient_accumulation_steps8 意味着每 8 个 batch 更新一次参数等效 batch size 是1 × 8 8兼顾显存和训练稳定性。启动训练只需要一条命令llamafactory-cli train configs/lora_sft.yaml训练数据用 Alpaca 格式即可每行一个 JSON 对象关键是 output 字段里必须包含完整思考过程和最终答案{ instruction: 分析以下合同条款中关于违约金的约定是否合理并给出修改建议。, input: 合同条款乙方逾期交付的每日按合同总金额的0.5%支付违约金。, output: 思考过程违约金比例是否过高根据行业惯例每日0.5%的年化超过180%明显偏高。需要结合合同总金额和违约后果判断。/思考过程最终答案该条款违约金计算标准过高建议调整为每日0.05%并增加违约金总额上限。 }注意 output 里的思考过程和最终答案要用你所用模型模板对应的特殊标记包住。不同模型系列的标记不一样以你下载权重时附带的模板为准。数据里最怕的一件事是有的样本带思考过程有的不带模型会学着混乱。4.3 推理模型微调的三个对齐陷阱数据配比、学习率与格式一致性微调跑通只是开始效果能不能立住才是关键。我在这部分吃过亏直接说结论。第一是数据配比。只用业务数据微调模型会「偏科」——业务能力上去通用能力垮掉数学和代码能力尤其明显。我常用的配比是领域业务数据 60%~70%通用推理数据 20%~30%通用对话数据 10%。这 10% 的通用对话数据看着不起眼作用是拉住模型原有的对话能力和世界知识防止灾难性遗忘。第二是学习率。推理模型经过大规模强化学习之后参数分布和普通对话模型不一样微调时对扰动更敏感。学习率 1e-4 用在对话模型上正常用在推理模型上可能直接毁掉它的思考能力。2e-5~5e-5 是保守区间如果训完发现模型「变傻」先把学习率降一个量级重试而不是加轮数。第三是格式一致性。训练样本里思维链和最终答案的格式必须完全统一统一用相同的标记包裹、统一不要有多余的 Markdown 标题、统一 JSON 输出的结构。推理模型的输出格式是靠 SFT 数据教出来的数据格式一乱模型生成时就会「时而思考、时而不思考」生产环境接这种模型非常痛苦。提示正式训练前先拿 20~50 条样本跑一轮过拟合确认模型能记住这批数据再上全量数据。这一步能筛掉大部分数据问题省下的时间远超付出。5. 避坑从入门到翻车之间最常见的 5 个坑这一章全部是血泪经验。每一条都是我在实际项目里见过或自己踩过的真实问题按「现象 → 原因 → 解决」结构写方便你对照排查。5.1 思维链被截断max_tokens 设置导致答案丢失现象模型输出一段思考过程后戛然而止没有最终答案或者最终答案刚开头就被切断。原因推理模型的思维链占 token 量远超预期。一个数学题可能只写 2 行最终答案思考过程却要 1500 token。客户端或服务端把max_tokens设成 512 或 1024思维链就把预算吃光了。解决把max_tokens提到 2048 起步复杂任务按最长样本实测结果再往上翻倍同时把max-model-len设到对应长度保证模型「有能力生成长输出」。判断是不是这个问题看返回里的finish_reason如果是length就说明是被截断的。5.2 JSON 解析崩溃思维链里混进了答案结构现象模型按要求输出 JSON但解析时报错打开原文发现思考过程里出现了一模一样的 JSON 样例程序把思考过程里的 JSON 当成最终结果解析了。原因思维链是模型「自言自语」的过程里面会包含对任务的理解、可能的输出结构草稿。如果任务要求输出 JSON思维链里大概率会出现 JSON 片段而后处理的解析器取到了错误的一段。解决两层保险。第一层在 prompt 里明确要求「最终答案单独放在最后一个代码块中」第二层解析时取最后一个代码块而不是第一个import re, json def extract_last_json(response_text: str) - dict: # 只找最后一个 json 代码块思维链里的草稿样例会被跳过 matches list(re.finditer(rjson\s*(.*?)\s*, response_text, re.S)) if not matches: raise ValueError(没有找到 JSON 代码块) return json.loads(matches[-1].group(1))逻辑说明re.finditer找到全部 JSON 代码块matches[-1]取最后一个。思维链通常在输出前面最终答案在后面取最后一个代码块是兼顾鲁棒性和实现简单度的做法。如果模型没有按代码块格式输出再退一步用「找最后一个匹配花括号」的方式兜底。5.3 采样参数照搬对话模型高温导致推理质量崩坏现象同一个问题temperature 设 1.0 时答案明显变差甚至出现逻辑断裂设 0.6 时稳定且准确。原因推理模型在训练时使用的采样策略偏低温模型学到的「解题风格」本身就比较确定。温度升高后每一步思考的概率分布变平坦模型更容易跳到不相关的方向思维链越长错误越容易累积。解决推理模型的 temperature 设在 0.5~0.7 区间我常用 0.6。想获得多个候选答案时不要靠升温度而是固定低温跑多次采样取最优结果或者用n参数请求多个回复效果远好于高温单次生成。5.4 微调后能力雪崩数学和代码能力明显变差现象LoRA 微调完业务任务效果不错但让模型做一道简单的数学题开始胡说代码生成也出现低级语法错误。原因典型的灾难性遗忘。训练数据里业务样本占比过高、学习率过大、LoRA rank 过高三者任一都会破坏基座模型原有的推理能力。推理模型比对话模型更容易出现这个问题因为它的能力高度依赖强化学习阶段建立的精细参数分布普通量级的扰动就会被放大。解决按 4.3 节的数据配比重做数据业务数据控制在 70% 以内保留通用推理数据学习率先降到 2e-5 试跑LoRA rank 不超过 64。训练后立刻回归测试用一组固定的数学题和代码题对比微调前后的准确率指标不下滑再谈上线。5.5 评测分数和手动体验对不上模板与采样参数不一致现象模型在评测集上分数很高实际业务里表现平平或者反过来业务里感觉不错评测分数难看。原因评测和业务用的是两套 prompt 模板和采样参数。评测时带了「lets think step by step」之类的引导而业务侧没带或者评测用 temperature 0.2、业务用 temperature 0.8。推理模型对 prompt 模板和参数极其敏感模板一变思维链的长度和结构都跟着变。解决评测环境与生产环境保持同一套配置。我在项目里的做法是写一份评估脚本固定模板、固定 temperature0.6、固定max_tokens生产环境的调用参数直接从这份配置里读取而不是各写一份。评测命令用同一份基准# 用生产同款 vLLM 服务和同款模板跑评测集 lm_eval --model vllm \ --model_args pretrained模型路径,tensor_parallel_size1 \ --tasks math_500 \ --batch_size auto命令说明--model vllm让评测走线上同款推理引擎--tasks指定评测任务集--batch_size auto让框架根据显存自动决定并发数。重点是「生产用什么评测就用什么」。6. 把推理能力接进业务系统JSON 输出、流式返回与成本控制最后一章给三个马上能用的技巧都是我反复用过的方案。第一个技巧JSON 输出用「先围栏后解析」。推理模型的思维链不可控直接让它「输出 JSON」风险很高。我习惯让最终答案以json代码块收尾再用 5.2 节的extract_last_json取最后一段这样无论思维链里出现什么结构的草稿都不会污染解析结果。第二个技巧流式返回时把思考过程和最终答案分流。推理模型的思考过程可能长达几千 token让用户盯着「正在思考」的文本体验很差而且泄露给用户还可能引发误解。正确做法思考过程进日志最终答案上屏。import requests, json, sys payload { model: my-server, messages: [{role: user, content: 解释一下什么是梯度消失并给出缓解方法。}], temperature: 0.6, max_tokens: 2048, stream: True } resp requests.post( http://localhost:8000/v1/chat/completions, jsonpayload, streamTrue ) answer_buffer [] for line in resp.iter_lines(): if not line or not line.startswith(bdata: ): continue chunk json.loads(line[6:]) delta chunk[choices][0][delta] # reasoning 字段打日志不直接输出 if reasoning in delta and delta[reasoning]: sys.stderr.write(delta[reasoning]) # content 字段是最终答案累积后上屏 if content in delta and delta[content]: answer_buffer.append(delta[content]) final_answer .join(answer_buffer)代码逻辑按 SSE 协议逐行解析返回流delta.reasoning里的思考内容写入 stderr 做日志追踪delta.content里的最终答案累积后交给业务展示。这样做既保留调试能力又不会让用户被思维链刷屏。第三个技巧成本控制做级联路由。满血推理模型每 token 的成本和延迟都高而业务流量里往往大量请求是简单问题用不上满血推理。我的做法是在入口加一道路由简单问题走小参数蒸馏模型复杂问题才转发给满血模型。方案单请求成本平均延迟复杂任务质量适用场景全量走满血推理模型高高高复杂任务占比高全量走蒸馏小模型低低中低简单任务占比极高级联路由简单走小模型复杂走满血中中高复杂任务占比 20%~40%路由的判定逻辑不用很复杂按问题长度和关键词规则先分一层拿不准的再让大模型处理。上线后持续统计「小模型答错的请求占比」如果超过 5%把更多请求转给满血模型。这套方案能让硬件成本直接砍半同时保住复杂任务的质量底线。有一回我为图省事把推理模型当对话模型用temperature 拉到 1.2 想多采样几个不同风格的结果结果模型半天回不到正题上白白浪费了一个下午定位问题。从那以后我养成一个习惯先跑默认参数保基线再一个变量一个变量地动每次改动都留一份对照记录绝不多个变量一起调。这个习惯帮我避开了后面无数个隐形坑希望也能帮到你。本文还有配套的精品资源点击获取