简介这份PDF文档共27页聚焦Python调用DeepSeek-R1 API完整流程适合希望快速上手大模型接口开发的Python工程师、机器学习爱好者也可用于智能客服、内容生成、教育辅导等业务场景。资源以单个PDF文件打包大小仅1.92MB章节目录清晰、阅读方便。目前已有286人浏览/学习。文档从DeepSeek-R1模型概述与API权限获取讲起逐步演示Python环境搭建、依赖安装、请求头与参数构建、响应处理等基础操作并通过手把手代码示例展示带参文本生成、批量调用与异步处理针对身份验证错误、请求参数错误、网络连接问题、速率限制等常见报错给出可落地的解决方案。同时补充了性能优化、缓存机制与资源监控建议并覆盖同步/异步批量调用两种实现方式可直接用于真实项目排错和调优。1. Python调用DeepSeek-R1API实战为什么多数人卡在第一步很多第一次接触Python调用DeepSeek-R1API实战的人并不是被代码难住的而是把DeepSeek-R1当成了普通的聊天模型来用。请求发出去了响应里的正文看起来也正常但回答质量平平和网页版完全是两个水平。问题出在多数示例只讲怎么发请求不讲怎么处理R1特有的思维链字段——reasoning_content。这个字段决定了R1的推理能力能不能真正为你所用。这篇笔记会从环境准备、最小可用代码、参数调优到排障把完整的调用路径拆开讲一遍适合刚拿到API Key的开发者也适合想从Chat系列迁移到R1、或者把R1接进自动化流程的工程师。2. 调用前准备API Key、SDK选型与Python环境怎么搭2.1 openai SDK还是requests直连两条路线各有什么取舍DeepSeek-R1的API兼容OpenAI的接口格式所以现成的两条路都能走一是装openai官方Python SDK只改base_url和api_key二是直接用requests库打HTTP请求。两者没有绝对优劣只有适不适合当前场景。我一般这样选第一次跑通、想要彻底看清请求和响应结构用requests直连要快速集成到已有项目、需要流式输出或并发调用直接用openai SDK。前者少一层封装出错了能直接看到HTTP状态码还能用curl验证后者的好处是代码量少换模型时改动小。对比项requests直连openai SDK依赖数量只需requests需要openai且版本要和接口匹配调试直观性高响应体原样可见中间层会吞掉部分字段需特殊处理流式支持手动解析SSE流内置stream参数换其他模型改URL和请求体就行换base_url即可兼容性好2.2 Python环境检查与依赖安装建议用Python 3.8以上版本。我在Windows和Linux上都跑过两个平台的差异不大唯一要注意的是别用系统自带的Python装依赖容易冲突。常见做法是开一个虚拟环境把requests和openai装进去。# 创建虚拟环境python3.8均可 python -m venv r1env source r1env/bin/activate # Windows下用 r1env\Scripts\activate # 安装依赖 pip install requests openai这段命令里python -m venv r1env会新建一个独立的Python环境source r1env/bin/activate激活它。装requests和openai是因为两条路线我们都可能用到。openai库的版本不用刻意挑最新稳定版就行如果代码里遇到OpenAI()构造函数报参数错误多半是版本太老升级即可。2.3 首次连通性验证用curl先给API探路写Python代码之前我强烈建议先用curl把API连通性验证一遍。这样做的好处是把「网络问题」和「代码问题」切分开万一后面Python代码报错你能确认不是Key失效或网络不通。curl的输出里能看到最原始的JSON结构方便对照后面的代码。curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-xxxxxxxx \ -d { model: deepseek-reasoner, messages: [{role: user, content: 11等于几}], max_tokens: 1024 }返回的JSON里choices[0].message下标下面有两个字段content和reasoning_content。reasoning_content就是R1的思维链。如果这一步返回401或403先检查API Key是否复制完整注意Key开头的sk-前缀不能丢也不要有引号残留在环境变量里。连通验证通过后再进入Python代码环节。3. 跑通最小可用示例requests直连DeepSeek-R1的完整代码3.1 一次请求的全过程从构造请求体到解析响应这段代码是最小可用的完整版。我没有用任何封装库只靠requests方便你看到每一个参数和字段的来龙去脉。import requests import json # API地址固定是这个不需要加版本号 url https://api.deepseek.com/chat/completions # 这里硬编码Key只为了方便演示生产环境务必用环境变量 api_key sk-xxxxxxxx headers { Content-Type: application/json, Authorization: fBearer {api_key} } payload { model: deepseek-reasoner, # R1对应的是deepseek-reasoner messages: [ {role: user, content: 一个长方体的长宽高分别是3、4、5求对角线长度} ], max_tokens: 2048, temperature: 1.0, # R1推荐用默认温度不要调低 } resp requests.post(url, headersheaders, jsonpayload, timeout60) data resp.json() # 建议先打印原始响应结构第一次跑一定要看 # print(json.dumps(data, ensure_asciiFalse, indent2)) message data[choices][0][message] print(思考过程) print(message.get(reasoning_content, )) print(\n最终回答) print(message.get(content, ))这段代码做了四件事构造请求头、组装payload、发送POST请求、解析响应。关键点在于model参数必须是deepseek-reasoner而不是deepseek-chatmessages列表里role只能是user或assistantR1不支持system角色的优先指令这点和很多其他模型不同塞了system消息要么被忽略、要么直接报错。timeout60是必须的。R1的思考时间比普通模型长尤其是复杂推理题30秒都不一定够超时设短了代码没报错但响应被截断人还找不到原因。3.2 响应字段解析为什么说reasoning_content是R1的灵魂上面的代码里reasoning_content拿出来直接打印了。这个字段别的模型没有是R1在给出正式回答前先进行内部推理的内容。它可能是一大段文字也可能包含公式推导长度往往超过最终答案。实测中一个中等难度的数学题reasoning_content可能有几千字而content只有几百字。正因如此解析时必须用.get()而不是直接下标访问。因为某些情况下比如遇到敏感词过滤或上下文截断reasoning_content可能不存在直接message[reasoning_content]会抛KeyError把整个程序打断。用get()取不到就给空字符串程序就不会挂。另外提醒一句content字段里有时会包含\boxed{}这类LaTeX格式的公式这是R1的正常输出不是BUG。下游做文档渲染时记得保留原样别自作主张删除。3.3 把回答落盘JSON格式保存方便排查真实项目中很少有人只把结果打印到控制台。我习惯把完整响应体原样存下来然后再做业务字段抽取。这样一旦后续处理出问题可以回看原始返回。# 续接上一段代码 with open(r1_response.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) # 只保存最终答案方便其他程序读取 result { question: payload[messages][0][content], reasoning: message.get(reasoning_content, ), answer: message.get(content, ), } with open(r1_result.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2, )存两份的原因很简单r1_response.json是API原始返回字段最全排错时对照它r1_result.json是清洗后的任务结果便于下游直接消费。注意写文件时ensure_asciiFalse否则中文会被转成\uXXXX打开文件根本没法看。4. 把R1用出质量的4个关键参数与输出后处理4.1 temperature、top_p、max_tokens怎么设R1官方建议和普通模型不太一样。常见做法是把temperature保持在1.0左右不要为了追求稳定输出而降得太低。因为R1的推理过程依赖一定的随机性来探索解法温度调到0.5以下答案会变得死板推理质量肉眼可见下降。有个比较玄学的现象同一道数学题温度调低反而容易答错这是我翻车几次后的血泪经验。参数R1推荐值普通模型常用值注意点temperature1.00.7左右低于0.5时推理质量明显下降top_p默认0.9建议不动和temperature同时改容易互相干扰max_tokens按需建议不低于2048512思考过程会占掉一半以上配额streamfalse按需流式模式时字段结构不同max_tokens是很多人忽略的坑。这个参数限定的是“完成部分”的总长度包括reasoning_content和content两者之和。所以给R1设置512时思考过程可能还没写完就被截断最终回答残缺甚至直接输出一段话到一半就停了。我的经验是复杂任务给4096以上简单问答至少2048。4.2 上下文长度预算思维链会把额度吃光R1单次请求可以携带的历史消息长度比普通模型要紧张因为每次都要额外输出一大段思维链。实际算账时要把这条公式记牢本次消耗Token 历史消息Token 本次思考Token 本次回答Token。历史消息每多一轮R1的思考量也会增加。实操中超出上下文长度最常见的表现不是直接报错而是回答质量骤降。因为API有时候会自动截断历史模型看不到对话开头的关键信息。所以多轮对话里我一般会把历史消息限制在最近三轮以内再早的对话直接用普通摘要代替。省下来的空间全留给思考过程。4.3 输出清洗拿到answer后的三步处理R1输出里有两个常见干扰一是reasoning_content有可能出现在content里原因是模型在回答过程中“自言自语”混入了思考二是content里的Markdown代码块可能没闭合。给下游用之前简单清洗是必要的。import re def clean_r1_output(text: str) - str: # 去掉模型偶尔重复输出的思考片段以嗯、让我开头的内容 text re.sub(r^[嗯啊哈].*?$, , text, flagsre.MULTILINE) # 自动补齐未闭合的代码块 if text.count() % 2 ! 0: text \n # 去掉多余的连续空行 text re.sub(r\n{3,}, \n\n, text) return text.strip()这里的三步处理分别是移除语气词开头的思考残留、补全代码块、压缩多余换行。第一项最常用R1在回答一些开放式问题时会出现一两行类似思考过程的碎碎念第三项是为了让输出直接进工单系统或者文档库时格式不会太难看。5. DeepSeek-R1调用避坑从401到超时我记录过的真实报错5.1 unexpected status 401 unauthorized: incorrect api key provided现象请求发出去后API返回401 unauthorized同行信息里提示incorrect api key provided而且后面跟着sk-svcac****这样的脱敏Key片段。原因表面看是Key错了实际上最常见的原因是复制Key时把空格、换行符带进去了或者用环境变量时变量名拼错。另一个隐蔽原因是网页控制台的Key列表里有多个Key旧Key在重置后失效了但代码里还留着旧的。解决先用chmod或编辑器打开存Key的文件确认没有隐藏字符。然后在Python里打印repr(api_key)看字符串内容print(repr(api_key)) # 正常情况输出 sk-xxxxx如果看到 sk-xxxxx\\n 就是多了换行如果是环境变量去Shell配置文件里重新export注意等号两边不能有空格。改完记得重启终端或source配置文件再跑。5.2 400报错上下文超限与请求体校验失败现象状态码400错误信息可能显示this models maximum context length is … tokens也可能报messages结构错误。原因最大头是上下文超限。R1虽然支持较长上下文但因为思维链会大量消耗Token当历史消息加上本次思考内容超过限制时就触发400。另外system角色消息也会让部分接口版本报错。解决把system角色合并到user消息里或者直接删掉。上下文超限时做两件事一是压缩历史消息把早期对话用一两句话概括二是改用deepseek-chat模型处理低难度任务把R1只留给需要推理的场景。我实测过同一段长文本普通模型消耗的Token只有R1的三分之一左右。5.3 思维链输出过长回答半天不出来甚至重复循环现象请求正常reasoning_content很长但content为空或者reasoning_content里反复出现同一句话。原因R1在探索解法时陷入局部循环尤其是题目表述模糊、有多种理解方式时。另一个诱因是max_tokens太小思考写到一半被强制截断模型就开始重复前面的话试图找回上下文。解决临时缓解可以把temperature提到1.2打破循环长期做法是改写提示词明确限定“只输出最终答案不要反复验证”。同时把max_tokens调大给思考留足空间。如果多次出现建议检查输入的题目是否有多义性补充限定词。5.4 连接超时与重试网络抖动不该让程序直接崩现象requests.exceptions.ConnectTimeout或ReadTimeout程序中断退出没有拿到任何结果。原因R1推理耗时波动大简单题2秒复杂题30秒以上。网络层代理不稳定、公共网络丢包也会导致超时。如果用了代理或自定义网络设置确认API地址api.deepseek.com没有被额外拦截。解决做两层防护——超时时间拉长并加重试。记住超时后重试要带指数退避别一失败就立刻重试。import time import requests def call_with_retry(payload, headers, max_retry3): for attempt in range(max_retry): try: resp requests.post( https://api.deepseek.com/chat/completions, headersheaders, jsonpayload, timeout120 ) if resp.status_code 200: return resp.json() # 429是限流503是服务暂时不可用值得重试 if resp.status_code in (429, 500, 503): time.sleep(2 ** attempt * 5) continue resp.raise_for_status() except requests.exceptions.Timeout: time.sleep(5) continue raise RuntimeError(多次重试仍失败请检查网络或API状态)6. 进阶流式输出与多轮对话的稳定姿势6.1 流式输出用SSE协议拿到即时的增量响应把stream设为true后响应体变成一行行SSE格式用requests库的iter_lines逐行读取再用json.loads解析每行数据。这里要留意delta字段里同样会带reasoning_content和content两种内容显示时建议分开区域展示避免把思考过程混进最终答案。6.2 多轮对话思维链不该带进下一轮请求多轮对话最容易犯的错误是把上一轮的reasoning_content拼进下一轮的messages里。R1不需要回顾自己上次想了什么它只需要知道对话历史和最终答案。正确做法是只保留assistant的content字段。我习惯在组装messages时过滤掉reasoning_content这个习惯帮我避免了很多次莫名其妙的回答漂移。6.3 回归验证拿一道标准题做上线前的最后检查每次调整完代码或参数我都会跑同一道题验证一个笼子里有鸡和兔共35个头、94只脚问各有多少只。这题适合做回归因为R1正常发挥时思考过程完整、答案明确。如果这题都答不对说明参数配置有偏差。最后还想多嘴一句把API Key放代码里这种事情真的不要再做了环境变量或密钥管理服务才是后悔药。希望帮到你。本文还有配套的精品资源点击获取 Python调用DeepSeek-R1 API实战：思维链处理与参数调优指南
简介这份PDF文档共27页聚焦Python调用DeepSeek-R1 API完整流程适合希望快速上手大模型接口开发的Python工程师、机器学习爱好者也可用于智能客服、内容生成、教育辅导等业务场景。资源以单个PDF文件打包大小仅1.92MB章节目录清晰、阅读方便。目前已有286人浏览/学习。文档从DeepSeek-R1模型概述与API权限获取讲起逐步演示Python环境搭建、依赖安装、请求头与参数构建、响应处理等基础操作并通过手把手代码示例展示带参文本生成、批量调用与异步处理针对身份验证错误、请求参数错误、网络连接问题、速率限制等常见报错给出可落地的解决方案。同时补充了性能优化、缓存机制与资源监控建议并覆盖同步/异步批量调用两种实现方式可直接用于真实项目排错和调优。1. Python调用DeepSeek-R1API实战为什么多数人卡在第一步很多第一次接触Python调用DeepSeek-R1API实战的人并不是被代码难住的而是把DeepSeek-R1当成了普通的聊天模型来用。请求发出去了响应里的正文看起来也正常但回答质量平平和网页版完全是两个水平。问题出在多数示例只讲怎么发请求不讲怎么处理R1特有的思维链字段——reasoning_content。这个字段决定了R1的推理能力能不能真正为你所用。这篇笔记会从环境准备、最小可用代码、参数调优到排障把完整的调用路径拆开讲一遍适合刚拿到API Key的开发者也适合想从Chat系列迁移到R1、或者把R1接进自动化流程的工程师。2. 调用前准备API Key、SDK选型与Python环境怎么搭2.1 openai SDK还是requests直连两条路线各有什么取舍DeepSeek-R1的API兼容OpenAI的接口格式所以现成的两条路都能走一是装openai官方Python SDK只改base_url和api_key二是直接用requests库打HTTP请求。两者没有绝对优劣只有适不适合当前场景。我一般这样选第一次跑通、想要彻底看清请求和响应结构用requests直连要快速集成到已有项目、需要流式输出或并发调用直接用openai SDK。前者少一层封装出错了能直接看到HTTP状态码还能用curl验证后者的好处是代码量少换模型时改动小。对比项requests直连openai SDK依赖数量只需requests需要openai且版本要和接口匹配调试直观性高响应体原样可见中间层会吞掉部分字段需特殊处理流式支持手动解析SSE流内置stream参数换其他模型改URL和请求体就行换base_url即可兼容性好2.2 Python环境检查与依赖安装建议用Python 3.8以上版本。我在Windows和Linux上都跑过两个平台的差异不大唯一要注意的是别用系统自带的Python装依赖容易冲突。常见做法是开一个虚拟环境把requests和openai装进去。# 创建虚拟环境python3.8均可 python -m venv r1env source r1env/bin/activate # Windows下用 r1env\Scripts\activate # 安装依赖 pip install requests openai这段命令里python -m venv r1env会新建一个独立的Python环境source r1env/bin/activate激活它。装requests和openai是因为两条路线我们都可能用到。openai库的版本不用刻意挑最新稳定版就行如果代码里遇到OpenAI()构造函数报参数错误多半是版本太老升级即可。2.3 首次连通性验证用curl先给API探路写Python代码之前我强烈建议先用curl把API连通性验证一遍。这样做的好处是把「网络问题」和「代码问题」切分开万一后面Python代码报错你能确认不是Key失效或网络不通。curl的输出里能看到最原始的JSON结构方便对照后面的代码。curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-xxxxxxxx \ -d { model: deepseek-reasoner, messages: [{role: user, content: 11等于几}], max_tokens: 1024 }返回的JSON里choices[0].message下标下面有两个字段content和reasoning_content。reasoning_content就是R1的思维链。如果这一步返回401或403先检查API Key是否复制完整注意Key开头的sk-前缀不能丢也不要有引号残留在环境变量里。连通验证通过后再进入Python代码环节。3. 跑通最小可用示例requests直连DeepSeek-R1的完整代码3.1 一次请求的全过程从构造请求体到解析响应这段代码是最小可用的完整版。我没有用任何封装库只靠requests方便你看到每一个参数和字段的来龙去脉。import requests import json # API地址固定是这个不需要加版本号 url https://api.deepseek.com/chat/completions # 这里硬编码Key只为了方便演示生产环境务必用环境变量 api_key sk-xxxxxxxx headers { Content-Type: application/json, Authorization: fBearer {api_key} } payload { model: deepseek-reasoner, # R1对应的是deepseek-reasoner messages: [ {role: user, content: 一个长方体的长宽高分别是3、4、5求对角线长度} ], max_tokens: 2048, temperature: 1.0, # R1推荐用默认温度不要调低 } resp requests.post(url, headersheaders, jsonpayload, timeout60) data resp.json() # 建议先打印原始响应结构第一次跑一定要看 # print(json.dumps(data, ensure_asciiFalse, indent2)) message data[choices][0][message] print(思考过程) print(message.get(reasoning_content, )) print(\n最终回答) print(message.get(content, ))这段代码做了四件事构造请求头、组装payload、发送POST请求、解析响应。关键点在于model参数必须是deepseek-reasoner而不是deepseek-chatmessages列表里role只能是user或assistantR1不支持system角色的优先指令这点和很多其他模型不同塞了system消息要么被忽略、要么直接报错。timeout60是必须的。R1的思考时间比普通模型长尤其是复杂推理题30秒都不一定够超时设短了代码没报错但响应被截断人还找不到原因。3.2 响应字段解析为什么说reasoning_content是R1的灵魂上面的代码里reasoning_content拿出来直接打印了。这个字段别的模型没有是R1在给出正式回答前先进行内部推理的内容。它可能是一大段文字也可能包含公式推导长度往往超过最终答案。实测中一个中等难度的数学题reasoning_content可能有几千字而content只有几百字。正因如此解析时必须用.get()而不是直接下标访问。因为某些情况下比如遇到敏感词过滤或上下文截断reasoning_content可能不存在直接message[reasoning_content]会抛KeyError把整个程序打断。用get()取不到就给空字符串程序就不会挂。另外提醒一句content字段里有时会包含\boxed{}这类LaTeX格式的公式这是R1的正常输出不是BUG。下游做文档渲染时记得保留原样别自作主张删除。3.3 把回答落盘JSON格式保存方便排查真实项目中很少有人只把结果打印到控制台。我习惯把完整响应体原样存下来然后再做业务字段抽取。这样一旦后续处理出问题可以回看原始返回。# 续接上一段代码 with open(r1_response.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) # 只保存最终答案方便其他程序读取 result { question: payload[messages][0][content], reasoning: message.get(reasoning_content, ), answer: message.get(content, ), } with open(r1_result.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2, )存两份的原因很简单r1_response.json是API原始返回字段最全排错时对照它r1_result.json是清洗后的任务结果便于下游直接消费。注意写文件时ensure_asciiFalse否则中文会被转成\uXXXX打开文件根本没法看。4. 把R1用出质量的4个关键参数与输出后处理4.1 temperature、top_p、max_tokens怎么设R1官方建议和普通模型不太一样。常见做法是把temperature保持在1.0左右不要为了追求稳定输出而降得太低。因为R1的推理过程依赖一定的随机性来探索解法温度调到0.5以下答案会变得死板推理质量肉眼可见下降。有个比较玄学的现象同一道数学题温度调低反而容易答错这是我翻车几次后的血泪经验。参数R1推荐值普通模型常用值注意点temperature1.00.7左右低于0.5时推理质量明显下降top_p默认0.9建议不动和temperature同时改容易互相干扰max_tokens按需建议不低于2048512思考过程会占掉一半以上配额streamfalse按需流式模式时字段结构不同max_tokens是很多人忽略的坑。这个参数限定的是“完成部分”的总长度包括reasoning_content和content两者之和。所以给R1设置512时思考过程可能还没写完就被截断最终回答残缺甚至直接输出一段话到一半就停了。我的经验是复杂任务给4096以上简单问答至少2048。4.2 上下文长度预算思维链会把额度吃光R1单次请求可以携带的历史消息长度比普通模型要紧张因为每次都要额外输出一大段思维链。实际算账时要把这条公式记牢本次消耗Token 历史消息Token 本次思考Token 本次回答Token。历史消息每多一轮R1的思考量也会增加。实操中超出上下文长度最常见的表现不是直接报错而是回答质量骤降。因为API有时候会自动截断历史模型看不到对话开头的关键信息。所以多轮对话里我一般会把历史消息限制在最近三轮以内再早的对话直接用普通摘要代替。省下来的空间全留给思考过程。4.3 输出清洗拿到answer后的三步处理R1输出里有两个常见干扰一是reasoning_content有可能出现在content里原因是模型在回答过程中“自言自语”混入了思考二是content里的Markdown代码块可能没闭合。给下游用之前简单清洗是必要的。import re def clean_r1_output(text: str) - str: # 去掉模型偶尔重复输出的思考片段以嗯、让我开头的内容 text re.sub(r^[嗯啊哈].*?$, , text, flagsre.MULTILINE) # 自动补齐未闭合的代码块 if text.count() % 2 ! 0: text \n # 去掉多余的连续空行 text re.sub(r\n{3,}, \n\n, text) return text.strip()这里的三步处理分别是移除语气词开头的思考残留、补全代码块、压缩多余换行。第一项最常用R1在回答一些开放式问题时会出现一两行类似思考过程的碎碎念第三项是为了让输出直接进工单系统或者文档库时格式不会太难看。5. DeepSeek-R1调用避坑从401到超时我记录过的真实报错5.1 unexpected status 401 unauthorized: incorrect api key provided现象请求发出去后API返回401 unauthorized同行信息里提示incorrect api key provided而且后面跟着sk-svcac****这样的脱敏Key片段。原因表面看是Key错了实际上最常见的原因是复制Key时把空格、换行符带进去了或者用环境变量时变量名拼错。另一个隐蔽原因是网页控制台的Key列表里有多个Key旧Key在重置后失效了但代码里还留着旧的。解决先用chmod或编辑器打开存Key的文件确认没有隐藏字符。然后在Python里打印repr(api_key)看字符串内容print(repr(api_key)) # 正常情况输出 sk-xxxxx如果看到 sk-xxxxx\\n 就是多了换行如果是环境变量去Shell配置文件里重新export注意等号两边不能有空格。改完记得重启终端或source配置文件再跑。5.2 400报错上下文超限与请求体校验失败现象状态码400错误信息可能显示this models maximum context length is … tokens也可能报messages结构错误。原因最大头是上下文超限。R1虽然支持较长上下文但因为思维链会大量消耗Token当历史消息加上本次思考内容超过限制时就触发400。另外system角色消息也会让部分接口版本报错。解决把system角色合并到user消息里或者直接删掉。上下文超限时做两件事一是压缩历史消息把早期对话用一两句话概括二是改用deepseek-chat模型处理低难度任务把R1只留给需要推理的场景。我实测过同一段长文本普通模型消耗的Token只有R1的三分之一左右。5.3 思维链输出过长回答半天不出来甚至重复循环现象请求正常reasoning_content很长但content为空或者reasoning_content里反复出现同一句话。原因R1在探索解法时陷入局部循环尤其是题目表述模糊、有多种理解方式时。另一个诱因是max_tokens太小思考写到一半被强制截断模型就开始重复前面的话试图找回上下文。解决临时缓解可以把temperature提到1.2打破循环长期做法是改写提示词明确限定“只输出最终答案不要反复验证”。同时把max_tokens调大给思考留足空间。如果多次出现建议检查输入的题目是否有多义性补充限定词。5.4 连接超时与重试网络抖动不该让程序直接崩现象requests.exceptions.ConnectTimeout或ReadTimeout程序中断退出没有拿到任何结果。原因R1推理耗时波动大简单题2秒复杂题30秒以上。网络层代理不稳定、公共网络丢包也会导致超时。如果用了代理或自定义网络设置确认API地址api.deepseek.com没有被额外拦截。解决做两层防护——超时时间拉长并加重试。记住超时后重试要带指数退避别一失败就立刻重试。import time import requests def call_with_retry(payload, headers, max_retry3): for attempt in range(max_retry): try: resp requests.post( https://api.deepseek.com/chat/completions, headersheaders, jsonpayload, timeout120 ) if resp.status_code 200: return resp.json() # 429是限流503是服务暂时不可用值得重试 if resp.status_code in (429, 500, 503): time.sleep(2 ** attempt * 5) continue resp.raise_for_status() except requests.exceptions.Timeout: time.sleep(5) continue raise RuntimeError(多次重试仍失败请检查网络或API状态)6. 进阶流式输出与多轮对话的稳定姿势6.1 流式输出用SSE协议拿到即时的增量响应把stream设为true后响应体变成一行行SSE格式用requests库的iter_lines逐行读取再用json.loads解析每行数据。这里要留意delta字段里同样会带reasoning_content和content两种内容显示时建议分开区域展示避免把思考过程混进最终答案。6.2 多轮对话思维链不该带进下一轮请求多轮对话最容易犯的错误是把上一轮的reasoning_content拼进下一轮的messages里。R1不需要回顾自己上次想了什么它只需要知道对话历史和最终答案。正确做法是只保留assistant的content字段。我习惯在组装messages时过滤掉reasoning_content这个习惯帮我避免了很多次莫名其妙的回答漂移。6.3 回归验证拿一道标准题做上线前的最后检查每次调整完代码或参数我都会跑同一道题验证一个笼子里有鸡和兔共35个头、94只脚问各有多少只。这题适合做回归因为R1正常发挥时思考过程完整、答案明确。如果这题都答不对说明参数配置有偏差。最后还想多嘴一句把API Key放代码里这种事情真的不要再做了环境变量或密钥管理服务才是后悔药。希望帮到你。本文还有配套的精品资源点击获取