企业官网建设流程全解析

简介：2025 DeepSeek使用教程蓝皮书是一份从入门到进阶的系统指南，面向开发者、数据工程师与企业技术人员，能够有效解决上手难、选型模糊、部署缺少参照等问题。资源包内共包含一个PDF文档，整体大小约2.95MB，便于跨设备随时查阅。内容从第一章“DeepSeek概述”与核心功能介绍展开，深入解析高可扩展性和灵活性的技术架构，讲解多维度数据采集、索引搜索、分布式计算、数据容错与安全等能力；同时梳理金融实时风控、医疗影像辅助诊断、电商个性化推荐、云计算与移动通讯等应用场景。教程兼顾不同基础的学习者：初学者可获得完整的入门指南与案例分析，进阶者能够学习知识蒸馏、模型压缩、参数微调与本地化部署等技术，并通过项目实操加强对推理模型和算力优化的理解。整份文档结构清晰、层级分明，目前已有289人学习下载，适合作为日常技术查漏补缺和智能项目实施的手册。

1. DeepSeek-R1的定位与入场姿势

同样是解一道竞赛级数学题，OpenAI O1系列需要付出数倍算力，DeepSeek-R1在AIME上做到了79.8%准确率，API单价却压到竞品的三分之一；671B总参数的模型，蒸馏出精简版之后，能在日常设备上以每秒60 tokens的速度响应。这个反差决定了它不是又一个聊天机器人，而是把推理能力、部署成本和开源权重同时摆上桌的选择。下面按五条路线走：先拆训练机制弄明白它为什么强，再讲API怎么接、参数怎么调，然后处理最容易翻车的提示词部分，最后落到本地部署的量化路径。适合打算把DeepSeek接进业务系统的工程师，也适合想搞清楚R1和V3差在哪、何时该开深度思考的普通用户。

2. 双轨训练机制与671B参数分层设计

2.1 长思维链微调：拆解问题的能力从哪里来

DeepSeek-R1的训练路径分两轨。第一轨是长思维链微调（Long Chain-of-Thought Fine-tuning），思路不是让模型记住更多答案，而是让它学会把一个大问题拆成若干个子问题，每个子问题独立求解再汇总。这个能力在数学和代码场景效果最直观：AIME测试做到79.8%准确率，Codeforces竞赛里超过96.3%的人类选手。AIME竞赛题本身需要多步推导，模型要写出完整的中间过程，一个步骤出错就会连锁崩盘，所以这个数字反映的是推导链的稳定性，而不是单纯的检索能力。

思维链的层级和长度是R1与普通对话模型的分水岭。普通模型面对复杂问题倾向于直接给结论，R1会先规划：题目给了什么条件、需要用什么定理、哪一步可以并行验证。这个行为在API里能直接观察到：调用deepseek-reasoner时，返回的消息体里带有独立的推理过程字段，里面就是模型自己展开的思考轨迹。先建立这个概念：长思维链微调提供骨架，强化学习负责填血肉。

提示：在商业场景里对模型做深度定制时，保留完整推理过程有助于审计，因为你能看到的不只是答案，还包括模型是如何一步步逼近这个答案的。

2.2 无监督强化学习：不靠人工标注也能自我纠错

单一思维链微调的问题是数据瓶颈。要让模型学会反思、尝试替代解法，靠人工标注推理过程成本太高。R1的第二轨用的是无监督强化学习，核心是不依赖标准答案，通过奖励模型判断最终结果的质量，让模型在探索中自己发现哪些推理路径更容易得到正确结果。模型在推理过程中会自我反思与迭代优化，类似人类写完答案后回头检查。实现这个行为，靠的是强化学习的策略梯度：模型生成完整推理链，奖励模型对这一整条链打分，分数反馈到策略更新上。

这个机制带来的直接结果是工程类任务反超O1。SWE-bench要求模型读懂issue、改代码、过测试，R1在这个榜单上超过了O1系列。原因也好理解：代码任务天然适合试错-反馈的强化学习回路，一次错误的patch会被测试用例判负，模型在训练中反复接收这个信号，自然比纯监督学习更懂如何规避常见bug。

2.3 Benchmark速览与快速验证脚本

把R1的核心成绩列出来，方便后续做回归参照。

想第一时间验证这些数字，不用等论文复现，写个最小脚本同时调deepseek-chat和deepseek-reasoner跑同一道题，对比答案即可：

from openai import OpenAI client = OpenAI( api_key="sk-你的key", base_url="https://api.deepseek.com" ) prompt = "求1到1000之间所有不能被7整除的整数之和。" for model in ["deepseek-chat", "deepseek-reasoner"]: resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], max_tokens=2048 ) content = resp.choices[0].message.content reasoning = getattr(resp.choices[0].message, "reasoning_content", None) print(f"模型: {model}") print(f"推理过程: {reasoning[:200] if reasoning else '（无）'}") print(f"答案: {content[:500]}")

这个脚本先构造OpenAI客户端，把base_url指到DeepSeek的API地址；然后遍历两个模型名，对同一道题分别生成答案。deepseek-chat对应V3对话模型，deepseek-reasoner对应R1推理模型。reasoning_content是R1专属字段，V3为空，打印前200字能看到“先算总和，再扣掉7的倍数”这类推导痕迹。max_tokens设到2048是给推理模型留足输出空间，数学推导很容易超出默认长度。跑完你会看到，V3直接给结论，R1先进思考区写推导，这就是两种训练路线最直观的分野。

3. API接入与推理参数调优

3.1 两个模型入口的语义区别

DeepSeek平台对外提供两个模型名，它们不是版本号差异，而是训练目标的差异。deepseek-chat走V3对话模型，响应快、成本低，适合日常问答、文案改写等不需要深度推理的任务；deepseek-reasoner走R1推理模型，适合数学、代码、逻辑分析等多步任务，代价是首token延迟更高。

网页端的“深度思考”开关，本质上就是在这两个入口之间切换。关掉默认走V3，打开才调用R1。这个设计有个容易被忽略的好处：混合架构下，你可以把两个模型拼在一个工作流里，先用R1做问题拆解和方案设计，再用V3做润色和格式整理，成本与质量同时兼顾。

3.2 最小可用的流式调用

生产环境我不建议一次性等待完整响应，推理模型的思维链可能很长，一次性返回容易触发超时，也难做中断控制。流式调用是常见做法：

from openai import OpenAI client = OpenAI( api_key="sk-你的key", base_url="https://api.deepseek.com" ) stream = client.chat.completions.create( model="deepseek-reasoner", messages=[ {"role": "system", "content": "你是资深算法工程师，回答时给出推导过程。"}, {"role": "user", "content": "用动态规划思路分析背包问题的状态转移方程。"} ], temperature=0.6, max_tokens=4096, stream=True ) reasoning_parts = [] answer_parts = [] for chunk in stream: delta = chunk.choices[0].delta if getattr(delta, "reasoning_content", None): reasoning_parts.append(delta.reasoning_content) if getattr(delta, "content", None): answer_parts.append(delta.content) print("思考过程：") print("".join(reasoning_parts)) print("最终回答：") print("".join(answer_parts))

这段代码做了三件事：把stream参数打开，逐块接收返回值；通过delta.reasoning_content收集R1的思考过程，通过delta.content收集正式回答；最后分别拼接打印。推理过程中两个字段时间上交替出现，模型先把思考内容输出完，再输出正式答案。temperature设0.6是社区里比较常见的取值，推理任务建议控制在0.5到0.7之间，太低会让模型重复同一路径，太高则增加瞎编概率。max_tokens要留够，因为R1的思考部分也占用token配额。

提示：生产环境建议把reasoning_content单独落盘，它占用的token是计费的，但价值也高，可以做用户意图归因和问题调试。

3.3 成本模型与动态取舍

R1的API定价是输入1元/百万tokens、输出16元/百万tokens，整体约为竞品的三分之一。这个单价看着便宜，但推理模型输出的token里有相当一部分花在思维链上，实际花费不能只按业务答案长度估算。

实际项目里，我建议先用reasoner跑一轮把问题结构化，再把它拆出来的子问题交给chat完成。推理精度保住了，费用比全部走reasoner低一大截。如果任务本身能从已有知识库查答案，则优先查库，只有查不到或需要多步运算时才升级到R1。

3.4 联网搜索与知识截止边界

R1的训练数据截止到2023年10月，超过这个时间点的事件模型不知道。比如问“今天的实时汇率”，直接问会得到过时信息或无法访问的提示，正确做法是打开“联网搜索”让模型先检索再回答。API场景没有网页上的开关，需要自己在prompt里注入搜索结果，或者在外层接一个搜索工具，把Top-K条结果作为上下文传给模型。有个坑要注意：关闭联网搜索时，即使你给模型一个URL，它也无法自动访问页面内容，必须在请求前完成抓取和清洗。我习惯把抓取到的正文直接放进system消息，要求模型仅依据该内容作答，并注明不要引用未提供的数据，能显著减少幻觉。

4. 提示词策略：从SFT指令式转向RL自由式

4.1 为什么分步骤指令会拖累R1

早期SFT模型依赖人工标注的分步示范，提示词里写“先做A再做B最后C”能显著提升输出质量。但R1这类强化学习模型已经训练出了自己的解题路径，此时再用“第一步、第二步”去框它，相当于强迫一位熟练工程师按小学算术的格式写解题过程。蓝皮书里给了一个典型的基金报告案例：旧写法要求模型“先收集基金净值、收益率等数据，用Excel计算各项指标，对比同类基金表现，分析市场环境，最后整理报告”；新写法只需要“我需要一份某基金的财务分析报告，包含核心财务指标、市场对比和风险评估等要素”。后者反而生成得更完整。

提示：判断提示词该不该拆步骤，先想清楚模型是服从指令型还是自主推理型。对deepseek-reasoner，给出目标和约束就够，把过程控制权交给模型。

4.2 基金报告案例的两版Prompt对照

直接看代码里的对比，两套写法的差异非常直观：

# 旧版：面向SFT模型的分步指令 old_prompt = """ 请按以下步骤制作基金分析报告： 1. 收集基金净值、收益率等数据 2. 用Excel计算各项指标 3. 对比同类基金表现 4. 分析市场环境 5. 最后整理报告 """ # 新版：面向RL模型的目标式指令 new_prompt = """ 我需要一份某基金的财务分析报告， 请包含核心财务指标、市场对比和风险评估等要素。 报告面向基金持有者，结论需要给出可操作的调仓建议。 """ for prompt in [old_prompt, new_prompt]: resp = client.chat.completions.create( model="deepseek-reasoner", messages=[{"role": "user", "content": prompt}], max_tokens=3072 ) print(resp.choices[0].message.content[:300])

这段验证脚本沿用前面初始化好的client，把两个版本喂给同一个deepseek-reasoner模型。分步骤版本因为限定了执行序列，模型机械地按编号输出，数据收集和计算过程被放大，真正有价值的风险评估被压缩。目标式版本不约束过程，R1自己会组织出“数据获取-指标量化-横向对比-风险提示-调仓建议”的完整框架。注意这里还加了一个面向对象约束“面向基金持有者”，这是影响输出风格的关键参数：指定读者之后，模型会自动把术语改写成持有者能看懂的语言。

4.3 典型任务的提示词骨架

把不同场景的写法沉淀成可复用模板：

骨架背后只有一个原则：给出“要什么”和“不要什么”，少写“怎么算”。如果非要在提示词里出现步骤，最多写“先给出结论，再附推导”，这是为了让输出结构符合阅读习惯，不是教模型推理。

4.4 深度思考开关的选型逻辑

网页端入口是chat.DeepSeek.com，App端在应用商店搜索DeepSeek，认准蓝色鲸鱼图标。网页和App都有“深度思考”和“联网搜索”两个开关。“深度思考”打开后调用R1，不打开默认走V3。这个开关不是越频繁打开越好。日常快问快答、翻译、润色，V3足够且响应快；遇到复杂计算、算法设计、条款推演，再切到R1。两个开关可以同时打开，但注意：同时开启时R1会先联网取资料再做推理，首token延迟明显变长。我建议把“深度思考”当成一个显式的算力预算，团队里每人每月的reasoner调用量设上限，超出部分自动降级到chat，既控成本，也逼着大家优化提问质量，减少不必要的重推理请求。

5. 本地部署、量化压缩与工程化落地

5.1 知识蒸馏版与4bit量化的两级路径

671B参数的主力模型跑在云端，本地部署走的是另一条路。DeepSeek-R1的精简模型采用知识蒸馏技术，把大模型学到的能力提炼到小模型，在尽量保住准确率的前提下大幅压缩参数量。日常设备能跑，是因为两步叠加：蒸馏缩小模型规模，4bit量化再砍掉约75%的存储和计算需求。这两步不能混为一谈——蒸馏发生在训练阶段，改变的是参数量；量化发生在部署阶段，改变的是每个参数的位宽。常见做法是先跑通原始精度，再做量化校准，最后用校准后的模型做线上误差评估，确认精度损失在可接受范围再切换。

5.2 Ollama部署步骤

本地部署推理模型，Ollama是目前门槛最低的路径，几行命令就能把蒸馏版R1拉起来：

# 拉取DeepSeek-R1蒸馏版（按参数量选规格） ollama pull deepseek-r1:7b # 启动本地API服务，默认端口11434 ollama serve # 另一终端发起请求验证 curl http://localhost:11434/api/chat \ -d '{"model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "解释一下为什么4bit量化能减少显存占用"}], "stream": false}'

ollama pull会自动完成模型下载和格式转换；ollama serve把本地模型暴露成HTTP接口；curl那条命令用来做冒烟测试，确认模型能正常出答案。如果本机显存不够8GB，可以改拉deepseek-r1:1.5b，规格越小速度越快，但推理能力随之下降。部署后正常的响应速度大约每秒60 tokens左右，这个数字来自精简版在消费级设备上的实测，能支撑交互式问答，但别指望它扛高并发生产请求——本地部署得越轻，单请求吞吐越低。

5.3 如何验证本地部署效果

部署不等于结束，需要一套可复现的自检方法。我用固定难度的数学题加固定提示词做回归。举例：问“一个笼子里有鸡和兔共35个头、94只脚，问各几只”，正常的推理模型应该输出方程求解过程，并给出鸡23只兔12只。如果输出过程不完整或数字错误，先确认模型蒸馏版本对应的参数量是否选得过小，再检查量化是否丢失过多精度，最后回退到不量化版本对比测试，确认瓶颈出在哪一层。再把第一次提问和第二次提问的耗时做对比，差值能反映模型是否完成了加载。推理模型第一次请求要载入权重，延迟通常是后续请求的三到十倍，属于正常现象；如果每次都慢，就要检查内存是否在做swap。

5.4 客户端工具接入DeepSeek的通用做法

最后落一个具体技巧。DeepSeek的API兼容OpenAI的消息格式，所以很多OpenAI生态的客户端工具都能直接复用。以codex这类命令行编程助手为例，你不需要改代码，只需在配置里把模型服务地址指向DeepSeek的base_url，并把模型名改成deepseek-reasoner，就可以用R1辅助写代码。vscode里的Continue插件也是同一套逻辑。配置改法核心就两行：

# 环境变量方式切换服务地址 export OPENAI_API_KEY="sk-你的key" export OPENAI_BASE_URL="https://api.deepseek.com"

注意要关闭原客户端的默认API地址，DeepSeek不兼容部分OpenAI私有参数，某些客户端会带上自定义字段或特定的response_format，遇到这类报错就检查请求体，移除不受支持的字段。改完环境变量后，先用一条短请求确认返回消息里出现了reasoning_content字段，出现即表示R1已接管后续对话。

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