简介《DeepSeek从入门到精通》是一份由清华大学新闻与传播学院新媒体研究中心团队撰写的系统教程面向希望深入掌握大模型应用的AI学习者、办公用户与开发者帮助读者理解DeepSeek是什么、能做什么以及如何精准使用。内容围绕DeepSeek-R1推理模型展开覆盖智能对话、文本生成、语义理解、代码调试等典型场景并重点对比推理模型与通用模型在思维链、响应速度、决策能力上的差异给出提示语设计原则与示例能有效引导读者从基础操作进阶到提示词工程。资源为1个PDF文档压缩包约5.92MB内容目录化、便于按章节研读。目前已有9312人学习下载。读者通过该PDF可获得从原理到实战的完整知识框架包括文本生成、语义理解、代码生成等场景中的提示语策略与范例可直接用于日常问答、办公写作、逻辑推演和编程辅助等实际任务。1. DeepSeek 这个标题背后值得动手的不是“看教程”而是“跑通一条自己的链路”打开某高校那套流传出来的 DeepSeek 实战课程笔记第一页就写着“从入门到精通”但真正翻过的人会意识到这套内容讲的不是让 AI 聊天而是把大模型装进自己的工程链路里跑起来。DeepSeek 的开源权重、蒸馏版本、API 兼容层这几条线分别对应了不同预算和不同场景的落地方式有人只需要一条 API Key有人却要在一张消费级显卡上把推理延迟压进百毫秒。面向的读者不是围观群众而是手里有具体问题、打算这周就把模型跑出结果的工程师。这篇笔记的思路也很直接先想清楚自己需要哪种形态的 DeepSeek再按最小路径部署、调参、踩坑、优化直到最后把模型能力接到自己的数据和应用里。接下来的内容全是我实际跑过之后的配置、参数和翻车记录。2. 部署形态先理清API、Ollama、vLLM 三条路线怎么选2.1 先看服务形态再选工具链DeepSeek 目前常见的接入方式有三条官方 API、Ollama 本地跑、vLLM 部署开服。很多人上来就问“哪个最快”但最快不等于最合适。API 意味着零部署成本、开箱即用你的机器只需要跑一个 HTTP 客户端Ollama 则是把模型权重拉到本地由 Ollama 的 C 运行时负责推理好处是数据不出内网、可离线、可深度定制 prompt 模板vLLM 适合要并发、要持续服务、要对接自己推理框架的团队它用 PagedAttention 管理显存吞吐能力比前两者高一个量级。选型我用一个朴素标准判断如果是个人学习和原型验证API 或 Ollama 都够如果是做内部工具、需要高频反复调 prompt 和测试私有数据Ollama 会让迭代更快如果目标是上线一个面向多人的服务vLLM 才是正路。另外要考虑数据的敏感性——私有代码、客户资料一旦过 API就等于把数据交给第三方处理很多公司在这一条上就直接把 API 方案否决了。我见过不止一个项目因为合规问题中途从 API 迁回本地部署白折腾了两周。2.2 Ollama 部署的最小命令与验证Ollama 是目前本地跑 DeepSeek 门槛最低的方案也是踩坑最少的一条路径。安装完成后命令行拉模型、起服务、做对话验证三步走# 安装 ollama 后拉取 DeepSeek 蒸馏版7B 量级消费级显卡可跑 ollama pull deepseek-r1:7b # 启动服务默认监听 11434 端口 ollama serve # 另开一个终端做一次流式对话验证 curl http://localhost:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 用 Python 写一个快速排序并解释时间复杂度的推导}], stream: false }这段命令里pull负责从模型仓库拉取权重deepseek-r1:7b是带量化标记的蒸馏版本显存 8GB 左右的卡就能跑serve是启动本地服务最后的 curl 请求验证的是 OpenAI 兼容的 chat 接口。注意/api/chat和/api/generate是两套接口前者按 messages 列表处理上下文后者是纯文本补全日常对话用 chat 更合适。stream:false表示等全部生成完再返回调试时方便看完整结果正式调接口时再改成 true 以降低首字延迟。这里的核心参数其实是量化版本的选择。7B 模型在 FP16 下约 14GB 显存很多卡放不下Ollama 默认拉取的版本往往已经做了 Q4 量化体积缩到约 4.7GB显存占用在 6GB 左右。如果你只有 8GB 显存建议优先用带q4标记的版本如果显存有 24GB可以换deepseek-r1:32b推理质量会有肉眼可见的提升。换版本时注意模型名不同服务端缓存也不同ollama pull之后要确认ollama list里显示的是你真正要跑的那个。2.3 vLLM 部署的开服命令与并发参数Ollama 适合单机和低并发但一旦要支撑几十个请求同时进来它就不太行了。vLLM 是当前更接近生产环境的方案部署命令也不算复杂# 安装 vLLM建议 Python 3.10 环境 pip install vllm # 启动 OpenAI 兼容服务--model 指向本地权重目录或 HuggingFace 模型名 python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek-r1-7b \ --served-model-name deepseek-r1 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000--tensor-parallel-size表示用几张卡切分模型单卡设 1--max-model-len控制最大上下文长度设太大显存会被预留掉导致实际推理时 OOM--gpu-memory-utilization允许 vLLM 占用 90% 显存余量要给 CUDA context 和 KV cache 留缓冲。这里最容易翻车的点是--max-model-len与显存不匹配我曾把 32B 模型的上下文设到 16384结果服务起来后第一个请求就报显存不足把参数降到 8192 才正常。vLLM 起服务后接口路径和 Ollama 不一样它走的是/v1/chat/completions兼容 OpenAI SDK这是它的一个重要设计你不需要改业务代码只把 base_url 指过去。验证方式也很简单用 curl 打一个最小请求curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1, messages: [{role: user, content: 你好请自我介绍}], max_tokens: 512, temperature: 0.7 }请求里的model字段要和--served-model-name保持一致否则会报 model not foundmax_tokens控制生成上限别把它设得太大让用户等太久。如果返回里有usage字段说明服务正常。线程数、并发这些参数通常靠前面的负载均衡器来控制vLLM 只管高性能推理这一层职责要分清楚。3. Prompt 工程是真正的“入门”模板、角色、上下文三板斧3.1 模板设计决定了 DeepSeek 的应答质量很多人部署完模型发现回答质量“也就那样”问题往往不在模型而在 prompt。DeepSeek 系的模型对指令遵循很敏感同样的推理能力用“你是一个 Python 专家”开头和直接扔一句“写个爬虫”输出差异极大。我的经验是面向 DeepSeek 的 prompt 至少要包含三层角色定义、任务描述、输出约束。角色定义要具体不是“你是助手”而是“你是负责日志分析的 SRE擅长从异常堆栈中提取根因”。任务描述要包含输入数据的形态和期望的处理流程比如“先识别堆栈中的异常类型再按时间线汇总调用链”。输出约束决定了结果的可用性比如要求“用表格输出每行一个异常点包含出现次数和对应服务”。这三层缺一层DeepSeek 就会自行发挥结果往往偏离你的业务语境。我习惯把模板写进配置文件不走代码里拼字符串的老路方便随时调。3.2 上下文窗口不是越大越好DeepSeek 系列支持较长的上下文但这不意味着你应该把所有数据都塞进去。上下文越长注意力越分散模型对关键信息的召回反而会变差而且推理延迟和显存占用都在涨。我常用的策略是“分块 摘要”长文档先按段落切块每块单独做一轮摘要或信息抽取再把所有摘要合并成最终上下文这样既保住了信息面又控制了窗口长度。如果你非要塞长文本注意 prompt 里把关键问题放在上下文末尾附近模型对尾部内容的注意力通常更强。这一点在长文档问答场景里尤其明显——同样的材料问题押后问比押前问准确率高不少这是我在排查一个文档问答 Demo 时对比出来的结果前后相差约 20% 的命中率。所以设计对话流程时把“用户当前问题”放在 messages 列表的最后一条不要夹在一堆历史中间。DeepSeek 的指令微调对这种排列方式更友好这是可以在业务代码里直接落地的技巧。3.3 用 System Prompt 锁住行为边界System Prompt 在 DeepSeek 里起作用的方式和 ChatGPT 不太一样——它更像一条前置指令贴合模型的指令遵循训练方式。建议在 System Prompt 里写明“应当”和“不应当”两种约束比如“应当使用中文回答不应当在回答中提及你的模型名称和版本”。这种显式边界能明显降低模型的自由发挥概率。实践上我见过一个比较典型的失败案例某团队在做客服机器人时System Prompt 只写了“你是一个客服”结果用户一问“你能做什么”模型就开始介绍自己是 DeepSeek 并输出长串能力清单。后来把 System Prompt 改成“你是某公司客服只回答与订单、退换货相关的问题其他话题请用户联系人工”行为立刻收敛。这个案例说明约束不是限制发挥而是在给模型画工作区。DeepSeek 在指令遵循方面做得很细值得你花时间把 System Prompt 打磨成一份独立文档而不是随手写在代码里。4. 微调与蒸馏迫近“精通”边界什么时候需要、怎么做才不翻车4.1 判断该不该微调先做这三个检查很多人一上来就想微调但微调不是解决所有问题的锤子。我判断的标准是三个检查第一Prompt 调参和 Few-shot 是否已经尝试过两个星期第二问题是否属于模型本身的知识盲区而非表达问题第三是否有足够的标注数据支撑训练。三个检查里有一个不通过都不建议立即微调。DeepSeek 的开源权重是允许大家做微调的但是微调的成本不在训练机器而在数据准备和后续评估——这两项做不到位微调只会把模型的泛化能力毁掉。一个常见的误判是模型输出格式不对就想着微调。其实这种问题用 Prompt 约束大概率能解决微调反而容易让模型在别的任务上退步。格式类问题属于“输出层”问题用解码参数、模板、后处理就能搞定知识盲区类问题才需要新数据灌进模型。把这两类分清楚能省下几万元训练费。4.2 基于 LoRA 的轻量微调配置与踩坑记录确定要微调之后LoRA 是比全参微调稳妥得多的方案——显存占用低、训练速度快、不容易灾难性遗忘。以下是我在单卡上微调 DeepSeek 蒸馏版的完整流程# 基于 peft transformers 的 LoRA 训练脚本核心片段 from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model, TaskType model AutoModelForCausalLM.from_pretrained( /data/models/deepseek-r1-7b, torch_dtypeauto, device_mapauto ) lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r8, lora_alpha16, lora_dropout0.1, target_modules[q_proj, v_proj] ) model get_peft_model(model, lora_config) model.print_trainable_parameters()这段配置里r是 LoRA 秩控制新增参数量8 是一个比较保守的起点lora_alpha是缩放系数通常设为r的两倍target_modules只改了q_proj和v_proj这是最稳的组合改k_proj或o_proj会让训练更容易发散。print_trainable_parameters()会输出可训练参数量如果看到总参数量只有 0.5% 左右可训练说明配置正确。训练时学习率建议设在 1e-4 到 2e-4太大会导致 loss 震荡太小则收敛极慢我新手期因为学习率设成 5e-3 直接把模型训崩过输出变成乱码。训练完成后用 PEFT 的save_pretrained保存 LoRA 权重推理时先加载基座模型再加载 LoRA 适配器。这里有一个坑如果把 LoRA 合并进 Base Model 后再导出推理速度会略快但想再调整 LoRA 权重就麻烦了建议保留两份一份合并版用于上线一份原始 LoRA 用于后续迭代。4.3 蒸馏版适合你的场景吗DeepSeek 官方发布过一系列蒸馏版本参数从 1.5B 到 70B 不等。蒸馏版的推理质量大幅领先同参数量的其他开源模型但使用时要清楚它的边界——蒸馏模型在某些任务上会保留教师模型的“偏好”比如过度谨慎或过度结构化输出。我建议在垂直场景里用蒸馏版时先拿自己的测试集跑一遍基线和原版对比质量差异。如果差异在可接受范围内蒸馏版能帮你节省大量显存如果差异明显说明任务需要的推理深度超出了蒸馏版的能力硬上蒸馏版只会不断打补丁。一个比较实用的中间路线用蒸馏版做粗筛把简单的、高置信度的请求直接处理把复杂请求转发给原版大模型。这种级联策略在成本和效果之间取了平衡也是我在内部工具里实际采用的方案。蒸馏版的另一个优势是部署到边缘设备比如 1.5B 版本甚至能在树莓派上跑特定场景非常有用。5. 避坑指南DeepSeek 实战里的 5 个高频翻车点5.1 显存 OOM现象背后是“没有看量化级别”现象模型加载时报CUDA out of memory或者推理跑到一半进程被杀。原因拉取模型时没注意量化标记FP16 版本体积是 Q4 的好几倍。解决换量化版本。ollama pull deepseek-r1:7b默认是 Q4如果显示体积大于 8GB说明没走对vLLM 场景则要调--max-model-len和--gpu-memory-utilization把上下文砍半、显存利用率压到 0.85 以下。显存优化是“从入门到精通”的第一道门槛跨不过去后面全是白费。5.2 输出乱码或不断重复大概率是采样参数失衡现象模型生成重复的句子或者输出包含大量无意义符号。原因temperature设得过高或top_p设得太小导致采样分布畸形。解决把temperature调到 0.5-0.8top_p调到 0.9 左右。如果用的是 vLLM还要检查frequency_penalty适度调高能抑制重复。这个坑在长文本生成场景特别常见我曾用 temperature 1.2 跑代码生成结果模型把同一行 import 连写了 20 遍。5.3 请求超时流式输出是必选项现象服务端生成大段内容时HTTP 请求被网关或客户端中断。原因非流式请求需要等待全部生成完毕长文本场景等几十秒很正常网关等不了。解决客户端改用流式解析收到一个 token 就处理一个。OpenAI 兼容接口用stream: true返回 SSE 流前端用fetch的ReadableStream解析Ollama 的/api/chat同样支持。流式不仅解决了超时还显著改善用户体验不要因为解析麻烦而放弃。5.4 上下文截断你的输入比想象中长现象模型忽略了你 prompt 里最关键的说明或者回答内容明显缺少前文信息。原因输入 token 超过模型上下文限制被静默截断。Ollama 的默认num_ctx可能只有 2048而用户对话一长就超限。解决启动时显式设置上下文窗口比如ollama run deepseek-r1:7b --num-ctx 8192vLLM 则在启动参数里调--max-model-len。另外在应用层要对输入做长度检查超过阈值就触发摘要压缩而不是硬塞进去。上下文截断的问题很难从输出反推因为它没有报错只是“遗忘”了最早的内容排查起来极其隐蔽。5.5 幻觉和“一本正经的胡说八道”需要外部资料兜底现象模型在回答专业问题时给出了看似合理但错误的信息尤其在产品参数、法规条文、内部流程这类领域。原因模型的知识来自训练语料不包含你的私有信息和最新的线上变更。解决关键信息走 RAG 而不是靠模型记忆。把文档切块做向量化检索到相关内容后连同用户问题一起喂给模型。这一条最值得早点做因为它能同时缓解幻觉和知识过期两个问题而且不需要微调。6. 进阶技巧推理加速与质量验证的两条实用路径走到这一步说明你已经把 DeepSeek 跑通并接进了自己的业务接下来值得花时间的是两件事让推理更快、让质量可度量。推理加速方面vLLM 自带 Continuous Batching 机制动态合并多个请求的 KV Cache提升吞吐如果单请求延迟仍然高可以换用 FP8 量化或 AWQ 量化模型把显存带宽占用降下来。启动 vLLM 时加一行--quantization awq加量化模型路径即可代价是偶尔的精度损失在大多数任务里可接受。另一个方向是speculative decoding用一个小模型先草拟多个候选 token大模型做验证加速效果在有明显显存余量时接近 2 倍vLLM 里通过--speculative-config配置启用。质量验证方面不要再用“感觉答得不错”来评估模型。我的习惯是沉淀一个 50-100 条的回归测试集覆盖三类典型任务格式要求明确的结构化输出、隐含推理链的逻辑题、业务上最频繁出现的真实问题。每次更换模型版本、调整量化级别或修改 prompt 模板之后跑一遍回归集记录正确率和字段格式达标率。这个仓库不花什么资源但能让你在“升级模型”和“修改模板”之后迅速知道是不是真的变好了也能在向同事解释“为什么不能换版本”时拿出数据。我自己的教训是曾经因为换了一个量化更激进的版本把代码生成任务的接口格式搞乱了一半如果没有回归集兜底这个问题会直接在线暴露。养成“先跑回归再上线”的习惯之后类似的事故基本没有重演过。希望帮到你。本文还有配套的精品资源点击获取