简介一份面向Python开发者与AI应用初学者的DeepSeek API调用实战指南重点解决从环境准备到真实接口对接的全流程问题帮助读者摆脱复杂数据处理和高质量文本生成时的调用门槛。文档从技术背景与Python基础讲起依次覆盖开发环境搭建、API密钥注册、requests库安装、请求构造与响应解析并进一步延伸至错误处理、重试机制、日志记录、批量调用与异步性能优化同时结合密钥存储、访问控制、传输安全等最佳实践贴近真实项目开发需求。整体内容按引言、工具准备、密钥获取、代码实践、进阶优化、安全规范、总结展望的顺序组织逻辑递进清晰便于按章节循序渐进地学习。资源为单文件PDF共27页压缩包大小约1.87MB目录层级完整每章配有示例代码与操作说明后续维护与查阅都很方便。目前已有171人学习下载无论是刚接触API调用的初学者还是希望规范接口开发流程的进阶开发者都能从中获得可直接落地的调用方法与排错思路。1. 从零到一Python 调用 DeepSeek API 这件事到底难在哪把 Python 和 DeepSeek API 接起来最少的代码不到二十行可多数人的第一次尝试还是卡在启动阶段。原因不在语法而在三个容易被忽略的细节环境里缺少可用的请求依赖、API Key 没有安全存放、max_tokens和temperature这类参数不知道该给什么值。下面按真实接入顺序推进先整理 Python 环境与依赖再分别用 openai SDK 和原生 requests 跑通对话接口之后处理多轮上下文、错误码与重试最后把调用收敛成一个带 Token 预算控制的模块。这套路径对刚学完 Python 基础语法、想拿大模型 API 做第一个实战项目的开发者最友好有几年经验的工程师也能在参数边界和排错逻辑上找到可用信息。2. 调用 DeepSeek API 前先把手头的 Python 环境与依赖理清楚2.1 确认 Python 版本用虚拟环境隔离依赖如果你电脑上还没有 Python先按 python 安装教程 装好再回来已经装了的第一步是确认版本。DeepSeek API 的官方 Python SDK 底层依赖了新版本的 httpx 和 pydanticPython 3.8 以下经常装不上或者装上后在初始化客户端时直接抛类型错误所以建议使用 3.10 及以上版本。python --version mkdir deepseek-demo cd deepseek-demo python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install openai requests python-dotenvvenv的作用是把依赖隔离在当前项目目录不污染全局 site-packages后续升级包或切换项目不会互相打架。Windows 下激活命令改成.venv\Scripts\activate如果你在用 VSCode 配置 Python 环境记得把解释器切换到这个虚拟环境里否则终端激活了、编辑器里还是旧解释器import 照样报 ModuleNotFoundError。pip install的写法和单独装 numpy 的方法完全一样下载慢就追加-i https://pypi.tuna.tsinghua.edu.cn/simple改用 PyPI 清华镜像源。提示虚拟环境激活后命令行提示符前面会出现(.venv)前缀。没有这个前缀说明激活失败后面安装的包全部落在全局环境里。装完后用pip list看一眼版本确认 openai、requests、python-dotenv 三条都在再进入鉴权配置环节。2.2 API Key 的获取与 .env 文件管理在 DeepSeek 开放平台的控制台里找到 API Keys 页面创建密钥后只会完整显示一次之后只能看到掩码需要立即复制保存。拿到 Key 先别往代码里写——硬编码进.py文件意味着每次提交代码都可能把密钥带出去这也是 GitHub 上密钥泄露事件最常见的原因。常见做法是放进项目根目录的.env文件并用.gitignore忽略它运行时由 python-dotenv 加载到环境变量echo DEEPSEEK_API_KEYsk-xxxxxxxx .env echo .env .gitignore环境变量存放内容加载方式DEEPSEEK_API_KEY平台创建的 sk- 开头密钥load_dotenv()DEEPSEEK_BASE_URLhttps://api.deepseek.com代码里os.getenvbase_url也建议放进环境变量而不是写死在代码里切换联调地址和正式地址时只改配置不动代码。若 Key 疑似泄露不要试图在控制台里修改直接吊销重建旧 Key 会在几分钟内失效。整个项目提交到远程仓库前养成检查.gitignore的习惯确认.env确实被忽略。2.3 SDK 与原生 requests两种请求方式怎么选DeepSeek API 兼容 OpenAI 的接口格式这意味着你既可以用现成的 openai 库也可以只带 requests 手写请求。两条路都值得会因为排查线上问题时直接用 requests 构造一个请求对比返回结果比翻 SDK 源码快得多。对比维度openai SDKrequests 手写流式输出原生迭代器需要自己解析 SSE 分块类型提示与错误包装完整无额外依赖较重几乎为零典型场景业务项目开发脚本验证、接口调试我的建议是项目里主用 openai SDK图它处理了鉴权头、JSON 序列化和流式解析同时保留一个 requests 版本作为调试工具。下一章两种写法都给出最小可运行代码参数以 DeepSeek 官方 chat completions 接口为准。3. 用 Python 跑通 DeepSeek APISDK 与原生请求的最小实现3.1 基于 openai SDK 的最小对话代码先把环境变量加载进来再创建客户端。注意base_url必须显式指定为 DeepSeek 的地址openai 库默认指向 OpenAI 官方服务器不传这个参数请求会打到错误的地方。import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL, https://api.deepseek.com), ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一位Python技术助手回答尽量简短}, {role: user, content: 用一句话解释什么是REST API}, ], temperature0.7, max_tokens512, ) print(resp.choices[0].message.content)关键参数逐个说。model选deepseek-chat对应通用对话模型需要展示推理过程时换成deepseek-reasonermessages是完整对话上下文数组里每个元素都有 rolesystem 设定人设user 是用户输入assistant 是模型历史回复temperature控制随机性取值范围 0 到 2写代码、提取结构化信息给 0.2 以下写文案创意内容再提到 0.8 左右max_tokens限制单次输出长度设太短回答会被截断设太长又占预算常规单轮对话 512 到 1024 够用。响应对象里resp.choices[0].message.content是最终文本。如果你需要看每次请求消耗了多少 Token打印resp.usage里面包含 prompt_tokens、completion_tokens 和 total_tokens 三个数值。3.2 不装 SDK用 requests 手写一次请求某些场景下你不想引入 openai 那套依赖或者只是想验证密钥是否有效直接发一个 POST 最干脆。整体写法和 python 爬虫 抓接口的套路一致构造 headers、组装 payload、解析 JSON。import os import requests from dotenv import load_dotenv load_dotenv() url https://api.deepseek.com/chat/completions headers { Authorization: fBearer {os.getenv(DEEPSEEK_API_KEY)}, Content-Type: application/json, } payload { model: deepseek-chat, messages: [{role: user, content: 用三句话解释Python的GIL}], stream: False, max_tokens: 512, } resp requests.post(url, jsonpayload, headersheaders, timeout60) resp.raise_for_status() data resp.json() print(data[choices][0][message][content])timeout60必须写不写的话 requests 会无限等待一旦服务端异常整个脚本直接挂住。raise_for_status()会在返回 4xx 或 5xx 时抛出异常配合下一章的排错表能快速定位问题。这里用jsonpayload而不是datapayload前者会自动做 JSON 序列化并设置 Content-Type后者按表单编码接口会返回 422。3.3 流式输出与温控参数对照对话模型生成长文时非流式模式要等全部内容生成完才返回耗时几秒到几十秒流式模式把响应拆成多个数据块边生成边返回首字延迟大幅降低体验接近打字机。SDK 里只改一个参数streamTrueresp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 写一首关于春天的五言绝句}], streamTrue, temperature0.9, ) for chunk in resp: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)流式模式下每个 chunk 的choices[0].delta.content只包含本次增量文本累加后才是完整回答所以循环里要逐段拼接。flushTrue保证每段到达即输出不带缓冲。参数取值区间对输出的影响temperature0.0 ~ 2.0越低越确定越高越发散max_tokens1 ~ 8192硬性截断输出长度streamtrue / false响应返回方式不影响内容质量deepseek-reasoner模型建议把 temperature 固定放在 0.8 到 1.0 附近它对取值约束更严格乱调可能返回 400。写生产代码时把流式与非流式的解析逻辑分开封装避免用一个函数硬扛两种返回结构。4. DeepSeek API 实战多轮上下文、错误码排错与重试策略4.1 多轮对话的上下文维护DeepSeek API 本身不记忆任何历史每次请求都要把完整对话通过 messages 传过去。多轮对话的正确姿势是把每轮 user 输入和模型回复依次追加进列表下一轮整体发送。messages [{role: system, content: 你是Python导师回答控制在五句以内}] MAX_HISTORY 6 def push_message(role, content): messages.append({role: role, content: content}) if len(messages) MAX_HISTORY: messages.pop(1) # 保留 system丢弃最早的非 system 消息 def chat(user_input): push_message(user, user_input) resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.3 ) reply resp.choices[0].message.content push_message(assistant, reply) return reply print(chat(什么是装饰器)) print(chat(那带参数的装饰器怎么写))注意两点。第一第二轮请求会把第一轮的整个问答都带上上下文越长prompt_tokens 越大费用按 Token 计所以长会话必须设置历史窗口超出就丢弃最早的非 system 消息。第二assistant 回复必须以模型实际返回内容为准不能自己编造历史模型看到前后矛盾的消息会生成混乱的回答。按条数截断滑动窗口简单直接但不同消息长度差异很大更精细的控制放在第五章的 Token 预算方案里。4.2 错误码排错清单接口报错时不要靠猜先看返回的 HTTP 状态码和错误体里的 message 字段大部分问题在十几秒内就能定位状态码含义优先排查方向401鉴权失败.env 是否加载、Key 是否被吊销402余额不足开放平台账户充值422请求参数不合法messages 结构、max_tokens 范围429请求频率或并发超限降低并发、加退避重试500 / 503服务端异常稍后重试配合指数退避以 429 为例响应头通常会带Retry-After字段里面是建议等待的秒数重试逻辑里应优先读这个值没有该字段再走通用的退避方案。402 这类计费问题重试没有意义直接在业务层转成人话提示比如“账户余额不足请充值后重试”。4.3 指数退避重试与并发上限网络抖动和服务端偶发 5xx 在真实环境里不可避免重试是必须的但不能固定间隔死等。常见做法是退避递增第一次失败等 1 秒第二次等 2 秒第三次等 4 秒同时加入少量随机抖动避免多个请求同时重试造成二次拥塞。import time import random def call_with_retry(client, messages, max_retries3, base_delay1.0): for attempt in range(max_retries): try: return client.chat.completions.create( modeldeepseek-chat, messagesmessages, timeout60, ) except Exception as exc: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) random.uniform(0, 0.5) time.sleep(delay)openai SDK 自带默认 2 次重试内部也是退避机制这个自定义函数主要面向 requests 手写版本以及需要精确控制重试次数的场景。追求更高吞吐时可以用 Python 多进程 或 asyncio 并发发起多个请求但 DeepSeek 的 429 限流很敏感个人项目并发超过 5 时触发概率明显上升建议用信号量控制并发数把 QPS 压在账户配额以内。判断是否触顶的标准很简单日志里 429 出现频率开始上升说明该降并发而不是升并发。5. 把 DeepSeek API 封装成带 Token 预算与历史截断的模块5.1 一个能直接放进项目的 DeepSeekClient把前面散落的逻辑收进一个类初始化时加载凭据并创建客户端ask()方法内部完成上下文追加、历史截断和请求发送。这样业务代码只关心传参和拿结果不关心 API 细节后续换模型、加缓存都只改一处。import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() class DeepSeekClient: def __init__(self, modeldeepseek-chat, max_history6): self.client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL), ) self.model model self.max_history max_history self.messages [{role: system, content: 你是一位严谨的工程师}] def ask(self, content, max_tokens1024): self.messages.append({role: user, content: content}) while len(self.messages) self.max_history: self.messages.pop(1) resp self.client.chat.completions.create( modelself.model, messagesself.messages, max_tokensmax_tokens ) reply resp.choices[0].message.content self.messages.append({role: assistant, content: reply}) return reply重试逻辑可以直接把 4.3 节的call_with_retry传进ask()内部替换最底层的 create 调用不需要改动类的外部接口。max_history控制保留轮数实际使用中可以先粗调再按下面的预算校准细化。5.2 用 usage 回读校准预算按条数截断只解决长度问题不解决 Token 预算问题。更实用的做法是配合响应里的resp.usage.total_tokens做预算控制连续对话时如果最近两次请求的 total_tokens 持续逼近 8000说明上下文已经接近模型窗口上限此时应当把历史消息从前往后弹出而不是等接口返回 400。这个方法的好处是拿真实消耗说话不依赖任何估算公式。中英混合文本也可以按“字符数除以二”粗估 Token 量作为弹出策略的辅助判断。验证封装是否生效的办法是连续发二十轮递增长度的对话观察日志里 total_tokens 的曲线历史窗口生效时曲线应该是锯齿状而非单调上升。本文还有配套的精品资源点击获取 Python调用DeepSeek API实战：从环境配置到Token预算控制
简介一份面向Python开发者与AI应用初学者的DeepSeek API调用实战指南重点解决从环境准备到真实接口对接的全流程问题帮助读者摆脱复杂数据处理和高质量文本生成时的调用门槛。文档从技术背景与Python基础讲起依次覆盖开发环境搭建、API密钥注册、requests库安装、请求构造与响应解析并进一步延伸至错误处理、重试机制、日志记录、批量调用与异步性能优化同时结合密钥存储、访问控制、传输安全等最佳实践贴近真实项目开发需求。整体内容按引言、工具准备、密钥获取、代码实践、进阶优化、安全规范、总结展望的顺序组织逻辑递进清晰便于按章节循序渐进地学习。资源为单文件PDF共27页压缩包大小约1.87MB目录层级完整每章配有示例代码与操作说明后续维护与查阅都很方便。目前已有171人学习下载无论是刚接触API调用的初学者还是希望规范接口开发流程的进阶开发者都能从中获得可直接落地的调用方法与排错思路。1. 从零到一Python 调用 DeepSeek API 这件事到底难在哪把 Python 和 DeepSeek API 接起来最少的代码不到二十行可多数人的第一次尝试还是卡在启动阶段。原因不在语法而在三个容易被忽略的细节环境里缺少可用的请求依赖、API Key 没有安全存放、max_tokens和temperature这类参数不知道该给什么值。下面按真实接入顺序推进先整理 Python 环境与依赖再分别用 openai SDK 和原生 requests 跑通对话接口之后处理多轮上下文、错误码与重试最后把调用收敛成一个带 Token 预算控制的模块。这套路径对刚学完 Python 基础语法、想拿大模型 API 做第一个实战项目的开发者最友好有几年经验的工程师也能在参数边界和排错逻辑上找到可用信息。2. 调用 DeepSeek API 前先把手头的 Python 环境与依赖理清楚2.1 确认 Python 版本用虚拟环境隔离依赖如果你电脑上还没有 Python先按 python 安装教程 装好再回来已经装了的第一步是确认版本。DeepSeek API 的官方 Python SDK 底层依赖了新版本的 httpx 和 pydanticPython 3.8 以下经常装不上或者装上后在初始化客户端时直接抛类型错误所以建议使用 3.10 及以上版本。python --version mkdir deepseek-demo cd deepseek-demo python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install openai requests python-dotenvvenv的作用是把依赖隔离在当前项目目录不污染全局 site-packages后续升级包或切换项目不会互相打架。Windows 下激活命令改成.venv\Scripts\activate如果你在用 VSCode 配置 Python 环境记得把解释器切换到这个虚拟环境里否则终端激活了、编辑器里还是旧解释器import 照样报 ModuleNotFoundError。pip install的写法和单独装 numpy 的方法完全一样下载慢就追加-i https://pypi.tuna.tsinghua.edu.cn/simple改用 PyPI 清华镜像源。提示虚拟环境激活后命令行提示符前面会出现(.venv)前缀。没有这个前缀说明激活失败后面安装的包全部落在全局环境里。装完后用pip list看一眼版本确认 openai、requests、python-dotenv 三条都在再进入鉴权配置环节。2.2 API Key 的获取与 .env 文件管理在 DeepSeek 开放平台的控制台里找到 API Keys 页面创建密钥后只会完整显示一次之后只能看到掩码需要立即复制保存。拿到 Key 先别往代码里写——硬编码进.py文件意味着每次提交代码都可能把密钥带出去这也是 GitHub 上密钥泄露事件最常见的原因。常见做法是放进项目根目录的.env文件并用.gitignore忽略它运行时由 python-dotenv 加载到环境变量echo DEEPSEEK_API_KEYsk-xxxxxxxx .env echo .env .gitignore环境变量存放内容加载方式DEEPSEEK_API_KEY平台创建的 sk- 开头密钥load_dotenv()DEEPSEEK_BASE_URLhttps://api.deepseek.com代码里os.getenvbase_url也建议放进环境变量而不是写死在代码里切换联调地址和正式地址时只改配置不动代码。若 Key 疑似泄露不要试图在控制台里修改直接吊销重建旧 Key 会在几分钟内失效。整个项目提交到远程仓库前养成检查.gitignore的习惯确认.env确实被忽略。2.3 SDK 与原生 requests两种请求方式怎么选DeepSeek API 兼容 OpenAI 的接口格式这意味着你既可以用现成的 openai 库也可以只带 requests 手写请求。两条路都值得会因为排查线上问题时直接用 requests 构造一个请求对比返回结果比翻 SDK 源码快得多。对比维度openai SDKrequests 手写流式输出原生迭代器需要自己解析 SSE 分块类型提示与错误包装完整无额外依赖较重几乎为零典型场景业务项目开发脚本验证、接口调试我的建议是项目里主用 openai SDK图它处理了鉴权头、JSON 序列化和流式解析同时保留一个 requests 版本作为调试工具。下一章两种写法都给出最小可运行代码参数以 DeepSeek 官方 chat completions 接口为准。3. 用 Python 跑通 DeepSeek APISDK 与原生请求的最小实现3.1 基于 openai SDK 的最小对话代码先把环境变量加载进来再创建客户端。注意base_url必须显式指定为 DeepSeek 的地址openai 库默认指向 OpenAI 官方服务器不传这个参数请求会打到错误的地方。import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL, https://api.deepseek.com), ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一位Python技术助手回答尽量简短}, {role: user, content: 用一句话解释什么是REST API}, ], temperature0.7, max_tokens512, ) print(resp.choices[0].message.content)关键参数逐个说。model选deepseek-chat对应通用对话模型需要展示推理过程时换成deepseek-reasonermessages是完整对话上下文数组里每个元素都有 rolesystem 设定人设user 是用户输入assistant 是模型历史回复temperature控制随机性取值范围 0 到 2写代码、提取结构化信息给 0.2 以下写文案创意内容再提到 0.8 左右max_tokens限制单次输出长度设太短回答会被截断设太长又占预算常规单轮对话 512 到 1024 够用。响应对象里resp.choices[0].message.content是最终文本。如果你需要看每次请求消耗了多少 Token打印resp.usage里面包含 prompt_tokens、completion_tokens 和 total_tokens 三个数值。3.2 不装 SDK用 requests 手写一次请求某些场景下你不想引入 openai 那套依赖或者只是想验证密钥是否有效直接发一个 POST 最干脆。整体写法和 python 爬虫 抓接口的套路一致构造 headers、组装 payload、解析 JSON。import os import requests from dotenv import load_dotenv load_dotenv() url https://api.deepseek.com/chat/completions headers { Authorization: fBearer {os.getenv(DEEPSEEK_API_KEY)}, Content-Type: application/json, } payload { model: deepseek-chat, messages: [{role: user, content: 用三句话解释Python的GIL}], stream: False, max_tokens: 512, } resp requests.post(url, jsonpayload, headersheaders, timeout60) resp.raise_for_status() data resp.json() print(data[choices][0][message][content])timeout60必须写不写的话 requests 会无限等待一旦服务端异常整个脚本直接挂住。raise_for_status()会在返回 4xx 或 5xx 时抛出异常配合下一章的排错表能快速定位问题。这里用jsonpayload而不是datapayload前者会自动做 JSON 序列化并设置 Content-Type后者按表单编码接口会返回 422。3.3 流式输出与温控参数对照对话模型生成长文时非流式模式要等全部内容生成完才返回耗时几秒到几十秒流式模式把响应拆成多个数据块边生成边返回首字延迟大幅降低体验接近打字机。SDK 里只改一个参数streamTrueresp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 写一首关于春天的五言绝句}], streamTrue, temperature0.9, ) for chunk in resp: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)流式模式下每个 chunk 的choices[0].delta.content只包含本次增量文本累加后才是完整回答所以循环里要逐段拼接。flushTrue保证每段到达即输出不带缓冲。参数取值区间对输出的影响temperature0.0 ~ 2.0越低越确定越高越发散max_tokens1 ~ 8192硬性截断输出长度streamtrue / false响应返回方式不影响内容质量deepseek-reasoner模型建议把 temperature 固定放在 0.8 到 1.0 附近它对取值约束更严格乱调可能返回 400。写生产代码时把流式与非流式的解析逻辑分开封装避免用一个函数硬扛两种返回结构。4. DeepSeek API 实战多轮上下文、错误码排错与重试策略4.1 多轮对话的上下文维护DeepSeek API 本身不记忆任何历史每次请求都要把完整对话通过 messages 传过去。多轮对话的正确姿势是把每轮 user 输入和模型回复依次追加进列表下一轮整体发送。messages [{role: system, content: 你是Python导师回答控制在五句以内}] MAX_HISTORY 6 def push_message(role, content): messages.append({role: role, content: content}) if len(messages) MAX_HISTORY: messages.pop(1) # 保留 system丢弃最早的非 system 消息 def chat(user_input): push_message(user, user_input) resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.3 ) reply resp.choices[0].message.content push_message(assistant, reply) return reply print(chat(什么是装饰器)) print(chat(那带参数的装饰器怎么写))注意两点。第一第二轮请求会把第一轮的整个问答都带上上下文越长prompt_tokens 越大费用按 Token 计所以长会话必须设置历史窗口超出就丢弃最早的非 system 消息。第二assistant 回复必须以模型实际返回内容为准不能自己编造历史模型看到前后矛盾的消息会生成混乱的回答。按条数截断滑动窗口简单直接但不同消息长度差异很大更精细的控制放在第五章的 Token 预算方案里。4.2 错误码排错清单接口报错时不要靠猜先看返回的 HTTP 状态码和错误体里的 message 字段大部分问题在十几秒内就能定位状态码含义优先排查方向401鉴权失败.env 是否加载、Key 是否被吊销402余额不足开放平台账户充值422请求参数不合法messages 结构、max_tokens 范围429请求频率或并发超限降低并发、加退避重试500 / 503服务端异常稍后重试配合指数退避以 429 为例响应头通常会带Retry-After字段里面是建议等待的秒数重试逻辑里应优先读这个值没有该字段再走通用的退避方案。402 这类计费问题重试没有意义直接在业务层转成人话提示比如“账户余额不足请充值后重试”。4.3 指数退避重试与并发上限网络抖动和服务端偶发 5xx 在真实环境里不可避免重试是必须的但不能固定间隔死等。常见做法是退避递增第一次失败等 1 秒第二次等 2 秒第三次等 4 秒同时加入少量随机抖动避免多个请求同时重试造成二次拥塞。import time import random def call_with_retry(client, messages, max_retries3, base_delay1.0): for attempt in range(max_retries): try: return client.chat.completions.create( modeldeepseek-chat, messagesmessages, timeout60, ) except Exception as exc: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) random.uniform(0, 0.5) time.sleep(delay)openai SDK 自带默认 2 次重试内部也是退避机制这个自定义函数主要面向 requests 手写版本以及需要精确控制重试次数的场景。追求更高吞吐时可以用 Python 多进程 或 asyncio 并发发起多个请求但 DeepSeek 的 429 限流很敏感个人项目并发超过 5 时触发概率明显上升建议用信号量控制并发数把 QPS 压在账户配额以内。判断是否触顶的标准很简单日志里 429 出现频率开始上升说明该降并发而不是升并发。5. 把 DeepSeek API 封装成带 Token 预算与历史截断的模块5.1 一个能直接放进项目的 DeepSeekClient把前面散落的逻辑收进一个类初始化时加载凭据并创建客户端ask()方法内部完成上下文追加、历史截断和请求发送。这样业务代码只关心传参和拿结果不关心 API 细节后续换模型、加缓存都只改一处。import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() class DeepSeekClient: def __init__(self, modeldeepseek-chat, max_history6): self.client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL), ) self.model model self.max_history max_history self.messages [{role: system, content: 你是一位严谨的工程师}] def ask(self, content, max_tokens1024): self.messages.append({role: user, content: content}) while len(self.messages) self.max_history: self.messages.pop(1) resp self.client.chat.completions.create( modelself.model, messagesself.messages, max_tokensmax_tokens ) reply resp.choices[0].message.content self.messages.append({role: assistant, content: reply}) return reply重试逻辑可以直接把 4.3 节的call_with_retry传进ask()内部替换最底层的 create 调用不需要改动类的外部接口。max_history控制保留轮数实际使用中可以先粗调再按下面的预算校准细化。5.2 用 usage 回读校准预算按条数截断只解决长度问题不解决 Token 预算问题。更实用的做法是配合响应里的resp.usage.total_tokens做预算控制连续对话时如果最近两次请求的 total_tokens 持续逼近 8000说明上下文已经接近模型窗口上限此时应当把历史消息从前往后弹出而不是等接口返回 400。这个方法的好处是拿真实消耗说话不依赖任何估算公式。中英混合文本也可以按“字符数除以二”粗估 Token 量作为弹出策略的辅助判断。验证封装是否生效的办法是连续发二十轮递增长度的对话观察日志里 total_tokens 的曲线历史窗口生效时曲线应该是锯齿状而非单调上升。本文还有配套的精品资源点击获取